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.

@balaton
Quote:zip (infozip/pkzip, not gzip) isn't much more alien to AmigaOS than lha is, zip includes some AmigaOS additions as well, just like lha does: Support for AmigaOS protection bits, AmigaOS file comments, etc.
Neither one originates from AmigaOS, lha and it's predecessor LHarc are from Unix, zip from MS-DOS.
However the lha port was the first usable compression tool on AmigaOS, and 99.9% of the archives on Aminet and OS4Depot are in lha format.
Additionally the lha versions developed on AmigaOS were way ahead of the Unix versions at some time.

Using infozip instead lha should be no problem, but using anything TAR based is a bad idea, even if all common compression formats for it (.gz, .bz2, .xz, etc.) are available on AmigaOS as well.
lha and zip are case insensitive, at least the AmigaOS ports of it are, while (the AmigaOS port of) TAR isn't, and TAR doesn't include any AmigaOS support like it's, different to POSIX, protections bits or comments.
There are probbly other ports as well, but I ported LZMA, XZ and 7-Zip to AmigaOS, incl. XFD libraries for them.

Quote:Should only be a problem for emulating something like a m68k FPU (80 bit FPU registers, the results from a real 68882 FPU were used as reference for the newlib C library math function tests for example), but not for 64 bit FPUs like the ones in PowerPCs, except for the flags maybe.

@kas1eQuote:

Please, what is advantage of using bboot on real Pegasos 2 machine?

@sailor
The BBoot README says:
Quote:
Primary advantage may be that it's faster and if PCI setup is enabled ("Apb" option) then also fixes interrupt controller setting which may avoid lost interrupts with multiple PCI cards. Also truncates 64 bit BARs of newer cards so AmigaOS can see them but that's not enough to use newer GPUs via a bridge because the bridge would also need to be handled which is only done by newer, still unreleased kernel.

@joerg
Probably the reason for lha on Amiga was that PKZip was copyrighted and maybe also patented while lha was free and achieved better compression than zip but could not replace zip on PC where that was already established but could become widepread on Amiga where zip wasn't yet present. For BBoot none of case insensitivity nor Amiga attributes are relavant as this archive primarily stores the sources that I wrote and compile on Linux so other format would actually lose attributes. Users only need the bboot binary from it and most users use it for QEMU on other platforms where extracting tar.xz is not a problem. So maybe those who use it on real Pegasos II can extract it on some other machine too which is a bit inconvenient but not a big barrier. I'm not sure it's even possible to download it from codeberg from AmigaOS given the browser situation.

Quote:
The flags are exactly the problem why PPC can't use hardfloat in QEMU. The PPC not only has cumulative flags like other archs but also per operation bits which need to be cleared and reset for each operation. Clearing the bit before each operation would be slower than using softfloat and not emulating these is not acceptable either (even optionally as checking for that option would also make it slower, I've tried that before). So the only way would be to detect if guest reads flags and recompute last FP op to provide per operation bits while we could skip updating these bits otherwise if guest does not access them. Most apps never read these so they could use hardfloat then. But somebody should look at implementeing this and submit it to QEMU.

@balaton
Quote:Case insensitivity in the infozip implementation used by BBoot would help, IIRC there was a Kickstart/SmartFileSystem.kmod in AmigaOS 4.0-4.1 and some updates of it but the Enhancer Software versions use Kickstart/SmartfileSystem.kmod instead (or maybe it was the other way round, not sure any more).
It's no problem on most real hardware using case insensitive file systems like FFS2 or SFS and SLB_v2 or AmigaBoot.(ub|of) for loading the Kickstart modules, but it's on QEmu, and real Pegasos2, using BBoot and Kickstart.zip instead.

As for copyrights, and maybe patents: PKZip was a problem.
But AFAIK the InfoZip re-implementation of it shouldn't have those.
Compression ratios in lharc/lha, pkzip/infozip and gzip are similar, on AmigaOS lzx was better. lzx was ported by it's author from AmigaOS to Windows and licensed to MicroSoft for their .CAB archives.
Of course all of those ancient LZ77, LZ78, bzip2, etc. based compression algotithms are a bad joke compared to more advanced ones like LZMA and XZ, or for archives instead of single files 7-Zip.

@sailor
Quote:
Speed of booting : bboot saves about 10-12 seconds on my peg2, i.e. instead of 40 something like 28-30 for full load up

@kas1e
Quote:Instead of using a LZ77 based (de)compression I'd try a LZO based one.
It's even much worse at compression than LZ77, LZ78, etc. (lha(rc), pk-/infozip, gzip, etc.) is, and I don't know anything about the Pegasos2 SmartFirmware, but the AmigaOne U-Boot is executed with caches disabled, and LZO is much faster, with and without caches, at decompressing than next to anything else is.
In a few very rare cases (or even most of of them, if you believe the stats reported by it's authors ) LZO compression and decompression can even be faster than an optimized memcpy().

@joerg
Info-Zip only became usable in 1992 (before that could only unzip) and wasn't available when lha got widespread on the Amiga in the end of 80's. At that time PKZip may also had used older compression methods yet that were not as good as lha plus it wasn't freely available for Amiga (if at all) so lha was a better choice then.
For BBoot zip isn't just for speed but for easy usability. E.g. on macOS you can make a zip just by right clicking on a folder without needing to install any tools for that and it's probably the same on Windows and on any operating system (except maybe Amiga) so zip is the simplest to use for novice users. Replacing it with something else would need other tools to make the Kickstart initrd so that would be a step back. I think the speed doesn't mainly depend on unzipping but loading the file from disk so using LZO may not be significantly faster but would require an obscure compression tool to use. Zip is a good compromise between size speed and easy of use.
Case sensitivity does not depend on the unzip implementation. I could uppercase or lowercase the name before comparing but that's additional code and on unix it's possible to make zip with files only differing in case so then case insensitive compare would find a random one. It's better to fix the Kicklayout.

Bboot was not designed for real hardware. It can be used there, but its intended purpose is emulation.
The fact that it works on real hardware and bypasses certain barriers is solely thanks to @balaton.
In QEMU A1 emulation, you don't currently need to use bboot. Only if you want to. For PEG2, due to uboot/firmware limitations in QEMU, yes

Quote:
In Linux too. In the case of LHA, different distributions need to be added manually. An extreme example would be Ubuntu 20.4. The deb package lha was broken and did not unpack lha files correctly.