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

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

[Simon Glass]

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!

Regards,
Simon

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

[Simon Glass]

(Correcting address for Masahiro, sorry)


On 8 April 2015 at 21:07, Simon Glass <sjg@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!
>
> Regards,
> Simon
>
>

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

[Przemyslaw Marczak]

Hello Simon,

On 04/09/2015 05:07 AM, Simon Glass 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!
>
> Regards,
> Simon
>

I tested this on Odroid U3.
It looks that everything works fine. I see that ehci_hcd_init() is not 
used, then where can we call the board_usb_init()?

Best regards,
-- 
Przemyslaw Marczak
Samsung R&D Institute Poland
Samsung Electronics
p.marczak at samsung.com

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

[Bin Meng]

Hi Simon,

On Thu, Apr 9, 2015 at 11:11 AM, Simon Glass <sjg@chromium.org> wrote:
> (Correcting address for Masahiro, sorry)
>
>
> On 8 April 2015 at 21:07, Simon Glass <sjg@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!
>>
>> Regards,
>> Simon
>>

I've tested it on CrownBay board and found one issue:

During the boot up, or typing 'sf probe' in the U-Boot shell, it reports:

Invalid bus 0 (err=-19)

I have not investigated but suspect this is due to the CrownBay board
has not been converted to use DM SPI, like Chromebook?

Regards,
Bin

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

[Simon Glass]

Hi Przemyslaw,

On 9 April 2015 at 01:55, Przemyslaw Marczak <p.marczak@samsung.com> wrote:
> Hello Simon,
>
>
> On 04/09/2015 05:07 AM, Simon Glass 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!
>>
>> Regards,
>> Simon
>>
>
> I tested this on Odroid U3.
> It looks that everything works fine. I see that ehci_hcd_init() is not used,
> then where can we call the board_usb_init()?

Thanks for testing.

Can board_usb_init() be called from within the board_init() code
instead? Or are you trying to avoid doing this init unless USB is
actually used? If so, then I'll need to have a think about it.

Regards,
Simon

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

[Simon Glass]

Hi Bin,

On 9 April 2015 at 06:52, Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Simon,
>
> On Thu, Apr 9, 2015 at 11:11 AM, Simon Glass <sjg@chromium.org> wrote:
>> (Correcting address for Masahiro, sorry)
>>
>>
>> On 8 April 2015 at 21:07, Simon Glass <sjg@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!
>>>
>>> Regards,
>>> Simon
>>>
>
> I've tested it on CrownBay board and found one issue:
>
> During the boot up, or typing 'sf probe' in the U-Boot shell, it reports:
>
> Invalid bus 0 (err=-19)
>
> I have not investigated but suspect this is due to the CrownBay board
> has not been converted to use DM SPI, like Chromebook?

All of x86 should use that - it is in arch/x86/Kconfig.

More likely the SPI compatible string is wrong:

compatible = "intel,ich7";

It should be "intel,ich-spi "I think. You can check with 'dm tree' to
see what devices have been found.

Regards,
Simon

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

[Przemyslaw Marczak]

Hello Simon,

On 04/10/2015 07:40 PM, Simon Glass wrote:
> Hi Przemyslaw,
>
> On 9 April 2015 at 01:55, Przemyslaw Marczak <p.marczak@samsung.com> wrote:
>> Hello Simon,
>>
>>
>> On 04/09/2015 05:07 AM, Simon Glass 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!
>>>
>>> Regards,
>>> Simon
>>>
>>
>> I tested this on Odroid U3.
>> It looks that everything works fine. I see that ehci_hcd_init() is not used,
>> then where can we call the board_usb_init()?
>
> Thanks for testing.
>
> Can board_usb_init() be called from within the board_init() code
> instead? Or are you trying to avoid doing this init unless USB is
> actually used? If so, then I'll need to have a think about it.
>
> Regards,
> Simon
>

I noticed, that after changes the USB command doesn't recognize the mass 
storage device. I haven't too much time for checking it deeper.
I will check it on Monday and give you a response.

Best regards,
-- 
Przemyslaw Marczak
Samsung R&D Institute Poland
Samsung Electronics
p.marczak at samsung.com

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

[Simon Glass]

Hi Przemyslaw,

On 10 April 2015 at 11:50, Przemyslaw Marczak <p.marczak@samsung.com> wrote:
> Hello Simon,
>
>
> On 04/10/2015 07:40 PM, Simon Glass wrote:
>>
>> Hi Przemyslaw,
>>
>> On 9 April 2015 at 01:55, Przemyslaw Marczak <p.marczak@samsung.com>
>> wrote:
>>>
>>> Hello Simon,
>>>
>>>
>>> On 04/09/2015 05:07 AM, Simon Glass 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!
>>>>
>>>> Regards,
>>>> Simon
>>>>
>>>
>>> I tested this on Odroid U3.
>>> It looks that everything works fine. I see that ehci_hcd_init() is not
>>> used,
>>> then where can we call the board_usb_init()?
>>
>>
>> Thanks for testing.
>>
>> Can board_usb_init() be called from within the board_init() code
>> instead? Or are you trying to avoid doing this init unless USB is
>> actually used? If so, then I'll need to have a think about it.
>>
>> Regards,
>> Simon
>>
>
> I noticed, that after changes the USB command doesn't recognize the mass
> storage device. I haven't too much time for checking it deeper.
> I will check it on Monday and give you a response.

OK thanks. You can also try removing CONFIG_DM_USB as a comparison.
I'm happy to switch this back to not use driver model until any
problems are resolved.

Regards,
Simon

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

[Przemyslaw Marczak]

Hello,

