[U-Boot] SPL Platdata howto?

[U-Boot] SPL Platdata howto?

[Simon Goldschmidt]

Hi,

while searching for bytes to save in SPL in order to add FIT signature 
handling, I am currently trying to get socfpga-gen5 to use OF_PLATDATA.

To begin, I stripped down socfpga_socrates_defconfig to absolutely 
nothing but serial drivers in SPL (with some modifications to the 
Kconfig) and enabled DEBUG_UART to see what's going on.

Now while this config runs OK with a dtb (it just won't boot as drivers 
are missing -> "failed to boot from all boot devices"), it does not find 
the serial driver after enabling OF_PLATDATA.

So since serial_rockchip.c already uses OF_PLATDATA and is based on 
ns16550 that my socfpga-gen5 platform is using: what do I have to do 
besides enabling OF_PLATDATA to get this working?

I just seems like uclass_first_device does not find any UCLASS_SERIAL 
deivce when OF_PLATDATA is enabled.

(And when answering this, keep in mind I need to get MMC and QSPI 
drivers working with OF_PLATDATA - I already fixed compiler errors in 
those, nothing more.)

Thanks,
Simon

[U-Boot] SPL Platdata howto?

[Simon Glass]

Hi Simon,

On Wed, 19 Dec 2018 at 14:06, Simon Goldschmidt
<simon.k.r.goldschmidt@gmail.com> wrote:
>
> Hi,
>
> while searching for bytes to save in SPL in order to add FIT signature
> handling, I am currently trying to get socfpga-gen5 to use OF_PLATDATA.
>
> To begin, I stripped down socfpga_socrates_defconfig to absolutely
> nothing but serial drivers in SPL (with some modifications to the
> Kconfig) and enabled DEBUG_UART to see what's going on.
>
> Now while this config runs OK with a dtb (it just won't boot as drivers
> are missing -> "failed to boot from all boot devices"), it does not find
> the serial driver after enabling OF_PLATDATA.
>
> So since serial_rockchip.c already uses OF_PLATDATA and is based on
> ns16550 that my socfpga-gen5 platform is using: what do I have to do
> besides enabling OF_PLATDATA to get this working?
>
> I just seems like uclass_first_device does not find any UCLASS_SERIAL
> deivce when OF_PLATDATA is enabled.

There is the of-plat.txt README.

Basically the dtoc tool creates U_BOOT_DEVICE() declarations and links
them with SPL. These should show up in your image and therefore be
bound. You can call dm_dump_all() in SPL to see what what devices are
bound. I presume you are calling spl_init()?

You can look at what dtoc produces. The example serial driver for
Rockchip is serial_rockchip.c

>
> (And when answering this, keep in mind I need to get MMC and QSPI
> drivers working with OF_PLATDATA - I already fixed compiler errors in
> those, nothing more.)

Yes MMC should be OK, but QSPI might be blazing a bit of a trail.

Regards,
Simon

[U-Boot] SPL Platdata howto?

[Simon Goldschmidt]

Am 20.12.2018 um 15:49 schrieb Simon Glass:
> Hi Simon,
> 
> On Wed, 19 Dec 2018 at 14:06, Simon Goldschmidt
> <simon.k.r.goldschmidt@gmail.com> wrote:
>>
>> Hi,
>>
>> while searching for bytes to save in SPL in order to add FIT signature
>> handling, I am currently trying to get socfpga-gen5 to use OF_PLATDATA.
>>
>> To begin, I stripped down socfpga_socrates_defconfig to absolutely
>> nothing but serial drivers in SPL (with some modifications to the
>> Kconfig) and enabled DEBUG_UART to see what's going on.
>>
>> Now while this config runs OK with a dtb (it just won't boot as drivers
>> are missing -> "failed to boot from all boot devices"), it does not find
>> the serial driver after enabling OF_PLATDATA.
>>
>> So since serial_rockchip.c already uses OF_PLATDATA and is based on
>> ns16550 that my socfpga-gen5 platform is using: what do I have to do
>> besides enabling OF_PLATDATA to get this working?
>>
>> I just seems like uclass_first_device does not find any UCLASS_SERIAL
>> deivce when OF_PLATDATA is enabled.
> 
> There is the of-plat.txt README.

Yes, I should have mentioned I already read that and still had those 
questions. Kconfig help says README.platdata though. We probably should 
update that link.

> Basically the dtoc tool creates U_BOOT_DEVICE() declarations and links
> them with SPL. These should show up in your image and therefore be
> bound. You can call dm_dump_all() in SPL to see what what devices are
> bound. I presume you are calling spl_init()?
> 
> You can look at what dtoc produces. The example serial driver for
> Rockchip is serial_rockchip.c

I saw that as an example (because I also have an ns16550 compatible on 
my board) but couldn't figure out why it is not bound. By debugging 
'dm_scan_platdata', 'lists_bind_drivers' and 'device_bind_by_name', by 
now I know the driver names don't match. That is something I did not get 
just by reading of-plat.txt. I'll work on a patch to clarify that document.

Right now, serial works. I had to add a new platform specific driver 
just like serial_rockchip though. For DTS, we can pass multiple 
'compatible' strings, but for platdata, we have to create multiple 
drivers. That's a bit strange when porting boards...

> 
>>
>> (And when answering this, keep in mind I need to get MMC and QSPI
>> drivers working with OF_PLATDATA - I already fixed compiler errors in
>> those, nothing more.)
> 
> Yes MMC should be OK, but QSPI might be blazing a bit of a trail.

I just wanted to start with QSPI, maybe I'll do MMC first now ;-)

Thanks for your hints!

Regards,
Simon

[U-Boot] SPL Platdata howto?

[Simon Glass]

Hi Simon,

