Hi Bin,

Thanks for your information.

The SPI address I mentioned was dumped from pch_get_spi_base(). But I have no idea where to check my memory mapping. It is possible that coreboot remaps the address due to my wrong init cofig. Attached is my boot-up log for your reference.

Regards, Hilbert

-----Original Message----- From: Bin Meng [mailto:bmeng.cn@gmail.com] Sent: Wednesday, June 15, 2016 4:09 PM To: Hilbert Tu(杜睿哲_Pegatron) Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] u-boot-x86 sf probe fail

Hi Hilbert,

On Wed, Jun 15, 2016 at 2:30 PM, Hilbert Tu(杜睿哲_Pegatron) Hilbert_Tu@pegatroncorp.com wrote:

Hi Simon,

I have checked the SPI base address in coreboot and u-boot. They are different. I am not sure is it due to the memory remapping. In coreboot, the SPI address is 0xfed0100 In u-boot, the SPI address is 0x7fc36e00 Do you have any comments? Thanks.

As Simon mentioned, please check pch_get_spi_base(). It's very likely your Atom SoC maps the SPI base register to some different address where current U-Boot does not know.

Regards, Bin This e-mail and its attachment may contain PEGATRON Corp information that is confidential or privileged, and are solely for the use of the individual to whom this e-mail is addressed. If you are not the intended recipient or have received it accidentally, please immediately notify the sender by reply e-mail and destroy all copies of this email and its attachment. Please be advised that any unauthorized use, disclosure, distribution or copying of this email or its attachment is strictly prohibited.

Hi Bin,

Sorry for the top-posting.

After check the datasheet, I think my SPI address was wrong due to null ops->read_config in pci_bus_read_config(). My dts file: spi: spi { #address-cells = <1>; #size-cells = <0>; compatible = "intel,ich9-spi"; spi-flash@0 { #address-cells = <1>; #size-cells = <1>; reg = <0>; compatible = "winbond,w25q128bv", "spi-flash"; memory-map = <0xff000000 0x01000000>; rw-mrc-cache { label = "rw-mrc-cache"; reg = <0xffe10000 0x00010000>; }; }; };

And also bind the node as following:

bind node spi ##device_bind: driver id:50, driver name:ich_spi Looking for 'spi' at 1140, name spi Looking for 'spi' at 1140, name spi - spi0, /pci/pch@1f,0/spi - spi0, /pci/pch@1f,0/spi Found seq 0 Found seq 0 bind node spi-flash@0 ##device_bind: driver id:52, driver name:spi_flash_std fdtdec_get_bool: spi-cpol fdtdec_get_bool: spi-cpha fdtdec_get_bool: spi-cs-high fdtdec_get_bool: spi-3wire fdtdec_get_bool: spi-half-duplex

The "dm tree" is as following: Class Probed Name ---------------------------------------- root [ + ] root_driver serial [ + ] |-- serial keyboard [ + ] |-- keyboard rtc [ ] |-- rtc timer [ + ] |-- tsc-timer pci [ + ] `-- pci pch [ + ] |-- pch@1f,0 irq [ + ] | |-- irq-router spi [ + ] | `-- spi spi_flash [ ] | `-- spi-flash@0 pci_generic [ ] |-- pci_0:0.0 pci [ + ] |-- pci_0:1.0 pci_generic [ ] | `-- pci_1:0.0 pci [ + ] |-- pci_0:3.0 pci_generic [ ] |-- pci_0:e.0 pci_generic [ ] |-- pci_0:f.0 pci_generic [ ] |-- pci_0:13.0 usb [ ] |-- ehci_pci pci_generic [ ] |-- pci_0:17.0 pci_generic [ ] |-- pci_0:18.0 pci_generic [ ] `-- pci_0:1f.3

So I think the initialization is ok. But when I execute "sf probe", I got following wrong result:

##uclass_find_device_by_seq: find_req_seq=0 seq_or_req_seq=0 ##uclass_find_device_by_seq: id=50, ret=0 ##uclass_find_device_by_seq: dev req bus=0 dev bus=-1 device not found ##spi_flash_probe_bus_cs: bus=0, num=0 ##uclass_find_device_by_seq: find_req_seq=0 seq_or_req_seq=0 ##uclass_find_device_by_seq: id=50, ret=0 ##uclass_find_device_by_seq: dev req bus=0 dev bus=-1 device not found ##uclass_get_device_by_seq: id=50, bus=0, ret=-19 ##uclass_find_device_by_seq: find_req_seq=1 seq_or_req_seq=0 ##uclass_find_device_by_seq: id=50, ret=0 ##uclass_find_device_by_seq: dev req bus=0 dev bus=-1 device found ##uclass_find_device_by_seq: find_req_seq=0 seq_or_req_seq=0 ##uclass_find_device_by_seq: id=50, ret=0 ##uclass_find_device_by_seq: dev req bus=0 dev bus=-1 device not found ##uclass_resolve_seq: Device 'spi': seq 0 dup name:'<NULL>', ret=-19 ###ops->read_config is null ##ich_init_controller: sbasep:2143514112, sbase_addr:7fc36ed2 ich_init_controller: sbase=7fc36e00

The node "spi" does not have correct operations to read config. Is it due to wrong device model or wrong dts file?

Regards, Hilbert This e-mail and its attachment may contain PEGATRON Corp information that is confidential or privileged, and are solely for the use of the individual to whom this e-mail is addressed. If you are not the intended recipient or have received it accidentally, please immediately notify the sender by reply e-mail and destroy all copies of this email and its attachment. Please be advised that any unauthorized use, disclosure, distribution or copying of this email or its attachment is strictly prohibited.

Hi Bin

Thanks for your help.

Following is my dts file for your reference. I use qemu-x86_q35 in u-boot as dts template. Orginally I think the ops->read_config should maps to pci_x86_read_config(), but the dump result is it failed in the logic "if (!ops->read_config)" in pci_bus_read_config(). I am not familiar with DM and I guess maybe my DM tree is incorrect that creates wrong mapping for the pci driver. This wrong mapping will result in incorret result of SPI_BASE_ADDRESS. Thanks.

/* * Copyright (C) 2015, Bin Meng bmeng.cn@gmail.com * * SPDX-License-Identifier: GPL-2.0+ */

/dts-v1/;

#include <dt-bindings/interrupt-router/intel-irq.h>

/* ICH9 IRQ router has discrete PIRQ control registers */ #undef PIRQE #undef PIRQF #undef PIRQG #undef PIRQH #define PIRQE 8 #define PIRQF 9 #define PIRQG 10 #define PIRQH 11

/include/ "skeleton.dtsi" /include/ "serial.dtsi" /include/ "keyboard.dtsi" /include/ "rtc.dtsi" /include/ "tsc_timer.dtsi"

/ { model = "QEMU x86 (Q35)"; compatible = "qemu,x86";

aliases { spi0 = &spi; };

config { silent_console = <0>; u-boot,no-apm-finalize; };

chosen { stdout-path = "/serial"; };

cpus { #address-cells = <1>; #size-cells = <0>;

cpu@0 { device_type = "cpu"; compatible = "cpu-qemu"; reg = <0>; intel,apic-id = <0>; }; };

tsc-timer { clock-frequency = <1000000000>; };

pci { compatible = "pci-x86"; #address-cells = <3>; #size-cells = <2>; u-boot,dm-pre-reloc; ranges = <0x02000000 0x0 0xc0000000 0xc0000000 0 0x10000000 0x42000000 0x0 0xd0000000 0xd0000000 0 0x10000000 0x01000000 0x0 0x2000 0x2000 0 0xe000>;

pch@1f,0 { reg = <0x0000f800 0 0 0 0>; compatible = "intel,pch9";

irq-router { compatible = "intel,irq-router"; intel,pirq-config = "pci"; intel,pirq-link = <0x60 8>; intel,pirq-mask = <0x0e40>; intel,pirq-routing = < /* e1000 NIC */ PCI_BDF(0, 2, 0) INTA PIRQG /* ICH9 UHCI */ PCI_BDF(0, 29, 0) INTA PIRQA PCI_BDF(0, 29, 1) INTB PIRQB PCI_BDF(0, 29, 2) INTC PIRQC /* ICH9 EHCI */ PCI_BDF(0, 29, 7) INTD PIRQD /* ICH9 SATA */ PCI_BDF(0, 31, 2) INTA PIRQA >; };

spi: spi { #address-cells = <1>; #size-cells = <0>; compatible = "intel,ich9-spi"; spi-flash@0 { #size-cells = <1>; #address-cells = <1>; reg = <0>; compatible = "winbond,w25q64dw", "spi-flash"; memory-map = <0xff000000 0x01000000>; rw-mrc-cache { label = "rw-mrc-cache"; reg = <0x006e0000 0x00010000>; }; }; }; };

};

};

Regards, Hilbert This e-mail and its attachment may contain PEGATRON Corp information that is confidential or privileged, and are solely for the use of the individual to whom this e-mail is addressed. If you are not the intended recipient or have received it accidentally, please immediately notify the sender by reply e-mail and destroy all copies of this email and its attachment. Please be advised that any unauthorized use, disclosure, distribution or copying of this email or its attachment is strictly prohibited.

On Wed, Jun 22, 2016 at 1:19 PM, Yaroslav yar444@gmail.com wrote:

Hello.

I have a similar problem with U-Boot on Intel Atom C2000. And I have found that the issue with the SPI flash is caused by a file x86/cpu/coreboot/pci.c which contains an empty driver claiming to be compatible with intel,pch7 and intel,pch9. After commenting it out the SPI flash is being probed and works just fine. Maybe the file contains outdated code or something. U-boot maintainers should check it.

Yes, this is the issue! Will prepare a patch soon.

Regards, Bin

Hi Hilbert,

On Wed, Jun 22, 2016 at 2:24 PM, Hilbert Tu(杜睿哲_Pegatron) Hilbert_Tu@pegatroncorp.com wrote:

Hi Bin,

As the earlier post, do you have any comments? Thanks.

Can you try this patch [1] and let me know if it fixes the issue?

[1]: http://patchwork.ozlabs.org/patch/639039/

Regards, Bin