From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Glass Date: Fri, 31 Mar 2017 22:34:35 -0600 Subject: [U-Boot] [PATCH v4 00/17] arm: rpi: Enable USB, Ethernet, MMC, Video driver model on Raspberry Pi In-Reply-To: References: <20170120140752.16296-1-sjg@chromium.org> <20170123182255.GZ10853@bill-the-cat> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Tom, On 31 March 2017 at 22:19, Simon Glass wrote: > Hi Tom, > > On 6 February 2017 at 08:32, Simon Glass wrote: >> >> Hi Tom, >> >> On 23 January 2017 at 10:22, Tom Rini 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