* [U-Boot] SPL Platdata howto? @ 2018-12-19 21:06 Simon Goldschmidt 2018-12-20 14:49 ` Simon Glass 0 siblings, 1 reply; 11+ messages in thread From: Simon Goldschmidt @ 2018-12-19 21:06 UTC (permalink / raw) To: u-boot 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. (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.) Thanks, Simon ^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] SPL Platdata howto? 2018-12-19 21:06 [U-Boot] SPL Platdata howto? Simon Goldschmidt @ 2018-12-20 14:49 ` Simon Glass 2018-12-20 15:03 ` Simon Goldschmidt 0 siblings, 1 reply; 11+ messages in thread From: Simon Glass @ 2018-12-20 14:49 UTC (permalink / raw) To: u-boot 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. 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 > > (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. Regards, Simon ^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] SPL Platdata howto? 2018-12-20 14:49 ` Simon Glass @ 2018-12-20 15:03 ` Simon Goldschmidt 2018-12-20 17:37 ` Simon Glass 0 siblings, 1 reply; 11+ messages in thread From: Simon Goldschmidt @ 2018-12-20 15:03 UTC (permalink / raw) To: u-boot 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. 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... > >> >> (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 ;-) Thanks for your hints! Regards, Simon ^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] SPL Platdata howto? 2018-12-20 15:03 ` Simon Goldschmidt @ 2018-12-20 17:37 ` Simon Glass 2018-12-20 20:53 ` Simon Goldschmidt 0 siblings, 1 reply; 11+ messages in thread From: Simon Glass @ 2018-12-20 17:37 UTC (permalink / raw) To: u-boot 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. > > > > >> > >> (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 ;-) > > Thanks for your hints! You're welcome, happy hunting. Regards, Simon ^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] SPL Platdata howto? 2018-12-20 17:37 ` Simon Glass @ 2018-12-20 20:53 ` Simon Goldschmidt 2018-12-20 21:32 ` Simon Goldschmidt 0 siblings, 1 reply; 11+ messages in thread From: Simon Goldschmidt @ 2018-12-20 20:53 UTC (permalink / raw) To: u-boot 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. >> >> 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 > ^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] SPL Platdata howto? 2018-12-20 20:53 ` Simon Goldschmidt @ 2018-12-20 21:32 ` Simon Goldschmidt 2018-12-21 21:16 ` Simon Glass 0 siblings, 1 reply; 11+ messages in thread From: Simon Goldschmidt @ 2018-12-20 21:32 UTC (permalink / raw) To: u-boot 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? 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 >> > ^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] SPL Platdata howto? 2018-12-20 21:32 ` Simon Goldschmidt @ 2018-12-21 21:16 ` Simon Glass 2018-12-21 21:20 ` Simon Goldschmidt 0 siblings, 1 reply; 11+ messages in thread From: Simon Glass @ 2018-12-21 21:16 UTC (permalink / raw) To: u-boot 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. 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 > >> > > > ^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] SPL Platdata howto? 2018-12-21 21:16 ` Simon Glass @ 2018-12-21 21:20 ` Simon Goldschmidt 2019-01-04 7:15 ` Simon Goldschmidt 0 siblings, 1 reply; 11+ messages in thread From: Simon Goldschmidt @ 2018-12-21 21:20 UTC (permalink / raw) To: u-boot 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 > > >> > > > > > > ^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] SPL Platdata howto? 2018-12-21 21:20 ` Simon Goldschmidt @ 2019-01-04 7:15 ` Simon Goldschmidt 2019-01-10 12:56 ` Simon Glass 0 siblings, 1 reply; 11+ messages in thread From: Simon Goldschmidt @ 2019-01-04 7:15 UTC (permalink / raw) To: u-boot On Fri, Dec 21, 2018 at 10:20 PM Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com> wrote: > > > > 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. 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? Regards, Simon ^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] SPL Platdata howto? 2019-01-04 7:15 ` Simon Goldschmidt @ 2019-01-10 12:56 ` Simon Glass 2019-01-11 7:37 ` Simon Goldschmidt 0 siblings, 1 reply; 11+ messages in thread From: Simon Glass @ 2019-01-10 12:56 UTC (permalink / raw) To: u-boot Hi Simon, On Fri, 4 Jan 2019 at 00:15, Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com> wrote: > > On Fri, Dec 21, 2018 at 10:20 PM Simon Goldschmidt > <simon.k.r.goldschmidt@gmail.com> wrote: > > > > > > > > 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. > > 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] SPL Platdata howto? 2019-01-10 12:56 ` Simon Glass @ 2019-01-11 7:37 ` Simon Goldschmidt 0 siblings, 0 replies; 11+ messages in thread From: Simon Goldschmidt @ 2019-01-11 7:37 UTC (permalink / raw) To: u-boot On Thu, Jan 10, 2019 at 1:57 PM Simon Glass <sjg@chromium.org> wrote: > > Hi Simon, > > On Fri, 4 Jan 2019 at 00:15, Simon Goldschmidt > <simon.k.r.goldschmidt@gmail.com> wrote: > > > > On Fri, Dec 21, 2018 at 10:20 PM Simon Goldschmidt > > <simon.k.r.goldschmidt@gmail.com> wrote: > > > > > > > > > > > > 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. > > > > 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. I had done those changes to dtoc, but as Marek seems so opposed to getting this integrated for socfpga, I don't know if I'll continue down that road... > That said, spi_get_bus_and_cs() is only used if you don't have the SPI > device in the DT. Hmm, I thought the way that spl_spi.c uses the spi flash framework would result in spi_get_bus_and_cs() being used. I'll need to check that again. Regards, Simon ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2019-01-11 7:37 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-12-19 21:06 [U-Boot] SPL Platdata howto? Simon Goldschmidt 2018-12-20 14:49 ` Simon Glass 2018-12-20 15:03 ` Simon Goldschmidt 2018-12-20 17:37 ` Simon Glass 2018-12-20 20:53 ` Simon Goldschmidt 2018-12-20 21:32 ` Simon Goldschmidt 2018-12-21 21:16 ` Simon Glass 2018-12-21 21:20 ` Simon Goldschmidt 2019-01-04 7:15 ` Simon Goldschmidt 2019-01-10 12:56 ` Simon Glass 2019-01-11 7:37 ` Simon Goldschmidt
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.