Another problem is that BBOOT find USB bootable stick just fine and booted from it, so ITS NOT CFE, but amigaboot acts, right ?
BBoot does not know nor care about USB so it did not find anything. BBoot just looks for the Kickstart.zip in memory and does not know how it ended up there just extracts and start it. Since amigaboot is not involved in this scenario and BBoot does not know about USB it must be CFE.
Quote:
So solution is to known EXACTLY file size of your file and it then works. So:
Works ! Full boot from USB Stick ! And to see size you just first time do "dir -fs=amigafs usbdisk0:" , then add them to menu-entry, and forget about it..
That's silly. Then -max should really be called -size. Is there any way to script CFE so this could be automated that you don't have to adjust size every time you update the Kickstart.zip?
Quote:
Now question why amigaboot fail.. not that it much important right now as we have usb boot working , but still..
I have no idea but if CFE has bugs amigaboot may also be hit by that.
Given I would have typed in a full reply before locating a device tree, that would be correct.
Haha :)
@All Find out something interesting: if i attach CD to the port 0, and nothing else , so it atapi0.0 and no other devices on sata ports, and trying to boot from it, amigaboot say me that same:
No bootable devices found. Press any key to return to the firmware.
Should't it boot instead from CD, as this install CD kind of bootable media, no ?
But if i attach to port0 (ide0.0) _any_ hdd, and then to port2 CD (so it atapi0.1), then, and only then, amigaboot boots from CD !
WTF ? I mean, ide0.0 should have anything (empty, non amiga HDD at all, but just anything in), so then and only then amigaboot find a way to boot from CD !
Is't it's the same bug because of which we can't boot from USB too ? Or at least share same issue ?
Funny to think that only a few years ago I was still paying to send each SMS separately on my mobile and had honed a skill to compress full replies into those 160 characters.
Quote:
Finding all block devices in the tree should not take too long as the OF device tree is probably not that large. At least this way it should find all possible boot devices.
It doesn't take long in real time. It looked like a lot of effort. When it only finds two devices in the end.
Quote:
BBoot seems to work on X1000 as testing from kas1e shows so this proves you don't need an elf loader just load the modules and make the list describing them and start loader.of that will take care of relocating and starting the kernel. You need to pass the OF client interface pointer on to loader.of too. Unless you also want to replace loader.of too but I don't see why you'd want to.
I could see it eventually would. The ELF loader wouldn't be needed for OS4 and I wouldn't know what other logic is in the loader.of so wouldn't to try. The ub2lb project does have some insight but again would pass it all to a loader. It's really only needed when booting Linux which is not relevant to OS4.
One thing to note is that on X1000 the standard ramdisk location is 0x24000000. CFE should also place the ramdisk in r3 and r4 but I don't have any logs with that info. If OF can be expected to fill in r3-r5 as standard it would be good to use that over hard coded addresses. But 0x00600000 does work.
Another thing is serial. I've set the BOOT_CONSOLE variable to redirect stdio to serial but I don't recall if that worked and it's not standard. Serial can be found on tree, if it has write methods is another story. I'm not sure if there is an OF standard for serial console. I was surprised you would need to hit hardware, as OF is meant to abstract away all that.
This reply seems a but short. Hmmm...
@kas1e
Quote:
The issue with crashes when load up anything "big" from -fs=amigafs, because it seems have broken "seek" or something routine, which when file have "paging" can't cope with and die. I did fix it in my pathes by using ldscript which make it all flat, so seek didn't broks, but do not know what to do with kickstart.zip in this regard , so to not create (at least for now) another fix for CFE. I have some wild idea like, create another partiion on usb stick, this time fat16, on which kickstart.zip will be placed, and then in startup menu for "boot from usb stick", can be just loadup of kickstart from fat16 parition, and then boot from ffs.
I've used boot and ramdisk to load files off FFS but doesn't look like I tried load command. Shouldn't make any difference. Those were Gzipped though. Anything 12MB and below shouldn't have any issues. Of course amigaboot.of is loading in smaller Kickstart modules, but in my testing a Kicklayout with a 13MB file will break it.
Quote:
Now question why amigaboot fail.. not that it much important right now as we have usb boot working , but still..
My OFI log from previous post would share a clue about that.
My OFI log from previous post would share a clue about that.
So its amigaboot.of (!) walking through devtree for search "block" device ? Then, that correct way for loader ? I mean any bootable device should be "block" one ?
As we know amigaboot.UB works for booting from USB (x5000, sam4xx) but amigaboot.of for peg2/x1000 didn't , maybe it's just OF based code in amigaboot which is flacky ? I mean it just have basic "walking for block devices", and be done with it, no internal parsing, no any usb-based code in, just what SmartFirmware on peg2 and CFE on x1000 gives in devtree, then just those which "block" can be check for being boot or not.
I for sake of test also check how it looks like when i attach usb stick in devtree to see, and while for both atapi and ide it have:
[pci@13] — OHCI USB (0x4387) — NO children
[pci@13,1] — OHCI USB (0x4388) — NO children
[pci@13,2] — OHCI USB (0x4389) — NO children
[pci@13,3] — OHCI USB (0x438A) — NO children
[pci@13,4] — OHCI USB (0x438B) — NO children
[pci@13,5] — EHCI USB (0x4386) — NO children
So the fix, is probably to patch CFE to inject OF device tree nodes for USB devices..
PS. And what i found, is that with CD-Drive, on the same configuration, i sometime can have "boot device" and it boot from CD, but sometime amigaboot.of says "no bootable device found", exactly on the same config 1:1 without single difference. Like, some probing isssues, or when CD detected CFE didn't wait for it to be "ready" or something of those timing sorts..
PS. And what i found, is that with CD-Drive, on the same configuration, i sometime can have "boot device" and it boot from CD, but sometime amigaboot.of says "no bootable device found", exactly on the same config 1:1 without single difference. Like, some probing isssues, or when CD detected CFE didn't wait for it to be "ready" or something of those timing sorts..
The ATA(PI) standard has a ridiculous high timeout of 30 seconds, for example if you try to access a CD but there is none in the drive it might take up to 30 seconds until you get the "no disk in drive" error. Nearly every ATA(PI) driver reduces it to smaller values, for example the A1 U-Boot to the value stored in the a1ide_timeout ENV variable, or 20 seconds if not set. Maybe in CFE it's reduced too much, like 3 or 5 seconds only, which can be too few for some CD/DVD/BD drives to detect if there is a CD in the drive or not after startup or after a reboot and you get the "no bootable device found" even if a bootable CD is in the drive. Check if there is a similar timeout ENV variable in CFE.
@joerg Will check for envs, but, is it mean timeout once i tried to access cd , or it mean timeout after i power on machine ?
For example, i can do "dir -fs=amigafs atapi0.0:" with no problems, it shows right away all fine, but when i do "boot -fs=amigafs atapi0.0:amigaboot.of" it starts, but then "no bootable device found". But i can't find for now a 100% reproducible pattern when it 100% works and when not : on the same exactly config , sometimes found, sometimes didn't.
No idea about the Peg2, but U-Boot on the A1 (SE/XE/µA1) is executed with all...
I have a request and a question for you. You probably won’t reply, but it’s worth a try (one last time). As you’ve noticed yourself, QEMU emulation sometimes has trouble getting various A1 hardware components to work properly. Even some of the code in QEMU isn’t finished yet because we don’t have access to the full documentation for this machine. QEMU isn’t the enemy of real hardware. You could say it serves more as a way to archive machines. To show how they worked, with care taken to ensure it’s accurate to the original.
I really want the A1 to work properly in QEMU. I don’t want to get involved in any legal disputes between you and Hyperion. I also asked someone at Hyperion who might have access to the U-Boot sources. The topic was more about QEMU passthrough. After asking about U-Boot for the A1, the correspondence ended. The whole U-Boot on A1 thing is really strange. This machine deserves to run under QEMU just as much as PEG2. It’s better suited to running under AOS4.
@All Going through CFE.pdf (original documentation of Broadcom's one), and find out that there wasn't implemented "devtree" at all, they even says that :
Quote:
The device manager maintains a simple list of device drivers that can be used by CFE as consoles, bootstrap devices, NVRAM storage, etc. For simplicity, CFE does not implement a “device tree” or other complex data structure to describe the devices it manages. It is expected that most implementations of CFE will include device support only for those devices needed for system bootstrap. The operating system’s probe routines will be responsible for discovering all the devices that are present.
So "devtree" thing is Pasemi/Hyperion addon, because they do not want to implement in amigaboot "The operating system’s probe routines will be responsible for discovering all the devices that are present." :)
It also, seems to be constructed one time on the boot, i.e. not "fully dynamic". At least, when i attach USB stick, and have from CFE words like "found stick blablab", in devtree there nothing new appears to b e visibly. What mean that "devtree" thing there can be some dunno, "debug-amiga-specific-so-to-work-with-amigaboot" ?
But then, if i understand it correctly and this one static, the "options" at top of devtree is surely dinamic, i.e. :
So we can update it in realtime, and it should have inside internal functions to update devtree in realtime. Sure, maybe not about pci-enumeration/device update, but still some base way are here to which we can hook into.
How else can we check if devtree updated by anything else and not only by options ? USB didn't update dev tree. And i can't hot plug HDD/CD on sata port.. So , what else to try ?
@kas1e I doubt that was Hyperion that hacked an OpenFirmware implementation on top of CFE because they had U-Boot on other machines so they had to change amigaboot and kernel to work with OpenFirmware (then after that was done for X1000 they could also support Pegasos2 as that hardware is similar to AmigaOne but with OF). Instead it was likely PAsemi who did that because they wanted to make a PPC chip that can boot MacOS which needs OpenFirmware but they had CFE so probably added an OF compatibility on top. This is just a guess but sounds plausible. That the /options node lists env vars does not mean you can change the devtree. It's easy to implement /options to provide the env vars on access but that does not mean CFE has other device tree manipulation implemented. But if it supports interpret from the client interface (as amigaboot.of uses that) then you could try sending commands over that that create a device tree node or set properties and see if that works. It could be CFE does not have a full Forth interpreter and it just emulates the interpret calls the boot loaders use (as I've done once in VOF for interpret mem-alloc to make amigaboot.of go further but then it sent more interpret commands to read the disks which would have been harder to emulate). At this point it may be easier to replace amigaboot.of with something or look at porting some other firmware to X1000 if you can recover the initial hardware init from CFE.bin and reimplement that in real OpenFirmware as in: AIX/PReP under QEMU How-To (source) but this needs Forth which might be a barrier to most but if you want a challenge it definitely is; or SmartFirmware which then you could also use to do the same on PegasosII and free the firmware of that machine as well. So instead of patching CFE you could try to get the hardware init that sets up memory controller and PCI buses and devices and hack that in SmartFirmware and see if you can get a working OF that way then AmigaOS and its bootloader might not need changes and still work. This looks more likely than porting U-Boot which would need a different kernel or emulating OF on top of U-Boot. But if somebody still has the CFE sources that would be the most helpful. PAsemi was bought by Apple and they have no use for this firmware so if you can find a contact maybe you can ask if they still have it somewhere. Not likely they answer but maybe they do and then you at least have the hardware init to make a new firmware. Was the PAsemi CFE open source? How did AEon/Hyperion got it to modify it? Looks like it was part of the SDK described here. Does somebody still have a copy of that SDK? Even if the whole SDK is not free the CFE sources might be so could be distributed.
@Balaton My plan later to port UBoot to x1000 instead of CFE, and maybe someday to pegasos2 if i will still alive after all that :) In another topic i even post an image where i already have create uboot binary, and running it inside of the CFE , re-init the basic (uart0) and give all other control to CFE, with the plan one by one take control by UBoot, and later reflash with uboot instead, etc. But that surely for very later..
@kas1e Problem with U-Boot is that X1000 and PegasosII versions of AmigaOS expect OpenFirmware, they use rtas to access PCI and other things that you'd either need to emulate on U-Boot in a boot loader replacing amigaboot.of or need a new kernel that works with U-Boot. Porting SmartFirmware would give the OF environment so no change needed in the OS. (Also other OSes expect OF on these machines so they won't boot on your U-Boot but could on an OF implementation.) The AmigaOS specific U-Boot hacks are also a mess that need to be ported to recent U-Boot versions so maybe the OF is better at least using some official API of the firmware not AmigaOS specific patches not in upstream. The porting is about the same work for any firmware as you'd need platform specific init and drivers so no difference in that.
@balaton Ah damn ! I forget the OS ! But was in hope we can simple use amigaboot.ub for them (just like on x5000 and sams).. But if not , then of course, no one will change kernel/os for that..
Do you perhaps have the U-Boot sources for the A1 (SE/XE/μA1) and can you share them?
No, I never had the U-Boot sources, except for the, apparently incomplete, publicly available parts like on https://git.codelinaro.org/clo/qsdk/os ... /board/MAI?ref_type=heads for example Looks like the original DENX U-Boot repository, on which the MAI Teron/EyeTech AmigaOne U-Boot parts were as well, and even the complete company DENX, no longer exists: https://www.denx.de/
The only U-Boot related part I was involved in is the "SLB_v2" 2nd level boot loader (SFS and ISO9660 file system implementations of it), but all I got for it, which was enough for implementing my parts, were some U-Boot includes related to it, for example with callback hooks for reading sectors from the current boot device, and an example SLB_v2 source for another file system implementation, probably the FFS one.
Quote:
I really want the A1 to work properly in QEMU.
The A1 emulation is the best target of the 3 AmigaNG PPC systems supported by QEmu, at least as long Hyperion intentionally only releases broken Peg2 kernels like in "FE Update 3", instead of the already existing bug fixed versions, which only seem to be available to OS4 developers and beta testers. Another big problem is that there are no copies of the AmigaOne version of AmigaOS 4.1 left in any Amiga shop any more, only the worse Peg2 version might still be available. Maybe the Sam460 version is still available as well somewhere, but it's emulation is much slower than the A1 and Peg2 one.
Looks like the original DENX U-Boot repository, on which the MAI Teron/EyeTech AmigaOne U-Boot parts were as well, and even the complete company DENX, no longer exists: https://www.denx.de/
That's strange. Who maintains U-Boot now? I once asked about it and was told that the sources for AmigaOne XE U-Boot used to be in some Hyperion CVS that's no longer up for a long time and it wasn't migrated to what they have now so maybe it's only in some archives that nobody seems to know where it is. It was probably never fully upstreamed to U-Boot, the parts that were there are for an older G3 based SE board anyway. I've tried and could compile that but it does not work for XE and missing a lot of parts anyway. I think the Sam U-Boot versions were made based on this so @m3x might have it but when I asked here he did not reply.
Quote:
Quote:
I really want the A1 to work properly in QEMU.
What's not working? The A1 U-Boot binary is still available from Hyperion and it works with QEMU so you can use that if you want it just does not come with QEMU because that would need to include sources as well. (Maybe the sam460ex version will be kicked from QEMU at one point too as that also does not compile with modern compilers so it's a pain for package maintianers who want to rebuild everyting from source.)
Quote:
The A1 emulation is the best target of the 3 AmigaNG PPC systems supported by QEmu, at least as long Hyperion intentionally only releases broken Peg2 kernels like in "FE Update 3", instead of the already existing bug fixed versions, which only seem to be available to OS4 developers and beta testers.
If I understood correctly the reason for that was that they wanted to stay on the same kernel version for all plarforms and they could not update X5000 beyond one point due to some unfixed issue in more recent versions so they could only advance until that which also happens to be before the PCI fixes for pegasos2 but it wasn't intentional but more due to being unable to fix something else that held things back. Maybe they can resolve that and release it in some future update. Quote:
Another big problem is that there are no copies of the AmigaOne version of AmigaOS 4.1 left in any Amiga shop any more,
Wasn't it that the recent agreement about not continuing to sue each other allows Hyperion to make elecronical versions for download possible? Then this could be resolved too.
So its amigaboot.of (!) walking through devtree for search "block" device ? Then, that correct way for loader ? I mean any bootable device should be "block" one ?
Yes, it looks for block devices. So this would discover devices on assigned SATA ports. Then it would scan for a filesystem and look for layout. Any bootable device should show up. But, given one is usually CD and other HDD, means it either finds CD or HDD. It looks like it is checking each block device until it finds one loaded.
Quote:
As we know amigaboot.UB works for booting from USB (x5000, sam4xx) but amigaboot.of for peg2/x1000 didn't , maybe it's just OF based code in amigaboot which is flacky ? I mean it just have basic "walking for block devices", and be done with it, no internal parsing, no any usb-based code in, just what SmartFirmware on peg2 and CFE on x1000 gives in devtree, then just those which "block" can be check for being boot or not.
I'm not sure but it's possible amigaboot.ub works for in same way an A1 can boot off USB and even autoboot. USB just needs to be a boot source for UBoot that it reads and can boot from. Then the boot loader code just needs to get current device handle and start reading. As I've mentioned previously UBoot code doesn't even need to check for USB. I've written a UBoot chain loader for booting ISO9660 boot block off USB. It just reads blocks off the boot device and looks for the real boot code.
OF and UB methods are like opposites: amigaboot.of: Scans for each boot device manually and opens. amigaboot.ub: Given boot device handle and starts reading.
As a contrast a PPC Mac can boot off USB but I've read it can be difficult and needs a few commands entered in if it works. But that is pure OF. So would have more features.
Quote:
So the fix, is probably to patch CFE to inject OF device tree nodes for USB devices..
One problem would be that SATA has exact addresses mapped out for each port and what not. But for USB, it's not static, but dynamic and controlled by the root hub. So in this case I expect it would need the analogue to ide0.x in the form of usbdisk0 or usbdisk1.
Quote:
PS. And what i found, is that with CD-Drive, on the same configuration, i sometime can have "boot device" and it boot from CD, but sometime amigaboot.of says "no bootable device found", exactly on the same config 1:1 without single difference. Like, some probing isssues, or when CD detected CFE didn't wait for it to be "ready" or something of those timing sorts..
I thought CFE might set a boot device variable but can't see one. Only for bootconsole. Sometimes I do see the DRQ message when booting CD. It has that quirky setup with needing to specify atapi device. So must have specific device commands it uses for CD. Yeah it can present glitches at random times it seems.
It looks like it is checking each block device until it finds one loaded.
Yes, it looks for all block devices : i already made USB boot working by adding to relevant pci@13 a node with "block" and correct methods and amigaboot finds it fine (together with HDD and CD), see (UDH2n that usb stick + CD + DH0):
Quote:
One problem would be that SATA has exact addresses mapped out for each port and what not. But for USB, it's not static, but dynamic and controlled by the root hub.
I didn't use static addresses already : because i even with sata have issues when user have added one or more PCI card at top, or have 2 gfx cards at the same time, and addresses shifts.
For sata i scan heap on known range for a pci@12\0 string + some checks. The same i do now for USB, i simple scan for "pci@13\0", and then scans for usbmass_driver struct for "Mass-Storage Device" string.
For clarity: the AmigaOne XE version of AmigaOS 4.1 is still available as a physical release.
The Pegasos II and Sam460 versions are no longer available in physical form. Availability in shops depends on whether dealers choose to stock remaining items.
@Joerg Want to create SFS2 reading-loading supportIs in CFE, and can you plz say if SFS sources on os4depot is SFS0/1 ones, but the one OS4's SFS2 is the same just large file support added with a bit changed structure ?
@balaton Is smartfirmware still developed or have some recent github repo for ? Or the one original one 20 years old , and more or less latest one is this https://www.openfirmware.info/ ?
Edited by kas1e on 2026/4/14 5:13:09 Edited by kas1e on 2026/4/14 12:20:05
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
