Re: [PATCH 08/14] fastboot: Remove dependencies on CMDLINE
On Mon, Dec 4, 2023 at 1:31 AM Simon Glass wrote:
>
> It is possible to boot a kernel without CMDLINE being enabled. Update
> the implementation to handle this, and drop the condition from the
> FASTBOOT config.
>
> Signed-off-by: Simon Glass
> ---
>
> drivers/fastboot/Kconfig | 1 -
> drivers/fastboot/fb_common.c | 26 --
> 2 files changed, 12 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/fastboot/Kconfig b/drivers/fastboot/Kconfig
> index 11fc0fe1c800..837c6f1180da 100644
> --- a/drivers/fastboot/Kconfig
> +++ b/drivers/fastboot/Kconfig
> @@ -1,5 +1,4 @@
> menu "Fastboot support"
> - depends on CMDLINE
>
> config FASTBOOT
> bool
> diff --git a/drivers/fastboot/fb_common.c b/drivers/fastboot/fb_common.c
> index 07f5946d9ed1..85935380e79d 100644
> --- a/drivers/fastboot/fb_common.c
> +++ b/drivers/fastboot/fb_common.c
> @@ -11,6 +11,7 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> @@ -144,20 +145,17 @@ void fastboot_boot(void)
> {
> char *s;
>
> - s = env_get("fastboot_bootcmd");
> - if (s) {
> - run_command(s, CMD_FLAG_ENV);
> - } else if (IS_ENABLED(CONFIG_CMD_BOOTM)) {
> - static char boot_addr_start[20];
> - static char *const bootm_args[] = {
> - "bootm", boot_addr_start, NULL
> - };
> -
> - snprintf(boot_addr_start, sizeof(boot_addr_start) - 1,
> -"%lx", fastboot_buf_addr);
> - printf("Booting kernel at %s...\n\n\n", boot_addr_start);
> -
> - do_bootm(NULL, 0, 2, bootm_args);
> + if (IS_ENABLED(CONFIG_CMDLINE)) {
> + s = env_get("fastboot_bootcmd");
> + if (s) {
> + run_command(s, CMD_FLAG_ENV);
> + return;
> + }
> + } else if (IS_ENABLED(CONFIG_BOOTM)) {
> + int ret;
> +
> + printf("Booting kernel at %lx...\n\n\n", fastboot_buf_addr);
> + ret = bootm_boot_start(fastboot_buf_addr, NULL);
>
> /*
> * This only happens if image is somehow faulty so we start
> --
Doesn't this change the logic? Previously if you didn't set
fastboot_bootcmd you'd fall into the bootm path (if CONFIG_BOOTM was
enabled), with this, if CONFIG_CMDLINE is enabled then you will never
hit the bootm path.
--
Alex Kiernan
Re: [BISECTED] BeagleBone Black doesn't boot after a58147c2dbbf
On Thu, Aug 11, 2022 at 1:46 PM Tom Rini wrote: > > On Thu, Aug 11, 2022 at 10:47:18AM +0300, Matwey V. Kornilov wrote: > > > Can somebody please advise me working CONFIG_DEBUG_UART _* values for > > the board? I think I need to obtain some output from the board to > > debug it further. > > Reading arch/arm/dts/am33xx-l4.dtsi isn't as easy to read as I would > personally like but 0x44e09000 is UART0 and so forth. Updating > doc/board/ti/am335x_evm.rst once you're done with a note about using > DEBUG_UART would be appreciated, thanks. > Some notes I have from a previous life which may be useful, but I'm afraid I've no way of checking these days: * CONFIG_DEBUG_UART=y * CONFIG_DEBUG_UART_BASE=0x44e09000 * CONFIG_DEBUG_UART_CLOCK=4800 * CONFIG_DEBUG_UART_OMAP=y * CONFIG_DEBUG_UART_SHIFT=2 * CONFIG_DEBUG_UART_BOARD_INIT=y * CONFIG_DEBUG_UART_ANNOUNCE=y -- Alex Kiernan
Re: [PATCH] Revert "env: Warn on force access if ENV_ACCESS_IGNORE_FORCE set"
On Sat, Aug 29, 2020 at 6:51 PM Marek Vasut wrote:
>
> On 8/29/20 4:14 PM, Alex Kiernan wrote:
> > On Thu, Aug 27, 2020 at 5:20 PM Alex Kiernan wrote:
> >>
> >> On Thu, Aug 27, 2020 at 2:03 PM Tom Rini wrote:
> >>>
> >>> On Thu, Aug 27, 2020 at 11:49:25AM +0200, Marek Vasut wrote:
> >>>> On 8/27/20 11:43 AM, Alex Kiernan wrote:
> >>>>> This reverts commit 0f036bf4b87e6416f5c4d23865a62a62d9073c20.
> >>>>>
> >>>>> With this change applied and CONFIG_ENV_ACCESS_IGNORE_FORCE disabled,
> >>>>> the warning appears on every force overwrite, but the variable is then
> >>>>> written to:
> >>>>>
> >>>>> => env print ethaddr
> >>>>> ethaddr=00:1C:2B:08:AF:65
> >>>>> => env set ethaddr 00:00:00:00:00:00
> >>>>> ## Error: Can't overwrite "ethaddr"
> >>>>> ## Error inserting "ethaddr" variable, errno=1
> >>>>> => env print ethaddr
> >>>>> ethaddr=00:1C:2B:08:AF:65
> >>>>> => env set -f ethaddr 00:00:00:00:00:00
> >>>>> ## Error: Can't force access to "ethaddr"
> >>>>> => env print ethaddr
> >>>>> ethaddr=00:00:00:00:00:00
> >>>>>
> >>>>> Signed-off-by: Alex Kiernan
> >>>>> ---
> >>>>> As I noted in my email, I can't see an immediately obvious way to make
> >>>>> this work as intended and given we're at -rc3, I think a revert is the
> >>>>> most appropriate way forward.
> >>>>
> >>>> Can you please spend some more time on proper fix, instead of just
> >>>> reverting ? Reverting isn't the way forward most of the time.
> >>>
> >>> Can you assist in that? So far the original patch broke the EFI tests,
> >>> but Heinrich and I came up with a compromise (but it's also I suspect
> >>> that Alex saw). It is probably better to go back to the same behavior
> >>> as the last release and try again next release once the problem can be
> >>> addressed by someone.
> >>>
> >>
> >> I had another play with it and think I have something that'll work,
> >> though I leave my current job at the end of the week, so if it's not
> >> right I'm unlikely to be able to fix it.
> >>
> >
> > Sorry, I ran out of time... so it's highly unlikely I'll get to look
> > at this any time soon. Unfortunately I don't have access to that tree
> > anymore either.
>
> OK, so that means the work is now pushed on me. I will try to schedule
> this in the near future, because currently I am highly overloaded. Can
> you please at least share some information on what the approach you took
> was ?
Sure, it was something like this, completely untested though (and
pasting into gmail seems to insist on eating tabs):
diff --git a/env/flags.c b/env/flags.c
index df4aed26b2..a9d629c1fc 100644
--- a/env/flags.c
+++ b/env/flags.c
@@ -527,6 +527,7 @@ int env_flags_validate(const struct env_entry
*item, const char *newval,
{
const char *name;
const char *oldval = NULL;
+ bool ok;
if (op != env_op_create)
oldval = item->data;
@@ -563,23 +564,21 @@ int env_flags_validate(const struct env_entry
*item, const char *newval,
return 1;
#endif
-#ifndef CONFIG_ENV_ACCESS_IGNORE_FORCE
- if (flag & H_FORCE) {
- printf("## Error: Can't force access to \"%s\"\n", name);
+ if (!CONFIG_IS_ENABLED(ENV_ACCESS_IGNORE_FORCE) && (flag & H_FORCE))
return 0;
- }
-#endif
+
+ ok = true;
switch (op) {
case env_op_delete:
if (item->flags & ENV_FLAGS_VARACCESS_PREVENT_DELETE) {
printf("## Error: Can't delete \"%s\"\n", name);
- return 1;
+ ok = false;
}
break;
case env_op_overwrite:
if (item->flags & ENV_FLAGS_VARACCESS_PREVENT_OVERWR) {
printf("## Error: Can't overwrite \"%s\"\n", name);
- return 1;
+ ok = false;
} else if (item->flags &
ENV_FLAGS_VARACCESS_PREVENT_NONDEF_OVERWR) {
const char *defval = env_get_default(name);
@@ -590,19 +589,22 @@ int env_flags_validate(const struct env_entry
*item, const char *newval,
if (strcmp(oldval, defval) != 0) {
printf("## Error: Can't overwrite \"%s\"\n",
name);
- return 1;
+ ok = false;
}
}
break;
case env_op_create:
if (item->flags & ENV_FLAGS_VARACCESS_PREVENT_CREATE) {
printf("## Error: Can't create \"%s\"\n", name);
- return 1;
+ ok = false;
}
break;
}
- return 0;
+ if (!ok)
+ printf("## Error: Can't force access to \"%s\"\n", name);
+
+ return ok ? 0 : 1;
}
#endif
--
Alex Kiernan
Re: [PATCH] Revert "env: Warn on force access if ENV_ACCESS_IGNORE_FORCE set"
On Thu, Aug 27, 2020 at 5:20 PM Alex Kiernan wrote: > > On Thu, Aug 27, 2020 at 2:03 PM Tom Rini wrote: > > > > On Thu, Aug 27, 2020 at 11:49:25AM +0200, Marek Vasut wrote: > > > On 8/27/20 11:43 AM, Alex Kiernan wrote: > > > > This reverts commit 0f036bf4b87e6416f5c4d23865a62a62d9073c20. > > > > > > > > With this change applied and CONFIG_ENV_ACCESS_IGNORE_FORCE disabled, > > > > the warning appears on every force overwrite, but the variable is then > > > > written to: > > > > > > > > => env print ethaddr > > > > ethaddr=00:1C:2B:08:AF:65 > > > > => env set ethaddr 00:00:00:00:00:00 > > > > ## Error: Can't overwrite "ethaddr" > > > > ## Error inserting "ethaddr" variable, errno=1 > > > > => env print ethaddr > > > > ethaddr=00:1C:2B:08:AF:65 > > > > => env set -f ethaddr 00:00:00:00:00:00 > > > > ## Error: Can't force access to "ethaddr" > > > > => env print ethaddr > > > > ethaddr=00:00:00:00:00:00 > > > > > > > > Signed-off-by: Alex Kiernan > > > > --- > > > > As I noted in my email, I can't see an immediately obvious way to make > > > > this work as intended and given we're at -rc3, I think a revert is the > > > > most appropriate way forward. > > > > > > Can you please spend some more time on proper fix, instead of just > > > reverting ? Reverting isn't the way forward most of the time. > > > > Can you assist in that? So far the original patch broke the EFI tests, > > but Heinrich and I came up with a compromise (but it's also I suspect > > that Alex saw). It is probably better to go back to the same behavior > > as the last release and try again next release once the problem can be > > addressed by someone. > > > > I had another play with it and think I have something that'll work, > though I leave my current job at the end of the week, so if it's not > right I'm unlikely to be able to fix it. > Sorry, I ran out of time... so it's highly unlikely I'll get to look at this any time soon. Unfortunately I don't have access to that tree anymore either. -- Alex Kiernan
Re: [PATCH] Revert "env: Warn on force access if ENV_ACCESS_IGNORE_FORCE set"
On Thu, Aug 27, 2020 at 2:03 PM Tom Rini wrote: > > On Thu, Aug 27, 2020 at 11:49:25AM +0200, Marek Vasut wrote: > > On 8/27/20 11:43 AM, Alex Kiernan wrote: > > > This reverts commit 0f036bf4b87e6416f5c4d23865a62a62d9073c20. > > > > > > With this change applied and CONFIG_ENV_ACCESS_IGNORE_FORCE disabled, > > > the warning appears on every force overwrite, but the variable is then > > > written to: > > > > > > => env print ethaddr > > > ethaddr=00:1C:2B:08:AF:65 > > > => env set ethaddr 00:00:00:00:00:00 > > > ## Error: Can't overwrite "ethaddr" > > > ## Error inserting "ethaddr" variable, errno=1 > > > => env print ethaddr > > > ethaddr=00:1C:2B:08:AF:65 > > > => env set -f ethaddr 00:00:00:00:00:00 > > > ## Error: Can't force access to "ethaddr" > > > => env print ethaddr > > > ethaddr=00:00:00:00:00:00 > > > > > > Signed-off-by: Alex Kiernan > > > --- > > > As I noted in my email, I can't see an immediately obvious way to make > > > this work as intended and given we're at -rc3, I think a revert is the > > > most appropriate way forward. > > > > Can you please spend some more time on proper fix, instead of just > > reverting ? Reverting isn't the way forward most of the time. > > Can you assist in that? So far the original patch broke the EFI tests, > but Heinrich and I came up with a compromise (but it's also I suspect > that Alex saw). It is probably better to go back to the same behavior > as the last release and try again next release once the problem can be > addressed by someone. > I had another play with it and think I have something that'll work, though I leave my current job at the end of the week, so if it's not right I'm unlikely to be able to fix it. That said, I think there's something which has changed because I now need force in order to set things like ethaddr in a boot script (where it's already been set in the board code) whereas I didn't before. -- Alex Kiernan
[PATCH] Revert "env: Warn on force access if ENV_ACCESS_IGNORE_FORCE set"
This reverts commit 0f036bf4b87e6416f5c4d23865a62a62d9073c20.
With this change applied and CONFIG_ENV_ACCESS_IGNORE_FORCE disabled,
the warning appears on every force overwrite, but the variable is then
written to:
=> env print ethaddr
ethaddr=00:1C:2B:08:AF:65
=> env set ethaddr 00:00:00:00:00:00
## Error: Can't overwrite "ethaddr"
## Error inserting "ethaddr" variable, errno=1
=> env print ethaddr
ethaddr=00:1C:2B:08:AF:65
=> env set -f ethaddr 00:00:00:00:00:00
## Error: Can't force access to "ethaddr"
=> env print ethaddr
ethaddr=00:00:00:00:00:00
Signed-off-by: Alex Kiernan
---
As I noted in my email, I can't see an immediately obvious way to make
this work as intended and given we're at -rc3, I think a revert is the
most appropriate way forward.
env/flags.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/env/flags.c b/env/flags.c
index df4aed26b2c6..4a73c31670f4 100644
--- a/env/flags.c
+++ b/env/flags.c
@@ -564,10 +564,8 @@ int env_flags_validate(const struct env_entry *item, const
char *newval,
#endif
#ifndef CONFIG_ENV_ACCESS_IGNORE_FORCE
- if (flag & H_FORCE) {
- printf("## Error: Can't force access to \"%s\"\n", name);
+ if (flag & H_FORCE)
return 0;
- }
#endif
switch (op) {
case env_op_delete:
--
2.17.1
Re: [PATCH V2 1/7] env: Warn on force access if ENV_ACCESS_IGNORE_FORCE set
On Tue, Jul 7, 2020 at 7:52 PM Marek Vasut wrote:
>
> If the ENV_ACCESS_IGNORE_FORCE is set, inform user that the variable
> cannot be force-set if such attempt happens.
>
> Signed-off-by: Marek Vasut
> ---
> V2: No change
> ---
> env/flags.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/env/flags.c b/env/flags.c
> index b88fe7ba9c..f7a53775c4 100644
> --- a/env/flags.c
> +++ b/env/flags.c
> @@ -524,8 +524,10 @@ int env_flags_validate(const struct env_entry *item,
> const char *newval,
>
> /* check for access permission */
> #ifndef CONFIG_ENV_ACCESS_IGNORE_FORCE
> - if (flag & H_FORCE)
> + if (flag & H_FORCE) {
> + printf("## Error: Can't force access to \"%s\"\n", name);
> return 0;
> + }
> #endif
> switch (op) {
> case env_op_delete:
AFAICT this is wrong - you get the message when you have
CONFIG_ENV_ACCESS_IGNORE_FORCE disabled and use force:
=> env print ethaddr
ethaddr=00:1C:2B:08:AF:65
=> env set ethaddr 00:00:00:00:00:00
## Error: Can't overwrite "ethaddr"
## Error inserting "ethaddr" variable, errno=1
=> env print ethaddr
ethaddr=00:1C:2B:08:AF:65
=> env set -f ethaddr 00:00:00:00:00:00
## Error: Can't force access to "ethaddr"
=> env print ethaddr
ethaddr=00:00:00:00:00:00
Just staring at the code, I don't see a good way to capture this
behaviour, other than wiring it into each of the branches of the
switch - I started off with something like this:
diff --git a/env/flags.c b/env/flags.c
index df4aed26b2c6..70621dff4434 100644
--- a/env/flags.c
+++ b/env/flags.c
@@ -563,12 +563,13 @@ int env_flags_validate(const struct env_entry
*item, const char *newval,
return 1;
#endif
-#ifndef CONFIG_ENV_ACCESS_IGNORE_FORCE
if (flag & H_FORCE) {
- printf("## Error: Can't force access to \"%s\"\n", name);
- return 0;
+ if (CONFIG_IS_ENABLED(ENV_ACCESS_IGNORE_FORCE))
+ printf("## Error: Can't force access to
\"%s\"\n", name);
+ else
+ return 0;
}
-#endif
+
switch (op) {
case env_op_delete:
if (item->flags & ENV_FLAGS_VARACCESS_PREVENT_DELETE) {
But I think with that you'll get the message for variables which can
be overwritten, so still not what's intended.
--
Alex Kiernan
Re: [PATCH 1/1] fastboot: add support for 'reboot fastboot' command
On Mon, Jun 1, 2020 at 1:55 PM Roman Kovalivskyi
wrote:
>
> On 27.05.20 15:56, Alex Kiernan wrote:
>
> > On Wed, May 27, 2020 at 12:14 PM Roman Kovalivskyi
> > wrote:
> >> From: Roman Stratiienko
> >>
> >> Android 10 adds support for dynamic partitions and in order to support
> >> them userspace fastboot must be used[1]. New tool fastbootd is
> >> included into recovery image.
> >>
> >> Userspace fastboot works from recovery and is launched if:
> >> 1) - Dynamic partitioning is enabled
> >> 2) - Boot control block has 'boot-fastboot' value into command field
> >> The bootloader is expected to load and boot into the recovery image
> >> upon seeing boot-fastboot in the BCB command. Recovery then parses the
> >> BCB message and switches to fastbootd mode[2].
> >>
> >> Please note that boot script is expected to handle 'boot-fastboot'
> >> command in BCB and load into recovery mode.
> >>
> >> Bootloader must support 'reboot fastboot' command which should reboot
> >> device into userspace fastboot to accomodate those changes[3].
> >>
> >> [1] - https://source.android.com/devices/bootloader/fastbootd
> >> [2] -
> >> https://source.android.com/devices/bootloader/fastbootd#unified_fastboot_and_recovery
> >> [3] -
> >> https://source.android.com/devices/bootloader/fastbootd#modifications_to_the_bootloader
> >>
> >> Signed-off-by: Roman Kovalivskyi
> >> Signed-off-by: Roman Stratiienko
> >> Change-Id: I9d2bdc9a6f6f31ea98572fe155e1cc8341e9af76
> >> ---
> >> drivers/fastboot/fb_command.c | 42 +
> >> drivers/fastboot/fb_common.c| 31
> >> drivers/usb/gadget/f_fastboot.c | 2 ++
> >> include/fastboot.h | 9 +++
> >> 4 files changed, 84 insertions(+)
> >>
> >> diff --git a/drivers/fastboot/fb_command.c b/drivers/fastboot/fb_command.c
> >> index 49f6a61c3745..3616133b880e 100644
> >> --- a/drivers/fastboot/fb_command.c
> >> +++ b/drivers/fastboot/fb_command.c
> >> @@ -37,6 +37,8 @@ static void flash(char *, char *);
> >> static void erase(char *, char *);
> >> #endif
> >> static void reboot_bootloader(char *, char *);
> >> +static void reboot_fastbootd(char *, char *);
> >> +static void reboot_recovery(char *, char *);
> >> #if CONFIG_IS_ENABLED(FASTBOOT_CMD_OEM_FORMAT)
> >> static void oem_format(char *, char *);
> >> #endif
> >> @@ -79,6 +81,14 @@ static const struct {
> >> .command = "reboot-bootloader",
> >> .dispatch = reboot_bootloader
> >> },
> >> + [FASTBOOT_COMMAND_REBOOT_FASTBOOTD] = {
> >> + .command = "reboot-fastboot",
> >> + .dispatch = reboot_fastbootd
> >> + },
> >> + [FASTBOOT_COMMAND_REBOOT_RECOVERY] = {
> >> + .command = "reboot-recovery",
> >> + .dispatch = reboot_recovery
> >> + },
> >> [FASTBOOT_COMMAND_SET_ACTIVE] = {
> >> .command = "set_active",
> >> .dispatch = okay
> >> @@ -307,12 +317,44 @@ static void erase(char *cmd_parameter, char
> >> *response)
> >> */
> >> static void reboot_bootloader(char *cmd_parameter, char *response)
> >> {
> >> +#if CONFIG_IS_ENABLED(CMD_BCB)
> >> + if (fastboot_set_flag("bootonce-bootloader"))
> >> +#else
> >> if (fastboot_set_reboot_flag())
> >> +#endif
> >> fastboot_fail("Cannot set reboot flag", response);
> >> else
> >> fastboot_okay(NULL, response);
> >> }
> >>
> >> +/**
> >> + * reboot_fastbootd() - Sets reboot fastboot flag.
> >> + *
> >> + * @cmd_parameter: Pointer to command parameter
> >> + * @response: Pointer to fastboot response buffer
> >> + */
> >> +static void reboot_fastbootd(char *cmd_parameter, char *response)
> >> +{
> >> + if (fastboot_set_flag("boot-fastboot"))
> >> + fastboot_fail("Cannot set fastboot flag", response);
> >> + else
> >> + fastboot_okay(NULL, response);
> >> +}
> >> +
> >> +/**
> >> + * reboot_recovery() - Sets reboot recovery flag.
> >>
Re: [PATCH 1/1] fastboot: add support for 'reboot fastboot' command
s that we should reboot into the recovery
> + * following the reboot that fastboot executes after this function.
> + */
> +int fastboot_set_flag(const char *command)
> +{
> +#if CONFIG_IS_ENABLED(CMD_BCB)
> + char cmd[32];
> +
> + snprintf(cmd, sizeof(cmd), "bcb load %d misc",
> +CONFIG_FASTBOOT_FLASH_MMC_DEV);
> +
> + if (run_command(cmd, 0))
> + return -ENODEV;
> +
> + snprintf(cmd, sizeof(cmd), "bcb set command %s", command);
> +
> + if (run_command(cmd, 0))
> + return -ENOEXEC;
> +
> + if (run_command("bcb store", 0))
> + return -EIO;
> +
> + return 0;
I've not been keeping up with where fastboot has been going, but this
feels ugly in common code.
> +#else
> + return -ENOSYS;
> +#endif
> +}
> +
> /**
> * fastboot_get_progress_callback() - Return progress callback
> *
Should fastboot_set_flag/fastboot_set_reboot_flag be consolidated into
a single interface?
> diff --git a/drivers/usb/gadget/f_fastboot.c b/drivers/usb/gadget/f_fastboot.c
> index 384c0f6f6e27..30f7a52087fc 100644
> --- a/drivers/usb/gadget/f_fastboot.c
> +++ b/drivers/usb/gadget/f_fastboot.c
> @@ -455,6 +455,8 @@ static void rx_handler_command(struct usb_ep *ep, struct
> usb_request *req)
>
> case FASTBOOT_COMMAND_REBOOT:
> case FASTBOOT_COMMAND_REBOOT_BOOTLOADER:
> + case FASTBOOT_COMMAND_REBOOT_FASTBOOTD:
> + case FASTBOOT_COMMAND_REBOOT_RECOVERY:
> fastboot_func->in_req->complete = compl_do_reset;
> break;
> }
I expect you need a similar change in net/fastboot.c:fastboot_send (a
piece of ugliness I failed to abstract away when redoing this).
> diff --git a/include/fastboot.h b/include/fastboot.h
> index 1933b1d98e3b..8fd2a9e49d0f 100644
> --- a/include/fastboot.h
> +++ b/include/fastboot.h
> @@ -32,6 +32,8 @@ enum {
> FASTBOOT_COMMAND_CONTINUE,
> FASTBOOT_COMMAND_REBOOT,
> FASTBOOT_COMMAND_REBOOT_BOOTLOADER,
> + FASTBOOT_COMMAND_REBOOT_FASTBOOTD,
> + FASTBOOT_COMMAND_REBOOT_RECOVERY,
> FASTBOOT_COMMAND_SET_ACTIVE,
> #if CONFIG_IS_ENABLED(FASTBOOT_CMD_OEM_FORMAT)
> FASTBOOT_COMMAND_OEM_FORMAT,
> @@ -79,6 +81,13 @@ void fastboot_okay(const char *reason, char *response);
> */
> int fastboot_set_reboot_flag(void);
>
> +/**
> + * fastboot_set_flag() - Set flag to indicate reboot-fastboot
> + *
> + * Set flag which indicates that system should reboot into specified mode.
> + */
> +int fastboot_set_flag(const char *command);
> +
> /**
> * fastboot_set_progress_callback() - set progress callback
> *
> --
> 2.17.1
>
--
Alex Kiernan
Re: [PATCH V2] mkimage: fit: Do not tail-pad fitImage with external data
On Wed, May 6, 2020 at 3:41 PM Marek Vasut wrote: > > On 5/6/20 4:37 PM, Tom Rini wrote: > > On Wed, May 06, 2020 at 04:33:37PM +0200, Marek Vasut wrote: > >> On 5/6/20 4:27 PM, Tom Rini wrote: > >>> On Wed, May 06, 2020 at 04:17:35PM +0200, Marek Vasut wrote: > >>>> On 5/6/20 3:48 PM, Tom Rini wrote: > >>>>> On Tue, May 05, 2020 at 11:17:19PM +0200, Michael Walle wrote: > >>>>>> Hi all, > >>>>>> > >>>>>> Am 2020-05-05 20:41, schrieb Simon Glass: > >>>>>>> Hi Tom, > >>>>>>> > >>>>>>> On Tue, 5 May 2020 at 11:50, Tom Rini wrote: > >>>>>>>> > >>>>>>>> On Tue, May 05, 2020 at 06:39:58PM +0200, Marek Vasut wrote: > >>>>>>>>> On 5/5/20 6:37 PM, Alex Kiernan wrote: > >>>>>>>>>> On Tue, May 5, 2020 at 2:28 PM Marek Vasut wrote: > >>>>>>>>>>> > >>>>>>>>>>> On 5/5/20 3:22 PM, Alex Kiernan wrote: > >>>>>>>>>>>> On Mon, May 4, 2020 at 12:28 PM Tom Rini > >>>>>>>>>>>> wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>> On Fri, May 01, 2020 at 05:40:25PM +0200, Marek Vasut wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>>> There is no reason to tail-pad fitImage with external data to > >>>>>>>>>>>>>> 4-bytes, > >>>>>>>>>>>>>> while fitImage without external data does not have any such > >>>>>>>>>>>>>> padding and > >>>>>>>>>>>>>> is often unaligned. DT spec also does not mandate any such > >>>>>>>>>>>>>> padding. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Moreover, the tail-pad fills the last few bytes with > >>>>>>>>>>>>>> uninitialized data, > >>>>>>>>>>>>>> which could lead to a potential information leak. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> $ echo -n xy > /tmp/data ; \ > >>>>>>>>>>>>>> ./tools/mkimage -E -f auto -d /tmp/data /tmp/fitImage ; \ > >>>>>>>>>>>>>> hexdump -vC /tmp/fitImage | tail -n 3 > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> before: > >>>>>>>>>>>>>> 0260 61 2d 6f 66 66 73 65 74 00 64 61 74 61 2d 73 69 > >>>>>>>>>>>>>> |a-offset.data-si| > >>>>>>>>>>>>>> 0270 7a 65 00 00 78 79 64 64 > >>>>>>>>>>>>>> |ze..xydd| > >>>>>>>>>>>>>>^^ ^^ ^^ > >>>>>>>>>>>>>> after: > >>>>>>>>>>>>>> 0260 61 2d 6f 66 66 73 65 74 00 64 61 74 61 2d 73 69 > >>>>>>>>>>>>>> |a-offset.data-si| > >>>>>>>>>>>>>> 0270 7a 65 00 78 79 > >>>>>>>>>>>>>> |ze.xy| > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Signed-off-by: Marek Vasut > >>>>>>>>>>>>>> Reviewed-by: Simon Glass > >>>>>>>>>>>>>> Cc: Heinrich Schuchardt > >>>>>>>>>>>>>> Cc: Tom Rini > >>>>>>>>>>>>> > >>>>>>>>>>>>> Applied to u-boot/master, thanks! > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> This breaks booting on my board (am3352, eMMC boot, FIT u-boot, > >>>>>>>>>>>> CONFIG_SPL_LOAD_FIT). Not got any useful diagnostics - if I boot > >>>>>>>>>>>> it > &
Re: [PATCH V2] mkimage: fit: Do not tail-pad fitImage with external data
On Tue, May 5, 2020 at 7:41 PM Simon Glass wrote: > > Hi Tom, > > On Tue, 5 May 2020 at 11:50, Tom Rini wrote: > > > > On Tue, May 05, 2020 at 06:39:58PM +0200, Marek Vasut wrote: > > > On 5/5/20 6:37 PM, Alex Kiernan wrote: > > > > On Tue, May 5, 2020 at 2:28 PM Marek Vasut wrote: > > > >> > > > >> On 5/5/20 3:22 PM, Alex Kiernan wrote: > > > >>> On Mon, May 4, 2020 at 12:28 PM Tom Rini wrote: > > > >>>> > > > >>>> On Fri, May 01, 2020 at 05:40:25PM +0200, Marek Vasut wrote: > > > >>>> > > > >>>>> There is no reason to tail-pad fitImage with external data to > > > >>>>> 4-bytes, > > > >>>>> while fitImage without external data does not have any such padding > > > >>>>> and > > > >>>>> is often unaligned. DT spec also does not mandate any such padding. > > > >>>>> > > > >>>>> Moreover, the tail-pad fills the last few bytes with uninitialized > > > >>>>> data, > > > >>>>> which could lead to a potential information leak. > > > >>>>> > > > >>>>> $ echo -n xy > /tmp/data ; \ > > > >>>>> ./tools/mkimage -E -f auto -d /tmp/data /tmp/fitImage ; \ > > > >>>>> hexdump -vC /tmp/fitImage | tail -n 3 > > > >>>>> > > > >>>>> before: > > > >>>>> 0260 61 2d 6f 66 66 73 65 74 00 64 61 74 61 2d 73 69 > > > >>>>> |a-offset.data-si| > > > >>>>> 0270 7a 65 00 00 78 79 64 64 > > > >>>>> |ze..xydd| > > > >>>>>^^ ^^ ^^ > > > >>>>> after: > > > >>>>> 0260 61 2d 6f 66 66 73 65 74 00 64 61 74 61 2d 73 69 > > > >>>>> |a-offset.data-si| > > > >>>>> 0270 7a 65 00 78 79|ze.xy| > > > >>>>> > > > >>>>> Signed-off-by: Marek Vasut > > > >>>>> Reviewed-by: Simon Glass > > > >>>>> Cc: Heinrich Schuchardt > > > >>>>> Cc: Tom Rini > > > >>>> > > > >>>> Applied to u-boot/master, thanks! > > > >>>> > > > >>> > > > >>> This breaks booting on my board (am3352, eMMC boot, FIT u-boot, > > > >>> CONFIG_SPL_LOAD_FIT). Not got any useful diagnostics - if I boot it > > > >>> from eMMC I get nothing at all on the console, if I boot over ymodem > > > >>> it stalls at 420k, before continuing to 460k. My guess is there's some > > > >>> error going to the console at the 420k mark, but obviously it's lost > > > >>> in the ymodem... I have two DTBs in the FIT image, 420k would about > > > >>> align to the point between them. > > > >> > > > >> My bet would be on some padding / unaligned access problem that this > > > >> patch uncovered. Can you take a look ? > > > > > > > > Seems plausible. With this change my external data starts at 0x483 and > > > > everything after it is non-aligned: > > > > > > Should the beginning of external data be aligned ? > > > > If in U-Boot we revert e8c2d25845c72c7202a628a97d45e31beea40668 does the > > problem go away? If so, that's not a fix outright, it means we need to > > dig back in to the libfdt thread and find the "make this work without > > killing performance everywhere all the time" option. > > If it is a device tree, it must be 32-bit aligned. > > But Marek's patch affects the FIT image itself, so I am not sure what > would go after that. > Just reading the commit log, the example in there shows the padding after the FIT image being dropped: $ echo -n xy > /tmp/data ; \ ./tools/mkimage -E -f auto -d /tmp/data /tmp/fitImage ; \ hexdump -vC /tmp/fitImage | tail -n 3 before: 0260 61 2d 6f 66 66 73 65 74 00 64 61 74 61 2d 73 69 |a-offset.data-si| 0270 7a 65 00 00 78 79 64 64 |ze..xydd| ^^ ^^ ^^ after: 0260 61 2d 6f 66 66 73 65 74 00 64 61 74 61 2d 73 69 |a-offset.data-si| 0270 7a 65 00 78 79|ze.xy| Though I can't reproduce that result with or without the associated commit. -- Alex Kiernan
Re: [PATCH V2] mkimage: fit: Do not tail-pad fitImage with external data
On Tue, May 5, 2020 at 10:17 PM Michael Walle wrote: > > Hi all, > > Am 2020-05-05 20:41, schrieb Simon Glass: > > Hi Tom, > > > > On Tue, 5 May 2020 at 11:50, Tom Rini wrote: > >> > >> On Tue, May 05, 2020 at 06:39:58PM +0200, Marek Vasut wrote: > >> > On 5/5/20 6:37 PM, Alex Kiernan wrote: > >> > > On Tue, May 5, 2020 at 2:28 PM Marek Vasut wrote: > >> > >> > >> > >> On 5/5/20 3:22 PM, Alex Kiernan wrote: > >> > >>> On Mon, May 4, 2020 at 12:28 PM Tom Rini wrote: > >> > >>>> > >> > >>>> On Fri, May 01, 2020 at 05:40:25PM +0200, Marek Vasut wrote: > >> > >>>> > >> > >>>>> There is no reason to tail-pad fitImage with external data to > >> > >>>>> 4-bytes, > >> > >>>>> while fitImage without external data does not have any such > >> > >>>>> padding and > >> > >>>>> is often unaligned. DT spec also does not mandate any such padding. > >> > >>>>> > >> > >>>>> Moreover, the tail-pad fills the last few bytes with uninitialized > >> > >>>>> data, > >> > >>>>> which could lead to a potential information leak. > >> > >>>>> > >> > >>>>> $ echo -n xy > /tmp/data ; \ > >> > >>>>> ./tools/mkimage -E -f auto -d /tmp/data /tmp/fitImage ; \ > >> > >>>>> hexdump -vC /tmp/fitImage | tail -n 3 > >> > >>>>> > >> > >>>>> before: > >> > >>>>> 0260 61 2d 6f 66 66 73 65 74 00 64 61 74 61 2d 73 69 > >> > >>>>> |a-offset.data-si| > >> > >>>>> 0270 7a 65 00 00 78 79 64 64 > >> > >>>>> |ze..xydd| > >> > >>>>>^^ ^^ ^^ > >> > >>>>> after: > >> > >>>>> 0260 61 2d 6f 66 66 73 65 74 00 64 61 74 61 2d 73 69 > >> > >>>>> |a-offset.data-si| > >> > >>>>> 0270 7a 65 00 78 79|ze.xy| > >> > >>>>> > >> > >>>>> Signed-off-by: Marek Vasut > >> > >>>>> Reviewed-by: Simon Glass > >> > >>>>> Cc: Heinrich Schuchardt > >> > >>>>> Cc: Tom Rini > >> > >>>> > >> > >>>> Applied to u-boot/master, thanks! > >> > >>>> > >> > >>> > >> > >>> This breaks booting on my board (am3352, eMMC boot, FIT u-boot, > >> > >>> CONFIG_SPL_LOAD_FIT). Not got any useful diagnostics - if I boot it > >> > >>> from eMMC I get nothing at all on the console, if I boot over ymodem > >> > >>> it stalls at 420k, before continuing to 460k. My guess is there's > >> > >>> some > >> > >>> error going to the console at the 420k mark, but obviously it's lost > >> > >>> in the ymodem... I have two DTBs in the FIT image, 420k would about > >> > >>> align to the point between them. > >> > >> > >> > >> My bet would be on some padding / unaligned access problem that this > >> > >> patch uncovered. Can you take a look ? > >> > > > >> > > Seems plausible. With this change my external data starts at 0x483 and > >> > > everything after it is non-aligned: > >> > > >> > Should the beginning of external data be aligned ? > >> > >> If in U-Boot we revert e8c2d25845c72c7202a628a97d45e31beea40668 does > >> the > >> problem go away? If so, that's not a fix outright, it means we need > >> to > >> dig back in to the libfdt thread and find the "make this work without > >> killing performance everywhere all the time" option. > > > > If it is a device tree, it must be 32-bit aligned. > > This commit actually breaks my board too (which I was just about to send > upstream, but realized it was broken). > > Said board uses SPL and main U-Boot. SPL runs fine and main u-boot > doesn't > output anything. The only difference which I found is that fit-dtb.blob > is > 2 bytes shorter. And the content is shifted by one byte although > data-offset is the same. Strange. In the non-working case, the inner > FDT magic isn't 4 byte aligned. > > You can find the two fit-dtb.blobs here: > > https://walle.cc/u-boot/fit-dtb.blob.working > https://walle.cc/u-boot/fit-dtb.blob.non-working > > > Reverting e8c2d25845c72c7202a628a97d45e31beea40668 doesn't help (I might > reverted it the wrong way, there is actually a conflict). > I just did the same thing by manually extracting the patches and I agree, reverting that doesn't fix the problem. > I'll dig deeper into that tomorrow, but maybe you have some pointers > where > to look. > > For reference you can find the current patch here: > https://github.com/mwalle/u-boot/tree/sl28-upstream > > > > > But Marek's patch affects the FIT image itself, so I am not sure what > > would go after that. > > > > Regards, > > Simon > > -- > -michael -- Alex Kiernan
Re: [PATCH V2] mkimage: fit: Do not tail-pad fitImage with external data
On Tue, May 5, 2020 at 2:28 PM Marek Vasut wrote: > > On 5/5/20 3:22 PM, Alex Kiernan wrote: > > On Mon, May 4, 2020 at 12:28 PM Tom Rini wrote: > >> > >> On Fri, May 01, 2020 at 05:40:25PM +0200, Marek Vasut wrote: > >> > >>> There is no reason to tail-pad fitImage with external data to 4-bytes, > >>> while fitImage without external data does not have any such padding and > >>> is often unaligned. DT spec also does not mandate any such padding. > >>> > >>> Moreover, the tail-pad fills the last few bytes with uninitialized data, > >>> which could lead to a potential information leak. > >>> > >>> $ echo -n xy > /tmp/data ; \ > >>> ./tools/mkimage -E -f auto -d /tmp/data /tmp/fitImage ; \ > >>> hexdump -vC /tmp/fitImage | tail -n 3 > >>> > >>> before: > >>> 0260 61 2d 6f 66 66 73 65 74 00 64 61 74 61 2d 73 69 > >>> |a-offset.data-si| > >>> 0270 7a 65 00 00 78 79 64 64 |ze..xydd| > >>>^^ ^^ ^^ > >>> after: > >>> 0260 61 2d 6f 66 66 73 65 74 00 64 61 74 61 2d 73 69 > >>> |a-offset.data-si| > >>> 0270 7a 65 00 78 79|ze.xy| > >>> > >>> Signed-off-by: Marek Vasut > >>> Reviewed-by: Simon Glass > >>> Cc: Heinrich Schuchardt > >>> Cc: Tom Rini > >> > >> Applied to u-boot/master, thanks! > >> > > > > This breaks booting on my board (am3352, eMMC boot, FIT u-boot, > > CONFIG_SPL_LOAD_FIT). Not got any useful diagnostics - if I boot it > > from eMMC I get nothing at all on the console, if I boot over ymodem > > it stalls at 420k, before continuing to 460k. My guess is there's some > > error going to the console at the 420k mark, but obviously it's lost > > in the ymodem... I have two DTBs in the FIT image, 420k would about > > align to the point between them. > > My bet would be on some padding / unaligned access problem that this > patch uncovered. Can you take a look ? Seems plausible. With this change my external data starts at 0x483 and everything after it is non-aligned: /dts-v1/; // magic: 0xd00dfeed // totalsize: 0x483 (1155) // off_dt_struct: 0x38 // off_dt_strings: 0x3f8 // off_mem_rsvmap: 0x28 // version: 17 // last_comp_version: 2 // boot_cpuid_phys: 0x0 // size_dt_strings: 0x8b // size_dt_struct: 0x3c0 -- Alex Kiernan
Re: [PATCH V2] mkimage: fit: Do not tail-pad fitImage with external data
On Mon, May 4, 2020 at 12:28 PM Tom Rini wrote: > > On Fri, May 01, 2020 at 05:40:25PM +0200, Marek Vasut wrote: > > > There is no reason to tail-pad fitImage with external data to 4-bytes, > > while fitImage without external data does not have any such padding and > > is often unaligned. DT spec also does not mandate any such padding. > > > > Moreover, the tail-pad fills the last few bytes with uninitialized data, > > which could lead to a potential information leak. > > > > $ echo -n xy > /tmp/data ; \ > > ./tools/mkimage -E -f auto -d /tmp/data /tmp/fitImage ; \ > > hexdump -vC /tmp/fitImage | tail -n 3 > > > > before: > > 0260 61 2d 6f 66 66 73 65 74 00 64 61 74 61 2d 73 69 > > |a-offset.data-si| > > 0270 7a 65 00 00 78 79 64 64 |ze..xydd| > >^^ ^^ ^^ > > after: > > 0260 61 2d 6f 66 66 73 65 74 00 64 61 74 61 2d 73 69 > > |a-offset.data-si| > > 0270 7a 65 00 78 79|ze.xy| > > > > Signed-off-by: Marek Vasut > > Reviewed-by: Simon Glass > > Cc: Heinrich Schuchardt > > Cc: Tom Rini > > Applied to u-boot/master, thanks! > This breaks booting on my board (am3352, eMMC boot, FIT u-boot, CONFIG_SPL_LOAD_FIT). Not got any useful diagnostics - if I boot it from eMMC I get nothing at all on the console, if I boot over ymodem it stalls at 420k, before continuing to 460k. My guess is there's some error going to the console at the 420k mark, but obviously it's lost in the ymodem... I have two DTBs in the FIT image, 420k would about align to the point between them. -- Alex Kiernan
[PATCH v2] cmd: gpio: Make `gpio input` return pin value again
4dbc107f4683 ("cmd: gpio: Correct do_gpio() return value") correctly
changed the behaviour of the gpio command to return CMD_RET_SUCCESS or
CMD_RET_FAILURE, but any existing script which expects the return value
to be the pin value is broken by this change.
Reinstate the legacy behaviour for `gpio input` only.
Fixes: 4dbc107f4683 ("cmd: gpio: Correct do_gpio() return value")
Signed-off-by: Alex Kiernan
Signed-off-by: Alex Kiernan
Reviewed-by: Simon Glass
---
Changes in v2:
- add test
cmd/gpio.c | 7 ++-
test/py/tests/test_gpio.py | 37 +
2 files changed, 43 insertions(+), 1 deletion(-)
create mode 100644 test/py/tests/test_gpio.py
diff --git a/cmd/gpio.c b/cmd/gpio.c
index 16c2cebb3d4b..408a942455b5 100644
--- a/cmd/gpio.c
+++ b/cmd/gpio.c
@@ -248,7 +248,12 @@ static int do_gpio(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
if (ret != -EBUSY)
gpio_free(gpio);
- return CMD_RET_SUCCESS;
+ /*
+* Whilst wrong, the legacy gpio input command returns the pin
+* value, or CMD_RET_FAILURE (which is indistinguishable from a
+* valid pin value).
+*/
+ return (sub_cmd == GPIOC_INPUT) ? value : CMD_RET_SUCCESS;
err:
if (ret != -EBUSY)
diff --git a/test/py/tests/test_gpio.py b/test/py/tests/test_gpio.py
new file mode 100644
index ..8c64f686b0ba
--- /dev/null
+++ b/test/py/tests/test_gpio.py
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: GPL-2.0+
+
+import pytest
+
+@pytest.mark.boardspec('sandbox')
+@pytest.mark.buildconfigspec('cmd_gpio')
+def test_gpio_input(u_boot_console):
+"""Test that gpio input correctly returns the value of a gpio pin."""
+
+response = u_boot_console.run_command('gpio input 0; echo rc:$?')
+expected_response = 'rc:0'
+assert(expected_response in response)
+response = u_boot_console.run_command('gpio toggle 0; gpio input 0; echo
rc:$?')
+expected_response = 'rc:1'
+assert(expected_response in response)
+
+@pytest.mark.boardspec('sandbox')
+@pytest.mark.buildconfigspec('cmd_gpio')
+def test_gpio_exit_statuses(u_boot_console):
+"""Test that non-input gpio commands correctly return the command
+success/failure status."""
+
+expected_response = 'rc:0'
+response = u_boot_console.run_command('gpio clear 0; echo rc:$?')
+assert(expected_response in response)
+response = u_boot_console.run_command('gpio set 0; echo rc:$?')
+assert(expected_response in response)
+response = u_boot_console.run_command('gpio toggle 0; echo rc:$?')
+assert(expected_response in response)
+response = u_boot_console.run_command('gpio status -a; echo rc:$?')
+assert(expected_response in response)
+
+expected_response = 'rc:1'
+response = u_boot_console.run_command('gpio nonexistent-command; echo
rc:$?')
+assert(expected_response in response)
+response = u_boot_console.run_command('gpio input 200; echo rc:$?')
+assert(expected_response in response)
--
2.17.1
Re: [PATCH 1/1 v1] cmd: gpio: Correct do_gpio() return value
On Tue, Mar 10, 2020 at 12:37 PM Tom Rini wrote: > > On Tue, Mar 10, 2020 at 09:47:33AM +, Alex Kiernan wrote: > > On Sat, Feb 8, 2020 at 12:06 AM Tom Rini wrote: > > > > > > On Sun, Jan 05, 2020 at 08:10:56PM +0100, Luka Kovacic wrote: > > > > > > > Use the correct return value in function do_gpio() and update > > > > commands documentation with the return values from command_ret_t enum. > > > > > > > > CMD_RET_SUCCESS is returned on command success and CMD_RET_FAILURE is > > > > returned on command failure. > > > > > > > > The command was returning the pin value, which caused confusion when > > > > debugging (#define DEBUG). > > > > > > > > Signed-off-by: Luka Kovacic > > > > Tested-by: Robert Marko > > > > > > Applied to u-boot/master, thanks! > > > > > > > I just pulled in HEAD for a test build and our boot scripts are broken > > with this gpio change - I don't see a way to get the value of a gpio > > pin in a script now? > > > > Whilst I agree what's there was wrong, I'm really not sure we can > > change an existing interface like this. > > Sigh, this is what I was worried about. If folks don't have a > suggestion on how to correct things again I'm going to revert this > change, sorry for the noise, thanks! > There's a one-liner which fixes it for me (implementing the suggestion of retaining the behaviour for gpio input): https://patchwork.ozlabs.org/patch/1252077/ -- Alex Kiernan
[PATCH] cmd: gpio: Make `gpio input` return pin value again
4dbc107f4683 ("cmd: gpio: Correct do_gpio() return value") correctly
changed the behaviour of the gpio command to return CMD_RET_SUCCESS or
CMD_RET_FAILURE.
But any existing script which expects the return value to be the pin
value is broken by this change.
Reinstate the legacy behaviour for `gpio input` only.
Fixes: 4dbc107f4683 ("cmd: gpio: Correct do_gpio() return value")
Signed-off-by: Alex Kiernan
---
cmd/gpio.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/cmd/gpio.c b/cmd/gpio.c
index 16c2cebb3d4b..b716f6f18b95 100644
--- a/cmd/gpio.c
+++ b/cmd/gpio.c
@@ -248,7 +248,11 @@ static int do_gpio(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
if (ret != -EBUSY)
gpio_free(gpio);
- return CMD_RET_SUCCESS;
+ /*
+* Whilst wrong, the legacy gpio input command returns the pin value
+* (or CMD_RET_FAILURE)
+*/
+ return (sub_cmd == GPIOC_INPUT) ? value : CMD_RET_SUCCESS;
err:
if (ret != -EBUSY)
--
2.17.1
Re: [PATCH 1/1 v1] cmd: gpio: Correct do_gpio() return value
On Sat, Feb 8, 2020 at 12:06 AM Tom Rini wrote: > > On Sun, Jan 05, 2020 at 08:10:56PM +0100, Luka Kovacic wrote: > > > Use the correct return value in function do_gpio() and update > > commands documentation with the return values from command_ret_t enum. > > > > CMD_RET_SUCCESS is returned on command success and CMD_RET_FAILURE is > > returned on command failure. > > > > The command was returning the pin value, which caused confusion when > > debugging (#define DEBUG). > > > > Signed-off-by: Luka Kovacic > > Tested-by: Robert Marko > > Applied to u-boot/master, thanks! > I just pulled in HEAD for a test build and our boot scripts are broken with this gpio change - I don't see a way to get the value of a gpio pin in a script now? Whilst I agree what's there was wrong, I'm really not sure we can change an existing interface like this. -- Alex Kiernan
Re: [PATCH 2/3] tools: add fdt_add_pubkey
On Tue, Feb 11, 2020 at 10:22 AM Rasmus Villemoes wrote: > > On 11/02/2020 10.54, Alex Kiernan wrote: > > On Tue, Feb 11, 2020 at 9:49 AM Rasmus Villemoes > > wrote: > >> > >> Having to use the -K option to mkimage to populate U-Boot's .dtb with the > >> public key while signing the kernel FIT image is often a little > >> awkward. In particular, when using a meta-build system such as > >> bitbake/Yocto, having the tasks of the kernel and U-Boot recipes > >> intertwined, modifying deployed artifacts and rebuilding U-Boot with > >> an updated .dtb is quite cumbersome. Also, in some scenarios one may > >> wish to build U-Boot complete with the public key(s) embedded in the > >> .dtb without the corresponding private keys being present on the same > >> build host. > >> > > > > Have you started looking at the required bitbake pieces? You're > > definitely dealing with a piece of pain that I'd like resolved! > > Not really, but I know that something like this is a necessary first > part - and I'm glad to know I'm not the only one struggling with this. > > For now I've come to the conclusion that kernel-fitimage.bbclass is not > worth the trouble (for example, I need to create two different fit > images with different initramfs, but a fit image without initramfs is > pointless in my case, and there's no way to use kernel-fitimage.bbclass > for that), so I just set KERNEL_IMAGETYPE to vmlinux, then have my own > extra tasks doing the objcopy -O binary, gzip, and mkimage the different > fit images I need. > kernel-fitimage is a nightmare... every time someone touches it the risk of it breaking for someone else is pretty high. FWIW my flow through it is just kernel (no initramfs), DTBs and configurations, with keys pre-embedded in U-Boot, so avoiding the loop back through that otherwise happens. But I could do with the ability to compose configurations in it, which isn't easy with it today. I suspect leaving kernel-fitimage to one side and starting again (with tests) has a lot of merit! > [I'm also thinking that adding a companion tool for doing the signing > part might make sense at some point - it's somewhat counter-intuituve > that the .its contains some of the information (base name of key and > algorithm - mkimage currently just segfaults if key-name-hint is > accidentally omitted from the .its), while mkimage needs to be fed with > another part (directory holding the keys).] > > Rasmus -- Alex Kiernan
Re: [PATCH 2/3] tools: add fdt_add_pubkey
t; + keydest = argv[optind];
> +
> + if (!keydest)
> + usage("Missing dtb file to update");
> +}
> +
> +int main(int argc, char *argv[])
> +{
> + struct image_sign_info info;
> + int destfd, ret;
> + void *dest_blob = NULL;
> + struct stat dest_sbuf;
> + size_t size_inc = 0;
> +
> + cmdname = argv[0];
> +
> + process_args(argc, argv);
> +
> + memset(, 0, sizeof(info));
> +
> + info.keydir = keydir;
> + info.keyname = keyname;
> + info.name = algo_name;
> + info.require_keys = require_keys;
> + info.crypto = image_get_crypto_algo(algo_name);
> + if (!info.crypto) {
> +fprintf(stderr, "Unsupported signature algorithm '%s'\n",
> algo_name);
> + exit(EXIT_FAILURE);
> + }
> +
> + while (1) {
> + destfd = mmap_fdt(cmdname, keydest, size_inc, _blob,
> _sbuf, false, false);
> + if (destfd < 0)
> + exit(EXIT_FAILURE);
> +
> + ret = info.crypto->add_verify_data(, dest_blob);
> +
> + munmap(dest_blob, dest_sbuf.st_size);
> + close(destfd);
> + if (!ret || ret != -ENOSPC)
> + break;
> + fprintf(stderr, ".dtb too small, increasing size by 1024
> bytes\n");
> + size_inc = 1024;
> + }
> +
> + if (ret) {
> + fprintf(stderr, "%s: Cannot add public key to FIT blob: %s\n",
> + cmdname, strerror(-ret));
> + exit(EXIT_FAILURE);
> + }
> +
> + exit(EXIT_SUCCESS);
> +}
> --
> 2.23.0
>
--
Alex Kiernan
Re: [U-Boot] [PATCH] spl_mmc: always use find_mmc_device() to get mmc handler
On Thu, Jul 25, 2019 at 11:32 AM jason@rock-chips.com
wrote:
>
> Hi,
>
> We use the aliases to set the MMC device order. For example:
> mmc0 =
> mmc1 =
> These define the MMC order in block layer.
> But in the mmc layer, the MMC device order is defined in the dts MMC node.
> It may make mistake to get MMC device order. So if we use the block layer
> interface to
> access mmc devices, use find_mmc_device to get current devnum but not
> uclass_get_device.
>
I get a similar (same?) problem too (and will test this patch) - I've
got no MMC1 on an AM335x, so the initialisation makes MMC2 the first
device, which then leads me to this revolting hack in my board.c:
void board_boot_order(u32 *spl_boot_list)
{
u32 boot_device = spl_boot_device();
/*
* This is a filthy hack... we don't have MMC1, but the SPL boot
* code works based on device numbers, not sequence numbers, so
* we have to ensure that when we're booted from the eMMC we pick
* the right entry from the DT
*/
if (boot_device == BOOT_DEVICE_MMC2)
spl_boot_list[0] = BOOT_DEVICE_MMC1;
else
spl_boot_list[0] = boot_device;
}
--
Alex Kiernan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v6 1/5] driver: net: ti: cpsw-mdio: use phys_addr_t for mdio_base addr
On Tue, Jul 9, 2019 at 6:01 AM Keerthy wrote:
>
> Use phys_addr_t for mdio_base address to avoid build
> warnings on arm64 and dra7. Cast it to uintprt_t before
> assigning to regs.
>
> Signed-off-by: Grygorii Strashko
> Signed-off-by: Keerthy
> Reviewed-by: Tom Rini
> Acked-by: Joe Hershberger
> ---
>
> Changes in v6:
>
> * Added Joe's Ack.
>
> drivers/net/ti/cpsw_mdio.c | 4 ++--
> drivers/net/ti/cpsw_mdio.h | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ti/cpsw_mdio.c b/drivers/net/ti/cpsw_mdio.c
> index 70f547e6d7..6e8f652011 100644
> --- a/drivers/net/ti/cpsw_mdio.c
> +++ b/drivers/net/ti/cpsw_mdio.c
> @@ -125,7 +125,7 @@ u32 cpsw_mdio_get_alive(struct mii_dev *bus)
> return val & GENMASK(15, 0);
> }
>
> -struct mii_dev *cpsw_mdio_init(const char *name, u32 mdio_base,
> +struct mii_dev *cpsw_mdio_init(const char *name, phys_addr_t mdio_base,
>u32 bus_freq, int fck_freq)
> {
> struct cpsw_mdio *cpsw_mdio;
> @@ -144,7 +144,7 @@ struct mii_dev *cpsw_mdio_init(const char *name, u32
> mdio_base,
> return NULL;
> }
>
> - cpsw_mdio->regs = (struct cpsw_mdio_regs *)mdio_base;
> + cpsw_mdio->regs = (struct cpsw_mdio_regs *)(uintptr_t)mdio_base;
>
I'm missing something... the (uintptr_t) cast - is that a narrowing cast?
--
Alex Kiernan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Verified boot of images without signatures
On Wed, Jun 12, 2019 at 7:00 PM Patrick Doyle wrote:
>
> I am looking at enabling verified boot in the v2019.04-rc4 tag of
> u-boot. I was pleased when I learned how to embed the public
> authentication key in my u-boot device tree, sign my kernel using my
> private authentication key, and see u-boot validate the signature on
> boot.
>
> But then I was very surprised to learn that I could still boot an
> unsigned image. So I started looking at the code and I found
> `fit_image_verify_with_data() in "common/image_fit.c", which does:
>
> if (IMAGE_ENABLE_VERIFY &&
> fit_image_verify_required_sigs(fit, image_noffset, data, size,
>gd_fdt_blob(), _all)) {
> err_msg = "Unable to verify required signature";
> goto error;
> }
>
> /* Process all hash subnodes of the component image node */
> fdt_for_each_subnode(noffset, fit, image_noffset) {
> const char *name = fit_get_name(fit, noffset, NULL);
>
> /*
> * Check subnode name, must be equal to "hash".
> * Multiple hash nodes require unique unit node
> * names, e.g. hash-1, hash-2, etc.
> */
> if (!strncmp(name, FIT_HASH_NODENAME,
> strlen(FIT_HASH_NODENAME))) {
> if (fit_image_check_hash(fit, noffset, data, size,
> _msg))
> goto error;
> puts("+ ");
> } else if (IMAGE_ENABLE_VERIFY && verify_all &&
> !strncmp(name, FIT_SIG_NODENAME,
> strlen(FIT_SIG_NODENAME))) {
> ret = fit_image_check_sig(fit, noffset, data,
> size, -1, _msg);
>
> /*
> * Show an indication on failure, but do not return
> * an error. Only keys marked 'required' can cause
> * an image validation failure. See the call to
> * fit_image_verify_required_sigs() above.
> */
> if (ret)
> puts("- ");
> else
> puts("+ ");
> }
> }
>
> I see that if I create a "required" property in my signature block,
> then u-boot will require that the signature match. But if I don't
> have that, then it will happily boot an unsigned image (or even one
> that doesn't have any signature blocks).
>
> Am I missing something here?
>
Probably... I went round a very similar loop too. You need the
required property in the U-Boot DTB, not in the image you're booting.
And if you're trying to do this for SPL loading U-Boot you need
CONFIG_SPL_LOAD_FIT_FULL. Oh and make sure you've disabled legacy
image support.
--
Alex Kiernan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] fw_env: Add missing write failure check
If flash_write fails, whilst we propagate this up to our caller, we need
to avoid swapping in the new file (if we're on a filesystem) in this
case.
Fixes: dbc34323796b ("tools: env: Implement atomic replace for filesystem")
Signed-off-by: Alex Kiernan
---
tools/env/fw_env.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c
index cfada0ee1157..eef12dd2b757 100644
--- a/tools/env/fw_env.c
+++ b/tools/env/fw_env.c
@@ -1317,7 +1317,7 @@ static int flash_io_write(int fd_current)
rc = -1;
}
- if (target_temp) {
+ if (rc >= 0 && target_temp) {
int dir_fd;
dir_fd = open(dname, O_DIRECTORY | O_RDONLY);
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] cmd: Add 'bcb' command to read/modify/write BCB fields
On Tue, May 21, 2019 at 10:14 AM Eugeniu Rosca wrote:
>
> Hi Lukasz,
>
> On Tue, May 21, 2019 at 10:02:34AM +0100, Alex Kiernan wrote:
> > On Tue, May 21, 2019 at 9:37 AM Lukasz Majewski wrote:
> > >
> > > Hi Alex,
> > >
> > > > On Mon, May 20, 2019 at 8:23 AM Eugeniu Rosca
> > > > wrote:
> > > > >
> > > > > >
> > > > > > Should it default to enabled if avb is used?
> > > > >
> > > > > I think at this specific moment in time, 'bcb' is orthogonal
> > > > > (meaning it is neither a direct, nor a reverse dependency) to any
> > > > > other Android feature in U-Boot. This could be re-assessed, if
> > > > > platform maintainers start to rely on 'bcb' in their U-Boot
> > > > > environments on regular basis.
> > > >
> > > > 'bcb' looks like something I'd be interested in, not running Android
> > > > at all... currently I (ab)use the bootcounter to communicate between
> > > > the kernel and U-Boot when I want to force a board through recovery,
> > >
> > > I don't know your exact use case, but wouldn't it be better to use envs
> > > (with redundancy) and fw_setenv / fw_printenv from Linux user space?
> > >
> > > Now those envs even support setting default values for u-boot (as there
> > > is now separate library used for it). Moreover there is OE/Yocto's
> > > recipe 'u-boot-fw-utils' which can be easily used and installed.
>
> That's a truly constructive suggestion. Nevertheless, I believe this
> would not work in case of CONFIG_ENV_IS_NOWHERE=y, which is how U-Boot
> is built and used by the developers in our organization.
>
That's how we build/run too, but with with hackery like this in a boot
script to pick pieces out of the legacy world:
mmc dev ${mmcdev}
mmc read ${loadaddr} 1300 100
env import -c ${loadaddr} 2 ethaddr
Yes, it's ugly...
--
Alex Kiernan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] cmd: Add 'bcb' command to read/modify/write BCB fields
On Tue, May 21, 2019 at 9:37 AM Lukasz Majewski wrote: > > Hi Alex, > > > On Mon, May 20, 2019 at 8:23 AM Eugeniu Rosca > > wrote: > > > > > > > > > > > Should it default to enabled if avb is used? > > > > > > I think at this specific moment in time, 'bcb' is orthogonal > > > (meaning it is neither a direct, nor a reverse dependency) to any > > > other Android feature in U-Boot. This could be re-assessed, if > > > platform maintainers start to rely on 'bcb' in their U-Boot > > > environments on regular basis. > > > > 'bcb' looks like something I'd be interested in, not running Android > > at all... currently I (ab)use the bootcounter to communicate between > > the kernel and U-Boot when I want to force a board through recovery, > > I don't know your exact use case, but wouldn't it be better to use envs > (with redundancy) and fw_setenv / fw_printenv from Linux user space? > > Now those envs even support setting default values for u-boot (as there > is now separate library used for it). Moreover there is OE/Yocto's > recipe 'u-boot-fw-utils' which can be easily used and installed. > It's a long story... I'm constrained by historic choices, which makes using the environment problematic. But you're right. -- Alex Kiernan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] cmd: Add 'bcb' command to read/modify/write BCB fields
On Mon, May 20, 2019 at 8:23 AM Eugeniu Rosca wrote: > > > > > Should it default to enabled if avb is used? > > I think at this specific moment in time, 'bcb' is orthogonal (meaning it > is neither a direct, nor a reverse dependency) to any other Android > feature in U-Boot. This could be re-assessed, if platform maintainers > start to rely on 'bcb' in their U-Boot environments on regular basis. > 'bcb' looks like something I'd be interested in, not running Android at all... currently I (ab)use the bootcounter to communicate between the kernel and U-Boot when I want to force a board through recovery, but this looks like something that might well give me a better interface. -- Alex Kiernan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] AM3517 SPL fails with CONFIG_DM enabled
On Wed, May 15, 2019 at 7:43 PM Adam Ford wrote: > > On Wed, May 15, 2019 at 1:25 PM Simon Goldschmidt > wrote: > > > > Am 15.05.2019 um 20:12 schrieb Adam Ford: > > > I am trying to add DM support in SPL along with device tree support > > > similar to how it's being done for the omap3_logic boards. > > > Unfortunately, I think something is going wrong in the initialization > > > with CONFIG_DM enabled for SPL because I get no text data, and it > > > doesn't appear to boot. > > > > > > I tried enabling DM in SPL and using the older platdata method without > > > success. I have disabled DM_SERIAL in SPL and tried enabling the > > > serial debug stuff, and I get nothing. I don't have a debugger, so > > > it's a bit more difficult to troubleshoot. > > > > > > The main difference between the am35 and omap3 is the memory > > > controller, and I've tried to model the am35 after the omap3 boards I > > > also maintain. I was hoping someone might have any suggestions on how > > > to track down the issue. As of right now, I have OF_CONTROL working > > > in U-Boot and with DM disabled in SPL, everything is good. > > > > I don't know that mach, but reading the files, you're calling > > 'spl_early_init()' from your 'board_init_f()'. The problem I had there > > was that I did not have enough heap - and notice you need pre-reloc heap > > enabled. > > I have a device tree setup with a variety of pre-reloc entries. There > is an omap3-u-boot.dtsi file which sets this up. > dtc -I dtb -O dts spl/u-boot-spl.dtb lists a bunch of nodes for gpio, > mmc, serial, and some misc dependencies. > > Is there somewhere else I need to enable the pre-reloc stuff? > > > > > spl_early_init() parses the dts and binds the drivers, and even the > > default CONFIG_SPL_SYS_MALLOC_F_LEN of 1 KiB wasn't enough for me. Oh, > > and of course you need CONFIG_SYS_MALLOC_F enabled when calling > > spl_early_ini() from board_init_f in SPL. > > My updated defconfig file has: > > CONFIG_SYS_MALLOC_F_LEN=0x4000 > CONFIG_SYS_MALLOC_F=y > We had a similar problem, which we tracked down to calling DM functions before the DT was loaded (because we needed to probe GPIOs in order to know which DT we wanted), obviously that wasn't useful, but even with a heap of the size you've got here we were OOMing. To figure out exactly where we'd got we it wrong we ended up running with full malloc in SPL rather than simple malloc and chopping enough stuff out that it all fitted, at which point actually finding out our mistake got a lot easier (and then we could turn simple malloc back on). -- Alex Kiernan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3] Convert CONFIG_SUPPORT_EMMC_BOOT to Kconfig
On Wed, May 1, 2019 at 3:49 PM Tom Rini wrote: > > On Wed, May 01, 2019 at 07:58:27AM +, Alex Kiernan wrote: > > This converts the following to Kconfig: > >CONFIG_SUPPORT_EMMC_BOOT > > > > As requested by Michal Simek , these boards > > have no eMMC so CONFIG_SUPPORT_EMMC_BOOT has not been migrated: > > > > xilinx_zynqmp_zc1275_revB > > xilinx_zynqmp_zc1751_xm018_dc4 > > xilinx_zynqmp_zc1751_xm019_dc5 > > xilinx_zynqmp_zcu100_revC > > xilinx_zynqmp_zcu102_rev1_0 > > xilinx_zynqmp_zcu102_revA > > xilinx_zynqmp_zcu102_revB > > xilinx_zynqmp_zcu104_revA > > xilinx_zynqmp_zcu104_revC > > xilinx_zynqmp_zcu106_revA > > xilinx_zynqmp_zcu111_revA > > > > Signed-off-by: Alex Kiernan > > Acked-by: Lukasz Majewski > > Acked-by: Patrick Delaunay > > Acked-by: Ramon Fried > > Reviewed-by: Andy Shevchenko > > Tested-by: Sébastien Szymanski > > --- > > Green travis build: > > > > https://travis-ci.org/akiernan/u-boot/builds/526591535 > > > > Testing for configuration changes shows just the expected xilinx_zynqmp > > boards: > > So, FWIW, what I do (and will do for this patch when I check it out > before pushing) ends up as: > $ export SOURCE_DATE_EPOCH=`date +%s` > $ ./tools/buildman/buildman -o /tmp/test -b master --force-build --step 0 \ > -SCdvel \ > 'arc|arm|sandbox|x86|aarch64|powerpc|m68k|nios2|nds32|sh|mips|xtensa|riscv' > $ ./tools/buildman/buildman -o /tmp/test -b master --step 0 -Ssdel \ > 'arc|arm|sandbox|x86|aarch64|powerpc|m68k|nios2|nds32|sh|mips|xtensa|riscv' > > With the patch applied in some branch that has 'master' as the upstream. > This is basically a world-build and will size compare before/after, > noting changes. If I see a size difference (outside of a few boards > that include the config in the binary and so grow slightly on > conversions), I use: > $ export SOURCE_DATE_EPOCH=`date +%s` > $ ./tools/buildman/buildman -o /tmp/brd -b master --step 0 -SBCdevlk BOARD > $ ./tools/buildman/buildman -o /tmp/brd -b master --step 0 -SsBdevlk BOARD > > Which probably has a few more flags than required but will also tell > which functions within the binary have changed and so a good place to > hunt down what didn't convert correctly and why. > That's a useful set of snippets - thanks! -- Alex Kiernan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3] Convert CONFIG_SUPPORT_EMMC_BOOT to Kconfig
This converts the following to Kconfig: CONFIG_SUPPORT_EMMC_BOOT As requested by Michal Simek , these boards have no eMMC so CONFIG_SUPPORT_EMMC_BOOT has not been migrated: xilinx_zynqmp_zc1275_revB xilinx_zynqmp_zc1751_xm018_dc4 xilinx_zynqmp_zc1751_xm019_dc5 xilinx_zynqmp_zcu100_revC xilinx_zynqmp_zcu102_rev1_0 xilinx_zynqmp_zcu102_revA xilinx_zynqmp_zcu102_revB xilinx_zynqmp_zcu104_revA xilinx_zynqmp_zcu104_revC xilinx_zynqmp_zcu106_revA xilinx_zynqmp_zcu111_revA Signed-off-by: Alex Kiernan Acked-by: Lukasz Majewski Acked-by: Patrick Delaunay Acked-by: Ramon Fried Reviewed-by: Andy Shevchenko Tested-by: Sébastien Szymanski --- Green travis build: https://travis-ci.org/akiernan/u-boot/builds/526591535 Testing for configuration changes shows just the expected xilinx_zynqmp boards: boards.cfg is up to date. Nothing to do. Summary of 2 commits for 1365 boards (4 threads, 1 job per thread) 01: Prepare v2019.07-rc1 arm: w+ blanche db-88f6281-bp-nand Nintendo_NES_Classic_Edition ts4600 kc1 vining_2000 topic_miamilite bcm7260 tqma6dl_mba6_spi dserve_dsrv9703c m68k: w+ M5485BFE powerpc: w+ MPC8313ERDB_NAND_66 P3041DS_SRIO_PCIE_BOOT P1022DS_36BIT_NAND xpedite550x P5040DS_SDCARD Cyrus_P5040 T2080RDB_SRIO_PCIE_BOOT 02: Convert CONFIG_SUPPORT_EMMC_BOOT to Kconfig x86: + conga-qeval20-qa3-e3845-internal-uart theadorable-x86-conga-qa3-e3845-pcie-x4 bayleybay dfi-bt700-q7x-151 theadorable-x86-dfi-bt700 galileo theadorable-x86-conga-qa3-e3845 minnowmax som-db5800-som-6867 conga-qeval20-qa3-e3845 aarch64: w+ ls1088ardb_sdcard_qspi_SECURE_BOOT am65x_hs_evm_a53 pine_h64 pinebook pine64-lts bananapi_m2_plus_h5 xilinx_versal_mini_emmc1 xilinx_versal_mini_emmc0 mvebu_espressobin-88f3720 ls1012aqds_tfa_SECURE_BOOT bubblegum_96 bcm958712k amarula_a64_relic uDPU oceanic_5205_5inmfd libretech_all_h3_cc_h5 nanopi_neo2 bananapi_m64 orangepi_prime hikey orangepi_pc2 nanopi_neo_plus2 s32v234evb pine64_plus orangepi_one_plus emlid_neutis_n5_devboard turris_mox orangepi_win a64-olinuxino imx8qxp_mek xilinx_zynqmp_mini_emmc1 ls2080aqds_nand rpi_3 ls2080aqds_qspi xilinx_zynqmp_mini_emmc0 ls2080aqds_sdcard am65x_evm_a53 orangepi_zero_plus socfpga_stratix10 ls1046ardb_sdcard_SECURE_BOOT imx8mq_evk orangepi_lite2 ls2080a_simu nanopi_a64 ls1043ardb_sdcard_SECURE_BOOT mvebu_mcbin-88f8040 mvebu_db_armada8k sopine_baseboard orangepi_zero_plus2 clearfog_gt_8k mvebu_db-88f3720 powerpc: w+ T4240RDB T1024RDB_SPIFLASH T2081QDS_SRIO_PCIE_BOOT T2080QDS_SPIFLASH P3041DS_NAND P1020RDB-PC_36BIT MPC837XEMDS_HOST P1024RDB_SPIFLASH P2020RDB-PC_36BIT_SPIFLASH P1010RDB-PB_SPIFLASH_SECBOOT hrcon P5020DS_NAND T1024QDS_SPIFLASH P1010RDB-PA_36BIT_NAND P1021RDB-PC P1010RDB-PB_SDCARD P1010RDB-PB_36BIT_NOR T1024QDS_DDR4_SECURE_BOOT P1020UTM-PC_36BIT controlcenterd_36BIT_SDCARD P5020DS_SRIO_PCIE_BOOT P1020MBG-PC_36BIT_SDCARD BSC9132QDS_SDCARD_DDRCLK133_SECURE P2041RDB_SPIFLASH P3041DS T2081QDS P1025RDB_SDCARD T2080QDS T4240QDS T1040D4RDB BSC9132QDS_NAND_DDRCLK133_SECURE P1010RDB-PA_36BIT_SPIFLASH_SECBOOT T4240RDB_SDCARD TWR-P1025 P1010RDB-PB_36BIT_NAND T1023RDB_NAND P1022DS_36BIT_SDCARD P2041RDB_SECURE_BOOT T1024QDS_NAND P1021RDB-PC_SPIFLASH P5020DS_NAND_SECURE_BOOT P1010RDB-PA_SPIFLASH_SECBOOT MPC8536DS_SDCARD T1040RDB_SPIFLASH BSC9132QDS_SDCARD_DDRCLK100 T1024RDB_NAND T2081QDS_SPIFLASH P1010RDB-PB_36BIT_NOR_SECBOOT P5020DS BSC9132QDS_NOR_DDRCLK100_SECURE T1023RDB_SDCARD P1020UTM-PC P3041DS_SECURE_BOOT Cyrus_P5020 P1010RDB-PB_36BIT_SDCARD P2020RDB-PC UCP1020 T4160QDS_NAND P1020MBG-PC_36BIT P1020RDB-PC_36BIT_NAND T1042D4RDB_SECURE_BOOT P5040DS_SECURE_BOOT P1020RDB-PC_SDCARD T2080RDB P1025RDB_36BIT P5040DS_NAND T4240QDS_SECURE_BOOT P3041DS_SDCARD T1024QDS P5040DS_NAND_SECURE_BOOT T1042RDB_PI_NAND P1010RDB-PA_SPIFLASH P1020RDB-PD_SPIFLASH T2080RDB_NAND P1010RDB-PB_36BIT_SPIFLASH_SECBOOT P1010RDB-PB_NAND_SECBOOT P1022DS_SDCARD P1020RDB-PC_36BIT_SPIFLASH T1042RDB_PI_SDCARD BSC9132QDS_SPIFLASH_DDRCLK100_SECURE P3041DS_NAND_SECURE_BOOT T2081QDS_NAND BSC9132QDS_SDCARD_DDRCLK133 T4160QDS_SDCARD T2080QDS_SDCARD P1020RDB-PC_SPIFLASH T1042RDB T4160QDS_SECURE_BOOT P1021RDB-PC_NAND P1020RDB-PD P2041RDB_SDCARD T1040D4RDB_SPIFLASH T2080RDB_SECURE_BOOT P1010RDB-PA_36BIT_NOR_SECBOOT T1040QDS P1010RDB-PA_36BIT_NOR T1042D4RDB P1021RDB-PC_SDCARD P1025RDB P2020RDB-PC_SPIFLASH MPC837XEMDS P4080DS_SECURE_BOOT T1040QDS_SECURE_BOOT strider_con_dp T1040QDS_DDR4 P1010RDB-PA_36BIT_SDCARD P1010RDB-PB_NOR T2080RDB_SPIFLASH P1021RDB-PC_36BIT_SPIFLASH P1020RDB-PC_36BIT_SDCARD T1024QDS_DDR4 P1010RDB-PB_36BIT_NAND_SECBOOT P1020RDB-PC_NAND T2080QDS_NAND BSC9132QDS_SPIFLASH_DDRCLK133 controlcenterd_36BIT_SDCARD_DEVELOP strider_cpu_dp P5020DS_SDCARD P1010RDB-PA_NOR T2080QDS_SRIO_PCIE_BOOT P5020DS_SPIFLASH P1022DS_SPIFLASH UCP1020_SPIFLASH BSC9132QDS_NAND_DDRCLK100 MPC8308RDB T1040D4RDB_NAND T4160QDS P1010RDB-PA_NAND_SECBOOT T4160RDB BSC9132QDS_SPIFLASH_DDRCLK133_SECURE P1010RDB-PA_NOR_SECBOOT
Re: [U-Boot] [PATCH] Convert CONFIG_SUPPORT_EMMC_BOOT to Kconfig
On Thu, Apr 25, 2019 at 8:07 PM Michal Simek wrote: > > On 19. 04. 19 6:38, Alex Kiernan wrote: > > This converts the following to Kconfig: > >CONFIG_SUPPORT_EMMC_BOOT > > > > Signed-off-by: Alex Kiernan > > --- > > Green travis build: > > > > https://travis-ci.org/akiernan/u-boot/builds/521906850 > > > > Testing affected boards for configuration changes: > > > > boards.cfg is up to date. Nothing to do. > > Summary of 3 commits for 95 boards (4 threads, 1 job per thread) > > 01: Merge tag 'u-boot-imx-20190415' of git://git.denx.de/u-boot-imx > > aarch64: w+ xilinx_zynqmp_mini_emmc1 xilinx_zynqmp_mini_emmc0 > > xilinx_zynqmp_mini_qspi clearfog_gt_8k imx8qxp_mek xilinx_zynqmp_mini > > xilinx_zynqmp_mini_nand imx8mq_evk > > arm: w+ cm_t54 cl-som-imx7 marsboard clearfog apalis_imx6 warp7 > > pico-hobbit-imx7d pico-pi-imx6ul dms-ba16 arndale riotboard > > pico-hobbit-imx6ul colibri_imx7 pico-imx7d xpress_spl opos6uldev warp7_bl33 > > imx6dl_mamoj ge_bx50v3 display5 mx7dsabresd_qspi display5_factory > > colibri_imx7_emmc gwventana_nand mx7dsabresd gwventana_gw5904 > > gwventana_emmc am57xx_hs_evm_usb omap5_uevm brppt1_spi xilinx_zynqmp_r5 > > vinco mx6sabresd warp riotboard_spl vining_2000 zc5601 zc5202 xpress > > pico-imx6ul dms-ba16-1g pico-pi-imx7d > > 02: configs: Resync with savedefconfig > > 03: Convert CONFIG_SUPPORT_EMMC_BOOT to Kconfig > > > > README | 3 --- > > configs/am57xx_evm_defconfig | 1 + > > configs/am57xx_hs_evm_defconfig | 1 + > > configs/am57xx_hs_evm_usb_defconfig | 1 + > > configs/apalis-tk1_defconfig | 1 + > > configs/apalis_imx6_defconfig| 1 + > > configs/arndale_defconfig| 1 + > > configs/avnet_ultra96_rev1_defconfig | 1 + > > configs/cl-som-imx7_defconfig| 1 + > > configs/clearfog_defconfig | 1 + > > configs/cm_t54_defconfig | 1 + > > configs/colibri_imx6_defconfig | 1 + > > configs/colibri_imx7_emmc_defconfig | 1 + > > configs/display5_defconfig | 1 + > > configs/display5_factory_defconfig | 1 + > > configs/dms-ba16-1g_defconfig| 1 + > > configs/dms-ba16_defconfig | 1 + > > configs/dra7xx_evm_defconfig | 1 + > > configs/dra7xx_hs_evm_defconfig | 1 + > > configs/dra7xx_hs_evm_usb_defconfig | 1 + > > configs/edison_defconfig | 1 + > > configs/ge_bx50v3_defconfig | 1 + > > configs/gwventana_emmc_defconfig | 1 + > > configs/gwventana_gw5904_defconfig | 1 + > > configs/gwventana_nand_defconfig | 1 + > > configs/imx6dl_mamoj_defconfig | 1 + > > configs/imx8mq_evk_defconfig | 1 + > > configs/imx8qxp_mek_defconfig| 1 + > > configs/liteboard_defconfig | 1 + > > configs/mt7623n_bpir2_defconfig | 1 + > > configs/mx6sabresd_defconfig | 1 + > > configs/mx7dsabresd_defconfig| 1 + > > configs/mx7dsabresd_qspi_defconfig | 1 + > > configs/mx7ulp_evk_defconfig | 1 + > > configs/mx7ulp_evk_plugin_defconfig | 1 + > > configs/odroid-xu3_defconfig | 1 + > > configs/omap5_uevm_defconfig | 1 + > > configs/opos6uldev_defconfig | 1 + > > configs/peach-pi_defconfig | 1 + > > configs/peach-pit_defconfig | 1 + > > configs/pico-hobbit-imx6ul_defconfig | 1 + > > configs/pico-hobbit-imx7d_defconfig | 1 + > > configs/pico-imx6ul_defconfig| 1 + > > configs/pico-imx7d_defconfig | 1 + > > configs/pico-pi-imx6ul_defconfig | 1 + > > configs/pico-pi-imx7d_defconfig | 1 + > > configs/riotboard_defconfig | 1 + > > configs/riotboard_spl_defconfig | 1 + > > configs/smdk5250_defconfig | 1 + > > configs/smdk5420_defconfig | 1 + > > configs/snow_defconfig | 1 + > > configs/spring_defconf
[U-Boot] [PATCH] Convert CONFIG_SUPPORT_EMMC_BOOT to Kconfig
This converts the following to Kconfig: CONFIG_SUPPORT_EMMC_BOOT Signed-off-by: Alex Kiernan --- Green travis build: https://travis-ci.org/akiernan/u-boot/builds/521906850 Testing affected boards for configuration changes: boards.cfg is up to date. Nothing to do. Summary of 3 commits for 95 boards (4 threads, 1 job per thread) 01: Merge tag 'u-boot-imx-20190415' of git://git.denx.de/u-boot-imx aarch64: w+ xilinx_zynqmp_mini_emmc1 xilinx_zynqmp_mini_emmc0 xilinx_zynqmp_mini_qspi clearfog_gt_8k imx8qxp_mek xilinx_zynqmp_mini xilinx_zynqmp_mini_nand imx8mq_evk arm: w+ cm_t54 cl-som-imx7 marsboard clearfog apalis_imx6 warp7 pico-hobbit-imx7d pico-pi-imx6ul dms-ba16 arndale riotboard pico-hobbit-imx6ul colibri_imx7 pico-imx7d xpress_spl opos6uldev warp7_bl33 imx6dl_mamoj ge_bx50v3 display5 mx7dsabresd_qspi display5_factory colibri_imx7_emmc gwventana_nand mx7dsabresd gwventana_gw5904 gwventana_emmc am57xx_hs_evm_usb omap5_uevm brppt1_spi xilinx_zynqmp_r5 vinco mx6sabresd warp riotboard_spl vining_2000 zc5601 zc5202 xpress pico-imx6ul dms-ba16-1g pico-pi-imx7d 02: configs: Resync with savedefconfig 03: Convert CONFIG_SUPPORT_EMMC_BOOT to Kconfig README | 3 --- configs/am57xx_evm_defconfig | 1 + configs/am57xx_hs_evm_defconfig | 1 + configs/am57xx_hs_evm_usb_defconfig | 1 + configs/apalis-tk1_defconfig | 1 + configs/apalis_imx6_defconfig| 1 + configs/arndale_defconfig| 1 + configs/avnet_ultra96_rev1_defconfig | 1 + configs/cl-som-imx7_defconfig| 1 + configs/clearfog_defconfig | 1 + configs/cm_t54_defconfig | 1 + configs/colibri_imx6_defconfig | 1 + configs/colibri_imx7_emmc_defconfig | 1 + configs/display5_defconfig | 1 + configs/display5_factory_defconfig | 1 + configs/dms-ba16-1g_defconfig| 1 + configs/dms-ba16_defconfig | 1 + configs/dra7xx_evm_defconfig | 1 + configs/dra7xx_hs_evm_defconfig | 1 + configs/dra7xx_hs_evm_usb_defconfig | 1 + configs/edison_defconfig | 1 + configs/ge_bx50v3_defconfig | 1 + configs/gwventana_emmc_defconfig | 1 + configs/gwventana_gw5904_defconfig | 1 + configs/gwventana_nand_defconfig | 1 + configs/imx6dl_mamoj_defconfig | 1 + configs/imx8mq_evk_defconfig | 1 + configs/imx8qxp_mek_defconfig| 1 + configs/liteboard_defconfig | 1 + configs/mt7623n_bpir2_defconfig | 1 + configs/mx6sabresd_defconfig | 1 + configs/mx7dsabresd_defconfig| 1 + configs/mx7dsabresd_qspi_defconfig | 1 + configs/mx7ulp_evk_defconfig | 1 + configs/mx7ulp_evk_plugin_defconfig | 1 + configs/odroid-xu3_defconfig | 1 + configs/omap5_uevm_defconfig | 1 + configs/opos6uldev_defconfig | 1 + configs/peach-pi_defconfig | 1 + configs/peach-pit_defconfig | 1 + configs/pico-hobbit-imx6ul_defconfig | 1 + configs/pico-hobbit-imx7d_defconfig | 1 + configs/pico-imx6ul_defconfig| 1 + configs/pico-imx7d_defconfig | 1 + configs/pico-pi-imx6ul_defconfig | 1 + configs/pico-pi-imx7d_defconfig | 1 + configs/riotboard_defconfig | 1 + configs/riotboard_spl_defconfig | 1 + configs/smdk5250_defconfig | 1 + configs/smdk5420_defconfig | 1 + configs/snow_defconfig | 1 + configs/spring_defconfig | 1 + configs/stm32mp15_basic_defconfig| 1 + configs/stm32mp15_trusted_defconfig | 1 + configs/uniphier_ld4_sld8_defconfig | 1 + configs/uniphier_v7_defconfig| 1 + configs/uniphier_v8_defconfig| 1 + configs/vinco_defconfig | 1 + configs/vining_2000_defconfig| 1 + configs/warp7_bl33_defconfig | 1 + configs/warp7_defconfig | 1 + configs/warp_defconfig | 1 + configs/xilinx_zynqmp_mini_emmc0_defconfig | 1 + configs/xilinx_zynqmp_mini_emmc1_defconfig | 1 + configs/xilinx_zynqmp_zc1275_revB_defconfig | 1 + configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig | 1 + configs/xilinx_zynqmp_zc1751_xm017_dc3_defconfig | 1 + configs
[U-Boot] [PATCH] Refactor IMAGE_ENABLE_VERIFY to handle builds without SPL verification
If building with SPL_LOAD_FIT_FULL and FIT_SIGNATURE, but without SPL_FIT_SIGNATURE then the build fails with: common/built-in.o: In function `fit_image_verify_with_data': common/image-fit.c:1220: undefined reference to `fit_image_verify_required_sigs' common/image-fit.c:1244: undefined reference to `fit_image_check_sig' common/built-in.o: In function `fit_image_load': common/image-fit.c:1857: undefined reference to `fit_config_verify' Refactor so that host builds still depend on FIT_SIGNATURE, but target builds check FIT_SIGNATURE/SPL_FIT_SIGNATURE dependent on the build. Signed-off-by: Alex Kiernan --- Green travis build: https://travis-ci.org/akiernan/u-boot/builds/521570862 include/image.h | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/include/image.h b/include/image.h index 765ffecee0a7..c8522189ebab 100644 --- a/include/image.h +++ b/include/image.h @@ -1071,18 +1071,18 @@ int calculate_hash(const void *data, int data_len, const char *algo, * At present we only support signing on the host, and verification on the * device */ -#if defined(CONFIG_FIT_SIGNATURE) -# ifdef USE_HOSTCC +#if defined(USE_HOSTCC) +# if defined(CONFIG_FIT_SIGNATURE) # define IMAGE_ENABLE_SIGN1 # define IMAGE_ENABLE_VERIFY 1 -# include -#else +# include +# else # define IMAGE_ENABLE_SIGN0 -# define IMAGE_ENABLE_VERIFY 1 +# define IMAGE_ENABLE_VERIFY 0 # endif #else # define IMAGE_ENABLE_SIGN 0 -# define IMAGE_ENABLE_VERIFY 0 +# define IMAGE_ENABLE_VERIFY CONFIG_IS_ENABLED(FIT_SIGNATURE) #endif #ifdef USE_HOSTCC -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [RESEND PATCH] usb: Select USB_MUSB_DSPS with USB_MUSB_TI
USB_MUSB_TI requires USB_MUSB_DSPS, failing at link time if it's not selected: drivers/usb/musb-new/built-in.o: In function `ti_musb_host_ofdata_to_platdata': drivers/usb/musb-new/ti-musb.c:193: undefined reference to `musb_dsps_ops' or if OF_CONTROL is not selected: arch/arm/mach-omap2/built-in.o:(.data.usb0+0x24): undefined reference to `musb_dsps_ops' Reviewed-by: Hannes Schmelzer Tested-by: Hannes Schmelzer Signed-off-by: Alex Kiernan --- Green Travis build: https://travis-ci.org/akiernan/u-boot/builds/521570727 configs/am335x_boneblack_vboot_defconfig | 1 - configs/am335x_evm_defconfig | 1 - configs/am335x_hs_evm_defconfig | 1 - configs/am335x_hs_evm_uart_defconfig | 1 - configs/brppt1_mmc_defconfig | 1 - configs/brppt1_nand_defconfig| 1 - configs/brppt1_spi_defconfig | 1 - configs/chiliboard_defconfig | 1 - drivers/usb/musb-new/Kconfig | 1 + 9 files changed, 1 insertion(+), 8 deletions(-) diff --git a/configs/am335x_boneblack_vboot_defconfig b/configs/am335x_boneblack_vboot_defconfig index 6afda7245372..ffe013fa2df7 100644 --- a/configs/am335x_boneblack_vboot_defconfig +++ b/configs/am335x_boneblack_vboot_defconfig @@ -56,7 +56,6 @@ CONFIG_SPL_DM_USB_GADGET=y CONFIG_USB_MUSB_HOST=y CONFIG_USB_MUSB_GADGET=y CONFIG_USB_MUSB_TI=y -CONFIG_USB_MUSB_DSPS=y CONFIG_USB_GADGET=y CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments" CONFIG_USB_GADGET_VENDOR_NUM=0x0451 diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig index a396a3931050..105ff01d14de 100644 --- a/configs/am335x_evm_defconfig +++ b/configs/am335x_evm_defconfig @@ -64,7 +64,6 @@ CONFIG_SPL_DM_USB_GADGET=y CONFIG_USB_MUSB_HOST=y CONFIG_USB_MUSB_GADGET=y CONFIG_USB_MUSB_TI=y -CONFIG_USB_MUSB_DSPS=y CONFIG_USB_GADGET=y CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments" CONFIG_USB_GADGET_VENDOR_NUM=0x0451 diff --git a/configs/am335x_hs_evm_defconfig b/configs/am335x_hs_evm_defconfig index 1746df90f411..a37966bc6dcb 100644 --- a/configs/am335x_hs_evm_defconfig +++ b/configs/am335x_hs_evm_defconfig @@ -60,7 +60,6 @@ CONFIG_DM_USB=y CONFIG_USB_MUSB_HOST=y CONFIG_USB_MUSB_GADGET=y CONFIG_USB_MUSB_TI=y -CONFIG_USB_MUSB_DSPS=y CONFIG_USB_GADGET=y CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments" CONFIG_USB_GADGET_VENDOR_NUM=0x0451 diff --git a/configs/am335x_hs_evm_uart_defconfig b/configs/am335x_hs_evm_uart_defconfig index d2d6f2fb6e4d..ff131eb60178 100644 --- a/configs/am335x_hs_evm_uart_defconfig +++ b/configs/am335x_hs_evm_uart_defconfig @@ -62,7 +62,6 @@ CONFIG_DM_USB=y CONFIG_USB_MUSB_HOST=y CONFIG_USB_MUSB_GADGET=y CONFIG_USB_MUSB_TI=y -CONFIG_USB_MUSB_DSPS=y CONFIG_USB_GADGET=y CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments" CONFIG_USB_GADGET_VENDOR_NUM=0x0451 diff --git a/configs/brppt1_mmc_defconfig b/configs/brppt1_mmc_defconfig index 6b0d0242f2eb..63cb240ea89b 100644 --- a/configs/brppt1_mmc_defconfig +++ b/configs/brppt1_mmc_defconfig @@ -84,7 +84,6 @@ CONFIG_DM_USB=y CONFIG_USB_MUSB_HOST=y CONFIG_USB_MUSB_GADGET=y CONFIG_USB_MUSB_TI=y -CONFIG_USB_MUSB_DSPS=y CONFIG_USB_STORAGE=y CONFIG_USB_GADGET=y CONFIG_FAT_WRITE=y diff --git a/configs/brppt1_nand_defconfig b/configs/brppt1_nand_defconfig index 4578f74a6208..57cd54bac26d 100644 --- a/configs/brppt1_nand_defconfig +++ b/configs/brppt1_nand_defconfig @@ -88,7 +88,6 @@ CONFIG_DM_USB=y CONFIG_USB_MUSB_HOST=y CONFIG_USB_MUSB_GADGET=y CONFIG_USB_MUSB_TI=y -CONFIG_USB_MUSB_DSPS=y CONFIG_USB_STORAGE=y CONFIG_USB_GADGET=y CONFIG_FAT_WRITE=y diff --git a/configs/brppt1_spi_defconfig b/configs/brppt1_spi_defconfig index 739b0786f34a..31ba5158b586 100644 --- a/configs/brppt1_spi_defconfig +++ b/configs/brppt1_spi_defconfig @@ -99,7 +99,6 @@ CONFIG_DM_USB=y CONFIG_USB_MUSB_HOST=y CONFIG_USB_MUSB_GADGET=y CONFIG_USB_MUSB_TI=y -CONFIG_USB_MUSB_DSPS=y CONFIG_USB_STORAGE=y CONFIG_USB_GADGET=y CONFIG_FAT_WRITE=y diff --git a/configs/chiliboard_defconfig b/configs/chiliboard_defconfig index a6c36eda503d..944dd0db3c87 100644 --- a/configs/chiliboard_defconfig +++ b/configs/chiliboard_defconfig @@ -50,6 +50,5 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_MUSB_HOST=y CONFIG_USB_MUSB_TI=y -CONFIG_USB_MUSB_DSPS=y CONFIG_FAT_WRITE=y CONFIG_LZO=y diff --git a/drivers/usb/musb-new/Kconfig b/drivers/usb/musb-new/Kconfig index f8f2205a62d3..1dd823037bec 100644 --- a/drivers/usb/musb-new/Kconfig +++ b/drivers/usb/musb-new/Kconfig @@ -21,6 +21,7 @@ config USB_MUSB_GADGET config USB_MUSB_TI bool "Enable TI OTG USB controller" depends on DM_USB + select USB_MUSB_DSPS default n help Say y here to enable support for the dual role high -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] tools: fit_image: Add the loadable property to configs
On Tue, Mar 12, 2019 at 8:34 AM Abel Vesa wrote:
>
> When running mkimage with "-f auto", the loadable property
> needs to be set in order to allow SPL FIT support to boot.
>
> Signed-off-by: Abel Vesa
I've just bisected out to this commit breaking Y-Modem booting of FIT
U-Boot on am335x. Right now I'm at a bit of a loss as to why, as I
can't find a code path where FIT_LOADABLE_PROP would be treated
differently between UART and MMC booting (which still works).
That said the loadables stuff with this patch doesn't seem to match up
with what doc/uImage.FIT/howto.txt has to say about loadables:
/ {
timestamp = <0x5cb08987>;
description = "Firmware image with one or more FDT blobs";
creator = "U-Boot mkimage 2019.04-00217-g38927694f48a-dirty";
#address-cells = <0x0001>;
images {
firmware-1 {
data-size = <0x0005e204>;
data-offset = <0x>;
description = "U-Boot 2019.04-00217-g38927694f48a-dirty
for A335XHUB board";
type = "firmware";
arch = "arm";
os = "u-boot";
compression = "none";
load = <0x8080>;
entry = <0x>;
};
fdt-1 {
data-size = <0x80c4>;
data-offset = <0x0005e204>;
description = "A335XHUB-0001";
type = "firmware";
arch = "arm";
compression = "none";
};
fdt-2 {
data-size = <0x88f4>;
data-offset = <0x000662c8>;
description = "A335XHUB-0003";
type = "firmware";
arch = "arm";
compression = "none";
};
};
configurations {
default = "conf-1";
conf-1 {
description = "A335XHUB-0001";
firmware = "firmware-1";
loadables = "firmware-1";
fdt = "fdt-1";
};
conf-2 {
description = "A335XHUB-0003";
firmware = "firmware-1";
loadables = "firmware-1";
fdt = "fdt-2";
};
};
};
Still digging...
--
Alex Kiernan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [RESEND PATCH] configs: Migrate USB_MUSB_DISABLE_BULK_COMBINE_SPLIT to Kconfig
Migrate support for disable MUSB bulk split/combine to Kconfig Green Travis build: https://travis-ci.org/akiernan/u-boot/builds/519101867 Signed-off-by: Alex Kiernan --- drivers/usb/musb-new/Kconfig | 9 + include/configs/am335x_evm.h | 1 - include/configs/baltos.h | 1 - include/configs/bav335x.h | 1 - include/configs/brppt1.h | 3 --- include/configs/brxre1.h | 3 --- include/configs/chiliboard.h | 1 - include/configs/pengwyn.h | 1 - include/configs/siemens-am33x-common.h | 2 -- scripts/config_whitelist.txt | 1 - 10 files changed, 9 insertions(+), 14 deletions(-) diff --git a/drivers/usb/musb-new/Kconfig b/drivers/usb/musb-new/Kconfig index f8f2205a62d3..fdf9ca61da06 100644 --- a/drivers/usb/musb-new/Kconfig +++ b/drivers/usb/musb-new/Kconfig @@ -54,6 +54,15 @@ config USB_MUSB_SUNXI Say y here to enable support for the sunxi OTG / DRC USB controller used on almost all sunxi boards. +config USB_MUSB_DISABLE_BULK_COMBINE_SPLIT + bool "Disable MUSB bulk split/combine" + default y + help + On TI AM335x devices, MUSB has bulk split/combine feature enabled + in the ConfigData register, but the current MUSB driver does not + support it yet. Select this option to disable the feature until the + driver adds the support. + endif config USB_MUSB_PIO_ONLY diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h index 0834ff502193..7721907d8f0d 100644 --- a/include/configs/am335x_evm.h +++ b/include/configs/am335x_evm.h @@ -240,7 +240,6 @@ * add mass storage support and for gadget we add both RNDIS ethernet * and DFU. */ -#define CONFIG_USB_MUSB_DISABLE_BULK_COMBINE_SPLIT #define CONFIG_AM335X_USB0 #define CONFIG_AM335X_USB0_MODEMUSB_PERIPHERAL #define CONFIG_AM335X_USB1 diff --git a/include/configs/baltos.h b/include/configs/baltos.h index ccbdc0a33566..98ec0d626ea8 100644 --- a/include/configs/baltos.h +++ b/include/configs/baltos.h @@ -251,7 +251,6 @@ * add mass storage support and for gadget we add both RNDIS ethernet * and DFU. */ -#define CONFIG_USB_MUSB_DISABLE_BULK_COMBINE_SPLIT #define CONFIG_AM335X_USB0 #define CONFIG_AM335X_USB0_MODEMUSB_HOST #define CONFIG_AM335X_USB1 diff --git a/include/configs/bav335x.h b/include/configs/bav335x.h index fb9c2a6d04d0..3d4d08aa70e1 100644 --- a/include/configs/bav335x.h +++ b/include/configs/bav335x.h @@ -387,7 +387,6 @@ DEFAULT_LINUX_BOOT_ENV \ * add mass storage support and for gadget we add both RNDIS ethernet * and DFU. */ -#define CONFIG_USB_MUSB_DISABLE_BULK_COMBINE_SPLIT #define CONFIG_AM335X_USB0 #define CONFIG_AM335X_USB0_MODEMUSB_PERIPHERAL #define CONFIG_AM335X_USB1 diff --git a/include/configs/brppt1.h b/include/configs/brppt1.h index ae9b75bb87ad..84c801d10a99 100644 --- a/include/configs/brppt1.h +++ b/include/configs/brppt1.h @@ -182,9 +182,6 @@ NANDTGTS \ #define CONFIG_NAND_OMAP_GPMC_WSCFG1 #endif /* CONFIG_NAND */ -/* USB configuration */ -#define CONFIG_USB_MUSB_DISABLE_BULK_COMBINE_SPLIT - #if defined(CONFIG_SPI) /* SPI Flash */ #define CONFIG_SYS_SPI_U_BOOT_OFFS 0x4 diff --git a/include/configs/brxre1.h b/include/configs/brxre1.h index 601b30dffd5f..7309e7d4831d 100644 --- a/include/configs/brxre1.h +++ b/include/configs/brxre1.h @@ -68,9 +68,6 @@ BUR_COMMON_ENV \ #define CONFIG_SETUP_MEMORY_TAGS #define CONFIG_INITRD_TAG -/* USB configuration */ -#define CONFIG_USB_MUSB_DISABLE_BULK_COMBINE_SPLIT - /* Environment */ #define CONFIG_SYS_MMC_ENV_DEV 1 #define CONFIG_SYS_MMC_ENV_PART2 diff --git a/include/configs/chiliboard.h b/include/configs/chiliboard.h index 4372280d2bbe..db990fcb2b47 100644 --- a/include/configs/chiliboard.h +++ b/include/configs/chiliboard.h @@ -148,7 +148,6 @@ /* USB configuration */ #define CONFIG_ARCH_MISC_INIT -#define CONFIG_USB_MUSB_DISABLE_BULK_COMBINE_SPLIT #define CONFIG_AM335X_USB1 #define CONFIG_AM335X_USB1_MODE MUSB_HOST diff --git a/include/configs/pengwyn.h b/include/configs/pengwyn.h index 48f1f7baccba..a535d0c2f2d0 100644 --- a/include/configs/pengwyn.h +++ b/include/configs/pengwyn.h @@ -157,7 +157,6 @@ * board schematic and physical port wired to each. Then for host we * add mass storage support. */ -#define CONFIG_USB_MUSB_DISABLE_BULK_COMBINE_SPLIT #define CONFIG_AM335X_USB0 #define CONFIG_AM335X_USB0_MODEMUSB_PERIPHERAL #define CONFIG_AM335X_USB1 diff --git a/include/configs/siemens-am33x-common.h b/include/configs/siemens-am33x-common.h index f44a4280f435..1170f24748d9 100644 --- a/include/configs/siemens-am33x-common.h +++ b/include/configs/siemens-am33x-common.h @@ -150,8 +150,6 @@ /* * USB configuration */ -#define CONFIG_USB_MUSB_DISABLE_BULK_COMBINE_SPLIT - #define CONFIG_AM335X_USB0 #define CONFIG_AM335X_USB0_MODEMUSB_PERIPHERA
Re: [U-Boot] [PATCH v1] fdt: Fix mkimage list to try every header type
On Tue, Apr 9, 2019 at 6:36 PM Jordan Hand wrote: > > Signed-off-by: Jordan Hand > --- > Image type is not supplied to `mkimage -l`. For this reason, we cannot > use imagetool_verify_print_header_by_type. Instead, this patch uses > imagetool_verify_print_header to look through all header types to find > one where image validation succeeds. > Doesn't this text want to be part of the changelog and not below the marker? However, definitely fixes it up for me. Tested-by: Alex Kiernan -- Alex Kiernan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] fastboot: Replace literal 32 with PART_NAME_LEN
Where we have to compute partition names, rather than using a hardcoded
32 for the partition name length, replace with PART_NAME_LEN.
Signed-off-by: Alex Kiernan
---
drivers/fastboot/fb_mmc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/fastboot/fb_mmc.c b/drivers/fastboot/fb_mmc.c
index 4c1c7fd2cd8d..3cebedcd5a92 100644
--- a/drivers/fastboot/fb_mmc.c
+++ b/drivers/fastboot/fb_mmc.c
@@ -31,13 +31,13 @@ static int part_get_info_by_name_or_alias(struct blk_desc
*dev_desc,
ret = part_get_info_by_name(dev_desc, name, info);
if (ret < 0) {
- /* strlen("fastboot_partition_alias_") + 32(part_name) + 1 */
- char env_alias_name[25 + 32 + 1];
+ /* strlen("fastboot_partition_alias_") + PART_NAME_LEN + 1 */
+ char env_alias_name[25 + PART_NAME_LEN + 1];
char *aliased_part_name;
/* check for alias */
strcpy(env_alias_name, "fastboot_partition_alias_");
- strncat(env_alias_name, name, 32);
+ strncat(env_alias_name, name, PART_NAME_LEN);
aliased_part_name = env_get(env_alias_name);
if (aliased_part_name != NULL)
ret = part_get_info_by_name(dev_desc,
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] burning eMMC from sdcard.img in U-Boot
On Tue, Apr 2, 2019 at 9:59 PM Adam Ford wrote: > > I have a board with eMMC storage. I've been trying to find an elegant > solution to burning the sdcard image to eMMC. I looked at using the > USB mass storage gadget, but it's a bit slow. I was hoping to avoid > having to boot all the way into Linux to do it, but the sdcard.img > file is larger than the memory I have available. > > Does anyone have any suggestions on how to burn the contents of a file > to eMMC (or mmc/sd) from within U-Boot when the source file size may > vary and it's larger than the available memory, so it needs to be done > in blocks? > Convert to Android sparse format and use that? You still need the sparse image to fit into memory though. -- Alex Kiernan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] fastboot: Improve error reporting on 'getvar partition-{size, type}'
On Thu, Mar 28, 2019 at 1:32 PM Eugeniu Rosca wrote:
>
> Currently U-Boot reports the same error message in all below cases:
> [A] host> fastboot getvar partition-type
> [B] host> fastboot getvar partition-size
> [C] host> fastboot getvar partition-type:
> [D] host> fastboot getvar partition-size:
> [E] host> fastboot getvar partition-type:
> [F] host> fastboot getvar partition-size:
>
> The message looks like:
> host> fastboot getvar partition-size:
> getvar:partition-size: FAILED (remote: partition not found)
> Finished. Total time: 0.003s
>
> Be more user friendly and output:
> - "partition not given" for [A-D]
> - "partition not found" for [E-F]
>
> Fixes: f73a7df984a9 ("net: fastboot: Merge AOSP UDP fastboot")
> Signed-off-by: Eugeniu Rosca
Acked-by: Alex Kiernan
--
Alex Kiernan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] fastboot: getvar: fix broken 'fastboot flash' when partition has slots
On Wed, Mar 27, 2019 at 12:32 PM Eugeniu Rosca wrote:
>
> Hi Alex,
>
> Thanks for the precious comments. Some remarks below.
>
> On Wed, Mar 27, 2019 at 05:55:51AM +, Alex Kiernan wrote:
> > On Wed, Mar 27, 2019 at 5:44 AM Alex Kiernan wrote:
> > > On Wed, Mar 27, 2019 at 1:04 AM Eugeniu Rosca
> > > wrote:
> [..]
> > > > diff --git a/drivers/fastboot/fb_getvar.c b/drivers/fastboot/fb_getvar.c
> > > > index 4d264c985d7e..03bcd7162b37 100644
> > > > --- a/drivers/fastboot/fb_getvar.c
> > > > +++ b/drivers/fastboot/fb_getvar.c
> > > > @@ -130,8 +130,17 @@ static void getvar_slot_suffixes(char
> > > > *var_parameter, char *response)
> > > >
> > > > static void getvar_has_slot(char *part_name, char *response)
> > > > {
> > > > - if (part_name && (!strcmp(part_name, "boot") ||
> > > > - !strcmp(part_name, "system")))
> > > > + struct blk_desc *dev_desc;
> > > > + disk_partition_t info;
> > > > + char name[32];
> > >
> > > For the code as written this needs to be 33, or the strcat can
> > > overflow by 1.
> >
> > Sorry, wrong way around... can truncate the name by 1, not overflow.
>
> Applying below two-liner instrumentation on top of my patch:
>
> diff --git a/drivers/fastboot/fb_getvar.c b/drivers/fastboot/fb_getvar.c
> index c703be4cd61e..0149824c0d3d 100644
> --- a/drivers/fastboot/fb_getvar.c
> +++ b/drivers/fastboot/fb_getvar.c
> @@ -138,7 +138,9 @@ static void getvar_has_slot(char *part_name, char
> *response)
> return;
>
> strlcpy(name, part_name, sizeof(name) - 2);
> + printf("%s: name: %s, strlen(name) %lu\n", __func__, name,
> strlen(name));
> strcat(name, "_a");
> + printf("%s: name: %s, strlen(name) %lu\n", __func__, name,
> strlen(name));
>
> if (fastboot_mmc_get_part_info(name, _desc, , response) >= 0)
> fastboot_okay("yes", response);
>
> Passing a 32+ character part-name to 'getvar has-slot' results in:
> $ host> fastboot getvar
> has-slot:0123456789abcdef0123456789abcdef0123456789abcdef
> $ target>
> getvar_has_slot: name: 0123456789abcdef0123456789abc, strlen(name) 29
> getvar_has_slot: name: 0123456789abcdef0123456789abc_a, strlen(name) 31
>
> From the above results, it looks to me that the partition name handling
> (including deliberate string truncation done by strlcpy) works
> correctly. I am still ready to rework/optimize the implementation if
> you have any concerns/counter-proposals.
>
Looking at the rest of the code, there's confusion as to whether it's
expecting a +1 or not, given disk_partition.name[] is PART_NAME_LEN, I
think what you have is right.
> >
> > > Also we should use PART_NAME_LEN not 32 (fb_mmc.c needs
> > > fixing in the same way).
>
> Agreed. Will be fixed in v2.
>
> > > > +
> > > > + if (!part_name || !strcmp(part_name, ""))
> > > > + return;
> > >
> > > This needs to do fastboot_okay/fastboot_fail or you'll get the
> > > protocol out of sync
>
> The idea was to avoid bloating U-Boot with string literals, but I can
> add a fastboot_fail() call if you wish so. IMO if the lack of
> fastboot_okay/fastboot_fail at the end of dispatching a fastboot call
> triggers undefined behavior on host side, then long-term this should
> be fixed in the U-Boot fastboot dispatcher itself. FWIW, the current
> behavior on my target is:
>
> host $> fastboot getvar has-slot
> getvar:has-slot FAILED (status malformed (0 bytes))
> Finished. Total time: 0.039s
> host $> fastboot getvar has-slot:
> getvar:has-slot: FAILED (status malformed (0 bytes))
> Finished. Total time: 0.039s
>
"status malformed" is a pretty poor failure. The other thing is check
both the UDP and USB paths - the UDP path gets stuck in timeouts if
you don't send something which is within the protocol (though probably
not for this case).
I'd agree that the structure is awkward - if you're looking at
implementing `getvar all` then I expect it all have to be refactored
as my recollection is for multiple values you have to send them as
INFO frames.
> > > > +
> > > > + strlcpy(name, part_name, sizeof(name) - 2);
> > > > + strcat(name, "_a");
> > > > +
> > > > + if (fastboot_mmc_get_part_info(name, _desc, ,
> > > > response) >= 0)
> > > > fastboot_okay("
Re: [U-Boot] [PATCH] fastboot: getvar: fix broken 'fastboot flash' when partition has slots
On Wed, Mar 27, 2019 at 5:44 AM Alex Kiernan wrote:
>
> On Wed, Mar 27, 2019 at 1:04 AM Eugeniu Rosca wrote:
> >
> > With eMMC partitioning [1], 'fastboot getvar has-slot:'
> > returns 'yes' only for 'system' and 'boot', while it is clear that [1]
> > has more partitions featuring slots (i.e. dtb, dtbo, vbmeta and vendor).
> >
> > One not so obvious consequence is that
> > 'fastboot flash {dtb,dtbo,vbmeta,vendor} img' will fail [2], while
> > 'fastboot flash {boot,system} img' will succeed [3]. This is because
> > 'fastboot flash' relies on the outcome of
> > 'fastboot has-slot:' behind the scene.
> >
> > Assuming that the list of partitions featuring slots is vendor-
> > specific, U-Boot fastboot driver is not the best place for such list.
> >
> > To avoid creating __weak functions overridden by board code, one simple
> > solution seems to be taking the user-provided partition as base, append
> > the "_a" suffix and checking if the result is a valid partition name.
> >
> > This approach assumes that the 'has-slot:' API is specifically
> > designed to work with partition names chopped of their slot suffixes.
> > Reviewing the usage of 'has-slot' in upstream fastboot [4], this
> > assumption seems to be fortified, but to be 100% sure we need an Ack
> > from a fastboot expert.
> >
> > [1] R-Car-H3 eMMC partitioning used for testing:
> > (bootloader) Created new GPT partition table:
> > (bootloader) /misc (512 KiB, raw)
> > (bootloader) /pst (512 KiB, raw)
> > (bootloader) /vbmeta_a (512 KiB, raw)
> > (bootloader) /vbmeta_b (512 KiB, raw)
> > (bootloader) /dtb_a (1024 KiB, raw)
> > (bootloader) /dtb_b (1024 KiB, raw)
> > (bootloader) /dtbo_a (512 KiB, raw)
> > (bootloader) /dtbo_b (512 KiB, raw)
> > (bootloader) /boot_a (16384 KiB, raw)
> > (bootloader) /boot_b (16384 KiB, raw)
> > (bootloader) /metadata (16384 KiB, raw)
> > (bootloader) /system_a (2301952 KiB, ext4)
> > (bootloader) /system_b (2301952 KiB, ext4)
> > (bootloader) /vendor_a (262144 KiB, ext4)
> > (bootloader) /vendor_b (262144 KiB, ext4)
> > (bootloader) /userdata (2451951 KiB, ext4)
> >
> > [2] fastboot flash vbmeta vbmeta.img
> > target reported max download size of 16777216 bytes
> > Sending 'vbmeta' (4 KB)...
> > OKAY [ 0.025s]
> > Writing 'vbmeta'...
> > FAILED (remote: cannot find partition)
> > Finished. Total time: 0.332s
> >
> > [3] fastboot flash boot boot.img
> > target reported max download size of 16777216 bytes
> > Sending 'boot_a' (16384 KB)...
> > OKAY [ 1.586s]
> > Writing 'boot_a'...
> > OKAY [ 0.379s]
> > Finished. Total time: 2.054s
> >
> > [4] core (f959fffc1c8c) git grep -l has-slot
> > fastboot/constants.h
> > fastboot/fastboot.cpp
> > fastboot/fuzzy_fastboot/main.cpp
> > fs_mgr/tests/adb-remount-test.sh
> >
> > Fixes: f73a7df984a9 ("net: fastboot: Merge AOSP UDP fastboot")
> > Signed-off-by: Eugeniu Rosca
> > ---
> > drivers/fastboot/fb_getvar.c | 13 +++--
> > 1 file changed, 11 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/fastboot/fb_getvar.c b/drivers/fastboot/fb_getvar.c
> > index 4d264c985d7e..03bcd7162b37 100644
> > --- a/drivers/fastboot/fb_getvar.c
> > +++ b/drivers/fastboot/fb_getvar.c
> > @@ -130,8 +130,17 @@ static void getvar_slot_suffixes(char *var_parameter,
> > char *response)
> >
> > static void getvar_has_slot(char *part_name, char *response)
> > {
> > - if (part_name && (!strcmp(part_name, "boot") ||
> > - !strcmp(part_name, "system")))
> > + struct blk_desc *dev_desc;
> > + disk_partition_t info;
> > + char name[32];
>
> For the code as written this needs to be 33, or the strcat can
> overflow by 1.
Sorry, wrong way around... can truncate the name by 1, not overflow.
> Also we should use PART_NAME_LEN not 32 (fb_mmc.c needs
> fixing in the same way).
>
> > +
> > + if (!part_name || !strcmp(part_name, ""))
> > + return;
>
> This needs to do fastboot_okay/fastboot_fail or you'll get the
> protocol out of sync
>
> > +
> > + strlcpy(name, part_name, sizeof(name) - 2);
> > + strcat(name, "_a");
> > +
> > + if (fastboot_mmc_get_part_info(name, _desc, , response) >=
> > 0)
> > fastboot_okay("yes", response);
> > else
> > fastboot_okay("no", response);
>
> This will fail if you're building with CONFIG_FASTBOOT_FLASH_NAND.
> Also fastboot_mmc_get_part_info() sends its own fastboot_fail so this
> just isn't going to work in a failure case.
>
> > --
> > 2.21.0
> >
>
>
> --
> Alex Kiernan
--
Alex Kiernan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] fastboot: getvar: fix broken 'fastboot flash' when partition has slots
On Wed, Mar 27, 2019 at 1:04 AM Eugeniu Rosca wrote:
>
> With eMMC partitioning [1], 'fastboot getvar has-slot:'
> returns 'yes' only for 'system' and 'boot', while it is clear that [1]
> has more partitions featuring slots (i.e. dtb, dtbo, vbmeta and vendor).
>
> One not so obvious consequence is that
> 'fastboot flash {dtb,dtbo,vbmeta,vendor} img' will fail [2], while
> 'fastboot flash {boot,system} img' will succeed [3]. This is because
> 'fastboot flash' relies on the outcome of
> 'fastboot has-slot:' behind the scene.
>
> Assuming that the list of partitions featuring slots is vendor-
> specific, U-Boot fastboot driver is not the best place for such list.
>
> To avoid creating __weak functions overridden by board code, one simple
> solution seems to be taking the user-provided partition as base, append
> the "_a" suffix and checking if the result is a valid partition name.
>
> This approach assumes that the 'has-slot:' API is specifically
> designed to work with partition names chopped of their slot suffixes.
> Reviewing the usage of 'has-slot' in upstream fastboot [4], this
> assumption seems to be fortified, but to be 100% sure we need an Ack
> from a fastboot expert.
>
> [1] R-Car-H3 eMMC partitioning used for testing:
> (bootloader) Created new GPT partition table:
> (bootloader) /misc (512 KiB, raw)
> (bootloader) /pst (512 KiB, raw)
> (bootloader) /vbmeta_a (512 KiB, raw)
> (bootloader) /vbmeta_b (512 KiB, raw)
> (bootloader) /dtb_a (1024 KiB, raw)
> (bootloader) /dtb_b (1024 KiB, raw)
> (bootloader) /dtbo_a (512 KiB, raw)
> (bootloader) /dtbo_b (512 KiB, raw)
> (bootloader) /boot_a (16384 KiB, raw)
> (bootloader) /boot_b (16384 KiB, raw)
> (bootloader) /metadata (16384 KiB, raw)
> (bootloader) /system_a (2301952 KiB, ext4)
> (bootloader) /system_b (2301952 KiB, ext4)
> (bootloader) /vendor_a (262144 KiB, ext4)
> (bootloader) /vendor_b (262144 KiB, ext4)
> (bootloader) /userdata (2451951 KiB, ext4)
>
> [2] fastboot flash vbmeta vbmeta.img
> target reported max download size of 16777216 bytes
> Sending 'vbmeta' (4 KB)...
> OKAY [ 0.025s]
> Writing 'vbmeta'...
> FAILED (remote: cannot find partition)
> Finished. Total time: 0.332s
>
> [3] fastboot flash boot boot.img
> target reported max download size of 16777216 bytes
> Sending 'boot_a' (16384 KB)...
> OKAY [ 1.586s]
> Writing 'boot_a'...
> OKAY [ 0.379s]
> Finished. Total time: 2.054s
>
> [4] core (f959fffc1c8c) git grep -l has-slot
> fastboot/constants.h
> fastboot/fastboot.cpp
> fastboot/fuzzy_fastboot/main.cpp
> fs_mgr/tests/adb-remount-test.sh
>
> Fixes: f73a7df984a9 ("net: fastboot: Merge AOSP UDP fastboot")
> Signed-off-by: Eugeniu Rosca
> ---
> drivers/fastboot/fb_getvar.c | 13 +++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/fastboot/fb_getvar.c b/drivers/fastboot/fb_getvar.c
> index 4d264c985d7e..03bcd7162b37 100644
> --- a/drivers/fastboot/fb_getvar.c
> +++ b/drivers/fastboot/fb_getvar.c
> @@ -130,8 +130,17 @@ static void getvar_slot_suffixes(char *var_parameter,
> char *response)
>
> static void getvar_has_slot(char *part_name, char *response)
> {
> - if (part_name && (!strcmp(part_name, "boot") ||
> - !strcmp(part_name, "system")))
> + struct blk_desc *dev_desc;
> + disk_partition_t info;
> + char name[32];
For the code as written this needs to be 33, or the strcat can
overflow by 1. Also we should use PART_NAME_LEN not 32 (fb_mmc.c needs
fixing in the same way).
> +
> + if (!part_name || !strcmp(part_name, ""))
> + return;
This needs to do fastboot_okay/fastboot_fail or you'll get the
protocol out of sync
> +
> + strlcpy(name, part_name, sizeof(name) - 2);
> + strcat(name, "_a");
> +
> + if (fastboot_mmc_get_part_info(name, _desc, , response) >= 0)
> fastboot_okay("yes", response);
> else
> fastboot_okay("no", response);
This will fail if you're building with CONFIG_FASTBOOT_FLASH_NAND.
Also fastboot_mmc_get_part_info() sends its own fastboot_fail so this
just isn't going to work in a failure case.
> --
> 2.21.0
>
--
Alex Kiernan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] fastboot: getvar: correct/rename "has_slot" to "has-slot"
On Tue, Mar 26, 2019 at 4:46 PM Eugeniu Rosca wrote:
>
> Since its inception in upstream fastboot android-n-preview-1 [1],
> "has-slot" option has never taken the form of "has_slot". Amongst the
> users of "getvar has-slot:" is the upstream bootloadertest.py [2].
>
> Current U-Boot "has_slot" version must be a typo. Fix it.
>
Looks like it... typo when pulling from Android things U-Boot:
https://android.googlesource.com/platform/external/u-boot/+/android-o-mr1-iot-preview-8/net/fastboot.c#274
> [1] https://android.googlesource.com/platform/system/core/+/a797479bd51c
> ("Fix fastboot variable name")
> [2] https://android.googlesource.com/platform/system/extras/+/72de393e118e3
> ("Bootloader verification for AndroidThings.")
>
> Fixes: f73a7df984a9 ("net: fastboot: Merge AOSP UDP fastboot")
> Signed-off-by: Eugeniu Rosca
Acked-by: Alex Kiernan
> ---
> drivers/fastboot/fb_getvar.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/fastboot/fb_getvar.c b/drivers/fastboot/fb_getvar.c
> index 4d264c985d7e..91a774a345b6 100644
> --- a/drivers/fastboot/fb_getvar.c
> +++ b/drivers/fastboot/fb_getvar.c
> @@ -62,7 +62,7 @@ static const struct {
> .variable = "slot-suffixes",
> .dispatch = getvar_slot_suffixes
> }, {
> - .variable = "has_slot",
> + .variable = "has-slot",
> .dispatch = getvar_has_slot
> #if CONFIG_IS_ENABLED(FASTBOOT_FLASH_MMC)
> }, {
> --
> 2.21.0
>
--
Alex Kiernan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] spl: avoid printf when we might be doing Ymodem with CONFIG_SPL_FIT_SIGNATURE
On Thu, Mar 21, 2019 at 2:58 AM Marek Vasut wrote:
>
> On 3/20/19 8:52 PM, Alex Kiernan wrote:
> > If CONFIG_SPL_FIT_SIGNATURE is enabled and U-Boot is being loaded from UART
> > over Ymodem then we can't emit messages using printf() without causing
> > errors like:
> >
> > Sending: u-boot-dtb.img
> > Ymodem sectors/kbytes sent: 3009/376kRetry 0: Got 23 for sector ACK
> > Retry 0: NAK on sector
> > Retry 0: Got 68 for sector ACK
> > Retry 0: NAK on sector
> > Ymodem sectors/kbytes sent: 3273/409kRetry 0: Got 23 for sector ACK
> > Retry 0: NAK on sector
> > Retry 0: Got 68 for sector ACK
> > Retry 0: NAK on sector
> >
> > Use debug() rather than printf() to avoid sending messages on the serial
> > port.
> >
> > Signed-off-by: Alex Kiernan
> > ---
> >
> > common/spl/spl_fit.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
> > index db436268cbcd..08faf2c1b058 100644
> > --- a/common/spl/spl_fit.c
> > +++ b/common/spl/spl_fit.c
> > @@ -240,12 +240,12 @@ static int spl_load_fit_image(struct spl_load_info
> > *info, ulong sector,
> > }
> >
> > #ifdef CONFIG_SPL_FIT_SIGNATURE
> > - printf("## Checking hash(es) for Image %s ... ",
> > -fit_get_name(fit, node, NULL));
> > + debug("## Checking hash(es) for Image %s ... ",
> > + fit_get_name(fit, node, NULL));
> > if (!fit_image_verify_with_data(fit, node,
> >src, length))
> > return -EPERM;
> > - puts("OK\n");
> > + debug("OK\n");
> > #endif
>
> Checking printf("Signature failed") to debug() is probably not what you
> want to do. It'd be hiding some pretty important output.
>
I'm not sure what message you do get in that case (since so far I've
failed to get keys into the SPL DTB in a way that seem to actually get
checked), but I take your point.
I can't see any mechanism for either buffering or discarding console
message when Ymodem is active, or am I just missing it, or anything
else that would address this problem?
--
Alex Kiernan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] spl: avoid printf when we might be doing Ymodem with CONFIG_SPL_FIT_SIGNATURE
If CONFIG_SPL_FIT_SIGNATURE is enabled and U-Boot is being loaded from UART
over Ymodem then we can't emit messages using printf() without causing
errors like:
Sending: u-boot-dtb.img
Ymodem sectors/kbytes sent: 3009/376kRetry 0: Got 23 for sector ACK
Retry 0: NAK on sector
Retry 0: Got 68 for sector ACK
Retry 0: NAK on sector
Ymodem sectors/kbytes sent: 3273/409kRetry 0: Got 23 for sector ACK
Retry 0: NAK on sector
Retry 0: Got 68 for sector ACK
Retry 0: NAK on sector
Use debug() rather than printf() to avoid sending messages on the serial
port.
Signed-off-by: Alex Kiernan
---
common/spl/spl_fit.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index db436268cbcd..08faf2c1b058 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -240,12 +240,12 @@ static int spl_load_fit_image(struct spl_load_info *info,
ulong sector,
}
#ifdef CONFIG_SPL_FIT_SIGNATURE
- printf("## Checking hash(es) for Image %s ... ",
- fit_get_name(fit, node, NULL));
+ debug("## Checking hash(es) for Image %s ... ",
+ fit_get_name(fit, node, NULL));
if (!fit_image_verify_with_data(fit, node,
src, length))
return -EPERM;
- puts("OK\n");
+ debug("OK\n");
#endif
#ifdef CONFIG_SPL_FIT_IMAGE_POST_PROCESS
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 01/34] Add target to generate initial environment
On Wed, Mar 13, 2019 at 8:47 AM Stefano Babic wrote: > > The initial environment is linked to the u-boot binary. Modifying the > environment from User Space with the env tools requires that the tools > are always built together with the bootloader to be sure that they > contain the initial environment in case no environment is stored into > persistent storage or when a board boots with just the default > environment. This makes difficult for distros to provide a general > package to access the environment. A simpler way is if the tools are > generic for all boards and a configuration file is given to provide the > initial environment. > > The patch just generates the initial environment by extracting it from > the compiled object. This file can then be used for tools in user space > to initialize the environment. > > Signed-off-by: Stefano Babic > --- > Makefile | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/Makefile b/Makefile > index 26db4e7b59..74e48ae9dc 100644 > --- a/Makefile > +++ b/Makefile > @@ -1932,6 +1932,13 @@ endif > $(build)=$(build-dir) $(@:.ko=.o) > $(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modpost > > +quiet_cmd_genenv = GENENV $@ > +cmd_genenv = $(OBJCOPY) --dump-section .rodata.default_environment=$@ > env/common.o; \ > + sed --in-place -e 's/\x00/\x0A/g' $@ > + Really an observation rather than an objection - there are boards which have newlines embedded in their compiled in environments - ge_bx50v3 and mx53ppd (the failbootcmd variable) are the two I know of. > +u-boot-initial-env: u-boot.bin > + $(call if_changed,genenv) > + > # Consistency checks > # --- > > -- > 2.17.1 > > _______ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot -- Alex Kiernan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] configs: Migrate USB_MUSB_DISABLE_BULK_COMBINE_SPLIT to Kconfig
Migrate support for disable MUSB bulk split/combine to Kconfig Green Travis build: https://travis-ci.org/akiernan/u-boot/builds/497722366 Signed-off-by: Alex Kiernan --- drivers/usb/musb-new/Kconfig | 9 + include/configs/am335x_evm.h | 1 - include/configs/baltos.h | 1 - include/configs/bav335x.h | 1 - include/configs/brppt1.h | 3 --- include/configs/brxre1.h | 3 --- include/configs/chiliboard.h | 1 - include/configs/pengwyn.h | 1 - include/configs/siemens-am33x-common.h | 2 -- scripts/config_whitelist.txt | 1 - 10 files changed, 9 insertions(+), 14 deletions(-) diff --git a/drivers/usb/musb-new/Kconfig b/drivers/usb/musb-new/Kconfig index f8f2205a62d3..fdf9ca61da06 100644 --- a/drivers/usb/musb-new/Kconfig +++ b/drivers/usb/musb-new/Kconfig @@ -54,6 +54,15 @@ config USB_MUSB_SUNXI Say y here to enable support for the sunxi OTG / DRC USB controller used on almost all sunxi boards. +config USB_MUSB_DISABLE_BULK_COMBINE_SPLIT + bool "Disable MUSB bulk split/combine" + default y + help + On TI AM335x devices, MUSB has bulk split/combine feature enabled + in the ConfigData register, but the current MUSB driver does not + support it yet. Select this option to disable the feature until the + driver adds the support. + endif config USB_MUSB_PIO_ONLY diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h index 3bd96b921b7d..b3c1279707e1 100644 --- a/include/configs/am335x_evm.h +++ b/include/configs/am335x_evm.h @@ -240,7 +240,6 @@ * add mass storage support and for gadget we add both RNDIS ethernet * and DFU. */ -#define CONFIG_USB_MUSB_DISABLE_BULK_COMBINE_SPLIT #define CONFIG_AM335X_USB0 #define CONFIG_AM335X_USB0_MODEMUSB_PERIPHERAL #define CONFIG_AM335X_USB1 diff --git a/include/configs/baltos.h b/include/configs/baltos.h index ccbdc0a33566..98ec0d626ea8 100644 --- a/include/configs/baltos.h +++ b/include/configs/baltos.h @@ -251,7 +251,6 @@ * add mass storage support and for gadget we add both RNDIS ethernet * and DFU. */ -#define CONFIG_USB_MUSB_DISABLE_BULK_COMBINE_SPLIT #define CONFIG_AM335X_USB0 #define CONFIG_AM335X_USB0_MODEMUSB_HOST #define CONFIG_AM335X_USB1 diff --git a/include/configs/bav335x.h b/include/configs/bav335x.h index df5d5bdc4a91..1fec50e48b7e 100644 --- a/include/configs/bav335x.h +++ b/include/configs/bav335x.h @@ -387,7 +387,6 @@ DEFAULT_LINUX_BOOT_ENV \ * add mass storage support and for gadget we add both RNDIS ethernet * and DFU. */ -#define CONFIG_USB_MUSB_DISABLE_BULK_COMBINE_SPLIT #define CONFIG_AM335X_USB0 #define CONFIG_AM335X_USB0_MODEMUSB_PERIPHERAL #define CONFIG_AM335X_USB1 diff --git a/include/configs/brppt1.h b/include/configs/brppt1.h index 5badd2da8b6c..9e06cbafd1e2 100644 --- a/include/configs/brppt1.h +++ b/include/configs/brppt1.h @@ -182,9 +182,6 @@ NANDTGTS \ #define CONFIG_NAND_OMAP_GPMC_WSCFG1 #endif /* CONFIG_NAND */ -/* USB configuration */ -#define CONFIG_USB_MUSB_DISABLE_BULK_COMBINE_SPLIT - #if defined(CONFIG_SPI) /* SPI Flash */ #define CONFIG_SF_DEFAULT_SPEED2400 diff --git a/include/configs/brxre1.h b/include/configs/brxre1.h index 601b30dffd5f..7309e7d4831d 100644 --- a/include/configs/brxre1.h +++ b/include/configs/brxre1.h @@ -68,9 +68,6 @@ BUR_COMMON_ENV \ #define CONFIG_SETUP_MEMORY_TAGS #define CONFIG_INITRD_TAG -/* USB configuration */ -#define CONFIG_USB_MUSB_DISABLE_BULK_COMBINE_SPLIT - /* Environment */ #define CONFIG_SYS_MMC_ENV_DEV 1 #define CONFIG_SYS_MMC_ENV_PART2 diff --git a/include/configs/chiliboard.h b/include/configs/chiliboard.h index 4372280d2bbe..db990fcb2b47 100644 --- a/include/configs/chiliboard.h +++ b/include/configs/chiliboard.h @@ -148,7 +148,6 @@ /* USB configuration */ #define CONFIG_ARCH_MISC_INIT -#define CONFIG_USB_MUSB_DISABLE_BULK_COMBINE_SPLIT #define CONFIG_AM335X_USB1 #define CONFIG_AM335X_USB1_MODE MUSB_HOST diff --git a/include/configs/pengwyn.h b/include/configs/pengwyn.h index 48f1f7baccba..a535d0c2f2d0 100644 --- a/include/configs/pengwyn.h +++ b/include/configs/pengwyn.h @@ -157,7 +157,6 @@ * board schematic and physical port wired to each. Then for host we * add mass storage support. */ -#define CONFIG_USB_MUSB_DISABLE_BULK_COMBINE_SPLIT #define CONFIG_AM335X_USB0 #define CONFIG_AM335X_USB0_MODEMUSB_PERIPHERAL #define CONFIG_AM335X_USB1 diff --git a/include/configs/siemens-am33x-common.h b/include/configs/siemens-am33x-common.h index d8ed02bf7955..570bc2a8c5fc 100644 --- a/include/configs/siemens-am33x-common.h +++ b/include/configs/siemens-am33x-common.h @@ -152,8 +152,6 @@ /* * USB configuration */ -#define CONFIG_USB_MUSB_DISABLE_BULK_COMBINE_SPLIT - #define CONFIG_AM335X_USB0 #define CONFIG_AM335X_USB0_MODEMUSB_
[U-Boot] [PATCH] usb: Select USB_MUSB_DSPS with USB_MUSB_TI
USB_MUSB_TI requires USB_MUSB_DSPS, failing at link time if it's not selected: drivers/usb/musb-new/built-in.o: In function `ti_musb_host_ofdata_to_platdata': drivers/usb/musb-new/ti-musb.c:193: undefined reference to `musb_dsps_ops' Signed-off-by: Alex Kiernan --- configs/am335x_boneblack_vboot_defconfig | 1 - configs/am335x_evm_defconfig | 1 - configs/am335x_hs_evm_defconfig | 1 - configs/am335x_hs_evm_uart_defconfig | 1 - configs/brppt1_mmc_defconfig | 1 - configs/brppt1_nand_defconfig| 1 - configs/brppt1_spi_defconfig | 1 - configs/chiliboard_defconfig | 1 - drivers/usb/musb-new/Kconfig | 1 + 9 files changed, 1 insertion(+), 8 deletions(-) diff --git a/configs/am335x_boneblack_vboot_defconfig b/configs/am335x_boneblack_vboot_defconfig index f455b01e1e81..f4bf88b5e094 100644 --- a/configs/am335x_boneblack_vboot_defconfig +++ b/configs/am335x_boneblack_vboot_defconfig @@ -55,7 +55,6 @@ CONFIG_SPL_DM_USB_GADGET=y CONFIG_USB_MUSB_HOST=y CONFIG_USB_MUSB_GADGET=y CONFIG_USB_MUSB_TI=y -CONFIG_USB_MUSB_DSPS=y CONFIG_USB_GADGET=y CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments" CONFIG_USB_GADGET_VENDOR_NUM=0x0451 diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig index 924116835251..962feedd1279 100644 --- a/configs/am335x_evm_defconfig +++ b/configs/am335x_evm_defconfig @@ -61,7 +61,6 @@ CONFIG_SPL_DM_USB_GADGET=y CONFIG_USB_MUSB_HOST=y CONFIG_USB_MUSB_GADGET=y CONFIG_USB_MUSB_TI=y -CONFIG_USB_MUSB_DSPS=y CONFIG_USB_GADGET=y CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments" CONFIG_USB_GADGET_VENDOR_NUM=0x0451 diff --git a/configs/am335x_hs_evm_defconfig b/configs/am335x_hs_evm_defconfig index faa6c2b05fcd..3c9d385b049a 100644 --- a/configs/am335x_hs_evm_defconfig +++ b/configs/am335x_hs_evm_defconfig @@ -60,7 +60,6 @@ CONFIG_DM_USB=y CONFIG_USB_MUSB_HOST=y CONFIG_USB_MUSB_GADGET=y CONFIG_USB_MUSB_TI=y -CONFIG_USB_MUSB_DSPS=y CONFIG_USB_GADGET=y CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments" CONFIG_USB_GADGET_VENDOR_NUM=0x0451 diff --git a/configs/am335x_hs_evm_uart_defconfig b/configs/am335x_hs_evm_uart_defconfig index 02332db0a6e9..9d970849cf66 100644 --- a/configs/am335x_hs_evm_uart_defconfig +++ b/configs/am335x_hs_evm_uart_defconfig @@ -62,7 +62,6 @@ CONFIG_DM_USB=y CONFIG_USB_MUSB_HOST=y CONFIG_USB_MUSB_GADGET=y CONFIG_USB_MUSB_TI=y -CONFIG_USB_MUSB_DSPS=y CONFIG_USB_GADGET=y CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments" CONFIG_USB_GADGET_VENDOR_NUM=0x0451 diff --git a/configs/brppt1_mmc_defconfig b/configs/brppt1_mmc_defconfig index f2d822012619..3d2f0737fdf2 100644 --- a/configs/brppt1_mmc_defconfig +++ b/configs/brppt1_mmc_defconfig @@ -83,7 +83,6 @@ CONFIG_DM_USB=y CONFIG_USB_MUSB_HOST=y CONFIG_USB_MUSB_GADGET=y CONFIG_USB_MUSB_TI=y -CONFIG_USB_MUSB_DSPS=y CONFIG_USB_STORAGE=y CONFIG_USB_GADGET=y CONFIG_FAT_WRITE=y diff --git a/configs/brppt1_nand_defconfig b/configs/brppt1_nand_defconfig index 275727d11f32..02dc03542c1d 100644 --- a/configs/brppt1_nand_defconfig +++ b/configs/brppt1_nand_defconfig @@ -87,7 +87,6 @@ CONFIG_DM_USB=y CONFIG_USB_MUSB_HOST=y CONFIG_USB_MUSB_GADGET=y CONFIG_USB_MUSB_TI=y -CONFIG_USB_MUSB_DSPS=y CONFIG_USB_STORAGE=y CONFIG_USB_GADGET=y CONFIG_FAT_WRITE=y diff --git a/configs/brppt1_spi_defconfig b/configs/brppt1_spi_defconfig index 668c4c22c27f..3619587bdc5c 100644 --- a/configs/brppt1_spi_defconfig +++ b/configs/brppt1_spi_defconfig @@ -97,7 +97,6 @@ CONFIG_DM_USB=y CONFIG_USB_MUSB_HOST=y CONFIG_USB_MUSB_GADGET=y CONFIG_USB_MUSB_TI=y -CONFIG_USB_MUSB_DSPS=y CONFIG_USB_STORAGE=y CONFIG_USB_GADGET=y CONFIG_FAT_WRITE=y diff --git a/configs/chiliboard_defconfig b/configs/chiliboard_defconfig index a6c36eda503d..944dd0db3c87 100644 --- a/configs/chiliboard_defconfig +++ b/configs/chiliboard_defconfig @@ -50,6 +50,5 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_MUSB_HOST=y CONFIG_USB_MUSB_TI=y -CONFIG_USB_MUSB_DSPS=y CONFIG_FAT_WRITE=y CONFIG_LZO=y diff --git a/drivers/usb/musb-new/Kconfig b/drivers/usb/musb-new/Kconfig index f8f2205a62d3..1dd823037bec 100644 --- a/drivers/usb/musb-new/Kconfig +++ b/drivers/usb/musb-new/Kconfig @@ -21,6 +21,7 @@ config USB_MUSB_GADGET config USB_MUSB_TI bool "Enable TI OTG USB controller" depends on DM_USB + select USB_MUSB_DSPS default n help Say y here to enable support for the dual role high -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Proposed fastboot changes
On Tue, Jan 15, 2019 at 11:04 PM Douglas Zobel wrote: > > On Tue, Jan 15, 2019 at 4:12 AM Alex Kiernan wrote: >> >> On Mon, Jan 14, 2019 at 8:49 PM Douglas Zobel >> wrote: >> > >> > I've made some changes to the fastboot handlers to meet my needs. If >> > there is interest, I can prepare patches and submit them upstream. The >> > changes are: >> > >> > BUGFIX: Currently the 'fastboot format [partition]' command (run from PC) >> > formats the partition smaller than expected. Change >> > getvar_partition_size() to return partition size in # of bytes instead of >> > the current behavior of # of blocks. The 'fastboot format [partition]' >> > command expect u-boot to return the size in number of bytes in order to >> > format the partition correctly. >> > >> > Make the a fastboot oem command handler with a dynamic lookup like the >> > base fastboot command handler currently is. This would allow easily >> > adding new oem commands in the baseline software (such as below). It >> > would also allow for board files to extend the oem handler to handle OEM >> > specific cases. I would use a weakly defined default oem command handler >> > (empty function) which a board file can optionally override to handle >> > board specific commands. >> > >> > Currently the 'fastboot oem format' command (gpt write mmc # $partitions) >> > is supported. I'd like to add a 'fastboot oem verify' (gpt verify mmc # >> > $partitions) to help the flashing PC detect when a board needs to be >> > re-formatted. >> > >> >> I'd no need for it, but when I did all of the changes to add UDP >> support, my intention was that you'd implement oem command using >> linker lists, at that point you can plug in whatever you need. >> > > I don't understand what you mean by linker lists. Can you give an example? > The most obvious example is the command handling in U-Boot - include/command.h and the macro U_BOOT_CMD_MKENT. The definitions for linker lists themselves are in include/linker_lists.h. -- Alex Kiernan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Proposed fastboot changes
On Mon, Jan 14, 2019 at 8:49 PM Douglas Zobel wrote: > > I've made some changes to the fastboot handlers to meet my needs. If there > is interest, I can prepare patches and submit them upstream. The changes are: > > BUGFIX: Currently the 'fastboot format [partition]' command (run from PC) > formats the partition smaller than expected. Change getvar_partition_size() > to return partition size in # of bytes instead of the current behavior of # > of blocks. The 'fastboot format [partition]' command expect u-boot to return > the size in number of bytes in order to format the partition correctly. > > Make the a fastboot oem command handler with a dynamic lookup like the base > fastboot command handler currently is. This would allow easily adding new > oem commands in the baseline software (such as below). It would also allow > for board files to extend the oem handler to handle OEM specific cases. I > would use a weakly defined default oem command handler (empty function) which > a board file can optionally override to handle board specific commands. > > Currently the 'fastboot oem format' command (gpt write mmc # $partitions) is > supported. I'd like to add a 'fastboot oem verify' (gpt verify mmc # > $partitions) to help the flashing PC detect when a board needs to be > re-formatted. > I'd no need for it, but when I did all of the changes to add UDP support, my intention was that you'd implement oem command using linker lists, at that point you can plug in whatever you need. -- Alex Kiernan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] dm: pinctrl: Prevent (re-)configuring pins when already done before relocation
On Tue, Jan 8, 2019 at 11:24 PM Lukasz Majewski wrote: > > Hi Alex, > > > On Tue, Jan 8, 2019 at 10:52 PM Lukasz Majewski wrote: > > > > > > Hi Alex, > > > > > > > On Thu, Dec 27, 2018 at 3:49 PM Tom Rini > > > > wrote: > > > > > > > > > > On Tue, Dec 18, 2018 at 12:30:50PM +0100, Lukasz Majewski wrote: > > > > > > > > > > > This commit prevents from re-configuring pins if those were > > > > > > configured before relocation. > > > > > > > > > > > > Some pins - like UART or DDR must be setup before relocation > > > > > > (as they have 'u-boot,dm-pre-reloc' property set in DTS). > > > > > > Without this change, those pins are re-configured after > > > > > > relocation (pre_reloc_only = 0, so we do not "continue"). > > > > > > Such behavior may be a problem for DDR PAD configuration, as > > > > > > they might be already leveled/tuned with original setup). > > > > > > > > > > > > Signed-off-by: Lukasz Majewski > > > > > > > > > > Applied to u-boot/master, thanks! > > > > > > > > > > > > > I've bisected out to this commit and it's slightly broken things > > > > for me on an AM3352. It all works fine so long as I boot MLO from > > > > MMC (so the MMC is probed, pinctrl setup), but if I boot from > > > > UART then I get to full U-Boot, MMC hasn't been probed and the > > > > pinmuxing isn't set up for the MMC. > > > > > > I suppose that the pinmux node have set "u-boot,dm-pre-reloc" > > > property? > > > > > > > Yeah, well "u-boot,dm-spl", though now I re-read the docs I guess > > that's equivalent to "u-boot,dm-pre-reloc" as I've no TPL. > > I do need to check this -> as in my case I do have > "u-boot,dm-pre-reloc" property. And yes, in my case I do not have TPL > too (just SPL). > > > > > > The problem is not with lack of eMMC probing - it is with pinctrl > > > nodes having "u-boot,dm-pre-reloc" set in DTS and the eMMC is > > > probed after MLO/SPL. > > > It looks like your use case implicitly depends on pinmux being > > > reconfigured no matter if we are pre-relocated (MLO) or afterwards. > > > > > > > Yes, that's a much clearer description... > > Frankly, your mail opened my eyes to a use case which was handled (I > assume on purpose) with the old code - the "cross" boot with pinmux > and devices. > > For example boot from UART (MLO/SPL) and then continue with eMMC (which > require pinmux). > So I guess this needs something like a bloblist to communicate the initialisation state between MLO/SPL and u-boot, which I've not the faintest idea where to start on. Horrible as they are, is a CONFIG symbol a possibility whilst we figure out how to solve this properly? I guess another option would be an additional two properties that give the two behaviours, but that feels like something we don't want long term. -- Alex Kiernan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] dm: pinctrl: Prevent (re-)configuring pins when already done before relocation
On Tue, Jan 8, 2019 at 10:52 PM Lukasz Majewski wrote: > > Hi Alex, > > > On Thu, Dec 27, 2018 at 3:49 PM Tom Rini wrote: > > > > > > On Tue, Dec 18, 2018 at 12:30:50PM +0100, Lukasz Majewski wrote: > > > > > > > This commit prevents from re-configuring pins if those were > > > > configured before relocation. > > > > > > > > Some pins - like UART or DDR must be setup before relocation > > > > (as they have 'u-boot,dm-pre-reloc' property set in DTS). Without > > > > this change, those pins are re-configured after relocation > > > > (pre_reloc_only = 0, so we do not "continue"). > > > > Such behavior may be a problem for DDR PAD configuration, as they > > > > might be already leveled/tuned with original setup). > > > > > > > > Signed-off-by: Lukasz Majewski > > > > > > Applied to u-boot/master, thanks! > > > > > > > I've bisected out to this commit and it's slightly broken things for > > me on an AM3352. It all works fine so long as I boot MLO from MMC (so > > the MMC is probed, pinctrl setup), but if I boot from UART then I get > > to full U-Boot, MMC hasn't been probed and the pinmuxing isn't set up > > for the MMC. > > I suppose that the pinmux node have set "u-boot,dm-pre-reloc" > property? > Yeah, well "u-boot,dm-spl", though now I re-read the docs I guess that's equivalent to "u-boot,dm-pre-reloc" as I've no TPL. > The problem is not with lack of eMMC probing - it is with pinctrl nodes > having "u-boot,dm-pre-reloc" set in DTS and the eMMC is probed after > MLO/SPL. > It looks like your use case implicitly depends on pinmux being > reconfigured no matter if we are pre-relocated (MLO) or afterwards. > Yes, that's a much clearer description... -- Alex Kiernan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] dm: pinctrl: Prevent (re-)configuring pins when already done before relocation
On Thu, Dec 27, 2018 at 3:49 PM Tom Rini wrote: > > On Tue, Dec 18, 2018 at 12:30:50PM +0100, Lukasz Majewski wrote: > > > This commit prevents from re-configuring pins if those were configured > > before relocation. > > > > Some pins - like UART or DDR must be setup before relocation > > (as they have 'u-boot,dm-pre-reloc' property set in DTS). Without this > > change, those pins are re-configured after relocation (pre_reloc_only = 0, > > so we do not "continue"). > > Such behavior may be a problem for DDR PAD configuration, as they might > > be already leveled/tuned with original setup). > > > > Signed-off-by: Lukasz Majewski > > Applied to u-boot/master, thanks! > I've bisected out to this commit and it's slightly broken things for me on an AM3352. It all works fine so long as I boot MLO from MMC (so the MMC is probed, pinctrl setup), but if I boot from UART then I get to full U-Boot, MMC hasn't been probed and the pinmuxing isn't set up for the MMC. -- Alex Kiernan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: musb-new: Add CONFIG_USB_MUSB_INIT_TIMEOUT
On Fri, Dec 7, 2018 at 12:30 PM Marek Vasut wrote:
>
> On 12/07/2018 01:29 PM, Alex Kiernan wrote:
> > On Fri, Dec 7, 2018 at 11:54 AM Marek Vasut wrote:
> >>
> >> On 12/07/2018 09:56 AM, Alex Kiernan wrote:
> >> [...]
> >>> +++ b/drivers/usb/musb-new/musb_uboot.c
> >>> @@ -214,7 +214,7 @@ int musb_lowlevel_init(struct musb_host_data *host)
> >>> {
> >>> void *mbase;
> >>> /* USB spec says it may take up to 1 second for a device to connect
> >>> */
> >>> - unsigned long timeout = get_timer(0) + 1000;
> >>> + unsigned long timeout = get_timer(0) + CONFIG_USB_MUSB_INIT_TIMEOUT;
> >>
> >> Isn't this the same as usb_pgood_delay ?
> >>
> >
> > Looks like it; I'll spin a v2 which uses that.
>
> I wonder if this code is needed at all, shouldn't the USB core deal with
> this delay ?
>
Oh I see... certainly I can't just take that delay out, that just ends up at:
USB0: scanning bus 0 for devices... USB device descriptor short read
(expected 8, got 0)
failed, error -5
Certainly without that delay, there's clearly delays in the rest of
the USB core, so I expect you're right, I just don't know where to put
the poll for MUSB_DEVCTL_HM.
--
Alex Kiernan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: musb-new: Add CONFIG_USB_MUSB_INIT_TIMEOUT
On Fri, Dec 7, 2018 at 11:54 AM Marek Vasut wrote:
>
> On 12/07/2018 09:56 AM, Alex Kiernan wrote:
> [...]
> > +++ b/drivers/usb/musb-new/musb_uboot.c
> > @@ -214,7 +214,7 @@ int musb_lowlevel_init(struct musb_host_data *host)
> > {
> > void *mbase;
> > /* USB spec says it may take up to 1 second for a device to connect */
> > - unsigned long timeout = get_timer(0) + 1000;
> > + unsigned long timeout = get_timer(0) + CONFIG_USB_MUSB_INIT_TIMEOUT;
>
> Isn't this the same as usb_pgood_delay ?
>
Looks like it; I'll spin a v2 which uses that.
--
Alex Kiernan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] usb: musb-new: Add CONFIG_USB_MUSB_INIT_TIMEOUT
Make the timeout in musb_lowlevel_init() configurable from the 1s default.
Some USB memory sticks take longer than 1s to connect and so whilst
usable in Linux aren't usable in U-Boot. The default in Kconfig is still
1000ms, so this should be a non-change for any existing users.
Signed-off-by: Alex Kiernan
---
drivers/usb/musb-new/Kconfig | 8
drivers/usb/musb-new/musb_uboot.c | 2 +-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb-new/Kconfig b/drivers/usb/musb-new/Kconfig
index f8f2205a62d3..5b9df5227961 100644
--- a/drivers/usb/musb-new/Kconfig
+++ b/drivers/usb/musb-new/Kconfig
@@ -54,6 +54,14 @@ config USB_MUSB_SUNXI
Say y here to enable support for the sunxi OTG / DRC USB controller
used on almost all sunxi boards.
+config USB_MUSB_INIT_TIMEOUT
+ int "Low level initialization timeout"
+ default 1000
+ help
+ The USB spec says it may take up to 1 second for a device to
+ connect. Some devices take longer than this to connect, so
+ you can increase the timeout here. The value here is in ms.
+
endif
config USB_MUSB_PIO_ONLY
diff --git a/drivers/usb/musb-new/musb_uboot.c
b/drivers/usb/musb-new/musb_uboot.c
index d40772b1aa5c..82591ad8f6b5 100644
--- a/drivers/usb/musb-new/musb_uboot.c
+++ b/drivers/usb/musb-new/musb_uboot.c
@@ -214,7 +214,7 @@ int musb_lowlevel_init(struct musb_host_data *host)
{
void *mbase;
/* USB spec says it may take up to 1 second for a device to connect */
- unsigned long timeout = get_timer(0) + 1000;
+ unsigned long timeout = get_timer(0) + CONFIG_USB_MUSB_INIT_TIMEOUT;
int ret;
if (!host->host) {
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] am33xx board with no external RTC crystal issue
On Fri, Nov 9, 2018 at 7:09 AM Belisko Marek wrote:
>
> Hi Alex,
>
> On Tue, Oct 30, 2018 at 7:12 AM Alex Kiernan wrote:
> >
> > On Mon, Oct 29, 2018 at 11:36 PM Belisko Marek
> > wrote:
> > >
> > > Hi,
> > >
> > > I'm working on custome am33xx based HW which have no external 32KHz
> > > crystal. Anyway I want to use bootcount feature. I was trying to use
> > > internal PRCM CLK_32KHZ clock as source for RTCSS but still when want
> > > to read RTC registers I get data abort.
> > >
> > > I adapted this method :
> > >
> > > static void rtc32k_enable(void)
> > > {
> > > struct davinci_rtc *rtc = (struct davinci_rtc *)RTC_BASE;
> > >
> > > /*
> > > * Unlock the RTC's registers. For more details please see the
> > > * RTC_SS section of the TRM. In order to unlock we need to
> > > @@ -287,9 +288,8 @@ static void rtc32k_enable(void)
> > > writel(RTC_KICK1R_WE, >kick1r);
> > >
> > > /* Enable the RTC 32K OSC by setting bits 3 and 6. */
> > > - writel((1 << 3) | (1 << 6), >osc);
> > > + writel((1 << 6), >osc);
> > > }
> > >
> > > to not use external crystal 32KHz clock but internal. Anyway when
> > > doing that board just hangs and thats it. Any ideas or suggestions?
> >
> > I've a board exactly like that... check you're driving RTC_PORz
> > correctly, if you hold it in reset, that's the behaviour I see.
> OK thanks for info. I think it's hold in reset.
> >
> > > It
> > > is even possible to have something like that? I just seen that
> > > include/configs/siemens-am33x-common.h (using also am335x cpu without
> > > external 32KHz crystal) storing bootcount to env. Thanks a lot for any
> > > pointers.
> > >
> >
> > FWIW I gave up trying to use the internal clock as I couldn't get it
> > to tick reliably (my suspicion was my hand modified board wasn't
> > actually driving the reset correctly) and instead switched to keeping
> > the bootcounter in SRAM.
> I'm using bootcount stored in env. I'm using 2017.09 and didn't see
> option to store bootcount in RAM (maybe overlooked something).
> So you mean bootcount is stored in internal cpu SRAM? Thanks.
That's what I'm doing. I can't find the source referred to in this
post, but this is the address we're using:
https://e2e.ti.com/support/processors/f/791/t/204956
--
Alex Kiernan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] am33xx board with no external RTC crystal issue
On Mon, Oct 29, 2018 at 11:36 PM Belisko Marek wrote:
>
> Hi,
>
> I'm working on custome am33xx based HW which have no external 32KHz
> crystal. Anyway I want to use bootcount feature. I was trying to use
> internal PRCM CLK_32KHZ clock as source for RTCSS but still when want
> to read RTC registers I get data abort.
>
> I adapted this method :
>
> static void rtc32k_enable(void)
> {
> struct davinci_rtc *rtc = (struct davinci_rtc *)RTC_BASE;
>
> /*
> * Unlock the RTC's registers. For more details please see the
> * RTC_SS section of the TRM. In order to unlock we need to
> @@ -287,9 +288,8 @@ static void rtc32k_enable(void)
> writel(RTC_KICK1R_WE, >kick1r);
>
> /* Enable the RTC 32K OSC by setting bits 3 and 6. */
> - writel((1 << 3) | (1 << 6), >osc);
> + writel((1 << 6), >osc);
> }
>
> to not use external crystal 32KHz clock but internal. Anyway when
> doing that board just hangs and thats it. Any ideas or suggestions?
I've a board exactly like that... check you're driving RTC_PORz
correctly, if you hold it in reset, that's the behaviour I see.
> It
> is even possible to have something like that? I just seen that
> include/configs/siemens-am33x-common.h (using also am335x cpu without
> external 32KHz crystal) storing bootcount to env. Thanks a lot for any
> pointers.
>
FWIW I gave up trying to use the internal clock as I couldn't get it
to tick reliably (my suspicion was my hand modified board wasn't
actually driving the reset correctly) and instead switched to keeping
the bootcounter in SRAM.
--
Alex Kiernan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] fw_setenv: avoid writing environment when nothing has changed
On Wed, Sep 5, 2018 at 8:23 PM Rasmus Villemoes
wrote:
>
> In the case where one deletes an already-non-existing variable, or sets
> a variable to the value it already has, there is no point in writing the
> environment back, thus reducing wear on the underlying storage
> device.
>
> Signed-off-by: Rasmus Villemoes
If you were running with a redundant env, and you were trying to sync
both copies, wouldn't you want a non-changing write to happen?
> ---
> tools/env/fw_env.c | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c
> index a5d75958e1..87aaa15198 100644
> --- a/tools/env/fw_env.c
> +++ b/tools/env/fw_env.c
> @@ -110,6 +110,7 @@ struct environment {
> unsigned char *flags;
> char *data;
> enum flag_scheme flag_scheme;
> + int dirty;
> };
>
> static struct environment environment = {
> @@ -508,6 +509,9 @@ int fw_env_flush(struct env_opts *opts)
> if (!opts)
> opts = _opts;
>
> + if (!environment.dirty)
> + return 0;
> +
> /*
> * Update CRC
> */
> @@ -553,7 +557,8 @@ int fw_env_write(char *name, char *value)
>
> deleting = (oldval && !(value && strlen(value)));
> creating = (!oldval && (value && strlen(value)));
> - overwriting = (oldval && (value && strlen(value)));
> + overwriting = (oldval && (value && strlen(value) &&
> + strcmp(oldval, value)));
>
> /* check for permission */
> if (deleting) {
> @@ -593,6 +598,7 @@ int fw_env_write(char *name, char *value)
> /* Nothing to do */
> return 0;
>
> + environment.dirty = 1;
> if (deleting || overwriting) {
> if (*++nxt == '\0') {
> *env = '\0';
> @@ -1441,6 +1447,7 @@ int fw_env_open(struct env_opts *opts)
> "Warning: Bad CRC, using default
> environment\n");
> memcpy(environment.data, default_environment,
>sizeof(default_environment));
> + environment.dirty = 1;
> }
> } else {
> flag0 = *environment.flags;
> @@ -1503,6 +1510,7 @@ int fw_env_open(struct env_opts *opts)
> "Warning: Bad CRC, using default
> environment\n");
> memcpy(environment.data, default_environment,
>sizeof(default_environment));
> + environment.dirty = 1;
> dev_current = 0;
> } else {
> switch (environment.flag_scheme) {
> --
> 2.16.4
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
--
Alex Kiernan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] bootm: fdt: Use panic() instead of hang() when presented with a bad image
On Fri, Sep 21, 2018 at 1:43 PM Wolfgang Denk wrote: > > Dear Alex, > > In message <20180918081013.26660-1-alex.kier...@gmail.com> you wrote: > > When the image which bootm is given can't be booted, call panic with > > the error message rather than printf/hang so that we can recover from > > broken images via a bootcount mechanism. If hang on failure is still > > required then CONFIG_PANIC_HANG can still be enabled. > > I wonder if the failing of the FDT creation is a reason to panic / > reboot at all? The point of no return is architecture dependent - > for example, on Power architecture it is usuallywhen the kernel > image gests decompressed/written to RAM, as then the exception > vectors get overwritten, so no return to U-Boot is possible. > > But the FDT is always (I think ?) just written to an area of RAM > that is not critical for the execution of U-Boot itself - so when > this fails, why can we not simply return to U-Boot with an eroor > indication? > > I feel we should use panic/hang only as a last resort, when no other > recovery is possible? > Thinking it through, that sounds reasonable to me... the reason I ended up looking at this code was because I deployed a broken FIT image, then got stuck here. But if bootm had returned with a failure I could have done useful recovery actions without needing a reboot. -- Alex Kiernan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] spl: mmc: Report device number when we fail
If we fail to find the MMC boot device, report the number of the one
we were looking for in the error to aid diagnosis.
Signed-off-by: Alex Kiernan
---
common/spl/spl_mmc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
index 0b2f059570..39d5ac1530 100644
--- a/common/spl/spl_mmc.c
+++ b/common/spl/spl_mmc.c
@@ -140,7 +140,8 @@ static int spl_mmc_find_device(struct mmc **mmcp, u32
boot_device)
#endif
if (err) {
#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
- printf("spl: could not find mmc device. error: %d\n", err);
+ printf("spl: could not find mmc device %d. error: %d\n",
+ mmc_dev, err);
#endif
return err;
}
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] bootm: fdt: Use panic() instead of hang() when presented with a bad image
When the image which bootm is given can't be booted, call panic with
the error message rather than printf/hang so that we can recover from
broken images via a bootcount mechanism. If hang on failure is still
required then CONFIG_PANIC_HANG can still be enabled.
Signed-off-by: Alex Kiernan
---
arch/arm/lib/bootm.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index c3c1d2fdfa..a5ed12df74 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -230,8 +230,7 @@ static void boot_prep_linux(bootm_headers_t *images)
#ifdef CONFIG_OF_LIBFDT
debug("using: FDT\n");
if (image_setup_linux(images)) {
- printf("FDT creation failed! hanging...");
- hang();
+ panic("FDT creation failed!\n");
}
#endif
} else if (BOOTM_ENABLE_TAGS) {
@@ -264,8 +263,7 @@ static void boot_prep_linux(bootm_headers_t *images)
setup_board_tags();
setup_end_tag(gd->bd);
} else {
- printf("FDT and ATAGS support not compiled in - hanging\n");
- hang();
+ panic("FDT and ATAGS support not compiled in\n");
}
}
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Fwd: Parallel build is broken
On Tue, Sep 4, 2018 at 3:54 PM Andy Shevchenko wrote: > > On Tue, Sep 4, 2018 at 5:50 PM Andy Shevchenko > wrote: > > > > On Tue, Sep 4, 2018 at 5:00 PM Tom Rini wrote: > > > > > > On Tue, Sep 04, 2018 at 03:42:05PM +0300, Andy Shevchenko wrote: > > > > > > > -- Forwarded message - > > > > From: Andy Shevchenko > > > > Date: Tue, Sep 4, 2018 at 3:40 PM > > > > Subject: Parallel build is broken > > > > To: Tom Rini > > > > Cc: Bin Meng , Simon Glass > > > > > > > > > > > > U-Boot can't be build with make -j16. > > > > > > > > Second pass passes fine. > > > > > > > > Didn't investigate myself and probably will not have time (near to > > > > vacation time for me). > > > > So, please, fix it before release. > > > > > > > > sh: echo: I/O error > > > > make[1]: *** [scripts/Makefile.build:278: common/malloc_simple.o] Error > > > > 1 > > > > make[1]: *** Waiting for unfinished jobs > > > > CC drivers/serial/ns16550.o > > > > CC drivers/spi/spi.o > > > > CC cmd/mmc.o > > > > CC drivers/watchdog/tangier_wdt.o > > > > CC drivers/serial/serial_intel_mid.o > > > > CC cmd/net.o > > > > CC drivers/usb/common/common.o > > > > CC arch/x86/lib/acpi.o > > > > LD drivers/timer/built-in.o > > > > CC arch/x86/lib/acpi_table.o > > > > CC drivers/video/console_normal.o > > > > make: *** [Makefile:1377: common] Error 2 > > > > make: *** Waiting for unfinished jobs > > > > > > What build target (and O= or not?) is this with? Thanks! > > > > make clean && make edison_defconfig && make -j16 > > > > gcc (Debian 8.2.0-4) 8.2.0 > > Copyright (C) 2018 Free Software Foundation, Inc. > > This is free software; see the source for copying conditions. There is NO > > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > So, first time it's being built, consequent runs usually failed. > I've seen this problem - building inside a VMware VM. I've always found that logging out and back in appears to fix it, so possibly something related to the session... I've similarly failed to figure out what the problem is as it comes and goes. -- Alex Kiernan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] spi: davinci: Full dm conversion
>> >> > >> >> - ds->regs = (struct davinci_spi_regs *)SPI2_BASE;
> >> >> > >> >> - break;
> >> >> > >> >> -#endif
> >> >> > >> >> - default: /* Invalid bus number */
> >> >> > >> >> - return NULL;
> >> >> > >> >> - }
> >> >> > >> >> -
> >> >> > >> >> - ds->freq = max_hz;
> >> >> > >> >> - ds->mode = mode;
> >> >> > >> >> -
> >> >> > >> >> - return >slave;
> >> >> > >> >> -}
> >> >> > >> >> -
> >> >> > >> >> -void spi_free_slave(struct spi_slave *slave)
> >> >> > >> >> -{
> >> >> > >> >> - struct davinci_spi_slave *ds = to_davinci_spi(slave);
> >> >> > >> >> -
> >> >> > >> >> - free(ds);
> >> >> > >> >> -}
> >> >> > >> >> -
> >> >> > >> >> -int spi_xfer(struct spi_slave *slave, unsigned int bitlen,
> >> >> > >> >> -const void *dout, void *din, unsigned long flags)
> >> >> > >> >> -{
> >> >> > >> >> - struct davinci_spi_slave *ds = to_davinci_spi(slave);
> >> >> > >> >> -
> >> >> > >> >> - ds->cur_cs = slave->cs;
> >> >> > >> >> -
> >> >> > >> >> - return __davinci_spi_xfer(ds, bitlen, dout, din, flags);
> >> >> > >> >> -}
> >> >> > >> >> -
> >> >> > >> >> -int spi_claim_bus(struct spi_slave *slave)
> >> >> > >> >> -{
> >> >> > >> >> - struct davinci_spi_slave *ds = to_davinci_spi(slave);
> >> >> > >> >> -
> >> >> > >> >> -#ifdef CONFIG_SPI_HALF_DUPLEX
> >> >> > >> >> - ds->half_duplex = true;
> >> >> > >> >> -#else
> >> >> > >> >> - ds->half_duplex = false;
> >> >> > >> >> -#endif
> >> >> > >> >> - return __davinci_spi_claim_bus(ds, ds->slave.cs);
> >> >> > >> >> -}
> >> >> > >> >> -
> >> >> > >> >> -void spi_release_bus(struct spi_slave *slave)
> >> >> > >> >> -{
> >> >> > >> >> - struct davinci_spi_slave *ds = to_davinci_spi(slave);
> >> >> > >> >> -
> >> >> > >> >> - __davinci_spi_release_bus(ds);
> >> >> > >> >> -}
> >> >> > >> >> -
> >> >> > >> >> -#else
> >> >> > >> >> -static int davinci_spi_set_speed(struct udevice *bus, uint
> >> >> > >> >> max_hz)
> >> >> > >> >> -{
> >> >> > >> >> - struct davinci_spi_slave *ds = dev_get_priv(bus);
> >> >> > >> >> -
> >> >> > >> >> - debug("%s speed %u\n", __func__, max_hz);
> >> >> > >> >> - if (max_hz > CONFIG_SYS_SPI_CLK / 2)
> >> >> > >> >> - return -EINVAL;
> >> >> > >> >> -
> >> >> > >> >> - ds->freq = max_hz;
> >> >> > >> >>
> >> >> > >> >> return 0;
> >> >> > >> >> }
> >> >> > >> >>
> >> >> > >> >> -static int davinci_spi_set_mode(struct udevice *bus, uint mode)
> >> >> > >> >> -{
> >> >> > >> >> - struct davinci_spi_slave *ds = dev_get_priv(bus);
> >> >> > >> >> -
> >> >> > >> >> - debug("%s mode %u\n", __func__, mode);
> >> >> > >> >> - ds->mode = mode;
> >> >> > >> >> -
> >> >> > >> >> - return 0;
> >> >> > >> >> -}
> >> >> > >> >> -
> >> >> > >> >> -static int davinci_spi_claim_bus(struct udevice *dev)
> >> >> > >> >> -{
> >> >> > >> >> - struct dm_spi_slave_platdata *slave_plat =
> >> >> > >> >> - dev_get_parent_platdata(dev);
> >> >> > >> >> - struct udevice *bus = dev->parent;
> >> >> > >> >> - struct davinci_spi_slave *ds = dev_get_priv(bus);
> >> >> > >> >> -
> >> >> > >> >> - if (slave_plat->cs >= ds->num_cs) {
> >> >> > >> >> - printf("Invalid SPI chipselect\n");
> >> >> > >> >> - return -EINVAL;
> >> >> > >> >> - }
> >> >> > >> >> - ds->half_duplex = slave_plat->mode & SPI_PREAMBLE;
> >> >> > >> >> -
> >> >> > >> >> - return __davinci_spi_claim_bus(ds, slave_plat->cs);
> >> >> > >> >> -}
> >> >> > >> >> -
> >> >> > >> >> -static int davinci_spi_release_bus(struct udevice *dev)
> >> >> > >> >> -{
> >> >> > >> >> - struct davinci_spi_slave *ds =
> >> >> > >> >> dev_get_priv(dev->parent);
> >> >> > >> >> -
> >> >> > >> >> - return __davinci_spi_release_bus(ds);
> >> >> > >> >> -}
> >> >> > >> >> +static const struct dm_spi_ops davinci_spi_ops = {
> >> >> > >> >> + .claim_bus = davinci_spi_claim_bus,
> >> >> > >> >> + .release_bus= davinci_spi_release_bus,
> >> >> > >> >> + .xfer = davinci_spi_xfer,
> >> >> > >> >> + .set_speed = davinci_spi_set_speed,
> >> >> > >> >> + .set_mode = davinci_spi_set_mode,
> >> >> > >> >> +};
> >> >> > >> >>
> >> >> > >> >> -static int davinci_spi_xfer(struct udevice *dev, unsigned int
> >> >> > >> >> bitlen,
> >> >> > >> >> - const void *dout, void *din,
> >> >> > >> >> - unsigned long flags)
> >> >> > >> >> +static int davinci_spi_probe(struct udevice *bus)
> >> >> > >> >> {
> >> >> > >> >> - struct dm_spi_slave_platdata *slave =
> >> >> > >> >> - dev_get_parent_platdata(dev);
> >> >> > >> >> - struct udevice *bus = dev->parent;
> >> >> > >> >> struct davinci_spi_slave *ds = dev_get_priv(bus);
> >> >> > >> >> + struct davinci_spi_platdata *plat = bus->platdata;
> >> >> > >> >> + ds->regs = plat->regs;
> >> >> > >> >> + ds->num_cs = plat->num_cs;
> >> >> > >> >>
> >> >> > >> >> - if (slave->cs >= ds->num_cs) {
> >> >> > >> >> - printf("Invalid SPI chipselect\n");
> >> >> > >> >> - return -EINVAL;
> >> >> > >> >> - }
> >> >> > >> >> - ds->cur_cs = slave->cs;
> >> >> > >> >> -
> >> >> > >> >> - return __davinci_spi_xfer(ds, bitlen, dout, din, flags);
> >> >> > >> >> -}
> >> >> > >> >> -
> >> >> > >> >> -static int davinci_spi_probe(struct udevice *bus)
> >> >> > >> >> -{
> >> >> > >> >> - /* Nothing to do */
> >> >> > >> >> return 0;
> >> >> > >> >> }
> >> >> > >> >>
> >> >> > >> >> +#if CONFIG_IS_ENABLED(OF_CONTROL)
> >> >> > >> >
> >> >> > >> > Looking at other drivers, I wonder if this should be
> >> >> > >> > +#if CONFIG_IS_ENABLED(OF_CONTROL) &&
> >> >> > >> > !CONFIG_IS_ENABLED(OF_PLATDATA)
> >> >> > >> >
> >> >> > >> >
> >> >> > >> >> static int davinci_ofdata_to_platadata(struct udevice *bus)
> >> >> > >> >> {
> >> >> > >> >> - struct davinci_spi_slave *ds = dev_get_priv(bus);
> >> >> > >> >> - const void *blob = gd->fdt_blob;
> >> >> > >> >> - int node = dev_of_offset(bus);
> >> >> > >> >> + struct davinci_spi_platdata *plat = bus->platdata;
> >> >> > >> >> + fdt_addr_t addr;
> >> >> > >> >>
> >> >> > >> >> - ds->regs = devfdt_map_physmem(bus, sizeof(struct
> >> >> > >> >> davinci_spi_regs));
> >> >> > >> >> - if (!ds->regs) {
> >> >> > >> >> - printf("%s: could not map device address\n",
> >> >> > >> >> __func__);
> >> >> > >> >> + addr = devfdt_get_addr(bus);
> >> >> > >> >> + if (addr == FDT_ADDR_T_NONE)
> >> >> > >> >> return -EINVAL;
> >> >> > >> >> - }
> >> >> > >> >> - ds->num_cs = fdtdec_get_int(blob, node, "num-cs", 4);
> >> >> > >> >> +
> >> >> > >> >> + plat->regs = (struct davinci_spi_regs *)addr;
> >> >> > >> >> + plat->num_cs = fdtdec_get_int(gd->fdt_blob,
> >> >> > >> >> dev_of_offset(bus), "num-cs", 4);
> >> >> > >> >>
> >> >> > >> >> return 0;
> >> >> > >> >> }
> >> >> > >> >>
> >> >> > >> >> -static const struct dm_spi_ops davinci_spi_ops = {
> >> >> > >> >> - .claim_bus = davinci_spi_claim_bus,
> >> >> > >> >> - .release_bus= davinci_spi_release_bus,
> >> >> > >> >> - .xfer = davinci_spi_xfer,
> >> >> > >> >> - .set_speed = davinci_spi_set_speed,
> >> >> > >> >> - .set_mode = davinci_spi_set_mode,
> >> >> > >> >> -};
> >> >> > >> >> -
> >> >> > >> >> static const struct udevice_id davinci_spi_ids[] = {
> >> >> > >> >> { .compatible = "ti,keystone-spi" },
> >> >> > >> >> { .compatible = "ti,dm6441-spi" },
> >> >> > >> >> { .compatible = "ti,da830-spi" },
> >> >> > >> >> { }
> >> >> > >> >> };
> >> >> > >> >> +#endif
> >> >> > >> >>
> >> >> > >> >> U_BOOT_DRIVER(davinci_spi) = {
> >> >> > >> >> .name = "davinci_spi",
> >> >> > >> >> .id = UCLASS_SPI,
> >> >> > >> >> +#if CONFIG_IS_ENABLED(OF_CONTROL)
> >> >> > >> >
> >> >> > >> > Like above, should this be:
> >> >> > >> > +#if CONFIG_IS_ENABLED(OF_CONTROL) &&
> >> >> > >> > !CONFIG_IS_ENABLED(OF_PLATDATA)
> >> >> > >> >
> >> >> > >> > With limited SPL resources, I cannot build OF_CONTROL in SPL and
> >> >> > >> > disabling OF_CONTROL in SPL doesn't build either.
> >> >> > >> > With the modification, I can build with OF_PLATDATA enabled.
> >> >> >
> >> >> > Is it possible to enable DM_SPI in SPL? da850evm_direct_nor_defconfig
> >> >> > is able to build since it has it.
> >> >>
> >> >> Enabling DM_SPI in SPL starts to grow, hence my other comments about
> >> >> SPL_OF_PLATDATA in order to make it fit into SPL.
> >> >> da850evm_direct_nor_defconfig does not enable SPL, but it does enable
> >> >> DM_SPI.
> >> >> I had to get the NOR expansion board in order to try it. I'm trying
> >> >> to get it to work now, but for some reason, I'm having difficulty
> >> >> booting the stock da850evm_direct_nor_defconfig
> >> >>
> >> >> It would be easiest if we could have both a DM_SPI and non DM_SPI
> >> >> version of the driver so it can fit into SPL or the ability to disable
> >> >> SPI in SPL. I am experimenting with the latter. Several drivers
> >> >> offer the option to be disabled in SPL, so I'm experimenting with that
> >> >> to save space in SPL.
> >> >>
> >> >
> >> > I was able to verify your code works for the
> >> > da850evm_direct_nor_defconfig version which doesn't use SPL.
> >> > I spent a significant amount of time yesterday trying to get SPL to
> >> > work, but just enabling SPL and disabling
> >> > all drivers except serial, I was not able to boot, so I think
> >> > something is wrong with DM and SPL. I don't have
> >> > a debugger at home for this board, so I'll need to get one from work
> >> > to further troubleshoot.
> >>
> >> I don't think it is much difficult to get serial up here. I made few
> >> changes for serial and spi platdata for SPL. If haven't try these
> >> please check the same and better change proper clock value for uart if
> >> added one is improper.
> >>
> >> >
> >> > I don't think any DA850/L138/AM1808 board uses DM in SPL, so I think
> >> > it would be best to maintain both DM
> >> > and non-DM code bases for now until we're able to support DM in SPL.
> >>
> >> But the whole idea is to drop nod-dm SPI as much as possible.
> >
> >
> > What your saying makes sense.
> >>
> >>
> >> [1]
> >> http://git.denx.de/?p=u-boot-spi.git;a=shortlog;h=refs/heads/spi-dm-migrate
> >
> >
> > I am traveling today, but I will try to look at that tomorrow. I did
> > something similar already without success, but I will try again with your
> > patch to see if it's any better.
> >
> > Is there a document somewhere that shows the order of operations during
> > SPL? I'm wondering if some of the SPL Davinci code should be refactored to
> > make sure the hardware is ready in the order that SPL is expecting it when
> > used with DM.
> >
>
> Your patch adding the UART stuff and enabling DM still didn't work.
> As soon as I enable DM in SPL, I no longer get any of the SPL text
> stuff that normally gets displayed immediately on boot. I will try to
> take a look at the suggestion from Simon Goldschmidt to see if I can
> adapt any of his work to the Davinci platform.
>
In case it's of use as another line to explore, we had the same
problem, which we eventually tracked down to some board detection code
which doing GPIO bashing using gpio_get_value (and friends) which with
SPL_DM ended up using a lot more RAM than we had with
SPL_SYS_MALLOC_SIMPLE. In truth the problem was actually slightly
worse because the board detection was before DM was initialised so the
GPIOs it was attempting to interrogate just failed... so we're now
just doing raw GPIO to do the board detect. But fixing the OOM at
least got us to the point where we could figure out what was actually
wrong.
--
Alex Kiernan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Converting to SPL_OF_CONTROL
On Wed, Aug 1, 2018 at 11:41 AM Alex Kiernan wrote:
>
> I've long been trying to convert our board (AM3352) to all DM, after
> knocking out lots of problems, I've run into one I can't seem to
> configure my way around, when I enable SPL_OF_CONTROL.
>
> We have MMC2 as our boot device, with no MMC1 (and hence not present
> in the DTB). Once we're into full U-Boot this is all okay, we get the
> board's MMC2 appearing as mmc0 and everything's fine.
>
> My problem's during SPL, where the boot device is MMC2, the code tries
> to lookup by devnum (which is 1 because it numbers from 0 at this
> point), which doesn't exist. I'd expected aliases to work, but we
> don't seem to lookup up by alias, only index, so I don't have any way
> that I can see of overriding it.
>
> If I make this change, then everything works (with the addition of an
> an alias for mmc1 = ):
>
> diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
> index 0b2f059570..b7544ba183 100644
> --- a/common/spl/spl_mmc.c
> +++ b/common/spl/spl_mmc.c
> @@ -131,7 +131,7 @@ static int spl_mmc_find_device(struct mmc **mmcp,
> u32 boot_device)
> }
>
> #if CONFIG_IS_ENABLED(DM_MMC)
> - err = uclass_get_device(UCLASS_MMC, mmc_dev, );
> + err = uclass_get_device_by_seq(UCLASS_MMC, mmc_dev, );
> if (!err)
> *mmcp = mmc_get_mmc_dev(dev);
> #else
>
> But that feels like a pretty fundamental change to make across every
> board and I've no real idea if that would even be the right thing to
> do, or if I should be trying to fix this some other way.
>
Thanks to Johan for pointing me at the Rockchip code; with that I can
get the board to use the right MMC in SPL, but I still have the same
problem, I'm booting from MMC2, but because all the numbering is by
devnum, not sequence, I end up with a board_boot_order function that's
the equivalent of this:
void board_boot_order(u32 *spl_boot_list)
{
u32 boot_device = spl_boot_device();
if (boot_device == BOOT_DEVICE_MMC2)
spl_boot_list[0] = BOOT_DEVICE_MMC1;
else
spl_boot_list[0] = boot_device;
}
Which seems fundamentally wrong...
I'm assuming that the change I was originally playing with is a non-starter:
--- a/common/spl/spl_mmc.c
+++ b/common/spl/spl_mmc.c
@@ -131,7 +131,7 @@ static int spl_mmc_find_device(struct mmc **mmcp,
u32 boot_device)
}
#if CONFIG_IS_ENABLED(DM_MMC)
- err = uclass_get_device(UCLASS_MMC, mmc_dev, );
+ err = uclass_get_device_by_seq(UCLASS_MMC, mmc_dev, );
if (!err)
*mmcp = mmc_get_mmc_dev(dev);
#else
Obviously I could guard that change with yet another symbol, but that
feels like it's papering over the problem... anyone got a pointer as
to what the right way to fix this is?
--
Alex Kiernan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Converting to SPL_OF_CONTROL
Hi Johann On Wed, Aug 1, 2018 at 2:18 PM Alex Kiernan wrote: > > On Wed, Aug 1, 2018 at 12:30 PM Johann Neuhauser > wrote: > > > > Hello Alex, > > > > have you tried to set "u-boot,spl-boot-order" in choosen node? > > > > Take a look into: > > doc/device-tree-bindings/chosen.txt > > > > Thanks, I totally failed to see that. > > Let me have an investigate! > So that only seems to be implemented for rockchip, but it certainly looks like it's solving the kind of problem I have. The big thing you've made me realise is that board_boot_order() is a weak function that I can override... I'll see what I can do starting from the rockchip code. Thanks! > > Best regards > > > > Johann Neuhauser > > > > -Ursprüngliche Nachricht- > > Von: U-Boot [mailto:u-boot-boun...@lists.denx.de] Im Auftrag von Alex > > Kiernan > > Gesendet: Mittwoch, 1. August 2018 12:42 > > An: u-boot ; Simon Glass > > Betreff: [U-Boot] Converting to SPL_OF_CONTROL > > > > I've long been trying to convert our board (AM3352) to all DM, after > > knocking out lots of problems, I've run into one I can't seem to configure > > my way around, when I enable SPL_OF_CONTROL. > > > > We have MMC2 as our boot device, with no MMC1 (and hence not present in the > > DTB). Once we're into full U-Boot this is all okay, we get the board's MMC2 > > appearing as mmc0 and everything's fine. > > > > My problem's during SPL, where the boot device is MMC2, the code tries to > > lookup by devnum (which is 1 because it numbers from 0 at this point), > > which doesn't exist. I'd expected aliases to work, but we don't seem to > > lookup up by alias, only index, so I don't have any way that I can see of > > overriding it. > > > > If I make this change, then everything works (with the addition of an an > > alias for mmc1 = ): > > > > diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c index > > 0b2f059570..b7544ba183 100644 > > --- a/common/spl/spl_mmc.c > > +++ b/common/spl/spl_mmc.c > > @@ -131,7 +131,7 @@ static int spl_mmc_find_device(struct mmc **mmcp, > > u32 boot_device) > > } > > > > #if CONFIG_IS_ENABLED(DM_MMC) > > - err = uclass_get_device(UCLASS_MMC, mmc_dev, ); > > + err = uclass_get_device_by_seq(UCLASS_MMC, mmc_dev, ); > > if (!err) > > *mmcp = mmc_get_mmc_dev(dev); #else > > > > But that feels like a pretty fundamental change to make across every board > > and I've no real idea if that would even be the right thing to do, or if I > > should be trying to fix this some other way. > > > > -- > > Alex Kiernan > > ___ > > U-Boot mailing list > > U-Boot@lists.denx.de > > https://lists.denx.de/listinfo/u-boot > > > > -- > Alex Kiernan -- Alex Kiernan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Converting to SPL_OF_CONTROL
On Wed, Aug 1, 2018 at 12:30 PM Johann Neuhauser wrote: > > Hello Alex, > > have you tried to set "u-boot,spl-boot-order" in choosen node? > > Take a look into: > doc/device-tree-bindings/chosen.txt > Thanks, I totally failed to see that. Let me have an investigate! > Best regards > > Johann Neuhauser > > -Ursprüngliche Nachricht- > Von: U-Boot [mailto:u-boot-boun...@lists.denx.de] Im Auftrag von Alex Kiernan > Gesendet: Mittwoch, 1. August 2018 12:42 > An: u-boot ; Simon Glass > Betreff: [U-Boot] Converting to SPL_OF_CONTROL > > I've long been trying to convert our board (AM3352) to all DM, after knocking > out lots of problems, I've run into one I can't seem to configure my way > around, when I enable SPL_OF_CONTROL. > > We have MMC2 as our boot device, with no MMC1 (and hence not present in the > DTB). Once we're into full U-Boot this is all okay, we get the board's MMC2 > appearing as mmc0 and everything's fine. > > My problem's during SPL, where the boot device is MMC2, the code tries to > lookup by devnum (which is 1 because it numbers from 0 at this point), which > doesn't exist. I'd expected aliases to work, but we don't seem to lookup up > by alias, only index, so I don't have any way that I can see of overriding it. > > If I make this change, then everything works (with the addition of an an > alias for mmc1 = ): > > diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c index > 0b2f059570..b7544ba183 100644 > --- a/common/spl/spl_mmc.c > +++ b/common/spl/spl_mmc.c > @@ -131,7 +131,7 @@ static int spl_mmc_find_device(struct mmc **mmcp, > u32 boot_device) > } > > #if CONFIG_IS_ENABLED(DM_MMC) > - err = uclass_get_device(UCLASS_MMC, mmc_dev, ); > + err = uclass_get_device_by_seq(UCLASS_MMC, mmc_dev, ); > if (!err) > *mmcp = mmc_get_mmc_dev(dev); #else > > But that feels like a pretty fundamental change to make across every board > and I've no real idea if that would even be the right thing to do, or if I > should be trying to fix this some other way. > > -- > Alex Kiernan > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot -- Alex Kiernan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Converting to SPL_OF_CONTROL
I've long been trying to convert our board (AM3352) to all DM, after knocking out lots of problems, I've run into one I can't seem to configure my way around, when I enable SPL_OF_CONTROL. We have MMC2 as our boot device, with no MMC1 (and hence not present in the DTB). Once we're into full U-Boot this is all okay, we get the board's MMC2 appearing as mmc0 and everything's fine. My problem's during SPL, where the boot device is MMC2, the code tries to lookup by devnum (which is 1 because it numbers from 0 at this point), which doesn't exist. I'd expected aliases to work, but we don't seem to lookup up by alias, only index, so I don't have any way that I can see of overriding it. If I make this change, then everything works (with the addition of an an alias for mmc1 = ): diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c index 0b2f059570..b7544ba183 100644 --- a/common/spl/spl_mmc.c +++ b/common/spl/spl_mmc.c @@ -131,7 +131,7 @@ static int spl_mmc_find_device(struct mmc **mmcp, u32 boot_device) } #if CONFIG_IS_ENABLED(DM_MMC) - err = uclass_get_device(UCLASS_MMC, mmc_dev, ); + err = uclass_get_device_by_seq(UCLASS_MMC, mmc_dev, ); if (!err) *mmcp = mmc_get_mmc_dev(dev); #else But that feels like a pretty fundamental change to make across every board and I've no real idea if that would even be the right thing to do, or if I should be trying to fix this some other way. -- Alex Kiernan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] musb-new startup timeout
We've been chasing a problem for a while where we've got USB3 devices
plugged in (on AM3352 board), this is using the musb-new driver.
The symptoms are you plug in a device in and run `usb start` and get
`USB0: Port not available.`, having watched the timings (and from
our reading of the USB spec - though this is spec in one hand and
analyser in the other...) we think that the USB device should raise
the D+ line within 100ms to indicate that it is present. With a USB
2.0 hubs we see this very quickly, but with some USB3 hubs (and some
USB3 memory sticks) this takes on the order of 800ms. We failed to
find the right part of the USB3 spec, so not sure if this is normal.
There's a timeout in musb_uboot.c of 1s:
int musb_lowlevel_init(struct musb_host_data *host)
{
void *mbase;
/* USB spec says it may take up to 1 second for a device to connect */
unsigned long timeout = get_timer(0) + 1000;
int ret;
...
If we bump that timeout to 1200ms then devices that were unreliable
now work, but obviously the longer the delay, the more time the boot
process takes when there's no USB (assuming there's a `usb start` in
there).
Would making that timeout configurable be a crazy thing to do, or are
these devices which we're trying to use just broken and we should
avoid them. Given the timeout's down in a driver, I assume other
drivers have the same 1s timeout?
--
Alex Kiernan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/2] env: Include bootdelay in environment if negative
On Fri, Jul 27, 2018 at 1:26 AM Tom Rini wrote: > > On Thu, Jul 26, 2018 at 09:31:08AM +0100, Alex Kiernan wrote: > > On Fri, Jul 20, 2018 at 11:34 PM Tom Rini wrote: > > > > > > On Thu, Jul 05, 2018 at 12:38:15PM +, Alex Kiernan wrote: > > > > > > > The test for (CONFIG_BOOTDELAY >= 0) has been in U-Boot since the > > > > beginning, but the meaning of it has changed over time. Allow the > > > > default to be set for any value, including -ve ones. This allows > > > > (for example) CONFIG_ENV_IS_NOWHERE to have values for bootdelay in > > > > its compiled in environment. > > > > > > > > The only thing this changes is where the default for bootdelay can be > > > > fetched from; before this change you get a compiled in default, after > > > > you'll pull it from the default value in the environment, but both > > > > values > > > > will be the same. Also if there's a value set in the environment then > > > > that will take precedence (as before). > > > > > > > > Signed-off-by: Alex Kiernan > > > > > > Applied to u-boot/master, thanks! > > > > > > > I've just realised that if you had an existing hardcoded bootdelay= to > > cover the case where it wasn't being inserted through env_defaults you > > would now end up with two. > > > > However checking there's 6 boards (9 configs) which possibly have this > > problem, but none of them have a -ve value for CONFIG_BOOTDELAY. If I > > revert this change and then grep out bootdelay from the generated > > environments for those configs, 7 have duplicates before this change > > (the last two are odroid-c2 and odroid-xu3 which are fine): > > > > cl-som-am57x/uboot.env: bootdelay=2 > > cl-som-am57x/uboot.env: bootdelay=3 > > cm_t54/uboot.env: bootdelay=3 > > cm_t54/uboot.env: bootdelay=3 > > display5_factory/uboot.env: bootdelay=3 > > display5_factory/uboot.env: bootdelay=1 > > display5/uboot.env: bootdelay=2 > > display5/uboot.env: bootdelay=1 > > nas220/uboot.env: bootdelay=3 > > nas220/uboot.env: bootdelay=-1 > > odroid/uboot.env: bootdelay=2 > > odroid/uboot.env: bootdelay=0 > > vinco/uboot.env: bootdelay=3 > > vinco/uboot.env: bootdelay=0 > > Ah, good catch. In the end, it's probably OK. > I guess last match will win, so you end up with what you've put in your board file, which is likely what's intended. > > I don't think there's anything here for me to fix up, but the > > maintainers of those boards probably want to figure out which of the > > bootdelay values they wanted. > > > > I wonder if we want some QA process off the end of the build (or in > > buildman?) which verifies the extracted environment for duplicate > > entries. > > That would be a great addition to buildman, yes. > Have we got any warning machinery in buildman? I can only find stuff which is reporting warnings from the tools, not from itself. -- Alex Kiernan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/2] env: Include bootdelay in environment if negative
On Fri, Jul 20, 2018 at 11:34 PM Tom Rini wrote: > > On Thu, Jul 05, 2018 at 12:38:15PM +, Alex Kiernan wrote: > > > The test for (CONFIG_BOOTDELAY >= 0) has been in U-Boot since the > > beginning, but the meaning of it has changed over time. Allow the > > default to be set for any value, including -ve ones. This allows > > (for example) CONFIG_ENV_IS_NOWHERE to have values for bootdelay in > > its compiled in environment. > > > > The only thing this changes is where the default for bootdelay can be > > fetched from; before this change you get a compiled in default, after > > you'll pull it from the default value in the environment, but both values > > will be the same. Also if there's a value set in the environment then > > that will take precedence (as before). > > > > Signed-off-by: Alex Kiernan > > Applied to u-boot/master, thanks! > I've just realised that if you had an existing hardcoded bootdelay= to cover the case where it wasn't being inserted through env_defaults you would now end up with two. However checking there's 6 boards (9 configs) which possibly have this problem, but none of them have a -ve value for CONFIG_BOOTDELAY. If I revert this change and then grep out bootdelay from the generated environments for those configs, 7 have duplicates before this change (the last two are odroid-c2 and odroid-xu3 which are fine): cl-som-am57x/uboot.env: bootdelay=2 cl-som-am57x/uboot.env: bootdelay=3 cm_t54/uboot.env: bootdelay=3 cm_t54/uboot.env: bootdelay=3 display5_factory/uboot.env: bootdelay=3 display5_factory/uboot.env: bootdelay=1 display5/uboot.env: bootdelay=2 display5/uboot.env: bootdelay=1 nas220/uboot.env: bootdelay=3 nas220/uboot.env: bootdelay=-1 odroid/uboot.env: bootdelay=2 odroid/uboot.env: bootdelay=0 vinco/uboot.env: bootdelay=3 vinco/uboot.env: bootdelay=0 I don't think there's anything here for me to fix up, but the maintainers of those boards probably want to figure out which of the bootdelay values they wanted. I wonder if we want some QA process off the end of the build (or in buildman?) which verifies the extracted environment for duplicate entries. -- Alex Kiernan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] bootcount: Fix misaligned cache operation
1947c2d2a0 introduces cache line flushes for the bootcounter, but if
the start address is not aligned then the flush causes warnings of
the form:
CACHE: Misaligned operation at range [4030b7fc, 4030b83c]
Align both the start and end of the buffer (possibly crossing multiple
lines).
Fixes: 1947c2d2a0 ("bootcount: flush after storing the bootcounter")
Signed-off-by: Alex Kiernan
---
drivers/bootcount/bootcount.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/bootcount/bootcount.c b/drivers/bootcount/bootcount.c
index a3162c97ed..646c563f8a 100644
--- a/drivers/bootcount/bootcount.c
+++ b/drivers/bootcount/bootcount.c
@@ -11,16 +11,23 @@
__weak void bootcount_store(ulong a)
{
void *reg = (void *)CONFIG_SYS_BOOTCOUNT_ADDR;
+ uintptr_t flush_start = rounddown(CONFIG_SYS_BOOTCOUNT_ADDR,
+ CONFIG_SYS_CACHELINE_SIZE);
+ uintptr_t flush_end;
#if defined(CONFIG_SYS_BOOTCOUNT_SINGLEWORD)
raw_bootcount_store(reg, (BOOTCOUNT_MAGIC & 0x) | a);
+
+ flush_end = roundup(CONFIG_SYS_BOOTCOUNT_ADDR + 4,
+ CONFIG_SYS_CACHELINE_SIZE);
#else
raw_bootcount_store(reg, a);
raw_bootcount_store(reg + 4, BOOTCOUNT_MAGIC);
+
+ flush_end = roundup(CONFIG_SYS_BOOTCOUNT_ADDR + 8,
+ CONFIG_SYS_CACHELINE_SIZE);
#endif /* defined(CONFIG_SYS_BOOTCOUNT_SINGLEWORD */
- flush_dcache_range(CONFIG_SYS_BOOTCOUNT_ADDR,
- CONFIG_SYS_BOOTCOUNT_ADDR +
- CONFIG_SYS_CACHELINE_SIZE);
+ flush_dcache_range(flush_start, flush_end);
}
__weak ulong bootcount_load(void)
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] Cleanup CONFIG_BOOTDELAY on cl-som-imx7
CONFIG_BOOTDELAY has been migrated to Kconfig, but cl-som-imx7 was missed. We can just delete the assignments as the config already has the correct value. Signed-off-by: Alex Kiernan --- include/configs/cl-som-imx7.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/include/configs/cl-som-imx7.h b/include/configs/cl-som-imx7.h index faea6c6b93..e4554ed541 100644 --- a/include/configs/cl-som-imx7.h +++ b/include/configs/cl-som-imx7.h @@ -64,9 +64,7 @@ #undef CONFIG_SYS_AUTOLOAD #undef CONFIG_EXTRA_ENV_SETTINGS #undef CONFIG_BOOTCOMMAND -#undef CONFIG_BOOTDELAY -#define CONFIG_BOOTDELAY 3 #define CONFIG_SYS_AUTOLOAD"no" #define CONFIG_EXTRA_ENV_SETTINGS \ -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 2/2] Migrate bootlimit to Kconfig
Migrate boards which set bootlimit in the environment to Kconfig. We exclude gurnard_defconfig which includes a bootlimit=, but doesn't set CONFIG_BOOTCOUNT_LIMIT, so we'd fail to include a bootlimit setting if we migrated it. display5_defconfig and display5_factory_defconfig share a SYS_CONFIG_NAME, but only display5_defconfig enables CONFIG_BOOTCOUNT_LIMIT, so we fail to set bootlimit= in display5_factory_defconfig. This is okay because the display5_factory_defconfig doesn't need to have it set, as it is only meant to prepare the board in the factory. Environment changes for all modified configs as seen from buildman: boards.cfg is up to date. Nothing to do. Summary of 3 commits for 32 boards (8 threads, 1 job per thread) 01: Merge git://git.denx.de/u-boot-x86 arm: + draco etamin rastaban pxm2 display5 thuban rut 02: Add BOOTCOUNT_BOOTLIMIT to set reboot limit 03: Migrate bootlimit to Kconfig - display5_factory: bootlimit=3 Signed-off-by: Alex Kiernan Reviewed-by: Lukasz Majewski --- Changes in v3: - Rebase - Add Lukasz' Reviewed-by Changes in v2: - include display5 in the migration to Kconfig configs/calimain_defconfig | 1 + configs/display5_defconfig | 1 + configs/draco_defconfig| 1 + configs/etamin_defconfig | 1 + configs/ge_bx50v3_defconfig| 1 + configs/km_kirkwood_128m16_defconfig | 1 + configs/km_kirkwood_defconfig | 1 + configs/km_kirkwood_pci_defconfig | 1 + configs/kmcoge4_defconfig | 1 + configs/kmcoge5ne_defconfig| 1 + configs/kmcoge5un_defconfig| 1 + configs/kmeter1_defconfig | 1 + configs/kmlion1_defconfig | 1 + configs/kmnusa_defconfig | 1 + configs/kmopti2_defconfig | 1 + configs/kmsugp1_defconfig | 1 + configs/kmsupx5_defconfig | 1 + configs/kmsuv31_defconfig | 1 + configs/kmtegr1_defconfig | 1 + configs/kmtepr2_defconfig | 1 + configs/kmvect1_defconfig | 1 + configs/mgcoge3un_defconfig| 1 + configs/mx53ppd_defconfig | 1 + configs/portl2_defconfig | 1 + configs/pxm2_defconfig | 1 + configs/rastaban_defconfig | 1 + configs/rut_defconfig | 1 + configs/suvd3_defconfig| 1 + configs/thuban_defconfig | 1 + configs/tuge1_defconfig| 1 + configs/tuxx1_defconfig| 1 + include/configs/calimain.h | 1 - include/configs/display5.h | 1 - include/configs/ge_bx50v3.h| 1 - include/configs/km/keymile-common.h| 1 - include/configs/mx53ppd.h | 1 - include/configs/siemens-am33x-common.h | 1 - 37 files changed, 31 insertions(+), 6 deletions(-) diff --git a/configs/calimain_defconfig b/configs/calimain_defconfig index 7908cfcc34..55782463ae 100644 --- a/configs/calimain_defconfig +++ b/configs/calimain_defconfig @@ -22,6 +22,7 @@ CONFIG_CMD_PING=y CONFIG_CMD_DIAG=y CONFIG_ENV_IS_IN_FLASH=y CONFIG_BOOTCOUNT_LIMIT=y +CONFIG_BOOTCOUNT_BOOTLIMIT=3 CONFIG_SYS_BOOTCOUNT_ADDR=0x01C23000 # CONFIG_MMC is not set CONFIG_MTD_NOR_FLASH=y diff --git a/configs/display5_defconfig b/configs/display5_defconfig index 1f3007f1be..0222144bf3 100644 --- a/configs/display5_defconfig +++ b/configs/display5_defconfig @@ -56,6 +56,7 @@ CONFIG_MTDPARTS_DEFAULT="mtdparts=02008000.spi.1:128k(SPL),1m(u-boot),64k(env1), CONFIG_OF_CONTROL=y CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_BOOTCOUNT_LIMIT=y +CONFIG_BOOTCOUNT_BOOTLIMIT=3 CONFIG_SYS_BOOTCOUNT_SINGLEWORD=y CONFIG_SYS_BOOTCOUNT_ADDR=0x020CC068 CONFIG_FSL_ESDHC=y diff --git a/configs/draco_defconfig b/configs/draco_defconfig index 5c61659fe5..3f91b0699c 100644 --- a/configs/draco_defconfig +++ b/configs/draco_defconfig @@ -56,6 +56,7 @@ CONFIG_OF_EMBED=y CONFIG_ENV_IS_IN_NAND=y CONFIG_BOOTCOUNT_LIMIT=y CONFIG_BOOTCOUNT_ENV=y +CONFIG_BOOTCOUNT_BOOTLIMIT=3 CONFIG_DFU_NAND=y CONFIG_MMC_OMAP_HS=y CONFIG_NAND=y diff --git a/configs/etamin_defconfig b/configs/etamin_defconfig index 3bb9b2e34e..1ffea06294 100644 --- a/configs/etamin_defconfig +++ b/configs/etamin_defconfig @@ -56,6 +56,7 @@ CONFIG_OF_EMBED=y CONFIG_ENV_IS_IN_NAND=y CONFIG_BOOTCOUNT_LIMIT=y CONFIG_BOOTCOUNT_ENV=y +CONFIG_BOOTCOUNT_BOOTLIMIT=3 CONFIG_DFU_NAND=y CONFIG_MMC_OMAP_HS=y CONFIG_NAND=y diff --git a/configs/ge_bx50v3_defconfig b/configs/ge_bx50v3_defconfig index b312920a25..78bc91ff2c 100644 --- a/configs/ge_bx50v3_defconfig +++ b/configs/ge_bx50v3_defconfig @@ -28,6 +28,7 @@ CONFIG_DOS_PARTITION=y CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_BOOTCOUNT_LIMIT=y CONFIG_BOOTCOUNT_EXT=y +CONFIG_BOOTCOUNT_BOOTLIMIT=10 CONFIG_SYS_BOOTCOUNT_EXT_DEVPART="1:5" CONFIG_SYS_BOOTCOUNT_ADDR=0x7000A000 CONFIG_FSL_ESDHC=y diff --git a/configs/km_kirkwood_128m16_defco
[U-Boot] [PATCH v3 1/2] Add BOOTCOUNT_BOOTLIMIT to set reboot limit
Add ability to set environment bootlimit from Kconfig
Signed-off-by: Alex Kiernan
---
Changes in v3: None
Changes in v2: None
drivers/bootcount/Kconfig | 8
include/env_default.h | 3 +++
2 files changed, 11 insertions(+)
diff --git a/drivers/bootcount/Kconfig b/drivers/bootcount/Kconfig
index d335ed14b9..9a0bd516d9 100644
--- a/drivers/bootcount/Kconfig
+++ b/drivers/bootcount/Kconfig
@@ -72,6 +72,14 @@ config BOOTCOUNT_AT91
endchoice
+config BOOTCOUNT_BOOTLIMIT
+ int "Maximum number of reboot cycles allowed"
+ default 0
+ help
+ Set the Maximum number of reboot cycles allowed without the boot
+ counter being cleared.
+ If set to 0 do not set a boot limit in the environment.
+
config BOOTCOUNT_ALEN
int "I2C address length"
default 1
diff --git a/include/env_default.h b/include/env_default.h
index bd600cfa44..86b639d3e2 100644
--- a/include/env_default.h
+++ b/include/env_default.h
@@ -104,6 +104,9 @@ const uchar default_environment[] = {
"soc=" CONFIG_SYS_SOC "\0"
#endif
#endif
+#if defined(CONFIG_BOOTCOUNT_BOOTLIMIT) && (CONFIG_BOOTCOUNT_BOOTLIMIT > 0)
+ "bootlimit="__stringify(CONFIG_BOOTCOUNT_BOOTLIMIT)"\0"
+#endif
#ifdef CONFIG_EXTRA_ENV_SETTINGS
CONFIG_EXTRA_ENV_SETTINGS
#endif
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 0/2] Add bootlimit to Kconfig
This patch series adds the bootlimit environment variable to Kconfig and migrates users to it. Changes in v3: - Rebase - Add Lukasz' Reviewed-by Changes in v2: - include display5 in the migration to Kconfig Alex Kiernan (2): Add BOOTCOUNT_BOOTLIMIT to set reboot limit Migrate bootlimit to Kconfig configs/calimain_defconfig | 1 + configs/display5_defconfig | 1 + configs/draco_defconfig| 1 + configs/etamin_defconfig | 1 + configs/ge_bx50v3_defconfig| 1 + configs/km_kirkwood_128m16_defconfig | 1 + configs/km_kirkwood_defconfig | 1 + configs/km_kirkwood_pci_defconfig | 1 + configs/kmcoge4_defconfig | 1 + configs/kmcoge5ne_defconfig| 1 + configs/kmcoge5un_defconfig| 1 + configs/kmeter1_defconfig | 1 + configs/kmlion1_defconfig | 1 + configs/kmnusa_defconfig | 1 + configs/kmopti2_defconfig | 1 + configs/kmsugp1_defconfig | 1 + configs/kmsupx5_defconfig | 1 + configs/kmsuv31_defconfig | 1 + configs/kmtegr1_defconfig | 1 + configs/kmtepr2_defconfig | 1 + configs/kmvect1_defconfig | 1 + configs/mgcoge3un_defconfig| 1 + configs/mx53ppd_defconfig | 1 + configs/portl2_defconfig | 1 + configs/pxm2_defconfig | 1 + configs/rastaban_defconfig | 1 + configs/rut_defconfig | 1 + configs/suvd3_defconfig| 1 + configs/thuban_defconfig | 1 + configs/tuge1_defconfig| 1 + configs/tuxx1_defconfig| 1 + drivers/bootcount/Kconfig | 8 include/configs/calimain.h | 1 - include/configs/display5.h | 1 - include/configs/ge_bx50v3.h| 1 - include/configs/km/keymile-common.h| 1 - include/configs/mx53ppd.h | 1 - include/configs/siemens-am33x-common.h | 1 - include/env_default.h | 3 +++ 39 files changed, 42 insertions(+), 6 deletions(-) -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 21/25] fastboot: sunxi: Update fastboot mmc default device
On Thu, Jul 19, 2018 at 2:26 PM Maxime Ripard wrote: > > On Wed, Jul 18, 2018 at 08:15:23PM +0100, Alex Kiernan wrote: > > On Tue, Jul 17, 2018 at 12:57 PM Maxime Ripard > > wrote: > > > > > > On Mon, Jul 16, 2018 at 12:11:59PM +0100, Alex Kiernan wrote: > > > > On Mon, Jul 16, 2018 at 11:13 AM Jagan Teki > > > > wrote: > > > > > > > > > > On Mon, Jul 16, 2018 at 3:16 PM, Maxime Ripard > > > > > wrote: > > > > > > On Mon, Jul 16, 2018 at 01:49:52PM +0530, Jagan Teki wrote: > > > > > >> Usually eMMC is default env fat device for environment, > > > > > >> if MMC_SUNXI_SLOT_EXTRA != 1 Sunxi always probed emmc > > > > > >> device as 1. but with DM_MMC it can be more possible to > > > > > >> probe eMMC as device 2 since for most of the sunxi platforms > > > > > >> eMMC is configured mmc2. > > > > > >> > > > > > >> So update the fastboot mmc default device as 2 if DM_MMC and > > > > > >> MMC_SUNXI_SLOT_EXTRA != 1 slot is 2 defined but some boards > > > > > >> may not use all possible mmc devices or partly disabled in DT, > > > > > >> for those update the device in board specific defconfig. > > > > > >> > > > > > >> Cc: Olliver Schinagl > > > > > >> Cc: Chen-Yu Tsai > > > > > >> Signed-off-by: Jagan Teki > > > > > >> --- > > > > > >> configs/A20-OLinuXino-Lime2-eMMC_defconfig | 1 + > > > > > >> configs/Sinlinx_SinA33_defconfig | 1 + > > > > > >> configs/amarula_a64_relic_defconfig| 1 + > > > > > >> drivers/fastboot/Kconfig | 3 ++- > > > > > >> 4 files changed, 5 insertions(+), 1 deletion(-) > > > > > >> > > > > > >> diff --git a/configs/A20-OLinuXino-Lime2-eMMC_defconfig > > > > > >> b/configs/A20-OLinuXino-Lime2-eMMC_defconfig > > > > > >> index 5657fc2594..20ea254191 100644 > > > > > >> --- a/configs/A20-OLinuXino-Lime2-eMMC_defconfig > > > > > >> +++ b/configs/A20-OLinuXino-Lime2-eMMC_defconfig > > > > > >> @@ -29,4 +29,5 @@ CONFIG_AXP_ALDO4_VOLT=2800 > > > > > >> CONFIG_SCSI=y > > > > > >> CONFIG_USB_EHCI_HCD=y > > > > > >> CONFIG_USB_MUSB_GADGET=y > > > > > >> +CONFIG_FASTBOOT_FLASH_MMC_DEV=1 > > > > > >> CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y > > > > > >> diff --git a/configs/Sinlinx_SinA33_defconfig > > > > > >> b/configs/Sinlinx_SinA33_defconfig > > > > > >> index 394534b8b5..7841219a65 100644 > > > > > >> --- a/configs/Sinlinx_SinA33_defconfig > > > > > >> +++ b/configs/Sinlinx_SinA33_defconfig > > > > > >> @@ -21,5 +21,6 @@ CONFIG_DFU_RAM=y > > > > > >> CONFIG_FASTBOOT_CMD_OEM_FORMAT=y > > > > > >> CONFIG_USB_EHCI_HCD=y > > > > > >> CONFIG_USB_MUSB_GADGET=y > > > > > >> +CONFIG_FASTBOOT_FLASH_MMC_DEV=1 > > > > > > > > > > > > Your commit doesn't make any sense: the SinaA33 and the Lime2 both > > > > > > have the eMMC on MMC2, and you claim you want to update the default > > > > > > to > > > > > > point to MMC2, but you're changing both these boards to point to > > > > > > MMC1 > > > > > > instead? > > > > > > > > > > If DM_MMC and SLOT != 1 => default device 2 which is updated by > > > > > kconfig, this is with all relevant mmc nodes are enabled > > > > > but these two boards mmc1 is not enabled so emmc will detected in > > > > > device 1 > > > > > > > > > > > > > > > > >> CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y > > > > > >> CONFIG_USB_FUNCTION_MASS_STORAGE=y > > > > > >> diff --git a/configs/amarula_a64_relic_defconfig > > > > > >> b/configs/amarula_a64_relic_defconfig > > > > > >> index b72cbfabc6..caeb3f6008 100644 > > > > > >> --- a/configs/amarula_a64_relic_defconfig > > > > > >> +++ b/configs/amarula_a64_relic_defconfig > > > > > >> @@
Re: [U-Boot] [PATCH 21/25] fastboot: sunxi: Update fastboot mmc default device
On Tue, Jul 17, 2018 at 12:57 PM Maxime Ripard wrote: > > On Mon, Jul 16, 2018 at 12:11:59PM +0100, Alex Kiernan wrote: > > On Mon, Jul 16, 2018 at 11:13 AM Jagan Teki > > wrote: > > > > > > On Mon, Jul 16, 2018 at 3:16 PM, Maxime Ripard > > > wrote: > > > > On Mon, Jul 16, 2018 at 01:49:52PM +0530, Jagan Teki wrote: > > > >> Usually eMMC is default env fat device for environment, > > > >> if MMC_SUNXI_SLOT_EXTRA != 1 Sunxi always probed emmc > > > >> device as 1. but with DM_MMC it can be more possible to > > > >> probe eMMC as device 2 since for most of the sunxi platforms > > > >> eMMC is configured mmc2. > > > >> > > > >> So update the fastboot mmc default device as 2 if DM_MMC and > > > >> MMC_SUNXI_SLOT_EXTRA != 1 slot is 2 defined but some boards > > > >> may not use all possible mmc devices or partly disabled in DT, > > > >> for those update the device in board specific defconfig. > > > >> > > > >> Cc: Olliver Schinagl > > > >> Cc: Chen-Yu Tsai > > > >> Signed-off-by: Jagan Teki > > > >> --- > > > >> configs/A20-OLinuXino-Lime2-eMMC_defconfig | 1 + > > > >> configs/Sinlinx_SinA33_defconfig | 1 + > > > >> configs/amarula_a64_relic_defconfig| 1 + > > > >> drivers/fastboot/Kconfig | 3 ++- > > > >> 4 files changed, 5 insertions(+), 1 deletion(-) > > > >> > > > >> diff --git a/configs/A20-OLinuXino-Lime2-eMMC_defconfig > > > >> b/configs/A20-OLinuXino-Lime2-eMMC_defconfig > > > >> index 5657fc2594..20ea254191 100644 > > > >> --- a/configs/A20-OLinuXino-Lime2-eMMC_defconfig > > > >> +++ b/configs/A20-OLinuXino-Lime2-eMMC_defconfig > > > >> @@ -29,4 +29,5 @@ CONFIG_AXP_ALDO4_VOLT=2800 > > > >> CONFIG_SCSI=y > > > >> CONFIG_USB_EHCI_HCD=y > > > >> CONFIG_USB_MUSB_GADGET=y > > > >> +CONFIG_FASTBOOT_FLASH_MMC_DEV=1 > > > >> CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y > > > >> diff --git a/configs/Sinlinx_SinA33_defconfig > > > >> b/configs/Sinlinx_SinA33_defconfig > > > >> index 394534b8b5..7841219a65 100644 > > > >> --- a/configs/Sinlinx_SinA33_defconfig > > > >> +++ b/configs/Sinlinx_SinA33_defconfig > > > >> @@ -21,5 +21,6 @@ CONFIG_DFU_RAM=y > > > >> CONFIG_FASTBOOT_CMD_OEM_FORMAT=y > > > >> CONFIG_USB_EHCI_HCD=y > > > >> CONFIG_USB_MUSB_GADGET=y > > > >> +CONFIG_FASTBOOT_FLASH_MMC_DEV=1 > > > > > > > > Your commit doesn't make any sense: the SinaA33 and the Lime2 both > > > > have the eMMC on MMC2, and you claim you want to update the default to > > > > point to MMC2, but you're changing both these boards to point to MMC1 > > > > instead? > > > > > > If DM_MMC and SLOT != 1 => default device 2 which is updated by > > > kconfig, this is with all relevant mmc nodes are enabled > > > but these two boards mmc1 is not enabled so emmc will detected in device 1 > > > > > > > > > > >> CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y > > > >> CONFIG_USB_FUNCTION_MASS_STORAGE=y > > > >> diff --git a/configs/amarula_a64_relic_defconfig > > > >> b/configs/amarula_a64_relic_defconfig > > > >> index b72cbfabc6..caeb3f6008 100644 > > > >> --- a/configs/amarula_a64_relic_defconfig > > > >> +++ b/configs/amarula_a64_relic_defconfig > > > >> @@ -12,4 +12,5 @@ CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-amarula-relic" > > > >> # CONFIG_SPL_DOS_PARTITION is not set > > > >> # CONFIG_SPL_EFI_PARTITION is not set > > > >> CONFIG_USB_MUSB_GADGET=y > > > >> +CONFIG_FASTBOOT_FLASH_MMC_DEV=0 > > > >> CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y > > > >> diff --git a/drivers/fastboot/Kconfig b/drivers/fastboot/Kconfig > > > >> index bc25ea1d9c..4a1bfd119c 100644 > > > >> --- a/drivers/fastboot/Kconfig > > > >> +++ b/drivers/fastboot/Kconfig > > > >> @@ -88,7 +88,8 @@ config FASTBOOT_FLASH_MMC_DEV > > > >> int "Define FASTBOOT MMC FLASH default device" > > > >> depends on FASTBOOT_FLASH_MMC > > > >> default 0 if ARCH_SUNXI && MMC_SUNXI_S
Re: [U-Boot] [PATCH 21/25] fastboot: sunxi: Update fastboot mmc default device
On Mon, Jul 16, 2018 at 11:13 AM Jagan Teki wrote: > > On Mon, Jul 16, 2018 at 3:16 PM, Maxime Ripard > wrote: > > On Mon, Jul 16, 2018 at 01:49:52PM +0530, Jagan Teki wrote: > >> Usually eMMC is default env fat device for environment, > >> if MMC_SUNXI_SLOT_EXTRA != 1 Sunxi always probed emmc > >> device as 1. but with DM_MMC it can be more possible to > >> probe eMMC as device 2 since for most of the sunxi platforms > >> eMMC is configured mmc2. > >> > >> So update the fastboot mmc default device as 2 if DM_MMC and > >> MMC_SUNXI_SLOT_EXTRA != 1 slot is 2 defined but some boards > >> may not use all possible mmc devices or partly disabled in DT, > >> for those update the device in board specific defconfig. > >> > >> Cc: Olliver Schinagl > >> Cc: Chen-Yu Tsai > >> Signed-off-by: Jagan Teki > >> --- > >> configs/A20-OLinuXino-Lime2-eMMC_defconfig | 1 + > >> configs/Sinlinx_SinA33_defconfig | 1 + > >> configs/amarula_a64_relic_defconfig| 1 + > >> drivers/fastboot/Kconfig | 3 ++- > >> 4 files changed, 5 insertions(+), 1 deletion(-) > >> > >> diff --git a/configs/A20-OLinuXino-Lime2-eMMC_defconfig > >> b/configs/A20-OLinuXino-Lime2-eMMC_defconfig > >> index 5657fc2594..20ea254191 100644 > >> --- a/configs/A20-OLinuXino-Lime2-eMMC_defconfig > >> +++ b/configs/A20-OLinuXino-Lime2-eMMC_defconfig > >> @@ -29,4 +29,5 @@ CONFIG_AXP_ALDO4_VOLT=2800 > >> CONFIG_SCSI=y > >> CONFIG_USB_EHCI_HCD=y > >> CONFIG_USB_MUSB_GADGET=y > >> +CONFIG_FASTBOOT_FLASH_MMC_DEV=1 > >> CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y > >> diff --git a/configs/Sinlinx_SinA33_defconfig > >> b/configs/Sinlinx_SinA33_defconfig > >> index 394534b8b5..7841219a65 100644 > >> --- a/configs/Sinlinx_SinA33_defconfig > >> +++ b/configs/Sinlinx_SinA33_defconfig > >> @@ -21,5 +21,6 @@ CONFIG_DFU_RAM=y > >> CONFIG_FASTBOOT_CMD_OEM_FORMAT=y > >> CONFIG_USB_EHCI_HCD=y > >> CONFIG_USB_MUSB_GADGET=y > >> +CONFIG_FASTBOOT_FLASH_MMC_DEV=1 > > > > Your commit doesn't make any sense: the SinaA33 and the Lime2 both > > have the eMMC on MMC2, and you claim you want to update the default to > > point to MMC2, but you're changing both these boards to point to MMC1 > > instead? > > If DM_MMC and SLOT != 1 => default device 2 which is updated by > kconfig, this is with all relevant mmc nodes are enabled > but these two boards mmc1 is not enabled so emmc will detected in device 1 > > > > >> CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y > >> CONFIG_USB_FUNCTION_MASS_STORAGE=y > >> diff --git a/configs/amarula_a64_relic_defconfig > >> b/configs/amarula_a64_relic_defconfig > >> index b72cbfabc6..caeb3f6008 100644 > >> --- a/configs/amarula_a64_relic_defconfig > >> +++ b/configs/amarula_a64_relic_defconfig > >> @@ -12,4 +12,5 @@ CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-amarula-relic" > >> # CONFIG_SPL_DOS_PARTITION is not set > >> # CONFIG_SPL_EFI_PARTITION is not set > >> CONFIG_USB_MUSB_GADGET=y > >> +CONFIG_FASTBOOT_FLASH_MMC_DEV=0 > >> CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y > >> diff --git a/drivers/fastboot/Kconfig b/drivers/fastboot/Kconfig > >> index bc25ea1d9c..4a1bfd119c 100644 > >> --- a/drivers/fastboot/Kconfig > >> +++ b/drivers/fastboot/Kconfig > >> @@ -88,7 +88,8 @@ config FASTBOOT_FLASH_MMC_DEV > >> int "Define FASTBOOT MMC FLASH default device" > >> depends on FASTBOOT_FLASH_MMC > >> default 0 if ARCH_SUNXI && MMC_SUNXI_SLOT_EXTRA = -1 > >> - default 1 if ARCH_SUNXI && MMC_SUNXI_SLOT_EXTRA != -1 > >> + default 1 if ARCH_SUNXI && !DM_MMC && MMC_SUNXI_SLOT_EXTRA != -1 > >> + default 2 if ARCH_SUNXI && DM_MMC && MMC_SUNXI_SLOT_EXTRA != -1 > > > > It'd be better to be fixed properly, instead of just relying on a > > broken index. > > I don't think we can't do anything with this now, since this INDEX > more rely on SPL for pinctrl enablement. if you have any suggestion > please share. Would another answer (at least for this specific case) to change the fastboot code so it doesn't need the device number in advance? Given we get device names along the lines of 'mmcsda1', we could parse out the 'a' to figure out the device number (and then use the alias code so your board can expose a portable name). -- Alex Kiernan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH v2 1/2] Add BOOTCOUNT_BOOTLIMIT to set reboot limit
On Sun, Jul 15, 2018 at 10:36 AM Prabhakar Kushwaha wrote: > > > > -Original Message- > > From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Alex Kiernan > > Sent: Saturday, July 14, 2018 1:30 PM > > To: u-boot@lists.denx.de > > Cc: Thomas Petazzoni ; Martyn Welch > > ; Ian Ray > > Subject: [U-Boot] [RESEND PATCH v2 1/2] Add BOOTCOUNT_BOOTLIMIT to set > > reboot limit > > > > Add ability to set environment bootlimit from Kconfig > > > > Signed-off-by: Alex Kiernan > > --- > > > > Changes in v2: None > > > > drivers/bootcount/Kconfig | 8 > > include/env_default.h | 3 +++ > > 2 files changed, 11 insertions(+) > > > > diff --git a/drivers/bootcount/Kconfig b/drivers/bootcount/Kconfig index > > d335ed14b9..9a0bd516d9 100644 > > --- a/drivers/bootcount/Kconfig > > +++ b/drivers/bootcount/Kconfig > > @@ -72,6 +72,14 @@ config BOOTCOUNT_AT91 > > > > endchoice > > > > +config BOOTCOUNT_BOOTLIMIT > > + int "Maximum number of reboot cycles allowed" > > + default 0 > > + help > > + Set the Maximum number of reboot cycles allowed without the boot > > + counter being cleared. > > + If set to 0 do not set a boot limit in the environment. > > + > > Just a curiosity, if maximum number of reboot cycles expires, what will be > the behavior of u-boot? > It depends on which bootcount implementation you're using, I expect some are undefined. For the default based on a u32, it'll wrap to 0 (which IIRC is defined behaviour in C) and you'll go back to the bootcmd flow rather than altbootcmd. > --pk > > -- Alex Kiernan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [RESEND PATCH v2 2/2] Migrate bootlimit to Kconfig
Migrate boards which set bootlimit in the environment to Kconfig. We exclude gurnard_defconfig which includes a bootlimit=, but doesn't set CONFIG_BOOTCOUNT_LIMIT, so we'd fail to include a bootlimit setting if we migrated it. display5_defconfig and display5_factory_defconfig share a SYS_CONFIG_NAME, but only display5_defconfig enables CONFIG_BOOTCOUNT_LIMIT, so we fail to set bootlimit= in display5_factory_defconfig. This is okay because the display5_factory_defconfig doesn't need to have it set, as it is only meant to prepare the board in the factory. Signed-off-by: Alex Kiernan --- Changes in v2: - include display5 in the migration to Kconfig configs/brppt1_mmc_defconfig | 1 + configs/brppt1_nand_defconfig | 1 + configs/brppt1_spi_defconfig | 1 + configs/calimain_defconfig | 1 + configs/display5_defconfig | 1 + configs/draco_defconfig| 1 + configs/etamin_defconfig | 1 + configs/ge_bx50v3_defconfig| 1 + configs/km_kirkwood_128m16_defconfig | 1 + configs/km_kirkwood_defconfig | 1 + configs/km_kirkwood_pci_defconfig | 1 + configs/kmcoge4_defconfig | 1 + configs/kmcoge5ne_defconfig| 1 + configs/kmcoge5un_defconfig| 1 + configs/kmeter1_defconfig | 1 + configs/kmlion1_defconfig | 1 + configs/kmnusa_defconfig | 1 + configs/kmopti2_defconfig | 1 + configs/kmsugp1_defconfig | 1 + configs/kmsupx5_defconfig | 1 + configs/kmsuv31_defconfig | 1 + configs/kmtegr1_defconfig | 1 + configs/kmtepr2_defconfig | 1 + configs/kmvect1_defconfig | 1 + configs/mgcoge3un_defconfig| 1 + configs/mx53ppd_defconfig | 1 + configs/portl2_defconfig | 1 + configs/pxm2_defconfig | 1 + configs/rastaban_defconfig | 1 + configs/rut_defconfig | 1 + configs/suvd3_defconfig| 1 + configs/thuban_defconfig | 1 + configs/tuge1_defconfig| 1 + configs/tuxx1_defconfig| 1 + include/configs/brppt1.h | 2 -- include/configs/calimain.h | 1 - include/configs/display5.h | 1 - include/configs/ge_bx50v3.h| 1 - include/configs/km/keymile-common.h| 1 - include/configs/mx53ppd.h | 1 - include/configs/siemens-am33x-common.h | 1 - 41 files changed, 34 insertions(+), 8 deletions(-) diff --git a/configs/brppt1_mmc_defconfig b/configs/brppt1_mmc_defconfig index a9d0f71fbe..7fb28b134b 100644 --- a/configs/brppt1_mmc_defconfig +++ b/configs/brppt1_mmc_defconfig @@ -50,6 +50,7 @@ CONFIG_CMD_FS_GENERIC=y CONFIG_ENV_IS_IN_MMC=y CONFIG_NETCONSOLE=y CONFIG_BOOTCOUNT_LIMIT=y +CONFIG_BOOTCOUNT_BOOTLIMIT=1 CONFIG_MMC_OMAP_HS=y CONFIG_DRIVER_TI_CPSW=y CONFIG_SYS_NS16550=y diff --git a/configs/brppt1_nand_defconfig b/configs/brppt1_nand_defconfig index ac50abc661..240e1187b2 100644 --- a/configs/brppt1_nand_defconfig +++ b/configs/brppt1_nand_defconfig @@ -51,6 +51,7 @@ CONFIG_MTDPARTS_DEFAULT="mtdparts=omap2-nand.0:128k(MLO),128k(MLO.backup),128k(d CONFIG_ENV_IS_IN_NAND=y CONFIG_NETCONSOLE=y CONFIG_BOOTCOUNT_LIMIT=y +CONFIG_BOOTCOUNT_BOOTLIMIT=1 # CONFIG_MMC is not set CONFIG_NAND=y CONFIG_DRIVER_TI_CPSW=y diff --git a/configs/brppt1_spi_defconfig b/configs/brppt1_spi_defconfig index 140a7ddfef..a12184cff4 100644 --- a/configs/brppt1_spi_defconfig +++ b/configs/brppt1_spi_defconfig @@ -57,6 +57,7 @@ CONFIG_CMD_MTDPARTS=y CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_NETCONSOLE=y CONFIG_BOOTCOUNT_LIMIT=y +CONFIG_BOOTCOUNT_BOOTLIMIT=1 CONFIG_MMC_OMAP_HS=y CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_STMICRO=y diff --git a/configs/calimain_defconfig b/configs/calimain_defconfig index 7908cfcc34..55782463ae 100644 --- a/configs/calimain_defconfig +++ b/configs/calimain_defconfig @@ -22,6 +22,7 @@ CONFIG_CMD_PING=y CONFIG_CMD_DIAG=y CONFIG_ENV_IS_IN_FLASH=y CONFIG_BOOTCOUNT_LIMIT=y +CONFIG_BOOTCOUNT_BOOTLIMIT=3 CONFIG_SYS_BOOTCOUNT_ADDR=0x01C23000 # CONFIG_MMC is not set CONFIG_MTD_NOR_FLASH=y diff --git a/configs/display5_defconfig b/configs/display5_defconfig index 1f3007f1be..0222144bf3 100644 --- a/configs/display5_defconfig +++ b/configs/display5_defconfig @@ -56,6 +56,7 @@ CONFIG_MTDPARTS_DEFAULT="mtdparts=02008000.spi.1:128k(SPL),1m(u-boot),64k(env1), CONFIG_OF_CONTROL=y CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_BOOTCOUNT_LIMIT=y +CONFIG_BOOTCOUNT_BOOTLIMIT=3 CONFIG_SYS_BOOTCOUNT_SINGLEWORD=y CONFIG_SYS_BOOTCOUNT_ADDR=0x020CC068 CONFIG_FSL_ESDHC=y diff --git a/configs/draco_defconfig b/configs/draco_defconfig index 5c61659fe5..3f91b0699c 100644 --- a/configs/draco_defconfig +++ b/configs/draco_defconfig @@ -56,6 +56,7 @@ CONFIG_OF_EMBED=y CONFIG_ENV_IS_IN_NAND=y CONFIG_BOOTCOUNT_LIMIT=y CONFIG_BOOTC
[U-Boot] [RESEND PATCH v2 0/2] Add bootlimit to Kconfig
This patch series adds the bootlimit environment variable to Kconfig and migrates users to it. Changes in v2: - include display5 in the migration to Kconfig Alex Kiernan (2): Add BOOTCOUNT_BOOTLIMIT to set reboot limit Migrate bootlimit to Kconfig configs/brppt1_mmc_defconfig | 1 + configs/brppt1_nand_defconfig | 1 + configs/brppt1_spi_defconfig | 1 + configs/calimain_defconfig | 1 + configs/display5_defconfig | 1 + configs/draco_defconfig| 1 + configs/etamin_defconfig | 1 + configs/ge_bx50v3_defconfig| 1 + configs/km_kirkwood_128m16_defconfig | 1 + configs/km_kirkwood_defconfig | 1 + configs/km_kirkwood_pci_defconfig | 1 + configs/kmcoge4_defconfig | 1 + configs/kmcoge5ne_defconfig| 1 + configs/kmcoge5un_defconfig| 1 + configs/kmeter1_defconfig | 1 + configs/kmlion1_defconfig | 1 + configs/kmnusa_defconfig | 1 + configs/kmopti2_defconfig | 1 + configs/kmsugp1_defconfig | 1 + configs/kmsupx5_defconfig | 1 + configs/kmsuv31_defconfig | 1 + configs/kmtegr1_defconfig | 1 + configs/kmtepr2_defconfig | 1 + configs/kmvect1_defconfig | 1 + configs/mgcoge3un_defconfig| 1 + configs/mx53ppd_defconfig | 1 + configs/portl2_defconfig | 1 + configs/pxm2_defconfig | 1 + configs/rastaban_defconfig | 1 + configs/rut_defconfig | 1 + configs/suvd3_defconfig| 1 + configs/thuban_defconfig | 1 + configs/tuge1_defconfig| 1 + configs/tuxx1_defconfig| 1 + drivers/bootcount/Kconfig | 8 include/configs/brppt1.h | 2 -- include/configs/calimain.h | 1 - include/configs/display5.h | 1 - include/configs/ge_bx50v3.h| 1 - include/configs/km/keymile-common.h| 1 - include/configs/mx53ppd.h | 1 - include/configs/siemens-am33x-common.h | 1 - include/env_default.h | 3 +++ 43 files changed, 45 insertions(+), 8 deletions(-) -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [RESEND PATCH v2 1/2] Add BOOTCOUNT_BOOTLIMIT to set reboot limit
Add ability to set environment bootlimit from Kconfig
Signed-off-by: Alex Kiernan
---
Changes in v2: None
drivers/bootcount/Kconfig | 8
include/env_default.h | 3 +++
2 files changed, 11 insertions(+)
diff --git a/drivers/bootcount/Kconfig b/drivers/bootcount/Kconfig
index d335ed14b9..9a0bd516d9 100644
--- a/drivers/bootcount/Kconfig
+++ b/drivers/bootcount/Kconfig
@@ -72,6 +72,14 @@ config BOOTCOUNT_AT91
endchoice
+config BOOTCOUNT_BOOTLIMIT
+ int "Maximum number of reboot cycles allowed"
+ default 0
+ help
+ Set the Maximum number of reboot cycles allowed without the boot
+ counter being cleared.
+ If set to 0 do not set a boot limit in the environment.
+
config BOOTCOUNT_ALEN
int "I2C address length"
default 1
diff --git a/include/env_default.h b/include/env_default.h
index 54d8124793..748076288e 100644
--- a/include/env_default.h
+++ b/include/env_default.h
@@ -104,6 +104,9 @@ const uchar default_environment[] = {
"soc=" CONFIG_SYS_SOC "\0"
#endif
#endif
+#if defined(CONFIG_BOOTCOUNT_BOOTLIMIT) && (CONFIG_BOOTCOUNT_BOOTLIMIT > 0)
+ "bootlimit="__stringify(CONFIG_BOOTCOUNT_BOOTLIMIT)"\0"
+#endif
#ifdef CONFIG_EXTRA_ENV_SETTINGS
CONFIG_EXTRA_ENV_SETTINGS
#endif
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] buildman failures and toolchains
On Sat, Jul 7, 2018 at 3:43 AM Adam Ford wrote: > > I am going to sound stupid, but I'm struggling to install all the > toolchains and use them with buildroot. I upgraded to Ubuntu 18.04 > and whenever try to run buildman, or attempt to build the moveconfig > database I get failures. > > i get the following error on every architecture type: > cc1: error while loading shared libraries: libmpfr.so.4: cannot > open shared object file: No such > file or directory > > I have confirmed that I have libmpfr installed on my host machine. > Does anyone have any suggestions? > From memory I just grabbed the 17.10 deb and installed that on 18.04: http://mirrors.kernel.org/ubuntu/pool/main/m/mpfr4/libmpfr4_3.1.6-1_amd64.deb Shout if that doesn't work and I'll dig some more. -- Alex Kiernan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] bootmenu: Extend BOOTDELAY help text
Extend BOOTDELAY help text to cover its additional usage within the bootmenu command. Signed-off-by: Alex Kiernan --- common/Kconfig | 4 1 file changed, 4 insertions(+) diff --git a/common/Kconfig b/common/Kconfig index 4c7a1a9af8..81e88ea77c 100644 --- a/common/Kconfig +++ b/common/Kconfig @@ -182,6 +182,10 @@ config BOOTDELAY set to -1 to disable autoboot. set to -2 to autoboot with no delay and not check for abort + If this value is >= 0 then it is also used for the default delay + before starting the default entry in bootmenu. If it is < 0 then + a default value of 10s is used. + See doc/README.autoboot for details. config USE_BOOTARGS -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] env: Include bootdelay in environment if negative
The test for (CONFIG_BOOTDELAY >= 0) has been in U-Boot since the
beginning, but the meaning of it has changed over time. Allow the
default to be set for any value, including -ve ones. This allows
(for example) CONFIG_ENV_IS_NOWHERE to have values for bootdelay in
its compiled in environment.
The only thing this changes is where the default for bootdelay can be
fetched from; before this change you get a compiled in default, after
you'll pull it from the default value in the environment, but both values
will be the same. Also if there's a value set in the environment then
that will take precedence (as before).
Signed-off-by: Alex Kiernan
---
include/env_default.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/env_default.h b/include/env_default.h
index 54d8124793..bd600cfa44 100644
--- a/include/env_default.h
+++ b/include/env_default.h
@@ -40,7 +40,7 @@ const uchar default_environment[] = {
#ifdef CONFIG_NFSBOOTCOMMAND
"nfsboot=" CONFIG_NFSBOOTCOMMAND "\0"
#endif
-#if defined(CONFIG_BOOTDELAY) && (CONFIG_BOOTDELAY >= 0)
+#if defined(CONFIG_BOOTDELAY)
"bootdelay="__stringify(CONFIG_BOOTDELAY) "\0"
#endif
#if defined(CONFIG_BAUDRATE) && (CONFIG_BAUDRATE >= 0)
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 4/5] cmd: nvedit: env import can now import only variables passed as parameters
d a list of vars to import, the whole environment > is deleted and only the vars in the list of vars are imported in the > environnement. This is what you fear and I agree this isn't a very nice > design. > > > So such a default is just dangerous, and (IMO) must be avoided. > > > > I think we misunderstood each other on the proposed patch last mail. > > Let me recapitulate what is the current behaviour (correct me if I'm > wrong). > > The current behaviour is the following: > > 1) himport_r withOUT a list of variables (vars=NULL) and with flag = 0: > = delete the current hash table and then import the environnement, > the example for this is basically: env import -d 0xaddr > 2) himport_r withOUT a list of variables (vars=NULL) and with flag = > H_NOCLEAR: > = do NOT delete the current hash table and then import the environnement, > the example for this is basically: env import 0xaddr > 3) himport_r WITH a list of variables (vars!=NULL) and with flag = 0: > = delete the current hash table and then import the variables vars > from the environnement to be imported, > the example for this is basically: env import -d 0xaddr varA varB varC > 4) himport_r WITH a list of variables (vars!=NULL) and with flag = > H_NOCLEAR: > = do NOT delete the current hash table and then import the variables vars > from the environnement to be imported, IF a var A in vars is not > present in the environnement to be imported, var A is removed from the > current environnement. > the example for this is basically: env import 0xaddr varA varB varC > > What I suggested is to modify 3 and 4) to the following: > 3) himport_r WITH a list of variables (vars!=NULL) and with flag = 0: > = import the variables vars from the environnement to be imported, IF > a var A in vars is not present in the environnement to be imported, > var A is removed from the current environnement. > the example for this is basically: env import -d 0xaddr varA varB varC > 4) himport_r WITH a list of variables (vars!=NULL) and with flag = > H_NOCLEAR: > = import the variables vars from the environnement to be imported, > the example for this is basically: env import 0xaddr varA varB varC > > This is what the proposed snippet in last mail is supposed to do. > > Hopefully, I better explained it. Let me know. > Certainly an option to leave existing values there and only overwrite if them if there are new values in the imported env would be very useful. -- Alex Kiernan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] CONFIG_BOOTDELAY and env_default.h
On Mon, Jul 2, 2018 at 3:25 AM Tom Rini wrote:
>
> On Fri, Jun 29, 2018 at 09:19:34PM -0700, Simon Glass wrote:
> > +Tom
> >
> > Hi Alex,
> >
> > On 29 June 2018 at 02:31, Alex Kiernan wrote:
> > >
> > > I've just been digging into a problem where I've got both
> > > CONFIG_ENV_IS_NOWHERE set and CONFIG_BOOTDELAY set to -2 and it turns
> > > out in env_default.h we have:
> > >
> > > #if defined(CONFIG_BOOTDELAY) && (CONFIG_BOOTDELAY >= 0)
> > > "bootdelay="__stringify(CONFIG_BOOTDELAY) "\0"
> > > #endifreason
> > >
> > > So the -ve values never make it into the default environment, which
> > > means I don't have it at all when CONFIG_ENV_IS_NOWHERE.
> > >
> > > The (CONFIG_BOOTDELAY >= 0) seems to have been there forever
> > > (c609719b8d1b2dca590e0ed499016d041203e403, Sun Nov 3 00:24:07 2002
> > > + is as far back as I've gone), but we've then changed the
> > > behaviours of the bootdelay values in (the commit I was looking at was
> > > 2fbb8462b0e18893b4b739705db047ffda82d4fc from Mon Jun 27 16:23:01 2016
> > > +0900, but I'm not sure that's really the right one)
> > >
> > > I think we should change the code to a simple #if
> > > defined(CONFIG_BOOTDELAY)
> > >
> > > ?
> >
> > I don't know what the check was supposed to do and the comment on the
> > 'bootdelay' env variable just says 'see CONFIG_BOOTDELAY'. Your
> > solution sounds reasonable to me but perhaps Tom or Wolfgang have more
> > insight.
>
> It seems like a historical oversight. But.. what happens before and
> after when you have a negative bootdelay value in the default
> environment?
>
It's a bit convoluted...
There's bootmenu, where (CONFIG_BOOTDELAY >= 0) supplies a compile
time default, which can be overridden by options to the command, or
the bootmenu_delay environment variable. This never looks at the
bootdelay environment variable, so I think we can ignore this one.
Then there's autoboot, which reads the environment for bootdelay, but
if that's not set then uses CONFIG_BOOTDELAY as a default.
So whilst you end up with the default in all cases, it's only stored
in the environment if it's >= 0.
Looking at the only place bootdelay is read from the environment (in
bootdelay_process):
s = env_get("bootdelay");
bootdelay = s ? (int)simple_strtol(s, NULL, 10) : CONFIG_BOOTDELAY;
So if you have a compiled in -ve CONFIG_BOOTDELAY, there won't be a
value for bootdelay in the default environment and we'll use the
compile time default. Swap to storing all values of CONFIG_BOOTDELAY
and you'll fetch it from the environment, rather than using the
compile time default.
So long as we don't remove the CONFIG_BOOTDELAY in this ternary
expression, I think you end up with the same behaviour in every
circumstance.
The reason I tripped over it was some scripting in CONFIG_PREBOOT
which was common between two configurations, but was expecting to
differentiate between them based on bootdelay (which broke when it
turned out to not be set).
--
Alex Kiernan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] CONFIG_BOOTDELAY and env_default.h
I've just been digging into a problem where I've got both CONFIG_ENV_IS_NOWHERE set and CONFIG_BOOTDELAY set to -2 and it turns out in env_default.h we have: #if defined(CONFIG_BOOTDELAY) && (CONFIG_BOOTDELAY >= 0) "bootdelay="__stringify(CONFIG_BOOTDELAY) "\0" #endif So the -ve values never make it into the default environment, which means I don't have it at all when CONFIG_ENV_IS_NOWHERE. The (CONFIG_BOOTDELAY >= 0) seems to have been there forever (c609719b8d1b2dca590e0ed499016d041203e403, Sun Nov 3 00:24:07 2002 + is as far back as I've gone), but we've then changed the behaviours of the bootdelay values in (the commit I was looking at was 2fbb8462b0e18893b4b739705db047ffda82d4fc from Mon Jun 27 16:23:01 2016 +0900, but I'm not sure that's really the right one) I think we should change the code to a simple #if defined(CONFIG_BOOTDELAY) ? -- Alex Kiernan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] cmd: fit_image: Add default property for FIT format scripts
When sourcing a FIT format script, if we've not been told the unit name
to use, look for a default property at the root of /images to work out
which unit we should use.
Signed-off-by: Alex Kiernan
---
cmd/source.c | 31 ++-
1 file changed, 26 insertions(+), 5 deletions(-)
diff --git a/cmd/source.c b/cmd/source.c
index 92481c4fff..6d98a1cfd3 100644
--- a/cmd/source.c
+++ b/cmd/source.c
@@ -22,6 +22,24 @@
#include
#include
+#if defined(CONFIG_FIT)
+/**
+ * get_default_image() - Return default property from /images
+ *
+ * Return: Pointer to value of default property (or NULL)
+ */
+static const char *get_default_image(const void *fit)
+{
+ int images_noffset;
+
+ images_noffset = fdt_path_offset(fit, FIT_IMAGES_PATH);
+ if (images_noffset < 0)
+ return NULL;
+
+ return fdt_getprop(fit, images_noffset, FIT_DEFAULT_PROP, NULL);
+}
+#endif
+
int
source (ulong addr, const char *fit_uname)
{
@@ -87,17 +105,20 @@ source (ulong addr, const char *fit_uname)
#endif
#if defined(CONFIG_FIT)
case IMAGE_FORMAT_FIT:
- if (fit_uname == NULL) {
- puts ("No FIT subimage unit name\n");
- return 1;
- }
-
fit_hdr = buf;
if (!fit_check_format (fit_hdr)) {
puts ("Bad FIT image format\n");
return 1;
}
+ if (!fit_uname)
+ fit_uname = get_default_image(fit_hdr);
+
+ if (!fit_uname) {
+ puts("No FIT subimage unit name\n");
+ return 1;
+ }
+
/* get script component image node offset */
noffset = fit_image_get_node (fit_hdr, fit_uname);
if (noffset < 0) {
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] mkimage: fit_image: Add support for SOURCE_DATE_EPOCH in signatures
When generating timestamps in signatures, use imagetool_get_source_date()
so we can be overridden by SOURCE_DATE_EPOCH to generate reproducible
images.
Signed-off-by: Alex Kiernan
---
include/image.h| 3 ++-
tools/fit_image.c | 3 ++-
tools/image-host.c | 34 --
3 files changed, 24 insertions(+), 16 deletions(-)
diff --git a/include/image.h b/include/image.h
index 420b8ff576..3bb7d29ef2 100644
--- a/include/image.h
+++ b/include/image.h
@@ -1009,6 +1009,7 @@ int fit_set_timestamp(void *fit, int noffset, time_t
timestamp);
* @comment: Comment to add to signature nodes
* @require_keys: Mark all keys as 'required'
* @engine_id: Engine to use for signing
+ * @cmdname: Command name used when reporting errors
*
* Adds hash values for all component images in the FIT blob.
* Hashes are calculated for all component images which have hash subnodes
@@ -1022,7 +1023,7 @@ int fit_set_timestamp(void *fit, int noffset, time_t
timestamp);
*/
int fit_add_verification_data(const char *keydir, void *keydest, void *fit,
const char *comment, int require_keys,
- const char *engine_id);
+ const char *engine_id, const char *cmdname);
int fit_image_verify_with_data(const void *fit, int image_noffset,
const void *data, size_t size);
diff --git a/tools/fit_image.c b/tools/fit_image.c
index 6f09a66106..3c265357ae 100644
--- a/tools/fit_image.c
+++ b/tools/fit_image.c
@@ -60,7 +60,8 @@ static int fit_add_file_data(struct image_tool_params
*params, size_t size_inc,
ret = fit_add_verification_data(params->keydir, dest_blob, ptr,
params->comment,
params->require_keys,
- params->engine_id);
+ params->engine_id,
+ params->cmdname);
}
if (dest_blob) {
diff --git a/tools/image-host.c b/tools/image-host.c
index 8e43671714..faa5e23c79 100644
--- a/tools/image-host.c
+++ b/tools/image-host.c
@@ -106,7 +106,7 @@ static int fit_image_process_hash(void *fit, const char
*image_name,
*/
static int fit_image_write_sig(void *fit, int noffset, uint8_t *value,
int value_len, const char *comment, const char *region_prop,
- int region_proplen)
+ int region_proplen, const char *cmdname)
{
int string_size;
int ret;
@@ -128,8 +128,12 @@ static int fit_image_write_sig(void *fit, int noffset,
uint8_t *value,
}
if (comment && !ret)
ret = fdt_setprop_string(fit, noffset, "comment", comment);
- if (!ret)
- ret = fit_set_timestamp(fit, noffset, time(NULL));
+ if (!ret) {
+ time_t timestamp = imagetool_get_source_date(cmdname,
+time(NULL));
+
+ ret = fit_set_timestamp(fit, noffset, timestamp);
+ }
if (region_prop && !ret) {
uint32_t strdata[2];
@@ -200,7 +204,8 @@ static int fit_image_setup_sig(struct image_sign_info *info,
static int fit_image_process_sig(const char *keydir, void *keydest,
void *fit, const char *image_name,
int noffset, const void *data, size_t size,
- const char *comment, int require_keys, const char *engine_id)
+ const char *comment, int require_keys, const char *engine_id,
+ const char *cmdname)
{
struct image_sign_info info;
struct image_region region;
@@ -228,7 +233,7 @@ static int fit_image_process_sig(const char *keydir, void
*keydest,
}
ret = fit_image_write_sig(fit, noffset, value, value_len, comment,
- NULL, 0);
+ NULL, 0, cmdname);
if (ret) {
if (ret == -FDT_ERR_NOSPACE)
return -ENOSPC;
@@ -295,7 +300,7 @@ static int fit_image_process_sig(const char *keydir, void
*keydest,
*/
int fit_image_add_verification_data(const char *keydir, void *keydest,
void *fit, int image_noffset, const char *comment,
- int require_keys, const char *engine_id)
+ int require_keys, const char *engine_id, const char *cmdname)
{
const char *image_name;
const void *data;
@@ -332,7 +337,7 @@ int fit_image_add_verification_data(const char *keydir,
void *keydest,
strlen(FIT_SIG_NODENAME))) {
ret = fit_image_process_sig(keydir, keydest,
fit, image_name, noffset, data, size,
- comment, require_keys, engine_id);
+
[U-Boot] [PATCH 1/2] mkimage: Refactor imagetool_get_source_date to take command name
So we can use imagetool_get_source_date() from callers who do not have
the image tool params struct, just pass in the command name for the error
message.
Signed-off-by: Alex Kiernan
---
tools/default_image.c | 2 +-
tools/fit_image.c | 3 ++-
tools/imagetool.c | 4 ++--
tools/imagetool.h | 4 ++--
4 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/tools/default_image.c b/tools/default_image.c
index 4abff4543a..4b7d1ed4a1 100644
--- a/tools/default_image.c
+++ b/tools/default_image.c
@@ -100,7 +100,7 @@ static void image_set_header(void *ptr, struct stat *sbuf,
int ifd,
sizeof(image_header_t)),
sbuf->st_size - sizeof(image_header_t));
- time = imagetool_get_source_date(params, sbuf->st_mtime);
+ time = imagetool_get_source_date(params->cmdname, sbuf->st_mtime);
ep = params->ep;
addr = params->addr;
diff --git a/tools/fit_image.c b/tools/fit_image.c
index e55a8943e7..6f09a66106 100644
--- a/tools/fit_image.c
+++ b/tools/fit_image.c
@@ -51,7 +51,8 @@ static int fit_add_file_data(struct image_tool_params
*params, size_t size_inc,
/* for first image creation, add a timestamp at offset 0 i.e., root */
if (params->datafile) {
- time_t time = imagetool_get_source_date(params, sbuf.st_mtime);
+ time_t time = imagetool_get_source_date(params->cmdname,
+ sbuf.st_mtime);
ret = fit_set_timestamp(ptr, 0, time);
}
diff --git a/tools/imagetool.c b/tools/imagetool.c
index a4e39b24bc..b3e628f612 100644
--- a/tools/imagetool.c
+++ b/tools/imagetool.c
@@ -116,7 +116,7 @@ int imagetool_get_filesize(struct image_tool_params
*params, const char *fname)
}
time_t imagetool_get_source_date(
-struct image_tool_params *params,
+const char *cmdname,
time_t fallback)
{
char *source_date_epoch = getenv("SOURCE_DATE_EPOCH");
@@ -128,7 +128,7 @@ time_t imagetool_get_source_date(
if (gmtime() == NULL) {
fprintf(stderr, "%s: SOURCE_DATE_EPOCH is not valid\n",
- params->cmdname);
+ cmdname);
time = 0;
}
diff --git a/tools/imagetool.h b/tools/imagetool.h
index d191b9cfe7..63c08ebc09 100644
--- a/tools/imagetool.h
+++ b/tools/imagetool.h
@@ -216,12 +216,12 @@ int imagetool_get_filesize(struct image_tool_params
*params, const char *fname);
* an error message if SOURCE_DATE_EPOCH contains an invalid value and returns
* 0.
*
- * @params:mkimage parameters
+ * @cmdname: command name
* @fallback: timestamp to use if SOURCE_DATE_EPOCH isn't set
* @return timestamp based on SOURCE_DATE_EPOCH
*/
time_t imagetool_get_source_date(
- struct image_tool_params *params,
+ const char *cmdname,
time_t fallback);
/*
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] Default script entry using FIT format scripts
I'm trying to get a build going without the legacy image format, but I need boot scripts (and I'm using distro boot). I'm coming unstuck when trying to boot one as there's no way to pass in the FIT unit name to source with distro boot. Would adding a default property inside /images (like we have inside /configurations for bootable images) be a reasonable approach? Trying to add the full configuration machinery feels over the top (though I'm wondering if down the road we want signed scripts if that might preclude it). -- Alex Kiernan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Duplicate description in Kconfig for SPL_LOAD_FIT/SPL_LOAD_FIT_FULL
We've got this in Kconfig: config SPL_LOAD_FIT bool "Enable SPL loading U-Boot as a FIT" select SPL_FIT help Normally with the SPL framework a legacy image is generated as part of the build. This contains U-Boot along with information as to where it should be loaded. This option instead enables generation of a FIT (Flat Image Tree) which provides more flexibility. In particular it can handle selecting from multiple device tree and passing the correct one to U-Boot. config SPL_LOAD_FIT_FULL bool "Enable SPL loading U-Boot as a FIT" select SPL_FIT help Normally with the SPL framework a legacy image is generated as part of the build. This contains U-Boot along with information as to where it should be loaded. This option instead enables generation of a FIT (Flat Image Tree) which provides more flexibility. In particular it can handle selecting from multiple device tree and passing the correct one to U-Boot. As far as I can see they're completely identical descriptions, presumably one should say something different? -- Alex Kiernan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] net: fastboot: Fix build when FASTBOOT_FLASH is disabled
When building without FASTBOOT_FLASH we don't include the intermediate update callback to keep the client alive, so ensure we don't try setting it here. Signed-off-by: Alex Kiernan --- net/fastboot.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/fastboot.c b/net/fastboot.c index a9f7c0743d..8afc5529cd 100644 --- a/net/fastboot.c +++ b/net/fastboot.c @@ -309,7 +309,9 @@ void fastboot_start_server(void) fastboot_our_port = WELL_KNOWN_PORT; +#if CONFIG_IS_ENABLED(FASTBOOT_FLASH) fastboot_set_progress_callback(fastboot_timed_send_info); +#endif net_set_udp_handler(fastboot_handler); /* zero out server ether in case the server ip has changed */ -- 2.17.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] mmc: Remove hwpartition help text when command is disabled
When the `mmc hwpartition` command is disabled, remove the associated help
text.
Signed-off-by: Alex Kiernan
---
cmd/mmc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/cmd/mmc.c b/cmd/mmc.c
index c2ee2d9c0a..3920a1836a 100644
--- a/cmd/mmc.c
+++ b/cmd/mmc.c
@@ -935,6 +935,7 @@ U_BOOT_CMD(
"mmc part - lists available partition on current mmc device\n"
"mmc dev [dev] [part] - show or set current mmc device [partition]\n"
"mmc list - lists available devices\n"
+#if CONFIG_IS_ENABLED(MMC_HW_PARTITIONING)
"mmc hwpartition [args...] - does hardware partitioning\n"
" arguments (sizes in 512-byte blocks):\n"
"[user [enh start cnt] [wrrel {on|off}]] - sets user data area
attributes\n"
@@ -942,6 +943,7 @@ U_BOOT_CMD(
"[check|set|complete] - mode, complete set partitioning completed\n"
" WARNING: Partitioning is a write-once setting once it is set to
complete.\n"
" Power cycling is required to initialize partitions after set to
complete.\n"
+#endif
#ifdef CONFIG_SUPPORT_EMMC_BOOT
"mmc bootbus dev boot_bus_width reset_boot_bus_width boot_mode\n"
" - Set the BOOT_BUS_WIDTH field of the specified device\n"
--
2.17.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] block: Add SPL_BLOCK_CACHE and default n
On Sat, Jun 9, 2018 at 11:55 PM Adam Ford wrote:
>
> When enabling BLOCK_CACHE on devices with limited RAM during SPL,
> some devices may not boot. This creates an option to enable
> block caching in SPL by defaults off. It is dependent on BLOCK_CACHE
> and SPL_BLK
>
> Fixes: 46960ad6d09b ("block: Have BLOCK_CACHE default to y in some cases")
>
> Signed-off-by: Adam Ford
> --
>
> V2: Clean up macros and ifdefs
>
> diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
> index 0792373cfc..8ef363b3d4 100644
> --- a/drivers/block/Kconfig
> +++ b/drivers/block/Kconfig
> @@ -37,6 +37,13 @@ config BLOCK_CACHE
> it will prevent repeated reads from directory structures and other
> filesystem data structures.
>
> +config SPL_BLOCK_CACHE
> + bool "Use block device cache in SPL"
> + depends on BLOCK_CACHE && SPL_BLK
Seems like an odd dependency - to use the block cache in SPL, you also
have to have block cache in full U-Boot? I'm guessing `depends on
SPL_BLK` would be sufficient
> + default n
> + help
> + This option enables the disk-block cache in SPL
> +
> config IDE
> bool "Support IDE controllers"
> select HAVE_BLOCK_DEVICE
> diff --git a/drivers/block/Makefile b/drivers/block/Makefile
> index 5fcafb193e..0e80ce9405 100644
> --- a/drivers/block/Makefile
> +++ b/drivers/block/Makefile
> @@ -11,4 +11,4 @@ endif
>
> obj-$(CONFIG_IDE) += ide.o
> obj-$(CONFIG_SANDBOX) += sandbox.o
> -obj-$(CONFIG_BLOCK_CACHE) += blkcache.o
> +obj-$(CONFIG_$(SPL_)BLOCK_CACHE) += blkcache.o
> diff --git a/include/blk.h b/include/blk.h
> index fc0c239e46..bd90e39932 100644
> --- a/include/blk.h
> +++ b/include/blk.h
> @@ -111,7 +111,8 @@ struct blk_desc {
> #define PAD_TO_BLOCKSIZE(size, blk_desc) \
> (PAD_SIZE(size, blk_desc->blksz))
>
> -#ifdef CONFIG_BLOCK_CACHE
> +#if (CONFIG_IS_ENABLED(BLOCK_CACHE) && !CONFIG_IS_ENABLED(SPL_BUILD)) || \
> +(CONFIG_IS_ENABLED(SPL_BLOCK_CACHE) && CONFIG_IS_ENABLED(SPL_BUILD))
Assuming I read it right, you shouldn't need all the &&/|| gyrations, just:
#if CONFIG_IS_ENABLED(BLOCK_CACHE)
Should get you what you want.
> /**
> * blkcache_read() - attempt to read a set of blocks from cache
> *
> --
> 2.17.1
>
--
Alex Kiernan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] block: Add SPL_BLOCK_CACHE and default n
On Sat, Jun 9, 2018 at 3:04 PM Adam Ford wrote:
>
> On Sat, Jun 9, 2018 at 8:26 AM Alex Kiernan wrote:
> >
> > On Fri, Jun 8, 2018 at 9:48 PM Adam Ford wrote:
> > >
> > > When enabling BLOCK_CACHE on devices with limited RAM during SPL,
> > > some devices may not boot. This creates an option to enable
> > > block caching in SPL by defaults off. It is dependant on BLOCK_CACHE
> > > and SPL_BLK
> > >
> > > Fixes: 46960ad6d09b ("block: Have BLOCK_CACHE default to y in some cases")
> > >
> > > Signed-off-by: Adam Ford
> > >
> > > diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
> > > index 0792373cfc..8ef363b3d4 100644
> > > --- a/drivers/block/Kconfig
> > > +++ b/drivers/block/Kconfig
> > > @@ -37,6 +37,13 @@ config BLOCK_CACHE
> > > it will prevent repeated reads from directory structures and
> > > other
> > > filesystem data structures.
> > >
> > > +config SPL_BLOCK_CACHE
> > > + bool "Use block device cache in SPL"
> > > + depends on BLOCK_CACHE && SPL_BLK
> > > + default n
> > > + help
> > > + This option enables the disk-block cache in SPL
> > > +
> > > config IDE
> > > bool "Support IDE controllers"
> > > select HAVE_BLOCK_DEVICE
> > > diff --git a/drivers/block/Makefile b/drivers/block/Makefile
> > > index 5fcafb193e..a9af28a552 100644
> > > --- a/drivers/block/Makefile
> > > +++ b/drivers/block/Makefile
> > > @@ -11,4 +11,9 @@ endif
> > >
> > > obj-$(CONFIG_IDE) += ide.o
> > > obj-$(CONFIG_SANDBOX) += sandbox.o
> > > +ifdef CONFIG_SPL_BUILD
> > > +obj-$(SPL_BLOCK_CACHE) += blkcache.o
> >
> > CONFIG_SPL_BLOCK_CACHE?
> >
> > > +endif
> > > +ifndef CONFIG_SPL_BUILD
> > > obj-$(CONFIG_BLOCK_CACHE) += blkcache.o
> > > +endif
> >
> > Could this all get replaced by:
> >
> > obj-$(CONFIG_$(SPL_)BLOCK_CACHE) += blkcache.o
> >
> Nicely done. I am not that familiar with Makefiles and how to clean
> that up, but it seems to work work this way at least for the AM3517
> EVM.
>
> > > diff --git a/include/blk.h b/include/blk.h
> > > index fc0c239e46..c17c5eb047 100644
> > > --- a/include/blk.h
> > > +++ b/include/blk.h
> > > @@ -111,7 +111,8 @@ struct blk_desc {
> > > #define PAD_TO_BLOCKSIZE(size, blk_desc) \
> > > (PAD_SIZE(size, blk_desc->blksz))
> > >
> > > -#ifdef CONFIG_BLOCK_CACHE
> > > +#if (defined(CONFIG_BLOCK_CACHE) && !defined(CONFIG_SPL_BUILD)) || \
> > > +(defined(CONFIG_SPL_BLOCK_CACHE) && defined(CONFIG_SPL_BUILD))
> > > /**
> >
> > Replace with CONFIG_IS_ENABLED?
>
> I tried replacing 'defined(x)' with 'CONFIG_IS_ENABLED(x)' and I got a
> bunch of build errors.
> The only way I could get it to work was using 'defined(x)'
>
You need to drop the CONFIG_ off the front of the symbol, something like:
#if CONFIG_IS_ENABLED(BLK_CACHE)
> adam
> >
> > > * blkcache_read() - attempt to read a set of blocks from cache
> > > *
> > > --
> > > 2.17.1
> > >
> > > ___
> > > U-Boot mailing list
> > > U-Boot@lists.denx.de
> > > https://lists.denx.de/listinfo/u-boot
> >
> >
> >
> > --
> > Alex Kiernan
--
Alex Kiernan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] block: Add SPL_BLOCK_CACHE and default n
On Fri, Jun 8, 2018 at 9:48 PM Adam Ford wrote:
>
> When enabling BLOCK_CACHE on devices with limited RAM during SPL,
> some devices may not boot. This creates an option to enable
> block caching in SPL by defaults off. It is dependant on BLOCK_CACHE
> and SPL_BLK
>
> Fixes: 46960ad6d09b ("block: Have BLOCK_CACHE default to y in some cases")
>
> Signed-off-by: Adam Ford
>
> diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
> index 0792373cfc..8ef363b3d4 100644
> --- a/drivers/block/Kconfig
> +++ b/drivers/block/Kconfig
> @@ -37,6 +37,13 @@ config BLOCK_CACHE
> it will prevent repeated reads from directory structures and other
> filesystem data structures.
>
> +config SPL_BLOCK_CACHE
> + bool "Use block device cache in SPL"
> + depends on BLOCK_CACHE && SPL_BLK
> + default n
> + help
> + This option enables the disk-block cache in SPL
> +
> config IDE
> bool "Support IDE controllers"
> select HAVE_BLOCK_DEVICE
> diff --git a/drivers/block/Makefile b/drivers/block/Makefile
> index 5fcafb193e..a9af28a552 100644
> --- a/drivers/block/Makefile
> +++ b/drivers/block/Makefile
> @@ -11,4 +11,9 @@ endif
>
> obj-$(CONFIG_IDE) += ide.o
> obj-$(CONFIG_SANDBOX) += sandbox.o
> +ifdef CONFIG_SPL_BUILD
> +obj-$(SPL_BLOCK_CACHE) += blkcache.o
CONFIG_SPL_BLOCK_CACHE?
> +endif
> +ifndef CONFIG_SPL_BUILD
> obj-$(CONFIG_BLOCK_CACHE) += blkcache.o
> +endif
Could this all get replaced by:
obj-$(CONFIG_$(SPL_)BLOCK_CACHE) += blkcache.o
> diff --git a/include/blk.h b/include/blk.h
> index fc0c239e46..c17c5eb047 100644
> --- a/include/blk.h
> +++ b/include/blk.h
> @@ -111,7 +111,8 @@ struct blk_desc {
> #define PAD_TO_BLOCKSIZE(size, blk_desc) \
> (PAD_SIZE(size, blk_desc->blksz))
>
> -#ifdef CONFIG_BLOCK_CACHE
> +#if (defined(CONFIG_BLOCK_CACHE) && !defined(CONFIG_SPL_BUILD)) || \
> +(defined(CONFIG_SPL_BLOCK_CACHE) && defined(CONFIG_SPL_BUILD))
> /**
Replace with CONFIG_IS_ENABLED?
> * blkcache_read() - attempt to read a set of blocks from cache
> *
> --
> 2.17.1
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
--
Alex Kiernan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
