Re: [PATCH 00/19] hw/arm/raspi: Improve Raspberry Pi 2/3 reliability

[Philippe Mathieu-Daudé]

On Thu, Sep 26, 2019 at 10:32 PM BALATON Zoltan <address@hidden> wrote:
> On Thu, 26 Sep 2019, Philippe Mathieu-Daudé wrote:
> > and got it almost working (boots Linux kernel to userland, sadly
> > I'm still having timeout issues with the eMMC block).
> [...]
> > $ make aarch64-softmmu/all check-venv
> > $ ./tests/venv/bin/avocado --show=app,console run -t machine:raspi2 -t 
> > machine:raspi3 tests/acceptance
> > JOB ID     : 10bf6593659f0b191941265c19fe3dbf1652c3e7
> > JOB LOG    : 
> > /home/phil/avocado/job-results/job-2019-09-26T19.04-10bf659/job.log
> > (1/4) 
> > tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_arm_raspi2_uart0:
> >  \console: [    0.000000] Booting Linux on physical CPU 0xf00
> > console: [    0.000000] Linux version 4.14.98-v7+ (dom@dom-XPS-13-9370) 
> > (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611)) #1200 
> > SMP Tue Feb 12 20:27:48 GMT 2019
> > console: [    0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), 
> > cr=10c5387d
> > console: [    0.000000] CPU: div instructions available: patching division 
> > code
> > console: [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT 
> > aliasing instruction cache
> > console: [    0.000000] OF: fdt: Machine model: Raspberry Pi 2 Model B
> > console: [    0.000000] earlycon: pl11 at MMIO 0x3f201000 (options '')
> > console: [    0.000000] bootconsole [pl11] enabled
> > console: [    0.000000] Memory policy: Data cache writealloc
> > console: [    0.000000] cma: Reserved 8 MiB at 0x3b800000
> > console: [    0.000000] percpu: Embedded 17 pages/cpu @baf2e000 s38720 
> > r8192 d22720 u69632
> > console: [    0.000000] Built 1 zonelists, mobility grouping on.  Total 
> > pages: 243600
> > console: [    0.000000] Kernel command line: printk.time=0 
> > earlycon=pl011,0x3f201000 console=ttyAMA0
>
> Not sure what timeouts you get related to eMMC but previously we've found
> that panic at boot due to mmcblk not ready is avoided with the "rootwait"
> kernel option which does not seem to be present in most of these tests.
> (It's also not present in images for real hardware so likely this only
> happens with QEMU but not on real hardware. Could it be that real hardware
> is slower so timing is different?)

The eMMC issue is on the raspi4.
Looking at my notes, I used "root=/dev/mmcblk0 rootwait", and it hangs with:

Waiting for root device /dev/mmcblk0...
[    0.898870] mmc-bcm2835 3f300000.mmc: mmc_debug:0 mmc_debug2:0
[    0.901397] mmc-bcm2835 3f300000.mmc: DMA channel allocated
[    0.930041] sdhost: log_buf @ (ptrval) (fac53000)
[    0.969910] mmc1: queuing unknown CIS tuple 0x80 (2 bytes)
[    0.973894] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[    0.977753] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[    0.981228] mmc0: sdhost-bcm2835 loaded - DMA enabled (>1)

So I guess now Linux improved and use new features not covered by our
hw/sd/bcm2835_sdhost.c model :(
(I have to use recent Linux kernels because older don't support the raspi4).

I'll keep you informed, thanks for the hint!

Phil.