u-boot board config for omap l138 based boards

Hi Laszlo,

Have a look at the include/configs/da850evm.h in mainline u-boot. This board config includes an SPL configuration for booting from SPI flash.

Build it using
make da850evm_config
make
You will find the final image including SPL and u-boot in u-boot.ais

If you are interested in booting from NOR, there is also a solution that uses neither UBL nor SPL, instead u-boot is directly executed from flash and then relocates itself to RAM. The calimain and enbw_cmc board configurations in mainline u-boot use this approach.

Hope that helps! Christian

I would not like to flash an AIS image into the NOR flash, just u-boot.

I know how to boot u-boot directly NOR flash because we have been doing that for a while, although we flash over JTAG.

So, my question is: is it possible to flash u-boot:

1) Without an AIS image?

2) With an AIS image, but not getting SPL flashed into the NOR flash as well? We only need u-boot as we are currently doing that with openocd and jtag.

See the following thread for details: http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/p/294128/1025624.aspx#1025624

I'm not sure if I understood you correctly, but let's try...

This is how I flash u-boot (without any SPL or AIS, just for direct booting from NOR) to NOR flash:

sfh.exe -p COM6 -targetType AM1808 -flashType NOR -flash_noubl u-boot.bin

I use the code above for the calimain board that I mentioned in my earlier posting. For your OMAP L-138 you will have to replace AM1808 by OMAPL138.

Best regards, Christian

Right, that is exactly what I was asking in the other thread linked. So you can verify that the question there would make it work for me, right?

I would not even need to bother with SPL, just building u-boot the regular way, and flashing it with either a mono tool or a Qt based I have written?

Yes, I think that should work for you (if I understood everything correctly). At least it's working fine for me :-) Note that my u-boot.bin however includes the magic word for direct booting from NOR flash, see the #define CONFIG_SYS_DV_NOR_BOOT_CFG in include/configs/calimain.h in u-boot.

Good luck, Christian

Yeah, we have that, too. We have been booting like that for a while after flashing the u-boot image via jtag.

Just to make it clear: you have flashed the u-boot that on an un-programmer board which had no content on it (not even UBL or SPL), and was just coming from the production, right?

Also, I wonder what "SFT" means that I see all around in the serial flasher code base (host). What does that stand for? Serial Flasher Target, or something else? I do not mean the executable name, but those upper-case letters.

This snippet is something I am referring to:

// Try transmitting the first stage boot-loader (the SFT) via the RBL
try
{
    String srchStr;
    Byte[] imageData;
    UARTBOOT_Header ackHeader = new UARTBOOT_Header();

    srchStr = "sft_"+cmdParams.deviceType+"_"+cmdParams.flashType+".bin";

    // Get the embedded SFT image data
    imageData =     EmbeddedFileIO.ExtractFileBytes(System.Reflection.Assembly.GetExecutingAssembly(), srchStr);
    ackHeader.startAddr = 0x0100; // Default for SFT
    ackHeader.loadAddr = 0x0020; // Not used here, but this what the RBL uses
    ackHeader.byteCnt = (UInt32) imageData.Length;

    TransmitSFT(imageData,ackHeader);
}

I would like to understand the logic behind it. I believe this would be the appropriate image in my case, but why do we need such an image before transferring the u-boot.bin file?

There is also lines like this in the code which worries me based on the comment. It seems they are trying to boot u-boot after flashing SFT:

// Wait for ^^^DONE that indicates SFT is exiting and so can this host program
if (!SerialIO.waitForSequence(" DONE\0", "BOOTUBL\0", MySP, cmdParams.verbose))
{
    throw new Exception("Final DONE not returned. Operation failed.");
}

To me, it feels like it still transmits the UBL in the background, and we may just not be aware of it. Try to remove the relevant UBL binary in your folders, and retry afterwards. I wonder if your flashing works in that case?

Yes, exactly, we are using this in our production process, we program u-boot onto boards with empty flashes that come right out of production.

