[U-Boot] [PATCH v4 00/17] arm: rpi: Enable USB, Ethernet, MMC, Video driver model on Raspberry Pi

[Tom Rini]

On Fri, Mar 31, 2017 at 10:34:35PM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On 31 March 2017 at 22:19, Simon Glass <sjg at chromium.org> wrote:
> > Hi Tom,
> >
> > On 6 February 2017 at 08:32, Simon Glass <sjg at chromium.org> wrote:
> >>
> >> Hi Tom,
> >>
> >> On 23 January 2017 at 10:22, Tom Rini <trini at konsulko.com> wrote:
> >> > On Fri, Jan 20, 2017 at 07:07:35AM -0700, Simon Glass wrote:
> >> >
> >> >> Raspberry Pi uses a DWC2 USB controller and a SMSC USB Ethernet adaptor.
> >> >> Driver model support for these is available.
> >> >>
> >> >> This series does the following:
> >> >> - Enable CONFIG_DM_ETH and CONFIG_DM_USB on Raspberry Pi
> >> >> - Convert the MMC driver to driver model
> >> >> - Convert the video driver to driver model
> >> >> - Fixes a driver model video bug which accessed beyond the frame buffer
> >> >> - Fixes start-up of MMC with driver model (e.g. at present it does not
> >> >>     support env_fat)
> >> >> - Clean up a few loose ends
> >> >>
> >> >> With Ethernet active the device list looks something like this:
> >> >
> >> > There's something wrong with the ethernet changes, at least on RPi 3.
> >> > The test.py TFTP test fails as the CRC32 on the file doesn't match, so
> >> > something got corrupted along the way.  I haven't thrown my monitor and
> >> > USB keyboard on the Pi yet to try out the video parts.  Thanks!
> >>
> >> OK, I will take a look at the CONFIG_DM_ETH patch. Feel free to pick
> >> up the other patches if you like.
> >
> > I have been able to repeat this. The problem (strangely) appears to be
> > that invalidate_dcache_range() does not work correctly. The symptom is
> > that only the first half of the first block of file data is received
> > (the rest is zeroes).
> >
> > There is something odd about this on armv8. For one thing it uses the
> > same function for invalidate and flush, which clearly cannot work if
> > the buffer has been modified by the CPU since it was last used. In
> > fact we do this in the dwc2.c driver But armv7 doesn't have this
> > problem and the problem repeated on rpi2. On the original rpi the
> > problem does not occur.
> >
> > If I change the invalidate_dcache_range() call in transfer_chunk() in
> > drivers/usb/host/dwc2.c to invalidate_dcache_all() then everything
> > works.
> >
> > If I put a flush_dcache_range() call immediately after the call at the
> > top (in the if (!in && xfer_len) block) then it works. This is making
> > sure that the CPU doesn't have that data cached.
> >
> > If I I try the tftpboot a second time it seems to work. In fact things
> > settle down after a few block transfers and the rest of the file seems
> > OK.
> >
> > If I disable the cache ('dcache off') then it works.
> >
> > I tried creating a new invalidate_dcache_range() function on armv8 to
> > use 'dc ivac' instead of 'dc civac' but no dice.
> >
> > I cannot really explain why it works correctly without DM for USB, or
> > why rpi is unaffected.
> >
> > So in summary there is definitely a bug somewhere, but I cannot see
> > where exactly it is. Ideas welcome!
> 
> I forgot to mention that I can easily create a patch to make the dwc2
> USB driver work, by using separate input and output buffers. That way
> the CPU will (likely) never cache incoming data and the
> clean/invalidate is fine. I've tested this and it seems to work.
> 
> But I must be missing something.

And you've since fixed it I believe and I'm testing that PR now.  Can
you re-spin this series when you have time?  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170405/32e2a139/attachment.sig>