I tested this on Qemu-10 peg2 U3 with bboot and VirtualSCSIDevice v53.8 Just to be sure, I’ve now also checked Qemu-9 A1 U3 with -bios u-boot-amigaone.bin (not bboot) The system disk is not located on VirtualSCSIDevice. Test 1: Create qemu-img create test.img 100M. Attach it to -device virtio-scsi-pci. After the system has booted, open the ‘Media Toolbox’ VirtualSCSIDevice 1.8 - works correctly. VirtualSCSIDevice 53.8 - does not work dubmp:
54.57 (29.7.2023) AmigaOne release
Machine model: 3 (AmigaOne)
Dump of context at 0xEFFEDBA0
Trap type: DSI exception
Machine State (raw): 0x0000D030
Machine State (verbose): [ExtInt on] [User] [IAT on] [DAT on]
Instruction pointer: in module Kickstart/dos.library.kmod+0x00001D34 (0x0153BBF4)
Crashed process: ramlib.support (0x6FDD8AB0)
DSI verbose error description: Access not found in hash or BAT (page fault)
Access was a store operation
0: 000000FE 6C9D0BC0 6FD34000 6A96E770 EEF6E780 6A8AEB80 00000000 EEF6E780
8: 08AA5530 6A96E770 01DD68E2 00000000 FFFFFFFF 00000000 01C56200 6AD464F0
16: 80001967 80001968 01550C44 00000000 53465300 6A8AEB80 00000074 00000001
24: 00000001 0000003F 00000000 00000012 FFFFFFFF 00000000 6FFAB180 6C792180
CR: 24022824 XER: 00000000 CTR: 014348AC LR: 0153BEC4
DSISR: 42000000 DAR: EEF6E780
Test 2: Use the pre-configured test.img (initialised with ‘Install...’, must contain a partition, does not need to be formatted) VirtualSCSIDevice 1.8 – works correctly. VirtualSCSIDevice 53.8 – works correctly.
I do not have the VirtualSCSIDevice version (virtioscsi.device.debug) – it is not included in the lha package.
As a side note, but is this confusing 53.8 naming are good thing for our 3d party stuff ? Isn't 1.8 ,etc are better ? I mean, why we need this 53.x there , like its component of the OS ?:)
It looks like there is a partition RDB entry for SFS on the test.img file, or at least thats what this bit of the log says.
Was this a new image file or was it previously setup as SFS in media toolbox? - If it was setup in media toolbox, what blocksize did you use? was the partition the complete image file? What version of SFS are you using? Is it crashing as soon as Media Toolbox loads, or can you select any options (virtioscsi.device, 'Install', ...) ?
I cant currently replicate the crash, so this extra information will help lots.
No real reason other than I was under a false impression that this needed to be a certain version number to work with mounter, so thats why only this driver has a v53 version number.
@derfs Qemu-9 A1 U3 – this is a clean system. Nothing from ES was installed on it. I haven’t installed anything on this system apart from Virtio9PFS-beta, VirtualSCSIDevice 53.8 and system updates to U3. The network isn’t even configured. The system disk HD.img, which I use with bus=ide.0, has an SFS file system Command line:
I’ll show you this visually – it’ll be easier to see if you don’t have access right now and can’t check it properly. Here’s the full TEST1 run, as you might be interested in one more error I create an image: qemu-img create test.img 100M I run QEMU from my command line as specified. After the system boots, I launch ‘Media Toolbox’ – the first crash occurs screen - > https://ibb.co/8nDxBzrz I select in ‘Media Toolbox’ -> ‘virtioscsi.device’ – the second crash occurs. The ‘Media Toolbox’ programme stops responding. screen -> https://ibb.co/qY2tTH9P
The problem also occurs if I remove the entry in SYS:Kickstart/diskboot.config ‘virtioscsi.device 8 3’
@derfs Replying post #60 in previous page. In QEMU the MV64361 and Articia are both emulated and don't emulate any of the floating buffer or transparency mentioned in the explanation so if that comes from an AI it's BS. It looks more likely something else is wrong. Maybe it just does not look for memory BARs at the right address as the PCI memory windows might be at different addresses on the two machines but if it found the config registers and the IO BAR it should also be able to look up the memory BAR. Maybe AmigaOS does not map these by default and BBoot or the A1 firmware did not do that either so maybe something needs to do that? Can you compare "info pci" and "info mtree" output on the two machines to see if the BAR needed is mapped and where? I think I've asked those outputs before but did not see an answer.
Maybe it just does not look for memory BARs at the right address as the PCI memory windows might be at different addresses on the two machines but if it found the config registers and the IO BAR it should also be able to look up the memory BAR. Maybe AmigaOS does not map these by default and BBoot or the A1 firmware did not do that either so maybe something needs to do that?
AFAIK the driver by using the expansion.library pci and pci_device functions, for example IPCI->AllocResource(). Check the pci/-background- and other PCI related parts in https://wiki.amigaos.net/amiga/autodocs/expansion.doc.txt
Always use the expansion.library PCI functions for everything, config as well as I/O accesses, which will handle endian conversion automatically where required as well as any possible differences on different hardware, don't try to do re-implement it yourself based on some PCI device config register contents.
No idea about QEmu VirtIO, but like accessing a VIA686B device on the A1 you might have to use pci_device/Lock() with PCI_LOCK_SHARED instead of PCI_LOCK_EXCLUSIVE mode in case all VirtIO uses the same, shared device function.
Looks like the high 32-bits of 64-bit BARs are not being zero'd out on AmigaOne so the addresses being accessed were out of range.
AmigaOne PCI mtree
Bus 0, device 11, function 0:
SCSI controller: PCI device 1af4:1004
PCI subsystem 1af4:0008
IRQ 7, pin A
BAR0: I/O at 0x800500 [0x80053f]
BAR4: 64 bit prefetchable memory at 0xffffffff84204000 [0xffffffff84207fff]
id "scsi0"
@derfs Just a cosmetic change, but _start() in a kickstart module, .library or .device not meant to be executed in a shell should return RETURN_FAIL instead of 0, and print some error message using IDOS->PrintFault() or IDOS->Printf(), or at least IExec->DebugPrintF() if you don't want to add the required code for opening dos.library, why it can't be executed in a shell.
@derfs I’ve tested the new version v53.8 virtioscsi.device.debug – works virtioscsi.device – doesn’t work; same issue as described earlier
Since virtioscsi.device.debug works, I’ve now tested further. I’ve got a small issue on PEG2 with bboot. It works on A1 with the firmware. I checked earlier on A1 with boot and it worked too. PEG2 installed from scratch. It only works for DH2 FFS. When connecting images from SFS/SFS2/JXFS, the system does not boot. The DH0 drive has an SFS file system.
[DOS] Bootnode from expansion->mountlist is device name "DH0"
[DOS] "Initial CLI" process started, doslib creation task now ending.
[virtioscsi:Open.c] Open unit 0 requested (flags 0)
[virtioscsi:unit_task.c] UnitTask_Entry: unit 0 started
[virtioscsi:unit_task.c] preallocate_unit_dma: unit 0 16 slots ready
[virtioscsi:unit_task.c] UnitTask_Start: unit 0 task ready
[virtioscsi:BeginIO.c] BeginIO [DH2/SmartFilesystem 1.290 ]: T0 L0 Cmd 22 (TD_GETGEOMETRY) Off 0x00000000 Data 0x6CB8FDF4 Len 32 Flags 0x01 G:1
[virtioscsi:BeginIO.c] Queuing cmd 22 to unit task port
[virtioscsi:scsi_cdb_helpers.c] ensure_geometry_cached: unit=0x6FFB0700 valid=1 (skip)
[virtioscsi] TD_GETGEOMETRY: SectorSize=512 TotalSectors=204800 C=3200 H=4 S=16 CylSectors=64 DevType=0 Flags=0
[virtioscsi:Open.c] Open unit 0 requested (flags 0)
[virtioscsi:Open.c] Open unit 0 requested (flags 0)
[virtioscsi:Close.c] Close called for unit ptr 0x6FFB0700, open_count 3
[virtioscsi:Close.c] Close called for unit ptr 0x6FFB0700, open_count 2
--
[DOS] Bootnode from expansion->mountlist is device name "DH0"
[DOS] "Initial CLI" process started, doslib creation task now ending.
[virtioscsi:Open.c] Open unit 0 requested (flags 0)
[virtioscsi:unit_task.c] UnitTask_Entry: unit 0 started
[virtioscsi:unit_task.c] preallocate_unit_dma: unit 0 16 slots ready
[virtioscsi:unit_task.c] UnitTask_Start: unit 0 task ready
[virtioscsi:BeginIO.c] BeginIO [DH2/SmartFilesystem 1.293 ]: T0 L0 Cmd 22 (TD_GETGEOMETRY) Off 0x00000000 Data 0x6CB96DF4 Len 32 Flags 0x01 G:1
[virtioscsi:BeginIO.c] Queuing cmd 22 to unit task port
[virtioscsi:scsi_cdb_helpers.c] ensure_geometry_cached: unit=0x6FFB4700 valid=1 (skip)
[virtioscsi] TD_GETGEOMETRY: SectorSize=512 TotalSectors=204800 C=3200 H=4 S=16 CylSectors=64 DevType=0 Flags=0
[virtioscsi:Open.c] Open unit 0 requested (flags 0)
[virtioscsi:Open.c] Open unit 0 requested (flags 0)
[virtioscsi:Close.c] Close called for unit ptr 0x6FFB4700, open_count 3
[virtioscsi:Close.c] Close called for unit ptr 0x6FFB4700, open_count 2
--
[DOS] Bootnode from expansion->mountlist is device name "DH0"
[DOS] "Initial CLI" process started, doslib creation task now ending.
[virtioscsi:Open.c] Open unit 0 requested (flags 0)
[virtioscsi:unit_task.c] UnitTask_Entry: unit 0 started
[virtioscsi:unit_task.c] preallocate_unit_dma: unit 0 16 slots ready
[virtioscsi:unit_task.c] UnitTask_Start: unit 0 task ready
[virtioscsi:BeginIO.c] BeginIO [DH1]: T0 L0 Cmd 22 (TD_GETGEOMETRY) Off 0x00000000 Data 0x6CB96D24 Len 32 Flags 0x01 G:1
[virtioscsi:BeginIO.c] Queuing cmd 22 to unit task port
[virtioscsi:scsi_cdb_helpers.c] ensure_geometry_cached: unit=0x6FFB4700 valid=1 (skip)
[virtioscsi] TD_GETGEOMETRY: SectorSize=512 TotalSectors=204800 C=3200 H=4 S=16 CylSectors=64 DevType=0 Flags=0
[virtioscsi:Open.c] Open unit 0 requested (flags 0)
[virtioscsi:Open.c] Open unit 0 requested (flags 0)
[virtioscsi:Close.c] Close called for unit ptr 0x6FFB4700, open_count 3
[virtioscsi:Close.c] Close called for unit ptr 0x6FFB4700, open_count 2
A quick test of the QEMU PEG2 boot firmware (FFS) using virtio-scsi-pci as the system drive:
The PEG2 firmware obviously does not recognise virtio-scsi-pci. For the system drive on virtio-scsi-pci to be recognised, you need to boot the system from a small disk, e.g. a 100MB ‘test.img’, by signing it on a bus recognised by the firmware. (-device ide-hd,drive=rdb,bus=ide.0). This is where amigaboot.of and the Kickstart directory are located. The partitions on the disk images are formatted as FFS.
Why is that? MMIO should work with amigaone too. Isn't it just a memory mapped BAR that should show up in the PCI window? Or does it need something else that pegasos2 has and amigaone lacks?
Theoretically, this has nothing to do with the Virtio SCSI driver I checked out the new patches from @derfs for VirtualSCSIDevice “v1.9: modern MMIO on AmigaOne” I updated Bar 0 to his developer version of AmigaNVMeDevice, and it works on QEMU A1! Yippee! I have NVMe for A1. Even @geennaam’s NVMe driver doesn’t work on A1. @derfs’s does I don’t use a1ide at all and boot the system with bboot without it. Thanks for the help
PS @derfs will definitely fix this, he just hasn't had the time. I had a moment and checked it out. I'm tempted to test this on a QEMU x86_64 machine with PCI passthrough nvme.
@derfs v1.10 A1: With the SFS system disk connected to ‘device scsi-hd’ and bboot, and with ‘-bios u-boot-amigaone.bin’ – it works. PEG2: SFS system drive connected to ‘device scsi-hd’ and ‘-bios pegasos2.rom’ works (PEG2 boots from the small drive on ‘ide.0’ where amigaboot.of and kickstart are located) – works. I’ll check other configurations/variations this evening. If there are any issues, I’ll let you know.
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