Regarding the SFT, I had no idea what it stands for, but I looked it up in the processor wiki and there is says "Serial Flasher Target" (http://processors.wiki.ti.com/index.php/Serial_Boot_and_Flash_Loading_Utility). This is how it works: First we put the processor into "boot from serial" mode, after resetting it prompts BOOTME on the console. Then we execute sfh.exe. sfh then transfers a suitable SFT to the processors internal RAM. The SFT is not flashed to some flash memory, it only is loaded into internal RAM. The SFT then initializes the DDR memory. After that SFT is ready to receive a firmware image via the serial interface. The sfh.exe will then transmit u-boot.bin via the serial interface. SFT will store it somewhere in the DDR memory, then erase the flash and program the firmware image to flash. There are different versions of SFT available, depending on targetType and flashType parameters, sfh.exe will use the right one, see the code you posted above. Note that the SFT does the actual flash programming, not the RBL, the RBL does not seem to have code for that.

Since the SFT configures the DDR memory and uses it, I had to modify it because I am using a different type of DDR memory, other than the one on the eval kit. The memory configuration is in OMAP-L138/Common/src/device.c in the flash loader code.

Best regards, Christian

Laszlo Papp said:

To me, it feels like it still transmits the UBL in the background, and we may just not be aware of it. Try to remove the relevant UBL binary in your folders, and retry afterwards. I wonder if your flashing works in that case?

To make this clear, if you use the -flash_noubl option, UBL is not flashed to the flash memory. I have verified this by looking at the flash memory content. The flash memory only contained u-boot.bin. There is no UBL binary file on the machines that I use for programming.

I meant UBL for only loading into the IRAM, not flashing that to the flash memory.

UBL seems to be used; see this code for details:

/// <summary>

/// Function to Transmit the UBL via the device ROM Serial boot
/// </summary>
private static void TransmitSFT(Byte[] imageData, UARTBOOT_Header ackHeader)

It is definitely using UBL, so I am not all that sure how it worked for you without the UBL/SFT images. Could you please clarify?

UBL and SFT seem to share the initialization code, but sfh.exe definitely uses the SFT binaries, not the UBL binaries. The SFT binaries seem to be linked into sfh.exe. So I only need sfh.exe on the machines that I use for programming the devices. Of course it does not work without the SFTs, but they are in the sfh.exe, so there is no need to keep them separately. UBL is neither used nor required. And neither UBL nor SFT is flashed to the flash memory. Only u-boot.bin is flashed to flash memory.

Christian

In that case, the code seems to be quite misleading (using ubl comments, variable names, etc)  ... ;-)

OK, thanks, I am writing a replacement in Qt... based on Qt 5.1 and QtSerialPort. Let me know if you are interested, and I will send details.

By the way, there are two issues I see:

1) Pressing a key results the text "Aborting program...", but the program is not actually aborted.

2) I am getting the output below, but then it got stuck without proceeding further for 1-2 minutes. What am I doing wrong?

-----------------------------------------------------
TI Serial Flasher Host Program for OMAP-L138
(C) 2012, Texas Instruments, Inc.
Ver. 1.67
-----------------------------------------------------

[TYPE] Single boot image
[BOOT IMAGE] /srv/tftp/u-boot.bin
[TARGET] OMAPL138
[DEVICE] SPI_MEM
[SPI Block] 0

Attempting to connect to device /dev/ttyUSB0...
Press any key to end this program at any time.

(AIS Parse): Read magic word 0x41504954.
(AIS Parse): Waiting for BOOTME... (power on or reset target now)
(AIS Parse): BOOTME received!
(AIS Parse): Performing Start-Word Sync...
(AIS Parse): Performing Ping Opcode Sync...
(AIS Parse): Processing command 0: 0x58535901.
(AIS Parse): Performing Opcode Sync...
(AIS Parse): Loading section...
(AIS Parse): Loaded 9200-Byte section to address 0x80000000.
(AIS Parse): Processing command 1: 0x58535901.
(AIS Parse): Performing Opcode Sync...
(AIS Parse): Loading section...
(AIS Parse): Loaded 736-Byte section to address 0x800023F0.
(AIS Parse): Processing command 2: 0x58535906.
(AIS Parse): Performing Opcode Sync...
(AIS Parse): Performing jump and close...
(AIS Parse): AIS complete. Jump to address 0x80000000.
(AIS Parse): Waiting for DONE...
(AIS Parse): Boot completed successfully.

Waiting for SFT on the OMAP-L138...

I am using 64 bit Archlinux on the host fwiw. Perhaps I also need to modify OMAP-L138/Common/src/device.c? Did you have to make an intrusive change to that, or just some minor?

Yes, absolutely, would be interesting to see? Will this be something proprietary, or are you going to release it under some open source license?

Maybe you would also like to have a look at the YMODEM-SPL-Support in u-boot (common/spl/spl_ymodem.c). Using this, the SFT could be replaced by an u-boot SPL that would be downloaded to IRAM by an sfl clone and then would accept a firmware image transferred via the serial port using the YMODEM protocol. By doing so, there would be no more need to put device configuration code into SFT and u-boot, instead the u-boot code would be used for normal operation AND for initial programming of the device. Currently the spl_ymodem support in u-boot seems only to be used for an AM335x configuration, but I think it shouldn't be much work to add it to DA850 based boards.

Christian

So, basically you rebuilt the sfh executable yourself to contain your modifications as the SFT binary is embedded. I am not sure I like this idea. I would rather make this as a parameter for the application I am writing in Qt. Alternatively, there could be a parameter to a device configuration file with well-defined parameters the users need to fill in. What do you think about this?

That would allow more flexibility without rebuilding everything to get your customization for a SFT binary, or I can just rebuild that with this mono tool without the whole rebuild of the sfh binary? Then, I could somehow replace that in the sfh executable?

What is your take on this decision?

PS.: do you know what configurations I should modify in the device.{h,c} files? They look a bit too long for getting this done within a couple of seconds. :-) This is the datasheet for the DDR2 SDRAM, fwiw: http://download.micron.com/pdf/datasheets/dram/ddr2/1GbDDR2.pdf

I have just opened a new thread for the customization:

http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/t/294867.aspx

Chris, what did you mean by "sfl clone" with this:

"Using this, the SFT could be replaced by an u-boot SPL that would be downloaded to IRAM by an sfl clone and then would accept a firmware image transferred via the serial port using the YMODEM protocol."

-> Was it a typo and you meant "sft clone"?

Laszlo Papp said:

Is there such a board config available? We also have a board based on that IC, and it would be some help if we could use that.

Laszlo Papp said:

PS.: do you know what configurations I should modify in the device.{h,c} files? They look a bit too long for getting this done within a couple of seconds. :-) This is the datasheet for the DDR2 SDRAM, fwiw: http://download.micron.com/pdf/datasheets/dram/ddr2/1GbDDR2.pdf

See http://processors.wiki.ti.com/index.php/Serial_Boot_and_Flash_Loading_Utility_for_OMAP-L138#Modifications_for_Custom_Boards

Laszlo Papp said:

Chris, what did you mean by "sfl clone" with this:

"Using this, the SFT could be replaced by an u-boot SPL that would be downloaded to IRAM by an sfl clone and then would accept a firmware image transferred via the serial port using the YMODEM protocol."

-> Was it a typo and you meant "sft clone"?

I meant sfh. So a program that first downloads the UART SPL and then transmits the u-boot image via ymodem. Then u-boot is executed on the board and you can use it to flash a firmware image to flash.

Thank you for your answers. Very much appreciated!

Do you know why TI did not establish a configuration file for the custom board settings as opposed to rebuilding the SFT if you need some specific settings?

Also, it seems they have hard coded C:\\ ... windows specific toolchain paths. I guess one needs to change that manually when building on Linux, or is there a cleaner way?

When I run make manually, I am still getting errors for the DSP toolchain part, but at least the .bin and .out files are already generated at that stage. Is it normal? Is there a way to tell the build system explicitly to only rebuild with the ARM toolchain, and ignore the DSP binaries?

No, there is no such configuration for the OMAP-L138 available (SPL configuration for booting from UART). There is only the one for the AM33xx SoC that I mentioned above.

I meant to ask for a customized SFT config, not SPL config. I know the two alternative technologies are mixing up here, so I thought I would clarify this.

I think it would be easier to get the SFT done because the common u-boot SPL framework was not applied properly to the da850evm-like boards.