Am Fr., 21. Dez. 2018, 22:16 hat Simon Glass <s...@chromium.org> geschrieben:
> Hi Simon, > > On Thu, 20 Dec 2018 at 14:32, Simon Goldschmidt > <simon.k.r.goldschm...@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.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. > > > > 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 mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