On Thu, 20 Dec 2018 at 08:03, Simon Goldschmidt
<simon.k.r.goldschmidt@gmail.com> wrote:
>
> Am 20.12.2018 um 15:49 schrieb Simon Glass:
> > Hi Simon,
> >
> > On Wed, 19 Dec 2018 at 14:06, Simon Goldschmidt
> > <simon.k.r.goldschmidt@gmail.com> wrote:
> >>
> >> Hi,
> >>
> >> while searching for bytes to save in SPL in order to add FIT signature
> >> handling, I am currently trying to get socfpga-gen5 to use OF_PLATDATA.
> >>
> >> To begin, I stripped down socfpga_socrates_defconfig to absolutely
> >> nothing but serial drivers in SPL (with some modifications to the
> >> Kconfig) and enabled DEBUG_UART to see what's going on.
> >>
> >> Now while this config runs OK with a dtb (it just won't boot as drivers
> >> are missing -> "failed to boot from all boot devices"), it does not find
> >> the serial driver after enabling OF_PLATDATA.
> >>
> >> So since serial_rockchip.c already uses OF_PLATDATA and is based on
> >> ns16550 that my socfpga-gen5 platform is using: what do I have to do
> >> besides enabling OF_PLATDATA to get this working?
> >>
> >> I just seems like uclass_first_device does not find any UCLASS_SERIAL
> >> deivce when OF_PLATDATA is enabled.
> >
> > There is the of-plat.txt README.
>
> Yes, I should have mentioned I already read that and still had those
> questions. Kconfig help says README.platdata though. We probably should
> update that link.
>
> > Basically the dtoc tool creates U_BOOT_DEVICE() declarations and links
> > them with SPL. These should show up in your image and therefore be
> > bound. You can call dm_dump_all() in SPL to see what what devices are
> > bound. I presume you are calling spl_init()?
> >
> > You can look at what dtoc produces. The example serial driver for
> > Rockchip is serial_rockchip.c
>
> I saw that as an example (because I also have an ns16550 compatible on
> my board) but couldn't figure out why it is not bound. By debugging
> 'dm_scan_platdata', 'lists_bind_drivers' and 'device_bind_by_name', by
> now I know the driver names don't match. That is something I did not get
> just by reading of-plat.txt. I'll work on a patch to clarify that document.

Yes I'd really appreciate some patches here. It is hard to know what
people won't understand and this feature could really do with a more
details docs or a walk-through.

>
> Right now, serial works. I had to add a new platform specific driver
> just like serial_rockchip though. For DTS, we can pass multiple
> 'compatible' strings, but for platdata, we have to create multiple
> drivers. That's a bit strange when porting boards...

Yes it is. I'm not sure how to solve that though. Probably dtoc can be
made smarter. Ideally you only need one device of each uclass in SPL.

>
> >
> >>
> >> (And when answering this, keep in mind I need to get MMC and QSPI
> >> drivers working with OF_PLATDATA - I already fixed compiler errors in
> >> those, nothing more.)
> >
> > Yes MMC should be OK, but QSPI might be blazing a bit of a trail.
>
> I just wanted to start with QSPI, maybe I'll do MMC first now ;-)
>
> Thanks for your hints!

You're welcome, happy hunting.

Regards,
Simon

[U-Boot] SPL Platdata howto?

[Simon Goldschmidt]

Am 20.12.2018 um 18:37 schrieb Simon Glass:
> Hi Simon,
> 
> On Thu, 20 Dec 2018 at 08:03, Simon Goldschmidt
> <simon.k.r.goldschmidt@gmail.com> wrote:
>>
>> Am 20.12.2018 um 15:49 schrieb Simon Glass:
>>> Hi Simon,
>>>
>>> On Wed, 19 Dec 2018 at 14:06, Simon Goldschmidt
>>> <simon.k.r.goldschmidt@gmail.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> while searching for bytes to save in SPL in order to add FIT signature
>>>> handling, I am currently trying to get socfpga-gen5 to use OF_PLATDATA.
>>>>
>>>> To begin, I stripped down socfpga_socrates_defconfig to absolutely
>>>> nothing but serial drivers in SPL (with some modifications to the
>>>> Kconfig) and enabled DEBUG_UART to see what's going on.
>>>>
>>>> Now while this config runs OK with a dtb (it just won't boot as drivers
>>>> are missing -> "failed to boot from all boot devices"), it does not find
>>>> the serial driver after enabling OF_PLATDATA.
>>>>
>>>> So since serial_rockchip.c already uses OF_PLATDATA and is based on
>>>> ns16550 that my socfpga-gen5 platform is using: what do I have to do
>>>> besides enabling OF_PLATDATA to get this working?
>>>>
>>>> I just seems like uclass_first_device does not find any UCLASS_SERIAL
>>>> deivce when OF_PLATDATA is enabled.
>>>
>>> There is the of-plat.txt README.
>>
>> Yes, I should have mentioned I already read that and still had those
>> questions. Kconfig help says README.platdata though. We probably should
>> update that link.
>>
>>> Basically the dtoc tool creates U_BOOT_DEVICE() declarations and links
>>> them with SPL. These should show up in your image and therefore be
>>> bound. You can call dm_dump_all() in SPL to see what what devices are
>>> bound. I presume you are calling spl_init()?
>>>
>>> You can look at what dtoc produces. The example serial driver for
>>> Rockchip is serial_rockchip.c
>>
>> I saw that as an example (because I also have an ns16550 compatible on
>> my board) but couldn't figure out why it is not bound. By debugging
>> 'dm_scan_platdata', 'lists_bind_drivers' and 'device_bind_by_name', by
>> now I know the driver names don't match. That is something I did not get
>> just by reading of-plat.txt. I'll work on a patch to clarify that document.
> 
> Yes I'd really appreciate some patches here. It is hard to know what
> people won't understand and this feature could really do with a more
> details docs or a walk-through.
> 
>>
>> Right now, serial works. I had to add a new platform specific driver
>> just like serial_rockchip though. For DTS, we can pass multiple
>> 'compatible' strings, but for platdata, we have to create multiple
>> drivers. That's a bit strange when porting boards...
> 
> Yes it is. I'm not sure how to solve that though. Probably dtoc can be
> made smarter. Ideally you only need one device of each uclass in SPL.

Would it work to use the unchanged 'compatible' string for the '.name' 
of U_BOOT_DEVICE generated by dtoc? Then the binding of such drivers 
could change from comparing names to comparing to compatibles. That 
would make it more DTS-like.

Then, I think we could need some kind of fallback code for properties 
that are optional in the DTS. Maybe we can create defines for each dtd 
struct so that drivers can test the existence of dtd sturct fields using 
#ifdef. [Given the special usage, I guess it's OK to assume that theses 
structs are only used once per DTS so that we don't have to worry about 
how to solve this for multiple occurrences with different optional 
parameters?]

Oh, and then I think dtb_platdata.py should create the dtd instances as 
const. I'll prepare a patch for that.

> 
>>
>>>
>>>>
>>>> (And when answering this, keep in mind I need to get MMC and QSPI
>>>> drivers working with OF_PLATDATA - I already fixed compiler errors in
>>>> those, nothing more.)
>>>
>>> Yes MMC should be OK, but QSPI might be blazing a bit of a trail.
>>
>> I just wanted to start with QSPI, maybe I'll do MMC first now ;-)

