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 <vijaykumar9...@gmail.com> wrote: > > > > > On Mon, Feb 24, 2020 at 8:16 PM Alan Cudmore <alan.cudm...@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 >> <vijaykumar9...@gmail.com> wrote: >> > >> > >> > >> > On Sun, Feb 23, 2020 at 11:46 PM Alan Cudmore <alan.cudm...@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 <l...@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@rtems.org >> >> http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
