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

[Paul Kocialkowski]

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?

-- 
Paul Kocialkowski, low-level free software developer on embedded devices

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160329/9e443309/attachment.sig>