[U-Boot] Testing u-boot-dm/next

[Stephen Warren]

On 04/13/2015 11:29 AM, Simon Glass wrote:
> Hi Stephen,
>
> On 13 April 2015 at 11:04, Stephen Warren <swarren at 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 <sjg at 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.