[U-Boot] SPL Platdata howto?

[Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>]

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