@flash Haven't read all of the Forth in your script but looking at case 5 I see -initrd which is a QEMU option and does not work from Pegasos firmware. From Forth you should call bboot.fth not bboot which then loads bboot and Kickstart.zip but if you don't have those on hd:0 then you also have to replace that to the right partition in bboot.fth. This is documented in the BBoot README. So it should probably just be
Hi Zoltan, thank you for your support but sadly I was not able to resolve, maybe I need a simple example.
Anyway I wonder if you can produce a BBoot binary not compressed in TAR but in an LHA archive to be easily usable by real amiga owners. I loose a lot of time to look for a decompressor for TAR files using AmigaOS. To get the binary I had to boot in Linux and decompress it on an usb pen.
In latest weeks I'm counting a lot of good news about Amiga world.
Michal Schulz is adapting Emu68k (running on ARM cpu) for a FAST PPC Core, much faster than QEMU. What about mixing your great knowledge of AmigaNG chipsets with a new faaast PPC Emulator?
@flash TAR isn't compressed at all (similar to lha -0 and the AmigaOS port of the Unix SysV tape backup and restore utility, C:BRU (not sure about the name, but it was included in some versions of AmigaOS), i.e. an uncompressed 1:1 copy of the data), only something like .tar.gz (.tgz), .tar.bz2, .tar.lzma, .tar.7z etc. is compressed data.
@flash What simple example could help? This is written in the BBoot README: Quote:
the Kickstart.zip, bboot binary and bboot.fth must be copied to the pegasos2 hard disk from where it's loaded by the firmware ROM. The boot.fth Forth script can load these which can be run with "boot hd:0 bboot.fth" from the SmartFirmware ok prompt and should do the rest automatically. It assumes that bboot binary and Kickstart.zip are on hd:0 (first partition of first hard disk) or this can be edited in the beginning and end of bboot.fth.
So does the "boot hd:0 bboot.fth" command work if you run it from the firmware prompt? If not then something is not as described above with the files or you don't have them on hd:0 partition in which case you need to edit bboot.fth as described above. Or if this command works then something is wrong with your boot menu script so figure out how to have it run this command.
BBoot dist file is tar.xz. Can't the xad based Unarc included with AmigaOS4 handle it? I haven't tried but there's an xadUnTar command so the only issue may be with xz but I'd expect this to be also handled by xad. It also has the Unarc GUI which I think is on the Dock by default so you could try if that works. I could do different format but tar.xz is quite common for a while to be generally supported.
How do you know Emu68k PPC core is much faster than QEMU? Have you run a benchmark on same hardware? QEMU linux-user emulation which is comparable to what Emu68k does is quite fast as it does not have to emulate MMU and a whole machine but that can only run Linux PPC executables on any other Linux arch. Emu68k has much narrower scope, only running on Pistorm so not much useful in QEMU. But QEMU allows different accelerators (e.g. you can use the same machine emulation with TCG or KVM) so it's possible to add other CPU emulators but it might not be easy to combine with Emu68k and if that's done would only run on ARM host. Also all my code in QEMU is under GPL so it's possible to combine that with other GPL sources as long as the result stays open source so if somebody wants they are free to do it.
@flash I forgot one thing. On real PegasosII you may not see the logs from BBoot as it defaults to serial. You can change settings to log to firmware console as described in the README: Quote:
first define a variable such as '16 nodefault-bytes bboot' then set options with setenv bboot . This is mostly only useful on real machine, with QEMU there is no way to set it currently but the defaults #define'ed in cfg.c as DEFAULT_OPTS are what is needed for QEMU so there should be no reason to change it. On real PegasosII hardware the settings "Of V0 Ab" (or V1 if you still want to get some feedback) might be better which skips PCI config that is already done by firmware and omits most output so may be faster and will print errors to the SmartFirmware console so no serial is needed. It is also possible to get messages on both console and serial with "Ofs"
The above was written before I've added fixups for PegasosII so maybe only change the output option for now as
16 nodefault-bytes bboot
setenv bboot Of V5 Apb
to keep defaults but change output to firmware so you don't need serial cable for debugging. You can then tweak V (verbosity) option later but keep Apb where p is PCI setup that does 64bit BAR and interrupt fixups so you don't want to disable it until it's fixed by an update which Update 3 apparently does not but the changelog does not mention what actually is fixed in kernel. You can verify if the settings were done with printenv where you should see a bboot variable with the values you set and make them permanent with nvstore that saves it to NVRAM otherwise they are only valid for the current boot. The nodefault-bytes is only needed once to define the bboot variable, after that you can change the setting with only setenv.
please take note "saveenv" is not right command to save them
Kickstart.zip is created from my working AmigaOS4 partition with this command zip -r Kickstart.zip Kickstart/
Kickstart.zip is present on my BOOT partition. bboot.fth and bboot are both present on my BOOT partition and loads ok!
On screen are printed some debug infos in very fast way, then screen goes black and Pegasos reboots. No success.
Maybe latest OS4.1fe update (3) is incompatible with bboot 0.8? ..Are there other real Peg2 users than can test it with update 3?
About TAR archives, I just used preinstalled OS4 tools and your archive is not compatible. If you want to refer to AmigaOS users you just simply to use LHA archives, this is my suggestion. Linux is another world..
About Emu68k and PPC support, if you look inside my link you can read some tips from Michal Schulz and udestand why PPC emualtion under ARM cpus is so fast. the major part of instructions falls on 1:1 conversion and big number of registers present on both ISA let him to sppedup translation againt 68k one.
On QEMU TCG is slower because it's targeted on many cases and until this version (QEMU 10) for PPC all FPU part is missing. All FPU math is made via SOFTFLOATS and so is MUCH MUCH slower. You altready knows it.
Latest suggestion for all DEVS.. why not use OS4DEPOT as main repository for OS4 software? A lot of software is present on websites I can not read with current OS4 browsers and than I simply not use them, sorry!
Are there other real Peg2 users than can test it with update 3?
Yes, me. I use bboot for year or so once balaton make it, starting from v 0.4 and now 0.9 or so. Always works with everything, and why shouldnt it : you only need properly call it with point out on ffs partition with zipoed ks folder.
So maybe I'm doing something wrong or my HW configuration is not compatible? I have some expansion cards in PCI slots like SoundBlaster, SATA adapter, USB ports expansion, and my board is latest revision with 2GB ram fully working.
Anyway bypassing my Multiboot forth script, entering in SmartFirmware console the basic command "boot hd:0 bboot" after printing some infos on screen leads to a reset.
bboot and Kickstart.zip are in the same boot partition and it seems both are loaded.
So maybe could my partitioning scheme prevents normal OS4 booting?
My last doubt about readme is about this step
"16 nodefault-bytes bboot" I have write it in SmartFirmware console without any error message as reply.
Later I hace set the bboot options setenv bboot Of V5 Apb
and then saved all vars in nvram with nvstore
What means "16 nodefault-bytes bboot" ? This is a cryptic passage for me.
Anyway bypassing my Multiboot forth script, entering in SmartFirmware console the basic command "boot hd:0 bboot" after printing some infos on screen leads to a reset.
"..bboot binary and bboot.fth must be copied to the pegasos2 hard disk from where it's loaded by the firmware ROM. The bboot.fth Forth script can load these which can be run with "boot hd:0 bboot.fth" from the SmartFirmware ok prompt and should do the rest automatically. It assumes that bboot binary and Kickstart.zip are on hd:0 (first partition of first hard disk) or this can be edited in the beginning and end of bboot.fth.."
On some circumstances I had to set first partition (hd:0) boot priority lower than AmigaOS disk. Both Zero-zero leads bboot try to boot OS from first partition, where bboot resides.
There is still lower/uppercase on upd3 kicklayout. On kicklayout is written SmartFilesystem when file name is SmartFileSystem. Bboot doesnt find it and result is black screen.
Edited: In here ”boot hd:0 bboot.fth” works fine on real peg2. Boot priority hd:0 is -3 and kicklayout/filenamind upper/lovercase corrected. Peg2 2b2, slots populated with sii3114 and nec usb2.0 card.
@Zoltan
As for bboor README: It is also possible to get messages on both console and serial with "Ofs"
How you set OF output to both screen and serial on same time ? I tried ”setenv output-device serial screen” when only first applied. Where serial is devalias to OF real serial device.
bypassing my Multiboot forth script, entering in SmartFirmware console the basic command "boot hd:0 bboot" after printing some infos on screen leads to a reset.
So the multiboot part is OK. You likely have some problem in Kicklayout like upper/lower case mismatch, check for that. To check for the error if the firmware does not return to console but reboots you have two options: If you have a serial cable you can get messages on serial just by unsetting bboot variable (then it will use the default Os V5 Apb setting) or setting it to Ofs V5 Apb to get both firmware and serial output. Without a serial cable you can try recording the screen and then see if you can catch the error by looking at the video frame by frame. Quote:
and then saved all vars in nvram with nvstore
OK then it's different in SmartFirmware, U-Boot has saveenv. Quote:
What means "16 nodefault-bytes bboot" ? This is a cryptic passage for me.
It allocates 16 bytes for the bboot variable otherwise you can't set it with setenv.
On some circumstances I had to set first partition (hd:0) boot priority lower than AmigaOS disk. Both Zero-zero leads bboot try to boot OS from first partition, where bboot resides.
Maybe you don't even need to set boot partition as bootable. That sounds like wrong at first but bootable is where your system files are and boot partition is where the bootloader is. The boot partition is read by firmware which does not know about Amiga bootable flag so probably it does not need bootable flag and would work either way and you should only set bootable your actual system partition. I don't know what AmigaOS install does or what the guides say about this and why you ended up with two bootable partitions with same priority. I still don't understand how it works with amigaboot.of. BBoot does not try to boot any partition, it only looks for Kickstart.zip in memory and starts the AmigaOS kernel from that. Maybe AmigaOS knows to ignore bootable flag on partitions where amigaboot.of is? You can try that by copying amigaboot.of file next to bboot even if not using it and see if that boots with boot priority set the same as system. I don't know how else amigaboot.of could set different boot partition as it's AmigaOS that looks for after it's started.
Quote:
As for bboor README: It is also possible to get messages on both console and serial with "Ofs"
How you set OF output to both screen and serial on same time ? I tried ”setenv output-device serial screen” when only first applied. Where serial is devalias to OF real serial device.
It's also written in README. On QEMU no way, only serial there. On real machine see in posts above.
@flash I'll check if there's a better format for BBoot dist archive but it's likely not lha. The primary audience for BBoot are QEMU users who want to use it on platforms where QEMU runs where it's usually easier to use tar.xz than lha. It's also the reason I picked zip as the Kickstart format and not lha because zip can be easily created anywhere and has a small extractor that's also faster than lha so it's better for this than lha even if it's a bit alien from AmigaOS.
This should likely belong to another thread not here but as a short comment I saw Michal's Emu68 presentation from Amiga40 and skimmed the link you posted but what was shown is closer to theoretical maximum and not what you'll get as average performance. QEMU is also quite good at running tight loops of integer ops once compiled as can be seen by benchmark results especially on ARM. Emu68 can be faster than QEMU as it only needs to run on certain RPi models and use a CPU exclisively without on OS and doesn't have to be accurate all the time but that's not useful for QEMU. The scope is different. Emu68 aims to be faster than hardware accelerator cards (which is probably easy considering they usually have old PPC CPUs on them) but QEMU aims to run anything anywhere and emulate whole machine not just a CPU. Also QEMU has a Q in its name but it's never said what it stands for. Likely "quick" but maybe it was originally referring to that it first was a quick hack to emulate a PC with TCG that started as a cross compiler but since it was also faster than non JIT compiling emulators this also referred to its performance. But the goal of QEMU is to emulate hardware accurately enough that guest code can run with a usable performance and it does not want to sacrifice accuracy for performance. The FPU performance could be improved but the easy way to ignore accuracy was not accepted and even making that optional would make the accurate way slower so that's also not acceptable. What could work is make FPU ops undoable then you can run fast but possibly inaccurate until the guest want it accurate (reads the flags) then you need to rerun the last FPU op slowly and provide accurate results. This was discussed but nobody implemented it so far.
Mlehto wins, thank you ALL much appreciated! ..The fuc*ing lowercase of SmartFileSsytem was the culprit, maybe someting to emphatize in readme.
Using Ranger I see always only 4 interrupts (you have to subtract 16) reserved for hardware, Is this correct or something could be reserved on a different interrupt? I.E. the VGA CONTROLLER share the IRQ 25 with other hardware, maybe it could be allocated on another free one?
Line: 0x00 Pin: A Number: 16 - HOST BRIDGE Line: 0x09 Pin: A Number: 25 - FIREWIRE Line: 0x09 Pin: A Number: 25 - AUDIO DEVICE Line: 0x09 Pin: A Number: 25 - MASS STORAGE CONTROLLER Line: 0x09 Pin: A Number: 25 - USB EHCI Line: 0x0E Pin: B Number: 30 - USB EHCI Line: 0x09 Pin: C Number: 25 - USB2 EHCI Line: 0x00 Pin: None Number: N/A - ISA Bridge Line: 0x0E Pin: None Number: N/A - IDE CONTROLLER Line: 0x09 Pin: D Number: 25 - USB UHCI Line: 0x09 Pin: D Number: 25 - USB UHCI Line: 0x00 Pin: None Number: N/A - BRIDGE DEVICE Line: 0x09 Pin: C Number: 25 - AUDIO DEVICE Line: 0x09 Pin: C Number: 25 - COMMUNICATIONS DEVICE Line: 0x09 Pin: A Number: 25 - ETHERNET CONTROLLER Line: 0x00 Pin: A Number: 16 - HOST BRIDGE Line: 0x09 Pin: A Number: 25 - VGA CONTROLLER
Someone can explain what is the "Pin" reported by Ranger?
about Emu68k and QEMU I was thinking for a little hardware baed on ARM to run OS4 baremetal at max speed. Something not possible with QEMU or not with same effiency.
I digged those out from OF with forth, didnt have time to test, how to set IRQs on more sensible order. Mostly because I didnt find correct way to call chipset (yet). My brains can be allso too small to make universal script, only particular where slots are populated with (my) known devices.
Anyway, as expected (and said), all irqs really are on 0x09 on OF, except ide. It is isa device or treated as one, so it gets own irq there.
For my understantment Pin A-D is hardware routes from slot to chipset. All peg2 slots has A-D wired. If you have multi-device card, say usb2.0, there is three devices, usb 1.0, 1.1, 2.0. Then card will get three pins. Each pin can have different irq number on samre slot (wich goes after all to chipset PIRQ:s). Not all pins necessarily have same irq. Pin A on one slot can have different irq on Pin A on next slot.
These frigging irq:s are pretty alien to Amiga ... :D Doesnt help that peg2 OF is low-level env, where everything is possible but nothing is available easily.
I presume, that modern NG motherboards (pcie) uses MSI/MSI-X scheme, where there is a LOT of irq:s to use and nothing to worry about. If they dont fall back compability layer to old IRQ:s. Anyway PCIe uses MSI/MSI-X nativelly.
I read it from somewhere, dont remember where. At least this edge/level can come from "The Open Desktop Workstation" specs, wich peg2 is build on. All irq on same, dont know. Dont know why level is picked instead of edge, maybe it was just leaved to OS to set them.
I think that you are right, first partition doesnt need any amiga flags. I dont remember any more, what I did 15 years ago, when I got peg2. My boota has been as is ever since. Ok, bboot&co added, but same disk, same partition scheme. And I probably mixed things when I booted from ide and moved OS to run on SSD. I changed it recently back to boot OS from ide, as it is more clean.
bboot works correctly, it boots, where Im set it, first bootable partition, highest or equal boot priority. Amigaboot.of skips hd:0 as unintresting source to boot and search next valid. Simplified.
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
