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 ? Becaues for now, it looks like this:
- amigaboot.of = disk reader - loader.of = linker/loader
amigaboot check for block devices, and load loader.of, which, then, doing another things like claim memory for modules and co and load them from the memory areas to which amigaboot.of load them.
Why ? Why simple not doing that all in amigaboot : read from disk , load to the memory, once all done, we done, os4 boots, why complicate things with all this different binaries ?
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.
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.
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.
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). - 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).
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.
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.
On top of this, people used to talk about the magic code in UBoot that booted AmigaOS, as if it was secretly hidden.
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.
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
