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