env: Rename getenv/_f() to env_get()

We are now using an env_ prefix for environment functions. Rename these
two functions for consistency. Also add function comments in common.h.

Quite a few place

env: Rename getenv/_f() to env_get()

We are now using an env_ prefix for environment functions. Rename these
two functions for consistency. Also add function comments in common.h.

Quite a few places use getenv() in a condition context, provoking a
warning from checkpatch. These are fixed up in this patch also.

Suggested-by: Wolfgang Denk <wd@denx.de>
Signed-off-by: Simon Glass <sjg@chromium.org>

show more ...

env: Rename setenv() to env_set()

We are now using an env_ prefix for environment functions. Rename setenv()
for consistency. Also add function comments in common.h.

Suggested-by: Wolfgang Denk <wd

env: Rename setenv() to env_set()

We are now using an env_ prefix for environment functions. Rename setenv()
for consistency. Also add function comments in common.h.

Suggested-by: Wolfgang Denk <wd@denx.de>
Signed-off-by: Simon Glass <sjg@chromium.org>

show more ...

arm: Add explicit include of <asm/mach-types.h>

Rather than relying on common.h to provide this include, which is going
away at some point, include it explicitly in each file.

Signed-off-by: Simon

arm: Add explicit include of <asm/mach-types.h>

Rather than relying on common.h to provide this include, which is going
away at some point, include it explicitly in each file.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

show more ...

ti: boot: Register the MMC controllers in SPL in the same way as in u-boot

To keep a consistent MMC device mapping in SPL and in u-boot, let's
register the MMC controllers the same way in u-boot and

ti: boot: Register the MMC controllers in SPL in the same way as in u-boot

To keep a consistent MMC device mapping in SPL and in u-boot, let's
register the MMC controllers the same way in u-boot and in the SPL.
In terms of boot time, it doesn't hurt to register more controllers than
needed because the MMC device is initialized only prior being accessed for
the first time.
Having the same device mapping in SPL and u-boot allows us to use the
environment in SPL whatever the MMC boot device.

Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

show more ...

kc1: Proper reboot mode and boot reason validation

With the previous implementation, rebooting without registering a recognized
reboot mode would end up with U-Boot checking for a valid power-on rea

kc1: Proper reboot mode and boot reason validation

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@paulk.fr>

show more ...

kc1: Clear reboot mode garbage on cold reset

Reboot mode garbage is found on cold reset and might be seen as valid on the
next warm reset, thus it has to be cleared on cold reset.

Signed-off-by: Pa

kc1: Clear reboot mode garbage on cold reset

Reboot mode garbage is found on cold reset and might be seen as valid on the
next warm reset, thus it has to be cleared on cold reset.

Signed-off-by: Paul Kocialkowski <contact@paulk.fr>

show more ...

kc1: Power off when the power on reason is not a valid one

Some power on reasons are not desirable (e.g. too short press on the power
button), battery plug. Thus, power off the device when one of th

kc1: Power off when the power on reason is not a valid one

Some power on reasons are not desirable (e.g. too short press on the power
button), battery plug. Thus, power off the device when one of those occurs.

Signed-off-by: Paul Kocialkowski <contact@paulk.fr>

show more ...

kc1: Boot to bootloader (fastboot) on ID pin pull-up

USB ID pin pull-up indicates factory (fastboot) cable detection.

Signed-off-by: Paul Kocialkowski <contact@paulk.fr>

kc1: OMAP4 reboot mode support

This adds support for the omap4 reboot mode mechanism and exports the reboot
mode via an environment variable, that is used in the boot command to make it
possible to

kc1: OMAP4 reboot mode support

This adds support for the omap4 reboot mode mechanism and exports the reboot
mode via an environment variable, that is used in the boot command to make it
possible to boot from the recovery partition or fastboot.

Signed-off-by: Paul Kocialkowski <contact@paulk.fr>

show more ...

kc1: MUSB USB controller and fastboot USB gadget support

This adds support for the MUSB USB dual-role controller in peripheral mode,
with configuration options for the fastboot USB gadget.

At this

kc1: MUSB USB controller and fastboot USB gadget support

This adds support for the MUSB USB dual-role controller in peripheral mode,
with configuration options for the fastboot USB gadget.

At this point, flashing the internal eMMC is support.

Signed-off-by: Paul Kocialkowski <contact@paulk.fr>

show more ...

Amazon Kindle Fire (first generation) codename kc1 support

The Amazon Kindle Fire (first generation) codename kc1 is a tablet that was
released by Amazon back in 2011.

It is using an OMAP4430 SoC G

Amazon Kindle Fire (first generation) codename kc1 support

The Amazon Kindle Fire (first generation) codename kc1 is a tablet that was
released by Amazon back in 2011.

It is using an OMAP4430 SoC GP version, which allows running U-Boot and the
U-Boot SPL from the ground up.

Signed-off-by: Paul Kocialkowski <contact@paulk.fr>

show more ...