[U-Boot] [Question] DM SPI FLASH

[U-Boot] [Question] DM SPI FLASH

[Peng Fan]

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 at 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.

[U-Boot] [Question] DM SPI FLASH

[Simon Glass]

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

[U-Boot] [Question] DM SPI FLASH

[Jagan Teki]

On 7 January 2015 at 14:32, Peng.Fan at freescale.com
<Peng.Fan@freescale.com> wrote:
> Hi, Simon,
>
> It works for me using aliases. This aliases node reassigns req_seq number to dev, so it works.
>
> Another question, spi device driver can not get cs value?
> `sf probe 0:0`. Bus is 0, and cs is 0. I want to use cs value to configure qspi controller, but i did not find way to do this. `0:0` is a new created device whose parent is spi controller device. But spi driver works at bus level. I am not sure whether this is correct, just want one way to get cs to configure qspi controller.

Yes, dm-spi not quite well this run-time cs change as of now.
We discussed the same while implementing, may be you can add cs
attribute number for
that particular bus or add support in dm-spi itself to support runtime
configurable using
sf probe [[bus:]cs]]

>
> Thanks,
> Peng.
>
> -----Original Message-----
> From: sjg at google.com [mailto:sjg at google.com] On Behalf Of Simon Glass
> Sent: Wednesday, January 07, 2015 1:33 PM
> To: Fan Peng-B51431
> Cc: Jagan Teki; u-Boot Mailing List
> Subject: Re: [Question] DM SPI FLASH
>
> 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 at 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 at 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!
-- 
Jagan.

[U-Boot] [Question] DM SPI FLASH

[Masahiro Yamada]

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

[U-Boot] [Question] DM SPI FLASH

[Simon Glass]

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