On Thu, Nov 22, 2018 at 03:44:28PM +0100, Simon Goldschmidt wrote:
Am Do., 22. Nov. 2018, 14:44 hat Tom Rini trini@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 <
sjg@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.