u-boot.git/include/environment, branch v2020.01-rc3 Unnamed repository; edit this file 'description' to name the repository. env: ti: Add environment variables to boot from UFS 2019-10-24T00:47:12+00:00 Faiz Abbas faiz_abbas@ti.com 2019-10-15T12:54:41+00:00 13b6770c0513eb80596c862b0c513101b5449934 Add environment variables to boot kernel from a filesystem contained in the 2nd UFS LUN. The user can boot from a ufs filesystem just by entering the following commands. => setenv boot ufs => boot Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> 
Add environment variables to boot kernel from a filesystem contained in
the 2nd UFS LUN. The user can boot from a ufs filesystem just by
entering the following commands.

=> setenv boot ufs
=> boot

Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
env: ti: k3_rproc: Add common rproc environment variables 2019-10-11T14:07:35+00:00 Suman Anna s-anna@ti.com 2019-09-04T10:31:42+00:00 bb17aaf658b4bb28677e346053a684447e3ddeb2 Add a new file include/environment/ti/k3_rproc.h that defines common environment variables useful for booting various remote processors from U-Boot. This file is expected to be included in the board config files with the EXTRA_ENV_RPROC_SETTINGS added to CONFIG_EXTRA_ENV_SETTINGS and DEFAULT_RPROCS macro overwritten to include the actual list of processors to be booted. The 'boot_rprocs' variable just needs to be added to the board's bootcmd to automatically boot the processors, and runtime control can be achieved through the 'dorprocboot' variable. The variables are currently defined to use MMC as the boot media, and can be expanded in the future to include other boot media. The immediate usage is intended for K3 J721E SoCs. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Signed-off-by: Suman Anna <s-anna@ti.com> 
Add a new file include/environment/ti/k3_rproc.h that defines
common environment variables useful for booting various remote
processors from U-Boot. This file is expected to be included in
the board config files with the EXTRA_ENV_RPROC_SETTINGS added
to CONFIG_EXTRA_ENV_SETTINGS and DEFAULT_RPROCS macro overwritten
to include the actual list of processors to be booted.

The 'boot_rprocs' variable just needs to be added to the board's
bootcmd to automatically boot the processors, and runtime control
can be achieved through the 'dorprocboot' variable.

The variables are currently defined to use MMC as the boot media,
and can be expanded in the future to include other boot media.
The immediate usage is intended for K3 J721E SoCs.

Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
arm: ti: Add missing "=" from previous fix 2019-09-09T14:55:45+00:00 Tom Rini trini@konsulko.com 2019-09-09T14:55:45+00:00 c705fc3b40b88bfbf465448643c91da71426df2f While the original patch to fix a regression in distro boot for mmc on these platforms had the correct syntax, I broke the change while applying. Add back in the missing "=" here so that the syntax is correct. Reported-by: Andre Heider <a.heider@gmail.com> Fixes: 27e0f3bcf075 ("arm: ti: Fix regression in distro boot for mmc") Signed-off-by: Tom Rini <trini@konsulko.com> 
While the original patch to fix a regression in distro boot for mmc on
these platforms had the correct syntax, I broke the change while
applying.  Add back in the missing "=" here so that the syntax is
correct.

Reported-by: Andre Heider <a.heider@gmail.com>
Fixes: 27e0f3bcf075 ("arm: ti: Fix regression in distro boot for mmc")
Signed-off-by: Tom Rini <trini@konsulko.com>
arm: ti: Fix regression in distro boot for mmc 2019-08-26T15:43:53+00:00 Nuno Gonçalves nunojpg@gmail.com 2019-07-10T11:46:57+00:00 27e0f3bcf07530a9cd272953797efda54ebb8f5e When devnum was changed to a local variable in distro_bootcmd we ran into a problem on TI platforms (confirmed on Beaglebone) as we had been using 'setenv devnum' there as well and it needs to match the other usage. Fixes: 13dd6665ed18 ("distro: not taint environment variables if possible") [trini: Review other platforms, re-word commit message] Signed-off-by: Tom Rini <trini@konsulko.com> 
When devnum was changed to a local variable in distro_bootcmd we ran
into a problem on TI platforms (confirmed on Beaglebone) as we had been
using 'setenv devnum' there as well and it needs to match the other
usage.