And now MMC is working just fine with very small adaptions to the 
current socfpga_dw_mmc driver! I only hope that this whole thing gives 
me the bytes I need to implement FIT signatures in SPL...

Regards,
Simon

>>
>> Thanks for your hints!
> 
> You're welcome, happy hunting.
> 
> Regards,
> Simon
> 

[U-Boot] SPL Platdata howto?

[Simon Goldschmidt]

Am 20.12.2018 um 21:53 schrieb Simon Goldschmidt:
> Am 20.12.2018 um 18:37 schrieb Simon Glass:
>> Hi Simon,
>>
>> On Thu, 20 Dec 2018 at 08:03, Simon Goldschmidt
>> <simon.k.r.goldschmidt@gmail.com> wrote:
>>>
>>> Am 20.12.2018 um 15:49 schrieb Simon Glass:
>>>> Hi Simon,
>>>>
>>>> On Wed, 19 Dec 2018 at 14:06, Simon Goldschmidt
>>>> <simon.k.r.goldschmidt@gmail.com> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> while searching for bytes to save in SPL in order to add FIT signature
>>>>> handling, I am currently trying to get socfpga-gen5 to use OF_PLATDATA.
>>>>>
>>>>> To begin, I stripped down socfpga_socrates_defconfig to absolutely
>>>>> nothing but serial drivers in SPL (with some modifications to the
>>>>> Kconfig) and enabled DEBUG_UART to see what's going on.
>>>>>
>>>>> Now while this config runs OK with a dtb (it just won't boot as drivers
>>>>> are missing -> "failed to boot from all boot devices"), it does not find
>>>>> the serial driver after enabling OF_PLATDATA.
>>>>>
>>>>> So since serial_rockchip.c already uses OF_PLATDATA and is based on
>>>>> ns16550 that my socfpga-gen5 platform is using: what do I have to do
>>>>> besides enabling OF_PLATDATA to get this working?
>>>>>
>>>>> I just seems like uclass_first_device does not find any UCLASS_SERIAL
>>>>> deivce when OF_PLATDATA is enabled.
>>>>
>>>> There is the of-plat.txt README.
>>>
>>> Yes, I should have mentioned I already read that and still had those
>>> questions. Kconfig help says README.platdata though. We probably should
>>> update that link.
>>>
>>>> Basically the dtoc tool creates U_BOOT_DEVICE() declarations and links
>>>> them with SPL. These should show up in your image and therefore be
>>>> bound. You can call dm_dump_all() in SPL to see what what devices are
>>>> bound. I presume you are calling spl_init()?
>>>>
>>>> You can look at what dtoc produces. The example serial driver for
>>>> Rockchip is serial_rockchip.c
>>>
>>> I saw that as an example (because I also have an ns16550 compatible on
>>> my board) but couldn't figure out why it is not bound. By debugging
>>> 'dm_scan_platdata', 'lists_bind_drivers' and 'device_bind_by_name', by
>>> now I know the driver names don't match. That is something I did not get
>>> just by reading of-plat.txt. I'll work on a patch to clarify that document.
>>
>> Yes I'd really appreciate some patches here. It is hard to know what
>> people won't understand and this feature could really do with a more
>> details docs or a walk-through.
>>
>>>
>>> Right now, serial works. I had to add a new platform specific driver
>>> just like serial_rockchip though. For DTS, we can pass multiple
>>> 'compatible' strings, but for platdata, we have to create multiple
>>> drivers. That's a bit strange when porting boards...
>>
>> Yes it is. I'm not sure how to solve that though. Probably dtoc can be
>> made smarter. Ideally you only need one device of each uclass in SPL.
> 
> Would it work to use the unchanged 'compatible' string for the '.name'
> of U_BOOT_DEVICE generated by dtoc? Then the binding of such drivers
> could change from comparing names to comparing to compatibles. That
> would make it more DTS-like.
> 
> Then, I think we could need some kind of fallback code for properties
> that are optional in the DTS. Maybe we can create defines for each dtd
> struct so that drivers can test the existence of dtd sturct fields using
> #ifdef. [Given the special usage, I guess it's OK to assume that theses
> structs are only used once per DTS so that we don't have to worry about
> how to solve this for multiple occurrences with different optional
> parameters?]
> 
> Oh, and then I think dtb_platdata.py should create the dtd instances as
> const. I'll prepare a patch for that.
> 
>>
>>>
>>>>
>>>>>
>>>>> (And when answering this, keep in mind I need to get MMC and QSPI
>>>>> drivers working with OF_PLATDATA - I already fixed compiler errors in
>>>>> those, nothing more.)
>>>>
>>>> Yes MMC should be OK, but QSPI might be blazing a bit of a trail.

Hmm, QSPI works as well when hacking the things that the driver wants to 
parse from subnode properties. However, I haven't found a way to access 
the platform data of the spi-flash from the driver.

Maybe we need to somehow make subnodes available in the dt-platdata 
structs to make that work?

Regards,
Simon

>>>
>>> I just wanted to start with QSPI, maybe I'll do MMC first now ;-)
> 
> And now MMC is working just fine with very small adaptions to the
> current socfpga_dw_mmc driver! I only hope that this whole thing gives
> me the bytes I need to implement FIT signatures in SPL...
> 
> Regards,
> Simon
> 
>>>
>>> Thanks for your hints!
>>
>> You're welcome, happy hunting.
>>
>> Regards,
>> Simon
>>
> 

[U-Boot] SPL Platdata howto?

[Simon Glass]

Hi Simon,

