Forums - All Posts - The Amigans website

Forum Index

Board index » All Posts (balaton)

Bottom

« 1 (2) 3 4 5 ... 50 »

balaton

Re: AmigaOne as qemu target

Posted on: 2025/10/28 13:07 #21

Quite a regular

@Mlehto
See: https://qmiga.codeberg.page/aos_problems.html
2GB works with -kernel bboot on pegasos2 but SmartFirmware cannot detect SIMMs bigger than 1GB. This could be fixed but I did not bother as it works with -kernel bboot which is probably the most used config.

https://qmiga.codeberg.page/

Topic | Forum

balaton

Re: AmigaOS 4.1 Update 3 Borked My X5K 2.2 Enhanced Boot Drive

Posted on: 2025/10/27 11:35 #22

Quite a regular

Just a guess based on the errors but could it be that the Update contains an updated bootloader (amigaboot or whatever is used on X5000) that needs to replace the one you boot with but it's not done if you have a boot partition or separate system partition or some other specific setup? The alignment values look completely wrong so looks if it gets an unexpected format for the data it is looking for and that data is supplied by the boot loader. Or because the boot loader uses the firmware to allocate memory and load files it could be an X5000 U-Boot issue too. Do you have the latest firmware?

https://qmiga.codeberg.page/

Topic | Forum

balaton

Re: Kyvos was updated

Posted on: 2025/10/27 11:28 #23

Quite a regular

@ilbarbax
I hope to have an updated sam460ex u-boot in the next QEMU release (that will be out before Xmas) that should fix this but I haven't finished it yet and this week is the last to merge things before the release freeze so if it does not get in then will only be in release after 10.2 due next year. Until then QEMU has -monitor option to redirect the monitor to anything which management apps can use to control the virtual machine and QEMU also has some JSON based interface called QMP if I'm not mistaken for this but I don't know much about that. It should be described somewhere in https://www.qemu.org/docs/master/interop/qmp-spec.html

https://qmiga.codeberg.page/

Topic | Forum

balaton

Re: Would you pre-order Enhancer Software 2.3 to get Virtio-GPU ?

Posted on: 2025/10/26 20:13 #24

Quite a regular

@Mlehto
That's about right. For virtio the virtqueues are better than emulated cards because the emulated vCPU can write them without exiting emulation so it saves that overhead. The IOMMU with vfio-pci should allow the same but currently we have some overhead in that which makes accessing VRAM slower than it should be. I did not have time to try to find a solution and vfio was under development so it was changing so this won't be fixed in next QEMU release. Having to use 16bit with sm501 also causes a conversion to 32bit which makes that slower than it could be if the guest driver supported 32 or 24 bit. Therefore just getting a simple AmigaOS framebuffer driver that can use 24/32 bit could help a bit.

https://qmiga.codeberg.page/

Topic | Forum

balaton

Re: AmigaOne as qemu target

Posted on: 2025/10/26 19:59 #25

Quite a regular

@Mlehto
The audio parts are present on QEMU so sound should work the same as on pegasos2 but maybe AmigaOS does not select the audio output automatically on amigaone. You should be able to set it in Prefs AHI/Audio/Sound or whatever that is called then select via-ac97 (or you can add -device ES1370 and use with SB128 driver instead). There was something about Units. I think the default Unit should stay at audio.device or something like that and only select via-ac97 or other hardware drivers for the other 4 units. This was discussed on this forum before and if I remember correctly audio.device allows more apps to use output simultaneosly so you only want to select sound card for the hardware units. Sorry for the approximate info but I don't remember exactly but hope this gives some directions. If you have pegasos2 running easiest is to check what is set there in AHI Prefs and set the same on amigaone.

https://qmiga.codeberg.page/

Topic | Forum

balaton

Re: BBoot on real Pegasos 2

Posted on: 2025/10/26 15:39 #26

Quite a regular

@Mlehto
Quote:

Amigaboot.of skips hd:0 as unintresting source to boot and search next valid. Simplified.

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.

https://qmiga.codeberg.page/

Topic | Forum

balaton

Re: BBoot on real Pegasos 2

Posted on: 2025/10/26 15:29 #27

Quite a regular

@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.

https://qmiga.codeberg.page/

Topic | Forum

balaton

Re: BBoot on real Pegasos 2

Posted on: 2025/10/26 15:09 #28

Quite a regular

@flash
Quote:

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 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.

https://qmiga.codeberg.page/

Topic | Forum

balaton

Re: BBoot on real Pegasos 2

Posted on: 2025/10/26 14:45 #29

Quite a regular

@flash
Quote:

Mlehto wins, thank you ALL much appreciated!
..The fuc*ing lowercase of SmartFileSsytem was the culprit, maybe someting to emphatize in readme.

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:

