Re: Oselas 2018.12.0 toolchain seems to break barebox for AM335x

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

Good day, everyone.

*bump*

On 2019-10-25 10:48 a.m., Andreas Geisenhainer wrote:
> 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. :)

Was anyone able find something regarding this?

Do some crazy ideas exist anywhere?

kind regards,
Andreas Geisenhainer

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