[PATCH v2 0/9] riscv: sifive/fu540: Booting from SPI
This series support Boot from SPI on SiFive FU540 HiFive Unleashed board, with improved version of detecting bootmode at runtime.
Previous version changes are at [1].
Changes for v2: - fu540 board driver - runtime bootmode detection - rebase on Pragnesh v11 series
[1] https://patchwork.ozlabs.org/project/uboot/cover/20200420140514.25847-1-jaga...
Any inputs? Jagan.
Jagan Teki (9): spl: Try to get SPL boot device via board_get_int dt-bindings: board: Document sifive,fu540-modeselect riscv: dts: fu540-c000-u-boot: Add sifive,fu540-modeselect drivers: Add fu540 board driver sifive: fu540: Add Booting from SPI env: Enable SPI flash env for SiFive FU540 sifive: fu540: Mark the default env as SPI flash sifive: fu540: Add boot flash script offset, size sifive: fu540: Enable SF distro bootcmd
arch/riscv/cpu/fu540/Kconfig | 15 ++++ arch/riscv/dts/fu540-c000-u-boot.dtsi | 7 ++ .../dts/hifive-unleashed-a00-u-boot.dtsi | 12 +++ board/sifive/fu540/Kconfig | 1 + board/sifive/fu540/fu540.c | 12 --- common/spl/spl.c | 14 ++- configs/sifive_fu540_defconfig | 4 + doc/board/sifive/fu540.rst | 41 +++++++++ .../board/sifive,fu540-modeselect.txt | 15 ++++ drivers/board/Kconfig | 8 ++ drivers/board/Makefile | 1 + drivers/board/fu540.c | 86 +++++++++++++++++++ include/board.h | 9 ++ include/configs/sifive-fu540.h | 7 +- 14 files changed, 218 insertions(+), 14 deletions(-) create mode 100644 doc/device-tree-bindings/board/sifive,fu540-modeselect.txt create mode 100644 drivers/board/fu540.c
Usually, the associated board would supply spl boot device using spl_boot_device() but some boards have board driver that are possible to supply boot device via board_get_int with BOARD_SPL_BOOT_DEVICE id.
This patch add support for those.
Cc: Mario Six mario.six@gdsys.cc Cc: Tom Rini trini@konsulko.com Cc: Simon Glass sjg@chromium.org Cc: Jean-Jacques Hiblot jjhiblot@ti.com Signed-off-by: Jagan Teki jagan@amarulasolutions.com --- Changes for v2: - new patch
common/spl/spl.c | 14 +++++++++++++- include/board.h | 9 +++++++++ 2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/common/spl/spl.c b/common/spl/spl.c index fc5cbbbeba..a07b71b3c1 100644 --- a/common/spl/spl.c +++ b/common/spl/spl.c @@ -9,6 +9,7 @@ #include <common.h> #include <bloblist.h> #include <binman_sym.h> +#include <board.h> #include <dm.h> #include <handoff.h> #include <hang.h> @@ -483,9 +484,20 @@ int spl_init(void) #define BOOT_DEVICE_NONE 0xdeadbeef #endif
+__weak u32 spl_boot_device(void) +{ + return 0; +} + __weak void board_boot_order(u32 *spl_boot_list) { - spl_boot_list[0] = spl_boot_device(); + struct udevice *board; + + if (!board_get(&board)) + board_get_int(board, BOARD_SPL_BOOT_DEVICE, + (int *)&spl_boot_list[0]); + else + spl_boot_list[0] = spl_boot_device(); }
static struct spl_image_loader *spl_ll_find_loader(uint boot_device) diff --git a/include/board.h b/include/board.h index 678b652b0a..ce4eaba38d 100644 --- a/include/board.h +++ b/include/board.h @@ -211,3 +211,12 @@ static inline int board_get_fit_loadable(struct udevice *dev, int index, }
#endif + +/** + * Common board unique identifier + * + * @BOARD_SPL_BOOT_DEVICE: id to get SPL boot device. + */ +enum common_ids { + BOARD_SPL_BOOT_DEVICE, +};
On Wed, May 20, 2020 at 12:53:32AM +0530, Jagan Teki wrote:
Usually, the associated board would supply spl boot device using spl_boot_device() but some boards have board driver that are possible to supply boot device via board_get_int with BOARD_SPL_BOOT_DEVICE id.
This patch add support for those.
Cc: Mario Six mario.six@gdsys.cc Cc: Tom Rini trini@konsulko.com Cc: Simon Glass sjg@chromium.org Cc: Jean-Jacques Hiblot jjhiblot@ti.com Signed-off-by: Jagan Teki jagan@amarulasolutions.com
Changes for v2:
- new patch
common/spl/spl.c | 14 +++++++++++++- include/board.h | 9 +++++++++ 2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/common/spl/spl.c b/common/spl/spl.c index fc5cbbbeba..a07b71b3c1 100644 --- a/common/spl/spl.c +++ b/common/spl/spl.c @@ -9,6 +9,7 @@ #include <common.h> #include <bloblist.h> #include <binman_sym.h> +#include <board.h> #include <dm.h> #include <handoff.h> #include <hang.h> @@ -483,9 +484,20 @@ int spl_init(void) #define BOOT_DEVICE_NONE 0xdeadbeef #endif
+__weak u32 spl_boot_device(void) +{
- return 0;
+}
__weak void board_boot_order(u32 *spl_boot_list) {
- spl_boot_list[0] = spl_boot_device();
- struct udevice *board;
- if (!board_get(&board))
board_get_int(board, BOARD_SPL_BOOT_DEVICE,(int *)&spl_boot_list[0]);- else
spl_boot_list[0] = spl_boot_device();}
static struct spl_image_loader *spl_ll_find_loader(uint boot_device) diff --git a/include/board.h b/include/board.h index 678b652b0a..ce4eaba38d 100644 --- a/include/board.h +++ b/include/board.h @@ -211,3 +211,12 @@ static inline int board_get_fit_loadable(struct udevice *dev, int index, }
#endif
+/**
- Common board unique identifier
- @BOARD_SPL_BOOT_DEVICE: id to get SPL boot device.
- */
+enum common_ids {
- BOARD_SPL_BOOT_DEVICE,
+};
I don't understand why we need this abstraction. The intention of what we have today is that the generic SPL framework calls out to something to ask "what are we booted from?". Why can the board driver not just supply that information? Thanks!
On Wed, May 20, 2020 at 6:32 PM Tom Rini trini@konsulko.com wrote:
On Wed, May 20, 2020 at 12:53:32AM +0530, Jagan Teki wrote:
Usually, the associated board would supply spl boot device using spl_boot_device() but some boards have board driver that are possible to supply boot device via board_get_int with BOARD_SPL_BOOT_DEVICE id.
This patch add support for those.
Cc: Mario Six mario.six@gdsys.cc Cc: Tom Rini trini@konsulko.com Cc: Simon Glass sjg@chromium.org Cc: Jean-Jacques Hiblot jjhiblot@ti.com Signed-off-by: Jagan Teki jagan@amarulasolutions.com
Changes for v2:
- new patch
common/spl/spl.c | 14 +++++++++++++- include/board.h | 9 +++++++++ 2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/common/spl/spl.c b/common/spl/spl.c index fc5cbbbeba..a07b71b3c1 100644 --- a/common/spl/spl.c +++ b/common/spl/spl.c @@ -9,6 +9,7 @@ #include <common.h> #include <bloblist.h> #include <binman_sym.h> +#include <board.h> #include <dm.h> #include <handoff.h> #include <hang.h> @@ -483,9 +484,20 @@ int spl_init(void) #define BOOT_DEVICE_NONE 0xdeadbeef #endif
+__weak u32 spl_boot_device(void) +{
return 0;+}
__weak void board_boot_order(u32 *spl_boot_list) {
spl_boot_list[0] = spl_boot_device();
struct udevice *board;if (!board_get(&board))board_get_int(board, BOARD_SPL_BOOT_DEVICE,(int *)&spl_boot_list[0]);elsespl_boot_list[0] = spl_boot_device();}
static struct spl_image_loader *spl_ll_find_loader(uint boot_device) diff --git a/include/board.h b/include/board.h index 678b652b0a..ce4eaba38d 100644 --- a/include/board.h +++ b/include/board.h @@ -211,3 +211,12 @@ static inline int board_get_fit_loadable(struct udevice *dev, int index, }
#endif
+/**
- Common board unique identifier
- @BOARD_SPL_BOOT_DEVICE: id to get SPL boot device.
- */
+enum common_ids {
BOARD_SPL_BOOT_DEVICE,+};
I don't understand why we need this abstraction. The intention of what we have today is that the generic SPL framework calls out to something to ask "what are we booted from?". Why can the board driver not just supply that information? Thanks!
Yes, we can update boot-device on respective areas by probing board driver and assign spl_boot_list[0] by explicitly define spl_boot_device function, but this change bypass all these codes. Just like how we did on SPL fit to load the concerned image via board driver.
152781d4641e0e4c37b3a32f699cf99aeec877c8 "spl: fit: Allow the board to tell if more images must be loaded from FIT"
Jagan.
On Wed, May 20, 2020 at 06:46:55PM +0530, Jagan Teki wrote:
On Wed, May 20, 2020 at 6:32 PM Tom Rini trini@konsulko.com wrote:
On Wed, May 20, 2020 at 12:53:32AM +0530, Jagan Teki wrote:
Usually, the associated board would supply spl boot device using spl_boot_device() but some boards have board driver that are possible to supply boot device via board_get_int with BOARD_SPL_BOOT_DEVICE id.
This patch add support for those.
Cc: Mario Six mario.six@gdsys.cc Cc: Tom Rini trini@konsulko.com Cc: Simon Glass sjg@chromium.org Cc: Jean-Jacques Hiblot jjhiblot@ti.com Signed-off-by: Jagan Teki jagan@amarulasolutions.com
Changes for v2:
- new patch
common/spl/spl.c | 14 +++++++++++++- include/board.h | 9 +++++++++ 2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/common/spl/spl.c b/common/spl/spl.c index fc5cbbbeba..a07b71b3c1 100644 --- a/common/spl/spl.c +++ b/common/spl/spl.c @@ -9,6 +9,7 @@ #include <common.h> #include <bloblist.h> #include <binman_sym.h> +#include <board.h> #include <dm.h> #include <handoff.h> #include <hang.h> @@ -483,9 +484,20 @@ int spl_init(void) #define BOOT_DEVICE_NONE 0xdeadbeef #endif
+__weak u32 spl_boot_device(void) +{
return 0;+}
__weak void board_boot_order(u32 *spl_boot_list) {
spl_boot_list[0] = spl_boot_device();
struct udevice *board;if (!board_get(&board))board_get_int(board, BOARD_SPL_BOOT_DEVICE,(int *)&spl_boot_list[0]);elsespl_boot_list[0] = spl_boot_device();}
static struct spl_image_loader *spl_ll_find_loader(uint boot_device) diff --git a/include/board.h b/include/board.h index 678b652b0a..ce4eaba38d 100644 --- a/include/board.h +++ b/include/board.h @@ -211,3 +211,12 @@ static inline int board_get_fit_loadable(struct udevice *dev, int index, }
#endif
+/**
- Common board unique identifier
- @BOARD_SPL_BOOT_DEVICE: id to get SPL boot device.
- */
+enum common_ids {
BOARD_SPL_BOOT_DEVICE,+};
I don't understand why we need this abstraction. The intention of what we have today is that the generic SPL framework calls out to something to ask "what are we booted from?". Why can the board driver not just supply that information? Thanks!
Yes, we can update boot-device on respective areas by probing board driver and assign spl_boot_list[0] by explicitly define spl_boot_device function, but this change bypass all these codes. Just like how we did on SPL fit to load the concerned image via board driver.
I still don't get it, sorry. Why is spl_boot_device() not provided by the "board" driver to say what to boot in this case?
On Wed, May 20, 2020 at 7:40 PM Tom Rini trini@konsulko.com wrote:
On Wed, May 20, 2020 at 06:46:55PM +0530, Jagan Teki wrote:
On Wed, May 20, 2020 at 6:32 PM Tom Rini trini@konsulko.com wrote:
On Wed, May 20, 2020 at 12:53:32AM +0530, Jagan Teki wrote:
Usually, the associated board would supply spl boot device using spl_boot_device() but some boards have board driver that are possible to supply boot device via board_get_int with BOARD_SPL_BOOT_DEVICE id.
This patch add support for those.
Cc: Mario Six mario.six@gdsys.cc Cc: Tom Rini trini@konsulko.com Cc: Simon Glass sjg@chromium.org Cc: Jean-Jacques Hiblot jjhiblot@ti.com Signed-off-by: Jagan Teki jagan@amarulasolutions.com
Changes for v2:
- new patch
common/spl/spl.c | 14 +++++++++++++- include/board.h | 9 +++++++++ 2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/common/spl/spl.c b/common/spl/spl.c index fc5cbbbeba..a07b71b3c1 100644 --- a/common/spl/spl.c +++ b/common/spl/spl.c @@ -9,6 +9,7 @@ #include <common.h> #include <bloblist.h> #include <binman_sym.h> +#include <board.h> #include <dm.h> #include <handoff.h> #include <hang.h> @@ -483,9 +484,20 @@ int spl_init(void) #define BOOT_DEVICE_NONE 0xdeadbeef #endif
+__weak u32 spl_boot_device(void) +{
return 0;+}
__weak void board_boot_order(u32 *spl_boot_list) {
spl_boot_list[0] = spl_boot_device();
struct udevice *board;if (!board_get(&board))board_get_int(board, BOARD_SPL_BOOT_DEVICE,(int *)&spl_boot_list[0]);elsespl_boot_list[0] = spl_boot_device();}
static struct spl_image_loader *spl_ll_find_loader(uint boot_device) diff --git a/include/board.h b/include/board.h index 678b652b0a..ce4eaba38d 100644 --- a/include/board.h +++ b/include/board.h @@ -211,3 +211,12 @@ static inline int board_get_fit_loadable(struct udevice *dev, int index, }
#endif
+/**
- Common board unique identifier
- @BOARD_SPL_BOOT_DEVICE: id to get SPL boot device.
- */
+enum common_ids {
BOARD_SPL_BOOT_DEVICE,+};
I don't understand why we need this abstraction. The intention of what we have today is that the generic SPL framework calls out to something to ask "what are we booted from?". Why can the board driver not just supply that information? Thanks!
Yes, we can update boot-device on respective areas by probing board driver and assign spl_boot_list[0] by explicitly define spl_boot_device function, but this change bypass all these codes. Just like how we did on SPL fit to load the concerned image via board driver.
I still don't get it, sorry. Why is spl_boot_device() not provided by the "board" driver to say what to boot in this case?
That means, we have to add spl_boot_device in board-uclass.c ? so-that respective board driver shall use?
Jagan.
On Fri, May 22, 2020 at 09:42:22PM +0530, Jagan Teki wrote:
On Wed, May 20, 2020 at 7:40 PM Tom Rini trini@konsulko.com wrote:
On Wed, May 20, 2020 at 06:46:55PM +0530, Jagan Teki wrote:
On Wed, May 20, 2020 at 6:32 PM Tom Rini trini@konsulko.com wrote:
On Wed, May 20, 2020 at 12:53:32AM +0530, Jagan Teki wrote:
Usually, the associated board would supply spl boot device using spl_boot_device() but some boards have board driver that are possible to supply boot device via board_get_int with BOARD_SPL_BOOT_DEVICE id.
This patch add support for those.
Cc: Mario Six mario.six@gdsys.cc Cc: Tom Rini trini@konsulko.com Cc: Simon Glass sjg@chromium.org Cc: Jean-Jacques Hiblot jjhiblot@ti.com Signed-off-by: Jagan Teki jagan@amarulasolutions.com
Changes for v2:
- new patch
common/spl/spl.c | 14 +++++++++++++- include/board.h | 9 +++++++++ 2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/common/spl/spl.c b/common/spl/spl.c index fc5cbbbeba..a07b71b3c1 100644 --- a/common/spl/spl.c +++ b/common/spl/spl.c @@ -9,6 +9,7 @@ #include <common.h> #include <bloblist.h> #include <binman_sym.h> +#include <board.h> #include <dm.h> #include <handoff.h> #include <hang.h> @@ -483,9 +484,20 @@ int spl_init(void) #define BOOT_DEVICE_NONE 0xdeadbeef #endif
+__weak u32 spl_boot_device(void) +{
return 0;+}
__weak void board_boot_order(u32 *spl_boot_list) {
spl_boot_list[0] = spl_boot_device();
struct udevice *board;if (!board_get(&board))board_get_int(board, BOARD_SPL_BOOT_DEVICE,(int *)&spl_boot_list[0]);elsespl_boot_list[0] = spl_boot_device();}
static struct spl_image_loader *spl_ll_find_loader(uint boot_device) diff --git a/include/board.h b/include/board.h index 678b652b0a..ce4eaba38d 100644 --- a/include/board.h +++ b/include/board.h @@ -211,3 +211,12 @@ static inline int board_get_fit_loadable(struct udevice *dev, int index, }
#endif
+/**
- Common board unique identifier
- @BOARD_SPL_BOOT_DEVICE: id to get SPL boot device.
- */
+enum common_ids {
BOARD_SPL_BOOT_DEVICE,+};
I don't understand why we need this abstraction. The intention of what we have today is that the generic SPL framework calls out to something to ask "what are we booted from?". Why can the board driver not just supply that information? Thanks!
Yes, we can update boot-device on respective areas by probing board driver and assign spl_boot_list[0] by explicitly define spl_boot_device function, but this change bypass all these codes. Just like how we did on SPL fit to load the concerned image via board driver.
I still don't get it, sorry. Why is spl_boot_device() not provided by the "board" driver to say what to boot in this case?
That means, we have to add spl_boot_device in board-uclass.c ? so-that respective board driver shall use?
Yes, or perhaps a board driver doesn't even make sense in this case and the existing abstraction should be used as is? This isn't a unique problem, it's something we've been handling in SPL since the beginning. In so far as we can now try and solve this problem with something DM-based instead of not, it should still I believe just be the same function call.
On Sat, May 23, 2020 at 2:55 AM Tom Rini trini@konsulko.com wrote:
On Fri, May 22, 2020 at 09:42:22PM +0530, Jagan Teki wrote:
On Wed, May 20, 2020 at 7:40 PM Tom Rini trini@konsulko.com wrote:
On Wed, May 20, 2020 at 06:46:55PM +0530, Jagan Teki wrote:
On Wed, May 20, 2020 at 6:32 PM Tom Rini trini@konsulko.com wrote:
On Wed, May 20, 2020 at 12:53:32AM +0530, Jagan Teki wrote:
Usually, the associated board would supply spl boot device using spl_boot_device() but some boards have board driver that are possible to supply boot device via board_get_int with BOARD_SPL_BOOT_DEVICE id.
This patch add support for those.
Cc: Mario Six mario.six@gdsys.cc Cc: Tom Rini trini@konsulko.com Cc: Simon Glass sjg@chromium.org Cc: Jean-Jacques Hiblot jjhiblot@ti.com Signed-off-by: Jagan Teki jagan@amarulasolutions.com
Changes for v2:
- new patch
common/spl/spl.c | 14 +++++++++++++- include/board.h | 9 +++++++++ 2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/common/spl/spl.c b/common/spl/spl.c index fc5cbbbeba..a07b71b3c1 100644 --- a/common/spl/spl.c +++ b/common/spl/spl.c @@ -9,6 +9,7 @@ #include <common.h> #include <bloblist.h> #include <binman_sym.h> +#include <board.h> #include <dm.h> #include <handoff.h> #include <hang.h> @@ -483,9 +484,20 @@ int spl_init(void) #define BOOT_DEVICE_NONE 0xdeadbeef #endif
+__weak u32 spl_boot_device(void) +{
return 0;+}
__weak void board_boot_order(u32 *spl_boot_list) {
spl_boot_list[0] = spl_boot_device();
struct udevice *board;if (!board_get(&board))board_get_int(board, BOARD_SPL_BOOT_DEVICE,(int *)&spl_boot_list[0]);elsespl_boot_list[0] = spl_boot_device();}
static struct spl_image_loader *spl_ll_find_loader(uint boot_device) diff --git a/include/board.h b/include/board.h index 678b652b0a..ce4eaba38d 100644 --- a/include/board.h +++ b/include/board.h @@ -211,3 +211,12 @@ static inline int board_get_fit_loadable(struct udevice *dev, int index, }
#endif
+/**
- Common board unique identifier
- @BOARD_SPL_BOOT_DEVICE: id to get SPL boot device.
- */
+enum common_ids {
BOARD_SPL_BOOT_DEVICE,+};
I don't understand why we need this abstraction. The intention of what we have today is that the generic SPL framework calls out to something to ask "what are we booted from?". Why can the board driver not just supply that information? Thanks!
Yes, we can update boot-device on respective areas by probing board driver and assign spl_boot_list[0] by explicitly define spl_boot_device function, but this change bypass all these codes. Just like how we did on SPL fit to load the concerned image via board driver.
I still don't get it, sorry. Why is spl_boot_device() not provided by the "board" driver to say what to boot in this case?
That means, we have to add spl_boot_device in board-uclass.c ? so-that respective board driver shall use?
Yes, or perhaps a board driver doesn't even make sense in this case and the existing abstraction should be used as is? This isn't a unique problem, it's something we've been handling in SPL since the beginning. In so far as we can now try and solve this problem with something DM-based instead of not, it should still I believe just be the same function call.
I don't understand why we have individual function calls though we have dm supported cases to get rid of those? then why would be the case for spl fit code to pump multiple images via dm board driver? What this patch is trying to do is fundamentally similar, like spl_fit is using a board driver to support multiple fit images where spl is using a board driver to support the desired boot device.
Jagan.
On Mon, May 25, 2020 at 02:01:09PM +0530, Jagan Teki wrote:
On Sat, May 23, 2020 at 2:55 AM Tom Rini trini@konsulko.com wrote:
On Fri, May 22, 2020 at 09:42:22PM +0530, Jagan Teki wrote:
On Wed, May 20, 2020 at 7:40 PM Tom Rini trini@konsulko.com wrote:
On Wed, May 20, 2020 at 06:46:55PM +0530, Jagan Teki wrote:
On Wed, May 20, 2020 at 6:32 PM Tom Rini trini@konsulko.com wrote:
On Wed, May 20, 2020 at 12:53:32AM +0530, Jagan Teki wrote:
> Usually, the associated board would supply spl boot device > using spl_boot_device() but some boards have board driver > that are possible to supply boot device via board_get_int > with BOARD_SPL_BOOT_DEVICE id. > > This patch add support for those. > > Cc: Mario Six mario.six@gdsys.cc > Cc: Tom Rini trini@konsulko.com > Cc: Simon Glass sjg@chromium.org > Cc: Jean-Jacques Hiblot jjhiblot@ti.com > Signed-off-by: Jagan Teki jagan@amarulasolutions.com > --- > Changes for v2: > - new patch > > common/spl/spl.c | 14 +++++++++++++- > include/board.h | 9 +++++++++ > 2 files changed, 22 insertions(+), 1 deletion(-) > > diff --git a/common/spl/spl.c b/common/spl/spl.c > index fc5cbbbeba..a07b71b3c1 100644 > --- a/common/spl/spl.c > +++ b/common/spl/spl.c > @@ -9,6 +9,7 @@ > #include <common.h> > #include <bloblist.h> > #include <binman_sym.h> > +#include <board.h> > #include <dm.h> > #include <handoff.h> > #include <hang.h> > @@ -483,9 +484,20 @@ int spl_init(void) > #define BOOT_DEVICE_NONE 0xdeadbeef > #endif > > +__weak u32 spl_boot_device(void) > +{ > + return 0; > +} > + > __weak void board_boot_order(u32 *spl_boot_list) > { > - spl_boot_list[0] = spl_boot_device(); > + struct udevice *board; > + > + if (!board_get(&board)) > + board_get_int(board, BOARD_SPL_BOOT_DEVICE, > + (int *)&spl_boot_list[0]); > + else > + spl_boot_list[0] = spl_boot_device(); > } > > static struct spl_image_loader *spl_ll_find_loader(uint boot_device) > diff --git a/include/board.h b/include/board.h > index 678b652b0a..ce4eaba38d 100644 > --- a/include/board.h > +++ b/include/board.h > @@ -211,3 +211,12 @@ static inline int board_get_fit_loadable(struct udevice *dev, int index, > } > > #endif > + > +/** > + * Common board unique identifier > + * > + * @BOARD_SPL_BOOT_DEVICE: id to get SPL boot device. > + */ > +enum common_ids { > + BOARD_SPL_BOOT_DEVICE, > +};
I don't understand why we need this abstraction. The intention of what we have today is that the generic SPL framework calls out to something to ask "what are we booted from?". Why can the board driver not just supply that information? Thanks!
Yes, we can update boot-device on respective areas by probing board driver and assign spl_boot_list[0] by explicitly define spl_boot_device function, but this change bypass all these codes. Just like how we did on SPL fit to load the concerned image via board driver.
I still don't get it, sorry. Why is spl_boot_device() not provided by the "board" driver to say what to boot in this case?
That means, we have to add spl_boot_device in board-uclass.c ? so-that respective board driver shall use?
Yes, or perhaps a board driver doesn't even make sense in this case and the existing abstraction should be used as is? This isn't a unique problem, it's something we've been handling in SPL since the beginning. In so far as we can now try and solve this problem with something DM-based instead of not, it should still I believe just be the same function call.
I don't understand why we have individual function calls though we have dm supported cases to get rid of those? then why would be the case for spl fit code to pump multiple images via dm board driver? What this patch is trying to do is fundamentally similar, like spl_fit is using a board driver to support multiple fit images where spl is using a board driver to support the desired boot device.
Because when using DM it needs to be to improve things overall, not just duplicate them. We have an abstraction for "figure out what device we've booted from" already. I don't see how your changes are improving the situation, just making the same abstraction with more calls.
When we're dealing with SPL we need to be even more thoughtful than usual about size impacts. So the DM implementation of spl_boot_device() belongs elsewhere rather than making SPL do some checks and doing DM or not DM. Thanks!
Add dt-bindings documentation for sifive,fu540-modeselect board driver, which usually get runtime boot mode of fu540 boards.
Cc: Simon Glass sjg@chromium.org Signed-off-by: Jagan Teki jagan@amarulasolutions.com --- Changes for v2: - new patch
.../board/sifive,fu540-modeselect.txt | 15 +++++++++++++++ 1 file changed, 15 insertions(+) create mode 100644 doc/device-tree-bindings/board/sifive,fu540-modeselect.txt
diff --git a/doc/device-tree-bindings/board/sifive,fu540-modeselect.txt b/doc/device-tree-bindings/board/sifive,fu540-modeselect.txt new file mode 100644 index 0000000000..801c068390 --- /dev/null +++ b/doc/device-tree-bindings/board/sifive,fu540-modeselect.txt @@ -0,0 +1,15 @@ +fu540 board driver + +This driver provides capabilities to get the current boot device for +fu540 associated board. + +Required properties: +- compatible: should be "sifive,fu540-modeselect" +- reg: physical base address and size of fu540 modeselct + +Example: + +board: mode@1000 { + compatible = "sifive,fu540-modeselect"; + reg = <0x0 0x1000 0x0 0x1FFF>; +};
Hi Jagan,
On Wed, May 20, 2020 at 3:24 AM Jagan Teki jagan@amarulasolutions.com wrote:
Add dt-bindings documentation for sifive,fu540-modeselect board driver, which usually get runtime boot mode of fu540 boards.
Cc: Simon Glass sjg@chromium.org Signed-off-by: Jagan Teki jagan@amarulasolutions.com
Changes for v2:
- new patch
.../board/sifive,fu540-modeselect.txt | 15 +++++++++++++++ 1 file changed, 15 insertions(+) create mode 100644 doc/device-tree-bindings/board/sifive,fu540-modeselect.txt
diff --git a/doc/device-tree-bindings/board/sifive,fu540-modeselect.txt b/doc/device-tree-bindings/board/sifive,fu540-modeselect.txt new file mode 100644 index 0000000000..801c068390 --- /dev/null +++ b/doc/device-tree-bindings/board/sifive,fu540-modeselect.txt @@ -0,0 +1,15 @@ +fu540 board driver
+This driver provides capabilities to get the current boot device for +fu540 associated board.
This is not a board specific setting, but a SoC specific setting. The MSEL is common for all FU540 based board.
+Required properties: +- compatible: should be "sifive,fu540-modeselect" +- reg: physical base address and size of fu540 modeselct
+Example:
+board: mode@1000 {
compatible = "sifive,fu540-modeselect";reg = <0x0 0x1000 0x0 0x1FFF>;
We should only map 4 bytes for mode select.
+};
Regards, Bin
Add sifive,fu540-modeselect node, which usually get runtime boot mode of fu540 boards.
Signed-off-by: Jagan Teki jagan@amarulasolutions.com --- Changes for v2: - new patch
arch/riscv/dts/fu540-c000-u-boot.dtsi | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/arch/riscv/dts/fu540-c000-u-boot.dtsi b/arch/riscv/dts/fu540-c000-u-boot.dtsi index fc91a7c987..0ccda0e59b 100644 --- a/arch/riscv/dts/fu540-c000-u-boot.dtsi +++ b/arch/riscv/dts/fu540-c000-u-boot.dtsi @@ -48,6 +48,13 @@
soc { u-boot,dm-spl; + + board: mode@1000 { + compatible = "sifive,fu540-modeselect"; + reg = <0x0 0x1000 0x0 0x1FFF>; + u-boot,dm-spl; + }; + otp: otp@10070000 { compatible = "sifive,fu540-c000-otp"; reg = <0x0 0x10070000 0x0 0x0FFF>;
Add fu540 board driver, which is used to get runtime boot mode of fu540 boards.
Cc: Mario Six mario.six@gdsys.cc Cc: Tom Rini trini@konsulko.com Cc: Simon Glass sjg@chromium.org Cc: Jean-Jacques Hiblot jjhiblot@ti.com Signed-off-by: Jagan Teki jagan@amarulasolutions.com --- Changes for v2: - new patch
drivers/board/Kconfig | 8 ++++ drivers/board/Makefile | 1 + drivers/board/fu540.c | 86 ++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 95 insertions(+) create mode 100644 drivers/board/fu540.c
diff --git a/drivers/board/Kconfig b/drivers/board/Kconfig index 254f657049..306ee76bbd 100644 --- a/drivers/board/Kconfig +++ b/drivers/board/Kconfig @@ -12,6 +12,14 @@ config SPL_BOARD depends on SPL_DM bool "Enable board driver support in SPL"
+config BOARD_FU540 + bool "Enable board driver for the FU540 boards" + depends on RISCV + select SPL_BOARD + help + Support querying board information for the fu540 boards, like + get soc mode select, get SPL boot device and etc. + config BOARD_GAZERBEAM bool "Enable board driver for the Gazerbeam board" help diff --git a/drivers/board/Makefile b/drivers/board/Makefile index cc16361755..e924472779 100644 --- a/drivers/board/Makefile +++ b/drivers/board/Makefile @@ -3,5 +3,6 @@ # (C) Copyright 2017 # Mario Six, Guntermann & Drunck GmbH, mario.six@gdsys.cc obj-y += board-uclass.o +obj-$(CONFIG_BOARD_FU540) += fu540.o obj-$(CONFIG_BOARD_GAZERBEAM) += gazerbeam.o obj-$(CONFIG_BOARD_SANDBOX) += sandbox.o diff --git a/drivers/board/fu540.c b/drivers/board/fu540.c new file mode 100644 index 0000000000..68d356df6b --- /dev/null +++ b/drivers/board/fu540.c @@ -0,0 +1,86 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (c) 2020 Amarula Solutions(India) + */ + +#include <common.h> +#include <dm.h> +#include <dm/device_compat.h> +#include <board.h> +#include <spl.h> +#include <asm/io.h> + +#define MODE_SELECT_QSPI 0x6 +#define MODE_SELECT_SD 0xb +#define MODE_SELECT_MASK GENMASK(3, 0) + +struct fu540_board { + void __iomem *regs; +}; + +static int fu540_get_boot_device(struct udevice *dev) +{ + struct fu540_board *priv = dev_get_priv(dev); + u8 boot_device = BOOT_DEVICE_MMC1; + u32 reg; + + reg = readl(priv->regs); + switch (reg & MODE_SELECT_MASK) { + case MODE_SELECT_QSPI: + boot_device = BOOT_DEVICE_SPI; + break; + case MODE_SELECT_SD: + boot_device = BOOT_DEVICE_MMC1; + break; + default: + dev_err(dev, + "Unsupported boot device 0x%x but trying MMC1\n", + boot_device); + break; + } + + return boot_device; +} + +static int fu540_board_get_int(struct udevice *dev, int id, int *val) +{ + switch (id) { + case BOARD_SPL_BOOT_DEVICE: + *val = fu540_get_boot_device(dev); + break; + default: + dev_err(dev, "%s: Integer value %d unknown\n", dev->name, id); + return -EINVAL; + } + + return 0; +} + +static const struct board_ops fu540_board_ops = { + .get_int = fu540_board_get_int, +}; + +static int fu540_board_probe(struct udevice *dev) +{ + struct fu540_board *priv = dev_get_priv(dev); + + priv->regs = (void __iomem *)dev_read_addr(dev); + if (IS_ERR(priv->regs)) + return PTR_ERR(priv->regs); + + return 0; +} + +static const struct udevice_id fu540_board_ids[] = { + { .compatible = "sifive,fu540-modeselect", }, + { /* sentinel */ } +}; + +U_BOOT_DRIVER(fu540_board) = { + .id = UCLASS_BOARD, + .name = "fu540_board", + .of_match = fu540_board_ids, + .ops = &fu540_board_ops, + .priv_auto_alloc_size = sizeof(struct fu540_board), + .probe = fu540_board_probe, +};
U-Boot SPL 2020.07-rc2-00156-gb9abb0716a-dirty (May 19 2020 - 21:56:17 +0530) Trying to boot from SPI
U-Boot 2020.07-rc2-00156-gb9abb0716a-dirty (May 19 2020 - 21:56:17 +0530)
CPU: rv64imafdc Model: SiFive HiFive Unleashed A00 DRAM: 8 GiB No reserved memory region found in source FDT MMC: spi@10050000:mmc@0: 0 In: serial@10010000 Out: serial@10010000 Err: serial@10010000 Net: eth0: ethernet@10090000 Hit any key to stop autoboot: 0
Signed-off-by: Jagan Teki jagan@amarulasolutions.com --- Changes for v2: - enable board driver - comment spl-payloade-offset - reference for SPI partition
arch/riscv/cpu/fu540/Kconfig | 2 + .../dts/hifive-unleashed-a00-u-boot.dtsi | 12 ++++++ board/sifive/fu540/fu540.c | 12 ------ configs/sifive_fu540_defconfig | 4 ++ doc/board/sifive/fu540.rst | 41 +++++++++++++++++++ 5 files changed, 59 insertions(+), 12 deletions(-)
diff --git a/arch/riscv/cpu/fu540/Kconfig b/arch/riscv/cpu/fu540/Kconfig index e9302e87c0..7a813a9ac8 100644 --- a/arch/riscv/cpu/fu540/Kconfig +++ b/arch/riscv/cpu/fu540/Kconfig @@ -5,6 +5,8 @@ config SIFIVE_FU540 bool select ARCH_EARLY_INIT_R + imply BOARD + imply BOARD_FU540 imply CPU imply CPU_RISCV imply RISCV_TIMER diff --git a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi index 303806454b..4b2b242deb 100644 --- a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi +++ b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi @@ -12,6 +12,10 @@ spi2 = &qspi2; };
+ config { + u-boot,spl-payload-offset = <0x105000>; /* loader2 @1044KB */ + }; + hfclk { u-boot,dm-spl; }; @@ -22,6 +26,14 @@
};
+&qspi0 { + u-boot,dm-spl; + + flash@0 { + u-boot,dm-spl; + }; +}; + &qspi2 { mmc@0 { u-boot,dm-spl; diff --git a/board/sifive/fu540/fu540.c b/board/sifive/fu540/fu540.c index 535ab60aed..a7b530b281 100644 --- a/board/sifive/fu540/fu540.c +++ b/board/sifive/fu540/fu540.c @@ -116,18 +116,6 @@ int board_init(void) return 0; }
-#ifdef CONFIG_SPL -u32 spl_boot_device(void) -{ -#ifdef CONFIG_SPL_MMC_SUPPORT - return BOOT_DEVICE_MMC1; -#else - puts("Unknown boot device\n"); - hang(); -#endif -} -#endif - #ifdef CONFIG_SPL_LOAD_FIT int board_fit_config_name_match(const char *name) { diff --git a/configs/sifive_fu540_defconfig b/configs/sifive_fu540_defconfig index 8d412f8d6a..551d4b04a5 100644 --- a/configs/sifive_fu540_defconfig +++ b/configs/sifive_fu540_defconfig @@ -2,9 +2,11 @@ CONFIG_RISCV=y CONFIG_SPL_GPIO_SUPPORT=y CONFIG_SYS_MALLOC_F_LEN=0x3000 CONFIG_ENV_SIZE=0x20000 +CONFIG_SPL_DM_SPI=y CONFIG_SPL_MMC_SUPPORT=y CONFIG_NR_DRAM_BANKS=1 CONFIG_SPL=y +CONFIG_SPL_SPI_FLASH_SUPPORT=y CONFIG_SPL_SPI_SUPPORT=y CONFIG_TARGET_SIFIVE_FU540=y CONFIG_ARCH_RV64I=y @@ -15,9 +17,11 @@ CONFIG_MISC_INIT_R=y CONFIG_DISPLAY_CPUINFO=y CONFIG_DISPLAY_BOARDINFO=y CONFIG_SPL_SEPARATE_BSS=y +CONFIG_SPL_SPI_LOAD=y CONFIG_SPL_YMODEM_SUPPORT=y CONFIG_OF_BOARD_FIXUP=y CONFIG_DEFAULT_DEVICE_TREE="hifive-unleashed-a00" CONFIG_SYS_RELOC_GD_ENV_ADDR=y +CONFIG_SPL_DM_SEQ_ALIAS=y CONFIG_SPL_CLK=y CONFIG_DM_MTD=y diff --git a/doc/board/sifive/fu540.rst b/doc/board/sifive/fu540.rst index 9e9ae98b64..d3d38eb966 100644 --- a/doc/board/sifive/fu540.rst +++ b/doc/board/sifive/fu540.rst @@ -541,3 +541,44 @@ Sample boot log from HiFive Unleashed board type: 0fc63daf-8483-4772-8e79-3d69d8477de4 type: linux guid: 9faa81b6-39b1-4418-af5e-89c48f29c20d + +Booting from SPI +---------------- + +Use Building steps from "Booting from MMC using U-Boot SPL" section. + +Partition the SPI in Linux via mtdblock. (Require to boot the board in +SD boot mode by enabling MTD block in Linux) + +Use prebuilt image from here [1], which support to partition the SPI flash. + +.. code-block:: none + + # sgdisk --clear \ + > --set-alignment=2 \ + > --new=1:40:2087 --change-name=1:loader1 --typecode=1:5B193300-FC78-40CD-8002-E86C45580B47 \ + > --new=2:2088:10279 --change-name=2:loader2 --typecode=2:2E54B353-1271-4842-806F-E436D6AF6985 \ + > --new=3:10536:65494 --change-name=3:rootfs --typecode=3:0FC63DAF-8483-4772-8E79-3D69D8477DE4 \ + > /dev/mtdblock0 + +Program the SPI (Require to boot the board in SD boot mode) + +Execute below steps on U-Boot proper, + +.. code-block:: none + + sf erase 0x5000 0x100000 + tftpboot $kernel_addr_r u-boot-spl.bin + sf write $kernel_addr_r 0x5000 $filesize + + sf erase 0x105000 0x100000 + tftpboot $kernel_addr_r u-boot.itb + sf write $kernel_addr_r 0x105000 $filesize + +Power off the board + +Change DIP switches MSEL[3:0] are set to 0110 + +Power up the board. + +[1] https://github.com/amarula/bsp-sifive
SPI flash device on HiFive Unleashed has 32MiB Size.
This patch add SPI flash environment after U-Boot proper partition with a size of 128KiB.
SPI flash partition layout(32MiB): 0 - 34 : reserved for GPT header 35 - 39 : unused 40 - 2087 : loader1 (SPL, FSBL) 2088 - 10279 : loader2 (U-Boot proper, U-Boot) 10280 - 10535 : environment 10536 - 65494 : rootfs 65528 - 65536 : distro script
Note: the loader1 must start from 40th sector even though there are 6 free sectors prior since 40th sector is nearest flash sector boundary.
Signed-off-by: Jagan Teki jagan@amarulasolutions.com --- Changes for v2: - move env offsets from generic to cpu Kconfig
arch/riscv/cpu/fu540/Kconfig | 13 +++++++++++++ 1 file changed, 13 insertions(+)
diff --git a/arch/riscv/cpu/fu540/Kconfig b/arch/riscv/cpu/fu540/Kconfig index 7a813a9ac8..417926d2cf 100644 --- a/arch/riscv/cpu/fu540/Kconfig +++ b/arch/riscv/cpu/fu540/Kconfig @@ -15,3 +15,16 @@ config SIFIVE_FU540 imply SPL_CPU_SUPPORT imply SPL_OPENSBI imply SPL_LOAD_FIT + +if CONFIG_ENV_IS_IN_SPI_FLASH + +config ENV_OFFSET + default 0x505000 + +config ENV_SIZE + default 0x20000 + +config ENV_SECT_SIZE + default 0x10000 + +endif # CONFIG_ENV_IS_IN_SPI_FLASH
Mark the default U-Boot environment as SPI flash since this is an on board flash device.
Reviewed-by: Bin Meng bmeng.cn@gmail.com Signed-off-by: Jagan Teki jagan@amarulasolutions.com --- Changes for v2: - none
board/sifive/fu540/Kconfig | 1 + 1 file changed, 1 insertion(+)
diff --git a/board/sifive/fu540/Kconfig b/board/sifive/fu540/Kconfig index 86193d7668..e1ba629e37 100644 --- a/board/sifive/fu540/Kconfig +++ b/board/sifive/fu540/Kconfig @@ -27,6 +27,7 @@ config BOARD_SPECIFIC_OPTIONS # dummy def_bool y select SIFIVE_FU540 select SUPPORT_SPL + select ENV_IS_IN_SPI_FLASH select RAM select SPL_RAM if SPL imply CMD_DHCP
HiFive-Unleashed-A00 has SPI flash with 32MiB size. So, let's use the script offset at the end of 4K. This way it cannot overlap any offsets being used by software components in flash layout.
So, SF distrocmd will pick the script at desired script address and run.
Signed-off-by: Jagan Teki jagan@amarulasolutions.com --- Changes for v2: - none
include/configs/sifive-fu540.h | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/include/configs/sifive-fu540.h b/include/configs/sifive-fu540.h index 72c841eb9b..68fda14d76 100644 --- a/include/configs/sifive-fu540.h +++ b/include/configs/sifive-fu540.h @@ -62,6 +62,8 @@ "kernel_addr_r=0x84000000\0" \ "fdt_addr_r=0x88000000\0" \ "scriptaddr=0x88100000\0" \ + "script_offset_f=0x1fff000\0" \ + "script_size_f=0x1000\0" \ "pxefile_addr_r=0x88200000\0" \ "ramdisk_addr_r=0x88300000\0" \ "type_guid_gpt_loader1=" TYPE_GUID_LOADER1 "\0" \
Enable SPI flash(SF) distro boot command in Sifive FU540.
This distro boot will read the boot script at specific location at the flash and start sourcing the same.
Included the SF device at the last of the target devices list since all the rest of the devices on the list have more possibility to boot the distribution due to the size of the SPI flash is concern.
Signed-off-by: Jagan Teki jagan@amarulasolutions.com --- Changes for v2: - none
include/configs/sifive-fu540.h | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/configs/sifive-fu540.h b/include/configs/sifive-fu540.h index 68fda14d76..f21411a701 100644 --- a/include/configs/sifive-fu540.h +++ b/include/configs/sifive-fu540.h @@ -43,9 +43,11 @@ #ifndef CONFIG_SPL_BUILD #define BOOT_TARGET_DEVICES(func) \ func(MMC, mmc, 0) \ + func(SF, sf, 0) \ func(DHCP, dhcp, na)
#include <config_distro_bootcmd.h> +#include <environment/distro/sf.h>
#define TYPE_GUID_LOADER1 "5B193300-FC78-40CD-8002-E86C45580B47" #define TYPE_GUID_LOADER2 "2E54B353-1271-4842-806F-E436D6AF6985" @@ -70,7 +72,8 @@ "type_guid_gpt_loader2=" TYPE_GUID_LOADER2 "\0" \ "type_guid_gpt_system=" TYPE_GUID_SYSTEM "\0" \ "partitions=" PARTS_DEFAULT "\0" \ - BOOTENV + BOOTENV \ + BOOTENV_SF
#define CONFIG_PREBOOT \ "setenv fdt_addr ${fdtcontroladdr};" \
Hi Jagan,
On Wed, May 20, 2020 at 3:24 AM Jagan Teki jagan@amarulasolutions.com wrote:
This series support Boot from SPI on SiFive FU540 HiFive Unleashed board, with improved version of detecting bootmode at runtime.
Previous version changes are at [1].
Changes for v2:
- fu540 board driver
- runtime bootmode detection
- rebase on Pragnesh v11 series
[1] https://patchwork.ozlabs.org/project/uboot/cover/20200420140514.25847-1-jaga...
Any inputs?
It looks this series does not build?
$ make sifive_fu540_defconfig $ make -j32 scripts/kconfig/conf --syncconfig Kconfig .config:36:warning: symbol value '' invalid for ENV_OFFSET .config:37:warning: symbol value '' invalid for ENV_SECT_SIZE * * Restart config... * * * Environment * Environment is not stored (ENV_IS_NOWHERE) [N/y/?] n Environment in EEPROM (ENV_IS_IN_EEPROM) [N/y/?] n Environment is in a FAT filesystem (ENV_IS_IN_FAT) [N/y/?] n Environment is in a EXT4 filesystem (ENV_IS_IN_EXT4) [N/y/?] n Environment in flash memory (ENV_IS_IN_FLASH) [N/y/?] n Environment in an MMC device (ENV_IS_IN_MMC) [N/y/?] n Environment in a NAND device (ENV_IS_IN_NAND) [N/y/?] n Environment in a non-volatile RAM (ENV_IS_IN_NVRAM) [N/y/?] n Environment is in OneNAND (ENV_IS_IN_ONENAND) [N/y/?] n Environment is in remote memory space (ENV_IS_IN_REMOTE) [N/y/?] n Environment is in SPI flash (ENV_IS_IN_SPI_FLASH) [Y/?] y SPI flash bus for environment (USE_ENV_SPI_BUS) [N/y/?] n SPI flash chip select for environment (USE_ENV_SPI_CS) [N/y/?] n SPI flash max frequency for environment (USE_ENV_SPI_MAX_HZ) [N/y/?] n SPI flash mode for environment (USE_ENV_SPI_MODE) [N/y/?] n Enable redundant environment support (SYS_REDUNDAND_ENVIRONMENT) [N/y/?] n Environment address (ENV_ADDR) [0x0] 0x0 Environment offset (ENV_OFFSET) [] (NEW) ^Cscripts/kconfig/Makefile:75: recipe for target 'syncconfig' failed make[2]: *** [syncconfig] Interrupt Makefile:565: recipe for target 'syncconfig' failed make[1]: *** [syncconfig] Interrupt
Regards, Bin
On Mon, May 25, 2020 at 10:10 AM Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Wed, May 20, 2020 at 3:24 AM Jagan Teki jagan@amarulasolutions.com wrote:
This series support Boot from SPI on SiFive FU540 HiFive Unleashed board, with improved version of detecting bootmode at runtime.
Previous version changes are at [1].
Changes for v2:
- fu540 board driver
- runtime bootmode detection
- rebase on Pragnesh v11 series
[1] https://patchwork.ozlabs.org/project/uboot/cover/20200420140514.25847-1-jaga...
Any inputs?
It looks this series does not build?
$ make sifive_fu540_defconfig $ make -j32 scripts/kconfig/conf --syncconfig Kconfig .config:36:warning: symbol value '' invalid for ENV_OFFSET .config:37:warning: symbol value '' invalid for ENV_SECT_SIZE
- Restart config...
- Environment
Environment is not stored (ENV_IS_NOWHERE) [N/y/?] n Environment in EEPROM (ENV_IS_IN_EEPROM) [N/y/?] n Environment is in a FAT filesystem (ENV_IS_IN_FAT) [N/y/?] n Environment is in a EXT4 filesystem (ENV_IS_IN_EXT4) [N/y/?] n Environment in flash memory (ENV_IS_IN_FLASH) [N/y/?] n Environment in an MMC device (ENV_IS_IN_MMC) [N/y/?] n Environment in a NAND device (ENV_IS_IN_NAND) [N/y/?] n Environment in a non-volatile RAM (ENV_IS_IN_NVRAM) [N/y/?] n Environment is in OneNAND (ENV_IS_IN_ONENAND) [N/y/?] n Environment is in remote memory space (ENV_IS_IN_REMOTE) [N/y/?] n Environment is in SPI flash (ENV_IS_IN_SPI_FLASH) [Y/?] y SPI flash bus for environment (USE_ENV_SPI_BUS) [N/y/?] n SPI flash chip select for environment (USE_ENV_SPI_CS) [N/y/?] n SPI flash max frequency for environment (USE_ENV_SPI_MAX_HZ) [N/y/?] n SPI flash mode for environment (USE_ENV_SPI_MODE) [N/y/?] n Enable redundant environment support (SYS_REDUNDAND_ENVIRONMENT) [N/y/?] n Environment address (ENV_ADDR) [0x0] 0x0 Environment offset (ENV_OFFSET) [] (NEW) ^Cscripts/kconfig/Makefile:75: recipe for target 'syncconfig' failed make[2]: *** [syncconfig] Interrupt Makefile:565: recipe for target 'syncconfig' failed make[1]: *** [syncconfig] Interrupt
Simply fixed the build by:
diff --git a/arch/riscv/cpu/fu540/Kconfig b/arch/riscv/cpu/fu540/Kconfig index 417926d..64f2b93 100644 --- a/arch/riscv/cpu/fu540/Kconfig +++ b/arch/riscv/cpu/fu540/Kconfig @@ -16,8 +16,6 @@ config SIFIVE_FU540 imply SPL_OPENSBI imply SPL_LOAD_FIT
-if CONFIG_ENV_IS_IN_SPI_FLASH - config ENV_OFFSET default 0x505000
@@ -26,5 +24,3 @@ config ENV_SIZE
config ENV_SECT_SIZE default 0x10000 - -endif # CONFIG_ENV_IS_IN_SPI_FLASH
Regards, Bin
participants (3)
-
Bin Meng -
Jagan Teki -
Tom Rini