u-boot.git/arch, branch v2018.05-rc2

bios: vesa: Guard setting vesa mode with CONFIG_FRAMEBUFFER_SET_VESA_MODE

2018-04-16T14:38:35+00:00

If CONFIG_FRAMEBUFFER_SET_VESA_MODE is not set, don't switch
graphics card to VESA mode. This applies to both native mode
and emulator mode of running the VGA BIOS.

Signed-off-by: Bin Meng 
Reviewed-by: Simon Glass

x86: Rename e820entry to e820_entry

2018-04-16T08:54:51+00:00

This changes 'struct e820entry' to 'struct e820_entry' to conform
with the coding style.

Signed-off-by: Bin Meng 
Reviewed-by: Christian Gmeiner

x86: Use 'unsigned int' in install_e820_map() functions

2018-04-16T08:54:51+00:00

This fixes the following checkpatch warning:

  warning: Prefer 'unsigned int' to bare use of 'unsigned'

Signed-off-by: Bin Meng 
Reviewed-by: Christian Gmeiner

x86: Update the io.h file to use {out|in}_{be|le}X macros

2018-04-16T08:54:51+00:00

The commit 3f70a6f57734 ("x86: Add clr/setbits functions")
introduced the {read|write}_ macros to manipulate data.

Those macros are not used by any code in the u-boot project (despite the
io.h itself). Other architectures use io.h with {in|out}_* macros.

This commit brings some unification across u-boot supported architectures.

Signed-off-by: Lukasz Majewski 
Reviewed-by: Bin Meng

x86: Add 64-bit memory-mapped I/O functions

2018-04-16T08:54:51+00:00

Add readq() and writeq() definitions for x86.

Please note: in 32-bit code readq/writeq will generate two 32-bit
memory access instructions instead of one atomic 64-bit operation.

Signed-off-by: Ivan Gorinov 
Reviewed-by: Andy Shevchenko 
Reviewed-by: Bin Meng

Merge git://git.denx.de/u-boot-imx

2018-04-15T12:43:50+00:00

Signed-off-by: Tom Rini

imx: Create distinct pre-processed mkimage config files

2018-04-15T09:55:23+00:00

Each imx image is created by a separate sub-make and during this process
the mkimage config file is run though cpp.

The cpp output is to the same file no matter what imx image is being
created.

This means if two imx images are generated in parallel they will attempt
to independently produce the same pre-processed mkimage config file at
the same time.

Avoid the problem by making the pre-processed config file name unique
based on the imx image it will be used in.  This way each image will
create a unique config file and they won't clobber each other when run
in parallel.

This should fixed the build bug referenced in b5b0e4e3 ("imximage:
Remove failure when no IVT offset is found").

Cc: Breno Lima 
Cc: Thomas Petazzoni 
Cc: Fabio Estevam 
Signed-off-by: Trent Piepho 
Tested-by: Fabio Estevam

mx31ads: Delete

2018-04-15T09:54:02+00:00

This platform has been marked as orphaned since September 2013, remove.

Signed-off-by: Tom Rini

imx31_phycore: Delete

2018-04-15T09:52:39+00:00

This platform has been marked as orphaned since September 2013, remove.

Signed-off-by: Tom Rini

imx: mx7: snvs: Add an SNVS init routine

2018-04-15T09:48:44+00:00

Working with HAB on the i.MX7 we've encountered a case where a board that
successfully authenticates u-boot when booting Linux via OPTEE subsequently
fails to properly bring up the RTC.

The RTC registers live in the low-power block of the Secure Non-Volatile
Storage (SNVS) block.

The root cause of the error has been traced to the HAB handing off the
SNVS-RTC in a state where HPCOMR::NPSWA_EN = 0 in other words where the
Non-Privileged Software Access Enable bit is zero. In ordinary
circumstances this is OK since we typically do not run in TZ mode, however
when we boot via HAB and enablng TrustZone, it is required to set
HPCOMR::NPSWA_EN = 1 in order for the upstream Linux driver to have
sufficient permissions to manipulate the SNVS-LP block.

On our reference board it is the difference between Linux doing this:

root@imx7s-warp-mbl:~# dmesg | grep rtc
snvs_rtc_enable read 0x00000000 from SNVS_LPLR @ 0x00000034
snvs_rtc_enable read 0x00000021 from SNVS_LPCR @ 0x00000038
snvs_rtc_enable read 0x00000000 from SNVS_HPLR @ 0x00000000
snvs_rtc_enable read 0x80002100 from SNVS_HPCOMR @ 0x00000004
snvs_rtc 30370000.snvs:snvs-rtc-lp: rtc core: registered
         30370000.snvs:snvs-rtc-lp as rtc0
snvs_rtc 30370000.snvs:snvs-rtc-lp: setting system clock to2018-04-01 00:51:04 UTC (1522543864)

and doing this:

root@imx7s-warp-mbl:~# dmesg | grep rtc
snvs_rtc_enable read 0x00000000 from SNVS_LPLR @ 0x00000034
snvs_rtc_enable read 0x00000020 from SNVS_LPCR @ 0x00000038
snvs_rtc_enable read 0x00000001 from SNVS_HPLR @ 0x00000000
snvs_rtc_enable read 0x00002020 from SNVS_HPCOMR @ 0x00000004
snvs_rtc 30370000.snvs:snvs-rtc-lp: failed to enable rtc -110
snvs_rtc: probe of 30370000.snvs:snvs-rtc-lp failed with error -110
hctosys: unable to open rtc device (rtc0)

Note bit 1 of LPCR is not set in the second case and is set in the first
case and that bit 31 of HPCOMR is set in the second case but not in the
first.

Setting NPSWA_EN in HPCOMR allows us to boot through enabling TrustZone
and continue onto the kernel. The kernel then has the necessary permissions
to set LPCR::SRTC_ENV (RTC enable in the LP command register) whereas in
contrast - in the failing case the non-privileged kernel cannot do so.

This patch adds a simple init_snvs() call which sets the permission-bit
called from soc.c for the i.MX7. It may be possible, safe and desirable to
perform this on other i.MX processors but for now this is only tested on
i.MX7 as working.

Signed-off-by: Bryan O'Donoghue