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