OMAP-L137 UART slave boot specifics

Stephen Bialkowski

Other Parts Discussed in Thread: OMAP-L137

Hi,

It took roughly 20 minutes to complete the following AIS boot, with an AIS file size ~0.5MB, using OMAP-L137 UART Boot Host, Ver. 1.01. The AIS file was generated from a relatively large *.sym file targetting the OMAP-L137 (as opposed to the DSP). The idea is to see if this is any faster than KERMIT/u-boot. It clearly is not.

I get the impression 20 minutes is not within the normal time range it could take to transmit this file. Are there ways to cut this time down?

UART Boot Host output:

(File IO): Read 557176 bytes from file C:\ais.out.
(Serial Port): Opening COM7 at 115200 baud...
(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: 0x5853590D.
(AIS Parse): Performing Opcode Sync...
(AIS Parse): Executing function...
(AIS Parse): Processing command 1: 0x58535907.
(AIS Parse): Performing Opcode Sync...
(AIS Parse): Loading boot table...
(AIS Parse): Processing command 2: 0x5853590D.
(AIS Parse): Performing Opcode Sync...
(AIS Parse): Executing function...
(AIS Parse): Processing command 3: 0x58535901.
(AIS Parse): Performing Opcode Sync...
(AIS Parse): Loading section...
(AIS Parse): Loaded 539924-Byte section to address 0xFE014000.
(AIS Parse): Processing command 4: 0x58535901.
(AIS Parse): Performing Opcode Sync...
(AIS Parse): Loading section...
(AIS Parse): Loaded 9232-Byte section to address 0xFE098000.
(AIS Parse): Processing command 5: 0x58535901.
(AIS Parse): Performing Opcode Sync...
(AIS Parse): Loading section...
(AIS Parse): Loaded 7908-Byte section to address 0xFE09A434.
(AIS Parse): Processing command 6: 0x58535906.
(AIS Parse): Performing Opcode Sync...
(AIS Parse): Performing jump and close...
(AIS Parse): AIS complete. Jump to address 0xFE045554.
(AIS Parse): Waiting for DONE...
(AIS Parse): Boot completed successfully.
(Serial Port): Closing COM7.

Contents of AISgen.log:

; Created by AISgen for D800K005 v0.8.2.0

[General]
BootMode = NONE
crcCheckType = NO_CRC

[PLLANDCLOCKCONFIG]
PLLCFG0 = 0x18010202
PLLCFG1 = 0x000501B9
PERIPHCLKCFG = 0x00010064

; DIV4p5
[AIS_Set]
TYPE = 0x00020004
ADDRESS = 0x01C14188
DATA = 5
SLEEP = 0

[EMIF3SDRAM]
SDCR = 0x00018421
SDTIMR = 0x0E9129C8
SDTIMR2 = 0x78080005
SDRCR = 0x000003FC

[PINMUX]
REGNUM = 0
MASK = 0xFFFFFFFF
VALUE = 0x11112188

[PINMUX]
REGNUM = 1
MASK = 0xFFFFFFFF
VALUE = 0x11111111

[PINMUX]
REGNUM = 2
MASK = 0xFFFFFFFF
VALUE = 0x11111111

[PINMUX]
REGNUM = 3
MASK = 0xFFFFFFFF
VALUE = 0x11111111

[PINMUX]
REGNUM = 4
MASK = 0xFFFFFFFF
VALUE = 0x11111111

[PINMUX]
REGNUM = 5
MASK = 0xFFFFFFFF
VALUE = 0x11111111

[PINMUX]
REGNUM = 6
MASK = 0xFFFFFFFF
VALUE = 0x11111111

[PINMUX]
REGNUM = 7
MASK = 0xFFFFFFFF
VALUE = 0x11111111

[PINMUX]
REGNUM = 8
MASK = 0xFFFFFFFF
VALUE = 0x21122111

[PINMUX]
REGNUM = 9
MASK = 0xFFFFFFFF
VALUE = 0x11011112

[PINMUX]
REGNUM = 10
MASK = 0xFFFFFFFF
VALUE = 0x22222221

[PINMUX]
REGNUM = 11
MASK = 0xFFFFFFFF
VALUE = 0x11142222

[PINMUX]
REGNUM = 12
MASK = 0xFFFFFFFF
VALUE = 0x11111111

[PINMUX]
REGNUM = 13
MASK = 0xFFFFFFFF
VALUE = 0x22111111

[PINMUX]
REGNUM = 14
MASK = 0xFFFFFFFF
VALUE = 0x88222222

[PINMUX]
REGNUM = 15
MASK = 0xFFFFFFFF
VALUE = 0x21888888

[PINMUX]
REGNUM = 16
MASK = 0xFFFFFFFF
VALUE = 0x11111112

[PINMUX]
REGNUM = 17
MASK = 0xFFFFFFFF
VALUE = 0x00100111

[PINMUX]
REGNUM = 18
MASK = 0xFFFFFFFF
VALUE = 0x11111111

[PINMUX]
REGNUM = 19
MASK = 0xFFFFFFFF
VALUE = 0x00000001

-ini AISgen.ini -o "C:\ais.h" -otype carray:nvram_image "\\Mac\Home\Desktop\procnto-instr.sym"

-----------------------------------------------------
TI AIS Hex File Generator for OMAP-L137
(C) 2012, Texas Instruments, Inc.
Ver. 1.27
-----------------------------------------------------

Begining the AIS file generation.
AIS file being generated for bootmode: NONE.
Parsing the input object file, \\Mac\Home\Desktop\procnto-instr.sym.
AIS file generation was successful.
Wrote 1672767 bytes to file C:\ais.h.
Conversion is complete.

over 6 years ago

0 Cvetolin Shulev-XID over 6 years ago

TI__Guru 65405 points

The team is notified. They will post their feedback directly here.

BR
Tsvetolin Shulev

0 Rahul Prabhu over 6 years ago

TI__Guru** 114410 points

Can you step and explain what is the usecase and what you are trying to test in this setup. Both OMAPL137 and C6747 devices are DSP boot master so UART booting on both the devices is processed by the DSP. Given the UART is configured at 115200 baud rate should take less than a minute even with re-transmissions and protocol delay.

The size of the output ais. is 1672767 bytes which is much larger than the 0.5 MB that you indicated in the post. Is this is different file. Even with that size the transfer time is unusually high. Also indicate if you are trying this on the EVM or on custom HW. If custom HW what is the input clocks. Is there an option to connect a UART analyzer in your setup ? In the load process where doesn`t the device take the most amount of time in the PLL config, section load or function execute

Regards,
Rahul

0 Stephen Bialkowski over 6 years ago in reply to Rahul Prabhu

Intellectual 450 points

Rahul,

Thanks for taking the time to dig through these details. I am currently using the Digital Spectrum eval board. The boot order was a total oversight. My apologies. I was trying to understand how long it would take to load a relatively larger file onto the ARM core of the digital spectrum eval board. I had since written a new host that wrote a binary to SDRAM. The results are on par with the theoretical throughput. So we are good there.

The current goal is to write an ARM binary to SDRAM, then eventually get it into flash on a custom board. The image size will be > 3MB. To further complicate the issue, we want to see if we can get away with using UART only in our custom boards. We will want to speed up the transfer. I will experiment with 10mbps RS-422/UART2. If we can't speed up the transfer, I may push for bringing out the lines of a high-speed peripheral.

Perhaps the best strategy is: load a DSP image that speeds up the UART clocks, downloads and writes the OMAP image to SDRAM, enables the ARM core. Do you anticipate any issues with this strategy?

Final question: I noticed there are, not 1, but 3 section load commands in the *.h file resulting from AISgen. I am confused by the addresses in these commands.

0x58535901, //section load command
0xFE014000, //address
0x00083D14, //size

0x58535901,
0xFE098000,
0x00002410,

0x58535901,
0xFE09A434,
0x00001EE4,

I can't seem to find these addresses in the memory maps in SPRS563G. Can you clarify what should be accomplished here, and why there are 3 section load commands?

Thanks!

Stephen

0 Rahul Prabhu over 6 years ago in reply to Stephen Bialkowski

TI__Guru** 114410 points

Stephen Bialkowski said:
Perhaps the best strategy is: load a DSP image that speeds up the UART clocks, downloads and writes the OMAP image to SDRAM, enables the ARM core. Do you anticipate any issues with this strategy?

As long as the UART host loader can switch from transferring image initially with 115.2 kbps to higher speed for the second stage then I don`t see any issues. However, you will need to implement UART protocol in your second stage using XMODEM or equivalent as you would have exitted the bootROM.

the address in your AISGen file is odd. the section load command is processed by the AISGen tool and the bootROM to load contiguous initialized code/data memory in the application binary. for example you can look at the map file to see if that address corresponds to .text section in the output binary.

Here is an example of .text section being converted to section load in the output binary.

If you provide map files and out files for the DSP and ARM binary then we might be able provide more insight on why the tool populates that address in the section load.

Regards,

Rahul

0 Stephen Bialkowski over 6 years ago in reply to Rahul Prabhu

Intellectual 450 points

Interesting. It should have occurred to me the addresses would be pulled from binary. I want to clarify what circumstances require an additional load section command. Is it accurate to say there will be exactly one load section command for each contiguous initialized section (e.g. two .text sections separated by a hole)? Is there more to it than this?

0 Rahul Prabhu over 6 years ago in reply to Stephen Bialkowski

TI__Guru** 114410 points

Stephen,

My understanding of the ELF parser in AISGEN is that it looks for code/data section that are contiguous and will skip over and create a new section load in the AIS binary if there is a memory hole so you should see a section load for all sections that need initialization or contain code.

Glad to know that I could provide more clarity to your use case. Let me know if you have any further questions.

Regards,
Rahul

0 Stephen Bialkowski over 6 years ago in reply to Rahul Prabhu

Intellectual 450 points

Rahul,

I created a secondary boot loader, that is again loaded via OMAP-L137 UART Boot Host, Ver. 1.01. It works. But, it takes about 42 seconds to transfer 19,500 bytes. This is much slower than the theoretical throughput (19500B / (115200/10)B/s = 1.7 seconds). We would like to get closer to the theoretical throughput during mass production. The setting of registers takes only a few seconds. It's the raw binary transfer that takes the most time here. I understand the section load command will write the address, then size, and then the entire binary one byte at a time. Upon inspecting the AISParse.cs example code, I found a delay of 0 after each byte written. I presume this equates to sleep(0) under the hood. I suppose giving up the processor after every 10 bit transfer could be slowing the transfer. That being the case, I'm not sure it would even make sense to write another boot loader...

Can you provide any insight here?

Thanks!

Stephen

EDIT: disregard. I created a master host that eliminates the delays.

Processors

Processors forum

OMAP-L137 UART slave boot specifics