On Thu, 20 Dec 2018 at 14:32, Simon Goldschmidt
<simon.k.r.goldschmidt@gmail.com> wrote:
>
> Am 20.12.2018 um 21:53 schrieb Simon Goldschmidt:
> > Am 20.12.2018 um 18:37 schrieb Simon Glass:
> >> Hi Simon,
> >>
> >> On Thu, 20 Dec 2018 at 08:03, Simon Goldschmidt
> >> <simon.k.r.goldschmidt@gmail.com> wrote:
> >>>
> >>> Am 20.12.2018 um 15:49 schrieb Simon Glass:
> >>>> Hi Simon,
> >>>>
> >>>> On Wed, 19 Dec 2018 at 14:06, Simon Goldschmidt
> >>>> <simon.k.r.goldschmidt@gmail.com> wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> while searching for bytes to save in SPL in order to add FIT signature
> >>>>> handling, I am currently trying to get socfpga-gen5 to use OF_PLATDATA.
> >>>>>
> >>>>> To begin, I stripped down socfpga_socrates_defconfig to absolutely
> >>>>> nothing but serial drivers in SPL (with some modifications to the
> >>>>> Kconfig) and enabled DEBUG_UART to see what's going on.
> >>>>>
> >>>>> Now while this config runs OK with a dtb (it just won't boot as drivers
> >>>>> are missing -> "failed to boot from all boot devices"), it does not find
> >>>>> the serial driver after enabling OF_PLATDATA.
> >>>>>
> >>>>> So since serial_rockchip.c already uses OF_PLATDATA and is based on
> >>>>> ns16550 that my socfpga-gen5 platform is using: what do I have to do
> >>>>> besides enabling OF_PLATDATA to get this working?
> >>>>>
> >>>>> I just seems like uclass_first_device does not find any UCLASS_SERIAL
> >>>>> deivce when OF_PLATDATA is enabled.
> >>>>
> >>>> There is the of-plat.txt README.
> >>>
> >>> Yes, I should have mentioned I already read that and still had those
> >>> questions. Kconfig help says README.platdata though. We probably should
> >>> update that link.
> >>>
> >>>> Basically the dtoc tool creates U_BOOT_DEVICE() declarations and links
> >>>> them with SPL. These should show up in your image and therefore be
> >>>> bound. You can call dm_dump_all() in SPL to see what what devices are
> >>>> bound. I presume you are calling spl_init()?
> >>>>
> >>>> You can look at what dtoc produces. The example serial driver for
> >>>> Rockchip is serial_rockchip.c
> >>>
> >>> I saw that as an example (because I also have an ns16550 compatible on
> >>> my board) but couldn't figure out why it is not bound. By debugging
> >>> 'dm_scan_platdata', 'lists_bind_drivers' and 'device_bind_by_name', by
> >>> now I know the driver names don't match. That is something I did not get
> >>> just by reading of-plat.txt. I'll work on a patch to clarify that document.
> >>
> >> Yes I'd really appreciate some patches here. It is hard to know what
> >> people won't understand and this feature could really do with a more
> >> details docs or a walk-through.
> >>
> >>>
> >>> Right now, serial works. I had to add a new platform specific driver
> >>> just like serial_rockchip though. For DTS, we can pass multiple
> >>> 'compatible' strings, but for platdata, we have to create multiple
> >>> drivers. That's a bit strange when porting boards...
> >>
> >> Yes it is. I'm not sure how to solve that though. Probably dtoc can be
> >> made smarter. Ideally you only need one device of each uclass in SPL.
> >
> > Would it work to use the unchanged 'compatible' string for the '.name'
> > of U_BOOT_DEVICE generated by dtoc? Then the binding of such drivers
> > could change from comparing names to comparing to compatibles. That
> > would make it more DTS-like.
> >
> > Then, I think we could need some kind of fallback code for properties
> > that are optional in the DTS. Maybe we can create defines for each dtd
> > struct so that drivers can test the existence of dtd sturct fields using
> > #ifdef. [Given the special usage, I guess it's OK to assume that theses
> > structs are only used once per DTS so that we don't have to worry about
> > how to solve this for multiple occurrences with different optional
> > parameters?]
> >
> > Oh, and then I think dtb_platdata.py should create the dtd instances as
> > const. I'll prepare a patch for that.
> >
> >>
> >>>
> >>>>
> >>>>>
> >>>>> (And when answering this, keep in mind I need to get MMC and QSPI
> >>>>> drivers working with OF_PLATDATA - I already fixed compiler errors in
> >>>>> those, nothing more.)
> >>>>
> >>>> Yes MMC should be OK, but QSPI might be blazing a bit of a trail.
>
> Hmm, QSPI works as well when hacking the things that the driver wants to
> parse from subnode properties. However, I haven't found a way to access
> the platform data of the spi-flash from the driver.
>
> Maybe we need to somehow make subnodes available in the dt-platdata
> structs to make that work?

There is support for phandles but not for parent relationships. I
suppose it would not be impossible to add that in dtoc with a 'parent'
pointer.

Regards,
Simon


>
> Regards,
> Simon
>
> >>>
> >>> I just wanted to start with QSPI, maybe I'll do MMC first now ;-)
> >
> > And now MMC is working just fine with very small adaptions to the
> > current socfpga_dw_mmc driver! I only hope that this whole thing gives
> > me the bytes I need to implement FIT signatures in SPL...
> >
> > Regards,
> > Simon
> >
> >>>
> >>> Thanks for your hints!
> >>
> >> You're welcome, happy hunting.
> >>
> >> Regards,
> >> Simon
> >>
> >
>

[U-Boot] SPL Platdata howto?

[Simon Goldschmidt]

Am Fr., 21. Dez. 2018, 22:16 hat Simon Glass <sjg@chromium.org> geschrieben:

> Hi Simon,
>
> On Thu, 20 Dec 2018 at 14:32, Simon Goldschmidt
> <simon.k.r.goldschmidt@gmail.com> wrote:
> >
> > Am 20.12.2018 um 21:53 schrieb Simon Goldschmidt:
> > > Am 20.12.2018 um 18:37 schrieb Simon Glass:
> > >> Hi Simon,
> > >>
> > >> On Thu, 20 Dec 2018 at 08:03, Simon Goldschmidt
> > >> <simon.k.r.goldschmidt@gmail.com> wrote:
> > >>>
> > >>> Am 20.12.2018 um 15:49 schrieb Simon Glass:
> > >>>> Hi Simon,
> > >>>>
> > >>>> On Wed, 19 Dec 2018 at 14:06, Simon Goldschmidt
> > >>>> <simon.k.r.goldschmidt@gmail.com> wrote:
> > >>>>>
> > >>>>> Hi,
> > >>>>>
> > >>>>> while searching for bytes to save in SPL in order to add FIT
> signature
> > >>>>> handling, I am currently trying to get socfpga-gen5 to use
> OF_PLATDATA.
> > >>>>>
> > >>>>> To begin, I stripped down socfpga_socrates_defconfig to absolutely
> > >>>>> nothing but serial drivers in SPL (with some modifications to the
> > >>>>> Kconfig) and enabled DEBUG_UART to see what's going on.
> > >>>>>
> > >>>>> Now while this config runs OK with a dtb (it just won't boot as
> drivers
> > >>>>> are missing -> "failed to boot from all boot devices"), it does
> not find
> > >>>>> the serial driver after enabling OF_PLATDATA.
> > >>>>>
> > >>>>> So since serial_rockchip.c already uses OF_PLATDATA and is based on
> > >>>>> ns16550 that my socfpga-gen5 platform is using: what do I have to
> do
> > >>>>> besides enabling OF_PLATDATA to get this working?
> > >>>>>
> > >>>>> I just seems like uclass_first_device does not find any
> UCLASS_SERIAL
> > >>>>> deivce when OF_PLATDATA is enabled.
> > >>>>
> > >>>> There is the of-plat.txt README.
> > >>>
> > >>> Yes, I should have mentioned I already read that and still had those
> > >>> questions. Kconfig help says README.platdata though. We probably
> should
> > >>> update that link.
> > >>>
> > >>>> Basically the dtoc tool creates U_BOOT_DEVICE() declarations and
> links
> > >>>> them with SPL. These should show up in your image and therefore be
> > >>>> bound. You can call dm_dump_all() in SPL to see what what devices
> are
> > >>>> bound. I presume you are calling spl_init()?
> > >>>>
> > >>>> You can look at what dtoc produces. The example serial driver for
> > >>>> Rockchip is serial_rockchip.c
> > >>>
> > >>> I saw that as an example (because I also have an ns16550 compatible
> on
> > >>> my board) but couldn't figure out why it is not bound. By debugging
> > >>> 'dm_scan_platdata', 'lists_bind_drivers' and 'device_bind_by_name',
> by
> > >>> now I know the driver names don't match. That is something I did not
> get
> > >>> just by reading of-plat.txt. I'll work on a patch to clarify that
> document.
> > >>
> > >> Yes I'd really appreciate some patches here. It is hard to know what
> > >> people won't understand and this feature could really do with a more
> > >> details docs or a walk-through.
> > >>
> > >>>
> > >>> Right now, serial works. I had to add a new platform specific driver
> > >>> just like serial_rockchip though. For DTS, we can pass multiple
> > >>> 'compatible' strings, but for platdata, we have to create multiple
> > >>> drivers. That's a bit strange when porting boards...
> > >>
> > >> Yes it is. I'm not sure how to solve that though. Probably dtoc can be
> > >> made smarter. Ideally you only need one device of each uclass in SPL.
> > >
> > > Would it work to use the unchanged 'compatible' string for the '.name'
> > > of U_BOOT_DEVICE generated by dtoc? Then the binding of such drivers
> > > could change from comparing names to comparing to compatibles. That
> > > would make it more DTS-like.
> > >
> > > Then, I think we could need some kind of fallback code for properties
> > > that are optional in the DTS. Maybe we can create defines for each dtd
> > > struct so that drivers can test the existence of dtd sturct fields
> using
> > > #ifdef. [Given the special usage, I guess it's OK to assume that theses
> > > structs are only used once per DTS so that we don't have to worry about
> > > how to solve this for multiple occurrences with different optional
> > > parameters?]
> > >
> > > Oh, and then I think dtb_platdata.py should create the dtd instances as
> > > const. I'll prepare a patch for that.
> > >
> > >>
> > >>>
> > >>>>
> > >>>>>
> > >>>>> (And when answering this, keep in mind I need to get MMC and QSPI
> > >>>>> drivers working with OF_PLATDATA - I already fixed compiler errors
> in
> > >>>>> those, nothing more.)
> > >>>>
> > >>>> Yes MMC should be OK, but QSPI might be blazing a bit of a trail.
> >
> > Hmm, QSPI works as well when hacking the things that the driver wants to
> > parse from subnode properties. However, I haven't found a way to access
> > the platform data of the spi-flash from the driver.
> >
> > Maybe we need to somehow make subnodes available in the dt-platdata
> > structs to make that work?
>
> There is support for phandles but not for parent relationships. I
> suppose it would not be impossible to add that in dtoc with a 'parent'
> pointer.
>

SPI flash actually needs it the other way round. At least the cadence qspi
driver I'm using checks for a subnode that describes the flash chip.

I'll see if I can add that to dtoc.

Regards,
Simon


> Regards,
> Simon
>
>
> >
> > Regards,
> > Simon
> >
> > >>>
> > >>> I just wanted to start with QSPI, maybe I'll do MMC first now ;-)
> > >
> > > And now MMC is working just fine with very small adaptions to the
> > > current socfpga_dw_mmc driver! I only hope that this whole thing gives
> > > me the bytes I need to implement FIT signatures in SPL...
> > >
> > > Regards,
> > > Simon
> > >
> > >>>
> > >>> Thanks for your hints!
> > >>
> > >> You're welcome, happy hunting.
> > >>
> > >> Regards,
> > >> Simon
> > >>
> > >
> >
>

[U-Boot] SPL Platdata howto?

[Simon Goldschmidt]