On 04/10/2015 07:57 PM, Simon Glass wrote:
> Hi Przemyslaw,
>
> On 10 April 2015 at 11:50, Przemyslaw Marczak <p.marczak@samsung.com> wrote:
>> Hello Simon,
>>
>>
>> On 04/10/2015 07:40 PM, Simon Glass wrote:
>>>
>>> Hi Przemyslaw,
>>>
>>> On 9 April 2015 at 01:55, Przemyslaw Marczak <p.marczak@samsung.com>
>>> wrote:
>>>>
>>>> Hello Simon,
>>>>
>>>>
>>>> On 04/09/2015 05:07 AM, Simon Glass 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!
>>>>>
>>>>> Regards,
>>>>> Simon
>>>>>
>>>>
>>>> I tested this on Odroid U3.
>>>> It looks that everything works fine. I see that ehci_hcd_init() is not
>>>> used,
>>>> then where can we call the board_usb_init()?
>>>
>>>
>>> Thanks for testing.
>>>
>>> Can board_usb_init() be called from within the board_init() code
>>> instead? Or are you trying to avoid doing this init unless USB is
>>> actually used? If so, then I'll need to have a think about it.
>>>
>>> Regards,
>>> Simon
>>>
>>
>> I noticed, that after changes the USB command doesn't recognize the mass
>> storage device. I haven't too much time for checking it deeper.
>> I will check it on Monday and give you a response.
>
> OK thanks. You can also try removing CONFIG_DM_USB as a comparison.
> I'm happy to switch this back to not use driver model until any
> problems are resolved.
>
> Regards,
> Simon
>

Ok, I will also check this. Or if find the time, I will fix the storage 
issue for dm-usb.

Best regards,
-- 
Przemyslaw Marczak
Samsung R&D Institute Poland
Samsung Electronics
p.marczak at samsung.com

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

[Bin Meng]

Hi Simon,

On Sat, Apr 11, 2015 at 1:42 AM, Simon Glass <sjg@chromium.org> wrote:
> Hi Bin,
>
> On 9 April 2015 at 06:52, Bin Meng <bmeng.cn@gmail.com> wrote:
>> Hi Simon,
>>
>> On Thu, Apr 9, 2015 at 11:11 AM, Simon Glass <sjg@chromium.org> wrote:
>>> (Correcting address for Masahiro, sorry)
>>>
>>>
>>> On 8 April 2015 at 21:07, Simon Glass <sjg@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!
>>>>
>>>> Regards,
>>>> Simon
>>>>
>>
>> I've tested it on CrownBay board and found one issue:
>>
>> During the boot up, or typing 'sf probe' in the U-Boot shell, it reports:
>>
>> Invalid bus 0 (err=-19)
>>
>> I have not investigated but suspect this is due to the CrownBay board
>> has not been converted to use DM SPI, like Chromebook?
>
> All of x86 should use that - it is in arch/x86/Kconfig.

Ah, I see.

> More likely the SPI compatible string is wrong:
>
> compatible = "intel,ich7";
>
> It should be "intel,ich-spi "I think. You can check with 'dm tree' to
> see what devices have been found.

But changing crownbay.dts to use "intel,ich-spi" does not help.

=> dm tree
 Class       Probed   Name
----------------------------------------
 root        [ + ]    root_driver
 serial      [ + ]    |-- serial
 gpio        [   ]    |-- gpioa
 gpio        [   ]    |-- gpiob
 spi         [   ]    `-- spi
 spi_flash   [   ]        `-- spi-flash at 0
=> sf probe
Invalid bus 0 (err=-19)
Failed to initialize SPI flash at 0:0 (error -19)

Regards,
Bin

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

[Bin Meng]

Hi Simon,

On Sat, Apr 11, 2015 at 9:22 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Simon,
>
> On Sat, Apr 11, 2015 at 1:42 AM, Simon Glass <sjg@chromium.org> wrote:
>> Hi Bin,
>>
>> On 9 April 2015 at 06:52, Bin Meng <bmeng.cn@gmail.com> wrote:
>>> Hi Simon,
>>>
>>> On Thu, Apr 9, 2015 at 11:11 AM, Simon Glass <sjg@chromium.org> wrote:
>>>> (Correcting address for Masahiro, sorry)
>>>>
>>>>
>>>> On 8 April 2015 at 21:07, Simon Glass <sjg@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!
>>>>>
>>>>> Regards,
>>>>> Simon
>>>>>
>>>
>>> I've tested it on CrownBay board and found one issue:
>>>
>>> During the boot up, or typing 'sf probe' in the U-Boot shell, it reports:
>>>
>>> Invalid bus 0 (err=-19)
>>>
>>> I have not investigated but suspect this is due to the CrownBay board
>>> has not been converted to use DM SPI, like Chromebook?
>>
>> All of x86 should use that - it is in arch/x86/Kconfig.
>
> Ah, I see.
>
>> More likely the SPI compatible string is wrong:
>>
>> compatible = "intel,ich7";
>>
>> It should be "intel,ich-spi "I think. You can check with 'dm tree' to
>> see what devices have been found.
>
> But changing crownbay.dts to use "intel,ich-spi" does not help.
>
> => dm tree
>  Class       Probed   Name
> ----------------------------------------
>  root        [ + ]    root_driver
>  serial      [ + ]    |-- serial
>  gpio        [   ]    |-- gpioa
>  gpio        [   ]    |-- gpiob
>  spi         [   ]    `-- spi
>  spi_flash   [   ]        `-- spi-flash at 0
> => sf probe
> Invalid bus 0 (err=-19)
> Failed to initialize SPI flash at 0:0 (error -19)
>

'git besect' shows that commit 898ed91 breaks the things.

A debug version of U-Boot log is:

=> sf probe
uclass_find_device_by_seq: 0 0
   - -1 -1
   - not found
spi_find_bus_and_cs: No bus 0
uclass_find_device_by_seq: 0 0
   - -1 -1
   - not found
uclass_find_device_by_seq: 1 0
   - -1 -1
   - not found
