Who's Online |
51 user(s) are online ( 38 user(s) are browsing Forums)
Members: 0
Guests: 51
more...
|
|
Headlines |
-
audiocast.lha - audio/misc
May 15, 2026
-
airscanner.lha - utility/print
May 15, 2026
-
nodeamiga.lha - development/language
May 14, 2026
-
unzip.lha - utility/archive
May 13, 2026
-
reportplus.lha - utility/misc
May 12, 2026
-
alienbreed3d.lha - game/fps
May 11, 2026
-
hwp_ahx.lha - library/hollywood
May 11, 2026
-
hwp_digibooster.lha - library/hollywood
May 11, 2026
-
hwp_xmp.lha - library/hollywood
May 11, 2026
-
dopus5byai.lha - utility/filetool
May 11, 2026
|
|
|
|
|
Re: X1000 CFE Patches: Testers Welcome (Fear not: real-time, no reflashing) v.02 NEW!
|
Posted on: Yesterday 14:36
#1
|
Not too shy to talk 
|
@joerg Quote: Wrong, OS3.9 includes updated, complete kickstart modules like exec, scsi.device, FFS, etc. which replace the old 3.1 ROM versions, it doesn't patch the OS 3.1 versions. expansion.library starts only one kickstart module, the one with the highest struct Resident rt_Version, if several kickstart modules with the same rt_Name name are installed, ROM and RAM in case of OS3.9. They weren't embedded in a full Kickstart image. That is a ROM image. If full Kickstart modules are included it should have supported ROM 3.0 and not needed ROM 3.1. That doesn't make sense. In any case it still wasn't a perfectly clean solution because it didn't load the modules and patch in before booting. It needed to partially boot and reset.
|
|
|
|
|
|
Re: X1000 CFE Patches: Testers Welcome (Fear not: real-time, no reflashing) v.02 NEW!
|
|
Not too shy to talk
|
@joerg Quote: I never had an A3000, but AFAIK it's ROM (Kickstart 1.4) can load the SuperKickstart (Kickstart 2.x) from a HD connected to the internal SCSI controller as well (a file in DEVS: on the boot partition), not only from a floppy. Well that sounds a lot more useful than being stuck to floppy. Where was this logic on the A4000 and A1200? I do wonder how it handled the Exec problem. What I mean is how much of Exec or the OS would exist before loading in the soft Kick and jumping to it. Same for the A1000 Kick loader which used the same kind of disk load logic for bringing in the Kickstart. So for the OS3.9 example it looked a bit sloppy. The Kickstart loads up, DOS boots and then an OS patch loads and reboots the machine. The reboot was a bit messy. And it wasn't a true soft Kick image, just patching existing OS3.1 in memory. So, a logical expectation, needing only OS3.0 ROMS which where close to OS3.1 wasn't met. I ended up installing an OS3.1 ROM just to run OS3.9. But I wondered why it needed it for a live software patch. Quote: Both Eyetech and bPlan/Genesi sold Linux PPC versions of their AmigaOS/MorphOS PPC systems. Can't find a link to a Eyetech LinuxOne page, the other one was https://web.archive.org/web/2008051407 ... ww.genesi-usa.com/odw.php I recall the ODW. This looked like good hardware. But I didn't see evidence of it being released. It appeared to be coming after the Pegasos 2. But instead it looks like they went backwards. Abandoning the Pegasos and releasing this inferior Efika. It didn't make sense! The Pegasos did at least receive some official Linux support. And by that I mean Debian did provide support on official CD images to boot Linux on a Pegasos. They were compatible and had Pegasos boot scripts. This is more than the AmigaOne got. People have disagreed with me over the AmigaOne having Linux support. But a standard Debian install CD doesn't boot on an AmigaOne. Not only must a Linux CD be customised to boot but the kernel needs compiling for the hardware or a generic kernel will crash. So I rest my case. This is not what I call Debian support and I didn't think I needed to point that out to people but some people just think differently. 
|
|
|
|
|
|
Re: X1000 CFE Patches: Testers Welcome (Fear not: real-time, no reflashing) v.02 NEW!
|
|
Not too shy to talk
|
@joerg Quote: It's not limited to the Amiga (later called "A1000") with it's 256 KB WORM for the KickStart, the A3000, at least early versions of it, used a "SuperKickstart" floppy disk for booting a 512 KB version AmigaOS (IIRC some 1.4 Betas and the 2.0 and 2.1 release versions) as well. I recall the "SuperKickstart" disk. Though by that stage a Kickstart on floppy, especially larger one, would have looked slow and annoying. Given the Amiga had that dependence on ROM a better, though more expensive solution, would have been a flash ROM the way I see it. Quote: IIRC for my A1000s I had several modified Kickstart floppies with a 512 KB OS (256 KB original kickstart 0.9-1.4 + 256 KB added tools, extended features, debugging, tools, etc.) which used the 256 KB WORM + the 256 KB TrapDor RAM expansion for it. There would have been a trick to it. I know a normal Kickdisk has a signature of KICK. On WB this would not be identified as a DOS disk without any DOS0 or DOS1 and beyond. I don't recall how a Kickstart disk come up on WB. Unless it knew what KICK is it would have come up as NDOS. IIRC I read of some patch that allows it to accept KICK as a DOS disk. Unless it wasn't an issue. I also came across the CIA OVL bit. Used for Kickstart lock. And how some early games even used it by loading data into the usual Kickstart space so they had extra memory. Quote: I never understood where that myth came from... Maybe because of the (cheaper?) "LinuxOne" PPC systems sold by EyeTech as well? Same hardware as the AmigaOne, just with a different U-Boot version which can only boot Linux but doesn't include the AmigaOS 4.x booting parts. I think you answered your own question there: doesn't include the AmigaOS 4.x booting parts.  That would be the caveat. The small code handling the AmigaOS 4.x booting. I don't quite recall the "LinuxOne" but just having that code looks like the catalyst for the myth. Quote: It was always, since about 25 years, secretly hidden in the public U-Boot sources I came across it some years back and there were no surprises there.
|
|
|
|
|
|
Re: X1000 CFE Patches: Testers Welcome (Fear not: real-time, no reflashing) v.02 NEW!
|
|
Not too shy to talk
|
@joerg Quote: Yes, SLB_v2 calls U-Boot functions for the ext2fs support.
There were 2 main reasons for the "SLB" boot method used on the AmigaOne SE/XE/etc.:
- Too small EEPROM for PPCBoot/U-Boot + additional AmigaOS file system loading and AmigaOS booting implementations, etc., even much worse on the µA1 with it's onboard R7000 GPU without a ROM, the BIOS for it is included in the U-Boot image instead (AFAIK compressed, but I don't know if gzip, bzip2 or something else, and maybe even other U-Boot parts had to be compressed on the µA1 as well to include everything required in the small EEPROM). It would have been expected to host the Kickstart on flash ROM, given an Amiga had Kickstart on ROM, but of course it would be too big. So that was moved to disk. UBoot in concept is foreign to Amiga in general since AmigaDOS booted the system and it didn't use a boot loader concept like today. The disk based Kickstart was more like the A1000 Kick, where it was loaded into memory from disk and locked in place. But, lacking the AmigaOS imagery of asking for Kick disk, as well as any minimal OS components such as Exec and trackdisk device driver. So by UBoot unpacking parts of itself, it needs time as well as RAM to even boot. Quote: - Licence reasons. U-Boot is GPL and therefore closed source code, like the implementations for all AmigaOS file systems and ISO9660, couldn't be included in U-Boot itself but had to be moved into a separate binary (SLB/SLB_v2). When Kickstart was all closed source this issue wouldn't have come up. So as soon as third party code was needed to bootstrap on independent hardware this GPL issue would come in. On top of this, people used to talk about the magic code in UBoot that booted AmigaOS, as if it was secretly hidden. I didn't think it was so secret. Anyone who knew how an Amiga booted would know what it needed to do. The drive was RDB formatted as standard. With boot block code in RDB boot blocks. But it didn't need to be embedded in RDB even and could exist within the first 16 or so blocks of the disk. UBoot just needed to locate the first BOOT block in the chain and load them all in. Because of this a hybrid ISO/USB is trivial to write, an image supporting both USB and CD media, by just installing a custom chain loader which diverts to CD bootblock from USB. UBoot can find a BOOT block from disk or USB media. Quote: Adding an ext2fs implementation in AmigaBoot, if it can't use firmware functions for it like SLB_v2 does, may be problematic since no GPL code, for example nothing from the Linux nor GRUB ext2fs sources, can be used in AmigaBoot. OTOH there may be other, free and usable for AmigaBoot implementations of ext2fs instead, for example in Net/Free/Open/DragonFly BSD. That likely would have made it harder as well. And since the point AmigaBoot is to be an AmigaBoot it does what is expected. While the OF client interface does support standard open and read methods, it's unlikely it would support transparent access to ext2/3, given it has device access and not higher level filesystem support limited to CFE. In any case, I solved this myself, by creating a boot loader and menu editor for Linux that uses AmigaBoot to show the menu. Instead of Ext3 it uses DOS3. And I had to figure out how to write my own EXEC binary to load or unpack kernel and ramdisk into memory then launch into kernel.
|
|
|
|
|
|
Re: X1000 CFE Patches: Testers Welcome (Fear not: real-time, no reflashing) v.02 NEW!
|
|
Not too shy to talk
|
@kas1e Quote: The thing which i currently not very well understand , is why there needs for different amigaboot.of and loader.of. I mean, should't it all be just done inside of amigaboot.of ? So in the Kicklayout documentation, it lists the loader.of as containing Exec. But that's not entirely accurate. To quote:
; Each configuration must have exactly one line with the EXEC keyword.
; This specifies the filename of the main kernel to use. This kernel is
; the absolute minimum required to boot. It contains, among other things,
; exec.library.
That's misleading. The exec.library is in fact in the kernel module. The loader.of patches the Kickstart in memory and then would jump start into Exec. What's also misleading is the Kicklayout mentions a bootloader.txt that doesn't exist. I think you are right with loader.of being a linker/loader. It also looks like it contains an ELF loader as it would need to load ELF modules in as binaries. Also, if you look you see the loader.of itself isn't an ELF, but is pure binary. IIRC it relocates itself before running. Possibly they wanted to avoid overloading amigaboot.of with extra code. And it's code that needs loading regardless. Well, loading from disk, then loading to memory. Also, the AmigaOne/XE has a loader. So this method was in place before amigaboot became a thing. ... In other news did some more USB testing. I checked volume label was unique and changed device name also in case. Still not showing with HDD connected. Reformatted and copied my fresh Update 2 volume to it. Even with FFS disk cache command and buffers it's still slow. Looked same as before. Drive not showing. Despite loading Kickstart off USB. Did a test. Rebooted to startup menu a few times after inserting USB into front port. Showed up in menu! But it wasn't booting it. I found the pri was too low and set at 0 so HDD volume was first, which must be first in DOS list. Raised it to 5 so it can boot. So: - Appears to ignore os4_bootdevice which it should have set to USB stick. - Boot pri needed to be 5 (or 10) to compensate like floppy in past. - Can only locate and mount drive on direct USB port. I also tried just using my front port. With USB patch. But, even after running patch then inserting stick, amigaboot still couldn't see stick. So I need to pull it out of one port and insert in another. Strange. Amigaboot can see it in my keyboard hub. AmigaDOS can only see it in a direct port.
|
|
|
|
|
|
Re: X1000 CFE Patches: Testers Welcome (Fear not: real-time, no reflashing) v.02 NEW!
|
|
Not too shy to talk
|
@joerg Quote: What an ugly mess... And i thought the old "SLB" method used on the AmigaOne SE/XE/µA1 and Sam4x0, which can no longer be used on newer systems for various reasons, was a bad hack already I preferred that way. It really should have been handled by Media Toolbox when installing a drive but was easy enough. However that also has other flaws such defaulting on DOS5 or DOS6 when DOS7 is the minimum supported for Workbench. Quote: But compared to what AmigaBoot.(ub|of) seems to do, like ignoring the RDB bootable flags of the partitions, it was an easy method that actually worked, across all possible boot methods supported by the hardware and firmware (TFPT, PATA, SATA, USB, CF, MicroSD, ..., supporting lots of different file systems, not only at least 8 AmigaOS ones but for example ext2fs for Linux booting as well, and ISO9660 El Torito for any OS, etc.) Yes, I expressed my gripe about lack of Linux support, which wasn't taken kindly and was met with a retort. It also looks like SLB had access to UBoot support for Ext2 where as amigaboot.of using the OF interface has no support for filesystems so handles it all itself. At least from what I can tell, it scans for block devices, but doesn't try to open any files. Also, this was even worse in Media Toolbox. No support at all. The user had to manually create a boot volume. I'm sorry, a boot volume, is this Linux? Then copy the bootloader. Then they decided to create the BOOT naming standard, after the fact, which cannot be used for updating boot loader. I don't see the excuse here, check for BOOT: and copy of it exists, otherwise tell the user they need to update by hand. I also expressed that the boot volume made it complicated. The reply I got was it was easier for the developers. Who cares! The point of OS4 is to be an AmigaOS and be friendly. This goes backwards. Again, it should have been in Media Toolbox, when the drive is installed. Simply create boot volume as part of installing, copy boot loader, done. See, the developers can rely on their easy boot volume, while the user can easily install HDD into system. Every one is happy. Obvious solution to me.  But it looks like nbache has the solution to the boot flag. A variable already exists. So there is a solution. It also reveals another flaw in the X1000, against it being decent hardware, and that is an inability to manage and save any settings to NVRAM from OS4. It should be in the RTAS resource. But somehow on the X1000 the OS4 developers didn't know the secret to writing to NVRAM or it was too complicated to implement. Quote: Even the much worse method used for booting AmigaOS 4.x PPC on classic Amigas, with AmigaOS 3.0/3.1 m68k used as "Firmware", seems to be better than what AmigaBoot is doing on the Peg2, X1000, X5000 and A1222+ 🤷 That is a rather odd arrangement of using AmigaOS to load AmigaOS. Which it needs to without any kind of flash ROM. But, it almost goes down the family line, as it's a similar method to the old OS3.9 Kickstart load, patch and reboot.
|
|
|
|
|
|
Re: X1000 CFE Patches: Testers Welcome (Fear not: real-time, no reflashing) v.02 NEW!
|
|
Not too shy to talk
|
@TSK Quote: I tried to remove the BootDevice file from some of them but that didn't change anything. That's because the BootDevice file species the device to boot from. In other words from where to boot Workbench. Since amigaboot.of is working at the Kickstart level the boot process hasn't got that far yet. I can see it makes no sense from a user point of view to include non-bootable devices. Of course the boot flag predates a bootable Kickstart. I don't see any obvious variables it looks for. Perhaps they would consider adding this as an option.
|
|
|
|
|
|
Re: X1000 CFE Patches: Testers Welcome (Fear not: real-time, no reflashing) v.02 NEW!
|
|
Not too shy to talk
|
@kas1e Quote: So that good, now maybe it worth trying to attach one hdd first, and try with it, and check wtf, etc. So we will find the patter to understand if it patch issue or amigaboot or missconfiguration So I plugged it all back in and tested again. In fact I only removed my main boot drive and left all others connected. The other SSD connected only has one OS4 volume, all the rest are Linux. It got stuck on boot again. I see the same two issues occurring. Which are the USB drive is not being detected by mass storage so that prevents it being the boot drive. It explains why it keeps booting to HDD after loading Kickstart off USB. However the old boot error about missing Workbench doesn't show up. I guess it just picks the next in the boot list. I'm not sure why a HDD full of partitions would mess with mass storage. Unless there is some limit to bootable volumes. I do have a few different Kickstarts I can test. Not that many, Update 1 may not be there, but Update 2 and 3 are. Update 3 may be too new so I may need to drop back down to Update 2. Easy enough. But a pure USB loading test would be better. I still have the ISO USB also. As to my device setup, I have mostly set this up as standard. That is what SATA port they specify to connect HDD and DVD. I know others have changed but I left mine as default ports as I didn't want any trouble. The only exception to this would be I have two optical drives, or in my case two Bluray drives, with one being a writer. And now with an SSD all ports are filled. I don't have any extra PCI cards except an RT8169. And don't have a CF card. Don't think I ever put one in. Quote: So i disassemble amigaboot.of, and that how it works: I expected as much. So it ignores any boot flags. Perhaps because the boot flag is designed for DOS boot and it's a level earlier loading Kickstart. Still seems inconsistent from a user perspective. I wonder then if some variable is needed to configure your patch? For example to apply PIO/DMA patch but disable adding devices. So far as I know arguments cannot be parsed on command line, unless there's a way, so NVRAM variable my be needed. Also, I notice your patches don't exit with the usual CFE exception that clears the screen. So you must really hook into the CFE routines for console and exiting. I'd like to write a binary that doesn't cause an exception when exiting normally with a 0.
|
|
|
|
|
|
Re: X1000 CFE Patches: Testers Welcome (Fear not: real-time, no reflashing) v.02 NEW!
|
|
Not too shy to talk
|
@kas1e So got some interesting results. Quote: Now, see, after a while you have LOGO on screen (before it was halt with nothing) :)) Some days more and you will be able to boot :) Lol. Quote: My wild guess is that you simple overmess everything with your 15 boot partitions, boot priorities and so on. I had a check and all except one volume has boot pri of 0. The one exception is my Linux boot volume with pri of 1. Quote: Just do simple test : disconnect everything from sata port (not from mother board itself, just disconnect all devices for test). And then simple power on, load usb patch, reinstert usb-stick (ffs one, with boot priority flag set to 0) , and then amigaboot from it. But you should be sure : I wasn't sure what you meant there, disconnecting from sata port but not motherboard, then I realised what you meant after I did it the easy way and pulled it from the drive. So I just disconnected my main drive. Checking the GAP guide my test stick had a few differences. The one formatted as FFS. - I used "USB:" as device name, - I renamed stick as "AmigaOS 4.1 Final Recovery" to avoid name clashes. - I don't have any RX drivers and didn't modify "startprefs.bat". - I didn't replace EHCI driver and am using Update 3 as base. - I had used my clean Update 3 volume as source and not CD image. So had a first go. After pulling my drive out I found out I had removed the floor from under my feet as your USB patch was on the HDD only.  Formatted and copied patch to another stick. Applied USB patch then swapped sticks. Booted amigaboot.of and it gave an error about no devices found. Perhaps some temporary glitch. Rebooted and tried again. Apply patch. Booted amigaboot.of and this time it found USB. Attempted boot from USB. Kickstart loads. Slowly from USB. AmigaDOS loads. Workbench boots! So it can work. What I wonder is what was stopping it with HDD connected. I did notice in some other tests errors with USB devices reported on serial in boot log. So something was causing conflict with USB. I also purposely booted from USB1.1 hub in order to avoid EHCI bugs.
|
|
|
|
|
|
Re: X1000 CFE Patches: Testers Welcome (Fear not: real-time, no reflashing) v.02 NEW!
|
|
Not too shy to talk
|
@kas1e So I successfully managed to load amigaboot.of and Kickstart off USB but the Workbench wouldn't boot. The USB stick was plugged into my keyboard hub so is at USB1.1 speed or full speed as its called. The end result was OS4 logo stuck on screen. I check the startup menu and all but the USB drive was listed. So the first problem is the USB drive not showing up. That's pretty much a showstopper regardless. Another problem is that nothing is booting. I can keep rebooting to see DOS boot drives so system is technically working but when letting it boot it cannot boot at all. Somehow, even though the volumes are there, it is not even booting from the first boot drive. There's not much clue as to why. The following is last seen on serial.
[_impl_AddTask] Task added to ready list
[_impl_RemTask] Removing 0x5E6F2B50 (self) = windowfade.task
[_impl_RemTask] Freeing tracked resources
[_impl_RemTask] Done freeing resources
[_impl_RemTask] Removing 0x619285A0 (self) = dopus_clock
[_impl_RemTask] Freeing tracked resources
[_impl_RemTask] Done freeing resources
[_impl_RemTask] Removing 0x619280C0 = dopus_hotkeez
[_impl_RemTask] Freeing tracked resources
[_impl_RemTask] Done freeing resources
[_impl_RemTask] Removing 0x5E6B3C90 (self) = dopus_arbiter
[_impl_RemTask] Freeing tracked resources
[_impl_RemTask] Done freeing resources
[_impl_RemTask] Removing 0x5ED4E070 (self) = CON/con-handler 53.82
[_impl_RemTask] Freeing tracked resources
[_impl_RemTask] Done freeing resources
[_impl_RemTask] Removing 0x5ED4E1F0 (self) = DirectoryOpus
[_impl_RemTask] Freeing tracked resources
[_impl_RemTask] Done freeing resources
|
|
|
|
|
|
Re: X1000 CFE Patches: Testers Welcome (Fear not: real-time, no reflashing) v.02 NEW!
|
|
Not too shy to talk
|
@TSK I haven't tested the SATA patch extensively yet. Since I've been testing USB more. But one thing that would affect it is the SATA patch adds all devices as boot sources. So when amigaboot.of scans for devices it will pick up any extra drives. Which were hidden before. So if you have another HDD connected to SATA, in addition to your boot drive, it will be picked up and any volumes added to the boot list. I found this when a recent SSD I added was picked up and a normally hidden OS4 volume added to the boot list. It messed up the order!
|
|
|
|
|
|
Re: X1000 CFE Patches: Testers Welcome (Fear not: real-time, no reflashing) v.02 NEW!
|
|
Not too shy to talk
|
@balaton Looks like this serial is more complicated than it used to be. I wonder how common these 16550 devices are? I mean, for example with a Mac, would it also have the same memory map as the "PC" serial at 0x03f8 and 0x02f8? PCI would complicate this slightly so I should look that up. I'm just thinking about where the hardware sits in the memory map. Anyway I hadn't listed any new logs as I was still testing in CFE and trying to figure why it is going wrong. It's just that the kickstart.zip is data like any other file so CFE should be able to load it in like a ramdisk normally regardless. I have used that command so many times so I don't know why it suddenly doesn't work without specifying a size. I've never needed to specify a size before so don't know why it demands it now. A kickstart,zip should be no different to a ramdisk-6.12 since both are just a file of data. As a test I gzipped the kickstart.zip but it still broke, even though my working ramdisks are gzipped. So now my CFE cannot load raw or gzipped ramdisks. It doesn't make sense to me. Is it looking at the filename and corrupting on purpose unless it has ramdisk or initrd in the file name?!? So I got it work. I used a Kickstart from the install CD since that is what I had written to USB. I just zipped up the Kickstart from root and System as is and it worked fine. However it still could not boot off USB. But that is beyond the control of your booter. My USB stick was not listed as a DOS device. But also it didn't try to boot anything else which is strange. Just stood there with OS4 boot logo. On serial I found it had crashed. So a few things wrong with booting from USB. It has no working screen mode for some reason. And something wrong with setting up USB. Looks like its trying to use my WB mode when the BootVGA mode should be used or fallback. This looks like it's causing another bug so should probably report this. As an alert should be displayed regardless. Given the early menu can display thus is odd.
[RAM] Handler has started successfully. [DebugLevel=5]
Mode 1600x1200x 8@60 75.0khz out of range
Valid ranges are vsync 59 - 71hz, hsync 30900 - 70100hz
Mode 1600x1200x16@60 75.0khz out of range
Valid ranges are vsync 59 - 71hz, hsync 30900 - 70100hz
Mode 1600x1200x24@60 75.0khz out of range
Valid ranges are vsync 59 - 71hz, hsync 30900 - 70100hz
*** DisplayAlert: $00088035
Bad arguments to USB function call!!
*** DisplayAlert: $00088035
Bad arguments to USB function call!!
Here ramdisk refuses to work ever:
CFE> dx
Directory
Kickstart.zip 4456853 rwedrwed----rwed
...
CFE> ramdisk -fs=amigafs -max=4456853 ide0.1,dh12:Kickstart.zip
Loader:raw Filesys:amigafs Dev:ide0.1,dh12 File:ramdisk Options:ide0.1,dh12:Kickstart.zip
Loading: ..... 4456853 bytes read
Entry at 0x0000000024000000
*** command status = 0
CFE> boot -noints -fs=amigafs usbdisk0:bboot
Loader:elf Filesys:amigafs Dev:usbdisk0 File:bboot Options:(null)
Loading: 0x0000000000200000/27352 0x0000000000206AD8/1400 Entry at 0x00000000002042F8
Starting program at 0x00000000002042F8
[RUN!]
OF interface initialized
BBoot 0.9 (unreleased)
Checking initrd at 0x24000000-0x24440195 (4456853 bytes)
Invalid zip file
[EXCP]*** program exit status = 0
So dx lists my Linux boot volume where I stored the zip at dh12. The ramdisk command always breaks. From both HDD and USB.
[CFE ]CFE> load -raw -fs=amigafs -max=4456853 -addr=0x24000000 ide0.1,dh12:Kickstart.zip
Loader:raw Filesys:amigafs Dev:ide0.1,dh12 File:Kickstart.zip Options:(null)
Loading: ..... 4456853 bytes read
Entry at 0x0000000024000000
*** command status = 0
CFE> boot -noints -fs=amigafs usbdisk0:bboot
Loader:elf Filesys:amigafs Dev:usbdisk0 File:bboot Options:(null)
Loading: 0x0000000000200000/27352 0x0000000000206AD8/1400 Entry at 0x00000000002042F8
Starting program at 0x00000000002042F8
[RUN!]
OF interface initialized
BBoot 0.9 (unreleased)
Checking initrd at 0x24000000-0x24440195 (4456853 bytes)
Found zip with 65 entries
Parsing Kicklayout at 0x24440195 (2560 bytes)
Booting config 1: AmigaOS4.1_X1000_Final_Edition
It only works load command. Somehow ramdisk only works with a Linux ramdisk. Beats me!
Edited by Hypex on 2026/4/24 8:05:33
|
|
|
|
|
|
Re: X1000 CFE Patches: Testers Welcome (Fear not: real-time, no reflashing) v.02 NEW!
|
|
Not too shy to talk
|
@balaton Thanks. Yes I had the alpha alpha. Updated and it runs. It gives me a message about invalid zip file so I'm finally getting somewhere! Regarding the direct serial access that would come down to semantics as I considered direct access to be hardware banging and so not portable in the generic sense. I suppose it's so common it would be considered portable and of course it's fine in a VM like QEMU. I found by simply having a serial terminal connected CFE echoes the output over serial. So I can still see it regardless. I don't know if it matters for the X1000 but I found some differences in assigned serial address:
CFE> show devices
Device Name Description
------------------- ---------------------------------------------------------
uart0 NS16550 UART at 0xFCFF03F8
pcconsole0 PC Console (USB/VESA)
[serial@1d]
| name str 'serial'
| device_type str 'serial'
| vendor-id val 0x00001959
| device-id val 0x0000A004
| revision-id val 0x00000002
| class-code val 0x00070003
| reg cell 0000E800 00000000 00000000 00000000 00000000 0
100E810 00000000 00000000 00000000 00000008
| assigned-addresses cell 8100E810 00000000 007F03F8 00000000 00000008
| interrupt-parent val 0x7FE2F6E8
| interrupts cell 00000049 00000001
| clock-frequency val 0x07F28155
| current-speed val 0x0001C200
| compatible str 'ns16550' 'pciclass,0700'
So the uart0 device is at 0xFCFF03F8 but the assigned address is at 007F03F8. I tested ramdisk command and bboot does pick it up in registers. However, as always with CFE there's a caveat: It still doesn't work! I've tested a few variations of ramdisk loading and all ramdisk commands loaded 37037056 bytes then stopped. By all accounts that should have worked as 37MB should have covered it. But the result is still corrupt. I need to find exact size as specifying over still broke. Be it loading off USB or HDD made no difference. I even tried to gzip but it did the same thing. I specified zip as gzip and it didn't even complain it was wrong format. I really don't know what is wrong with it. I have CFE variables I used for years that loaded in ramdisk and the command worked. I'm certain I tested loading in a Linux ramdisk from FFS. I still have an old variable doing it. The kernel can load from FFS. Obviously FFS driver has issues. But maybe it only works if data is gzipped. I give up half the time trying to understand what its problem is.
|
|
|
|
|
|
Re: Is your X1000 unstable, and sometimes hangs on bootup?
|
Posted on: 4/21 13:13
#14
|
Not too shy to talk
|
@Deniil
Funny, a number of years ago my X1/XE suddenly came down with a case of the black screen of death. Powered on but no sign on screen. On serial all I could see was a message about VGA then it stopped. Obviously suspecting my ATI card was at fault I check it over but it seemed fine. I then slowly pulled other things off like IDE cables and finally RAM. All the time checking serial. By the end I had it all stripped down and found out it could be stripped down to the bare minimum which was good as UBoot would still attempt boot and error out. After I removed the RAM and put it back it suddenly came back to life. Turned out the contacts had gone stale and simply disturbing the contact was enough to break it back into order. RAM was holding it back. I've only seen this on PPC machines.
Now, this is on the X1000. My X1000 has had various problems over the years. Here's a list:
* Failing to turn on or off.
* Stalling on boot logo after reset.
* CFE unable to detect HDD.
* CFE crashing during Kickstart load.
* Sudden SATA errors while system was in use.
* Sudden loss of SATA HDD after reset.
* Freeze on Workbench boot.
* USB EHCI driver broken and temporarily locking up system.
The power switch going faulty, failing to turn or off, was due to low battery. A bad power cable can also cause issues.
The stalling is an old CFE bug.
The inability to detect HDD, CFE crashing on Kickstart and other sudden SATA errors remain as unknowns. But, to stabilise this, I replaced my SATA cables and also installed SATA clips to secure them better over long periods. I also replaced my RAM which I bought new at the time. Should have bought spares. Since these proactive methods to stabilise system I haven't seen sudden SATA errors occur for a while.
The last two items. Unfortunately Update 2 brought me freezes on boot and Update 3 combined this with a broken EHCI driver. Apparently this only affects specific hardware configurations. I suspect a change in Exec or some other module has introduced a bug that has messed up interrupt signals or similar. That only shows up with particular hardware. I've confirmed in my case a screen mode change hangs on a vertical interrupt, which goes forever missing, and my Workbench hangs. Given it's interrupt related makes me wonder if the EHCI driver is also failing due to an interrupt issue.
Edited by Hypex on 2026/4/22 5:12:17
|
|
|
|
|
|
Re: [FS] The A1-X1000 used in RadeonHD/RX driver development
|
|
Not too shy to talk
|
Be good to find a developer to sell it too. So they can find those interrupting bugs causing Workbench freezes and breaking USB2 on Update 3. Then I could relax.  I'm sure you will find interest in New Zealand or Australia. From time to time the X1000 comes up in discussion at Amiga groups. The general consensus is the X1000 is unobtainium and the X5000 is too expensive.
|
|
|
|
|
|
Re: X1000 CFE Patches: Testers Welcome (Fear not: real-time, no reflashing) v.02 NEW!
|
Posted on: 4/20 14:49
#16
|
Not too shy to talk
|
@kas1e Quote: You mean with my patch booting work now for you ? (yes/no please) No. Quote: Did it work till full workbench load, or hang after modules load ? (please answer short). No, it hung after modules load. Quote: If you mean amigaboot, then try this version of amigaboot where they add it. Yes I do mean that. This would because of the ISO I used. The newest I can find is the 53.27 once. So I would need AmiDVD to make a newer one but had kept it simple. In this case it was simply copying an installer CD image to USB. Fastest way to create recovery key. Quote: And don't do load/go , do "boot". That for clear test case. I usually do use boot. I may have used load by accident that time. Quote: I do not understand still sorry : its all chaotic unstructured report with lots of phrases on differnt matters :(( Can you make it all VERY short by simple points ? Yes, fair enough. Quote: All i undertand now, is that you have 2 usb sticks: one ISO and one FFS7. ISO one, is booting fine with my patch you say, but then, few phrases later, you show me log showing it didn't boot, what is right answer then ? Then you have second FFS based one, which boots, load kickstart files, but then nothing happens. While i understand what you mean about FFS one, i didn't get about ISO is it boot or not , what of your answers is correct one ? Okay. So yes I have two USB sticks. One is a straight image copy of OS4 installer CD image. This is limited by that. Since it is the last released X1000 CD image I could find but it is from 2014. The other stick is a FFS7 formatted stick. I recently erased this and made a new OS4 copy from my HDD recovery partition. So now my FFS USB is at 4.1 FE Update 3 standard. In addition, because this is writable, I also copied over bboot and created a Kickstart.zip for that so I could also test bboot. So to clarify further. Your USB patch is preloaded for test boots from ISO stick and FFS stick. The only exception is when doing separate tests with bboot, since it doesn't require your patch. From ISO USB stick amigaboot.of is booted and doesn't know file system on disk. It's obviously because amigaboot.of is too old so no further tests needed. Loading a newer amigaboot.of from HDD is another option. From USB FFS stick amigaboot.of is booted. It is able to locate USB as first entry in boot list. I chose this and it loads modules. I see a message about having loaded modules and then it just hangs. Quote: I am 99% now sure you mess with FFS stick, just really sure. You copy wrong data, or something of that sort. Or you forget something, and will find it after a days or weeks :) Before you have crash you say not just hang doing nothing, now crash somehow gone. Before it wasn't booting from ISO, few big posts about, and then it can now, but then again can't with log that it can't. Previously I had tested with FFS7 formatted USB and a 4.1 Update 5 WB. Booting from amigaboot.of V53.21 off same USB. This configuration crashed. Because of WB age which predates FE and newer amigaboot.of I decided to erase and copy a more up to date WB. I also realised the files I had copied, which were just for bboot, were copied to HDD instead because I copied them to the source HDD volume and not USB destination volume. I also need to note where I load from since I have a USB1.1 hub and USB2 port on case.
|
|
|
|
|
|
Re: x1000 hw programmer and CFE bugs
|
Posted on: 4/20 11:53
#17
|
Not too shy to talk
|
@balaton Quote: These are what Open Firmware calls client interface. Then CFE is like VOF in QEMU that only emulates this and provides enough of the Open Firmware enviromnent that simple boot loaders need. Except that CFE also supports reading blocks from disks which isn't implemented in QEMU's VOF. Suppose block support would be considered a lower level access. This would be needed because amigaboot.of needs to scans drive for partitions and determining filesystem. I don't recall the history but I wonder if the OF interface in CFE is present because they could take the Pegasos OF loader and easily port it to the X1000. Now days SLB is mostly dropped. Amigaboot is coded in OF and UB variants so they do share the same code base.
|
|
|
|
|
|
Re: X1000 CFE Patches: Testers Welcome (Fear not: real-time, no reflashing) v.02 NEW!
|
Posted on: 4/20 11:38
#18
|
Not too shy to talk
|
@balaton Quote: No BBoot likely could not find it because zip was loaded at wrong address. That's what I mean. If the zip data wasn't there it should have failed instantly. If it was there partially it should have failed a CRC check. It would obviously first check for a "PK" and if it wasn't there simply abort. But I didn't see this happen. It crashed soon after loading, so I wonder if something else went wrong. I used the 0.9 alpha posted here so should have the correct version. Quote: According to the above output ramdisk command may load at the default 0x24000000 address not at the -addr you specified. According to previous posts load command is also broken in other ways that it honors -addr but without also specifing -max with the exact size of the zip to the byte it either loads 0 bytes or tries to load too many and crashes. The commands @kas1e gave before (adjusting the -max number to be your zip size) should work but you did something else. There must be some issue with USB and FFS. I've loaded Linux kernel and ramdisk off a FAT USB stick for years and never seen these issues. Of course, apart from being FAT disk, that was an ELF and a ramdisk at expected location so not exactly the same. This issue could occur on FAT but I never tested using the same conditions with a generic or zip file at another address. However, according to the code, it checks r3 and r4 after entry for a ramdisk and falls back to 0x600000. I did a test and ramdisk command does populate these registers. So the simple solution should be to use ramdisk command in CFE and bboot should pick it right up. I did do something else when loading it because I've never needed to specify a rigid size when loading initrd data in. Quote: Also BBoot does print debug and errors but serial on X1000 is not yet supported so these are printed in the CFE console (provided you used the 0.9-alpha version from earlier post) so look for it there but you did not post that part of the output so I don't know what it said. Older BBoot versions won't work or could tell you that on X1000 as there's no support for that machine in those versions. (Older BBoot version could still tell you machine is not supported if you 'setenv bboot "Of V5 Ab"' that disables serial output but all it would tell you is unknown machine.) I've been investigating the CFE boot console. So it can be pcconsole0 or uart0. I'm wondering if stdout handle can be changed to switch console. There is a bootconsole variable I tried changing to uart0 bit saw no difference. So possibly it just grabs that string from stdout or bootconsole and stdout handle needs changing to parent handle or something. Given all devices are named in tree it would be good if it could be redirected in a clean way without hardware banging. Which helps to keep code clean and portable. My output is on the serial and CFE echos console to serial automatically which is useful. Last night I switched to serial console and ran it. It didn't get far, setting up prom and crashing soon after.
CFE> boot -fs=amigafs usbdisk0:bboot
Loader:elf Filesys:amigafs Dev:usbdisk0 File:bboot Options:(null)
Loading: 0x0000000000200000/27376 0x0000000000206AF0/1400 Entry at 0x0000000000204320
Starting program at 0x0000000000204320
[RUN!]
OF interface initialized
** Exception 0x0200: SRR0=0000000000202598 SRR1=1000000002103000 [MCheck ] cpu0
LR = 000000000020006C CTR = 00000000000061A8
XER = 0000000020000000 DSISR = 00008000
HID0 = 8000000000000000 HID1 = 000000005CE993B1
HID4 = 4400240000080180 HID5 = 0000006600000000
LPCR = 0000000000000000
r0 = 0000000000202328 r1 = 000000007FFFF8B0
r2 = 000000007FD20838 r3 = 00000000FCFF03F8
r4 = 000000000000000D r5 = 0000000000000004
r6 = 000000007FFFFA14 r7 = FFFFFFFFFFFFFF83
r8 = 0000000000000001 r9 = 00000000000061A9
r10 = 0000000000000000 r11 = FFFFFFFFFFFFFFFF
r12 = 0000000000000000 r13 = 0000000000000000
r14 = 0000000000000000 r15 = 0000000000000000
r16 = 0000000000000000 r17 = 0000000000000000
r18 = 0000000000000000 r19 = 0000000000000000
r20 = 0000000000000000 r21 = 0000000000000000
r22 = 0000000000000000 r23 = 0000000000000000
r24 = 0000000000000000 r25 = 0000000000000001
r26 = 0000000000000000 r27 = 0000000024000000
r28 = 0000000000206AFC r29 = 000000000020676C
r30 = 000000000020676D r31 = 0000000000000001
Edited by Hypex on 2026/4/20 14:05:10
|
|
|
|
|
|
Re: X1000 CFE Patches: Testers Welcome (Fear not: real-time, no reflashing) v.02 NEW!
|
Posted on: 4/20 10:17
#19
|
Not too shy to talk
|
@kas1e Quote: So, seeing the mess you have in system, we of course can't rely on your tests :( It can be anything, if you says so easy that you may lost files somewhere else , those are not very good tests then :) What mess? That's my organised boot menu. I'm a beta tester so I have a few more Amiga volumes than the average bear. The top was my main Workbench. Below that latest beta and public release. Then all my Linux volumes which are used for production or just testing. Next there is Workbench volumes for testing, stable and fresh. Stable is my solid production Workbench. Fresh is a clean install of all latest updates. The bottom one is my newest, which is actually my recovery partition, as it's a bootable installer CD on HDD. So, while it may be a big boot menu, they all serve a purpose. In any case, I'm not trying to boot volumes off HDD, which works fine. Disregarding the volumes hidden on my SSD. I'm trying to sort out booting from USB. Regarding the missing files it looks like a simple case of copying to the wrong volume since my USB drive had the same label as a Workbench on my HDD. It's since been reformatted with a newer Workbench to test. On that note, I've solved an issue I had. I got stuck on CFE being inconsistent. Booting amigaboot.of from an ISO imaged USB stick does work. It was the filesystem. I was specifying "isofs" because other CFE filesystem names have "fs" appended. But then I found out by accident it just calls it "iso" instead. I had forgot about this. Seems it had slipped my mind. That I was working with the Confused Firmware Environment.
CFE> dir -fs=iso usbdisk0:
Installation_Files
Installation_Support
Kickstart
Media
S
System
.backdrop 76
amigaboot.of 51420
AmigaOS 4.1 FileSystems 39773
AmigaOS 4_1 FileSystems.i11642
Disk.info 15732
Media.info 11420
System.info 15182
*** command status = 0
CFE> load -fs=iso usbdisk0:amigaboot.of
Loader:elf Filesys:iso Dev:usbdisk0 File:amigaboot.of Options:(null)
Loading: 0x0000000000200000/50812 0x000000000021C67C/76 Entry at 0x0000000000200034
*** command status = 0
CFE> go
Starting program at 0x0000000000200034
AmigaOS 4.x OpenFirmware Bootloader V1.0
Unknown file system on disk /pxp@0,e0000000/pci@11/pci@13/usbdisk0
So it does load as above. However look here and you see it can't understand ISO format on USB. This must be what was fixed up in that version where they added ISO9660 support to USB. That one above is from the AmigaOneX1000InstallCD-53.27 since it was the closest X1000 CD image I had to quickly write to USB. My other USB stick has FFS DOS7 and is a copy of my recovery volume. I couldn't get this to load. On my last test it loaded all the modules off USB then just hung, with no sign of Exec on serial. Left it for a minute then reset. I'll do some more tests on that.
|
|
|
|
|
|
Re: Odd A1222+ Issue
|
|
Not too shy to talk
|
@icbrkr That was a ridiculous amount of work. Of course this stems from the system being too old. It of course doesn't need to reboot since it's only a format away. But because they are still using the same method as an A500 from 35 years ago it wants to reboot. On top of making it so hard to even manage partitions and sizes you want. By now this should be automated in a more simpler way. It's still too technical. The USB should be set to priority 5 or 10 to match a floppy I'd say. 1 seems a bit low. The problem is that can be overridden. The Kickstart can or NVRAM variable can change the boot drive. And it can be changed in the early startup menu. So rather than fiddle with boot priorities bring up the menu to check can be easiest. And then to specify what to boot off and also check what it's trying to boot off. Looks like the installer key needs some more beta testing as the key gets stuck trying to unlock.
|
|
|
|
|
News feed
OS4 Feedback forum
OS4Depot Feedback forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
