| Message ID | 20191221075440.6944-3-jagan@amarulasolutions.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | rk3399: SPI boot support (fixes, updates) | expand |
On 2019/12/21 下午3:54, Jagan Teki wrote: > Add distro boot command support for SPI flash. > > This distro boot will read the boot script at specific > location at the flash and start sourcing the same. > > The common macro like BOOTENV_SHARED_FLASH would help > to extend the support for nand flash in future. > > Cc: Tom Rini <trini@konsulko.com> > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> Thanks, - Kever > --- > include/config_distro_bootcmd.h | 35 +++++++++++++++++++++++++++++++++ > 1 file changed, 35 insertions(+) > > diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h > index fc0935fa21..d68b79e290 100644 > --- a/include/config_distro_bootcmd.h > +++ b/include/config_distro_bootcmd.h > @@ -43,6 +43,22 @@ > #define BOOTENV_DEV_NAME_BLKDEV(devtypeu, devtypel, instance) \ > #devtypel #instance " " > > +#define BOOTENV_SHARED_SF_BODY(devtypel) \ > + "if " #devtypel " probe ${devnum}; then " \ > + "devtype=" #devtypel "; " \ > + "run scan_flash_for_scripts; " \ > + "fi\0" > + > +#define BOOTENV_SHARED_FLASH(devtypel) \ > + #devtypel "_boot=" \ > + BOOTENV_SHARED_SF_BODY(devtypel) > + > +#define BOOTENV_DEV_FLASH(devtypeu, devtypel, instance) \ > + BOOTENV_DEV_BLKDEV(devtypeu, devtypel, instance) > + > +#define BOOTENV_DEV_NAME_FLASH(devtypeu, devtypel, instance) \ > + BOOTENV_DEV_NAME_BLKDEV(devtypeu, devtypel, instance) > + > #ifdef CONFIG_SANDBOX > #define BOOTENV_SHARED_HOST BOOTENV_SHARED_BLKDEV(host) > #define BOOTENV_DEV_HOST BOOTENV_DEV_BLKDEV > @@ -398,6 +414,18 @@ > BOOT_TARGET_DEVICES_references_PXE_without_CONFIG_CMD_DHCP_or_PXE > #endif > > +#if defined(CONFIG_CMD_SF) > +#define BOOTENV_SHARED_SF BOOTENV_SHARED_FLASH(sf) > +#define BOOTENV_DEV_SF BOOTENV_DEV_FLASH > +#define BOOTENV_DEV_NAME_SF BOOTENV_DEV_NAME_FLASH > +#else > +#define BOOTENV_SHARED_SF > +#define BOOTENV_DEV_SF \ > + BOOT_TARGET_DEVICES_references_SF_without_CONFIG_CMD_SF > +#define BOOTENV_DEV_NAME_SF \ > + BOOT_TARGET_DEVICES_references_SF_without_CONFIG_CMD_SF > +#endif > + > #define BOOTENV_DEV_NAME(devtypeu, devtypel, instance) \ > BOOTENV_DEV_NAME_##devtypeu(devtypeu, devtypel, instance) > #define BOOTENV_BOOT_TARGETS \ > @@ -412,6 +440,7 @@ > BOOTENV_SHARED_USB \ > BOOTENV_SHARED_SATA \ > BOOTENV_SHARED_SCSI \ > + BOOTENV_SHARED_SF \ > BOOTENV_SHARED_NVME \ > BOOTENV_SHARED_IDE \ > BOOTENV_SHARED_UBIFS \ > @@ -436,6 +465,12 @@ > "echo SCRIPT FAILED: continuing...; " \ > "fi\0" \ > \ > + "scan_flash_for_scripts=" \ > + "${devtype} read ${scriptaddr} " \ > + "${script_offset_f} ${script_size_f}; " \ > + "source ${scriptaddr}; " \ > + "echo SCRIPT FAILED: continuing...\0" \ > + \ > "boot_a_script=" \ > "load ${devtype} ${devnum}:${distro_bootpart} " \ > "${scriptaddr} ${prefix}${script}; " \
+A few people that may have insight to my question On Sat, Dec 21, 2019 at 01:24:31PM +0530, Jagan Teki wrote: > Add distro boot command support for SPI flash. > > This distro boot will read the boot script at specific > location at the flash and start sourcing the same. > > The common macro like BOOTENV_SHARED_FLASH would help > to extend the support for nand flash in future. > > Cc: Tom Rini <trini@konsulko.com> > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> What distro is this for? My concern here is that hundreds of boards (literally) grow by a few hundred bytes to add in this bit of additional default logic. That's not a big problem if distributions are now going to be using SPI flash as where they're programming in their bootscript. But, who is doing that? Thanks!
On 20.01.20 18:22, Tom Rini wrote: > +A few people that may have insight to my question > > On Sat, Dec 21, 2019 at 01:24:31PM +0530, Jagan Teki wrote: > >> Add distro boot command support for SPI flash. >> >> This distro boot will read the boot script at specific >> location at the flash and start sourcing the same. >> >> The common macro like BOOTENV_SHARED_FLASH would help >> to extend the support for nand flash in future. >> >> Cc: Tom Rini <trini@konsulko.com> >> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> > What distro is this for? My concern here is that hundreds of boards > (literally) grow by a few hundred bytes to add in this bit of additional > default logic. That's not a big problem if distributions are now going > to be using SPI flash as where they're programming in their bootscript. > But, who is doing that? Thanks! I am not aware of any "distro" that puts a U-Boot script at offset 0 of the SPI Flash. Traditionally, SPI Flash boot setups were always very hand crafted - exactly the opposite of what distro boot is for. That said, I think supporting SPI Flash boot for rk3399 is great! Albeit I would personally only store U-Boot and the environment on SPI, not the target OS. Jagan, is putting a U-Boot script on the SPI Flash something you thought of or something that the rk3399 reference board already does? If it's the latter, maybe you could add it as a board custom boot function? Alex
On Mon, Jan 20, 2020 at 11:10 PM Alexander Graf <agraf@csgraf.de> wrote: > > > On 20.01.20 18:22, Tom Rini wrote: > > +A few people that may have insight to my question > > > > On Sat, Dec 21, 2019 at 01:24:31PM +0530, Jagan Teki wrote: > > > >> Add distro boot command support for SPI flash. > >> > >> This distro boot will read the boot script at specific > >> location at the flash and start sourcing the same. > >> > >> The common macro like BOOTENV_SHARED_FLASH would help > >> to extend the support for nand flash in future. > >> > >> Cc: Tom Rini <trini@konsulko.com> > >> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> > > What distro is this for? My concern here is that hundreds of boards > > (literally) grow by a few hundred bytes to add in this bit of additional > > default logic. That's not a big problem if distributions are now going > > to be using SPI flash as where they're programming in their bootscript. > > But, who is doing that? Thanks! > > > I am not aware of any "distro" that puts a U-Boot script at offset 0 of > the SPI Flash. > > Traditionally, SPI Flash boot setups were always very hand crafted - > exactly the opposite of what distro boot is for. That said, I think > supporting SPI Flash boot for rk3399 is great! Albeit I would personally > only store U-Boot and the environment on SPI, not the target OS. > > Jagan, is putting a U-Boot script on the SPI Flash something you thought > of or something that the rk3399 reference board already does? If it's > the latter, maybe you could add it as a board custom boot function? Yes it would be later that points to. rk3399 has SPI flash layout and out of which one of offset(script_offset_f=0xffe000 from include/configs/rk3399_common.h) stored the programming script. Jagan.
On Thu, Jan 23, 2020 at 10:25:50PM +0530, Jagan Teki wrote: > On Mon, Jan 20, 2020 at 11:10 PM Alexander Graf <agraf@csgraf.de> wrote: > > > > > > On 20.01.20 18:22, Tom Rini wrote: > > > +A few people that may have insight to my question > > > > > > On Sat, Dec 21, 2019 at 01:24:31PM +0530, Jagan Teki wrote: > > > > > >> Add distro boot command support for SPI flash. > > >> > > >> This distro boot will read the boot script at specific > > >> location at the flash and start sourcing the same. > > >> > > >> The common macro like BOOTENV_SHARED_FLASH would help > > >> to extend the support for nand flash in future. > > >> > > >> Cc: Tom Rini <trini@konsulko.com> > > >> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> > > > What distro is this for? My concern here is that hundreds of boards > > > (literally) grow by a few hundred bytes to add in this bit of additional > > > default logic. That's not a big problem if distributions are now going > > > to be using SPI flash as where they're programming in their bootscript. > > > But, who is doing that? Thanks! > > > > > > I am not aware of any "distro" that puts a U-Boot script at offset 0 of > > the SPI Flash. > > > > Traditionally, SPI Flash boot setups were always very hand crafted - > > exactly the opposite of what distro boot is for. That said, I think > > supporting SPI Flash boot for rk3399 is great! Albeit I would personally > > only store U-Boot and the environment on SPI, not the target OS. > > > > Jagan, is putting a U-Boot script on the SPI Flash something you thought > > of or something that the rk3399 reference board already does? If it's > > the latter, maybe you could add it as a board custom boot function? > > Yes it would be later that points to. rk3399 has SPI flash layout and > out of which one of offset(script_offset_f=0xffe000 from > include/configs/rk3399_common.h) stored the programming script. So I'm not sure why we're adding distro boot support to SPI flash. What is the reference platform storing there exactly? Thanks!
On Thu, Jan 23, 2020 at 10:33 PM Tom Rini <trini@konsulko.com> wrote: > > On Thu, Jan 23, 2020 at 10:25:50PM +0530, Jagan Teki wrote: > > On Mon, Jan 20, 2020 at 11:10 PM Alexander Graf <agraf@csgraf.de> wrote: > > > > > > > > > On 20.01.20 18:22, Tom Rini wrote: > > > > +A few people that may have insight to my question > > > > > > > > On Sat, Dec 21, 2019 at 01:24:31PM +0530, Jagan Teki wrote: > > > > > > > >> Add distro boot command support for SPI flash. > > > >> > > > >> This distro boot will read the boot script at specific > > > >> location at the flash and start sourcing the same. > > > >> > > > >> The common macro like BOOTENV_SHARED_FLASH would help > > > >> to extend the support for nand flash in future. > > > >> > > > >> Cc: Tom Rini <trini@konsulko.com> > > > >> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> > > > > What distro is this for? My concern here is that hundreds of boards > > > > (literally) grow by a few hundred bytes to add in this bit of additional > > > > default logic. That's not a big problem if distributions are now going > > > > to be using SPI flash as where they're programming in their bootscript. > > > > But, who is doing that? Thanks! > > > > > > > > > I am not aware of any "distro" that puts a U-Boot script at offset 0 of > > > the SPI Flash. > > > > > > Traditionally, SPI Flash boot setups were always very hand crafted - > > > exactly the opposite of what distro boot is for. That said, I think > > > supporting SPI Flash boot for rk3399 is great! Albeit I would personally > > > only store U-Boot and the environment on SPI, not the target OS. > > > > > > Jagan, is putting a U-Boot script on the SPI Flash something you thought > > > of or something that the rk3399 reference board already does? If it's > > > the latter, maybe you could add it as a board custom boot function? > > > > Yes it would be later that points to. rk3399 has SPI flash layout and > > out of which one of offset(script_offset_f=0xffe000 from > > include/configs/rk3399_common.h) stored the programming script. > > So I'm not sure why we're adding distro boot support to SPI flash. What > is the reference platform storing there exactly? Thanks! I'm not sure I understand the question? we have rk3399 SBC's that boot from SPI and have feasibility to run distro boot using programming script store in flash offset like boot.scr does for MMC.
On Thu, Jan 23, 2020 at 10:41:15PM +0530, Jagan Teki wrote: > On Thu, Jan 23, 2020 at 10:33 PM Tom Rini <trini@konsulko.com> wrote: > > > > On Thu, Jan 23, 2020 at 10:25:50PM +0530, Jagan Teki wrote: > > > On Mon, Jan 20, 2020 at 11:10 PM Alexander Graf <agraf@csgraf.de> wrote: > > > > > > > > > > > > On 20.01.20 18:22, Tom Rini wrote: > > > > > +A few people that may have insight to my question > > > > > > > > > > On Sat, Dec 21, 2019 at 01:24:31PM +0530, Jagan Teki wrote: > > > > > > > > > >> Add distro boot command support for SPI flash. > > > > >> > > > > >> This distro boot will read the boot script at specific > > > > >> location at the flash and start sourcing the same. > > > > >> > > > > >> The common macro like BOOTENV_SHARED_FLASH would help > > > > >> to extend the support for nand flash in future. > > > > >> > > > > >> Cc: Tom Rini <trini@konsulko.com> > > > > >> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> > > > > > What distro is this for? My concern here is that hundreds of boards > > > > > (literally) grow by a few hundred bytes to add in this bit of additional > > > > > default logic. That's not a big problem if distributions are now going > > > > > to be using SPI flash as where they're programming in their bootscript. > > > > > But, who is doing that? Thanks! > > > > > > > > > > > > I am not aware of any "distro" that puts a U-Boot script at offset 0 of > > > > the SPI Flash. > > > > > > > > Traditionally, SPI Flash boot setups were always very hand crafted - > > > > exactly the opposite of what distro boot is for. That said, I think > > > > supporting SPI Flash boot for rk3399 is great! Albeit I would personally > > > > only store U-Boot and the environment on SPI, not the target OS. > > > > > > > > Jagan, is putting a U-Boot script on the SPI Flash something you thought > > > > of or something that the rk3399 reference board already does? If it's > > > > the latter, maybe you could add it as a board custom boot function? > > > > > > Yes it would be later that points to. rk3399 has SPI flash layout and > > > out of which one of offset(script_offset_f=0xffe000 from > > > include/configs/rk3399_common.h) stored the programming script. > > > > So I'm not sure why we're adding distro boot support to SPI flash. What > > is the reference platform storing there exactly? Thanks! > > I'm not sure I understand the question? we have rk3399 SBC's that boot > from SPI and have feasibility to run distro boot using programming > script store in flash offset like boot.scr does for MMC. OK, and what distro(s) today are doing that? I'm not happy with this patch as it's growing hundreds (literally) of boards in size and I'd like to know what is leveraging this functionality today, or is going to be as soon as it's upstream and widely available. Thanks!
On Thu, Jan 23, 2020 at 10:45 PM Tom Rini <trini@konsulko.com> wrote: > > On Thu, Jan 23, 2020 at 10:41:15PM +0530, Jagan Teki wrote: > > On Thu, Jan 23, 2020 at 10:33 PM Tom Rini <trini@konsulko.com> wrote: > > > > > > On Thu, Jan 23, 2020 at 10:25:50PM +0530, Jagan Teki wrote: > > > > On Mon, Jan 20, 2020 at 11:10 PM Alexander Graf <agraf@csgraf.de> wrote: > > > > > > > > > > > > > > > On 20.01.20 18:22, Tom Rini wrote: > > > > > > +A few people that may have insight to my question > > > > > > > > > > > > On Sat, Dec 21, 2019 at 01:24:31PM +0530, Jagan Teki wrote: > > > > > > > > > > > >> Add distro boot command support for SPI flash. > > > > > >> > > > > > >> This distro boot will read the boot script at specific > > > > > >> location at the flash and start sourcing the same. > > > > > >> > > > > > >> The common macro like BOOTENV_SHARED_FLASH would help > > > > > >> to extend the support for nand flash in future. > > > > > >> > > > > > >> Cc: Tom Rini <trini@konsulko.com> > > > > > >> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> > > > > > > What distro is this for? My concern here is that hundreds of boards > > > > > > (literally) grow by a few hundred bytes to add in this bit of additional > > > > > > default logic. That's not a big problem if distributions are now going > > > > > > to be using SPI flash as where they're programming in their bootscript. > > > > > > But, who is doing that? Thanks! > > > > > > > > > > > > > > > I am not aware of any "distro" that puts a U-Boot script at offset 0 of > > > > > the SPI Flash. > > > > > > > > > > Traditionally, SPI Flash boot setups were always very hand crafted - > > > > > exactly the opposite of what distro boot is for. That said, I think > > > > > supporting SPI Flash boot for rk3399 is great! Albeit I would personally > > > > > only store U-Boot and the environment on SPI, not the target OS. > > > > > > > > > > Jagan, is putting a U-Boot script on the SPI Flash something you thought > > > > > of or something that the rk3399 reference board already does? If it's > > > > > the latter, maybe you could add it as a board custom boot function? > > > > > > > > Yes it would be later that points to. rk3399 has SPI flash layout and > > > > out of which one of offset(script_offset_f=0xffe000 from > > > > include/configs/rk3399_common.h) stored the programming script. > > > > > > So I'm not sure why we're adding distro boot support to SPI flash. What > > > is the reference platform storing there exactly? Thanks! > > > > I'm not sure I understand the question? we have rk3399 SBC's that boot > > from SPI and have feasibility to run distro boot using programming > > script store in flash offset like boot.scr does for MMC. > > OK, and what distro(s) today are doing that? I'm not happy with this > patch as it's growing hundreds (literally) of boards in size and I'd > like to know what is leveraging this functionality today, or is going to > be as soon as it's upstream and widely available. Thanks! Not sure about the possibility more boards using this at this point, but I was initially created custom to rockchip and feel that it would be useful to rest if it's generic. May be will split into rockchip area if it's eating too much footprint. Jagan.
On Thu, Jan 23, 2020 at 10:59:17PM +0530, Jagan Teki wrote: > On Thu, Jan 23, 2020 at 10:45 PM Tom Rini <trini@konsulko.com> wrote: > > > > On Thu, Jan 23, 2020 at 10:41:15PM +0530, Jagan Teki wrote: > > > On Thu, Jan 23, 2020 at 10:33 PM Tom Rini <trini@konsulko.com> wrote: > > > > > > > > On Thu, Jan 23, 2020 at 10:25:50PM +0530, Jagan Teki wrote: > > > > > On Mon, Jan 20, 2020 at 11:10 PM Alexander Graf <agraf@csgraf.de> wrote: > > > > > > > > > > > > > > > > > > On 20.01.20 18:22, Tom Rini wrote: > > > > > > > +A few people that may have insight to my question > > > > > > > > > > > > > > On Sat, Dec 21, 2019 at 01:24:31PM +0530, Jagan Teki wrote: > > > > > > > > > > > > > >> Add distro boot command support for SPI flash. > > > > > > >> > > > > > > >> This distro boot will read the boot script at specific > > > > > > >> location at the flash and start sourcing the same. > > > > > > >> > > > > > > >> The common macro like BOOTENV_SHARED_FLASH would help > > > > > > >> to extend the support for nand flash in future. > > > > > > >> > > > > > > >> Cc: Tom Rini <trini@konsulko.com> > > > > > > >> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> > > > > > > > What distro is this for? My concern here is that hundreds of boards > > > > > > > (literally) grow by a few hundred bytes to add in this bit of additional > > > > > > > default logic. That's not a big problem if distributions are now going > > > > > > > to be using SPI flash as where they're programming in their bootscript. > > > > > > > But, who is doing that? Thanks! > > > > > > > > > > > > > > > > > > I am not aware of any "distro" that puts a U-Boot script at offset 0 of > > > > > > the SPI Flash. > > > > > > > > > > > > Traditionally, SPI Flash boot setups were always very hand crafted - > > > > > > exactly the opposite of what distro boot is for. That said, I think > > > > > > supporting SPI Flash boot for rk3399 is great! Albeit I would personally > > > > > > only store U-Boot and the environment on SPI, not the target OS. > > > > > > > > > > > > Jagan, is putting a U-Boot script on the SPI Flash something you thought > > > > > > of or something that the rk3399 reference board already does? If it's > > > > > > the latter, maybe you could add it as a board custom boot function? > > > > > > > > > > Yes it would be later that points to. rk3399 has SPI flash layout and > > > > > out of which one of offset(script_offset_f=0xffe000 from > > > > > include/configs/rk3399_common.h) stored the programming script. > > > > > > > > So I'm not sure why we're adding distro boot support to SPI flash. What > > > > is the reference platform storing there exactly? Thanks! > > > > > > I'm not sure I understand the question? we have rk3399 SBC's that boot > > > from SPI and have feasibility to run distro boot using programming > > > script store in flash offset like boot.scr does for MMC. > > > > OK, and what distro(s) today are doing that? I'm not happy with this > > patch as it's growing hundreds (literally) of boards in size and I'd > > like to know what is leveraging this functionality today, or is going to > > be as soon as it's upstream and widely available. Thanks! > > Not sure about the possibility more boards using this at this point, > but I was initially created custom to rockchip and feel that it would > be useful to rest if it's generic. May be will split into rockchip > area if it's eating too much footprint. Yes, the "distro boot" functionality refers to what we need to allow boards to easily Just Work with standard off the shelf *nix distributions. Thanks!
diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h index fc0935fa21..d68b79e290 100644 --- a/include/config_distro_bootcmd.h +++ b/include/config_distro_bootcmd.h @@ -43,6 +43,22 @@ #define BOOTENV_DEV_NAME_BLKDEV(devtypeu, devtypel, instance) \ #devtypel #instance " " +#define BOOTENV_SHARED_SF_BODY(devtypel) \ + "if " #devtypel " probe ${devnum}; then " \ + "devtype=" #devtypel "; " \ + "run scan_flash_for_scripts; " \ + "fi\0" + +#define BOOTENV_SHARED_FLASH(devtypel) \ + #devtypel "_boot=" \ + BOOTENV_SHARED_SF_BODY(devtypel) + +#define BOOTENV_DEV_FLASH(devtypeu, devtypel, instance) \ + BOOTENV_DEV_BLKDEV(devtypeu, devtypel, instance) + +#define BOOTENV_DEV_NAME_FLASH(devtypeu, devtypel, instance) \ + BOOTENV_DEV_NAME_BLKDEV(devtypeu, devtypel, instance) + #ifdef CONFIG_SANDBOX #define BOOTENV_SHARED_HOST BOOTENV_SHARED_BLKDEV(host) #define BOOTENV_DEV_HOST BOOTENV_DEV_BLKDEV @@ -398,6 +414,18 @@ BOOT_TARGET_DEVICES_references_PXE_without_CONFIG_CMD_DHCP_or_PXE #endif +#if defined(CONFIG_CMD_SF) +#define BOOTENV_SHARED_SF BOOTENV_SHARED_FLASH(sf) +#define BOOTENV_DEV_SF BOOTENV_DEV_FLASH +#define BOOTENV_DEV_NAME_SF BOOTENV_DEV_NAME_FLASH +#else +#define BOOTENV_SHARED_SF +#define BOOTENV_DEV_SF \ + BOOT_TARGET_DEVICES_references_SF_without_CONFIG_CMD_SF +#define BOOTENV_DEV_NAME_SF \ + BOOT_TARGET_DEVICES_references_SF_without_CONFIG_CMD_SF +#endif + #define BOOTENV_DEV_NAME(devtypeu, devtypel, instance) \ BOOTENV_DEV_NAME_##devtypeu(devtypeu, devtypel, instance) #define BOOTENV_BOOT_TARGETS \ @@ -412,6 +440,7 @@ BOOTENV_SHARED_USB \ BOOTENV_SHARED_SATA \ BOOTENV_SHARED_SCSI \ + BOOTENV_SHARED_SF \ BOOTENV_SHARED_NVME \ BOOTENV_SHARED_IDE \ BOOTENV_SHARED_UBIFS \ @@ -436,6 +465,12 @@ "echo SCRIPT FAILED: continuing...; " \ "fi\0" \ \ + "scan_flash_for_scripts=" \ + "${devtype} read ${scriptaddr} " \ + "${script_offset_f} ${script_size_f}; " \ + "source ${scriptaddr}; " \ + "echo SCRIPT FAILED: continuing...\0" \ + \ "boot_a_script=" \ "load ${devtype} ${devnum}:${distro_bootpart} " \ "${scriptaddr} ${prefix}${script}; " \
Add distro boot command support for SPI flash. This distro boot will read the boot script at specific location at the flash and start sourcing the same. The common macro like BOOTENV_SHARED_FLASH would help to extend the support for nand flash in future. Cc: Tom Rini <trini@konsulko.com> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> --- include/config_distro_bootcmd.h | 35 +++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+)