I haven't followed this thread for a while. Can someone give a summary of where we are right now? bboot will replace pegasos2.com + BAR script? Or is a script still necessary?
Yes, that’s the idea. Bboot + VOF does all the hardware config and OS module loading. At the moment I don’t think it has worked for either of us that have tried on actual hardware yet but Balaton made a change last night that I’m hopeful will work. I’ll test shortly.
Unknown at the moment but I would say yes, you would because I don't think this changes any of that, the big benefit to us is that we should no longer need to mess about with Forth scripts. There are other benefits of course.
The only reason I'm not so sure is because it looks like bboot is patching a bit extra compared to what I was doing in Forth.
I'm not going to get time to test until after work this evening now.
Do I also need to apply this interrupt patch? Or is building from the latest sources enough.
Nobody knows until somebody tries. Try with qemu 8.1-rc0 or git master without any patches first then if it still has problems we can try patching IRQs. BBoot does not handle IRQs it will just set IRQ 9 for any devices not having an IRQ yet which is what pegasos2.rom seems to do as well but we never understood what exavtly causes the freeze so that's the next thing to debug. BBoot at least provides infos on how the PCI devices are configured at boot and we can compare those with different settings.
One thing that I do not understand in the Pegasos2 interrupts discussion is the whole edge sensitivity. PCI interrupts are level sensitive. Therefore the emulated legacy interrupts consist of a begin and end interrupt message.
@balaton Oh my ! bboot 0.2 works fine on real pegasos2 ! I can boot amigaos4 with it just fine, the same as it happens with amigaboot.of. That the output i have on serial:
I compare time wise the execution, and with my IDE2SAta adapter and Sata disk i got this:
Amigaboot 54.9 (10/27/2022) - 36 seconds once amigaboot start execution of modules till working Workbench.
Bboot - 27 seconds once i type "boot hd:0 bboot.fth" till working Workbench.
10 seconds faster !
Those figures with debug level enabled, so without it will be even faster.
Waiting now for the PCI to PCIE adapters to arrive to check with RadeonHD/RX. But so far it works with real pegasos2 for sure, which mean that users will have no needs for manual BAR fixes then.
Will check if it is possible from forth calculate size of the Kickstart.zip to avoid manual typing.
Did i understand right, that needs for kickstart.zip to be in the boot ffs partition and not the same as for amigaboot.of to be in the kickstart directory on the SFS disk, because bboot can't work with SFS ? only that ?
Radeon 4850 results in a crash of the RadeonHD driver right after the workbench screen shows up on the display. Radeon RX 560 results in a crash of QEMU. Will post more details tomorrow.
Did i understand right, that needs for kickstart.zip to be in the boot ffs partition and not the same as for amigaboot.of to be in the kickstart directory on the SFS disk, because bboot can't work with SFS ? only that ?
BBoot is GPL v2, therefore it never can get any support for my AmigaOS SFS versions.
Adding support for old SFS versions like 1.84, for example using the AROS GPLed SFS 1.84 sources, would be possible (after porting the AROS code back to AmigaOS), but since such old versions aren't compatible to current AmigaOS SFS versions any more that may not work either.
BBoot is GPL v2, therefore it never can get any support for my AmigaOS SFS versions.
What kind of support you mean ? Is there needs for any support to add read-only support of any fs does not matter what, so to be able to read from to be able to load kickstart modules ?
But all that just theoretical and not important, loading kickstarts from FFS work fine as well for now, and more than enough to handle issues with RadeonHD/RX in meanwhile. With .zip file loading from FFS even faster than with unpacked modules on SFS2 (At least on pegasos2 and at least with the ~4mb zip archive).
EDIT: By the way, i found that latest pegasos2 firmwares, not only support USB keyboards (i use USB keyboard there) , but also have ability to boot from SFS too, but so far it looks like just from some ancient version of SFS (it can see morphos's SFS, but can't see amigaos4's SFS00).
Edited by kas1e on 2023/7/21 16:35:46 Edited by kas1e on 2023/7/21 16:51:35
Im getting the kickstart files to load, but before i get the pass-through gfx output on the 2nd screen my PC hard crashes!
My hard-crash issue seems to be a known issue with Ryzen cpus
Linux logs show it as a MCE hardware error, which - depending on what you read - either needs an update to the bios, or requires playing around with voltages in the bios.
EDIT: By the way, i found that latest pegasos2 firmwares, not only support USB keyboards (i use USB keyboard there) , but also have ability to boot from SFS too. But i assume it's an ancient version of SFS
Maybe not (much) older, but it's for the incompatible MorphOS SFS port, which doesn't even seems to be compatible to SFS 1.84, let alone to the changes I did in my AmigaOS SFS versions, which aren't 100% compatible to SFS 1.84 anymore either, but of course using different changes.
I got sector dumps from someone who destroyed an AmigaOS 4.x SFS partition by writing from MorphOS to it several years ago. Some of the sectors included invalid data which was definitely overwritten by the incompatible MorphOS SFS version.
Read-only access, like in a boot loader, might work most of the time even when using incompatible SFS versions, but there is no guarantee.
I got sector dumps from someone who destroyed an AmigaOS 4.x SFS partition by writing from MorphOS to it several years ago. Some of the sectors included invalid data which was definitely overwritten by the incompatible MorphOS SFS version.
Years ago i also destroyed OS4's SFS boot partition when wrote from Morphos to it (it wasn't like from the first write, but just after i do many write to). But other way around (from OS4's SFS to Morphos's SFS) works fine. So i just remember to not write from mos to os4's sfs anymore.
As for SFS reading from peg2's firmware, i do have on pegasos2's disk such partitions:
And when i do "ls" on them from peg's firmware, i can see ffs, morphos's sfs, but for our one have just "sfs-load: file "" not found ". So, yeah, it only read mos's sfs.
@All Interesting that on real pegasos2 , both Ethernets (and inbuilt one, and my PCI card one) sit on irq 0x09, together as many other things, but bridges (host bridge, isa bridge, etc) on 0x00 and IDE on 0x0E. But all others like audio, network, video, fireware, usb all indeed on 0x09. Just not IDE and bridges.
@balaton So far sitting playing with peg2 for few hours booted from bboot 0.2 do not cause in os4 itself any differences in compassion with when i boot by amigaboot.of.
Edited by kas1e on 2023/7/21 17:20:37 Edited by kas1e on 2023/7/21 17:34:54 Edited by kas1e on 2023/7/21 17:36:57
@balaton So far sitting playing with peg2 for few hours booted from bboot 0.2 do not cause in os4 itself any differences in compassion with when i boot by amigaboot.of.
I am surprised myself that BBoot runs so well with AmigaOs4.1.
I can also confirm that the system continues to work stable without problems. Web browsing with YouTube streaming and sending files via FTP with ZitaFTP all no problem, even a good 30 minutes BreakHack play was possible until I had no more desire.
Fantastic work, tested under Qemu 8.1 RC0
Edit: Due to the new bootloader "BBoot" I am forced to completely revise my installation instructions concerning the installation of AmigaOs.4.1 under Qemu Pegasos 2. Maybe someone could also create an english manual? Otherwise you could translate my installation guide into English since it is written in German.
Edited by Maijestro on 2023/7/21 19:34:29 Edited by Maijestro on 2023/7/21 19:36:43
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
Looking at the log from real PegasosII it looks like board firmware also leaves card at least on AGP bus with all ff values not only for interrupt but also for BARs. I'm not sure how that happens but if this works on real machine then BBoot should also not set these and leave them when they are set to all ff values. Currently in 0.2 these will be set and due to having wrong BAR values it results in 32 bit BARs set to 64 bit which maybe does not cause a problem if AmigaOS driver only needs the assigned-addresses property values and later reprograms the card based on that but I should probably need to fix this in a next version to get closer to real hardware.
To check if other values are the same with pegasos2.rom and bboot+VOF you could try booting with bboot both through bboot.fth with -bios pegasos2.rom (and maybe also running your script first) and without ROM just using -kernel bboot and post both logs and compare the values in those. BBoot prints the assigned-addresses property and other PCI values as it finds them and all chnages it made to them so this should help to find what's different when it works vs. when it doesn't. I think you got this just did not have time to test it but just saying it again to make sure I've explained it clearly enough.
@Maijestro I plan to update my pegasos2 guide with BBoot instructions, I just haven't got to it yet.
@Maijestro I plan to update my pegasos2 guide with BBoot instructions, I just haven't got to it yet.
No problem, I'll take care of it and send you the updated installation instructions by mail for comparison, I think you'll surely find one or the other error.
I am also not sure if BBoot works for the complete standard installation with the AmigaOs4.1 Pegasos 2 install CD. Since I'm on vacation right now, I'll test it over the next few days.
Edited by Maijestro on 2023/7/21 21:02:28 Edited by Maijestro on 2023/7/21 21:03:35
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE