Prebuilt u-boot binary for AM3359 IDK for running QNX

I installed the SDK for the AM3359IDK. It contains code for a different type of boot loader - "StarterWare". It seems the MLO that ships with the IDK is created by this StarterWare - probably incompatible with u-boot..

What I basically need is the binaries the this process produces: http://processors.wiki.ti.com/index.php/AM335x_U-Boot_User's_Guide. It seems that I would have to setup a linux machine to compile it from source, and never did that before and would possibly encounter various problems - as other posts show.

-Albrecht

Albrecht,

as mentioned in other threads there is currently no support for Linux on IDK and ICE boards. The software we use (mainly Sys/Bios 6) only needs a simple boot loader and that is coming from Starterware. I am not aware of a working u-boot for IDK at the moment.

However there are a few people reporting they can boot Linux on ICE or IDK on the forum here. So I assume they managed the few changes to u-boot that may be required for the IDK. It would be great if someone could post their code or patches so that others could continue or reuse the work. Long term I hope we can add some support on Arago  project for example.

Generally u-boot and the process of building from source is well described to my mind. Just see the Linux SDK, wikis and so on.

Regards.

Hello Frank,

I'm not specifically after U-boot. I'm after a bootloader that allows me to transfer a QNX Bootimage (a single file basically) from storage (SD-card for the moment, later on-board NAND) to RAM and jump to it. QNX has developed its own technology to do this, we call it IPL (Initial Program Loader). Its functionality is similar to what MLO does: It can locate a valid QNX Bootimage in some storage (or wait for one on serial line), transfer it to RAM and give control to it. To do this, it needs to do not much: Setup stack, set up RAM controller,  set up controller for storage where QNX Bootimage is located (SD card in this case) and locate and load image. Description is here: http://www.qnx.com/developers/docs/6.5.0/topic/com.qnx.doc.neutrino_building/load_process.html.

All this is already contained in the Starterware MLO, is it not?

I downloaded the IDK SDK (am335x_sysbios_ind_sdk_1.0.0.4). Is it correct that the binary that will be generated from the C:\ti\am335x_sysbios_ind_sdk_1.0.0.4\sdk\starterware\bootloader\src subfolder is the MLO used in the IDK?

u-boot was only meant as a temporary loader for development. When the final system is designed, we would switch to a QNX IPL anyway. I wonder now if it is a viable solution to skip u-boot altogether and create a proper QNX IPL right from the start. It would also eliminate any GPL issues right away.

If you were able to guide me to build the starterware MLO, I think I can manage to do the rest. I don't have CCS, is it free? Or what toolchain is necessary? I used CCS about 10 years ago with a DSP, but things certainly have changed.

Many thanks for you help.

-Albrecht

For your reference, I also created a thread in the QNX forum Foundry 27 to see what comes from their side: http://community.qnx.com/sf/discussion/do/listPosts/projects.bsp/discussion.bsp.topc22401.

Albrecht,

I think your assessment is correct. The Starterware bootloader (renamed to 'MLO' so that AM335x ROM does find the file on SD) does nearly the same as your IPL I think. You can look at the sources in the starterware folder and the process to build is described in the IA-SDK UG section "Building Bootloader". If it doesn't work post the questions here...

CCSv5 is free for download. You may install the trial setup (90 days) which then can be upgraded by buying a license. It supports all features. Basic debug using XDS100v2 emu or on-board emulation (ICE) is always free. Only for professional development using XDS510/560 class emulators you will need to buy full CCS at some time.

The TI Starterware code is free and there is no GPL issue (exceptions might be in the third-party folder).

I think it was a good idea to also post in the QNX forum as I know they have a port for AM335x but I have no details what boards they support and how. They might have a solution for you already.

Regards.

Frank,

Got far but not yet quite through. downloaded and installe CCSv5 v5.2.1.00018. Imported and built the depandent projects - I could create platform.lib, drivers.lib and mmcsd.lib under binary/armv7a/cgt_ccs. Imported the bootloader project. Compiled ok but the linker complains about two things:

"../boot.cmd", line 83: error: IRAM_MEM memory range overlaps existing memory
   range SRAM
"../boot.cmd", line 83: error: IRAM_MEM memory range overlaps existing memory
   range L3OCMC0

And also about the C runtime:

warning: automatic library build: using library
   "C:\ti\ccsv5\tools\compiler\tms470_4.9.5\lib\rtsv7A8_A_le_eabi.lib" for the
   first time, so it must be built.  This may take a few minutes.
  -->  error: '*.obj
' not found
gmake.exe[1]: *** [library] Error 1
>> ERROR: mklib: gmake error during rtsv7A8_A_le_eabi.lib build
warning: automatic RTS selection:  resolving index library "libc.a" to
   "C:\ti\ccsv5\tools\compiler\tms470_4.9.5\lib\rtsv7A8_A_le_eabi.lib", but
   "C:\ti\ccsv5\tools\compiler\tms470_4.9.5\lib\rtsv7A8_A_le_eabi.lib" was not
   found

Since the automatic build of the C runtime failed, of course the linker gets lots of unresolved symbols like strcat() and friends.

Ideas? Maybe its easier to build the C runtime libs separately? How to do this?

Then I changed the project settings for the Runtime support library from <automatic> to "rtsv7A8_T_le_n_v3_eabi.lib". That one is obviously there (preinstalled) but compiled with wrong FP format:

>> Compilation failure

"C:/ti/ccsv5/tools/compiler/tms470_4.9.5/lib/rtsv7A8_T_le_n_v3_eabi.lib<auto_init.obj>" was built with VFP coprocessor support while a previously seen file was not; combining incompatible files

gmake: *** [../../../../../../../binary/armv7a/cgt_ccs/am335x/evmAM335x/bootloader/boot.out] Error 1

Thanks,

-Albrecht

Albrecht,

I am not sure why you rebuild all the libs?

I have to defer support for boot loader build to a colleague who developed that stuff. All the apps we build use rtsv7A8_A_le_n_v3_eabi.lib. That is compatible to Sys/Bios version we use for AM335x. But I am not sure about the boot loader as it doesn't need floating point I assume.

Regards.

Well, I very strictly followed the chapter "Building Bootloader" in the IDK Users Guide - as recommended by you. In steps 2-4 it requires me to build the support libraries from source with the configuration set to "Fixed Point" - because the bootloader doesn't use VFP. This is, I argue, I very fundamental difference compared to building apps. And all the libraries had that "Fixed Point" configuration and it built.

So I believe that for the bootloader we also need a specific runtime support without VFP, which doesn't come prebuilt. I tried to invoke mklib directly from the command line, this is the result:

C:\ti\ccsv5\tools\compiler\tms470_4.9.5\lib>mklib --pattern=rtsv7A8_A_le_eabi.lib --index=libc.a

....

  inflating: newnothrow.cpp          [text]
  inflating: placedel.cpp            [text]
  inflating: placenew.cpp            [text]
  inflating: pure_virt.cpp           [text]
  inflating: vec_newdel.cpp          [text]
  inflating: typeinfo_.cpp           [text]
  inflating: vec_cctor.cpp           [text]
cl470 decode.c -o -oe -k -ps -pdsw225 -q  -mv7A8 --fp_mode=strict --no_visible_e
nums --abi=eabi -c --ti_lib --building_runtime -D_BOOL -me -fg --rtti -Ic:/dokum
e~1/uhlman~2.bit/lokale~1/temp/ti9e28~1/src -fr c:/dokume~1/uhlman~2.bit/lokale~
1/temp/ti9e28~1/obj -fs c:/dokume~1/uhlman~2.bit/lokale~1/temp/ti9e28~1/obj -ft
c:/dokume~1/uhlman~2.bit/lokale~1/temp/ti9e28~1/obj
cl470 xerrno.cx -o -oe -k -ps -pdsw225 -q  -mv7A8 --fp_mode=strict --no_visible_
enums --abi=eabi -c --ti_lib --building_runtime -D_BOOL -me  -Ic:/dokume~1/uhlma
n~2.bit/lokale~1/temp/ti9e28~1/src -fr c:/dokume~1/uhlman~2.bit/lokale~1/temp/ti
9e28~1/obj -fs c:/dokume~1/uhlman~2.bit/lokale~1/temp/ti9e28~1/obj -ft c:/dokume
~1/uhlman~2.bit/lokale~1/temp/ti9e28~1/obj
C:/DOKUME~1/UHLMAN~2.BIT/LOKALE~1/Temp/make48764.sh[1]: cl470: not found
make.exe: *** [c:/dokume~1/uhlman~2.bit/lokale~1/temp/ti9e28~1/obj/decode.obj] E
rror 127
make.exe: *** Waiting for unfinished jobs....
C:/DOKUME~1/UHLMAN~2.BIT/LOKALE~1/Temp/make48765.sh[1]: cl470: not found
make.exe: *** [c:/dokume~1/uhlman~2.bit/lokale~1/temp/ti9e28~1/obj/xerrno.obj] E
rror 127
>> ERROR: mklib: gmake error during rtsv7A8_A_le_eabi.lib build

Is it possible that building the RTS must be done on Linux? Or do I have to invoke a special script to set the environment?

Maybe your collegue can simply post a prebuilt RTS.

-Albrecht

Yes, I see the issue.

I did the RTS build only once before we had the required float lib build automatically by Sys/Bios. Unfortunately that doesn't seem to be the case for the bootloader...

Now until you get more help I can only say that the ARM compiler UG (spnu151g) describes the process in section 7.4.

Regards.

Oh, when I add

C:\ti\ccsv5\tools\compiler\tms470_4.9.5\bin

to the Windows PATH env var it builds something ... CCS now links successfully (I explicitly set boot.cmd es linker command file) and produces boot.out. (192KB in size). Now I try to create an MLO from this ... stay tuned.

-Albrecht

OK I can successfully build boot.out but the required post-build step is not successful.

It looks as if my CCS installation is incomplete. The environment variables CCS_INSTALL_ROOT and CG_TOOL_ROOT are not set. OK I can replace them by using the explicit paths, like

C:\ti\ccsv5 and C.\ti\ccsv5\tools (maybe?)

But it looks as if some programs are missing. For instance post_build.bat, line 11, says:

call "%~1/utils/tiobj2bin/tiobj2bin.bat"

If %~1 is replaced by C:\ti\ccsv5 I can find the folder "utils" but it doesn't contain a subfolder "tiobj2bin", so the script doesn't work There are some other such errors as well. I searched "C:\ti" for "*.bat" but didn't find the referenced scripts. I found that other users had the same problem: http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/168266.aspx. I will try to fix this.

Regards,

-Albrecht

Unbelievable, it works now! I added some fancy lines to bl_main.c, 153:

bl_UARTPuts(" Boot Loader. Build - ");

bl_UARTPuts(__DATE__);

bl_UARTPuts(", ");

bl_UARTPuts(__TIME__);

bl_UARTPuts(" ***\n\r");

with this effect:

*** StarterWare  Boot Loader. Build - Aug 30 2012, 18:17:48 ***
Copying application image from MMCSD to RAM

Copying to RAM completed successfully
 Image Copy Successful, Executing Application..
ECAT Limited Demo - 1.0.14

.... OK...back to QNX

Usually, the QNX IFS is a single file and prepended with a short header (same like MLO) with a jump instruction to the real entry point deep inside. So, any loader who doesn't know what a QNX IFS is just jumps to the start of the image. All I want now is that MLO transfer my QNX IFS to DDR RAM and then I will set entryPoint to that address - done!

When I look into the sources, I find that the file "app" is transferred to DDR_START_ADDR if the loader doesn't find a valid ti_header at the beginning of the "app" file (bl_hsmmcsd.c, line 480ff). In case of QNX IFS of course this is the case. So if I have a valid QNX IFS that expects to be at DDR_START_ADDR the MLO should boot it out of the box. Is my understanding correct?

-Albrecht.

Yes. You are right. If  loader doesn't find a valid ti_header, app will be copied to DDR_START_ADDR and the MLO will transfer execution control to DDR_START_ADDR . If your QNX entry point is at DDR_START_ADDR, everything should be fine.

Regards,

Shahid

OK I managed to boot QNX. The clock setup is not complete, though. The system timer ticks far too slow. Is it possible to guide me to a good document that describes the required clock and timer setup on boot? The registers are scattered all over the place and it's easy to miss a bit somewhere.

Thanks,

Albrecht

We successfully created a board support package (BSP) supporting QNX Neutrino RTOS on the IDK:

http://www.bitctrl.de/produkte/hw_qnx/bsp/ti-am3359idk/index_en.shtml

Regards,

Albrecht