L138 ARM boot sequence

Hi Jeff,

Thanks for reply.

So, I guess ARM ROM boot loader is pre-loaded in every single TI OMAP L138 at the factory ? Most probably we are not able to modify this ?

In our final product, we are planning to get rid of U-boot. I guess UBL is from TI, do we need license if we are going to use UBL (or modify it) in our final product ?

As we are using VxWorks in our final product, the boot sequence will most probably as below:

ARM ROM boot loader -> UBL -> VxWorks bootrom

rgds,

kc Wong

Thanks, Jeff.

What actually is AISGen tool doing ?

What does bootable AIS image mean ? I just wonder because you mentioned U-boot can be converted to bootable AIS image to replace UBL.

Does it mean that any image also can be converted to bootable AIS image ?

rgds,

kc Wong

Hi Jeff,

Thanks for reply.

Let say I have modified the UBL, do I need to know the address of the flash where I will have to store the new UBL ?

Or the flash loading utility will know where to store the UBL ? By the way, any documentation that says about the memory map for the flash on Logic PD eXperimenter Kit ?

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

Any documentation that says about what does the default UBL do ? Or I have to read the code to figure up ?

I got the UBL from DaVinci-PSP-SDK-03.20.00.11.

rgds,

kc Wong

Hi Jeff,

Thanks for reply. I will look at the UBL code to figure out.

One question about U-boot, does U-boot do any hardware initialization or any of its functionality is needed by the subsequent boot loader ? I believe all the hardware initialization is in the UBL, and none is in U-boot, am I right ?

I just want to make sure there is no dependency on U-boot, and it can be removed entirely from the boot sequence.

rgds,

kc Wong

Hi Jeff,

I am looking at the L138 EVM SPI boot sequence. There is a function SPIBOOT_copy in spiboot.c.

Inside the function, the first thing it reads from flash is a header. After that, U-Boot is loaded from flash into its link address and jump to there.

I just wonder where does the header comes from ? I look at the U-Boot image, it is not there.

UBOOT header : (magicnumber, entry, appsize , ldAddress) - (0xA1ACED00 ,0xC1080000 ,0x00055848 ,0xC1080000 )

I am suspecting this information is placed there by the Serial Flasher Host (sfh_OMAP-L138.exe). Is this the case ?

rgds,

kc Wong

Yes that is correct. The serial flash host places the header that the UBL expects.

Jeff

Hi Jeff,

If these information hard coded in the serial flash host ?

As I replace U-Boot with other image, the information for the header remains the same except the application size.

rgds,

kc Wong

The magic number is hard coded, the app size is determined from the size of the application, and the start and load addresses are parameters that can be passed in from the command line.

Jeff

I just wanted to get a little clarification on something.  Where does the ubl actually exist on the device? Is it on the ROM or on one of the flash memory devices. Specifically I have an experimenter L138 board and to me it looks like: 

1) Arm ROM boot loader loads the ubl from the spi flash.

2) Which then loads u-boot from the sd/mmc card?

3) And then on to the kernel?

My question is this:

1) Where does the ubl actually exist? Is there some part of the ROM that can be written to?  

2) Where does the slh tool actually write to? Is it writing to ROM or spi?

thanks for any help you can give,

-tony

Hi Tony,

My understanding is, they are (ubl, u-boot, linux kernel) all in the spi flash.

UBL at address 0x0 of the flash and u-boot, at address 0x10000. Not quite sure about linux kernel as we are not using linux

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

There is tutorial and labs "AM1808/OMAP-L138 SOM-M1 U-Boot Software & Labs" from LogicPD. You may access the labs and other documentation after opening a free LogicPD account and registering your kit.

http://support.logicpd.com/auth/downloads/Zoom%20OMAP-L138%20eXperimenter%20Kit/

rgds,

kc wong

KC,

Thanks for getting back to me. The experimenter kit that I have uses an sd card for the u-boot and the kernel. However S7 is set to boot to spi. I tested u-boot on the sd card by removing the sd card, and I don't get the u-boot prompt. I reinstall the sd card and I do get the u-boot prompt and then it boots all the way through to the kernel, or I can stop u-boot and set values as expected. I've also recompiled the kernel and u-boot and used the uflash utility to burn the u-boot onto a clean sd,  so I'm pretty sure that u-boot and the kernel are on the sd not on the spi. The Serail Boot and Flash Loading doc make it sound like they are all on the spi, but from I saw that is incorrect, at least for Linux. 

What is unclear to me is the ubl, spi, and rom. On my board the S7 switch is set to boot to the spi by default, so the rom must be pointing to the spi. All of my questinos are sort of related to that same issues:

1) I've been reading through the OMAP-l1x8 bootloader doc (sprab41c.pdf) . The examples in the docs say that the rom ais file should be built with an executable binary application in them. Can the ais file be built without a binary file, just using an .ini file that points to whatever memory device is holding the next stage of the loader, say ubl for example? Or does the ais file require some sort of application?  

2)  The FlashAndBootUtils zip file contains a whole collection of ais files. All of them are UBL_*.ais. The names make it sound like they are ais files with ubl built into them, or is that just a way that the rom knows what file to look for? If they do have the ubl built into them why even have a ubl as a separate file as is referred to in the Serial Boot and Flash Loading Utility doc talks about?

3) Will the rom boot to whatever memory device is set by the S7 switch regardless of the ais file? Or do the ais file and the S7 switch have to both be set the same way?

I know these are a lot of question, but the docs are pretty confusing on these points.

again thanks for all your help,

-tony

Many of the answers to your primary question about the ROM, UBL, etc. are actually answered in this thread at the beginning.  The ROM on the processor is not changeable; it is read-only.  The ROM is the first thing executed by the ARM CPU when reset is released.  The ROM has code in it that tells the ARM CPU to determine the settings of the boot mode configuration pins and then performs the appropriate action (ie. boot from a particular interface with a particular protocol) as defined in the bootloader document.  If your experimenter kit is configured for SPI flash boot, then this is where the UBL is placed.  The UBL is nothing more than a very small and compact initialization code that can be modified to tailor to your own board's needs, if necessary.  This UBL will setup clocks on the processor, initialize the memory interfaces to support the appropriate timing and then copy u-boot out of the "destined" non-volatile memory device and place it in DRAM.

The AIS format is a scripting format supported by the ROM.  This AIS file will be placed in the non-volatile memory device (ie. SPI flash in your case) and can be parsed by the ROM code.  The AIS format allows for commands to be interpreted by the ROM code and executed, such as writing to device registers to initialize the device.  One can think of this as replacing a small kernel which would need to be used to perform this function (aka. the UBL).  Why do I keep coming back to initializing the device?  Because there is a small amount of internal SRAM on the device which only fits a certain amount of program code and data and u-boot is typically much bigger than what can be held in this internal memory.  Therefore, u-boot needs to be copied into DRAM, BUT how would the ROM code (which can not be changed) know what your specific board's clock frequency and DRAM memory vendor of choice is?  It doesn't.  Therefore, these board specific items need to be handled by the UBL, which can be changed, or through AIS commands which again can be modified.

Anthony Glaser said:

1) I've been reading through the OMAP-l1x8 bootloader doc (sprab41c.pdf) . The examples in the docs say that the rom ais file should be built with an executable binary application in them. Can the ais file be built without a binary file, just using an .ini file that points to whatever memory device is holding the next stage of the loader, say ubl for example? Or does the ais file require some sort of application?  

Ultimately, you will need to have an actual program inside the AIS scripting file.  The ROM code needs to jump to something.

Anthony Glaser said:

2)  The FlashAndBootUtils zip file contains a whole collection of ais files. All of them are UBL_*.ais. The names make it sound like they are ais files with ubl built into them, or is that just a way that the rom knows what file to look for? If they do have the ubl built into them why even have a ubl as a separate file as is referred to in the Serial Boot and Flash Loading Utility doc talks about?

I suspect these are pre-built items.

Anthony Glaser said:

3) Will the rom boot to whatever memory device is set by the S7 switch regardless of the ais file? Or do the ais file and the S7 switch have to both be set the same way?

The S7 switch configures the boot mode configuration pins, which the ROM code will then read and determine which interface to use for booting.

Brandon,

    Thanks for the response, I guess that part of my confusion is in that there are two utilities sfh-OMAP-L138 as well as slh-OMAP-L138. Slh-OMAP-L138 is used just for the ais files while sfh-OMAP-L138 is used for the whole memory device. The fact that there is a separate utility just for the ais file made me suspect that is was doing something with the rom. I do understand that ROM stands for READ ONLY, but none the less, why a separate utitility uf they are both writing to the memory device?

    Then the other thing that's a little confusing is that the Serial Boot and Flash Loading doc talks about the sfh writing the ubl as if it were seperate from the ais, but from what I see the ubl is typically bundled into the ais. Is that correct?

   thanks again for your help,

-tony

This is really starting to get off topic.  Please take a look at the following wiki article which discusses the serial boot and flash loading utilities.

If you still have questions about them, please create a new thread.

1) The UBL exists on the external SPI Flash on the SOM. It can be erase and rewritten as desired.

2) The SLH is the Serial Loading Host, which will parse the AIS file and load the program data to either internal memory or external RAM. The SFH is the Serial Flashing Host, and is used to flash binaries to the boot medium (SPI Flash, NAND, NOR).

Jeff

The experimenter kit comes with a UBL flashed on the SPI flash, which then loads u-boot from the MMC card. The PSP comes with different prebuilt UBLs depending on where u-boot is flashed.

1) While this is possible, this would only work with boot medium that can be directly access from the memory map, such as NOR. The device cannot directly execute code out of NAND, SPI, or any of the other boot modes.

2) The UBL_*.ais files found in the ubl/ directory of the flashing utilities are UBL out files converted to AIS format in order to be bootable. The ROM will look for an AIS file at location 0x0 of the SPI flash, which in this case will be the UBL AIS file. Can you explain what you are referring to in the documentation?

3) The ROM will always boot from the memory device set by S7. The boot loader will parse the UBL AIS file found on the memory device and load sections to different memory regions. Depending on the UBL, it will load UBOOT from another memory device, which could be the same or different from where the UBL is located. The source for the UBLs is included with the PSP and can be viewed to see the exact implementation details.

Jeff