~tobetter/+git/u-boot:odroid-v2020.01

Last commit made on 2020-03-28
Get this branch:
git clone -b odroid-v2020.01 https://git.launchpad.net/~tobetter/+git/u-boot

Branch merges

Branch information

Name:
odroid-v2020.01
Repository:
lp:~tobetter/+git/u-boot

Recent commits

d23ab4f... by Dongjin Kim

ODROID-XU3: add 'CONFIG_OF_LIBFDT_OVERLAY' and 'CONFIG_CMD_INI'

Change-Id: I09c9031be4c5257c415f54575e23a6dade179abb
Signed-off-by: Dongjin Kim <email address hidden>

589067c... by Dongjin Kim

ODROID: echoing with '>' instead of '| tee' since tee is missing

Signed-off-by: Dongjin Kim <email address hidden>

77294e9... by Dongjin Kim

ODROID: use 'conv=fsync' with 'dd' command

Signed-off-by: Dongjin Kim <email address hidden>

12f39e9... by Dongjin Kim

ODROID: fix to build only for ODROID

Change-Id: I652337824d250d0dd04a92ee0b1d22abdfad2d08
Signed-off-by: Dongjin Kim <email address hidden>

2a421a4... by Dongjin Kim

ODROID: fix boot order by boot select switch

Signed-off-by: Dongjin Kim <email address hidden>

60b5043... by Dongjin Kim

ODROID: fix up reading board revision by ADC

Signed-off-by: Dongjin Kim <email address hidden>

0b0c6af... by Tom Rini <email address hidden>

Prepare v2020.01

Signed-off-by: Tom Rini <email address hidden>

797eee3... by Tom Rini <email address hidden>

Revert "mmc: davinci: drop struct davinci_mmc_plat"

Adam Ford reports that this change breaks booting on da850-evm and
Bartosz Golaszewski agrees that with the impending release we should
revert the change for now. With that noted:

This reverts commit 21a4d80a710c79053ac1deaa65ff9b69e6c031d4.

Cc: Bartosz Golaszewski <email address hidden>
Tested-by: Adam Ford <email address hidden>
Signed-off-by: Tom Rini <email address hidden>

70bd39d... by Tom Rini <email address hidden>

Merge branch '2020-01-03-master-imports'

- Fixes for host tools with musl C library
- Two fixes for TI K3 platforms

40109f4... by Lokesh Vutla <email address hidden>

arm: mach-k3: Enable WA for R5F deadlock

On K3 devices there are 2 conditions where R5F can deadlock:
1.When software is performing series of store operations to
  cacheable write back/write allocate memory region and later
  on software execute barrier operation (DSB or DMB). R5F may
  hang at the barrier instruction.
2.When software is performing a mix of load and store operations
  within a tight loop and store operations are all writing to
  cacheable write back/write allocates memory regions, R5F may
  hang at one of the load instruction.

To avoid the above two conditions disable linefill optimization
inside Cortex R5F which will make R5F to only issue up to 2 cache
line fills at any point of time.

Signed-off-by: Lokesh Vutla <email address hidden>