Invalid bus 0 (err=-19)
Failed to initialize SPI flash at 0:0 (error -19)
Command failed, result=1=>

Regards,
Bin

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

[Simon Glass]

Hi Bin,

On 11 April 2015 at 07:22, Bin Meng <bmeng.cn@gmail.com> wrote:
>
> Hi Simon,
>
> On Sat, Apr 11, 2015 at 1:42 AM, Simon Glass <sjg@chromium.org> wrote:
> > Hi Bin,
> >
> > On 9 April 2015 at 06:52, Bin Meng <bmeng.cn@gmail.com> wrote:
> >> Hi Simon,
> >>
> >> On Thu, Apr 9, 2015 at 11:11 AM, Simon Glass <sjg@chromium.org> wrote:
> >>> (Correcting address for Masahiro, sorry)
> >>>
> >>>
> >>> On 8 April 2015 at 21:07, Simon Glass <sjg@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!
> >>>>
> >>>> Regards,
> >>>> Simon
> >>>>
> >>
> >> I've tested it on CrownBay board and found one issue:
> >>
> >> During the boot up, or typing 'sf probe' in the U-Boot shell, it reports:
> >>
> >> Invalid bus 0 (err=-19)
> >>
> >> I have not investigated but suspect this is due to the CrownBay board
> >> has not been converted to use DM SPI, like Chromebook?
> >
> > All of x86 should use that - it is in arch/x86/Kconfig.
>
> Ah, I see.
>
> > More likely the SPI compatible string is wrong:
> >
> > compatible = "intel,ich7";
> >
> > It should be "intel,ich-spi "I think. You can check with 'dm tree' to
> > see what devices have been found.
>
> But changing crownbay.dts to use "intel,ich-spi" does not help.
>
> => dm tree
>  Class       Probed   Name
> ----------------------------------------
>  root        [ + ]    root_driver
>  serial      [ + ]    |-- serial
>  gpio        [   ]    |-- gpioa
>  gpio        [   ]    |-- gpiob
>  spi         [   ]    `-- spi
>  spi_flash   [   ]        `-- spi-flash at 0
> => sf probe
> Invalid bus 0 (err=-19)
> Failed to initialize SPI flash at 0:0 (error -19)

'dm uclass' will show the bus number. I suspect you need to add an
alias for spi0, as with chromebook_link.dts.

Regards,
Simon

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

[Simon Glass]

Hi Bin,

On 11 April 2015 at 07:48, Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Simon,
>
> On Sat, Apr 11, 2015 at 9:22 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
>> Hi Simon,
>>
>> On Sat, Apr 11, 2015 at 1:42 AM, Simon Glass <sjg@chromium.org> wrote:
>>> Hi Bin,
>>>
>>> On 9 April 2015 at 06:52, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>> Hi Simon,
>>>>
>>>> On Thu, Apr 9, 2015 at 11:11 AM, Simon Glass <sjg@chromium.org> wrote:
>>>>> (Correcting address for Masahiro, sorry)
>>>>>
>>>>>
>>>>> On 8 April 2015 at 21:07, Simon Glass <sjg@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!
>>>>>>
>>>>>> Regards,
>>>>>> Simon
>>>>>>
>>>>
>>>> I've tested it on CrownBay board and found one issue:
>>>>
>>>> During the boot up, or typing 'sf probe' in the U-Boot shell, it reports:
>>>>
>>>> Invalid bus 0 (err=-19)
>>>>
>>>> I have not investigated but suspect this is due to the CrownBay board
>>>> has not been converted to use DM SPI, like Chromebook?
>>>
>>> All of x86 should use that - it is in arch/x86/Kconfig.
>>
>> Ah, I see.
>>
>>> More likely the SPI compatible string is wrong:
>>>
>>> compatible = "intel,ich7";
>>>
>>> It should be "intel,ich-spi "I think. You can check with 'dm tree' to
>>> see what devices have been found.
>>
>> But changing crownbay.dts to use "intel,ich-spi" does not help.
>>
>> => dm tree
>>  Class       Probed   Name
>> ----------------------------------------
>>  root        [ + ]    root_driver
>>  serial      [ + ]    |-- serial
>>  gpio        [   ]    |-- gpioa
>>  gpio        [   ]    |-- gpiob
>>  spi         [   ]    `-- spi
>>  spi_flash   [   ]        `-- spi-flash at 0
>> => sf probe
>> Invalid bus 0 (err=-19)
>> Failed to initialize SPI flash at 0:0 (error -19)
>>
>
> 'git besect' shows that commit 898ed91 breaks the things.
>
> A debug version of U-Boot log is:
>
> => sf probe
> uclass_find_device_by_seq: 0 0
>    - -1 -1
>    - not found
> spi_find_bus_and_cs: No bus 0
> uclass_find_device_by_seq: 0 0
>    - -1 -1
>    - not found
> uclass_find_device_by_seq: 1 0
>    - -1 -1
>    - not found
> Invalid bus 0 (err=-19)
> Failed to initialize SPI flash at 0:0 (error -19)
> Command failed, result=1=>

OK thanks, let me take a look...

Regards,
Simon

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

[Simon Glass]

Hi Bin,

On 11 April 2015 at 07:48, Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Simon,
>
> On Sat, Apr 11, 2015 at 9:22 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
>> Hi Simon,
>>
>> On Sat, Apr 11, 2015 at 1:42 AM, Simon Glass <sjg@chromium.org> wrote:
>>> Hi Bin,
>>>
>>> On 9 April 2015 at 06:52, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>> Hi Simon,
>>>>
>>>> On Thu, Apr 9, 2015 at 11:11 AM, Simon Glass <sjg@chromium.org> wrote:
>>>>> (Correcting address for Masahiro, sorry)
>>>>>
>>>>>
>>>>> On 8 April 2015 at 21:07, Simon Glass <sjg@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!
>>>>>>
>>>>>> Regards,
>>>>>> Simon
>>>>>>
>>>>
>>>> I've tested it on CrownBay board and found one issue:
>>>>
>>>> During the boot up, or typing 'sf probe' in the U-Boot shell, it reports:
>>>>
>>>> Invalid bus 0 (err=-19)
>>>>
>>>> I have not investigated but suspect this is due to the CrownBay board
>>>> has not been converted to use DM SPI, like Chromebook?
>>>
>>> All of x86 should use that - it is in arch/x86/Kconfig.
>>
>> Ah, I see.
>>
>>> More likely the SPI compatible string is wrong:
>>>
>>> compatible = "intel,ich7";
>>>
>>> It should be "intel,ich-spi "I think. You can check with 'dm tree' to
>>> see what devices have been found.
>>
>> But changing crownbay.dts to use "intel,ich-spi" does not help.
>>
>> => dm tree
>>  Class       Probed   Name
>> ----------------------------------------
>>  root        [ + ]    root_driver
>>  serial      [ + ]    |-- serial
>>  gpio        [   ]    |-- gpioa
>>  gpio        [   ]    |-- gpiob
>>  spi         [   ]    `-- spi
>>  spi_flash   [   ]        `-- spi-flash at 0
>> => sf probe
>> Invalid bus 0 (err=-19)
>> Failed to initialize SPI flash at 0:0 (error -19)
>>
>
> 'git besect' shows that commit 898ed91 breaks the things.
>
> A debug version of U-Boot log is:
>
> => sf probe
> uclass_find_device_by_seq: 0 0
>    - -1 -1
>    - not found
> spi_find_bus_and_cs: No bus 0
> uclass_find_device_by_seq: 0 0
>    - -1 -1
>    - not found
> uclass_find_device_by_seq: 1 0
>    - -1 -1
>    - not found
> Invalid bus 0 (err=-19)
> Failed to initialize SPI flash at 0:0 (error -19)
> Command failed, result=1=>

With the conversion to driver model it no-longer probes the PCI bus
looking for a SPI device. Did you try adding and alias too? I think
you fixed the compatible string.

I have tested this again on link and it seems OK there (there is an
unrelated problem with coreboot not supporting the pch and so not
seeing SPI which I will look at).

Since you have a SPI bus device, and its sequence number appears to be
unset, it should just be a case of sorting that out.

Can you send the output of 'dm uclass'.

Regards,
Simon

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

[Simon Glass]

Hi Prazemyslaw,

On 10 April 2015 at 12:08, Przemyslaw Marczak <p.marczak@samsung.com> wrote:
> Hello,
>
>
> On 04/10/2015 07:57 PM, Simon Glass wrote:
>>
>> Hi Przemyslaw,
>>
>> On 10 April 2015 at 11:50, Przemyslaw Marczak <p.marczak@samsung.com>
>> wrote:
>>>
>>> Hello Simon,
>>>
>>>
>>> On 04/10/2015 07:40 PM, Simon Glass wrote:
>>>>
>>>>
>>>> Hi Przemyslaw,
>>>>
>>>> On 9 April 2015 at 01:55, Przemyslaw Marczak <p.marczak@samsung.com>
>>>> wrote:
>>>>>
>>>>>
>>>>> Hello Simon,
>>>>>
>>>>>
>>>>> On 04/09/2015 05:07 AM, Simon Glass 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!
>>>>>>
>>>>>> Regards,
>>>>>> Simon
>>>>>>
>>>>>
>>>>> I tested this on Odroid U3.
>>>>> It looks that everything works fine. I see that ehci_hcd_init() is not
>>>>> used,
>>>>> then where can we call the board_usb_init()?
>>>>
>>>>
>>>>
>>>> Thanks for testing.
>>>>
>>>> Can board_usb_init() be called from within the board_init() code
>>>> instead? Or are you trying to avoid doing this init unless USB is
>>>> actually used? If so, then I'll need to have a think about it.
>>>>
>>>> Regards,
>>>> Simon
>>>>
>>>
>>> I noticed, that after changes the USB command doesn't recognize the mass
>>> storage device. I haven't too much time for checking it deeper.
>>> I will check it on Monday and give you a response.
>>
>>
>> OK thanks. You can also try removing CONFIG_DM_USB as a comparison.
>> I'm happy to switch this back to not use driver model until any
>> problems are resolved.
>>
>> Regards,
>> Simon
>>
>
> Ok, I will also check this. Or if find the time, I will fix the storage
> issue for dm-usb.

Thanks. Just a note on my testing. I used a power hub with 3 USB flash
sticks and a USB Ethernet dongle. Also I plugged a unpowered hub into
the powered hub, with its own USB stick. I tried this on snow/pit both
with and without DM_USB.

For mass storage the detection method is different (you now register
drivers which can handle the various interface classes, etc.) but the
effect is intended to be the same. But there may be an error
somewhere.

Regards,
Simon

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

[Bin Meng]

Hi Simon,

On Mon, Apr 13, 2015 at 10:27 PM, Simon Glass <sjg@chromium.org> wrote:
> Hi Bin,
>
> On 11 April 2015 at 07:48, Bin Meng <bmeng.cn@gmail.com> wrote:
>> Hi Simon,
>>
>> On Sat, Apr 11, 2015 at 9:22 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
>>> Hi Simon,
>>>
>>> On Sat, Apr 11, 2015 at 1:42 AM, Simon Glass <sjg@chromium.org> wrote:
>>>> Hi Bin,
>>>>
>>>> On 9 April 2015 at 06:52, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>> Hi Simon,
>>>>>
>>>>> On Thu, Apr 9, 2015 at 11:11 AM, Simon Glass <sjg@chromium.org> wrote:
>>>>>> (Correcting address for Masahiro, sorry)
>>>>>>
>>>>>>
>>>>>> On 8 April 2015 at 21:07, Simon Glass <sjg@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!
>>>>>>>
>>>>>>> Regards,
>>>>>>> Simon
>>>>>>>
>>>>>
>>>>> I've tested it on CrownBay board and found one issue:
>>>>>
>>>>> During the boot up, or typing 'sf probe' in the U-Boot shell, it reports:
>>>>>
>>>>> Invalid bus 0 (err=-19)
>>>>>
>>>>> I have not investigated but suspect this is due to the CrownBay board
>>>>> has not been converted to use DM SPI, like Chromebook?
>>>>
>>>> All of x86 should use that - it is in arch/x86/Kconfig.
>>>
>>> Ah, I see.
>>>
>>>> More likely the SPI compatible string is wrong:
>>>>
>>>> compatible = "intel,ich7";
>>>>
>>>> It should be "intel,ich-spi "I think. You can check with 'dm tree' to
>>>> see what devices have been found.
>>>
>>> But changing crownbay.dts to use "intel,ich-spi" does not help.
>>>
>>> => dm tree
>>>  Class       Probed   Name
>>> ----------------------------------------
>>>  root        [ + ]    root_driver
>>>  serial      [ + ]    |-- serial
>>>  gpio        [   ]    |-- gpioa
>>>  gpio        [   ]    |-- gpiob
>>>  spi         [   ]    `-- spi
>>>  spi_flash   [   ]        `-- spi-flash at 0
>>> => sf probe
>>> Invalid bus 0 (err=-19)
>>> Failed to initialize SPI flash at 0:0 (error -19)
>>>
>>
>> 'git besect' shows that commit 898ed91 breaks the things.
>>
>> A debug version of U-Boot log is:
>>
>> => sf probe
>> uclass_find_device_by_seq: 0 0
>>    - -1 -1
>>    - not found
>> spi_find_bus_and_cs: No bus 0
>> uclass_find_device_by_seq: 0 0
>>    - -1 -1
>>    - not found
>> uclass_find_device_by_seq: 1 0
>>    - -1 -1
>>    - not found
>> Invalid bus 0 (err=-19)
>> Failed to initialize SPI flash at 0:0 (error -19)
>> Command failed, result=1=>
>
> With the conversion to driver model it no-longer probes the PCI bus
> looking for a SPI device. Did you try adding and alias too? I think
> you fixed the compatible string.

Yes, I only fixed the compatible string. Just now I added an alias to
the spi node, and it worked. So the alias is a must-have now?

diff --git a/arch/x86/dts/crownbay.dts b/arch/x86/dts/crownbay.dts
index e81054e..fbdeade 100644
--- a/arch/x86/dts/crownbay.dts
+++ b/arch/x86/dts/crownbay.dts
@@ -13,6 +13,10 @@
        model = "Intel Crown Bay";
        compatible = "intel,crownbay", "intel,queensbay";

+       aliases {
+               spi0 = "/spi";    /* looks like spi = "/spi" also works */
+       };
+
        config {
                silent_console = <0>;
        };
