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.
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 :)
My wild guess is that you simple overmess everything with your 15 boot partitions, boot priorities and so on.
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 :
1). all drivers disconnected 2). stick correctly done like this : https://g-a-p.me/inside/x5kbootstick.html 3). you not forget to set boot flag on it in mediatoolbox.
@TSK With patch just more devices found , and if any of them have boot flag set, amigaboot will find them (that not about patch, but about amigaboot scanning all available devices in devtree and add them to the list). So patch just enable all devices you have connected.
@TearsOfMe Quote:
When I enter the line "setenv bootargs "root=/dev/sdb1" the saved environment is still used. I must use setenv -p .. and a reset to change the bootargs.
Now sure i understand, but as Sailor said it works that way : when -p it then saved permanently , when without, just used for current session. Or issue is that when you use it without -p even for localy session doing "printenv" it didn't changes ?
@Sailor How it going ? Weren't you able to test something else, like new cmds with pager / editenv , sfs2, etc ?
kas1e wrote:@Sailor How it going ? Weren't you able to test something else, like new cmds with pager / editenv , sfs2, etc ?
SFS2 works fine I booted from USB / SFS2 with no problems. editenv is nice feature, but if there are spaces in env, is needed to close between ´´ manually. Thanks, it is very nice work you did on old X1000!
Now I am not testing neither Amiga, neither Mirari, neither linux kernels. We are moved to garage, because we are repairing floors in the house. So all my computers are packed in basement, and stays there one or two weeks more
AmigaOS3: Amiga 1200 AmigaOS4: Micro A1-C, AmigaOne XE, Pegasos II, Sam440ep, Sam440ep-flex, AmigaOne X1000 MorphOS: Efika 5200b, Pegasos I, Pegasos II, Powerbook, Mac Mini, iMac, Powermac Quad
With patch just more devices found , and if any of them have boot flag set, amigaboot will find them (that not about patch, but about amigaboot scanning all available devices in devtree and add them to the list). So patch just enable all devices you have connected.
It lists partitions without boot flags definitely.
Either somebody must update amigaboot.of to not list everything in the device tree but check the boot flag by itself. Or your code should not add any partitions to the device tree without the boot flag.
Why would you need any partitions to be listed which you can't boot. You don't have any Amiga DOS commands in CFE so you can't access any files anyway. Any reason to do anything in CFE is to boot the machine.
Rock lobster bit me - so I'm here forever X1000 + AmigaOS 4.1 FE "Anyone can build a fast CPU. The trick is to build a fast system." - Seymour Cray
It lists partitions without boot flags definitely.
There can be bugs on my side with patches of course, but there we need to be double sure that this is the case. What are the names in the amigaboot list of those partitions which shouldn't be bootable ? It can't be that you have some test partitions (old ones and forgotten) ? Can you check to be double sure in media toolbox ? What the names of those partitions in the amigaboot list which shouldn't be there as you think ?
Quote:
Either somebody must update amigaboot.of to not list everything in the device tree but check the boot flag by itself. Or your code should not add any partitions to the device tree without the boot flag.
No one will update amigaboot.of , and even if anyone will, forget about "soon to be released", so that out of question.
My patchs code didn't add any paritions at all, my code didn't know about partitions. All my code do in regards to allow booting, is add missing before devices to the CFE three, nothing else. So if you have in your amigaboot.of list some paritions which you think should't be there, then:
1). double sure you didn't have connected any HDD/SSD/CD/USB which may have those boot partitions and about which you simple forget.
2). check the name of partition in amigaboot list and device name, and check (again, yeah) in mediatoolbox what bootable flag is have.
Quote:
Why would you need any partitions to be listed which you can't boot.
It should't. Either you have bootable flag on them and forget about (like, some old HDD connected and you just forgot that it have it), or something of that sort. Amigaboot actually itself check if your device have boot flag or not as i aware, so chances that you need to recheck bootable flag and open up a x1000 case to see what is connected to sata ports are high.
Quote:
You don't have any Amiga DOS commands in CFE so you can't access any files anyway.
Are you for real ? YOU CAN access any files via CFE. You can list them, you can even load them to memory and read them, you can do a lot of things from CFE, because CFE is small OS. You just didn't know about seems so.
Quote:
Any reason to do anything in CFE is to boot the machine.
Probably for you, others ones want to work with it in all the ways before hi-level kind of OS starts.
So, plz check if you have connected another HDDs to other ports on your x1000 which you simple forget, and as they wasn't ever detected by CFE before patch , amigaboot.of didn't see them, but see now. Check the name of those partitions and devices name , and check via mediatool box about.
I have 3 HDD's. For example DH19 does not have boot flag set but is listed in the menu (which lists AmigaOS partitions to boot Workbench from).
I know these are unofficial patches so asking help from Hyperion or A-Eon they might say no because of that. But our community should learn to work together.
Rock lobster bit me - so I'm here forever X1000 + AmigaOS 4.1 FE "Anyone can build a fast CPU. The trick is to build a fast system." - Seymour Cray
For example DH19 does not have boot flag set but is listed in the menu (which lists AmigaOS partitions to boot Workbench from).
Probably it have something else which amigaboot.of find as parition to be boot from. What happens when you press on it ? Is it boots ? Nothing happens ? How it named in am8gaboot menu, just an dh19 ? Be sure you recheck on nootable flag and check maybe it have system directory in root or kickstart one or kivklsyout file left
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.
@Hypex 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 disassemble amigaboot.of, and that how it works:
1). walk OF device tree, find all block devices
2). for each block device: try_boot_device() which:
-- scan_partitions (RDB): find Amiga partitions -- for each partition: check FFS/SFS/ISO9660 for Kickstart/Kicklayout -- if found: calling add_boot_source() to add to boot source list
3). main_boot: clear screen, print banner, show menu and when entry taken parse_kicklayout from this partition: parse MODULE/EXEC/LABEL labels, etc and giving control to first one in list which usually loader.of.
That all.
So, if you connect any device which have RDB and on this RDB based device have FFS/SFS/ISO (amigaboot support only those in it's default public version for peg2), and by luck it have directory called Kickstart with Kicklayout file : then there you go, it will be added to the list. Probably even boot flag doesn't matter for amigaboot.of (it matter later for OS itself).
@TSK So my wild guess, one of your HDDs which now detected by CFE and which isn't marked as boot device, still have Kickstart directory with Kicklayout file in the root of volume. I am almost sure now that this is the case. Can you confirm ?
Yes, all partitions listed are backups or testing of the OS so they all have Kickstart files and the Kicklayout file. I tried to remove the BootDevice file from some of them but that didn't change anything.
The thing that puzzles me is why the behaviour was different before. What you say about how amigaboot.of works, everything should have been working the same way always.
Rock lobster bit me - so I'm here forever X1000 + AmigaOS 4.1 FE "Anyone can build a fast CPU. The trick is to build a fast system." - Seymour Cray
What you say about how amigaboot.of works, everything should have been working the same way always.
And it was, just without patch your other HDDs wasn't recognized by CFE.
Quote:
I tried to remove the BootDevice file
Not BootDevice file, but Kickstart/Kicklayout from parition which you do not want to be listed in amigaboot from those HDDs which now recognized in CFE.
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.
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.
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.
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 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.) 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+ 🤷
Maybe amigaboot does not check bootable flag because that's for something else. A bootable partition is what can be SYS: but the Kickstart files can live on a separate boot partition like on pegasos2 where the firmware can't read the file system used by AmigaOS so it may need boot a partition for Kickstart. That boot partition is probably not set bootable because it's not the SYS: volume but amigaboot still has to read Kickstart from there.