Hi Simon,
On 26.11.2015 19:22, Simon Glass wrote:
Hi Stefan,
On 26 November 2015 at 10:12, Stefan Roese <s...@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 <s...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
