On Thu, Sep 26, 2019 at 10:32 PM BALATON Zoltan <bala...@eik.bme.hu> 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.
