Hi Tom,
On 6 February 2017 at 08:32, Simon Glass <s...@chromium.org> wrote:
>
> Hi Tom,
>
> On 23 January 2017 at 10:22, Tom Rini <tr...@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!
Regards,
Simon
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
