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

[BALATON Zoltan]

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?)

Regards,
BALATON Zoltan