AnsweredAssumed Answered

Memory Import Significantly Slower Than Executable Download

Question asked by Charles Yocum on Aug 30, 2018
Latest reply on Sep 5, 2018 by Charles Yocum

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?

Outcomes