Someone can explain what is the "Pin" reported by Ranger?

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.

https://qmiga.codeberg.page/

Topic | Forum

balaton

Re: BBoot on real Pegasos 2

Posted on: 2025/10/26 13:06 #30

Quite a regular

@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.

https://qmiga.codeberg.page/

Topic | Forum

balaton

Re: BBoot on real Pegasos 2

Posted on: 2025/10/26 12:41 #31

Quite a regular

@Mlehto
Quote:

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.

https://qmiga.codeberg.page/

Topic | Forum

balaton

Re: BBoot on real Pegasos 2

Posted on: 2025/10/26 12:21 #32

Quite a regular

@flash
Quote:

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.

https://qmiga.codeberg.page/

Topic | Forum

balaton

Re: Kyvos was updated

Posted on: 2025/10/25 19:50 #33

Quite a regular

@walkero
I think it's safest to always use Kickstart.zip matching the installed system or CD only updating the files that are needed to do the install and update Kickstart.zip after each update. That way problems or spurious errors (that you may or may not ignore) can be avoided. So my guide recommends that way. Maybe we need a simpler way to update Kickstart.zip but it should not be too difficult to do that after each update. At least users would be trained to not forget that after the next update.

I really need to update my web pages but I rarely come to that when there are other things to do like improving code instead. But I'll eventually get to that. Although it seems people know about Kyvos probably more than about my pages and QEMU now.

https://qmiga.codeberg.page/

Topic | Forum

balaton

Re: Kyvos was updated

Posted on: 2025/10/25 19:40 #34

Quite a regular

@derfs
I haven't seen that USB error with Update 2 when following my AmigaOS with BBoot guide posted at the URL in my signature which I have tested and can say that works. I haven't tested other ways or Kyvos so don't know about that just guessing. I can't easily have a look at the Kyvos docs if it can't be downloaded freely without hassle so don't know what's in the latest version. I've only seen an early version once but I forgot that too.

https://qmiga.codeberg.page/

Topic | Forum

balaton

Re: BBoot on real Pegasos 2

Posted on: 2025/10/25 19:23 #35

Quite a regular

@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.

Edited by balaton on 2025/10/26 12:22:52

https://qmiga.codeberg.page/

Topic | Forum

balaton

Re: BBoot on real Pegasos 2

Posted on: 2025/10/25 18:16 #36

Quite a regular

@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.

https://qmiga.codeberg.page/

Topic | Forum

balaton

Re: Kyvos was updated

Posted on: 2025/10/25 17:51 #37

Quite a regular

@derfs
The USB error seems to happen at booting the install CD so no updates are installed yet. Maybe it's result of Kyvos taking files from Update 3 other than kernel (maybe the new kernel does not work without those)? I can imagine, because Update 3 is just released, using it at install is not well tested. So maybe it's safer to install with only Update 2 as before that is known to work. That will still result in an unapdated system at 4.1FE which only has new kernel from Update 2 for the siliconmotion502.chip driver so one may then need to go through Update 1, Update 2 and only then install Update 3. This might confuse new users a lot. Even I'm not sure what is the right way to do this so I could be wrong. Having version numbers like 4.1 Update 3 and 4.1FE Update 3 that refer to completely different versions probably also does not help. So setting up AmigaOS is a challenge but may be part of the fun for some to feel they achieve something when it finally succeeds

https://qmiga.codeberg.page/

Topic | Forum

balaton

Re: Problems using a SiI3132 SATA2 controller card with my SAM460LE

Posted on: 2025/10/25 17:38 #38

Quite a regular

@skygecko
This does not look like an x86 exception to me but a PPC one. Maybe it's a bug in U-Boot? I think you should ask aCube they should know better than ChatGPT.

https://qmiga.codeberg.page/

Topic | Forum

balaton

Re: Kyvos was updated

Posted on: 2025/10/25 13:09 #39

Quite a regular

@walkero
I don't know about Windows but -initrd should work with quotes and for -drive option I usually put file= at the end and this should also work: -drive media=disk,format=raw,file="what ever path here"
If that does not work you could search for spaces in paths and add \ before them to escape them, I think that also works on Windows too. (Just don't \ escape and quote both as that won't work again; one or the other.)

https://qmiga.codeberg.page/

Topic | Forum

balaton

Re: Kyvos was updated

Posted on: 2025/10/25 12:16 #40

Quite a regular

@walkero
The QEMU command line posted above by AmigaNG has some unquoted paths. You should make sure that all paths or strings provided by the user are quoted when passed on to something else (and check that there are no quotes inside the string that could unquote them and escape those too).

https://qmiga.codeberg.page/

Topic | Forum

Top

« 1 (2) 3 4 5 ... 50 »