BBoot on real Pegasos 2

@flash
Quote:
Quote from BBoot README Troubleshooting section: "In particular SFSFileSystem is sometimes written as SFSFilesystem so either Kicklayout needs to be edited or the file renamed." Did you actually read that README? If nobody reads it no matter what I write there I think this problem with SFS may come from Enhancer as one of those have different spelling and replaces the file but does not edit Kicklayout or it may already be wrong on the CD, I did not check. I could make BBoot to try to check case insensitively but there are case sensitive file systems so it's better to fix the files and it keeps BBoot simpler.

Quote:
Some documentation to read:
https://wiki.osdev.org/Interrupts
https://wiki.osdev.org/PCI#IRQ_Handling
These are high level and x86 centered so not everything is the same on Pegasos but the general idea is the same and Pegasos also has the x86 PIC since it uses a PC south bridge chip that integrates PC hardware.

@flash
Quote:
I think they had plans (or mentioned that if anything, they would consider) to eventually do a pistorm standalone where an FPGA could emulate/implement the Amiga hardware which is more similar to what you propose. Instead of the FPGA you could take Amiga hardware emulation in software from UAE and combine that with Emu68 which may be easier than combining Emu68 with QEMU. WinUAE already has a lot of device emulation from QEMU and other sources so you just need to replace it's JIT with Emu68. The problem is that Emu68 is bare metal and UAE and QEMU run on an OS so they don't easily combine. If you want the result to be bare metal you have to remove the guts of UAE or QEMU and somehow make those run without an OS and interface it to Emu68. Using just the Emu68 JIT in QEMU or UAE is simpler but then you lose bare metal. But that probably isn't the real problem but that you also need to emulate a whole machine is what would make it slower and that may matter more than being bare metal or not. I think Emu68 is mostly bare metal to boot faster and not to run faster. It could be just as fast on a real time OS with nothing else running but if it does not need much of its services it can do without at the expense of being tied to a specific system.

@Mlehto
You can check the pegasosII schematics (link in my signature, Development page on top left, Pegasos2 emulation) how are the PCI IRQ lines connected. IRQs are usually swizzled so that each slot has different IRQ for different pins so when most cards only use a single interrupt they will end up on different IRQs. I.e. Slot 1 has ABCD connected to PCI IRQ 0123 then Slot 2 connects ABCD to 1230, Slot 3 ABCD to 2301 or so. Thus 3 cards using PinA will raise PCI IRQs 012. Then these lines go to the VT8231 chip where you can set registers to route the PCI IRQ 0123 lines to ISA IRQ 0-15 but in reality only a few of those as most of them are reserved for something.
Pegasos follows CHRP standard and a previous PREP standard based on IBM RS/6000 had all PCI interrupts connected to a single ISA interrupt so maybe it has something to do with that but I'm not sure. To change this mapping you would need to set registers in VT8231 appropriately and change properties in device tree to match so the OS that looks at the device tree will pick this up. OSes like Linux that do their own PCI setup probably don't care but AmigaOS uses what it finds set up by the firmware. If it's simpler to do in C you can look at brd_pegasos2.c in BBoot and see if it can be done from there. We have setprop and can write PCI config regs so it might be possible but I don't want to do that. After all this is up to bPlan for pegasos2 firmware or Hyperion or whoever owns AmigaOS now to support their software and not for me to spend time to work around their bugs for free. When it's easy like edge/level and 64-bit BARs or is needed for QEMU I did that but I don't want to spend more time with it. Especially when they already fixed it just could not release the fixed kernel. At least BBoot is open source so someone else can also do that.

@Mlehto
Quote:
But AFAIK it can't. All that these boot loaders do is read Kickstart modules and put them in memory and create a list of the loaded modules which is then passed to the loader that relocates them and then starts the kernel. The boot device is then selected by the kernel when amigaboot or bboot is not running. The difference is that amigaboot reads disk to load modules from there and bboot looks in the memory and expect something to preload a Kickstart.zip for it so it does not have to know about disks and file systems. The firmware already can load images and on QEMU we can write guest memory from host so I don't have to care about disks. I don't know how could amigaboot.of tell the kernel to ignore the partition it is on when there's nothing in the Kickstart list or command line it passes to the kernel to do that. So if that works then meybe the kernel somehow knows about amigaboot and ignores that partition. Or there is something in the firmware as amigaboot calls back to firmware to read disk so the firmware may know which disk it read and AmigaOS kernel could maybe check that but I don't know.