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@chromium.org wrote:
Hi Tom,
On 6 February 2017 at 08:32, Simon Glass sjg@chromium.org wrote:
Hi Tom,
On 23 January 2017 at 10:22, Tom Rini trini@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!