Aarch64 Qemu virt - crash

Aarch64 Qemu virt - crash

[Gittinger Joerg (XC-ECO/ESH2)]

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@entry=0x40c07ad0, sect=sect@entry=0, offset=offset@entry=0, cmd=cmd@entry=240) at drivers/mtd/nor/cfi_flash.c:837
#3  0x000000004100d940 in flash_detect_width (info=info@entry=0x40c07ad0, qry=qry@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@entry=0x40c07998) at drivers/base/driver.c:91
#9  0x000000004100c258 in match (drv=drv@entry=0x40c07910, dev=0x40c07998, dev@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@entry=0x4102b5d0 "cfi_flash", id=id@entry=0, resname=resname@entry=0x0, start=start@entry=0,
    size=size@entry=134217728, flags=flags@entry=512, pdata=pdata@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.

Thanks + Regards
Joerg

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: 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@entry=0x40c07ad0, sect=sect@entry=0, offset=offset@entry=0, cmd=cmd@entry=240) at drivers/mtd/nor/cfi_flash.c:837
> #3  0x000000004100d940 in flash_detect_width (info=info@entry=0x40c07ad0, qry=qry@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@entry=0x40c07998) at drivers/base/driver.c:91
> #9  0x000000004100c258 in match (drv=drv@entry=0x40c07910, dev=0x40c07998, dev@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@entry=0x4102b5d0 "cfi_flash", id=id@entry=0, resname=resname@entry=0x0, start=start@entry=0,
>     size=size@entry=134217728, flags=flags@entry=512, pdata=pdata@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


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Aarch64 Qemu virt - crash

[Ahmad Fatoum]

Hello,

On 12.03.21 11:55, 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@entry=0x40c07ad0, sect=sect@entry=0, offset=offset@entry=0, cmd=cmd@entry=240) at drivers/mtd/nor/cfi_flash.c:837
> #3  0x000000004100d940 in flash_detect_width (info=info@entry=0x40c07ad0, qry=qry@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@entry=0x40c07998) at drivers/base/driver.c:91
> #9  0x000000004100c258 in match (drv=drv@entry=0x40c07910, dev=0x40c07998, dev@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@entry=0x4102b5d0 "cfi_flash", id=id@entry=0, resname=resname@entry=0x0, start=start@entry=0,
>     size=size@entry=134217728, flags=flags@entry=512, pdata=pdata@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.

There was recent rework on this platform, please pull again. This particular
issue is worked around with
767edcc58757 ("mtd: cfi-flash: fail gracefully instead of crashing on NULL page")

The root cause is that when MMU is enabled, barebox traps NULL pointer dereference
and accessing the first page of a cfi-flash mapped at zero looks just like one.

The proper fix would be to remap the cfi-flash for this board, but no one
has come around to do this yet. An alternative if you need to pass data to barebox
is to use VirtIO Block devices. They need no further configuration than qemu command
line parameters. That's in next as well.

Cheers,
Ahmad

> 
> Thanks + Regards
> Joerg
> 
> _______________________________________________
> barebox mailing list
> barebox@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/barebox
> 

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

AW: Aarch64 Qemu virt - crash

[Gittinger Joerg (XC-ECO/ESH2)]

Hi Ahmad,

>> 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.

> There was recent rework on this platform, please pull again. This particular issue is worked around with
> 767edcc58757 ("mtd: cfi-flash: fail gracefully instead of crashing on NULL page")

Yes, cherry-picking this change solved the crash. Thanks.

> The root cause is that when MMU is enabled, barebox traps NULL pointer dereference and accessing the first page of a cfi-flash mapped at zero looks just like one.
>
> The proper fix would be to remap the cfi-flash for this board, but no one has come around to do this yet. An alternative if you need to pass data to barebox is to use 
> VirtIO Block devices. They need no further configuration than qemu command line parameters. That's in next as well.

BTW, I tried disabling MMU in config as well as Rouven suggested (thanks). But this gives me a linker error:

---------------------------------------------
...
  LD      barebox
aarch64-linux-gnu-ld: common/uimage.o: in function `zero_page_memcpy':
/home/gjt2abt/src/barebox/include/zero_page.h:47: undefined reference to `zero_page_access'
/home/gjt2abt/src/barebox/include/zero_page.h:47:(.text.uimage_sdram_flush+0xc4): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `zero_page_access'
aarch64-linux-gnu-ld: /home/gjt2abt/src/barebox/include/zero_page.h:49: undefined reference to `zero_page_faulting'
/home/gjt2abt/src/barebox/include/zero_page.h:49:(.text.uimage_sdram_flush+0xd8): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `zero_page_faulting'
aarch64-linux-gnu-ld: /home/gjt2abt/src/barebox/include/zero_page.h:47: undefined reference to `zero_page_access'
/home/gjt2abt/src/barebox/include/zero_page.h:47:(.text.file_to_sdram+0xd8): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `zero_page_access'
aarch64-linux-gnu-ld: /home/gjt2abt/src/barebox/include/zero_page.h:49: undefined reference to `zero_page_faulting'
/home/gjt2abt/src/barebox/include/zero_page.h:49:(.text.file_to_sdram+0xf0): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `zero_page_faulting'
make: *** [Makefile:915: barebox] Error 1
---------------------------------------------

Regards,
Joerg
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: AW: Aarch64 Qemu virt - crash

[Ahmad Fatoum]

Hello Joerg,

On 12.03.21 13:23, Gittinger Joerg (XC-ECO/ESH2) wrote:
> Hi Ahmad,
> 
>>> 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.
> 
>> There was recent rework on this platform, please pull again. This particular issue is worked around with
>> 767edcc58757 ("mtd: cfi-flash: fail gracefully instead of crashing on NULL page")
> 
> Yes, cherry-picking this change solved the crash. Thanks.
> 
>> The root cause is that when MMU is enabled, barebox traps NULL pointer dereference and accessing the first page of a cfi-flash mapped at zero looks just like one.
>>
>> The proper fix would be to remap the cfi-flash for this board, but no one has come around to do this yet. An alternative if you need to pass data to barebox is to use 
>> VirtIO Block devices. They need no further configuration than qemu command line parameters. That's in next as well.
> 
> BTW, I tried disabling MMU in config as well as Rouven suggested (thanks). But this gives me a linker error:

Don't cherry pick, check out next. This is also fixed there.

> 
> ---------------------------------------------
> ...
>   LD      barebox
> aarch64-linux-gnu-ld: common/uimage.o: in function `zero_page_memcpy':
> /home/gjt2abt/src/barebox/include/zero_page.h:47: undefined reference to `zero_page_access'
> /home/gjt2abt/src/barebox/include/zero_page.h:47:(.text.uimage_sdram_flush+0xc4): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `zero_page_access'
> aarch64-linux-gnu-ld: /home/gjt2abt/src/barebox/include/zero_page.h:49: undefined reference to `zero_page_faulting'
> /home/gjt2abt/src/barebox/include/zero_page.h:49:(.text.uimage_sdram_flush+0xd8): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `zero_page_faulting'
> aarch64-linux-gnu-ld: /home/gjt2abt/src/barebox/include/zero_page.h:47: undefined reference to `zero_page_access'
> /home/gjt2abt/src/barebox/include/zero_page.h:47:(.text.file_to_sdram+0xd8): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `zero_page_access'
> aarch64-linux-gnu-ld: /home/gjt2abt/src/barebox/include/zero_page.h:49: undefined reference to `zero_page_faulting'
> /home/gjt2abt/src/barebox/include/zero_page.h:49:(.text.file_to_sdram+0xf0): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `zero_page_faulting'
> make: *** [Makefile:915: barebox] Error 1
> ---------------------------------------------
> 
> Regards,
> Joerg
> 

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox