Memory Import Significantly Slower Than Executable Download

[cpyocum]

I am developing a new board support package for a custom LS1021A-based board. As part of initial development, I am loading U-Boot onto the board using the JTAG because there is a problem with the flash chips. Since CodeWarrior requires an ELF file and the standard U-Boot ELF file doesn't include the device tree binary, I am re-importing the `u-boot.bin` file right after I start the debug session. This is an acceptable workaround for me since we'll have the flash up and running sometime soon, but I noticed something peculiar.

When I start the debug session, CodeWarrior is able to download the program (~565kB) in about 17 seconds. When I use the "Memory" tab to reload the `u-boot.bin` file (also ~565kB), it takes about 70 seconds. The factor of 4 made me think that this could be a 1-byte-write vs 4-byte-write thing, so I looked at making a Target Task both to speed up the repeatability of the operation and configure the "Access Size" of the write and maybe save myself a minute.

After creating a Memory import target task, configuring the correct address, selecting the file, and setting the File Type to "Raw Binary", attempting to run the Target Task does not appear to work. A dialog box briefly pops up, but disappears almost immediately. I've verified that the write doesn't take place by attempting to boot U-Boot and verifying that U-Boot fails to find the device tree binary.

I have tried all 4 types of address space (Physical, Physical Cache-coherent, Virtual Secure and Virtual Non-Secure) and all Access Size options, and the behavior is the same. Even though the "Fill pattern:" box gets grayed out, I set the "Number of elements:" field to "0x10000", which is enough to cover the 565kB size of the binary. This succeeds only in keeping the dialog box open longer, but still doesn't appear to actually import the binary file into memory as observed by U-Boot failing to boot when resuming the program.

So, I have two separate lines of inquiry:

1. Why is the memory monitor import ~4 times slower than the initial binary load? Can I speed it up somehow?

2. Have I misconfigured my Memory Import Target Task? Has anyone successfully used it to import large binary files?

[yipingwang]

Hello Charles Yocum,

You need to to use CodeWarrior to connect to the target board with RAM connect launch configuration, then create and configure Import/Export/Fill Memory Action task to import u-boot.bin to the specific location in memory, then execute this target task. Please note LS1021 uses fixed memory map, DDR RAM address starts at 0x80000000.

In addition, you could use Debugger Shell command to write file contents to memory.

After connect CodeWarrior to the target board with RAM connect launch configuration, please open Debugger Shell panel from Window->Show View->other->Debugger Shell, and use "restore" command to write u-boot.bin to DDR memory.

restore -h <filename> [[<ms>:]<addr>|+<offset>] [8bit|16bit|32bit|64bit]
restore -b <filename> [<ms>:]<addr> [8bit|16bit|32bit|64bit]

Command Description
-h|-b Specifies the input file format as hex or binary.
[<ms>:]<addr> Address to load to. For hex format, this selection overrides the address specified in the file. For architectures with multiple memory spaces, a memory space id may be specified.
<offset> Loads the contents of the hex file at an offset of the original location.
8bit|16bit|32bit|64bit Controls the memory access size.

For example

restore -b dat.bin 0x20

Loads the contents of binary file dat.bin into memory beginning at 0x20.

Have a great day,
TIC

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[cpyocum]

Following your instructions, I am able to reload the u-boot binary in the same amount of time as it takes using the Debugger Console.

However, I still don't understand why the memory import target task isn't working using the same file and target address. You mentioned the LS1021ATWR's memory map - are you saying that I should be using an address relative to the 0x80000000 base? (I have been using the absolute address of 0x8200000, the same as what works for the "restore" command in the console).

Also, none of this explains why Memory Monitor is so slow to import, relative to these other methods.

Finally, I noticed a rather large discrepancy in throughput based on the size of the file being imported when using the "restore" command in the Debugger console. The U-Boot binary, 567 kB, will transfer in 18 seconds (about 31.9 kB/second). With files exceeding about 3 mB, this drops down to about 10 kB/second. I'm seeing 10.9 kB/s for a 3.4 mB file, 10.8 for a 3.7 mB file and finally 10.7 for a 22 mB file. It would be really nice if I could transfer those larger files in 1/3 the time.