Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
124 user(s) are online (38 user(s) are browsing Forums)

Members: 0
Guests: 124

more...

Support us!

Headlines

 
  Register To Post  

« 1 ... 47 48 49 (50) 51 52 53 ... 78 »
Re: What the fastest possible x64 emulation way of OS4 today ?
Quite a regular
Quite a regular


See User information
@Maijestro, @joerg

There may be some issues with parsing but BBoot is case sensitive and don't plan to make it insensitive (no strcasecmp in minimal libc) so you should match file case. I did a diff of the names in Kicklayout and zip listing above and it found this:

-Kickstart/SmartFilesystem
+Kickstart/SmartFileSystem

This is what I said in first reply: "check that 1. it's there, 2. its name matches what's in Kicklayout"

Leading spaces should not cause problem and ; lines should also be ignored even with spaces before them. I'll check white space at end that may cause trouble and may need to be handled.

Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Not too shy to talk
Not too shy to talk


See User information
@balatonQuote:
balaton wrote:@derfs
Does that crash cause any issue apart from the log? The emulated pegasos2 does not have nvram so even using the pegasos2.rom it would not be able to read anything but if it uses rtas then with VOF even the rtas calls are not implemented. I can look into that if it causes a problem but since there's nothing to return it does not matter if the result is only this log message but no other problems in AmigaOS.

If it's a problem with unimplemented rtas call you should see messages saying "Unknown RTAS token..." when using -d unimp QEMU option when the crash happens. That would confirm this is calling rtas and does not handle error from there (becuase on real firmware these are implemented).


There are no unimplemented messages when the programs crash. If I use the pegasos firmware then nvgetvar produces output instead of crashing.

New Shell process 8
8.AmigaOS
:> nvgetvar
peg2ide_xfer
=FFFF
peg2ide_irq
=1111

«­Êþ«­Êþ«­Êþi
¢ài
¡Ài
¯Ði
¢Þ­¾ïÞ­¾ïÞ­¾ïÞ­¾ïÞ­¾ïÞ­¾ïÞ­¾ïÞ­¾ïi
¡ði
¡0i
¯Ði
¢°Þ­¾ïÞ­¾ïÞ­¾ïÞ­¾ïÞ­¾ïÞ­¾ïÞ­¾ïÞ­¾ïi
 Ði
