This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

How to install SYS/BIOS on Beaglebone Black

Other Parts Discussed in Thread: AM3359, SYSBIOS

Hello, 

I am struggling with getting the RTOS to run on the BeagleBone Black.  I can get no further than the "Jumping to StarterWare Application"  part.  Here it apparently hangs. 

Does the SYS/BIOS require a different MLO, bootloader than the standard StarterWare examples?

My setup:
I am not using an emulator or a JTAG
Using 6-pin header to USB cable for serial output, via TeraTerm.

BeagleBone Black Rev B
CCS Version: 5.5.0.00077
AM335X_StarterWare_02_00_01_01
Latest patch for BBB has been installed
Built bootloader app and renamed the boot.bin to MLO
I can build and run the StarterWare example projects

Here's what I have done: 
Created new Workspace
TI Resource Explorer>ARM>AM3359>GNU Target Examples>Generic Examples>Hello Example
Import the project. 
Build the project. Creates a "hello_AM3359_CortexA.out"   
Used tiobj2bin to convert .out file to .bin file
Renamed "hello_AM3359_CortexA.bin"    to "app"
Used MLO that worked with all StarterWare example code

I have compiled different example projects under SYS/BIOS but they all fail at the same place, and appear to hang at the Jumping to StarterWare Application.  I am not positive that it is hanging, but I do know that I can see nothing happening on the TeraTerm, where my serial output is.

