[U-Boot] [PATCH 2/4] net: round up before calling flush_cache
Marek Vasut
marex at denx.de
Sun Apr 1 17:35:18 CEST 2012
Dear Stefano Babic,
> On 01/04/2012 15:46, Marek Vasut wrote:
> > Dear Stefano Babic,
>
> Hi Marek,
>
> >> If the range passed to flush_cache is not multiple
> >> of ARCH_DMA_MINALIGN, a warning due to mislaignment
> >> is printed.
> >> Detected with fec_mxc, mx35 boards:
> >>
> >> CACHE: Misaligned operation at range [80800000, 8083c310]
> >>
> >> Signed-off-by: Stefano Babic <sbabic at denx.de>
> >> CC: Marek Vasut <marex at denx.de>
> >> CC: Joe Hershberger <joe.hershberger at gmail.com>
> >> Cc: Wolfgang Denk <wd at denx.de>
> >> ---
> >>
> >> common/cmd_net.c | 2 +-
> >> 1 files changed, 1 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/common/cmd_net.c b/common/cmd_net.c
> >> index 65f32bc..a500919 100644
> >> --- a/common/cmd_net.c
> >> +++ b/common/cmd_net.c
> >> @@ -256,7 +256,7 @@ static int netboot_common(enum proto_t proto,
> >> cmd_tbl_t *cmdtp, int argc, }
> >>
> >> /* flush cache */
> >>
> >> - flush_cache(load_addr, size);
> >> + flush_cache(load_addr, roundup(size, ARCH_DMA_MINALIGN));
> >
> > This ain't gonna slide. You might overwrite something, even though this
> > is just loading into memory, right?
>
> Really we do not reserve space before a network transfer and we pass
> only the start address (load address) where the file is copied. It is
> not known its size before the transfer. So maybe it is not important up
> to further 31 bytes are flushed ;-)
>
> Anyway, for my understanding: we are calling a function to flush caches.
> This means that if the size is something more as required there will be
> a cache hit misseing, and the SOC will load data again - but without
> corrupt data, right ?
Sure, but you can flush data into the RAM that should have never been flushed to
the ram in the first place and that might confuse some controller -- or I might
be overly paranoid.
>
> > I'm not quite sure how to handle this kind of
> > unaligned access.
>
> Well, my first goal was to explain which is the cause of the
> misalignment I found last friday testing Anatolij's patch, proofing that
> it is not due to last FEC patches ;-)
>
> > But adding at least if (unaligned) debug(...); to aid people easily
> > finding these trouble would be nice ;-)
>
> Not sure - where should be inserted or what do you exactly mean? size
> is the length of the transfered bytes, and can assueme any value, so it
> is often not aligned.
Well just before the cache-line aligning.
> Best regards,
> Stefano Babic
Best regards,
Marek Vasut
More information about the U-Boot
mailing list