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