| Message ID | 1464340402-2249-9-git-send-email-maxime.ripard@free-electrons.com |
|---|---|
| State | Accepted |
| Delegated to: | Pantelis Antoniou |
| Headers | show |
Hi Maxime, On 27 May 2016 at 03:13, Maxime Ripard <maxime.ripard@free-electrons.com> wrote: > The device tree overlays are a good way to deal with user-modifyable nit: modifiable > boards or boards with some kind of an expansion mechanism where we can > easily plug new board in (like the BBB or the raspberry pi). > > However, so far, the usual mechanism to deal with it was to have in Linux > some driver detecting the expansion boards plugged in and then request > these overlays using the firmware interface. > > That works in most cases, but in some cases, you might want to have the > overlays applied before the userspace comes in. Either because the new > board requires some kind of an early initialization, or because your root > filesystem is accessed through that expansion board. > > The easiest solution in such a case is to simply have the component before > Linux applying that overlay, removing all these drawbacks. > > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> > --- > cmd/fdt.c | 20 ++++++++++++++++++++ > 1 file changed, 20 insertions(+) Acked-by: Simon Glass <sjg@chromium.org>
On 2016-05-27 02:13, Maxime Ripard wrote: > The device tree overlays are a good way to deal with user-modifyable > boards or boards with some kind of an expansion mechanism where we can > easily plug new board in (like the BBB or the raspberry pi). > > However, so far, the usual mechanism to deal with it was to have in Linux > some driver detecting the expansion boards plugged in and then request > these overlays using the firmware interface. > > That works in most cases, but in some cases, you might want to have the > overlays applied before the userspace comes in. Either because the new > board requires some kind of an early initialization, or because your root > filesystem is accessed through that expansion board. > > The easiest solution in such a case is to simply have the component before > Linux applying that overlay, removing all these drawbacks. > > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> > --- > cmd/fdt.c | 20 ++++++++++++++++++++ > 1 file changed, 20 insertions(+) Reviewed-by: Stefan Agner <stefan@agner.ch> > > diff --git a/cmd/fdt.c b/cmd/fdt.c > index 0f5923e75a41..6cbc9e525d6c 100644 > --- a/cmd/fdt.c > +++ b/cmd/fdt.c > @@ -639,6 +639,25 @@ static int do_fdt(cmd_tbl_t *cmdtp, int flag, int > argc, char * const argv[]) > #endif > > } > + /* apply an overlay */ > + else if (strncmp(argv[1], "ap", 2) == 0) { > + unsigned long addr; > + struct fdt_header *blob; > + > + if (argc != 3) > + return CMD_RET_USAGE; > + > + if (!working_fdt) > + return CMD_RET_FAILURE; > + > + addr = simple_strtoul(argv[2], NULL, 16); > + blob = map_sysmem(addr, 0); > + if (!fdt_valid(&blob)) > + return CMD_RET_FAILURE; > + > + if (fdt_overlay_apply(working_fdt, blob)) > + return CMD_RET_FAILURE; > + } > /* resize the fdt */ > else if (strncmp(argv[1], "re", 2) == 0) { > fdt_shrink_to_minimum(working_fdt); > @@ -1025,6 +1044,7 @@ static int fdt_print(const char *pathp, char > *prop, int depth) > #ifdef CONFIG_SYS_LONGHELP > static char fdt_help_text[] = > "addr [-c] <addr> [<length>] - Set the [control] fdt location to <addr>\n" > + "fdt apply <addr> - Apply overlay to the DT\n" > #ifdef CONFIG_OF_BOARD_SETUP > "fdt boardsetup - Do board-specific set up\n" > #endif
> On May 27, 2016, at 12:13 , Maxime Ripard <maxime.ripard@free-electrons.com> wrote: > > The device tree overlays are a good way to deal with user-modifyable > boards or boards with some kind of an expansion mechanism where we can > easily plug new board in (like the BBB or the raspberry pi). > > However, so far, the usual mechanism to deal with it was to have in Linux > some driver detecting the expansion boards plugged in and then request > these overlays using the firmware interface. > > That works in most cases, but in some cases, you might want to have the > overlays applied before the userspace comes in. Either because the new > board requires some kind of an early initialization, or because your root > filesystem is accessed through that expansion board. > > The easiest solution in such a case is to simply have the component before > Linux applying that overlay, removing all these drawbacks. > > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> > --- > cmd/fdt.c | 20 ++++++++++++++++++++ > 1 file changed, 20 insertions(+) > > diff --git a/cmd/fdt.c b/cmd/fdt.c > index 0f5923e75a41..6cbc9e525d6c 100644 > --- a/cmd/fdt.c > +++ b/cmd/fdt.c > @@ -639,6 +639,25 @@ static int do_fdt(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) > #endif > > } > + /* apply an overlay */ > + else if (strncmp(argv[1], "ap", 2) == 0) { > + unsigned long addr; > + struct fdt_header *blob; > + > + if (argc != 3) > + return CMD_RET_USAGE; > + > + if (!working_fdt) > + return CMD_RET_FAILURE; > + > + addr = simple_strtoul(argv[2], NULL, 16); > + blob = map_sysmem(addr, 0); > + if (!fdt_valid(&blob)) > + return CMD_RET_FAILURE; > + > + if (fdt_overlay_apply(working_fdt, blob)) > + return CMD_RET_FAILURE; > + } > /* resize the fdt */ > else if (strncmp(argv[1], "re", 2) == 0) { > fdt_shrink_to_minimum(working_fdt); > @@ -1025,6 +1044,7 @@ static int fdt_print(const char *pathp, char *prop, int depth) > #ifdef CONFIG_SYS_LONGHELP > static char fdt_help_text[] = > "addr [-c] <addr> [<length>] - Set the [control] fdt location to <addr>\n" > + "fdt apply <addr> - Apply overlay to the DT\n" > #ifdef CONFIG_OF_BOARD_SETUP > "fdt boardsetup - Do board-specific set up\n" > #endif > -- > 2.8.2 > Acked-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
diff --git a/cmd/fdt.c b/cmd/fdt.c index 0f5923e75a41..6cbc9e525d6c 100644 --- a/cmd/fdt.c +++ b/cmd/fdt.c @@ -639,6 +639,25 @@ static int do_fdt(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) #endif } + /* apply an overlay */ + else if (strncmp(argv[1], "ap", 2) == 0) { + unsigned long addr; + struct fdt_header *blob; + + if (argc != 3) + return CMD_RET_USAGE; + + if (!working_fdt) + return CMD_RET_FAILURE; + + addr = simple_strtoul(argv[2], NULL, 16); + blob = map_sysmem(addr, 0); + if (!fdt_valid(&blob)) + return CMD_RET_FAILURE; + + if (fdt_overlay_apply(working_fdt, blob)) + return CMD_RET_FAILURE; + } /* resize the fdt */ else if (strncmp(argv[1], "re", 2) == 0) { fdt_shrink_to_minimum(working_fdt); @@ -1025,6 +1044,7 @@ static int fdt_print(const char *pathp, char *prop, int depth) #ifdef CONFIG_SYS_LONGHELP static char fdt_help_text[] = "addr [-c] <addr> [<length>] - Set the [control] fdt location to <addr>\n" + "fdt apply <addr> - Apply overlay to the DT\n" #ifdef CONFIG_OF_BOARD_SETUP "fdt boardsetup - Do board-specific set up\n" #endif
The device tree overlays are a good way to deal with user-modifyable boards or boards with some kind of an expansion mechanism where we can easily plug new board in (like the BBB or the raspberry pi). However, so far, the usual mechanism to deal with it was to have in Linux some driver detecting the expansion boards plugged in and then request these overlays using the firmware interface. That works in most cases, but in some cases, you might want to have the overlays applied before the userspace comes in. Either because the new board requires some kind of an early initialization, or because your root filesystem is accessed through that expansion board. The easiest solution in such a case is to simply have the component before Linux applying that overlay, removing all these drawbacks. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> --- cmd/fdt.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+)