* [PATCH v2 1/9] spl: Try to get SPL boot device via board_get_int
2020-05-19 19:23 [PATCH v2 0/9] riscv: sifive/fu540: Booting from SPI Jagan Teki
@ 2020-05-19 19:23 ` Jagan Teki
2020-05-20 13:02 ` Tom Rini
2020-05-19 19:23 ` [PATCH v2 2/9] dt-bindings: board: Document sifive,fu540-modeselect Jagan Teki
` (8 subsequent siblings)
9 siblings, 1 reply; 20+ messages in thread
From: Jagan Teki @ 2020-05-19 19:23 UTC (permalink / raw)
To: u-boot
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,
+};
--
2.20.1
^ permalink raw reply related [flat|nested] 20+ messages in thread* [PATCH v2 1/9] spl: Try to get SPL boot device via board_get_int
2020-05-19 19:23 ` [PATCH v2 1/9] spl: Try to get SPL boot device via board_get_int Jagan Teki
@ 2020-05-20 13:02 ` Tom Rini
2020-05-20 13:16 ` Jagan Teki
0 siblings, 1 reply; 20+ messages in thread
From: Tom Rini @ 2020-05-20 13:02 UTC (permalink / raw)
To: u-boot
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!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200520/c637c17d/attachment.sig>
^ permalink raw reply [flat|nested] 20+ messages in thread* [PATCH v2 1/9] spl: Try to get SPL boot device via board_get_int
2020-05-20 13:02 ` Tom Rini
@ 2020-05-20 13:16 ` Jagan Teki
2020-05-20 14:10 ` Tom Rini
0 siblings, 1 reply; 20+ messages in thread
From: Jagan Teki @ 2020-05-20 13:16 UTC (permalink / raw)
To: u-boot
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.
152781d4641e0e4c37b3a32f699cf99aeec877c8
"spl: fit: Allow the board to tell if more images must be loaded from FIT"
Jagan.
^ permalink raw reply [flat|nested] 20+ messages in thread* [PATCH v2 1/9] spl: Try to get SPL boot device via board_get_int
2020-05-20 13:16 ` Jagan Teki
@ 2020-05-20 14:10 ` Tom Rini
2020-05-22 16:12 ` Jagan Teki
0 siblings, 1 reply; 20+ messages in thread
From: Tom Rini @ 2020-05-20 14:10 UTC (permalink / raw)
To: u-boot
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?
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200520/0211f759/attachment.sig>
^ permalink raw reply [flat|nested] 20+ messages in thread* [PATCH v2 1/9] spl: Try to get SPL boot device via board_get_int
2020-05-20 14:10 ` Tom Rini
@ 2020-05-22 16:12 ` Jagan Teki
2020-05-22 21:25 ` Tom Rini
0 siblings, 1 reply; 20+ messages in thread
From: Jagan Teki @ 2020-05-22 16:12 UTC (permalink / raw)
To: u-boot
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?
Jagan.
^ permalink raw reply [flat|nested] 20+ messages in thread* [PATCH v2 1/9] spl: Try to get SPL boot device via board_get_int
2020-05-22 16:12 ` Jagan Teki
@ 2020-05-22 21:25 ` Tom Rini
2020-05-25 8:31 ` Jagan Teki
0 siblings, 1 reply; 20+ messages in thread
From: Tom Rini @ 2020-05-22 21:25 UTC (permalink / raw)
To: u-boot
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.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200522/4c67de72/attachment.sig>
^ permalink raw reply [flat|nested] 20+ messages in thread* [PATCH v2 1/9] spl: Try to get SPL boot device via board_get_int
2020-05-22 21:25 ` Tom Rini
@ 2020-05-25 8:31 ` Jagan Teki
2020-05-25 13:15 ` Tom Rini
0 siblings, 1 reply; 20+ messages in thread
From: Jagan Teki @ 2020-05-25 8:31 UTC (permalink / raw)
To: u-boot
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.
Jagan.
^ permalink raw reply [flat|nested] 20+ messages in thread* [PATCH v2 1/9] spl: Try to get SPL boot device via board_get_int
2020-05-25 8:31 ` Jagan Teki
@ 2020-05-25 13:15 ` Tom Rini
0 siblings, 0 replies; 20+ messages in thread
From: Tom Rini @ 2020-05-25 13:15 UTC (permalink / raw)
To: u-boot
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!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200525/835a584c/attachment.sig>
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH v2 2/9] dt-bindings: board: Document sifive,fu540-modeselect
2020-05-19 19:23 [PATCH v2 0/9] riscv: sifive/fu540: Booting from SPI Jagan Teki
2020-05-19 19:23 ` [PATCH v2 1/9] spl: Try to get SPL boot device via board_get_int Jagan Teki
@ 2020-05-19 19:23 ` Jagan Teki
2020-05-20 13:13 ` [PATCH v2 2/9] dt-bindings: board: Document sifive, fu540-modeselect Bin Meng
2020-05-19 19:23 ` [PATCH v2 3/9] riscv: dts: fu540-c000-u-boot: Add " Jagan Teki
` (7 subsequent siblings)
9 siblings, 1 reply; 20+ messages in thread
From: Jagan Teki @ 2020-05-19 19:23 UTC (permalink / raw)
To: u-boot
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 at 1000 {
+ compatible = "sifive,fu540-modeselect";
+ reg = <0x0 0x1000 0x0 0x1FFF>;
+};
--
2.20.1
^ permalink raw reply related [flat|nested] 20+ messages in thread* [PATCH v2 2/9] dt-bindings: board: Document sifive, fu540-modeselect
2020-05-19 19:23 ` [PATCH v2 2/9] dt-bindings: board: Document sifive,fu540-modeselect Jagan Teki
@ 2020-05-20 13:13 ` Bin Meng
0 siblings, 0 replies; 20+ messages in thread
From: Bin Meng @ 2020-05-20 13:13 UTC (permalink / raw)
To: u-boot
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 at 1000 {
> + compatible = "sifive,fu540-modeselect";
> + reg = <0x0 0x1000 0x0 0x1FFF>;
We should only map 4 bytes for mode select.
> +};
> --
Regards,
Bin
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH v2 3/9] riscv: dts: fu540-c000-u-boot: Add sifive, fu540-modeselect
2020-05-19 19:23 [PATCH v2 0/9] riscv: sifive/fu540: Booting from SPI Jagan Teki
2020-05-19 19:23 ` [PATCH v2 1/9] spl: Try to get SPL boot device via board_get_int Jagan Teki
2020-05-19 19:23 ` [PATCH v2 2/9] dt-bindings: board: Document sifive,fu540-modeselect Jagan Teki
@ 2020-05-19 19:23 ` Jagan Teki
2020-05-19 19:23 ` [PATCH v2 4/9] drivers: Add fu540 board driver Jagan Teki
` (6 subsequent siblings)
9 siblings, 0 replies; 20+ messages in thread
From: Jagan Teki @ 2020-05-19 19:23 UTC (permalink / raw)
To: u-boot
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 at 1000 {
+ compatible = "sifive,fu540-modeselect";
+ reg = <0x0 0x1000 0x0 0x1FFF>;
+ u-boot,dm-spl;
+ };
+
otp: otp at 10070000 {
compatible = "sifive,fu540-c000-otp";
reg = <0x0 0x10070000 0x0 0x0FFF>;
--
2.20.1
^ permalink raw reply related [flat|nested] 20+ messages in thread* [PATCH v2 4/9] drivers: Add fu540 board driver
2020-05-19 19:23 [PATCH v2 0/9] riscv: sifive/fu540: Booting from SPI Jagan Teki
` (2 preceding siblings ...)
2020-05-19 19:23 ` [PATCH v2 3/9] riscv: dts: fu540-c000-u-boot: Add " Jagan Teki
@ 2020-05-19 19:23 ` Jagan Teki
2020-05-19 19:23 ` [PATCH v2 5/9] sifive: fu540: Add Booting from SPI Jagan Teki
` (5 subsequent siblings)
9 siblings, 0 replies; 20+ messages in thread
From: Jagan Teki @ 2020-05-19 19:23 UTC (permalink / raw)
To: u-boot
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 at 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,
+};
--
2.20.1
^ permalink raw reply related [flat|nested] 20+ messages in thread* [PATCH v2 5/9] sifive: fu540: Add Booting from SPI
2020-05-19 19:23 [PATCH v2 0/9] riscv: sifive/fu540: Booting from SPI Jagan Teki
` (3 preceding siblings ...)
2020-05-19 19:23 ` [PATCH v2 4/9] drivers: Add fu540 board driver Jagan Teki
@ 2020-05-19 19:23 ` Jagan Teki
2020-05-19 19:23 ` [PATCH v2 6/9] env: Enable SPI flash env for SiFive FU540 Jagan Teki
` (4 subsequent siblings)
9 siblings, 0 replies; 20+ messages in thread
From: Jagan Teki @ 2020-05-19 19:23 UTC (permalink / raw)
To: u-boot
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 at 10050000:mmc at 0: 0
In: serial at 10010000
Out: serial at 10010000
Err: serial at 10010000
Net: eth0: ethernet at 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 at 0 {
+ u-boot,dm-spl;
+ };
+};
+
&qspi2 {
mmc at 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
--
2.20.1
^ permalink raw reply related [flat|nested] 20+ messages in thread* [PATCH v2 6/9] env: Enable SPI flash env for SiFive FU540
2020-05-19 19:23 [PATCH v2 0/9] riscv: sifive/fu540: Booting from SPI Jagan Teki
` (4 preceding siblings ...)
2020-05-19 19:23 ` [PATCH v2 5/9] sifive: fu540: Add Booting from SPI Jagan Teki
@ 2020-05-19 19:23 ` Jagan Teki
2020-05-19 19:23 ` [PATCH v2 7/9] sifive: fu540: Mark the default env as SPI flash Jagan Teki
` (3 subsequent siblings)
9 siblings, 0 replies; 20+ messages in thread
From: Jagan Teki @ 2020-05-19 19:23 UTC (permalink / raw)
To: u-boot
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
--
2.20.1
^ permalink raw reply related [flat|nested] 20+ messages in thread* [PATCH v2 7/9] sifive: fu540: Mark the default env as SPI flash
2020-05-19 19:23 [PATCH v2 0/9] riscv: sifive/fu540: Booting from SPI Jagan Teki
` (5 preceding siblings ...)
2020-05-19 19:23 ` [PATCH v2 6/9] env: Enable SPI flash env for SiFive FU540 Jagan Teki
@ 2020-05-19 19:23 ` Jagan Teki
2020-05-19 19:23 ` [PATCH v2 8/9] sifive: fu540: Add boot flash script offset, size Jagan Teki
` (2 subsequent siblings)
9 siblings, 0 replies; 20+ messages in thread
From: Jagan Teki @ 2020-05-19 19:23 UTC (permalink / raw)
To: u-boot
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
--
2.20.1
^ permalink raw reply related [flat|nested] 20+ messages in thread* [PATCH v2 8/9] sifive: fu540: Add boot flash script offset, size
2020-05-19 19:23 [PATCH v2 0/9] riscv: sifive/fu540: Booting from SPI Jagan Teki
` (6 preceding siblings ...)
2020-05-19 19:23 ` [PATCH v2 7/9] sifive: fu540: Mark the default env as SPI flash Jagan Teki
@ 2020-05-19 19:23 ` Jagan Teki
2020-05-19 19:23 ` [PATCH v2 9/9] sifive: fu540: Enable SF distro bootcmd Jagan Teki
2020-05-25 2:10 ` [PATCH v2 0/9] riscv: sifive/fu540: Booting from SPI Bin Meng
9 siblings, 0 replies; 20+ messages in thread
From: Jagan Teki @ 2020-05-19 19:23 UTC (permalink / raw)
To: u-boot
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" \
--
2.20.1
^ permalink raw reply related [flat|nested] 20+ messages in thread* [PATCH v2 9/9] sifive: fu540: Enable SF distro bootcmd
2020-05-19 19:23 [PATCH v2 0/9] riscv: sifive/fu540: Booting from SPI Jagan Teki
` (7 preceding siblings ...)
2020-05-19 19:23 ` [PATCH v2 8/9] sifive: fu540: Add boot flash script offset, size Jagan Teki
@ 2020-05-19 19:23 ` Jagan Teki
2020-05-25 2:10 ` [PATCH v2 0/9] riscv: sifive/fu540: Booting from SPI Bin Meng
9 siblings, 0 replies; 20+ messages in thread
From: Jagan Teki @ 2020-05-19 19:23 UTC (permalink / raw)
To: u-boot
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};" \
--
2.20.1
^ permalink raw reply related [flat|nested] 20+ messages in thread* [PATCH v2 0/9] riscv: sifive/fu540: Booting from SPI
2020-05-19 19:23 [PATCH v2 0/9] riscv: sifive/fu540: Booting from SPI Jagan Teki
` (8 preceding siblings ...)
2020-05-19 19:23 ` [PATCH v2 9/9] sifive: fu540: Enable SF distro bootcmd Jagan Teki
@ 2020-05-25 2:10 ` Bin Meng
2020-05-25 2:27 ` Bin Meng
9 siblings, 1 reply; 20+ messages in thread
From: Bin Meng @ 2020-05-25 2:10 UTC (permalink / raw)
To: u-boot
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-jagan at amarulasolutions.com/
>
> 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
^ permalink raw reply [flat|nested] 20+ messages in thread* [PATCH v2 0/9] riscv: sifive/fu540: Booting from SPI
2020-05-25 2:10 ` [PATCH v2 0/9] riscv: sifive/fu540: Booting from SPI Bin Meng
@ 2020-05-25 2:27 ` Bin Meng
0 siblings, 0 replies; 20+ messages in thread
From: Bin Meng @ 2020-05-25 2:27 UTC (permalink / raw)
To: u-boot
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-jagan at amarulasolutions.com/
> >
> > 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
^ permalink raw reply related [flat|nested] 20+ messages in thread