| Message ID | 20170302190435.23212-13-fcooper@ti.com |
|---|---|
| State | Changes Requested |
| Delegated to: | Tom Rini |
| Headers | show |
On Thu, Mar 02, 2017 at 01:04:16PM -0600, Franklin S Cooper Jr wrote: > Runtime U-boot dtb selection is generally a two step process. First step > is to simply use an initial generic dtb. The second step is to select > the dtb and perhaps execute additional code ones U-boot knows what board > it is running on. Embedded_dtb_select handles the second step by allowing > board specific code to run and perform what ever necessary configuration > that is needed. So I'm not 100% sure on how to proceed here exactly. We have a few things to consider. First, I bet the generic dtb is good enough for loading up and booting to Linux (and loading/passing a different, complete and board specific DTB). Second, we have the (reasonable) set of patches and discussion to make the DTB that we use available easily so that it could be passed on to Linux (or EFI apps or whatever). So, this is probably the right thing to do in the long run, but is also another data point in the "but we need to think and talk about if some platforms really shouldn't be shipping their full FT on the HW somewhere". > > Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com> [snip] > +config DTB_RESELECT > + bool "Support swapping dtbs at a later point in boot" > + depends on FIT_EMBED > + default n This is the default, you can drop it.
On Thu, 9 Mar 2017 08:08:20 -0500 Tom Rini <trini@konsulko.com> wrote: > On Thu, Mar 02, 2017 at 01:04:16PM -0600, Franklin S Cooper Jr wrote: > > > Runtime U-boot dtb selection is generally a two step process. First > > step is to simply use an initial generic dtb. The second step is to > > select the dtb and perhaps execute additional code ones U-boot > > knows what board it is running on. Embedded_dtb_select handles the > > second step by allowing board specific code to run and perform what > > ever necessary configuration that is needed. > > So I'm not 100% sure on how to proceed here exactly. We have a few > things to consider. First, I bet the generic dtb is good enough for > loading up and booting to Linux (and loading/passing a different, > complete and board specific DTB). Second, we have the (reasonable) > set of patches and discussion to make the DTB that we use available > easily so that it could be passed on to Linux (or EFI apps or > whatever). So, this is probably the right thing to do in the long > run, but is also another data point in the "but we need to think and > talk about if some platforms really shouldn't be shipping their full > FT on the HW somewhere". It might also happen that somebody would like to have one "blessed" u-boot binary stored in one place and then only change u-boot DTB stored on another memory region (like eMMC, NOR). The above also seems like a valid use case, especially when one wants to support device for a long time (many DTBs) and avoid uncontrolled grown of final u-boot.img binary size (as this is now the case for TI). > > > > > Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com> > [snip] > > +config DTB_RESELECT > > + bool "Support swapping dtbs at a later point in boot" > > + depends on FIT_EMBED > > + default n > > This is the default, you can drop it. > Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
On Thu, Mar 09, 2017 at 09:12:56PM +0100, Lukasz Majewski wrote: > On Thu, 9 Mar 2017 08:08:20 -0500 > Tom Rini <trini@konsulko.com> wrote: > > > On Thu, Mar 02, 2017 at 01:04:16PM -0600, Franklin S Cooper Jr wrote: > > > > > Runtime U-boot dtb selection is generally a two step process. First > > > step is to simply use an initial generic dtb. The second step is to > > > select the dtb and perhaps execute additional code ones U-boot > > > knows what board it is running on. Embedded_dtb_select handles the > > > second step by allowing board specific code to run and perform what > > > ever necessary configuration that is needed. > > > > So I'm not 100% sure on how to proceed here exactly. We have a few > > things to consider. First, I bet the generic dtb is good enough for > > loading up and booting to Linux (and loading/passing a different, > > complete and board specific DTB). Second, we have the (reasonable) > > set of patches and discussion to make the DTB that we use available > > easily so that it could be passed on to Linux (or EFI apps or > > whatever). So, this is probably the right thing to do in the long > > run, but is also another data point in the "but we need to think and > > talk about if some platforms really shouldn't be shipping their full > > FT on the HW somewhere". > > It might also happen that somebody would like to have one "blessed" > u-boot binary stored in one place and then only change u-boot DTB stored > on another memory region (like eMMC, NOR). > > The above also seems like a valid use case, especially when one wants to > support device for a long time (many DTBs) and avoid uncontrolled grown > of final u-boot.img binary size (as this is now the case for TI). I'd rather stress that the problem is that when we want to support N boards and we do that by including N device tree blobs, the size is going to grow with each board. What's not happening yet is the DTB is being stored in the device and accessed that way. I'd really like to see some boards moving in that direction. And it seems like perhaps you're working on some that could? Thanks!
On 03/10/2017 09:42 AM, Tom Rini wrote: > On Thu, Mar 09, 2017 at 09:12:56PM +0100, Lukasz Majewski wrote: >> On Thu, 9 Mar 2017 08:08:20 -0500 >> Tom Rini <trini@konsulko.com> wrote: >> >>> On Thu, Mar 02, 2017 at 01:04:16PM -0600, Franklin S Cooper Jr wrote: >>> >>>> Runtime U-boot dtb selection is generally a two step process. First >>>> step is to simply use an initial generic dtb. The second step is to >>>> select the dtb and perhaps execute additional code ones U-boot >>>> knows what board it is running on. Embedded_dtb_select handles the >>>> second step by allowing board specific code to run and perform what >>>> ever necessary configuration that is needed. >>> >>> So I'm not 100% sure on how to proceed here exactly. We have a few >>> things to consider. First, I bet the generic dtb is good enough for >>> loading up and booting to Linux (and loading/passing a different, >>> complete and board specific DTB). Second, we have the (reasonable) >>> set of patches and discussion to make the DTB that we use available >>> easily so that it could be passed on to Linux (or EFI apps or >>> whatever). So, this is probably the right thing to do in the long >>> run, but is also another data point in the "but we need to think and >>> talk about if some platforms really shouldn't be shipping their full >>> FT on the HW somewhere". >> >> It might also happen that somebody would like to have one "blessed" >> u-boot binary stored in one place and then only change u-boot DTB stored >> on another memory region (like eMMC, NOR). >> >> The above also seems like a valid use case, especially when one wants to >> support device for a long time (many DTBs) and avoid uncontrolled grown >> of final u-boot.img binary size (as this is now the case for TI). > > I'd rather stress that the problem is that when we want to support N > boards and we do that by including N device tree blobs, the size is > going to grow with each board. What's not happening yet is the DTB is > being stored in the device and accessed that way. I'd really like to > see some boards moving in that direction. And it seems like perhaps > you're working on some that could? Thanks! The problem I see is storing dtbs that U-boot needs as part of booting at a different location requires alot of guarantees across all the evms being supported by the single image. If for NAND boot one board stores U-boot's dtb blobs in one partition vs another then things fall apart. The larger this minimal dtb is the harder it is to guarantee that it will be valid in the future when/if new boards are introduced or reved. The benefit of having a dtb bundled in the U-boot image is that no matter the boot mode or board differences as long as something loads U-boot it can then select the proper dtb to use from memory. I think I remember Andrew also saying how having U-boot's dtbs built in will make things easier in the HS world. Now the method that U-boot is loaded and where U-boot is stored will need to deal with U-boots larger size. But I think its rather enviable since atleast for TI evms we kept space allowance for U-boot in NOR and NAND rather small for no real reason. In general if someone adds support and makes use of using a minimal U-boot dtb and loading the "correct" one from some other location I wouldn't have an issue with that. But atleast to me I don't think that is the direction for TI evms. >
diff --git a/common/Kconfig b/common/Kconfig index 11495f3..bf4e94b 100644 --- a/common/Kconfig +++ b/common/Kconfig @@ -352,6 +352,16 @@ config SYS_STDIO_DEREGISTER endmenu +config DTB_RESELECT + bool "Support swapping dtbs at a later point in boot" + depends on FIT_EMBED + default n + help + It is possible during initial boot you may need to use a generic + dtb until you can fully determine the board your running on. This + config allows boards to implement a function at a later point + during boot to switch to the "correct" dtb. + config FIT_EMBED bool "Support a FIT image embedded in the U-boot image" default n diff --git a/common/board_f.c b/common/board_f.c index ae6cd85..2e69b3a 100644 --- a/common/board_f.c +++ b/common/board_f.c @@ -920,6 +920,9 @@ static const init_fnc_t init_sequence_f[] = { #if defined(CONFIG_DISPLAY_CPUINFO) print_cpuinfo, /* display cpu info (and speed) */ #endif +#if defined(CONFIG_DTB_RESELECT) + embedded_dtb_select, +#endif #if defined(CONFIG_DISPLAY_BOARDINFO) show_board_info, #endif diff --git a/include/common.h b/include/common.h index fbbc2cb..7bc85d8 100644 --- a/include/common.h +++ b/include/common.h @@ -451,6 +451,10 @@ void pci_init_board(void); #endif #endif +#if defined(CONFIG_DTB_RESELECT) +int embedded_dtb_select(void); +#endif + int misc_init_f (void); int misc_init_r (void);
Runtime U-boot dtb selection is generally a two step process. First step is to simply use an initial generic dtb. The second step is to select the dtb and perhaps execute additional code ones U-boot knows what board it is running on. Embedded_dtb_select handles the second step by allowing board specific code to run and perform what ever necessary configuration that is needed. Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com> --- common/Kconfig | 10 ++++++++++ common/board_f.c | 3 +++ include/common.h | 4 ++++ 3 files changed, 17 insertions(+)