[U-Boot] arm: cache: misaligned operation with fastboot

[Steve Rae]

On Fri, Mar 3, 2017 at 9:27 AM, Gary Bisson <gary.bisson at boundarydevices.com
> wrote:

> Hi Steve,
>
> On Fri, Mar 3, 2017 at 12:03 AM, Steve Rae <steve.rae at raedomain.com>
> wrote:
> >
> > Hi Gary,
> >
> > On Thu, Mar 2, 2017 at 3:12 AM, Lukasz Majewski <lukma at 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 at 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