Re: [U-Boot] [linux-sunxi] Re: [RFC PATCH 08/11] sunxi: SPL: add FIT config selector for Pine64 boards
2017年1月24日 01:29于 Maxime Ripard maxime.ripard@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@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@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
On Tue, Jan 24, 2017 at 02:30:24PM +0800, Icenowy Zheng wrote:
2017年1月24日 01:29于 Maxime Ripard maxime.ripard@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@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?
Well this is precisely to be able to do that. If you have another serie of boards with one flavour having 512MB and the other one having more, you would have fallen in that case, while it might not be the DT to pick.
The option prevents you to fall into that hole.
Maxime
participants (2)
-
Icenowy Zheng -
Maxime Ripard