@@ -46,7 +50,7 @@
        spi {
                #address-cells = <1>;
                #size-cells = <0>;
-               compatible = "intel,ich7";
+               compatible = "intel,ich-spi";
                spi-flash at 0 {
                        reg = <0>;
                        compatible = "sst,25vf016b", "spi-flash";

> I have tested this again on link and it seems OK there (there is an
> unrelated problem with coreboot not supporting the pch and so not
> seeing SPI which I will look at).
>
> Since you have a SPI bus device, and its sequence number appears to be
> unset, it should just be a case of sorting that out.
>
> Can you send the output of 'dm uclass'.
>

We need fix crownbay/minnowmax/galileo dts files. I can prepare
patches if you like.

Regards,
Bin

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

[Simon Glass]

Hi Bin,

On 13 April 2015 at 09:05, Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Simon,
>
> On Mon, Apr 13, 2015 at 10:27 PM, Simon Glass <sjg@chromium.org> wrote:
>> Hi Bin,
>>
>> On 11 April 2015 at 07:48, Bin Meng <bmeng.cn@gmail.com> wrote:
>>> Hi Simon,
>>>
>>> On Sat, Apr 11, 2015 at 9:22 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>> Hi Simon,
>>>>
>>>> On Sat, Apr 11, 2015 at 1:42 AM, Simon Glass <sjg@chromium.org> wrote:
>>>>> Hi Bin,
>>>>>
>>>>> On 9 April 2015 at 06:52, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>> Hi Simon,
>>>>>>
>>>>>> On Thu, Apr 9, 2015 at 11:11 AM, Simon Glass <sjg@chromium.org> wrote:
>>>>>>> (Correcting address for Masahiro, sorry)
>>>>>>>
>>>>>>>
>>>>>>> On 8 April 2015 at 21:07, Simon Glass <sjg@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!
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Simon
>>>>>>>>
>>>>>>
>>>>>> I've tested it on CrownBay board and found one issue:
>>>>>>
>>>>>> During the boot up, or typing 'sf probe' in the U-Boot shell, it reports:
>>>>>>
>>>>>> Invalid bus 0 (err=-19)
>>>>>>
>>>>>> I have not investigated but suspect this is due to the CrownBay board
>>>>>> has not been converted to use DM SPI, like Chromebook?
>>>>>
>>>>> All of x86 should use that - it is in arch/x86/Kconfig.
>>>>
>>>> Ah, I see.
>>>>
>>>>> More likely the SPI compatible string is wrong:
>>>>>
>>>>> compatible = "intel,ich7";
>>>>>
>>>>> It should be "intel,ich-spi "I think. You can check with 'dm tree' to
>>>>> see what devices have been found.
>>>>
>>>> But changing crownbay.dts to use "intel,ich-spi" does not help.
>>>>
>>>> => dm tree
>>>>  Class       Probed   Name
>>>> ----------------------------------------
>>>>  root        [ + ]    root_driver
>>>>  serial      [ + ]    |-- serial
>>>>  gpio        [   ]    |-- gpioa
>>>>  gpio        [   ]    |-- gpiob
>>>>  spi         [   ]    `-- spi
>>>>  spi_flash   [   ]        `-- spi-flash at 0
>>>> => sf probe
>>>> Invalid bus 0 (err=-19)
>>>> Failed to initialize SPI flash at 0:0 (error -19)
>>>>
>>>
>>> 'git besect' shows that commit 898ed91 breaks the things.
>>>
>>> A debug version of U-Boot log is:
>>>
>>> => sf probe
>>> uclass_find_device_by_seq: 0 0
>>>    - -1 -1
>>>    - not found
>>> spi_find_bus_and_cs: No bus 0
>>> uclass_find_device_by_seq: 0 0
>>>    - -1 -1
>>>    - not found
>>> uclass_find_device_by_seq: 1 0
>>>    - -1 -1
>>>    - not found
>>> Invalid bus 0 (err=-19)
>>> Failed to initialize SPI flash at 0:0 (error -19)
>>> Command failed, result=1=>
>>
>> With the conversion to driver model it no-longer probes the PCI bus
>> looking for a SPI device. Did you try adding and alias too? I think
>> you fixed the compatible string.
>
> Yes, I only fixed the compatible string. Just now I added an alias to
> the spi node, and it worked. So the alias is a must-have now?

U-Boot relies on being able to number its devices (at least until we
decide we want to allow device names in commands like 'sf probe'). If
a device has no sequence number it will be allocated when the device
is probed. But until it is probed we can't know what the sequence
number will be - it depends on the order that devices are probed. So
it is best to explicitly give devices a number I think.

It is certainly possible to change this - e.g. by figuring out the
next available sequence number, knowing that this is what the
to-be-probed device will be allocated. But we don't do that at
present.

>
> diff --git a/arch/x86/dts/crownbay.dts b/arch/x86/dts/crownbay.dts
> index e81054e..fbdeade 100644
> --- a/arch/x86/dts/crownbay.dts
> +++ b/arch/x86/dts/crownbay.dts
> @@ -13,6 +13,10 @@
>         model = "Intel Crown Bay";
>         compatible = "intel,crownbay", "intel,queensbay";
>
> +       aliases {
> +               spi0 = "/spi";    /* looks like spi = "/spi" also works */
> +       };
> +
>         config {
>                 silent_console = <0>;
>         };
> @@ -46,7 +50,7 @@
>         spi {
>                 #address-cells = <1>;
>                 #size-cells = <0>;
> -               compatible = "intel,ich7";
> +               compatible = "intel,ich-spi";
>                 spi-flash at 0 {
>                         reg = <0>;
>                         compatible = "sst,25vf016b", "spi-flash";
>
>> I have tested this again on link and it seems OK there (there is an
>> unrelated problem with coreboot not supporting the pch and so not
>> seeing SPI which I will look at).
>>
>> Since you have a SPI bus device, and its sequence number appears to be
>> unset, it should just be a case of sorting that out.
>>
>> Can you send the output of 'dm uclass'.
>>
>
> We need fix crownbay/minnowmax/galileo dts files. I can prepare
> patches if you like.

Yes please. Sorry I missed this implication of the change.

Regards,
Simon

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

[Przemyslaw Marczak]

Hello Simon,

On 04/13/2015 04:31 PM, Simon Glass wrote:
> Hi Prazemyslaw,
>
> On 10 April 2015 at 12:08, Przemyslaw Marczak <p.marczak@samsung.com> wrote:
>> Hello,
>>
>>
>> On 04/10/2015 07:57 PM, Simon Glass wrote:
>>>
>>> Hi Przemyslaw,
>>>
>>> On 10 April 2015 at 11:50, Przemyslaw Marczak <p.marczak@samsung.com>
>>> wrote:
>>>>
>>>> Hello Simon,
>>>>
>>>>
>>>> On 04/10/2015 07:40 PM, Simon Glass wrote:
>>>>>
>>>>>
>>>>> Hi Przemyslaw,
>>>>>
>>>>> On 9 April 2015 at 01:55, Przemyslaw Marczak <p.marczak@samsung.com>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> Hello Simon,
>>>>>>
>>>>>>
>>>>>> On 04/09/2015 05:07 AM, Simon Glass 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!
>>>>>>>
>>>>>>> Regards,
>>>>>>> Simon
>>>>>>>
>>>>>>
>>>>>> I tested this on Odroid U3.
>>>>>> It looks that everything works fine. I see that ehci_hcd_init() is not
>>>>>> used,
>>>>>> then where can we call the board_usb_init()?
>>>>>
>>>>>
>>>>>
>>>>> Thanks for testing.
>>>>>
>>>>> Can board_usb_init() be called from within the board_init() code
>>>>> instead? Or are you trying to avoid doing this init unless USB is
>>>>> actually used? If so, then I'll need to have a think about it.
>>>>>
>>>>> Regards,
>>>>> Simon
>>>>>
>>>>
>>>> I noticed, that after changes the USB command doesn't recognize the mass
>>>> storage device. I haven't too much time for checking it deeper.
>>>> I will check it on Monday and give you a response.
>>>
>>>
>>> OK thanks. You can also try removing CONFIG_DM_USB as a comparison.
>>> I'm happy to switch this back to not use driver model until any
>>> problems are resolved.
>>>
>>> Regards,
>>> Simon
>>>
>>
>> Ok, I will also check this. Or if find the time, I will fix the storage
>> issue for dm-usb.
>
> Thanks. Just a note on my testing. I used a power hub with 3 USB flash
> sticks and a USB Ethernet dongle. Also I plugged a unpowered hub into
> the powered hub, with its own USB stick. I tried this on snow/pit both
> with and without DM_USB.
>
> For mass storage the detection method is different (you now register
> drivers which can handle the various interface classes, etc.) but the
> effect is intended to be the same. But there may be an error
> somewhere.
>
> Regards,
> Simon
>

Sorry, I haven't time for this today.
I hope to check this tomorrow.

Best regards,
-- 
Przemyslaw Marczak
Samsung R&D Institute Poland
Samsung Electronics
p.marczak at samsung.com

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

[Stephen Warren]

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@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. Here's a good run with 
something based on a merge of v2015.0r-rc5 and a merge of 
u-boot-tegra/master from around the end of March:

> Tegra124 (Jetson TK1) # usb start
> starting USB...
> USB0:   USB EHCI 1.10
> scanning bus 0 for devices... 1 USB Device(s) found
> USB1:   USB EHCI 1.10
> scanning bus 1 for devices... 6 USB Device(s) found
>        scanning usb for storage devices... 1 Storage Device(s) found
>        scanning usb for ethernet devices... 0 Ethernet Device(s) found
> Tegra124 (Jetson TK1) # usb tree
> USB device tree:
>   1  Hub (480 Mb/s, 0mA)
>      u-boot EHCI Host Controller
>
>   2  Hub (480 Mb/s, 0mA)
>   |  u-boot EHCI Host Controller
>   |
>   +-3  Hub (480 Mb/s, 100mA)
>     |   USB2.0 Hub
>     |
>     +-4  Hub (480 Mb/s, 100mA)
>     | |   USB2.0 Hub
>     | |
>     | +-5  Human Interface (1.5 Mb/s, 100mA)
>     | |    Microsoft Microsoft IntelliMouse? Explore
>     | |
>     | +-6  Human Interface (1.5 Mb/s, 70mA)
>     |      LITEON Technology USB Multimedia Keyboard
>     |
>     +-7  Mass Storage (480 Mb/s, 2mA)
>          Sunplus Innovation Technology. USB to Serial-ATA bridge FF980813AF0000000000005FF16BFF

... 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

(I notice both those lines have the same device ID rather than one being 
0 and the other 1)

> 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
> Tegra124 (Jetson TK1) # usb tree
> USB device tree:
> +-1  Hub (480 Mb/s, 0mA)
>      u-boot EHCI Host Controller
>
> +-1  Hub (480 Mb/s, 0mA)

(same issue there, although perhaps this is expected if USB devnum is 
per-controller now?)

>   |  u-boot EHCI Host Controller
>   |
>   +-2  Hub (480 Mb/s, 100mA)
>     |   USB2.0 Hub
>     |
>     | 3  Hub (480 Mb/s, 100mA)
>     |     USB2.0 Hub
>     |
>     +-4  Mass Storage (480 Mb/s, 2mA)
>          Sunplus Innovation Technology. USB to Serial-ATA bridge FF980813AF0000000000005FF16BFF

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

... and despite reporting an error during flash writing, the system 
boots, I don't know if this is anything related to the DM changes or 
something else though; I'll go check.

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

[Stephen Warren]

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@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

...
> 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

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?

For testing, it may be easier to load U-Boot into RAM that flash it 
every time. If so, since there's only 1 USB port, you'll need to use 
"usb reset" to re-scan that USB port. That will only work with the 
following patch, which I'll send in a minute:

diff --git a/include/configs/tegra-common-post.h 
b/include/configs/tegra-common-post.h
index c3ad8beb903d..9ab58555378c 100644
--- a/include/configs/tegra-common-post.h
+++ b/include/configs/tegra-common-post.h
@@ -26,10 +26,11 @@
  #define STDIN_KBD_KBC ""
  #endif

-#ifdef CONFIG_USB_KEYBOARD
+#if defined(CONFIG_USB_KEYBOARD) && !defined(CONFIG_SPL_BUILD)
  #define STDIN_KBD_USB ",usbkbd"
  #define CONFIG_SYS_USB_EVENT_POLL
  #define CONFIG_PREBOOT			"usb start"
+#define CONFIG_SYS_STDIO_DEREGISTER
  #else
  #define STDIN_KBD_USB ""
  #endif

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

[Simon Glass]

Hi Stephen,

On 13 April 2015 at 11:04, Stephen Warren <swarren@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@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.

> ...
>>
>> 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.

>
> 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?

>
> For testing, it may be easier to load U-Boot into RAM that flash it every
> time. If so, since there's only 1 USB port, you'll need to use "usb reset"
> to re-scan that USB port. That will only work with the following patch,
> which I'll send in a minute:
>
> diff --git a/include/configs/tegra-common-post.h
> b/include/configs/tegra-common-post.h
> index c3ad8beb903d..9ab58555378c 100644
> --- a/include/configs/tegra-common-post.h
> +++ b/include/configs/tegra-common-post.h
> @@ -26,10 +26,11 @@
>  #define STDIN_KBD_KBC ""
>  #endif
>
> -#ifdef CONFIG_USB_KEYBOARD
> +#if defined(CONFIG_USB_KEYBOARD) && !defined(CONFIG_SPL_BUILD)
>  #define STDIN_KBD_USB ",usbkbd"
>  #define CONFIG_SYS_USB_EVENT_POLL
>  #define CONFIG_PREBOOT                 "usb start"
> +#define CONFIG_SYS_STDIO_DEREGISTER
>  #else
>  #define STDIN_KBD_USB ""
>  #endif
>

Regards,
Simon

[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@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@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] Testing u-boot-dm/next

[Simon Glass]

Hi Stephen,

On 13 April 2015 at 11:36, Stephen Warren <swarren@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@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@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

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

[Simon Glass]

Hi Stephen,

On 13 April 2015 at 11:46, Simon Glass <sjg@chromium.org> wrote:
> Hi Stephen,
>
> On 13 April 2015 at 11:36, Stephen Warren <swarren@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@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@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

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

[Stephen Warren]

On 04/13/2015 11:52 AM, Simon Glass wrote:
...
>>>>>>> On 8 April 2015 at 21:07, Simon Glass <sjg@chromium.org> wrote:
>>>>>>>> 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!
...
> I've pushed a new u-boot-dm/next if you'd like to try it.

(On Seaboard at least) this solves the two problems we were discussing:
* Cache alignment issues during NAND writes.
* Failure to enumerate some USB devices.

However, I just noticed that USB keyboard support doesn't work (On 
Seaboard at least). I've bisect this to:

6105422c50ee dm: usb: Move descriptor setup code into its own function

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

[Simon Glass]

Hi Stephen,

On 13 April 2015 at 13:03, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 04/13/2015 11:52 AM, Simon Glass wrote:
> ...
>>>>>>>>
>>>>>>>> On 8 April 2015 at 21:07, Simon Glass <sjg@chromium.org> wrote:
>>>>>>>>>
>>>>>>>>> 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!
>
> ...
>>
>> I've pushed a new u-boot-dm/next if you'd like to try it.
>
>
> (On Seaboard at least) this solves the two problems we were discussing:
> * Cache alignment issues during NAND writes.
> * Failure to enumerate some USB devices.
>
> However, I just noticed that USB keyboard support doesn't work (On Seaboard
> at least). I've bisect this to:
>
> 6105422c50ee dm: usb: Move descriptor setup code into its own function

Interesting - there is a small change in that function which I thought
was safe, but apparently not. I'll revert it and re-test later today,
and let you know when it is ready.

Regards,
Simon

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

[Simon Glass]

Hi Stephen,

On 13 April 2015 at 14:17, Simon Glass <sjg@chromium.org> wrote:
> Hi Stephen,
>
> On 13 April 2015 at 13:03, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> On 04/13/2015 11:52 AM, Simon Glass wrote:
>> ...
>>>>>>>>>
>>>>>>>>> On 8 April 2015 at 21:07, Simon Glass <sjg@chromium.org> wrote:
>>>>>>>>>>
>>>>>>>>>> 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!
>>
>> ...
>>>
>>> I've pushed a new u-boot-dm/next if you'd like to try it.
>>
>>
>> (On Seaboard at least) this solves the two problems we were discussing:
>> * Cache alignment issues during NAND writes.
>> * Failure to enumerate some USB devices.
>>
>> However, I just noticed that USB keyboard support doesn't work (On Seaboard
>> at least). I've bisect this to:
>>
>> 6105422c50ee dm: usb: Move descriptor setup code into its own function
>
> Interesting - there is a small change in that function which I thought
> was safe, but apparently not. I'll revert it and re-test later today,
> and let you know when it is ready.

Actually that was another patch I was thinking off. I tested the
series with two different keyboards at the time (which is why I had to
add the later patch to move USB keyboards over to drive model), but
obviously I did something wrong as when I test it now, it does not
work. Oh dear.

I fixed up the three refactoring patches and have resent them to the
list. I've also updated u-boot-dm/next if you have time to test again.
Both keyboards work for me on seaboard now.

I did consider just adding a fixup patch to the end, but I don't like
the idea of USB keyboard being broken for many patches if someone
later bisects the tree.

Thanks for helping test this. I suspect there might be other problems
that will show up when more people try it out, but there is plenty of
time to deal with that.

Regards,
Simon

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

[Simon Glass]

Hi,

On 13 April 2015 at 21:25, Simon Glass <sjg@chromium.org> wrote:
>
> Hi Stephen,
>
> On 13 April 2015 at 14:17, Simon Glass <sjg@chromium.org> wrote:
> > Hi Stephen,
> >
> > On 13 April 2015 at 13:03, Stephen Warren <swarren@wwwdotorg.org> wrote:
> >> On 04/13/2015 11:52 AM, Simon Glass wrote:
> >> ...
> >>>>>>>>>
> >>>>>>>>> On 8 April 2015 at 21:07, Simon Glass <sjg@chromium.org> wrote:
> >>>>>>>>>>
> >>>>>>>>>> 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!
> >>
> >> ...
> >>>
> >>> I've pushed a new u-boot-dm/next if you'd like to try it.
> >>
> >>
> >> (On Seaboard at least) this solves the two problems we were discussing:
> >> * Cache alignment issues during NAND writes.
> >> * Failure to enumerate some USB devices.
> >>
> >> However, I just noticed that USB keyboard support doesn't work (On Seaboard
> >> at least). I've bisect this to:
> >>
> >> 6105422c50ee dm: usb: Move descriptor setup code into its own function
> >
> > Interesting - there is a small change in that function which I thought
> > was safe, but apparently not. I'll revert it and re-test later today,
> > and let you know when it is ready.
>
> Actually that was another patch I was thinking off. I tested the
> series with two different keyboards at the time (which is why I had to
> add the later patch to move USB keyboards over to drive model), but
> obviously I did something wrong as when I test it now, it does not
> work. Oh dear.

This may be because I did most of my testing with XHCI which uses a
different code path. The code sequence of USB init is quite complex,
but it seems that most of this complexity is unfortunately needed for
the various cases that come up.

Regards,
Simon

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

[Stephen Warren]

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@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!

I assume this has been merged into u-boot/master now. FWIW, commit
d8c1d5d5fb6e "Merge branch 'buildman' of git://git.denx.de/u-boot-x86"
from there seems to work fine on the RPi.

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

[Simon Glass]

Hi Stephen,

On 24 April 2015 at 22:46, Stephen Warren <swarren@nvidia.com> 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@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!
>
> I assume this has been merged into u-boot/master now. FWIW, commit
> d8c1d5d5fb6e "Merge branch 'buildman' of git://git.denx.de/u-boot-x86"
> from there seems to work fine on the RPi.

Thanks for the follow-up, good to hear.

Regards,
Simon