From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Glass Date: Thu, 10 Jan 2019 05:56:45 -0700 Subject: [U-Boot] SPL Platdata howto? In-Reply-To: References: <5143162a-d59d-f58e-3a34-c75b2003b55a@gmail.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Simon, On Fri, 4 Jan 2019 at 00:15, Simon Goldschmidt wrote: > > On Fri, Dec 21, 2018 at 10:20 PM Simon Goldschmidt > wrote: > > > > > > > > Am Fr., 21. Dez. 2018, 22:16 hat Simon Glass geschrieben: > >> > >> Hi Simon, > >> > >> On Thu, 20 Dec 2018 at 14:32, Simon Goldschmidt > >> 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 > >> > >> wrote: > >> > >>> > >> > >>> Am 20.12.2018 um 15:49 schrieb Simon Glass: > >> > >>>> Hi Simon, > >> > >>>> > >> > >>>> On Wed, 19 Dec 2018 at 14:06, Simon Goldschmidt > >> > >>>> 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. > > By now I have SPI successfully running with platdata by adding child > arrays to the platdata struct via dtoc. > > However, probing the flash chip is not found in 'spi_get_bus_and_cs' > and so the transfer falls back to 100 kHz, which is of course bad. > That code expects a udevice child under the spi udevice. Looks like > that needs more changes than just in dtoc? > > Did you have SPI running with platdata on any board, yet? No. The implementation does not deal well with parent/child relationships, as with buses, and in every case we need to make changes. That said, spi_get_bus_and_cs() is only used if you don't have the SPI device in the DT. Regards, Simon