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@12000 - found match at 'ns16550_serial' Bound device serial@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@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@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@12000 - found match at 'ns16550_serial' Bound device serial@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@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