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

[Simon Glass]

Hi Tom,

On 5 April 2017 at 07:41, Tom Rini <trini at konsulko.com> wrote:
> 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!

OK I have resent it without the dmc2 patch.

My preferred fix for the problem is this:

http://patchwork.ozlabs.org/patch/746917/

Regards,
Simon