Any ideas?

  • I'm going to post an update on this in hopes that it sparks some input.  

    Can anybody post a sequence of events that must happen to load a sys/bios project on the target?  I now have a JTAG debugger set up, but when running the sys/bios application it never makes it to main before fritzing out. 

  • So far I have had no luck. I do not have a hardware debugger but I am not able to flash the LED so I am 99.9% sure I never made it to main(). Anyone???

    Seems kinda critical to have this working as this is AFAIK the BBB is the most relevant platform available for most developers today.

    Re

     SM

  • Hello,

    Starterware expects certain information in the binary header to load an image from SD card. I don't think those headers are added if you use tiobj2bin. Please use ti_image tool(available in Starterware) to generate the bin file.

    Regards,
    Vinesh

  • Hay Vinesh Thanks for the help.

     I have success in building the sample gpioLEDBlink program on the BBB using CCS and StarterWare but I did have to create this custom post build step so it may not be correct but again it does seem to work for my LED blink

    "/home/user/ti/ccsv6/utils/tiobj2bin/tiobj2bin"  "minimal_GenericCortexA8Device.out"  "minimal_GenericCortexA8Device.bin"  "/home/user/ti/ccsv6/tools/compiler/arm_5.1.5/bin/armofd"  "/home/user/ti/ccsv6/tools/compiler/arm_5.1.5/bin/armhex"  "/home/user/ti/ccsv6/utils/tiobj2bin/mkhex4bin" & "/home/user/AM335X_StarterWare_02_00_01_01/tools/ti_image/tiimage" "0x80000000" "NONE" "minimal_GenericCortexA8Device.bin" "minimal_GenericCortexA8Device_ti.bin"

    It does run ti_image and then I place the _ti.bin on the uSD card. I modified the minimal_GenericCortexA8Device to blink the LED so I can confirm if main() was called and the LED does not flash. I do not have a jtag debugger so that is the best I can do to test at this time.

    Re

     Sean M

  • Sean,

    You can find some help on post build script here. Please note that this uses isdk_image instead of ti_image to generate the binary file(thus wouldn't work with the Starterware MLO).

    Regards,
    Vinesh

  • Also, you have given Run Address as 0x8000_0000. Please make sure that your .init section lies there(check map file).

    Regards,
    Vinesh

  • It is not. Unlike the led blink example the RTOS example placed the entry point as follows

    ******************************************************************************
                      TI ARM Linker Unix v5.1.5
    ******************************************************************************
    >> Linked Fri Apr 25 23:06:23 2014

    OUTPUT FILE NAME:   <minimal_GenericCortexA8Device.out>
    ENTRY POINT SYMBOL: "_c_int00"  address: 80008da4

    I could move this using the following in my app.cfg

    Program.sectMap[".init  { boot*(.text) }"] = new Program.SectionSpec();
    Program.sectMap[".init  { boot*(.text) }"].loadAddress = 0x80000000;

    Or I could adjust my tiimage command.

    It is not clear to me what is the correct or preferred option. It seems to me if the compiler and tools put it at 80008da4 then it knows what it wants and I would adjust my commands to use that entry point.

    I also think my reason for not seeing the LED blink is related to not configuring the MMU so I am likely looking at multiple problems but for now the question as to what the entry point should be and what needs to be adjusted is my first concern.

    Your thoughts are appreciated and thanks in advance.

    Re

     Sean M

  • Well I answered my own question. Changing to 0x80000000 does work trying to adjust to 80008da4 using tiimage did not work.

    I would like to understand why the default address of this build is at a location that seems to not work? is this related to the compiler presuming I am using a debugger? or some other bug I need to report?

    Re

     Sean M

  • Sean,

    It's not that it doesn't work, just thatthe Bootloader of Starterware is configured that way. Ideally, giving the correct params to ti_image should work. That's how it's done is Industrial SDK examples.

    Regards,

    Vinesh

  • Here is what I have found so far after a few days of trying to get minimal_GenericCortexA8Device to run on a BeagleBone Black using the latest tools as follows

    AM335X_StarterWare_02_00_01_01, tirtos_sitara_2_00_01_23

    1. I am sometimes able to get the LED to flash or turn ON when I relocate to 0x80000000 but the program is not stable and if I modify any code in main() such as turn the LED off/on again it will just not run at all.

    Looking at the MAP file if I do force to 0x80000000 it looks to me as if several functions exist at that same address so I suspect the relocation is not a good solution.

    2. I have never been able to get the LED to turn on when I record the int00 location after a build then build my tiimage using this address.

    I have found many others in the forums with the same issue with no solutions, I have not see anyone successfully use RTOS on the BBB. If anyone has a BBB and has a process that works or if soomeone from TI could please actually test all of these tools on a BBB that would sure help all of the people trying with no success.

    3. I have no problem building a normal BBB image such as the example led blinking when "not" using RTOS and it works perfectly. The problems only exist when trying to use SYSBIOS from the provided examples.

    Re

     Sean M

  • Sean, I have spent several days trying to get Sys/Bios to run on the Black.  I don't understand it.  Since there is a special build in Sysbios named Beaglebone Black I would have supposed that it had been built and tested to work with the BBB.  But so far I cannot get it to run.  

    I have ran the application to build the image with the _ti image header, and it still doesn't work with their MLO.  I have tried just about every combination of binaries, header-appended and headerless, with several different different MLO's that I have rounded up, including rebuilt ones out of Starterware.  Nothing has worked.  When hooking it up to JTAG, I can't even make it to main.  

    It has been very frustrating for us, as we are trying to use the BBB as a development platform for an avionics product, and so far the support for it has been extremely limited.  No HDMI support and no USB support for bare metal programming either.  These roadblocks have really cost our team alot of time and effort, and we only have a bare shell of an OS built so far, with much of the hardware still unsupported.  

    I am watching this thread closely, because if anybody can ever outline a way to get Sys/Bios running on the BBB, (if it is even possible) I will be right on it. 

  • As a possible next step, you can try loading Bootloader via JTAG and check why the image is not getting loaded.

    Regards,
    Vinesh

  • Vinesh thanks for your help I managed to get everything working and have a timers and tasks running with a semaphore serializing my output to uart0.

    I did order a JTAG debugger from mouser for future use.

    Thanks again.

    Re

     Sean Mathews

  • Sean,

    That's great. Anything particular you did to make it work? Please share information.

    Regards,
    Vinesh

  •  The linker will place c_int00 where ever it wants. It is not clear to me what the boot process would be that would call c_int00 correctly using the resulting binary but I presume it would be a reset vector or another part of this bin that would normally be placed directly onto the chips rom but because it moves every build I have to presume that the jump is baked into the resulting bin and thus not usable when using the MLO. If someone has more info on the boot process for this please do explain the intent of the binary produced during build and how it would be used. Maybe its only designed to be used with an emulator or debugger that already knows where c_int00 is?

     In order to make sure c_int00 is at the correct place for the MLO it is necessary to force the linker command to relocate it to where the MLO loader will call it after it is loaded into DDR in this case for the MLO for the beaglebone black patched booloader for StarterWare it is 0x80000000.

    The linker.cmd needs to have this section attribute in order to relocate _c_int00
    SECTION
    {
    ...
        .c_int00 { boot.aea8fnv<boot.oea8fnv> (.text) } load > 0x80000000
    ...
    }
    To force StarterWare to add this line to the linker.cmd file the app.cmd needs this for the beaglebone black (oea8fnv) but will differ for other chips.
    Program.sectMap[".c_int00 { boot.aea8fnv<boot.oea8fnv> (.text) }"] = new Program.SectionSpec();
    Program.sectMap[".c_int00 { boot.aea8fnv<boot.oea8fnv> (.text) }"].loadAddress = 0x80000000;

    The references that helped me figure out what was going on as well as reading the map files to see what was wrong although this document is wrong for SYSBIOS projects as it does not follow this pattern and what pattern it does follow is still a mystery.
       http://processors.wiki.ti.com/index.php/AM335X_StarterWare_Booting_And_Flashing
    Also look at the map files of working non SYSBIOS binary that works where 'Entry' is the jump vector to start the code.

    Regards
     Sean Mathews
       NuTech.com
       coder at f34r.com
  • Sean,

    Isn't this the expected behavior? The .init section is expected to be at a fixed location, which is then passed to ti_image so that the binary generated has a header with the required info(read by the bootloader and executes the app accordingly). We do the same process is Industrial SDK, which uses a modified bootloader and ti_image(isdk_Image), to be able to boot from different media(NOR, SPI and SD card). Industrial SDK does not support BBB though, you can check the examples provided as a reference.

    Regards,
    Vinesh

  • Hay Vinesh.

    I can only say from reading the code for the bootloader patched for BBB with StarterWare that the init section has nothing to do with the entry point problem people are having. The compiling and linker already place everything starting at 0x80000000 so everything is aligned to run from DDR.

    The link I provided describes the boot process and the "header" you discuss added by ti_image is only 2 values the location to place the binary in DDR and the size of the binary. The address argument for ti_image only defines where in DDR the binary will be placed not what the entry point is.

    The start address "could" be adjusted to match the binary produced by StarterWare and the location of c_int00 but that would be a real pain as it changes every time and it wont work in any case because the bootloader only knows to start execution at offset 0 from where the binary is loaded into DDR as shown below a snipit from bl_msmmscd.c .

    So if it is loaded into DDR at 0x80000000 then the _init_c or some jump instruction on where to reach _init_c needs to be exactly at 0x80000000.

    destAddr = (unsigned char*)imageHdr.load_addr;
    entryPoint = imageHdr.load_addr;

    Just telling app.cfg to move .init wont help because the first instruction at 0x80000000 will still be garbage and it will crash. Maybe this is a bug in the linker that it did not produce an error.

    Here is trying to relocate .init to 0x80000000 and you can see now we have multiple blocks of code at the same address ie corrupted and it will crash or be unstable.

    app.cfg setting suggsted by other posts.

    Program.sectMap[".init { boot*(.text) }"] = new Program.SectionSpec();
    Program.sectMap[".init { boot*(.text) }"].loadAddress = 0x80000000;

    resulting map

    address name
    -------- ----
    00000000 _argsize
    00000001 __TI_args_main
    00000001 xdc_runtime_Startup__EXECFXN__C
    00000001 xdc_runtime_Startup__RESETFXN__C
    00000400 __STACK_SIZE
    48200000 ti_sysbios_family_arm_a8_intcps_Hwi_intc
    80000000 __ASM__ < COLLISION
    80000000 _c_int00 < COLLISION
    80000000 xdc_runtime_Text_charTab__A < COLLISION
    80000074 __ISA__

    The only solution that made any sense to me was to make sure that inside of the init section that the first bytes are c_int00 by moving c_init00 to the start of 0x80000000 . The linker did do this correctly.

    Re
    Sean Mathews
    NuTech.com
    coder at f34r.com
  • Sean,

    Ok, so the issue is the inability configure the "start" address of the binary. As I mentioned earlier, we have a modified version of ti_image used in Industrial SDK. Please check details here. This takes in a configured value for  "Start" address, which is read by the bootloader(again modified to adapt this change).

    Regards,

    Vinesh

  •  I will find a windows system to install the IDK on and see how it looks but afaik this is not on topic for the Beaglebone Black as it is not supported at all on the IDK.

     I hope that more support from TI is put into supporting the BBB on SYSBIOS in the future so far I have not even been able to get i2c or GPIO to work and have so far had to use raw code to do any GPIO when trying to add 'Board_initGPIO()' to my project I end up with this error and looking around it seems that no drivers are included for this chip not even the onboard i2c or UART

    Description    Resource    Path    Location    Type
     Driver not found for this device AM3359 and target ea8fnv    .xdchelp    /minimal_GenericCortexA8Device    line 90    C/C++ Problem

    StarterWare has had some work on the BBB in recent months is more being done and will SYSBIOS and BBB drivers be added for i2c and gpio? I dont want to start writing my own just to find out its in beta testing :c)

    Re

     Sean M

     coder at f34r.com

  • Sean,

    I'm afraid Starterware does not have plan to support BBB - http://e2e.ti.com/support/embedded/starterware/f/790/p/336801/1179556.aspx#1179556

    Industrial SDK has drivers which support SYS/Bios using Starterwar. It does not officially support BBB, but would be a good reference point.

    Regards,
    Vinesh

  • I did get SYSBIOS running on BBWhite, and the solution probably applies to BBB as well.  From my development diary:

    There was some discussion on the TI e2e site on making an application suitable for loading and running by the boot loader.  The requirement is that the program entry point be at the first word of the load image.  This is a linker function.  There is no configuration in SYS/BIOS to force it’s C initialization routine, _c_int00, to the beginning of the load image.  The article http://processors.wiki.ti.com/index.php/Accessing_c_int00 gives the clue. 

    So I created a linker command file to do just his.  The relevant excerpts are:

    /*
     This command file is a hook to force the SYS/BIOS C inititialization
     code to the start of memory space.  This is needed because the boot
     loader simply loads the image to the destination and jumps there.
    */

    /*
     This file must be called by the linker BEFORE the generated linker.cmd.
     To do this, the link order must be modified in the project Build settings

     CCS Build -> Link Order, select Add, then check
     "Generated Linker Command Files", and this file.
     Use the UP/DOWN buttons to make this file first in the list.
    */


    /* Define a section for booting, define the address, input the code. */
    /* The module name comes from the link map.                          */
    SECTIONS
    {
        boot : > 0x80000000
        {
            *<boot.oea8fnv>(.text)
         }
    }

    And then it builds an image MLO can load and run, with the MLO required header prepended of course.

  • I know this is an old thread, but the answer can be found here: https://e2e.ti.com/support/embedded/starterware/f/790/t/356334

    Here is an excerpt from one of the replies on the thread and this worked for me to get the beaglebone black starterware bootloader to work with a TIRTOS application.  I performed the post-build step to get the _ti.bin file at address 0x80000000.  The .cfg file has to be modified to get the SYS/BIOS application to load at that address.

    If you use the ti compiler then add the following to your .cfg (from here: processors.wiki.ti.com/.../BIOS_with_GCC_%28CortexA%29)

    Program.sectMap[".init  { boot*(.text) }"] = new Program.SectionSpec();

    Program.sectMap[".init  { boot*(.text) }"].loadAddress = 0x80000000;

    if you using the gcc compiler then it is (from here: processors.wiki.ti.com/.../BIOS_with_GCC_(CortexA))

     Program.sectMap[".c_int00"] = new Program.SectionSpec();

    Program.sectMap[".c_int00"].loadAddress = 0x80000000;

    Program.sectMap[".c_int00"].runAddress = 0x80000000;