Aarch64 Qemu virt - crash

[Rouven Czerwinski]

Hi Joerg,

On Fri, 2021-03-12 at 10:55 +0000, Gittinger Joerg (XC-ECO/ESH2) wrote:
> Hi,
> 
> I'd like to check out bareboot. In the documentation I found that aarch64 QEMU virt target is supported. Therefore I wanted to build it and run it in the emulator. I checked out latest git and built it for aarch64. When running it in QEMU 
>   $ qemu-system-aarch64 -m 2G -M virt -cpu cortex-a53 -kernel ../barebox/barebox -display none -serial stdio
> I run into an exception:
> 
> -------- qemu output ---------
> barebox 2021.02.0-jg-00106-g43a513fa8 #1 Mon Mar 8 15:56:47 CET 2021
> 
> 
> Board: ARM QEMU virt64
> DABT (current EL) exception (ESR 0x9600004b) at 0x0000000000000000
> elr: 000000004100d754 lr : 000000004100d740
> x0 : 0000000000000001 x1 : 00000000000000f0
> x2 : 00000000bffefdbc x3 : 00000000ffffffff
> x4 : 0000000000000008 x5 : 0000000000000000
> x6 : 0000000040c07ad0 x7 : 0000000000000000
> x8 : 0000000040c07ad0 x9 : 00000000bffefe90
> ...
> -----------------------------------
> 
> I debugged it in gdb and set a breakpoint at the ELR value. Backtrace shows this:
> 
> -----------------------------------
> #0  flash_write8 (addr=0x0, value=240 '\360') at drivers/mtd/nor/cfi_flash.h:258
> #1  flash_write_word (addr=0x0, datum=240, info=0x40c07ad0) at drivers/mtd/nor/cfi_flash.h:336
> #2  flash_write_cmd (info=info at entry=0x40c07ad0, sect=sect at entry=0, offset=offset at entry=0, cmd=cmd at entry=240) at drivers/mtd/nor/cfi_flash.c:837
> #3  0x000000004100d940 in flash_detect_width (info=info at entry=0x40c07ad0, qry=qry at entry=0xbffefe90) at drivers/mtd/nor/cfi_flash.c:244
> #4  0x000000004100dc60 in flash_detect_cfi (qry=0xbffefe90, info=0x40c07ad0) at drivers/mtd/nor/cfi_flash.c:287
> #5  flash_detect_size (info=0x40c07ad0) at drivers/mtd/nor/cfi_flash.c:321
> #6  cfi_probe_one (num=0, info=0x40c07ad0) at drivers/mtd/nor/cfi_flash.c:972
> #7  cfi_probe (dev=0x40c07910) at drivers/mtd/nor/cfi_flash.c:1013
> #8  0x000000004100c188 in device_probe (dev=0x40c07910, dev at entry=0x40c07998) at drivers/base/driver.c:91
> #9  0x000000004100c258 in match (drv=drv at entry=0x40c07910, dev=0x40c07998, dev at entry=0x40c07910) at drivers/base/driver.c:164
> #10 0x000000004100c574 in register_device (new_device=0x40c07910) at drivers/base/driver.c:209
> #11 0x000000004100ca28 in add_generic_device (devname=devname at entry=0x4102b5d0 "cfi_flash", id=id at entry=0, resname=resname at entry=0x0, start=start at entry=0,
>     size=size at entry=134217728, flags=flags at entry=512, pdata=pdata at entry=0x0) at drivers/base/resource.c:78
> #12 0x0000000041027260 in add_cfi_flash_device (flags=0, size=134217728, start=0, id=0) at include/driver.h:267
> #13 virt_env_init () at arch/arm/boards/qemu-virt64/init.c:30
> #14 0x0000000041001610 in start_barebox () at common/startup.c:412
> #15 0x00000000410289a0 in barebox_non_pbl_start (membase=1090689334, memsize=<optimized out>, boarddata=0x41035000 <__barebox_cmd_drvinfo+8>)
>     at arch/arm/cpu/start.c:246
> #16 0x00000000410289d0 in __barebox_arm_entry ()
> -----------------------------------
> 
> Apparently the NOR cfi driver tries to figure out the flash width by writing to it. In QEMU aarch64 virt machine, the flash starts at 0x0, so the address is correct. In barebox config the "QEMU arm64 virt machine" is selected. I tried with specifying a "-pflash ..." parameter at QEMU command line but still got the same exception. MMU (SCTLR.M) is turned on - therefore I wonder why I get this exception. It seems that the MMU region for the flash is not or not correctly set up when the memory access occurs..? Or do I do something wrong? Please let me know how I get it running.
> 

qemu decided to map the flash at 0x0, which coincides with the zero
page mapping of the MMU which is created within barebox by default. I
send some patches to the list where this was (uglily) fixed([1], [2]),
but we didn't deem it worth it to have an MMU on qemu for the
workarounds. In the end MMU on qemu won't gain any speed advantage, so
for now the virt machine will only work with MMU=n.

[1]: http://lists.infradead.org/pipermail/barebox/2020-November/034509.html
[2]: http://lists.infradead.org/pipermail/barebox/2020-November/034511.html

Regards,
Rouven Czerwinski