Re: Oselas 2018.12.0 toolchain seems to break barebox for AM335x

[Andreas Geisenhainer <Andreas.Geisenhainer@atsonline.de>]

[-- Attachment #1: Type: text/plain, Size: 2123 bytes --]

Hello Sascha, hello barebox-ml.

 > On 2019-07-10 9:58 a.m., Sascha Hauer wrote:
 >> On Mon, Jul 08, 2019 at 04:15:00PM +0200, Andreas Geisenhainer wrote:
 >>> We're running barebox an a Phytec PhyCORE AM335x platform, and the
 >>> behaviour does emerge for the default
 >>> "barebox-am335x-phytec-phycore.img"
 >>> image from barebox.
 >> I just tried to reproduce this on a beaglebone black as this is at least
 >> the same SoC. Unfortunately I was not successful.

I finally found the time to reproduce this on a beaglebone black.
I tried two different barebox versions (v2018.03 and v2019.10)
without any changes to the source.

My current steps where

1) make am335x_mlo_defconfig / am335x_defconfig
	(depending on the version)
2) make
3) copied two files onto the uSD card I booted the boneblack
    from:
     - barebox-am33xx-beaglebone.img (I)
     - barebox-am33xx-phytec-phycore.img (II)
4) booted the boneblack and loaded each file manually using the
    `bootm` command.


I'm working under the following assumption:
  a) the beagleboneblack image is working for our AM335x-phycore
  b) the phytec-phycore image should work on a boneblack
      (at least rudimentary)

When I'm using the OSELAS.2018.02.0 toolchain a) und b) hold up. 
Additionally we get
   c) on the boneblack both images (I) and (II) are working

With the OSELAS.2019.09.0 toolchain, the boneblack image (I) is
working on the boneblack, but the phycore-image (II) is not.

There seem to be at least two slightly different behaviors
I've been observing:
Yesterday it justs stops working, no further output, nothing (see Part 
B) within attachment.
Two days ago it complained about a "unhandled NULL pointer dereference", 
followed by a reset of the chip (i captured that within the attachment 
at C).

One more point: I've chosen to build the toolchains for 
"arm-cortexa8-linux-gnueabihf".
To rule out problems with this decision I build a more generic 
"arm-v7a-linux-gnueabihf"
one, but the problem persists with it, too.

Is there anything more I can do on my end?
I'm open for any ideas, here. :)

with kind regards
Andreas Geisenhainer

[-- Attachment #2: barebox_observations.txt --]
[-- Type: text/plain, Size: 2484 bytes --]


###########################
# A) working barebox 2018.03.0 compiled with OSELAS_2018.02
###############

Loading ARM barebox image '/mnt/10.0.1.6/root/barebox-am33xx-phytec-phycore-no-spi.img'
exitcall-> nv_exit+0x1/0x20
exitcall-> devices_shutdown+0x1/0x28
exitcall-> arch_shutdown+0x1/0x1c


barebox 2018.03.0-gcfddd8e026db #14 Wed Oct 23 10:48:06 CEST 2019


Board: Phytec phyCORE AM335x
initcall-> globalvar_init+0x1/0x2c
initcall-> platform_init+0x1/0xc
initcall-> mdio_bus_init+0x1/0xc
initcall-> usb_bus_init+0x1/0xc
initcall-> spi_bus_init+0x1/0xc
initcall-> i2c_bus_init+0x1/0x10
initcall-> gpio_desc_alloc+0x1/0x18
initcall-> fs_bus_init+0x1/0xc
initcall-> dmtimer_init+0x1/0x30
initcall-> of_arm_init+0x1/0x2c
initcall-> unwind_init+0x1/0x24
initcall-> pcs_init+0x1/0xc
initcall-> net_init+0x1/0x64
initcall-> init_fs+0x1/0x2c
initcall-> omap_init+0x1/0x5c
initcall-> ns16550_serial_driver_register+0x1/0xc
initcall-> dos_partition_init+0x1/0xc
initcall-> am33xx_scrm_init+0x1/0xc
initcall-> mmu_init+0x1/0x1e8
[...]


###########################
# B) broken barebox 2019.10.0 compiled with OSELAS_2019.09
########
barebox@TI AM335x BeagleBone black:/mnt/mmc0.0 bootm -vv -c barebox-am33xx-phytec-phycore.img

Loading ARM barebox image 'barebox-am33xx-phytec-phycore.img'
OS image not yet relocated
Passing control to OMAP barebox handler
exitcall-> nv_exit+0x1/0x20
exitcall-> state_shutdown+0x1/0x20
exitcall-> devices_shutdown+0x1/0x24
exitcall-> arch_shutdown+0x1/0x1c

-> waits here (nothing seems to happen)


########################
# C) broken barebox 2018.03.0 compiled with OSELAS_2019.09
#########

Loading ARM barebox image '/mnt/10.0.1.6/root/barebox-am33xx-phytec-phycore-no-spi.img'
exitcall-> nv_exit+0x1/0x20
exitcall-> devices_shutdown+0x1/0x28
exitcall-> arch_shutdown+0x1/0x1c
unable to handle NULL pointer dereference at address 0x000009db
pc : [<88009d1a>]    lr : [<88009d35>]
sp : 8ffef918  ip : 00000000  fp : 00000000
r10: 00000000  r9 : 88009c21  r8 : 87fea400
r7 : 00000004  r6 : 8ffef954  r5 : 88009c18  r4 : 0000000e
r3 : 01000000  r2 : 00000003  r1 : 000009d8  r0 : 00000002
Flags: nzcv  IRQs off  FIQs on  Mode SVC_32

[<8fe52ca5>] (unwind_backtrace+0x1/0x58) from [<8fe00c11>] (panic+0x1d/0x34)
[<8fe00c11>] (panic+0x1d/0x34) from [<8fe512cd>] (do_exception+0xd/0x10)
[<8fe512cd>] (do_exception+0xd/0x10) from [<8fe5132d>] (do_data_abort+0x21/0x2c)
[<8fe5132d>] (do_data_abort+0x21/0x2c) from [<8fe50dd4>] (do_abort_6+0x48/0x54)

->reset

[-- Attachment #3: Type: text/plain, Size: 149 bytes --]

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