Re: 64-bit userspace root file system for hppa64

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Linux SoC]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux