[U-Boot] [Question] DM SPI FLASH
Hi Simon,
I am hacking DTB and DM SPI FLASH support for i.MX 6SoloX. I have a question about `sf probe`. In original way, `sf probe` or `sf probe 0:0` can detect qspi flashes on my platform. But after using DM, I should use `sf probe 35536896:0` to probe flashes. 35536896 is the address of QSPI controller's reg base 0x021e4000 in hex format. Does I miss something in my driver? It seems dev->seq is not valid so should pass req_seq which is the address of qspi controller in dts file.
Any ideas?
The log using `sf probe 0:0`. Fail to probe flash => sf probe 0:0 uclass_find_device_by_seq: 0 0 - 35536896 35536896 - not found spi_find_bus_and_cs: No bus 0 uclass_find_device_by_seq: 0 0 - 35536896 35536896 - not found uclass_find_device_by_seq: 1 0 - 35536896 35536896 - not found Invalid bus 0 (err=-19) Failed to initialize SPI flash at 0:0 (error -19)
The log using `sf probe 35536896:0`. Success to probe flash. => sf probe 35536896:0 uclass_find_device_by_seq: 0 35536896 - 35536896 -1 - not found spi_find_bus_and_cs: No bus 35536896 uclass_find_device_by_seq: 0 35536896 - 35536896 -1 - not found uclass_find_device_by_seq: 1 35536896 - 35536896 -1 - found uclass_find_device_by_seq: 0 -1 uclass_find_device_by_seq: 0 0 - -1 -1 - 33554432 -1 - 33554432 -1 - 34373632 -1 - -1 -1 - 34603008 -1 - 35651584 -1 - 35913728 -1 - -1 -1 - not found uclass_find_device_by_seq: 0 34603008 - -1 0 - 33554432 -1 - 33554432 -1 - 34373632 -1 - -1 -1 - 34603008 -1 - 35651584 -1 - 35913728 -1 - -1 -1 - not found uclass_find_device_by_seq: 0 35536896 - 35536896 -1 - not found fdtdec_get_int_array: reg get_prop_check_min_len: reg fdtdec_get_int: spi-max-frequency: (not found) fsl_qspi_ofdata_to_platdata: reg_base=0x21e4000 amba_base=0x70000000 max-frequency=500000 fdtdec_get_int: spi-max-frequency: (not found) spi_get_bus_and_cs: Binding new device '35536896:0', busnum=35536896, cs=0, driver=spi_flash_std fdtdec_get_int: reg: (not found) Bound device 35536896:0 to qspi@021e4000 fdtdec_get_int: reg: (not found) fdtdec_get_int: spi-max-frequency: (not found) fdtdec_get_bool: spi-cpol fdtdec_get_bool: spi-cpha fdtdec_get_bool: spi-cs-high fdtdec_get_bool: spi-half-duplex uclass_find_device_by_seq: 0 -1 uclass_find_device_by_seq: 0 0 - -1 -1 - not found spi_flash_std_probe: slave=bfc5b208, cs=0 fsl_qspi_set_speed: hz=100000 fsl_qspi_set_mode: mode=0 SF: Got idcodes 00000000: 20 ba 19 10 00 .... SF: Detected N25Q256 with page size 256 Bytes, erase size 4 KiB, total 32 MiB SF: Warning - Only lower 16MiB accessible, Full access #define CONFIG_SPI_FLASH_BAR fsl_qspi_set_speed: hz=1000000 fsl_qspi_set_mode: mode=3 spi_get_bus_and_cs: bus=bfc53308, slave=bfc5b208
Thanks, Peng.
Hi Peng,
On 6 January 2015 at 20:06, Peng Fan B51431@freescale.com wrote:
Hi Simon,
I am hacking DTB and DM SPI FLASH support for i.MX 6SoloX. I have a question about `sf probe`. In original way, `sf probe` or `sf probe 0:0` can detect qspi flashes on my platform. But after using DM, I should use `sf probe 35536896:0` to probe flashes. 35536896 is the address of QSPI controller's reg base 0x021e4000 in hex format. Does I miss something in my driver? It seems dev->seq is not valid so should pass req_seq which is the address of qspi controller in dts file.
Any ideas?
You can use:
aliases { spi0 = "/spi@xxxx"; }
to correct the sequence number.
It would be better if we had a way to indicate a bus where reg provides the sequence number, so we know when it doesn't. I haven't come up with a good idea on that yet.
The log using `sf probe 0:0`. Fail to probe flash => sf probe 0:0 uclass_find_device_by_seq: 0 0
- 35536896 35536896
- not found
spi_find_bus_and_cs: No bus 0 uclass_find_device_by_seq: 0 0
- 35536896 35536896
- not found
uclass_find_device_by_seq: 1 0
- 35536896 35536896
- not found
Invalid bus 0 (err=-19) Failed to initialize SPI flash at 0:0 (error -19)
The log using `sf probe 35536896:0`. Success to probe flash. => sf probe 35536896:0 uclass_find_device_by_seq: 0 35536896
- 35536896 -1
- not found
spi_find_bus_and_cs: No bus 35536896 uclass_find_device_by_seq: 0 35536896
- 35536896 -1
- not found
uclass_find_device_by_seq: 1 35536896
- 35536896 -1
- found
uclass_find_device_by_seq: 0 -1 uclass_find_device_by_seq: 0 0
- -1 -1
- 33554432 -1
- 33554432 -1
- 34373632 -1
- -1 -1
- 34603008 -1
- 35651584 -1
- 35913728 -1
- -1 -1
- not found
uclass_find_device_by_seq: 0 34603008
- -1 0
- 33554432 -1
- 33554432 -1
- 34373632 -1
- -1 -1
- 34603008 -1
- 35651584 -1
- 35913728 -1
- -1 -1
- not found
uclass_find_device_by_seq: 0 35536896
- 35536896 -1
- not found
fdtdec_get_int_array: reg get_prop_check_min_len: reg fdtdec_get_int: spi-max-frequency: (not found) fsl_qspi_ofdata_to_platdata: reg_base=0x21e4000 amba_base=0x70000000 max-frequency=500000 fdtdec_get_int: spi-max-frequency: (not found) spi_get_bus_and_cs: Binding new device '35536896:0', busnum=35536896, cs=0, driver=spi_flash_std fdtdec_get_int: reg: (not found) Bound device 35536896:0 to qspi@021e4000 fdtdec_get_int: reg: (not found) fdtdec_get_int: spi-max-frequency: (not found) fdtdec_get_bool: spi-cpol fdtdec_get_bool: spi-cpha fdtdec_get_bool: spi-cs-high fdtdec_get_bool: spi-half-duplex uclass_find_device_by_seq: 0 -1 uclass_find_device_by_seq: 0 0
- -1 -1
- not found
spi_flash_std_probe: slave=bfc5b208, cs=0 fsl_qspi_set_speed: hz=100000 fsl_qspi_set_mode: mode=0 SF: Got idcodes 00000000: 20 ba 19 10 00 .... SF: Detected N25Q256 with page size 256 Bytes, erase size 4 KiB, total 32 MiB SF: Warning - Only lower 16MiB accessible, Full access #define CONFIG_SPI_FLASH_BAR fsl_qspi_set_speed: hz=1000000 fsl_qspi_set_mode: mode=3 spi_get_bus_and_cs: bus=bfc53308, slave=bfc5b208
Regards, Simon
On Tue, 6 Jan 2015 22:33:02 -0700 Simon Glass sjg@chromium.org wrote:
Hi Peng,
On 6 January 2015 at 20:06, Peng Fan B51431@freescale.com wrote:
Hi Simon,
I am hacking DTB and DM SPI FLASH support for i.MX 6SoloX. I have a question about `sf probe`. In original way, `sf probe` or `sf probe 0:0` can detect qspi flashes on my platform. But after using DM, I should use `sf probe 35536896:0` to probe flashes. 35536896 is the address of QSPI controller's reg base 0x021e4000 in hex format. Does I miss something in my driver? It seems dev->seq is not valid so should pass req_seq which is the address of qspi controller in dts file.
Any ideas?
You can use:
aliases { spi0 = "/spi@xxxx"; }
to correct the sequence number.
It would be better if we had a way to indicate a bus where reg provides the sequence number, so we know when it doesn't. I haven't come up with a good idea on that yet.
My device tree source is growing its aliases node...
arch/arm/dts/uniphier-ph1-pro4-ref.dts
aliases { serial0 = &uart0; serial1 = &uart1; serial2 = &uart2; serial3 = &uart3; i2c0 = &i2c0; i2c1 = &i2c1; i2c2 = &i2c2; i2c3 = &i2c3; i2c5 = &i2c5; i2c6 = &i2c6; };
Best Regards Masahiro Yamada
Hi,
On 7 January 2015 at 02:22, Masahiro Yamada yamada.m@jp.panasonic.com wrote:
On Tue, 6 Jan 2015 22:33:02 -0700 Simon Glass sjg@chromium.org wrote:
Hi Peng,
On 6 January 2015 at 20:06, Peng Fan B51431@freescale.com wrote:
Hi Simon,
I am hacking DTB and DM SPI FLASH support for i.MX 6SoloX. I have a question about `sf probe`. In original way, `sf probe` or `sf probe 0:0` can detect qspi flashes on my platform. But after using DM, I should use `sf probe 35536896:0` to probe flashes. 35536896 is the address of QSPI controller's reg base 0x021e4000 in hex format. Does I miss something in my driver? It seems dev->seq is not valid so should pass req_seq which is the address of qspi controller in dts file.
Any ideas?
You can use:
aliases { spi0 = "/spi@xxxx"; }
to correct the sequence number.
It would be better if we had a way to indicate a bus where reg provides the sequence number, so we know when it doesn't. I haven't come up with a good idea on that yet.
My device tree source is growing its aliases node...
arch/arm/dts/uniphier-ph1-pro4-ref.dts
aliases { serial0 = &uart0; serial1 = &uart1; serial2 = &uart2; serial3 = &uart3; i2c0 = &i2c0; i2c1 = &i2c1; i2c2 = &i2c2; i2c3 = &i2c3; i2c5 = &i2c5; i2c6 = &i2c6; };
This is good. It makes it very clear in one place which port is which.
But I am going to propose dropping the 'reg' support for sequence numbers in driver model. With I2C and SPI doing there own thing, we don't use it. And it just creates problems - e.g. if reg is actually an address we end up with a very strange sequence number on various devices.
Regards, Simon
participants (3)
-
Masahiro Yamada -
Peng Fan -
Simon Glass