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.goldschm...@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.goldschm...@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 mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
