On 29/12/20 9:27 am, James Fitzsimons wrote: > Hi all, > > I am trying to debug an RTEMS application on a TI AM3358 ARM processor > (Beaglebone Black) and the RTEMS startup code is halting on the bsp_fdt_get > call. > > I'm using TI Code Composer Studio to load the RTEMS application image via > XDS100 > V3.0 debugger. If I reset the program counter and step through the startup > code > I see it error on the bsp_fdt_get() call.
Is this a crash or is an error reported? We should report an error and not crash. > My IDE isn't copying an fdt image to the expected location the way uboot > would, > and so this makes sense. My question is how do other people get around this > problem? > > Has anyone else used a similar setup and solved this issue? I have not hit this issue but I saw this as a problem with the approach taken of loading an FDT via the bootloader. It would have been nice to have a way to integrate an FDT into the IMFS (or executable) rather than an external load. > Many thanks for any advice you can provide. The only approaches I can think of are a bit hack'ish but they might work. Can you set up an environment to load and run uboot from an SD card? Have uboot load the FDT then stop at it's command line. Once at the command line connect via JTAG and load the application. I suspect you will need to set the registers to the same values uboot uses when entering the application. I seem to remember one of them points to the FDT blob. Another approach is to boot using uboot and have it load the FDT and RTEMS executable then jump to it. If you can connect via JTAG, reset the processor, set a hardware break point on the entry point to RTEMS, and start the processor running from reset it should trigger when uboot jumps to RTEMS. The entry point is at a fixed address. When the breakpoint is hit delete it and then you can set further break points in your application. Chris _______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
