Device Tree Blob for Beaglebone Black?

[Vijay Kumar Banerjee]

On Mon, Feb 24, 2020 at 8:16 PM Alan Cudmore <alan.cudmore at gmail.com> wrote:

> Hi Vijay,
> My uEnv.txt was very similar, but I did not have the "fdt addr
> 0x88000000" command. But that did not seem to help. I still get a
> fatal exception when trying to run the usb01 and ping01 programs.
>
> Do you think the u-boot version matters?
> I am using the following:
> - MLO and u-boot.img from a buildroot linux build. ( u-boot 2018.1)
>
I don't think it's making much difference. I'm currently running u-boot
2018.11

> - RTEMS kernel master from about a week ago ( samples like unlimited
> and ticker work )
> - rtems-libbsd 5-freebsd-12 branch
>
I haven't tested with 5-freebsd-12 branch but it runs fine on master
branch.

> - The am335x-boneblack.dtb compiled from the suggested commit from the
> FreeBSD github repository.
>
> This one is fine.

> I don't have a debugger, so I looked up the PC address from the register
> dump.
> For the ping01 sample the PC indicates that it is in the fdt_ro_probe_
> function.
> For the usb01, it seems to crash in an termios program.
>
> ## Transferring control to RTEMS (at address 80000000) ...
>
> RTEMS Beagleboard: am335x-based
>         ARM Debug: 0x4b141000
> *** LIBBSD PING 1 TEST ***
>
> *** FATAL ***
> fatal source: 9 (RTEMS_FATAL_SOURCE_EXCEPTION)
>
> R0   = 0x00000000 R8  = 0x00000000
> R1   = 0x0000feed R9  = 0x00000000
> R2   = 0x00000007 R10 = 0x00000064
> R3   = 0x006e6573 R11 = 0x802520a0
> R4   = 0x00000007 R12 = 0x01010101
> R5   = 0xfffffff7 SP  = 0x8027589c
> R6   = 0x80150dac LR  = 0x8011b1d0
> R7   = 0x00000000 PC  = 0x8011a11c
> CPSR = 0x00000113 VEC = 0x00000004
> RTEMS version: 5.0.0.588646279951ff696f3893a4c2e79aa1ba67fccf
> RTEMS tools: 7.5.0 20191114 (RTEMS 5, RSB 5 (57011908b007), Newlib
> d14714c69)
> executing thread ID: 0x08a010001
> executing thread name: UI1
>
> One more question:
> I am converting the images using the following commands:
> arm-rtems5-objcopy $1.exe -O binary $1.bin
> gzip -9 $1.bin
> mkimage -A arm -O rtems -T kernel -a 0x80000000 -e 0x80000000 -n RTEMS
> -d $1.bin.gz $1-app.img
>
> Mine is similar with a slight change in OS option:

arm-rtems5-objcopy $executable -O binary $TMPDIR/${base}.bin
gzip -9 $TMPDIR/${base}.bin
mkimage -A arm -O linux -T kernel -a 0x80000000 -e 0x80000000 -n RTEMS -d
$TMPDIR/${base}.bin.gz $TMPDIR/$app

Are the 0x8000.0000 addresses correct in the mkimage command? It seems
> that the RTEMS executable considers the start of RAM to be 0x8000.0000
>
> Yes, the start address is correct.

> It might be good to have an image I can try.
>
> I'll send that to you offlist shortly :)

> Thanks for the help!
> Alan
>
> On Mon, Feb 24, 2020 at 12:57 AM Vijay Kumar Banerjee
> <vijaykumar9597 at gmail.com> wrote:
> >
> >
> >
> > On Sun, Feb 23, 2020 at 11:46 PM Alan Cudmore <alan.cudmore at gmail.com>
> wrote:
> >>
> >> Hi Christian,
> >> Thanks for the quick response. I followed the instructions in the
> >> docs.rtems.org manual and generated the dtb from the FreeBSD commit
> >> that Vijay suggested. It still resulted in an exception in the same
> >> function.
> >>
> >> Do you know if a specific commit of rtems-libbsd is required to work
> >> with that dtb?
> >> I tried master, and then the "5-freebsd-12" branch.
> >>
> >> Thanks,
> >> Alan
> >>
> > Hi Alan,
> >
> > I checked with the usb01 and ping01 tests running on libbsd master
> > and the dtb from the commit mentioned by Christian. I can't reproduce
> > the error and it seems to run as expected. I'm not sure where the
> > error might be coming from. Below I'm pasting the contents of my uEnv.txt
> > If the error isn't in the uEnv, I can send you my sd card image(offlist)
> so that you
> > can try that on your board and that might give some hint on what was
> going
> > wrong.
> >
> > ```
> > setenv bootdelay 5
> > uenvcmd=run boot
> > boot=fatload mmc 0 0x80800000 rtems-app.img ; fatload mmc 0 0x88000000
> am335x-boneblack.dtb ; fdt addr 0x88000000; bootm 0x80800000 - 0x88000000
> > ```
> >
> > Best regards,
> > Vijay
> >>
> >> On Sun, Feb 23, 2020 at 11:32 AM Christian Mauderer <list at c-mauderer.de>
> wrote:
> >> >
> >> > On 23/02/2020 17:07, Alan Cudmore wrote:
> >> > > I have been trying to bring up RTEMS with rtems-libbsd on the
> >> > > beaglebone black (latest master).
> >> > >
> >> > > I can run the regular RTEMS samples on the board, and a couple of
> the
> >> > > rtems-libbsd testsuite examples run as well.
> >> > >
> >> > > The samples such as ping01 and usb01 get a fatal exception in the
> >> > > function fdt_ro_probe_ , leading me to believe that maybe I am not
> >> > > using the correct device tree blob.
> >> > >
> >> > > I'm using the instructions here:
> >> > > https://git.rtems.org/rtems-docs/tree/user/bsps/arm/beagle.rst
> >> > >
> >> > > And I have am loading am335x-boneblack.dtb that I copied from a
> linux
> >> > > u-boot build. The instructions talk about getting the one from the
> >> > > FreeBSD repository, but there are many other files included in that
> >> > > dts source.
> >> > >
> >> > > What dtb is normally used for the Beaglebone black RTEMS libbsd
> testing?
> >> > >
> >> > > Is the dtb needed for the non-libbsd BSP?
> >> > >
> >> > > Also, is the ethernet supported on the RTEMS beagle BSP, or do I
> need
> >> > > libbsd to get ethernet?
> >> > >
> >> > > Thanks,
> >> > > Alan
> >> >
> >> > Hello Alan,
> >> >
> >> > I recommend to use the FreeBSD device trees. libbsd is FreeBSD based
> and
> >> > therefore works best with them. Normally I would suggest to use the
> >> > version matching the FreeBSD commit used in libbsd. But unfortunately
> in
> >> > the last commit that doesn't seem to work. Vijay had some problems
> with
> >> > it and noted that the version from FreeBSD commit
> >> > 19a6ceb89dbacf74697d493e48c388767126d418 works fine.
> >> >
> >> > Regarding Ethernet support: As far as I know there is no support for
> the
> >> > legacy stack. But the one in libbsd worked fine the last time I tested
> >> > it (which was when I ported it). If you really want to use the legacy
> >> > stack please note that it is still an IPv4 only one and therefore it
> is
> >> > quite limited nowadays.
> >> >
> >> > Best regards
> >> >
> >> > Christian
> >> _______________________________________________
> >> devel mailing list
> >> devel at rtems.org
> >> http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200224/663eb2f6/attachment-0001.html>