On Thu, Nov 22, 2018 at 9:50 PM Simon Glass <s...@chromium.org> wrote: > > Hi, > > On Thu, 22 Nov 2018 at 10:02, Tom Rini <tr...@konsulko.com> wrote: > > > > On Thu, Nov 22, 2018 at 03:44:28PM +0100, Simon Goldschmidt wrote: > > > Am Do., 22. Nov. 2018, 14:44 hat Tom Rini <tr...@konsulko.com> > > > geschrieben: > > > > > > > On Thu, Nov 22, 2018 at 02:24:49PM +0100, Marek Vasut wrote: > > > > > On 11/22/2018 01:52 PM, Tom Rini wrote: > > > > > > On Thu, Nov 22, 2018 at 10:25:14AM +0100, Christian Gmeiner wrote: > > > > > > > > > > > >> Am Mo., 19. Nov. 2018 um 16:56 Uhr schrieb Simon Glass < > > > > s...@chromium.org>: > > > > > >>> > > > > > >>> This board has not been converted to CONFIG_DM_BLK by the > > > > > >>> deadline. > > > > > >>> Remove it. > > > > > >>> > > > > > >> > > > > > >> As the board is still mainted I will NAK it for the moment. Are > > > > > >> there > > > > > >> any hints want needs to be done > > > > > >> to port thie board over to new DM stuff? > > > > > > > > > > > > Yes, as a start you need to switch over to using CONFIG_OF_CONTROL > > > > > > and > > > > > > selecting/providing a dtb file. I see ot1200 is using DWC_AHSATA > > > > > > which > > > > > > needs more work, but this is the board-level work that needs doing. > > > > > > > > > > Wasn't there a possibility to use platform data in board file instead > > > > > of > > > > > DT ? Or is DT mandatory now , including the libfdt overhead ? > > > > > > > > In short, DT for U-Boot and platform data for SPL is what's recommended, > > > > yes. > > > > > > > > > > This is a little confusing for me. Socfpga gen5 SPL doesn't do that. And > > > it > > > seems a little strange or outdated overall. > > > > > > Would there be some kind of reference architecture or mach to look at > > > what's the suggested/up-to-date way to implement SPL? Also regarding code > > > flow? > > > > So, SPL is where things get, ahem, fuzzy. While I don't want to > > encourage boundless growth in U-Boot proper, we aren't exactly size > > constrained (but rather, functional/logical constrained). But in SPL, > > yes, we have many platforms with 32/64/128 kilobyte hard limits (and > > some smaller) and we can't always shove in a "TPL" before SPL either. > > So in SPL we do make use of platform data instead. While not the > > smallest size constraint, am335x_hs_evm is a reasonable thing to look at > > in this case. > > Also 'rock' uses CONFIG_OF_PLATDATA which provides a halfway house - > still uses DT, but it gets converted into C structs so saves code > space. > > firefly-rk3288 is a pretty good DM/DT example, including SPL.
I've currently got an issue on socfpga gen5 that could be solved best by enabling CONFIG_OF_EMBED (mixing const and non-const sections is a problem for CRC calculation). However, it could probably also solve by using platform data (but that doesn't work out of the box, yet). The problem with CONFIG_OF_EMBED is that I think it's OK to enable this for SPL but I don't like enabling it for U-Boot, so: Would it make sense to duplicate the whole "Provider of DTB for OF control" choice so that it can be OF_EMBED for SPL but different for U-Boot? Or does it make more sense to convert socfpga gen5 to use OF_PLATDATA? Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
