Re: Oselas 2018.12.0 toolchain seems to break barebox for AM335x

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/barebox




[Index of Archives]     [Linux Embedded]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux