On Wed, May 2, 2018 at 6:51 AM Jocelyn Bohr <b...@verily.com> wrote:
> On Tue, May 1, 2018 at 10:46 PM Jocelyn Bohr <b...@google.com> wrote: >> On Tue, May 1, 2018 at 1:21 AM Alex Kiernan <alex.kier...@gmail.com> wrote: >>> On Tue, May 1, 2018 at 8:22 AM Alex Kiernan <alex.kier...@gmail.com> wrote: >>> > On Tue, May 1, 2018 at 7:50 AM Jocelyn Bohr <b...@google.com> wrote: >>> > > On Mon, Apr 30, 2018 at 1:33 AM Alex Kiernan <alex.kier...@gmail.com >>> > wrote: ... >>> > >> diff --git a/drivers/fastboot/fb_common.c >>> b/drivers/fastboot/fb_common.c >>> > >> index 8b3627b..36ef669 100644 >>> > >> --- a/drivers/fastboot/fb_common.c >>> > >> +++ b/drivers/fastboot/fb_common.c >>> > >> @@ -102,3 +102,8 @@ int fastboot_lookup_command(const char *cmd_string) >>> > >> return -1; >>> > >> } >>> > >> + >>> > >> +int __weak fb_set_reboot_flag(void) >>> > >> +{ >>> > >> + return -1; >>> > >> +} >>> > > Instead could this write the string "reboot-bootloader" to >>> > CONFIG_FASTBOOT_BUF_ADDR? >>> > I guess the thing you lose is you don't then get a default "I don't know >>> > how to do that" response. Am I right in thinking you're only using this >>> > behaviour on Raspberry Pi, or is it broader? >>> Thinking about this some more... if we moved that string write into the >>> default fb_set_reboot_flag implementation and then guarded the >>> reboot-bootloader command with a new Kconfig symbol, you could get the "I >>> don't know how to do that" behaviour by disabling the command? >> The "reboot-bootloader" behavior isn't RPi specific, it's part of the fastboot >> protocol and is required by all Android bootloaders that support fastboot. >> https://android.googlesource.com/platform/system/core/+/master/fastboot/ >> So my thinking was that since it's part of the protocol, the weak function could >> have some default implementation. I can't think of a reason for a device to >> support fastboot but not the "reboot-bootloader" command. > I think I'm also fine with adding a default implementation later, when > common/android-bootloader.c from AOSP gets merged. That would probably make > more sense, because currently nothing in the upstream code reads the > "reboot-bootloader" flag. But I prefer to not add a new Kconfig to guard the > reboot-bootloader command. Thanks, I'll leave it like it is... Whenever code to honour it gets added, the various other mechanisms that already exist for fb_set_reboot_flag() want looking at too as there's a mix of approaches today (my least favourite of which is arch/arm/mach-omap2/boot-common.c... which the board I'm interested in ends up using). -- Alex Kiernan _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot