On 08/12/2023 20:32, Guenter Roeck wrote:
On 12/8/23 11: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?
It might make sense to try booting from some other controller. I tried
various usb variants as well as nvme, sata-cmd646, and sdhci (mmc).
This would help identifying if the problem has to do with your ext4 image.
I am not saying that the ext4 image is bad, but it might trigger something
that the emulation doesn't like.
I've also had cases working on the ESP series whereby an error would corrupt the
underlying disk image, and then I'd roll back to an earlier commit and wonder why
things had stopped working again. Restoring the working image from a backup made
things start to function as expected.
For testing in QEMU I highly recommend using a qcow2 image with the -snapshot option
so that the original image remains untouched regardless of any bugs in the emulation.
ATB,
Mark.
