On Fri, Mar 3, 2017 at 9:27 AM, Gary Bisson <gary.bisson@boundarydevices.com
wrote:
Hi Steve,
On Fri, Mar 3, 2017 at 12:03 AM, Steve Rae steve.rae@raedomain.com wrote:
Hi Gary,
On Thu, Mar 2, 2017 at 3:12 AM, Lukasz Majewski lukma@denx.de wrote:
Hi,
Hi Fabio, Lukasz,
On Wed, Feb 15, 2017 at 02:24:40PM -0200, Fabio Estevam wrote:
On Wed, Feb 15, 2017 at 2:04 PM, Gary Bisson gary.bisson@boundarydevices.com wrote:
Hi,
I've been testing fastboot to flash a sparse image on a i.MX6Q platform (Nitrogen6x) with U-Boot v2017.01.
This test shows a lot of "misaligned operation" traces: => fastboot 0 Starting download of 415679660 bytes ... downloading of 415679660 bytes finished Flashing sparse image at offset 82124 Flashing Sparse Image CACHE: Misaligned operation at range [12000028, 12028028] CACHE: Misaligned operation at range [12028044, 1208f044] CACHE: Misaligned operation at range [1208f060, 123fd060] ...
Has any of you seen that behavior?
Note that this behavior only happens for sparse images, flashing a raw image doesn't exhibit the problem.
<snip> yes -- I have seen these warning messages when flashing a "sparse"
image....
- they don't seem to cause any issues,
True, the flashing process is successful. But avoiding those warnings would provide a better user experience. We've had customers asking for it since to them it looks like something isn't copied properly.
- I haven't had time to investigate yet....
Well the whole image is downloaded to an aligned address which is fine. But then the header is skipped which gives a non-aligned data address for the write command: http://git.denx.de/?p=u-boot.git;a=blob;f=common/image- sparse.c;hb=HEAD#l153
Here is the backtrace when that happens (not sure if it helps): http://pastebin.com/Qun8uMXq
Not sure what would be the proper way to fix, copy the buffer to align it seems inefficient.
Regards, Gary
So, here is the explanation (that I think you already understand): In the code that I am testing, the "sparse" image is 350,723,024 bytes and is downloaded into an aligned buffer on the device. This image/buffer contains a header ('a') and 13903 "chunks" (b1/c1 through bx/cx): +---+----+----+----+----+ +----+----+ | a | b1 | c1 | b2 | c2 | ... | bx | cx | +---+----+----+----+----+ +----+----+ where: a = the "sparse image" header (28 bytes) b* = the "chunk" header (12 bytes) c* = the "chunk" data (which is always an exact multiple of CONFIG_SYS_CACHELINE_SIZE) Whenever the "chunk" type is CHUNK_TYPE_RAW, then the data in the current 'c' (the "chunk" data) needs to be written into the flash as is, using the pointer to the first byte of this 'c' as the starting address for the blk_dwrite(). Because of the 28 byte image header, and the 12 byte "chunk" header(s), it is extremely unlikely that this starting address will be aligned - resulting in many "CACHE: Misaligned operation at range [XXXX, YYYY]" messages while these 13093 "chunks" are processed. In the code that I am testing, this message is being generated by the call to flush_cache(start_addr, trans_bytes) in the sdhci_send_command() function.
Gary, I agree that copying each "chuck data" to an aligned buffer before calling blk_dwrite() in order to avoid this message would be highly inefficient -- the desire is to download the code and flash it as fast as possible! Therefore, I will propose a patch which provides a runtime flag to suppress this warning message, which is used when processing these fastboot "sparse" images.
Thanks, Steve