summaryrefslogtreecommitdiff
path: root/arch/arm/mach-tegra/tegra186/nvtboot_ll.S
AgeCommit message (Collapse)Author
2016-11-07ARM: tegra: ensure nvtboot_boot_x0 alignmentStephen Warren
nvtboot_boot_x0 is a 64-bit variable and hence must be 64-bit aligned. So far this has happened by accident! Fix the code so this is guaranteed. This fixes the following build error: ... relocation truncated to fit: R_AARCH64_LDST64_ABS_LO12_NC against symbol `nvtboot_boot_x0' ... Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
2016-07-21ARM: tegra: pick up actual memory sizeStephen Warren
On Tegra186, U-Boot is booted by the binary firmware as if it were a Linux kernel. Consequently, a DTB is passed to U-Boot. Cache the address of that DTB, and parse the /memory/reg property to determine the actual RAM regions that U-Boot and subsequent EL2/EL1 SW may actually use. Given the binary FW passes a DTB to U-Boot, I anticipate the suggestion that U-Boot use that DTB as its control DTB. I don't believe that would work well, so I do not plan to put any effort into this. By default the FW-supplied DTB is the L4T kernel's DTB, which uses non-upstreamed DT bindings. U-Boot aims to use only upstreamed DT bindings, or as close as it can get. Replacing this DTB with a DTB using upstream bindings is physically quite easy; simply replace the content of one of the GPT partitions on the eMMC. However, the binary FW at least partially relies on the existence/content of some nodes in the DTB, and that requires the DTB to be written according to downstream bindings. Equally, if U-Boot continues to use appended DTBs built from its own source tree, as it does for all other Tegra platforms, development and deployment is much easier. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>