Device Tree Blob for Beaglebone Black?

Mon Feb 24 18:43:06 UTC 2020

It looks like the mkimage command difference fixed the crash.

The original BSP README:
https://git.rtems.org/rtems/tree/bsps/arm/beagle/README
$ mkimage -A arm -O rtems -T kernel -a 0x80000000 -e 0x80000000 -n
RTEMS -d $exe.bin.gz rtems-app.img

The docs.rtems.org beagle BSP readme:
https://git.rtems.org/rtems-docs/tree/user/bsps/arm/beagle.rst
mkimage -A arm -O linux -T kernel -a 0x80000000 -e 0x80000000 -n RTEMS
-d app.bin.gz rtems-app.img

Thanks for the help! Next is trying to get the ethernet to communicate
with a host!

Alan

On Mon, Feb 24, 2020 at 12:08 PM Vijay Kumar Banerjee
<vijaykumar9597 at gmail.com> wrote:
>
>
>
>
> 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