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

[Simon Glass]

Hi Stephen,

On 13 April 2015 at 11:46, Simon Glass <sjg at chromium.org> wrote:
> Hi Stephen,
>
> On 13 April 2015 at 11:36, Stephen Warren <swarren at wwwdotorg.org> wrote:
>>
>> 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.
>
> Ah OK, I thought you were saying this was a USB issue. I can't see how
> the driver model updates would affect NAND except as you say, that the
> commit changes the data/bss section layout.
>
> For now I'm going to drop this commit from dm/next, since it might
> take a bit of time to figure things out.

I've pushed a new u-boot-dm/next if you'd like to try it.

Regards,
Simon