¢i
¯Ði
¢àÞ­¾ïÞ­¾ïÞ­¾ïÞ­¾ïÞ­¾ïÞ­¾ïÞ­¾ïÞ­¾ï
(goñ(
8.AmigaOS:>

The peg2ide commands are found in the kickstart file nvram.config

*edit*

noticed that AmigaOS has an extra error in the debug log for bboot, but not pegasos2.rom

Error adding SMI interrupt

Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Just can't stay away
Just can't stay away


See User information
@balatonQuote:
balaton wrote:@Maijestro, @joerg

There may be some issues with parsing but BBoot is case sensitive and don't plan to make it insensitive (no strcasecmp in minimal libc) so you should match file case. I did a diff of the names in Kicklayout and zip listing above and it found this:

-Kickstart/SmartFilesystem
+Kickstart/SmartFileSystem

This is what I said in first reply: "check that 1. it's there, 2. its name matches what's in Kicklayout"

Leading spaces should not cause problem and ; lines should also be ignored even with spaces before them. I'll check white space at end that may cause trouble and may need to be handled.


Ok I found the error in the kicklayout it says "SmartFileSystem" but in the kickstart folder the module is called "SmartFilesystem" this caused BBoot not to find the file.

@joerg

I use the SmartFileSystem from Enhancer Software 2.2 apparently it is written differently "SmartFilesystem" like the original one on the AmigaOs4.1 Pegasos 2 install CD. Maybe this should be fixed in the Enhancer Software package. ?

Balaton I am thrilled with the boot speed this takes Qemu to the next level finally the boot command is no longer needed and AmigaOs.4.1 boots completely. Due to the new bootloader, we can now use 2048 MB of RAM, a great additional side effect

Thank you for this alternative boot option I am so happy wow this is even more fun now. I hope you got your donation account in order in the meantime

@all

Thank you very much for trying to help. It is impressive what we can achieve together as an Amiga community.





Edit: @Balaton It seems like Qemu 8.1 RC has been optimized a bit...this is what some benchmarks I did conclude. With 8.1 RC I get for the first time without "hard float" patch with Quake Timedemo over 30 FPS that is impressive.


Edited by Maijestro on 2023/7/20 18:27:03
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Just can't stay away
Just can't stay away


See User information
-


Edited by white on 2025/11/9 5:15:36
Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Not too shy to talk
Not too shy to talk


See User information
@white

Check the contents of your zip for "SmartFilesystem" vs "SmartFileSystem" it looks like you have the exact same error as Maijestro just one reply above yours.

Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Just can't stay away
Just can't stay away


See User information
-


Edited by white on 2023/7/20 17:55:34
Edited by white on 2025/11/9 5:15:18
Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Home away from home
Home away from home


See User information
@Maijestro
Quote:
@joerg
I use the SmartFileSystem from Enhancer Software 2.2 apparently it is written differently "SmartFilesystem" like the original one on the AmigaOs4.1 Pegasos 2 install CD. Maybe this should be fixed in the Enhancer Software package. ?
I can change it in the next SFS update, but until now that never was a problem since all other bootloaders (classic Amiga, SLB_V2, amigaboot.(ub|of)) are case insensitive.
The only problem might have been using a case-sensitive formatted SFS partition for the kickstart files, but I'm not sure any of the boot-loaders supports that at all.

Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Just can't stay away
Just can't stay away


See User information
@joergQuote:
joerg wrote:@Maijestro
Quote:
@joerg
I use the SmartFileSystem from Enhancer Software 2.2 apparently it is written differently "SmartFilesystem" like the original one on the AmigaOs4.1 Pegasos 2 install CD. Maybe this should be fixed in the Enhancer Software package. ?
I can change it in the next SFS update, but until now that never was a problem since all other bootloaders (classic Amiga, SLB_V2, amigaboot.(ub|of)) are case insensitive.
The only problem might have been using a case-sensitive formatted SFS partition for the kickstart files, but I'm not sure any of the boot-loaders supports that at all.


It doesn't really matter either, since it works on real hardware. I just wanted to point it out to you

MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Quite a regular
Quite a regular


See User information
@joerg
Quote:
I can change it in the next SFS update, but until now that never was a problem since all other bootloaders (classic Amiga, SLB_V2, amigaboot.(ub|of)) are case insensitive.
The only problem might have been using a case-sensitive formatted SFS partition for the kickstart files, but I'm not sure any of the boot-loaders supports that at all.


More exactly Amiga file systems are usually case insensitive so the bootloader passing a name with a different case would still read the file. There's nothing in the bootloaders to handle this, it's because of the file systems. BBoot cannot read from disk so it reads from a zip instead which is case sensitive but I don't want to add special handling as it may later also read from disk and then reading from a case sensitive file system will be the same.

If you correct this in SFS consider that all other file system modules seem to be using capital S as FileSystem only SFS uses lower case so maybe it was supposed to be corrected by renaming the module but the Kicklayout entry was missed as it still loads that way on case insensitive file systems. It seems the upper case version comes with Enhancer Software so perhaps that should also change Kicklayout when installing the new module.

I've made some changes to Kicklayout parsing to be more tolerant in next version but I don't plan to handle case sensitivity there.

Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Quite a regular
Quite a regular


See User information
@white
Quote:

this is the qemu 8.0.3 command line:

Are you sure it's QEMU 8.0.3? That version didn't have -initrd yet I think unless that patch made it in stable without me noticing but it's more likely a typo. All should be testing 8.1 rc release now so we can fix any bugs for the release.

Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Quite a regular
Quite a regular


See User information
@derfs
If you see no Unknown RTAS token message then it's not using rtas to access nvram but reads it directly. I think I know what might be missing then but does this cause any issue other than the crash log? If not I probably won't fix until QEMU 8.2. The output you get with pegasos2 firmware does not seem meaningful anyway.

Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Not too shy to talk
Not too shy to talk


See User information
@balaton

I'm still double-checking to make sure I've not got something mixed up here. I'm on my linux box now (the one with passthrough). With SM501 everything boots OK using the new bboot. With my 5450 passed through on pci.1,addr3 & addr4 (hdmi sound) I can't boot and I think it's because there's an incorrect address.

BBOOT:
/pci@80000000/pci1002,68e1:    0:3.0     1002:68e1 30000 68e11002 01ff 0
Fixed ROM BAR
Added assigned
-addresses
 42001810        0 90000000         0 10000000  
0000000c 90000008
  2001818        0 a0000000         0    20000  
00000004 a0000000
  1001820        0 fe001300         0      100  
00000001 00001301
  2001830        0 a0020000         0    20000  
00000000 a0020000
/pci@80000000/pci1002,aa68:    0:4.0     1002:aa68 40300 aa681002 02ff 0
Added assigned
-addresses
  2002010        0 a0040000         0     4000  
00000004 a0040000


Note the 0x100 byte mapping of 0xfe001300

If i boot the old way and query the properties:

reg                   3:0
                      xp3
,0,10,0:10000000
                      x3
,0,18,0:20000
                      i3
,0,20,0:100
                      m3
,0,30,0:20000
assigned
-addresses    xp3,0,10,90000000:10000000
                      x3
,0,18,81020000:20000
                      i3
,0,20,FE001200:100
                      m3
,0,30,81080000:20000


Note: 0xfe001200 (not 0xfe001300) but I'm scratching my head a bit at the moment how this could be coming out wrong for this one instance and correct for everyone else.

I am using latest master Qemu with the original patch MBOX applied on top.

[edit] Actually that's completely different addresses. Let me make sure I'm not getting something mixed up!

Nope, only difference is in the use of bboot:

New (bboot)
QEMU_CMD="sudo $QEMU_BIN \
-L pc-bios -M pegasos2 -vga none \
-cpu 7457 -m 1024 -kernel bboot -initrd Kickstart.zip \
-rtc base=localtime -serial mon:stdio -display sdl \
-device bochs-display,romfile="" \
-drive media=disk,format=raw,file=hd/os41_pegasos2.img \
-drive media=disk,format=raw,file=hd/os41_data.img \
-audiodev pa,id=snd0,server=unix:/run/user/1000/pulse/native \
-device rtl8139,netdev=net0 -netdev user,id=net0 \
-device vfio-pci,host=02:00.0,bus=pci.1,addr=3,multifunction=on,x-vga=on \
-device vfio-pci,host=02:00.1,bus=pci.1,addr=4"


Old (bios rom)
QEMU_CMD="sudo $QEMU_BIN \
-L pc-bios -M pegasos2 -vga none \
-cpu 7457 -m 1024 -bios pegasos2.rom \
-rtc base=localtime -serial mon:stdio -display sdl \
-device bochs-display,romfile="" \
-drive media=disk,format=raw,file=hd/os41_pegasos2.img \
-drive media=disk,format=raw,file=hd/os41_data.img \
-audiodev pa,id=snd0,server=unix:/run/user/1000/pulse/native \
-device rtl8139,netdev=net0 -netdev user,id=net0 \
-device vfio-pci,host=02:00.0,bus=pci.1,addr=3,multifunction=on,x-vga=on \
-device vfio-pci,host=02:00.1,bus=pci.1,addr=4"


I did also try with 2048 memory in case that changed anything but it didn't.


Amiga x5040 ı 16GB ı RX580
A1200 PiStorm32-Lite CM4
Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Quite a regular
Quite a regular


See User information
@MartinW
If you use BBoot with -kernel then it will assign addresses instead of the firmware because VOF does not do that so you get similar but not identical results as BBoot's algorithm for allocating addresses is not the same as what the pegasos2 firmware does. The results are similar but there can be differences. I'm not sure what BBoot does is correct but as long as it does not allocate overlapping areas and everything is mapped that should be OK. There's not much info in the partial log you've posted but what looks strange is the 0xff value set for interrupt line. BBoot would set it to 9 if it was 0 but does not touch it if it has another value but I'm not sure how 0xff ended up there.

To check the mapping you can run BBoot with the pegasos2.rom firmware, just loading boot hd:0 bboot without the forth script to load initrd won't boot but still get the numbers about PCI BARs so you can check and debug that way what are the differences when the firmware assigns BARs and when BBoot does it. So you'd need to get two logs:
1. with -bios pegasos2.rom and loading bboot from guest disk and
2. the full log when using -kernel bboot without -bios which is when BBoot is assigning addresses and compare the two to see there are anything that could cause trouble.

Different guest RAM sizes won't change anything as these BARs are mapped in the windows over 2GB, it does not matter what's below that only how the windows are set but QEMU follows what the firmware does in setting the windows for the PCI buses.

Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Not too shy to talk
Not too shy to talk


See User information
@balaton

OK, yes - info pci shows interrupt 0.

I'll investigate.

Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Just can't stay away
Just can't stay away


See User information
@balaton

--version gives me this:
qemu-system-ppc --version
QEMU emulator version 8.0.50 (v8.0.0-2725-g887cba855b-dirty)
Copyright (c) 2003-2023 Fabrice Bellard and the QEMU Project developers

Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Not too shy to talk
Not too shy to talk


See User information
@white

Have you done a
git fetch
git pull

And then rebuilt Qemu?

You should be seeing something along these lines:
[mart@archlinux OS4_QEMU]$ ../Dev/patched-qemu/bin/ppc/qemu-system-ppc --version
QEMU emulator version 8.0.90 
(v8.1.0-rc0-1-g91ce90cf59-dirty)
Copyright (c2003-2023 Fabrice Bellard and the QEMU Project developers

[mart@archlinux OS4_QEMU]$ ../Dev/qemu/bin/ppc/qemu-system-ppc --version
QEMU emulator version 8.0.90 
(v8.1.0-rc0-dirty)
Copyright (c2003-2023 Fabrice Bellard and the QEMU Project developers


Note: I have two different directories with two different qemu source clones (one patched, one not) because I'm being lazy with git!

Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Quite a regular
Quite a regular


See User information
@white
That's some version compiled from some git repository with additional patches, definitely not 8.0.3. You should be on qemu git master or wait for 8.1-rc0 that's already tagged and should be available shortly on QEMU download page too.

Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Just can't stay away
Just can't stay away


See User information
@whiteQuote:
white wrote:@balaton

--version gives me this:
qemu-system-ppc --version
QEMU emulator version 8.0.50 (v8.0.0-2725-g887cba855b-dirty)
Copyright (c) 2003-2023 Fabrice Bellard and the QEMU Project developers


You should compile from the Qemu git master source, there have been many changes within Qemu. You can read it above post #983 there were also some optimizations.

This is the source I used:

https://gitlab.com/qemu-project/qemu/-/tree/master

MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Just can't stay away
Just can't stay away


See User information
@MartinW

I usually do this:
https://www.qemu.org/download/

git clone https://gitlab.com/qemu-project/qemu.git
cd qemu
git submodule init
git submodule update --recursive
./configure (parameters)
sudo make install -j16

Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Quite a regular
Quite a regular


See User information
@MartinW
That's probably bcause BBoot should also set interrupt if it's 0xff but don't know why that happens as all other cases I've seen it was 0 but maybe it's related to pass through? If you get the numbers with bboot under pegasos2.rom we can compare what the firmware does vs. what BBoot does. If BBoot changes anything it will log it so you'd see Added assigned-addresses if the property was modified or ! new value on the right if the PCI config reg was written or set interrupt x if the interrupt was changed. I hope you've read the comment in brd_pegasos2.c referred in the README about how to read these numbers but it's possible I could not explain that clearly.

Go to top

  Register To Post
« 1 ... 47 48 49 (50) 51 52 53 ... 78 »

 




Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )



Polls
Running AmigaOS 4 on?
AmigaOne SE/XE or microA1
Pegasos2
X5000
X1000
A1222
Sam 440/460
Classic PowerPC Amiga
WinUAE emulation
Qemu emulation
Total Votes: 199
The poll will close at 2025/12/1 12:00
4 Comments


Powered by XOOPS 2.0 © 2001-2024 The XOOPS Project