[U-Boot] [PATCH 6/7] kc1: Proper reboot mode and boot reason validation

[Tom Rini]

On Tue, Mar 29, 2016 at 02:14:34PM +0200, Paul Kocialkowski wrote:
> Le lundi 28 mars 2016 à 10:06 -0400, Tom Rini a écrit :
> > On Mon, Mar 28, 2016 at 02:07:13PM +0200, Paul Kocialkowski wrote:
> > > With the previous implementation, rebooting without registering a recognized
> > > reboot mode would end up with U-Boot checking for a valid power-on reason,
> > > which
> > > might result in the device turning off (e.g. with no USB cable attached and
> > > no
> > > buttons pressed).
> > > 
> > > Since this approach is not viable (breaks reboot in most cases), the
> > > validity of
> > > the reboot reason is checked (in turn, by checking that a warm reset
> > > happened,
> > > as there is no magic) to detect a reboot and the 'o' char is recognized to
> > > indicate that power-off is required. Still, that might be overridden by the
> > > detection of usual power-on reasons, on purpose.
> > > 
> > > Signed-off-by: Paul Kocialkowski <contact at paulk.fr>
> > Reviewed-by: Tom Rini <trini at konsulko.com>
> > 
> > ... but since Sniper and KC1 are doing the same thing, and other OMAP
> > devices that are also Android devices will also be in the same camp, can
> > we perhaps include some of the above information in a comment, make
> > android_omap_reboot_mode (or something along those lines) in
> > arch/arm/cpu/armv7/omap-common/something-appropriate.c ?
> 
> The way things are done now, a few distinct aspects are tied together in my
> approach:
> * reboot mode storage, which is Android-specific and also involves the boot
> command
> * valid power-on reason checking, which relies on twl code, that I'm not
> comfortable making part of the omap arch code
> * device-specific reboot mode setting (overriding omap reboot mode), e.g. from
> buttons
> 
> So I think we could go with the following:
> * Making the twl code common on each twl power driver
> * Making the Android aspects common through functions dealing with the reboot-
> mode env variable and associated boot command, with their own Kconfig option
> * Keeping the global coordination between these in each board file, to handle
> device-specific input and quirks
> 
> I'd rather make a clean new series to support that.
> 
> What do you think?

Since mutt is telling me I forgot to reply, sorry, yes, a follow-up
sounds good, thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160408/19564e52/attachment.sig>