[U-Boot] [PATCH v7 00/34] sf: MTD support

[Stefan Roese <sr@denx.de>]

Hi Simon,

On 26.11.2015 19:22, Simon Glass wrote:
> Hi Stefan,
>
> On 26 November 2015 at 10:12, Stefan Roese <sr@denx.de> wrote:
>> Hi Simon,
>>
>> On 26.11.2015 18:55, Simon Glass wrote:
>>> Hi Stefan,
>>>
>>> On 26 November 2015 at 09:47, Stefan Roese <sr@denx.de> wrote:
>>>> Hi Simon,
>>>>
>>>> On 26.11.2015 17:48, Simon Glass wrote:
>>>>
>>>> <snip>
>>>>
>>>>
>>>>>> Yes. I'm trying to enable SPL_DM on MVEBU. And this with
>>>>>> DM_SPI and DM_SPI_FLASH enabled as well. I've the kirkwood
>>>>>> SPI driver ported to DM here for this (patches will follow).
>>>>>>
>>>>>>> what kind of issue?
>>>>>>> is it failed to probe device or something?
>>>>>>
>>>>>>
>>>>>> Here the log (with some debug() enabled):
>>>>>>
>>>>>> ----------<-------------------------------
>>>>>> uclass_find_device_by_seq: 0 -1
>>>>>> uclass_find_device_by_seq: 0 0
>>>>>>       - -1 -1
>>>>>>       - not found
>>>>>> bind node serial at 12000
>>>>>>       - found match at 'ns16550_serial'
>>>>>> Bound device serial at 12000 to root_driver
>>>>>> uclass_find_device_by_seq: 0 -1
>>>>>> uclass_find_device_by_seq: 0 0
>>>>>>       - -1 -1
>>>>>>       - not found
>>>>>>
>>>>>> U-Boot SPL 2016.01-rc1-00267-gdb3362c-dirty (Nov 26 2015 - 14:00:16)
>>>>>> High speed PHY - Version: 2.0
>>>>>> Detected Device ID 6828
>>>>>> board SerDes lanes topology details:
>>>>>>     | Lane #  | Speed |  Type       |
>>>>>>     --------------------------------
>>>>>>     |   0    |  5   |  PCIe0       |
>>>>>>     |   1    |  3   |  SATA0       |
>>>>>>     |   2    |  3   |  SATA1       |
>>>>>>     |   3    |  3   |  SATA3       |
>>>>>>     |   4    |  3   |  SATA2       |
>>>>>>     |   5    |  5   |  USB3 HOST1  |
>>>>>>     --------------------------------
>>>>>> PCIe, Idx 0: detected no link
>>>>>> High speed PHY - Ended Successfully
>>>>>> DDR3 Training Sequence - Ver TIP-1.29.0
>>>>>> DDR3 Training Sequence - Switching XBAR Window to FastPath Window
>>>>>> DDR3 Training Sequence - Ended Successfully
>>>>>> Trying to boot from SPI
>>>>>> uclass_find_device_by_seq: 0 0
>>>>>>       - not found
>>>>>> uclass_find_device_by_seq: 1 0
>>>>>>       - not found
>>>>>> Invalid bus 0 (err=-19)
>>>>>> SPI probe failed.
>>>>>> SPL: failed to boot from all boot devices
>>>>>> ### ERROR ### Please RESET the board ###
>>>>>> ----------<-------------------------------
>>>>>>
>>>>>> Simon, do you have a clue what's missing here? SPI NOR booting
>>>>>> is working just fine in SPL without SPL_DM enabled on this
>>>>>> platform. AFAICT, I've added the required "u-boot,dm-pre-reloc"
>>>>>> properties to the dts.
>>>>>>
>>>>>>> I will verify the same and
>>>>>>> let you know.
>>>>>>
>>>>>>
>>>>>> How can you verify this if SPI is not working at all for you? Or
>>>>>> did I misunderstand you (see above)?
>>>>>
>>>>>
>>>>> -19 means -ENODEV. I suppose CONFIG_SPL_OF_CONTROL is enabled.
>>>>
>>>>
>>>> Yes.
>>>>
>>>>> You can
>>>>> check the device tree used for SPL in your build directory -
>>>>> spl/u-boot-spl.dtb.
>>>>>
>>>>>    From the debugging it looks like you have no SPI flash devices.
>>>>
>>>>
>>>> That is my understanding as well. And I fail to see, where this
>>>> device get added to the list of UCLASS devices.
>>>>
>>>>> You can check chromebook_jerry which uses this feature. See this node:
>>>>>
>>>>> &spi2 {
>>>>>       status = "okay";
>>>>>       u-boot,dm-pre-reloc;
>>>>>
>>>>>       spi_flash: spiflash at 0 {
>>>>>          u-boot,dm-pre-reloc;
>>>>>          compatible = "spidev", "spi-flash";
>>>>>          spi-max-frequency = <20000000>; /* Reduce for Dediprog em100 pro */
>>>>>          reg = <0>;
>>>>>       };
>>>>> };
>>>>
>>>>
>>>> I've checked this now and reworked the dts a bit. But still no
>>>> cigar. The debug output is identical to the last one.
>>>>
>>>> I've attached the dts / dtb and the current .config. It would
>>>> be great if you could take a quick look at it to see, what I
>>>> am missing here.
>>>
>>> CONFIG_SPL_OF_TRANSLATE should be defined I think,
>>
>> Yes. But this does not explain why this device is not found at all.
>> This would only result in an incorrect base-address. And this works
>> since the serial node seems to be okay (DM in SPL here as well).
>>
>>> and also you need a
>>> u-boot,dm-pre-reloc in the soc {} node, otherwise the properties there
>>> will not appear.
>>
>> Its already there in the dtsi file. I've added it again in this
>> dts file as well.
>>
>>>
>>> You can call dm_dump_all() in SPL, and dm_dump_uclass(), to see what
>>> devices are present.
>>
>> Ah, this is helpful. Thanks. Here the output for your profound
>> inspection: ;)
>>
>> Trying to boot from SPI
>> uclass_find_device_by_seq: 0 0
>>     - not found
>> uclass_find_device_by_seq: 1 0
>>     - not found
>> Invalid bus 0 (err=-19)
>> SPI probe failed.
>>   Class       Probed   Name
>> ----------------------------------------
>>   root        [ + ]    root_driver
>>   serial      [ + ]    `-- serial at 12000
>
> That shows that the SPI device or driver is not being found. I don't
> see a driver for 'marvell,armada-380-spi' in the tree anyway - is it
> your own private patches?

Yes, this is in my local tree - waiting for this issue to get
resolved before sending to the list.

> If you add DEBUG to drivers/core/lists.c you may be able to see why it
> is not finding a driver for that node.

"#define DEBUG" is already set in lists.c.

I have the notion that drivers are not added "automatically" to
the lists. My debugging has shown that for example the serial
driver is only added to the list after this call in serial-uclass.c:

	lists_bind_fdt(gd->dm_root, blob, node, &dev)

Before this call, I have this output from dm_dump_all():

  Class       Probed   Name
----------------------------------------
  root        [ + ]    root_driver

Then, calling lists_bind_fdt() results in this debug output:

bind node serial at 12000
    - found match at 'ns16550_serial'
Bound device serial at 12000 to root_driver

And now, dm_dump_all() shows this directly after the lists_bind_fdt():

  Class       Probed   Name
----------------------------------------
  root        [ + ]    root_driver
  serial      [   ]    `-- serial at 12000


Seems that drivers need to get actively "binded" to the lists.
And this is not happening for the SPI driver.

What am I missing?

Thanks,
Stefan