[U-Boot] [PATCH] nios2: convert cache flush to use dm cpu data

Marek Vasut marex at denx.de
Sat Oct 17 13:44:11 CEST 2015


On Saturday, October 17, 2015 at 05:22:41 AM, Thomas Chou wrote:
> Hi Marek,

Hi!

> On 10/17/2015 07:03 AM, Marek Vasut wrote:
> >> I would suggest the "cache alignment check and skip" be removed from
> >> cache flush ops, and say out the DMA buffer allocation rule loudly in
> >> README, and enforce it by guardianship.
> > 
> > What exactly do you envision by this "guardianship" ?
> 
> I mean the reviews of custodians.

Wouldn't an automated check be better ? It's easier and costs almost nothing.
Besides, custodians are not perfect and cannot detect all the issues.

> >> Please allow me to restate the reasons,
> >> 
> >> 1. The cache flush ops are commonly used. Please refer to the "Cache and
> >> TLB Flushing Under Linux" doc, linux/Documentation/cachetlb.txt.
> >> Violating the defined interface is much worse than violating coding
> >> style. It will certainly impact the portability of u-boot. And might
> >> introduce more bug than resolve.
> > 
> > I agree with this one.
> > 
> >> 2. We all agree that enforcing DMA buffer allocation to cache aligned is
> >> the only real solution. Adding such "check and skip" to cache flush ops
> >> cannot prevent the flush or solve the problem.
> > 
> > We should probably check-scream-skip here.
> > 
> >> 3. Though the flush size of block device are usually aligned, the size
> >> of packet are not. Asking the packet drivers to adjust the flush size
> >> does not make sense. It is the job of cache flush ops. The debug probe
> >> should not override the original purpose. It should be spelled for
> >> common understanding.
> > 
> > The socket buffer(s) should be aligned, so network packets should be
> > fine.
> 
> While the start of socket buffer might be aligned, the size of the
> transfer might not for the send ops. It is depended on the net/tcp/ip
> packets size.

Aurgh :-( Now I see what you mean. This is purely bad, very bad. Here is
a real possibility for corruption of variables close to the allocated DMA
buffer, right ?

> For example, with tftp, there is a lot of unaligned end of packets.
> 
> tftp d1000000 u-boot-dtb.bin
> 
> flush unaligned d7ff7020-d7ff704e
> [repeat ..]
> 
> So, such an alarm may be false. And such a skip can be bug.
> 
> In fact, for my own projects, I have changed the memory allocation to
> always cache aligned. And I rarely worry about it ever after.
> 
> I look at the net.c of u-boot. There are packets buffer allocated on BSS
> and stack. I would suggest avoid such programming, and use aligned
> memory allocation stead.

The stack allocation there is used because it's slightly faster and you don't
need mallocator for that. I guess this is a topic for a broader discussion and
we should include Tom and others into it. Would you mind starting another thread
on the ML and CCing me, Tom Rini, Simon Glass etc please ?

Best regards,
Marek Vasut


More information about the U-Boot mailing list