| Message ID | 20190926173428.10713-1-f4bug@amsat.org |
|---|---|
| Headers | show |
| Series | hw/arm/raspi: Improve Raspberry Pi 2/3 reliability | expand |
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
On Thu, Sep 26, 2019 at 10:32 PM BALATON Zoltan <balaton@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.
On Thu, 26 Sep 2019 at 18:34, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote: > > Hi, > > I previously posted a RFC for the Raspberry Pi 4: > https://www.mail-archive.com/qemu-devel@nongnu.org/msg642241.html > and got it almost working (boots Linux kernel to userland, sadly > I'm still having timeout issues with the eMMC block). > However since it is quite usable, I started to clean up to post > the series and realized it is way too big for Peter Maydell, so > I'm following his rule of thumb by splitting in 3 sets of ~20 > functional patches. > Philippe Mathieu-Daudé (19): > hw/arm/raspi: Use the IEC binary prefix definitions > hw/arm/bcm2835_peripherals: Improve logging > hw/arm/bcm2835_peripherals: Name various address spaces > hw/arm/bcm2835: Rename some definitions > hw/arm/bcm2835: Add various unimplemented peripherals > hw/char/bcm2835_aux: Add trace events > hw/misc/bcm2835_mbox: Add trace events > hw/misc/bcm2835_thermal: Add a dummy BCM2835 thermal sensor > hw/arm/bcm2835_peripherals: Use the thermal sensor block > hw/timer/bcm2835: Add the BCM2835 SYS_timer > hw/arm/bcm2835_peripherals: Use the SYS_timer > hw/arm/bcm2835_peripherals: Add Clock/Power/Reset Manager blocks > hw/arm/raspi: Define various blocks base addresses > python/qemu/machine: Allow to use other serial consoles than default > tests/boot_linux_console: Extract the gunzip() helper > tests/boot_linux_console: Add a test for the Raspberry Pi 2 > tests/boot_linux_console: Test the raspi2 UART1 (16550 based) > tests/boot_linux_console: Boot Linux and run few commands on raspi3 > tests/boot_linux_console: Test SDHCI and termal sensor on raspi3 From this patchset, I'm going to apply patches 1-5 and 7 to target-arm.next, since they're good cleanups that have been reviewed. I've given a few review comments on some of the others but mostly it seems to have been reviewed by others already (so thanks to those reviewers). -- PMM
On 10/14/19 5:45 PM, Peter Maydell wrote: > On Thu, 26 Sep 2019 at 18:34, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote: >> >> Hi, >> >> I previously posted a RFC for the Raspberry Pi 4: >> https://www.mail-archive.com/qemu-devel@nongnu.org/msg642241.html >> and got it almost working (boots Linux kernel to userland, sadly >> I'm still having timeout issues with the eMMC block). >> However since it is quite usable, I started to clean up to post >> the series and realized it is way too big for Peter Maydell, so >> I'm following his rule of thumb by splitting in 3 sets of ~20 >> functional patches. > >> Philippe Mathieu-Daudé (19): >> hw/arm/raspi: Use the IEC binary prefix definitions >> hw/arm/bcm2835_peripherals: Improve logging >> hw/arm/bcm2835_peripherals: Name various address spaces >> hw/arm/bcm2835: Rename some definitions >> hw/arm/bcm2835: Add various unimplemented peripherals >> hw/char/bcm2835_aux: Add trace events >> hw/misc/bcm2835_mbox: Add trace events >> hw/misc/bcm2835_thermal: Add a dummy BCM2835 thermal sensor >> hw/arm/bcm2835_peripherals: Use the thermal sensor block >> hw/timer/bcm2835: Add the BCM2835 SYS_timer >> hw/arm/bcm2835_peripherals: Use the SYS_timer >> hw/arm/bcm2835_peripherals: Add Clock/Power/Reset Manager blocks >> hw/arm/raspi: Define various blocks base addresses >> python/qemu/machine: Allow to use other serial consoles than default >> tests/boot_linux_console: Extract the gunzip() helper >> tests/boot_linux_console: Add a test for the Raspberry Pi 2 >> tests/boot_linux_console: Test the raspi2 UART1 (16550 based) >> tests/boot_linux_console: Boot Linux and run few commands on raspi3 >> tests/boot_linux_console: Test SDHCI and termal sensor on raspi3 > > From this patchset, I'm going to apply patches 1-5 and 7 > to target-arm.next, since they're good cleanups that have > been reviewed. I've given a few review comments on > some of the others but mostly it seems to have been reviewed > by others already (so thanks to those reviewers). OK, thanks!
On 9/26/19 7:34 PM, Philippe Mathieu-Daudé wrote: > Hi, > > I previously posted a RFC for the Raspberry Pi 4: > https://www.mail-archive.com/qemu-devel@nongnu.org/msg642241.html > and got it almost working (boots Linux kernel to userland, sadly > I'm still having timeout issues with the eMMC block). > However since it is quite usable, I started to clean up to post > the series and realized it is way too big for Peter Maydell, so > I'm following his rule of thumb by splitting in 3 sets of ~20 > functional patches. > > In this first series, we pay old debts with these models. Linux > evolved and recent kernels were barely usable. U-boot now ticks, > Linux stops to Oops every so and then. We can use more than one > console at a time (think pppd?). > > Then we add various tests to confirm our effort made sense, and > to avoid regressions. > > Laurent, Cheng, do you mind testing on U-Boot? Great, thanks a lot Phil! We've managed to run u-boot with serial output and switch to the kernel read from the same sd card image we use on real hardware. It also requires the small hack to make qemu simulate the early boot sequence from the rpi firmware, following the explanations of Peter: mkimage -A arm -T kernel -C none -O linux -a 0x800 -e 0x800 -d u-boot.bin u-boot.img qemu ... -kernel u-boot.img ... After that, we are getting kernel panics at the point where our initramfs' init get executed. We are not yet sure about the exact reason, but that's still a great improvement. Laurent > In the next part we'll improve/update the MBox/Properties and the > interrupt controller blocks. > > Finally the last part adds the raspi4. > > Please review. > > Regards, > > Phil. >