On Fri, Dec 21, 2018 at 10:20 PM Simon Goldschmidt
<simon.k.r.goldschmidt@gmail.com> wrote:
>
>
>
> Am Fr., 21. Dez. 2018, 22:16 hat Simon Glass <sjg@chromium.org> geschrieben:
>>
>> Hi Simon,
>>
>> On Thu, 20 Dec 2018 at 14:32, Simon Goldschmidt
>> <simon.k.r.goldschmidt@gmail.com> wrote:
>> >
>> > Am 20.12.2018 um 21:53 schrieb Simon Goldschmidt:
>> > > Am 20.12.2018 um 18:37 schrieb Simon Glass:
>> > >> Hi Simon,
>> > >>
>> > >> On Thu, 20 Dec 2018 at 08:03, Simon Goldschmidt
>> > >> <simon.k.r.goldschmidt@gmail.com> wrote:
>> > >>>
>> > >>> Am 20.12.2018 um 15:49 schrieb Simon Glass:
>> > >>>> Hi Simon,
>> > >>>>
>> > >>>> On Wed, 19 Dec 2018 at 14:06, Simon Goldschmidt
>> > >>>> <simon.k.r.goldschmidt@gmail.com> wrote:
>> > >>>>>
>> > >>>>> Hi,
>> > >>>>>
>> > >>>>> while searching for bytes to save in SPL in order to add FIT signature
>> > >>>>> handling, I am currently trying to get socfpga-gen5 to use OF_PLATDATA.
>> > >>>>>
>> > >>>>> To begin, I stripped down socfpga_socrates_defconfig to absolutely
>> > >>>>> nothing but serial drivers in SPL (with some modifications to the
>> > >>>>> Kconfig) and enabled DEBUG_UART to see what's going on.
>> > >>>>>
>> > >>>>> Now while this config runs OK with a dtb (it just won't boot as drivers
>> > >>>>> are missing -> "failed to boot from all boot devices"), it does not find
>> > >>>>> the serial driver after enabling OF_PLATDATA.
>> > >>>>>
>> > >>>>> So since serial_rockchip.c already uses OF_PLATDATA and is based on
>> > >>>>> ns16550 that my socfpga-gen5 platform is using: what do I have to do
>> > >>>>> besides enabling OF_PLATDATA to get this working?
>> > >>>>>
>> > >>>>> I just seems like uclass_first_device does not find any UCLASS_SERIAL
>> > >>>>> deivce when OF_PLATDATA is enabled.
>> > >>>>
>> > >>>> There is the of-plat.txt README.
>> > >>>
>> > >>> Yes, I should have mentioned I already read that and still had those
>> > >>> questions. Kconfig help says README.platdata though. We probably should
>> > >>> update that link.
>> > >>>
>> > >>>> Basically the dtoc tool creates U_BOOT_DEVICE() declarations and links
>> > >>>> them with SPL. These should show up in your image and therefore be
>> > >>>> bound. You can call dm_dump_all() in SPL to see what what devices are
>> > >>>> bound. I presume you are calling spl_init()?
>> > >>>>
>> > >>>> You can look at what dtoc produces. The example serial driver for
>> > >>>> Rockchip is serial_rockchip.c
>> > >>>
>> > >>> I saw that as an example (because I also have an ns16550 compatible on
>> > >>> my board) but couldn't figure out why it is not bound. By debugging
>> > >>> 'dm_scan_platdata', 'lists_bind_drivers' and 'device_bind_by_name', by
>> > >>> now I know the driver names don't match. That is something I did not get
>> > >>> just by reading of-plat.txt. I'll work on a patch to clarify that document.
>> > >>
>> > >> Yes I'd really appreciate some patches here. It is hard to know what
>> > >> people won't understand and this feature could really do with a more
>> > >> details docs or a walk-through.
>> > >>
>> > >>>
>> > >>> Right now, serial works. I had to add a new platform specific driver
>> > >>> just like serial_rockchip though. For DTS, we can pass multiple
>> > >>> 'compatible' strings, but for platdata, we have to create multiple
>> > >>> drivers. That's a bit strange when porting boards...
>> > >>
>> > >> Yes it is. I'm not sure how to solve that though. Probably dtoc can be
>> > >> made smarter. Ideally you only need one device of each uclass in SPL.
>> > >
>> > > Would it work to use the unchanged 'compatible' string for the '.name'
>> > > of U_BOOT_DEVICE generated by dtoc? Then the binding of such drivers
>> > > could change from comparing names to comparing to compatibles. That
>> > > would make it more DTS-like.
>> > >
>> > > Then, I think we could need some kind of fallback code for properties
>> > > that are optional in the DTS. Maybe we can create defines for each dtd
>> > > struct so that drivers can test the existence of dtd sturct fields using
>> > > #ifdef. [Given the special usage, I guess it's OK to assume that theses
>> > > structs are only used once per DTS so that we don't have to worry about
>> > > how to solve this for multiple occurrences with different optional
>> > > parameters?]
>> > >
>> > > Oh, and then I think dtb_platdata.py should create the dtd instances as
>> > > const. I'll prepare a patch for that.
>> > >
>> > >>
>> > >>>
>> > >>>>
>> > >>>>>
>> > >>>>> (And when answering this, keep in mind I need to get MMC and QSPI
>> > >>>>> drivers working with OF_PLATDATA - I already fixed compiler errors in
>> > >>>>> those, nothing more.)
>> > >>>>
>> > >>>> Yes MMC should be OK, but QSPI might be blazing a bit of a trail.
>> >
>> > Hmm, QSPI works as well when hacking the things that the driver wants to
>> > parse from subnode properties. However, I haven't found a way to access
>> > the platform data of the spi-flash from the driver.
>> >
>> > Maybe we need to somehow make subnodes available in the dt-platdata
>> > structs to make that work?
>>
>> There is support for phandles but not for parent relationships. I
>> suppose it would not be impossible to add that in dtoc with a 'parent'
>> pointer.
>
>
> SPI flash actually needs it the other way round. At least the cadence qspi driver I'm using checks for a subnode that describes the flash chip.
>
> I'll see if I can add that to dtoc.

By now I have SPI successfully running with platdata by adding child
arrays to the platdata struct via dtoc.

However, probing the flash chip is not found in 'spi_get_bus_and_cs'
and so the transfer falls back to 100 kHz, which is of course bad.
That code expects a udevice child under the spi udevice. Looks like
that needs more changes than just in dtoc?

Did you have SPI running with platdata on any board, yet?

Regards,
Simon

[U-Boot] SPL Platdata howto?

[Simon Glass]

Hi Simon,

On Fri, 4 Jan 2019 at 00:15, Simon Goldschmidt
<simon.k.r.goldschmidt@gmail.com> wrote:
>
> On Fri, Dec 21, 2018 at 10:20 PM Simon Goldschmidt
> <simon.k.r.goldschmidt@gmail.com> wrote:
> >
> >
> >
> > Am Fr., 21. Dez. 2018, 22:16 hat Simon Glass <sjg@chromium.org> geschrieben:
> >>
> >> Hi Simon,
> >>
> >> On Thu, 20 Dec 2018 at 14:32, Simon Goldschmidt
> >> <simon.k.r.goldschmidt@gmail.com> wrote:
> >> >
> >> > Am 20.12.2018 um 21:53 schrieb Simon Goldschmidt:
> >> > > Am 20.12.2018 um 18:37 schrieb Simon Glass:
> >> > >> Hi Simon,
> >> > >>
> >> > >> On Thu, 20 Dec 2018 at 08:03, Simon Goldschmidt
> >> > >> <simon.k.r.goldschmidt@gmail.com> wrote:
> >> > >>>
> >> > >>> Am 20.12.2018 um 15:49 schrieb Simon Glass:
> >> > >>>> Hi Simon,
> >> > >>>>
> >> > >>>> On Wed, 19 Dec 2018 at 14:06, Simon Goldschmidt
> >> > >>>> <simon.k.r.goldschmidt@gmail.com> wrote:
> >> > >>>>>
> >> > >>>>> Hi,
> >> > >>>>>
> >> > >>>>> while searching for bytes to save in SPL in order to add FIT signature
> >> > >>>>> handling, I am currently trying to get socfpga-gen5 to use OF_PLATDATA.
> >> > >>>>>
> >> > >>>>> To begin, I stripped down socfpga_socrates_defconfig to absolutely
> >> > >>>>> nothing but serial drivers in SPL (with some modifications to the
> >> > >>>>> Kconfig) and enabled DEBUG_UART to see what's going on.
> >> > >>>>>
> >> > >>>>> Now while this config runs OK with a dtb (it just won't boot as drivers
> >> > >>>>> are missing -> "failed to boot from all boot devices"), it does not find
> >> > >>>>> the serial driver after enabling OF_PLATDATA.
> >> > >>>>>
> >> > >>>>> So since serial_rockchip.c already uses OF_PLATDATA and is based on
> >> > >>>>> ns16550 that my socfpga-gen5 platform is using: what do I have to do
> >> > >>>>> besides enabling OF_PLATDATA to get this working?
> >> > >>>>>
> >> > >>>>> I just seems like uclass_first_device does not find any UCLASS_SERIAL
> >> > >>>>> deivce when OF_PLATDATA is enabled.
> >> > >>>>
> >> > >>>> There is the of-plat.txt README.
> >> > >>>
> >> > >>> Yes, I should have mentioned I already read that and still had those
> >> > >>> questions. Kconfig help says README.platdata though. We probably should
> >> > >>> update that link.
> >> > >>>
> >> > >>>> Basically the dtoc tool creates U_BOOT_DEVICE() declarations and links
> >> > >>>> them with SPL. These should show up in your image and therefore be
> >> > >>>> bound. You can call dm_dump_all() in SPL to see what what devices are
> >> > >>>> bound. I presume you are calling spl_init()?
> >> > >>>>
> >> > >>>> You can look at what dtoc produces. The example serial driver for
> >> > >>>> Rockchip is serial_rockchip.c
> >> > >>>
> >> > >>> I saw that as an example (because I also have an ns16550 compatible on
> >> > >>> my board) but couldn't figure out why it is not bound. By debugging
> >> > >>> 'dm_scan_platdata', 'lists_bind_drivers' and 'device_bind_by_name', by
> >> > >>> now I know the driver names don't match. That is something I did not get
> >> > >>> just by reading of-plat.txt. I'll work on a patch to clarify that document.
> >> > >>
> >> > >> Yes I'd really appreciate some patches here. It is hard to know what
> >> > >> people won't understand and this feature could really do with a more
> >> > >> details docs or a walk-through.
> >> > >>
> >> > >>>
> >> > >>> Right now, serial works. I had to add a new platform specific driver
> >> > >>> just like serial_rockchip though. For DTS, we can pass multiple
> >> > >>> 'compatible' strings, but for platdata, we have to create multiple
> >> > >>> drivers. That's a bit strange when porting boards...
> >> > >>
> >> > >> Yes it is. I'm not sure how to solve that though. Probably dtoc can be
> >> > >> made smarter. Ideally you only need one device of each uclass in SPL.
> >> > >
> >> > > Would it work to use the unchanged 'compatible' string for the '.name'
> >> > > of U_BOOT_DEVICE generated by dtoc? Then the binding of such drivers
> >> > > could change from comparing names to comparing to compatibles. That
> >> > > would make it more DTS-like.
> >> > >
> >> > > Then, I think we could need some kind of fallback code for properties
> >> > > that are optional in the DTS. Maybe we can create defines for each dtd
> >> > > struct so that drivers can test the existence of dtd sturct fields using
> >> > > #ifdef. [Given the special usage, I guess it's OK to assume that theses
> >> > > structs are only used once per DTS so that we don't have to worry about
> >> > > how to solve this for multiple occurrences with different optional
> >> > > parameters?]
> >> > >
> >> > > Oh, and then I think dtb_platdata.py should create the dtd instances as
> >> > > const. I'll prepare a patch for that.
> >> > >
> >> > >>
> >> > >>>
> >> > >>>>
> >> > >>>>>
> >> > >>>>> (And when answering this, keep in mind I need to get MMC and QSPI
> >> > >>>>> drivers working with OF_PLATDATA - I already fixed compiler errors in
> >> > >>>>> those, nothing more.)
> >> > >>>>
> >> > >>>> Yes MMC should be OK, but QSPI might be blazing a bit of a trail.
> >> >
> >> > Hmm, QSPI works as well when hacking the things that the driver wants to
> >> > parse from subnode properties. However, I haven't found a way to access
> >> > the platform data of the spi-flash from the driver.
> >> >
> >> > Maybe we need to somehow make subnodes available in the dt-platdata
> >> > structs to make that work?
> >>
> >> There is support for phandles but not for parent relationships. I
> >> suppose it would not be impossible to add that in dtoc with a 'parent'
> >> pointer.
> >
> >
> > SPI flash actually needs it the other way round. At least the cadence qspi driver I'm using checks for a subnode that describes the flash chip.
> >
> > I'll see if I can add that to dtoc.
>
> By now I have SPI successfully running with platdata by adding child
> arrays to the platdata struct via dtoc.
>
> However, probing the flash chip is not found in 'spi_get_bus_and_cs'
> and so the transfer falls back to 100 kHz, which is of course bad.
> That code expects a udevice child under the spi udevice. Looks like
> that needs more changes than just in dtoc?
>
> Did you have SPI running with platdata on any board, yet?

No. The implementation does not deal well with parent/child
relationships, as with buses, and in every case we need to make
changes.

That said, spi_get_bus_and_cs() is only used if you don't have the SPI
device in the DT.

Regards,
Simon

[U-Boot] SPL Platdata howto?

[Simon Goldschmidt]

On Thu, Jan 10, 2019 at 1:57 PM Simon Glass <sjg@chromium.org> wrote:
>
> Hi Simon,
>
> On Fri, 4 Jan 2019 at 00:15, Simon Goldschmidt
> <simon.k.r.goldschmidt@gmail.com> wrote:
> >
> > On Fri, Dec 21, 2018 at 10:20 PM Simon Goldschmidt
> > <simon.k.r.goldschmidt@gmail.com> wrote:
> > >
> > >
> > >
> > > Am Fr., 21. Dez. 2018, 22:16 hat Simon Glass <sjg@chromium.org> geschrieben:
> > >>
> > >> Hi Simon,
> > >>
> > >> On Thu, 20 Dec 2018 at 14:32, Simon Goldschmidt
> > >> <simon.k.r.goldschmidt@gmail.com> wrote:
> > >> >
> > >> > Am 20.12.2018 um 21:53 schrieb Simon Goldschmidt:
> > >> > > Am 20.12.2018 um 18:37 schrieb Simon Glass:
> > >> > >> Hi Simon,
> > >> > >>
> > >> > >> On Thu, 20 Dec 2018 at 08:03, Simon Goldschmidt
> > >> > >> <simon.k.r.goldschmidt@gmail.com> wrote:
> > >> > >>>
> > >> > >>> Am 20.12.2018 um 15:49 schrieb Simon Glass:
> > >> > >>>> Hi Simon,
> > >> > >>>>
> > >> > >>>> On Wed, 19 Dec 2018 at 14:06, Simon Goldschmidt
> > >> > >>>> <simon.k.r.goldschmidt@gmail.com> wrote:
> > >> > >>>>>
> > >> > >>>>> Hi,
> > >> > >>>>>
> > >> > >>>>> while searching for bytes to save in SPL in order to add FIT signature
> > >> > >>>>> handling, I am currently trying to get socfpga-gen5 to use OF_PLATDATA.
> > >> > >>>>>
> > >> > >>>>> To begin, I stripped down socfpga_socrates_defconfig to absolutely
> > >> > >>>>> nothing but serial drivers in SPL (with some modifications to the
> > >> > >>>>> Kconfig) and enabled DEBUG_UART to see what's going on.
> > >> > >>>>>
> > >> > >>>>> Now while this config runs OK with a dtb (it just won't boot as drivers
> > >> > >>>>> are missing -> "failed to boot from all boot devices"), it does not find
> > >> > >>>>> the serial driver after enabling OF_PLATDATA.
> > >> > >>>>>
> > >> > >>>>> So since serial_rockchip.c already uses OF_PLATDATA and is based on
> > >> > >>>>> ns16550 that my socfpga-gen5 platform is using: what do I have to do
> > >> > >>>>> besides enabling OF_PLATDATA to get this working?
> > >> > >>>>>
> > >> > >>>>> I just seems like uclass_first_device does not find any UCLASS_SERIAL
> > >> > >>>>> deivce when OF_PLATDATA is enabled.
> > >> > >>>>
> > >> > >>>> There is the of-plat.txt README.
> > >> > >>>
> > >> > >>> Yes, I should have mentioned I already read that and still had those
> > >> > >>> questions. Kconfig help says README.platdata though. We probably should
> > >> > >>> update that link.
> > >> > >>>
> > >> > >>>> Basically the dtoc tool creates U_BOOT_DEVICE() declarations and links
> > >> > >>>> them with SPL. These should show up in your image and therefore be
> > >> > >>>> bound. You can call dm_dump_all() in SPL to see what what devices are
> > >> > >>>> bound. I presume you are calling spl_init()?
> > >> > >>>>
> > >> > >>>> You can look at what dtoc produces. The example serial driver for
> > >> > >>>> Rockchip is serial_rockchip.c
> > >> > >>>
> > >> > >>> I saw that as an example (because I also have an ns16550 compatible on
> > >> > >>> my board) but couldn't figure out why it is not bound. By debugging
> > >> > >>> 'dm_scan_platdata', 'lists_bind_drivers' and 'device_bind_by_name', by
> > >> > >>> now I know the driver names don't match. That is something I did not get
> > >> > >>> just by reading of-plat.txt. I'll work on a patch to clarify that document.
> > >> > >>
> > >> > >> Yes I'd really appreciate some patches here. It is hard to know what
> > >> > >> people won't understand and this feature could really do with a more
> > >> > >> details docs or a walk-through.
> > >> > >>
> > >> > >>>
> > >> > >>> Right now, serial works. I had to add a new platform specific driver
> > >> > >>> just like serial_rockchip though. For DTS, we can pass multiple
> > >> > >>> 'compatible' strings, but for platdata, we have to create multiple
> > >> > >>> drivers. That's a bit strange when porting boards...
> > >> > >>
> > >> > >> Yes it is. I'm not sure how to solve that though. Probably dtoc can be
> > >> > >> made smarter. Ideally you only need one device of each uclass in SPL.
> > >> > >
> > >> > > Would it work to use the unchanged 'compatible' string for the '.name'
> > >> > > of U_BOOT_DEVICE generated by dtoc? Then the binding of such drivers
> > >> > > could change from comparing names to comparing to compatibles. That
> > >> > > would make it more DTS-like.
> > >> > >
> > >> > > Then, I think we could need some kind of fallback code for properties
> > >> > > that are optional in the DTS. Maybe we can create defines for each dtd
> > >> > > struct so that drivers can test the existence of dtd sturct fields using
> > >> > > #ifdef. [Given the special usage, I guess it's OK to assume that theses
> > >> > > structs are only used once per DTS so that we don't have to worry about
> > >> > > how to solve this for multiple occurrences with different optional
> > >> > > parameters?]
> > >> > >
> > >> > > Oh, and then I think dtb_platdata.py should create the dtd instances as
> > >> > > const. I'll prepare a patch for that.
> > >> > >
> > >> > >>
> > >> > >>>
> > >> > >>>>
> > >> > >>>>>
> > >> > >>>>> (And when answering this, keep in mind I need to get MMC and QSPI
> > >> > >>>>> drivers working with OF_PLATDATA - I already fixed compiler errors in
> > >> > >>>>> those, nothing more.)
> > >> > >>>>
> > >> > >>>> Yes MMC should be OK, but QSPI might be blazing a bit of a trail.
> > >> >
> > >> > Hmm, QSPI works as well when hacking the things that the driver wants to
> > >> > parse from subnode properties. However, I haven't found a way to access
> > >> > the platform data of the spi-flash from the driver.
> > >> >
> > >> > Maybe we need to somehow make subnodes available in the dt-platdata
> > >> > structs to make that work?
> > >>
> > >> There is support for phandles but not for parent relationships. I
> > >> suppose it would not be impossible to add that in dtoc with a 'parent'
> > >> pointer.
> > >
> > >
> > > SPI flash actually needs it the other way round. At least the cadence qspi driver I'm using checks for a subnode that describes the flash chip.
> > >
> > > I'll see if I can add that to dtoc.
> >
> > By now I have SPI successfully running with platdata by adding child
> > arrays to the platdata struct via dtoc.
> >
> > However, probing the flash chip is not found in 'spi_get_bus_and_cs'
> > and so the transfer falls back to 100 kHz, which is of course bad.
> > That code expects a udevice child under the spi udevice. Looks like
> > that needs more changes than just in dtoc?
> >
> > Did you have SPI running with platdata on any board, yet?
>
> No. The implementation does not deal well with parent/child
> relationships, as with buses, and in every case we need to make
> changes.

I had done those changes to dtoc, but as Marek seems so opposed to
getting this integrated for socfpga, I don't know if I'll continue down that
road...

> That said, spi_get_bus_and_cs() is only used if you don't have the SPI
> device in the DT.

Hmm, I thought the way that spl_spi.c uses the spi flash framework
would result in spi_get_bus_and_cs() being used. I'll need to check
that again.

Regards,
Simon