u-boot.git/arch/arm/include/asm/global_data.h, branch v2016.09

armv8: Add tlb_allocated to arch global data

2016-07-15T16:01:43+00:00

When secure ram is used, MMU tables have to be put into secure ram.
To use common MMU code, gd->arch.tlb_addr will be used to host TLB
entry pointer. To save allocated memory for later use, tlb_allocated
variable is added to global data structure.

Signed-off-by: York Sun

armv8: Move secure_ram variable out of generic global data

2016-07-15T16:01:43+00:00

Secure_ram variable was put in generic global data. But only ARMv8
uses this variable. Move it to ARM specific data structure.

Signed-off-by: York Sun

arm64: Remove non-full-va map code

2016-03-15T19:13:10+00:00

By now the code to only have a single page table level with 64k page
size and 42 bit address space is no longer used by any board in tree,
so we can safely remove it.

To clean up code, move the layerscape mmu code to the new defines,
removing redundant field definitions.

Signed-off-by: Alexander Graf

arm64: Make full va map code more dynamic

2016-03-15T19:13:01+00:00

The idea to generate our pages tables from an array of memory ranges
is very sound. However, instead of hard coding the code to create up
to 2 levels of 64k granule page tables, we really should just create
normal 4k page tables that allow us to set caching attributes on 2M
or 4k level later on.

So this patch moves the full_va mapping code to 4k page size and
makes it fully flexible to dynamically create as many levels as
necessary for a map (including dynamic 1G/2M pages). It also adds
support to dynamically split a large map into smaller ones when
some code wants to set dcache attributes.

With all this in place, there is very little reason to create your
own page tables in board specific files.

Signed-off-by: Alexander Graf

armv8: New MMU setup code allowing to use 48+ bits PA/VA

2016-01-19T22:25:36+00:00

This patch adds code which sets up 2-level page tables on ARM64 thus
extending available VA space. CPUs implementing 64k translation
granule are able to use direct PA-VA mapping of the whole 48 bit
address space.
It also adds the ability to reset the SCTRL register at the very beginning
of execution to avoid interference from stale mappings set up by early
firmware/loaders/etc.

Signed-off-by: Sergey Temerkhanov 
Signed-off-by: Radha Mohan Chintakuntla

armv8: LS2080A: Rename LS2085A to reflect LS2080A

2015-11-30T16:53:04+00:00

LS2080A is a prime personality of Freescale’s LS2085A. It is a non-AIOP
personality without support of DP-DDR, L2 switch, 1588, PCIe endpoint etc.
So renaming existing LS2085A code base to reflect LS2080A (Prime personality)

Signed-off-by: Pratiyush Mohan Srivastava 
Signed-off-by: Prabhakar Kushwaha 
[York Sun: Dropped #ifdef in cpu.c for cpu_type_list]
Reviewed-by: York Sun

omap-common: Common boot code OMAP3 support and cleanup

2015-07-27T19:02:03+00:00

This introduces OMAP3 support for the common omap boot code, as well as a
major cleanup of the common omap boot code.

First, the omap_boot_parameters structure becomes platform-specific, since its
definition differs a bit across omap platforms. The offsets are removed as well
since it is U-Boot's coding style to use structures for mapping such kind of
data (in the sense that it is similar to registers). It is correct to assume
that romcode structure encoding is the same as U-Boot, given the description
of these structures in the TRMs.

The original address provided by the bootrom is passed to the U-Boot binary
instead of a duplicate of the structure stored in global data. This allows to
have only the relevant (boot device and mode) information stored in global data.
It is also expected that the address where the bootrom stores that information
is not overridden by the U-Boot SPL or U-Boot.

The save_omap_boot_params is expected to handle all special cases where the data
provided by the bootrom cannot be used as-is, so that spl_boot_device and
spl_boot_mode only return the data from global data.

All of this is only relevant when the U-Boot SPL is used. In cases it is not,
save_boot_params should fallback to its weak (or board-specific) definition.
save_omap_boot_params should not be called in that context either.

Signed-off-by: Paul Kocialkowski

armv8/fsl-lsch3: Add support for second DDR clock

2015-02-24T21:09:14+00:00

FSL-LSCH3 platforms can have multiple DDR clocks. LS2085A has one clock for
general DDR controlers, and another clock for DP-DDR. DDR driver needs to
change to support multiple clocks.

Signed-off-by: York Sun

qe: add u-qe support to arm board

2014-11-19T20:55:45+00:00

ls1021 is arm-core and support qe which is u-qe.
add u-qe init for arm board.

Signed-off-by: Zhao Qiang 
[York Sun: Fix compiling error caused by u_qe_init()]
Reviewed-by: York Sun

ARM: make gd a function for clang

2014-09-09T11:51:08+00:00

"clang does not support global register variables; this is
unlikely to be implemented soon because it requires additional
LLVM backend support" [1]

Workaround it by obtaining the value of gd/r9 by an inline
asm routine. Note there is no set routine added for ARM at the
moment, since most if not all updates of gd from c are actually
not needed for ARM.

[1] http://clang.llvm.org/docs/UsersManual.html

cc: Albert ARIBAUD 
Signed-off-by: Jeroen Hofstee