u-boot.git/include/environment/ti/boot.h, branch master

arm: ti: environment: Move in to

2021-07-15T12:26:04+00:00

This include file is only used by ti_omap5_common.h.  Further, the move
is towards using the generic distro boot framework and not this set of
macros.  Start by moving all of the contents in directly to where they
are used.

Signed-off-by: Tom Rini 
Signed-off-by: Lokesh Vutla 
Link: https://lore.kernel.org/r/20210701132612.7559-2-trini@konsulko.com

common: Drop linux/stringify.h from common header

2020-05-19T01:19:23+00:00

Move this uncommon header out of the common header.

Signed-off-by: Simon Glass

env: ti: boot: Fix Android boot on AM57x EVM

2020-03-03T07:38:14+00:00

When applying DTBO on top of DTB (with "fdt apply" command) on AM57x EVM
board, there is not enough memory reserved in RAM for DTB blob. Hence,
DTBO can't be merged in DTB. It leads to inability to boot Android with
next error message:

    failed on fdt_overlay_apply(): FDT_ERR_NOSPACE

To overcome that issue let's provide 512 KiB of space to keep DTB and
all merged DTBO blobs. To do so, "length" parameter should be specified
for "fdt addr" command:

    => fdt addr $fdtaddr 0x80000

512 KiB is the maximum size we can use for this, because next address
after $fdtaddr is 512 KiB ahead of it:

    fdtaddr=0x88000000
    rdaddr=0x88080000

Also add size variables to 'adtimg' command invocations, to avoid
cluttering the console with DTBO blob sizes.

Signed-off-by: Sam Protsenko 
Reviewed-by: Eugeniu Rosca

arm: ti: boot: Use correct dtb and dtbo on Android boot

2020-02-04T03:37:24+00:00

Read correct dtb blob from boot.img/recovery.img and apply correct dtbo
blobs from dtbo partition.

Signed-off-by: Sam Protsenko 
Signed-off-by: Lokesh Vutla

env: ti: boot: Boot Android with dynamic partitions

2020-02-04T03:37:24+00:00

Changes:
  - use boot.img instead of boot_fit.img
  - use .dtb from boot.img v2
  - implement recovery boot
  - always boot ramdisk from boot.img, we can't mount system as root
    now, as system is a logical partition inside of super partition
  - don't add "skip_initramfs" to cmdline anymore
  - to boot into recovery, use boot image from recovery partition
  - prepare partition table:
    - A/B scheme
    - use 'super' partition instead of 'system' and 'vendor'
    - add dtbo partitions
    - introduce metadata partition

Not implemented: reading and applying dtbo blobs from dtbo partition.

Signed-off-by: Sam Protsenko 
Signed-off-by: Lokesh Vutla

env: ti: boot: Respect slot_suffix in AVB commands

2020-02-04T03:37:24+00:00

Signed-off-by: Sam Protsenko 
Signed-off-by: Lokesh Vutla

board: ti: beagleboneai: enable in am57xx_evm_defconfig

2020-01-20T04:40:28+00:00

Adding the configurations to the evm_defconfig file

Signed-off-by: Jason Kridner 
Signed-off-by: Caleb Robey 
Signed-off-by: Lokesh Vutla

env: ti: boot: Handle reboot reason from BCB

2019-07-31T17:08:07+00:00

In case of Android boot, reboot reason can be written into BCB (usually
it's an area in 'misc' partition). U-Boot then can obtain that reboot
reason from BCB and handle it accordingly to achieve correct Android
boot flow, like it was suggested in [1]:
  - if it's empty: perform normal Android boot from eMMC
  - if it contains "bootonce-bootloader": get into fastboot mode
  - if it contains "boot-recovery": perform recovery boot

The latter is not implemented yet, as it depends on some features that
are not implemented on TI platforms yet (in AOSP and in U-Boot).

[1] https://marc.info/?l=u-boot&m=152508418909737&w=2

Signed-off-by: Sam Protsenko

env: ti: boot: Use ttyS2 instead of ttyO2

2019-07-27T17:36:54+00:00

ttyO2 console enables legacy CONFIG_SERIAL_OMAP driver in kernel.
Nowadays it's preferred to use the generic CONFIG_SERIAL_8250_OMAP
driver, which being enabled via ttyS2 console. Both drivers are enabled
in multi_v7_defconfig and in omap2plus_defconfig, for compatibility
reasons. Let's switch to ttyS2 console, to be sure that standard 8250
serial driver is used.

Similar behavior can be also achieved by enabling
CONFIG_SERIAL_8250_OMAP_TTYO_FIXUP option in kernel, but it's better not
to rely on that, as it can be disabled or removed after transitional
period.

Right now on DRA7/AM57x platforms the 8250-omap driver is being probed
first, and omap-serial driver is only probed if the first one failed.
It can be seen from uart3 definition in arch/arm/boot/dts/dra7-l4.dtsi:

    compatible = "ti,dra742-uart", "ti,omap4-uart";

So the kernel already uses 8250 driver. This change basically allows
kernel developers to throw away the omap-serial driver and associated
compatibility options. Similar discussions [1,2] have started several
years ago, so it should be safe to do that now.

[1] https://patchwork.kernel.org/patch/6198471/
[2] http://processors.wiki.ti.com/index.php/Sitara_Linux_UART_-_Switching_to_8250_Driver

Signed-off-by: Sam Protsenko 
Reviewed-by: Andrew F. Davis 
[trini: Update omap5_uevm]
Signed-off-by: Tom Rini

env: am57xx: Implement A/B boot process

2019-07-24T17:20:27+00:00

Add support for A/B boot process on AM57xx based boards:

  1. Define 'slot_suffix' variable (using 'ab_select' command)
  2. Extend 'emmc_android_boot' boot command (add commands for A/B boot
     process)

'ab_select' command is used to decide which slot should be used for
booting up. A/B metadata resides in 'misc' partition.

To activate the A/B boot process, the following config options must be
set:

    CONFIG_ANDROID_AB=y
    CONFIG_CMD_AB_SELECT=y

For successful A/B boot, the corresponding A/B infrastructure must be
involved on Android side [1] (including mounting system as root), and
disk must be partitioned accordingly.

When A/B boot is enabled, there are some known limitations currently
exist (not related to A/B patches, need to be implemented later):

  1. The 'Verified Boot' sequence is not supported
  2. dev path to system partition (system_a or system_b) is passed via
     'bootargs' as 'root=' argument like 'root=/dev/mmcblk1p12', but
     further we'll need to rework it with respect to dm-verity
     requirements [2]

In case when A/B partitions are not present in system (and A/B boot is
enabled), boot up process will be terminated and next message will be
shown:

    "boot_a(b) partition not found"

[1] https://source.android.com/devices/tech/ota/ab
[2] https://source.android.com/devices/tech/ota/ab/ab_implement#kernel

Signed-off-by: Ruslan Trofymenko 
Signed-off-by: Igor Opaniuk 
Signed-off-by: Sam Protsenko 
Reviewed-by: Alistair Strachan 
Reviewed-by: Sam Protsenko 
Reviewed-by: Simon Glass