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

[Stefan Roese <sr@denx.de>]

Hi Simon,

On 27.11.2015 05:01, Stefan Roese wrote:
> 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?

I finally found it. I had CONFIG_SPL_SIMPLE_BUS disabled. So all devices
behind this "simple-bus" where not visible to DM. Now this looks much
better.

Thanks,
Stefan