Hi, All,
I found root cause of this issue and just fixed.
Please see https://github.com/apache/incubator-nuttx/pull/303
Regards,
Masayuki
On 2020/02/18 21:03, "Petro Karashchenko" <petro.karashche...@gmail.com> wrote:
Hello Merlin,
Please send me compiler/toolchain version that you are using.
Also please attach produced binary and map file.
I will try to reproduce your case locally.
Some time ago when I was bringing up BBB I had similar issue, but at that
point I considered it a compiler bug, because switching to -O0 "cured" the
case and after I upgraded compiler I have never met this issue again.
Regards,
Petro
вт, 18 лют. 2020 о 01:40 Ishikawa, Masayuki (SHES) <
masayuki.ishik...@sony.com> пише:
> Hi,
>
> > arm_dataabort: Data abort. PC: 8a010e64 DFAR: 8a019b04 DFSR: 00000001
>
> According to the Arm Technical Reference Manual, DFSR: 00000001 means that
> alignment fault happened at PC:8a010e64 when accessing data at DFAR:
> 8a019b04.
>
>
>
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0464d/BABFFDFD.html
>
> You can find the code with the following commands.
> NOTE: you need to add CONFIG_DEBUG_SYMBOLS=y to defconfig
>
> $ arm-none-eabi-addr2line -afp -e nuttx 8a010e64
> $ arm-none-eabi-objdump -S nuttx | grep 8a010e64
>
> I think 8a019b04 is already aligned in 4bytes, so perhaps 8bytes access
> happened.
>
> On 2020/02/17 15:14, "Merlin Hansen" <heymerlinhan...@gmail.com> wrote:
>
> Hi,
>
> I'm new to NuttX and BBBW, any assistance would be appreciated.
>
> I followed Alan Assis' blog post on how to get NuttX running on the
> BeagBone Black board. I have the wireless version but I don't know if
> that
> is causing my issue.
>
>
https://acassis.wordpress.com/2019/01/09/compiling-nuttx-to-beagleboneblack/
>
> The first think I noticed is that my nuttx.bin file is about 1/2 the
> size
> of Alan's. In looking at the configuration, I only checked/changed
> what
> the tutorial suggested and there really is not much else configured by
> default. When I load and launch the code I get an immediate assert
> error
> due to a seg fault.
>
> U-Boot SPL 2017.05-rc1-00002-g35aecb22fe (Apr 05 2017 - 16:51:58)
> Trying to boot from MMC2
>
>
> U-Boot 2017.05-rc1-00002-g35aecb22fe (Apr 05 2017 - 16:51:58 -0500),
> Build:
> jenkins-github_Bootloader
> -Builder-541
>
> CPU : AM335X-GP rev 2.1
> I2C: ready
> DRAM: 512 MiB
> Reset Source: Global warm SW reset has occurred.
> Reset Source: Power-on reset has occurred.
> MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
> Using default environment
>
> <ethaddr> not set. Validating first E-fuse MAC
> BeagleBone Black:
> Model: BeagleBoard.org BeagleBone Black Wireless:
> BeagleBone: cape eeprom: i2c_probe: 0x54:
> BeagleBone: cape eeprom: i2c_probe: 0x55:
> BeagleBone: cape eeprom: i2c_probe: 0x56:
> BeagleBone: cape eeprom: i2c_probe: 0x57:
> Net: eth0: MII MODE
> Could not get PHY for cpsw: addr 0
> cpsw
> Press SPACE to abort autoboot in 2 seconds
> => load mmc 0 0x8a000000 nuttx.bin
> reading nuttx.bin
> 97000 bytes read in 11 ms (8.4 MiB/s)
> => go 0x8A000000
> ## Starting application at 0x8A000000 ...
> arm_dataabort: Data abort. PC: 8a010e64 DFAR: 8a019b04 DFSR: 00000001
> up_assert: Assertion failed at file:armv7-a/arm_dataabort.c line: 175
> task:
> Idle Task
> up_registerdump: R0: 8a01792d 8a019b68 00000000 fffffffe 00000000
> 00000000
> 8a019b30 00000000
> up_registerdump: R8: 00000000 9df2ded8 9ffa12e8 00000000 016e3664
> 8a019b04
> 8a010ca0 8a010e64
> up_registerdump: CPSR: 60000113
> up_dumpstate: Current sp: 8a0199f8
> up_dumpstate: Interrupt stack:
> up_dumpstate: base: 8a0182ec
> up_dumpstate: size: 00000800
> up_dumpstate: User stack:
> up_dumpstate: base: 8a019b94
> up_dumpstate: size: 00000400
> up_dumpstate: ERROR: Stack pointer is not within the interrupt stack
> up_stackdump: 8a017ae0: 00000001 0000003f 05445101 08082882 00000000
> 00000000 00000000 00000000
>
> I downloaded the latest from bitbucket... version 8.2.
>
> I have not done much to troubleshoot this as I am, admittedly, a
little
> lost. I did take a quick look at the code to get an idea where it was
> seg
> faulting but it is not something obvious to me.
>
> I'm currently assisting one of my faculty in evaluating the BBBW and
> NuttX
> to be used in a RTOS course he is teaching. The idea is that if we
> can get
> NuttX up and running on the BBBW then we can proceed with purchasing
> enough
> boards for the class.
>
> Any assistance on determining if this is something I can correct would
> be
> very much appreciated.
>
> Cheers,
> Merlin.
>
>
>
