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

[Simon Glass]

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.

Regards,
Simon