Fixes: 13dd6665ed18 ("distro: not taint environment variables if possible")
[trini: Review other platforms, re-word commit message]
Signed-off-by: Tom Rini <trini@konsulko.com>
env: ti: boot: Handle reboot reason from BCB 2019-07-31T17:08:07+00:00 Sam Protsenko semen.protsenko@linaro.org 2019-07-25T13:20:41+00:00 3db0989e68ee23db9d5ae970304890100b4fb9bb 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 <semen.protsenko@linaro.org> 
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 <semen.protsenko@linaro.org>
env: ti: boot: Use ttyS2 instead of ttyO2 2019-07-27T17:36:54+00:00 Sam Protsenko semen.protsenko@linaro.org 2019-07-12T17:38:12+00:00 adc097e13320f1016526f0fab75321ad7bab9521 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 <semen.protsenko@linaro.org> Reviewed-by: Andrew F. Davis <afd@ti.com> [trini: Update omap5_uevm] Signed-off-by: Tom Rini <trini@konsulko.com> 
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 <semen.protsenko@linaro.org>
Reviewed-by: Andrew F. Davis <afd@ti.com>
[trini: Update omap5_uevm]
Signed-off-by: Tom Rini <trini@konsulko.com>
env: am57xx: Implement A/B boot process 2019-07-24T17:20:27+00:00 Ruslan Trofymenko ruslan.trofymenko@linaro.org 2019-07-05T12:37:36+00:00 edd31084f2560008b7aed6c9654b014a90ebd33e 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 <ruslan.trofymenko@linaro.org> Signed-off-by: Igor Opaniuk <igor.opaniuk@gmail.com> Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Reviewed-by: Alistair Strachan <astrachan@google.com> Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org> 
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 <ruslan.trofymenko@linaro.org>
Signed-off-by: Igor Opaniuk <igor.opaniuk@gmail.com>
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Alistair Strachan <astrachan@google.com>
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
configs: ti_omap5_common: Add NAND environment settings 2019-04-12T12:05:50+00:00 Faiz Abbas faiz_abbas@ti.com 2019-02-27T07:59:38+00:00 097fd51b7ab2b179719f13cc9cca77043c45bb4c Now that NAND is supported on DRA71x include various NAND environment settings Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> 
Now that NAND is supported on DRA71x include various NAND environment
settings

Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
arm: ti: boot: Remove legacy Android partitions 2019-01-09T12:13:32+00:00 Sam Protsenko semen.protsenko@linaro.org 2019-01-04T20:09:08+00:00 35e3d2e8a30321195e4f5cd8aafba6aefe818b3d Remove unused Android partitions: - efs, crypto, cache: we don't use it anymore (images are not built in AOSP - ipu1, ipu2: IPU firmware is now a part of vendor image and doesn't reside as a separate partition While at it, rename "reserved" partition to "uboot-env", as it's actually stores U-Boot environment. Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Signed-off-by: Praneeth Bajjuri <praneeth@ti.com> 
Remove unused Android partitions:
  - efs, crypto, cache: we don't use it anymore (images are not built
    in AOSP
  - ipu1, ipu2: IPU firmware is now a part of vendor image and doesn't
    reside as a separate partition

While at it, rename "reserved" partition to "uboot-env", as it's
actually stores U-Boot environment.

Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
arm: ti: boot: Increase system partition size 2018-12-17T13:42:19+00:00 Sam Protsenko semen.protsenko@linaro.org 2018-12-11T16:20:21+00:00 528920f94ef22f9e5cf183cc193246e01280c65e Android code base is growing, so since Android "Pie" the size of system.img grew up to be about 740 MiB. Let's increase system.img to 1 GiB to accommodate for those changes and leave some margin for future changes. We don't want to make it more than 1 GiB, because we should keep userdata partition big enough (for user files, like media etc.), and eMMC size on BeagleBoard-X15 is only 3.5 GiB. Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Acked-by: Praneeth Bajjuri <praneeth@ti.com> 
Android code base is growing, so since Android "Pie" the size of
system.img grew up to be about 740 MiB. Let's increase system.img to
1 GiB to accommodate for those changes and leave some margin for future
changes. We don't want to make it more than 1 GiB, because we should
keep userdata partition big enough (for user files, like media etc.),
and eMMC size on BeagleBoard-X15 is only 3.5 GiB.

Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Acked-by: Praneeth Bajjuri <praneeth@ti.com>