[U-Boot] [linux-sunxi] Re: [RFC PATCH 08/11] sunxi: SPL: add FIT config selector for Pine64 boards

[Icenowy Zheng]

2017年1月24日 01:29于 Maxime Ripard <maxime.ripard at free-electrons.com>写道：
>
> On Sat, Jan 21, 2017 at 03:15:27PM +0000, André Przywara wrote: 
> > >>> On Fri, Jan 20, 2017 at 01:53:28AM +0000, Andre Przywara wrote:  
> > >>>> For a board or platform to support FIT loading in the SPL, it has to 
> > >>>> provide a board_fit_config_name_match() routine, which helps to select 
> > >>>> one of possibly multiple DTBs contained in a FIT image. 
> > >>>> Provide a simple function to cover the two different Pine64 models, 
> > >>>> which can be easily told apart by looking at the amount of installed 
> > >>>> RAM. 
> > >>>> 
> > >>>> Signed-off-by: Andre Przywara <andre.przywara at arm.com> 
> > >>>> --- 
> > >>>>  board/sunxi/board.c | 13 +++++++++++++ 
> > >>>>  1 file changed, 13 insertions(+) 
> > >>>> 
> > >>>> diff --git a/board/sunxi/board.c b/board/sunxi/board.c 
> > >>>> index 5365638..bbbb826 100644 
> > >>>> --- a/board/sunxi/board.c 
> > >>>> +++ b/board/sunxi/board.c 
> > >>>> @@ -726,3 +726,16 @@ int ft_board_setup(void *blob, bd_t *bd) 
> > >>>>  #endif 
> > >>>>  return 0; 
> > >>>>  } 
> > >>>> + 
> > >>>> +#ifdef CONFIG_SPL_LOAD_FIT 
> > >>>> +int board_fit_config_name_match(const char *name) 
> > >>>> +{ 
> > >>>> +#ifdef CONFIG_MACH_SUN50I 
> > >>>> + if ((gd->ram_size > 512 * 1024 * 1024)) 
> > >>>> + return !strcmp(name, "sun50i-a64-pine64-plus"); 
> > >>>> + else 
> > >>>> + return !strcmp(name, "sun50i-a64-pine64"); 
> > >>>> +#endif 
> > >>>> + return -1; 
> > >>>> +}  
> > >>> 
> > >>> That looks fishy. It means that any A64 board with CONFIG_SPL_LOAD_FIT 
> > >>> enabled will be considered a pine64 board?  
> > >> 
> > >> Yes, at least for now, because that's the only A64 board we officially 
> > >> support so far. 
> > >> And yes again, it is fishy. It is more a demo or a placeholder for now, 
> > >> because you _need_ an implementation of board_fit_config_name_match() 
> > >> once you enable CONFIG_SPL_LOAD_FIT. 
> > >> 
> > >> One solution would be to have only one DTB supported per build, so 
> > >> board_fit_config_name_match() always returns 0. 
> > >> 
> > >> Another (better) solution would be to store the board name in the SPL 
> > >> header, which could be done later when flashing the image. Then this 
> > >> function would just return strcmp(name, spl_header_name) or 0 if no name 
> > >> is found for whatever reason. 
> > > 
> > > Yes, this is a good solution in the case if we have some non-removable 
> > > storage on the board (SPI NOR flash, NAND, EEPROM or something else). 
> > > We can discuss it separately. 
> > 
> > I totally agree. I rebased your patch to latest mainline already and 
> > will send out something later. 
> > 
> > > But the current generation of Pine64 boards don't have any 
> > > non-removable storage yet. My understanding is that you tried to 
> > > provide the DTB selection, which is based on circumstantial evidences, 
> > > such as the RAM size. IMHO this is also a valid selection method, 
> > > because it can reduce the number of required OS image variants. 
> > 
> > Yes, the point is that for U-Boot's purposes the only difference between 
> > the Pine64 and Pine64+ (apart from DRAM size, which is autodetected) is 
> > using MII vs. RGMII for the Ethernet PHY. The sun8i_emac driver gets 
> > this information from the DT only, so there is no point at all for 
> > different defconfigs. And the DRAM size is a safe indicator for that 
> > difference, at least if we confine our view to Pine64 boards. 
> > 
> > Now how other boards fit in here is a separate discussion IMO, so let's 
> > solve one problem after the other. 
> > I just thought that we could use: 
> > 
> > #ifdef CONFIG_SPL_LOAD_FIT 
> > int board_fit_config_name_match(const char *name) 
> > { 
> > return strcmp(name, CONFIG_DEFAULT_DEVICE_TREE); 
> > } 
> > #endif 
>
> I guess an easy way around this would be to add a Kconfig option for 
> the pine64, like I tried to do for the CHIP (but never ended up 
> merging). That way, at least we won't impact the other board, and we 
> can have that default. 

For every alike, SPL-compatible, easily-detectable board groups?

>
> Maxime 
>
> -- 
> Maxime Ripard, Free Electrons 
> Embedded Linux and Kernel engineering 
> http://free-electrons.com 
>
> -- 
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group. 
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com. 
> For more options, visit https://groups.google.com/d/optout.