On 04/13/2015 11:29 AM, Simon Glass wrote:
Hi Stephen,
On 13 April 2015 at 11:04, Stephen Warren <swar...@wwwdotorg.org> wrote:
On 04/13/2015 10:27 AM, Stephen Warren wrote:
On 04/08/2015 09:11 PM, Simon Glass wrote:
(Correcting address for Masahiro, sorry)
On 8 April 2015 at 21:07, Simon Glass <s...@chromium.org> wrote:
Hi,
I have quite a few patches queued up in the next branch of u-boot-dm,
ready for when the merge window options.
If anyone has time and can give it a spin on their board, it would be
much
appreciated!
On Jetson TK1, there's something up with USB.
...
... and here's u-boot-dm/next
Tegra124 (Jetson TK1) # usb start
starting USB...
USB-1: USB EHCI 1.10
scanning bus 0 for devices... 1 USB Device(s) found
USB-1: USB EHCI 1.10
scanning bus 1 for devices... EHCI timed out on TD - token=0x80008d80
USB device not accepting new address (error=2)
EHCI timed out on TD - token=0x80008d80
USB device not accepting new address (error=2)
4 USB Device(s) found
scanning usb for ethernet devices... 0 Ethernet Device(s) found
I saw that too, and not just on Tegra. But in my testing it didn't
happen on every run and it happened before and after switching to
driver model. Can you check by running it 5 times?
I saw a report of this problem on the mailing list so figured it was
unrelated. For now I can remove this patch from dm/next, but I'll wait
to hear from you.
I already checked the bisect result 5 times on the bad and immediately
preceding good commit.
...
Seaboard/Springbank appears to have the same issue. Additionally, the
flashing process spews a ton of:
ERROR: v7_dcache_inval_range - start address is not aligned - 0x3f77a428
ERROR: v7_dcache_inval_range - stop address is not aligned - 0x3f77ac28
This is supposed to use alloc_priv() in drivers/core/device.c to
allocate a DMA-aligned address. I wonder which buffer is causing this
problem? I'll check it out on seaboard - I did most of my testing on
Jetson only a sanity check on seaboard, so perhaps something broke in
the meantime.
It looks like this one in tegra_nand.c:nand_rw_page():
dma_prepare(buf, 1 << chip->page_shift, is_writing);
... which is odd since I thought that "buf" was simply the user-supplied
buffer, incremented by the NAND page size each time. I'll trace through
the code a bit more.
Both of those bisect to:
7bf0b2d00982 dm: usb: tegra: Move to driver model for USB
I wonder if the NAND issue is just a bug that's triggered by stack/data
layout changes, and that commit tickles it?
Which NAND issue?
The cache alignment errors during NAND write.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
