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

[Simon Glass]

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.

Regards,
Simon