Re: 64-bit userspace root file system for hppa64

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


On 12/8/23 15: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
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
and booting like this:

./qemu-system-hppa -drive file=../qemu-images/,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/,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.

Larger than 64k transfers are supposedly enabled by setting bit 6 of CNTLREG2.
As fas as I can see, the qemu driver does not check if the bit is set and always
supports large transfers. Unless I am missing something, the linux driver limits
DMA transfer length to 64k, so it is at least questionable if larger transfers
have ever been tested.


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

  Powered by Linux