On 12/9/23 13:12, Mark Cave-Ayland wrote:
On 08/12/2023 23:36, Helge Deller wrote:
On 12/8/23 23:09, Helge Deller wrote:
On 12/8/23 22:25, Mark Cave-Ayland wrote:
On 08/12/2023 20:28, Guenter Roeck wrote:
On 12/8/23 11:55, Mark Cave-Ayland wrote:
On 08/12/2023 19:37, Helge Deller wrote:
On 12/8/23 20:26, Helge Deller wrote:
Yeah that's one of the many bugs which should be fixed by my latest
series. I've pushed the current version of my branch with the ESP
rewrite to https://github.com/mcayland/qemu/tree/esp-rework-testing
if you would both like to give it a test.
Tried it with qemu-hppa:
[ 4.257547] am53c974 0000:00:04.0: enabling SERR and PARITY (0107 -> 0147)
[ 4.917824] am53c974 0000:00:04.0: esp0: regs[(ptrval):(ptrval)] irq[70]
[ 4.918704] am53c974 0000:00:04.0: esp0: is a AM53C974, 40 MHz (ccf=0), SCSI ID 15
[ 8.010626] scsi host1: esp
[ 8.026345] scsi 1:0:0:0: Direct-Access QEMU QEMU HARDDISK 2.5+ PQ: 0 ANSI: 5
[ 8.032066] scsi target1:0:0: Beginning Domain Validation
[ 8.043254] scsi target1:0:0: Domain Validation skipping write tests
[ 8.044284] scsi target1:0:0: Ending Domain Validation
[ 8.123681] sd 1:0:0:0: Power-on or device reset occurred
[ 8.134707] sd 1:0:0:0: [sda] 209715200 512-byte logical blocks: (107 GB/100 GiB)
[ 8.140043] sd 1:0:0:0: [sda] Write Protect is off
[ 8.144759] sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 8.205316] sda: sda1 sda2 sda3 < sda5 sda6 >
[ 8.222763] sd 1:0:0:0: [sda] Attached SCSI disk
[ 8.231170] sd 1:0:0:0: Attached scsi generic sg0 type 0
...> [ 8.679666] Freeing unused kernel image (initmem) memory: 3072K
[ 8.680679] Write protected read-only-after-init data: 2k
[ 8.681338] Run /sbin/init as init process
[ 8.731576] EXT4-fs error (device sda5): ext4_lookup:1855: inode #787975: comm swapper/0: iget: checksum invalid
[ 8.736664] scsi host1: Spurious irq, sreg=10.
[ 8.760106] Starting init: /sbin/init exists but couldn't execute it (error -67)
The driver isn't so bad in general.
With my current seabios-hppa from
https://github.com/hdeller/seabios-hppa/tree/devel
and booting like this:
./qemu-system-hppa -drive file=../qemu-images/hdd.img.new,if=none,id=d0 -serial mon:stdio -smp cpus=3 -machine C3700 -nographic -snapshot -device dc390,id=scsi -device scsi-hd,bus=scsi.0,drive=d0 -bios ../seabios-hppa/out/hppa-firmware.img
it actually can *partly* boot from disc:
...
Selected kernel: /vmlinux from partition 2
Selected ramdisk: /initrd.img from partition 2
ELF64 executable
Segment 0 load 0x000e0000 size 5171564 mediaptr 0x1000
Segment 1 load 0x01a00000 size 25012 mediaptr 0x4f0000
Loading ramdisk 23869192 bytes @ 3e92a000...
Decompressing Linux... XZ-compressed data is corrupt
-- System halted
So, it can read partition table, even load some sectors, but
the data returned can be corrupt, as the "XZ-compressed data is corrupt"
message states.
This fits with the CRC checksum errors I saw when booting
from ext4 disc.
Is the dc390/esp driver functional on other big-endian machines?
Yes it is, in fact the majority of my test images were from SPARC/m68k (including a hppa image) and the series in its current form passes all my boot tests except for an x86 DOS image with ASPI.
The command line I used for testing hppa is below:
./qemu-system-hppa \
-kernel vmlinux-parisc \
-no-reboot \
-snapshot \
-device am53c974,id=scsi \
-device scsi-hd,bus=scsi.0,drive=d0 \
-drive file=rootfs.ext2-parisc,format=raw,if=none,id=d0 \
-append "panic=-1 slub_debug=FZPUA root=/dev/sda console=ttyS0,115200" \
-nographic -monitor null
If you are still seeing errors then I'd suspect an issue with the hppa CPU emulation or the esp-pci device.
I suspect it has more to do with ext4 vs. ext2 because ext2 works just fine for me
while I get unaligned access crashes with ext4. I started some tests with btrfs
and f2fs in addition to ext2 to see how those are doing.
That sounds really useful, thanks for testing.
I think there are multiple issues.
Most likely some CPU emulation bug, maybe happens in CRC checksumming.
Nevertheless, with this command:
./qemu-system-hppa -drive file=../qemu-images/hdd.img.new,if=none,id=d0 -serial mon:stdio -smp cpus=3 -machine C3700 -nographic -snapshot -device am53c974,id=scsi -device scsi-hd,bus=scsi.0,drive=d0 -bios ../seabios-hppa/out/hppa-firmware.img
I get this error:
Decompressing Linux... XZ-compressed data is corrupt
Replacing the scsi driver "am53c974" by "lsi53c895a" does boot.
At this stage no linux kernel is loaded yet, it's just the seabios-hppa
which loaded some scsi blocks into memory.
Does the esp driver has a limit of only being able to
load max. 64kb at once (per SCSI command) ?
By reducing to 64kb, booting directly from Seabios-hppa
now works for me.
From a QEMU perspective it should support a maximum 24-bit transfer size.
I fixed it now in my Seabio-hppa devel branch.
Booting from firmware now works (with your branch), but kernel
still shows crc errors, which is probably a cpu emulation bug.
Still analyzing.
Helge
