- 22 7月, 2016 9 次提交
-
-
-
由 Tom Rini 提交于
Per Vikas' request, the problem this commit is supposed to be solving is something he doesn't see and further this introduces additional hardware requirements. This reverts commit 4b2fd720. Signed-off-by: NTom Rini <trini@konsulko.com>
-
由 Stephen 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: NStephen Warren <swarren@nvidia.com> Signed-off-by: NTom Warren <twarren@nvidia.com>
-
由 Stephen Warren 提交于
Implement a hook to allow boards to save boot-time CPU state for later use. When U-Boot is chain-loaded by another bootloader, CPU registers may contain useful information such as system configuration information. This feature mirrors the equivalent ARMv7 feature. Signed-off-by: NStephen Warren <swarren@nvidia.com> Reviewed-by: NTom Rini <trini@konsulko.com> Signed-off-by: NTom Warren <twarren@nvidia.com>
-
由 Stephen Warren 提交于
Rev A03 of P2180 requires some PMIC programming adjustments, yet the PMIC's own OTP has not been updated. Consequently, U-Boot must make these changes itself. NVIDIA's syseng team has confirmed that these changes can be enabled on all board revisions without issue. Signed-off-by: NStephen Warren <swarren@nvidia.com> Signed-off-by: NTom Warren <twarren@nvidia.com>
-
由 Stephen Warren 提交于
IVC (Inter-VM Communication) protocol is a Tegra-specific IPC (Inter Processor Communication) framework. Within the context of U-Boot, it is typically used for communication between the main CPU and various auxiliary processors. In particular, it will be used to communicate with the BPMP (Boot and Power Management Processor) on Tegra186 in order to manipulate clocks and reset signals. Signed-off-by: NStephen Warren <swarren@nvidia.com> Signed-off-by: NTom Warren <twarren@nvidia.com>
-
由 Stephen Warren 提交于
Many files in arch/arm/mach-tegra are compiled conditionally based on Kconfig variables, or applicable to all platforms. We can let the main Tegra Makefile handle compiling (or not) those files to avoid each SoC- specific Makefile needing to duplicate entries for those files. This leaves the SoC-specific Makefiles to compile truly SoC-specific code. In the future, we'll hopefully add Kconfig variables for all the other files, and refactor those files, and so reduce the need for SoC-specific Makefiles and/or ifdefs in the Makefiles. Signed-off-by: NStephen Warren <swarren@nvidia.com> Signed-off-by: NTom Warren <twarren@nvidia.com>
-
由 Stephen Warren 提交于
There are multiple versions of p2771-0000 board. There are SW visible incompatible differences between the versions, and they are relevant to U-Boot. Create separate "A02" and "B00" defconfigs (named after the first and/or only board rev the defconfig supports) so that users can select which build they want. With the minimal set of HW currently enabled in U-Boot, the differences are irrelevant, hence the DT files aren't different. However, that will change in a future patch. Signed-off-by: NStephen Warren <swarren@nvidia.com> Signed-off-by: NTom Warren <twarren@nvidia.com>
-
由 Stephen Warren 提交于
Tegra186 uses different GPIO port IDs compared to previous chips. Make sure the SoC DT file includes the correct GPIO binding header. Signed-off-by: NStephen Warren <swarren@nvidia.com> Signed-off-by: NTom Warren <twarren@nvidia.com>
-
- 21 7月, 2016 2 次提交
-
-
由 Masahiro Yamada 提交于
Commit 555f45d8 ("image: Convert the IH_... values to enums") accidentally changed some IH_ARCH_... values. Prior to that commit, there existed a gap between IH_ARCH_M68K and IH_ARCH_MICROBLAZE, like follows. #define IH_ARCH_SPARC64 11 /* Sparc 64 Bit */ #define IH_ARCH_M68K 12 /* M68K */ #define IH_ARCH_MICROBLAZE 14 /* MicroBlaze */ #define IH_ARCH_NIOS2 15 /* Nios-II */ The enum conversion broke the compatibility with existing uImage files. Reverting 555f45d8 will cause build error unfortunately, so here is a more easy fix. I dug the git history and figured out the gap was introduced by commit 1117cbf2 ("nios: remove nios-32 arch"). So, I revived IH_ARCH_NIOS just for filling the gap. I added comments to each enum block. Once we assign a value to IH_... it is not allowed to change it. Acked-by: NMichal Simek <michal.simek@xilinx.com> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
-
- 20 7月, 2016 9 次提交
-
-
由 Daniel Schwierzeck 提交于
flash_full_status_check() checks bit XSR.7 on Intel chips. This should be done by only checking bit 7 and not by comparing the whole status byte or word with 0x80. This fixes the non-working block erase in the pflash emulation of Qemu when used with the MIPS Malta board. MIPS Malta uses x32 mode to access the pflash device. In x32 mode Qemu mirrors the lower 16 bits of the status word into the upper 16 bits. Thus the CFI driver gets a status word of 0x8080 in x32 mode. If flash_full_status_check() uses flash_isequal(), then it polls for XSR.7 by comparing 0x8080 with 0x80 which never becomes true. Reported-by: NAlon Bar-Lev <alon.barlev@gmail.com> Signed-off-by: NDaniel Schwierzeck <daniel.schwierzeck@gmail.com> Signed-off-by: NStefan Roese <sr@denx.de>
-
git://git.denx.de/u-boot-fsl-qoriq由 Tom Rini 提交于
Signed-off-by: NTom Rini <trini@konsulko.com> Conflicts: arch/arm/cpu/armv8/Makefile arch/arm/lib/bootm-fdt.c
-
由 Hou Zhiqiang 提交于
The PPA use PSCI to make secondary cores bootup. So when PPA was enabled, add the CONFIG_ARMV8_PSCI to identify the SMP boot-method between PSCI and spin-table. Signed-off-by: NHou Zhiqiang <Zhiqiang.Hou@nxp.com> Reviewed-by: NYork Sun <york.sun@nxp.com>
-
由 Hou Zhiqiang 提交于
Set the enable-method in the cpu node to PSCI, and create device node for PSCI, when PSCI was enabled. Signed-off-by: NHou Zhiqiang <Zhiqiang.Hou@nxp.com> Reviewed-by: NYork Sun <york.sun@nxp.com>
-
由 Hou Zhiqiang 提交于
If the PSCI and PPA is ready, skip the fixup for spin-table and waking secondary cores. Otherwise, change SMP method to spin-table, and the device node of PSCI will be removed. Signed-off-by: NHou Zhiqiang <Zhiqiang.Hou@nxp.com> Reviewed-by: NYork Sun <york.sun@nxp.com>
-
由 Hou Zhiqiang 提交于
The FSL Primary Protected Application (PPA) is a software component loaded during boot which runs in TrustZone and remains resident after boot. Use the secure firmware framework to integrate FSL PPA into U-Boot. Signed-off-by: NHou Zhiqiang <Zhiqiang.Hou@nxp.com> Reviewed-by: NYork Sun <york.sun@nxp.com>
-
由 Hou Zhiqiang 提交于
This framework is introduced for ARMv8 secure monitor mode firmware. The main functions of the framework are, on EL3, verify the firmware, load it to the secure memory and jump into it, and while it returned to U-Boot, do some necessary setups at the 'target exception level' that is determined by the respective secure firmware. So far, the framework support only FIT format image, and need to define the name of which config node should be used in 'configurations' and the name of property for the raw secure firmware image in that config. The FIT image should be stored in Byte accessing memory, such as NOR Flash, or else it should be copied to main memory to use this framework. Signed-off-by: NHou Zhiqiang <Zhiqiang.Hou@nxp.com> Reviewed-by: NYork Sun <york.sun@nxp.com>
-
由 Hou Zhiqiang 提交于
This function assume that the d-cache and MMU has been enabled earlier, so it just created MMU table in main memory. But the assumption is not always correct, for example, the early setup is done in EL3, while enable_caches() is called when the PE has turned into another EL. Define the function mmu_setup() for fsl-layerscape to cover the weak one. Signed-off-by: NHou Zhiqiang <Zhiqiang.Hou@nxp.com> Reviewed-by: NYork Sun <york.sun@nxp.com>
-
由 York Sun 提交于
Drop platform code to create static MMU tables. Use common framework to create MMU tables on the run. Tested on LS2080ARDB with secure and non-secure ram scenarios. Signed-off-by: NYork Sun <york.sun@nxp.com>
-
- 17 7月, 2016 1 次提交
-
-
由 Simon Glass 提交于
This should be spl_of_platdata, since otherwise it will try to run on boards that don't support of-platdata. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
- 16 7月, 2016 7 次提交
-
-
由 Robert P. J. Day 提交于
Fix a number of typos, including: * "compatble" -> "compatible" * "eanbeld" -> "enabled" * "envrionment" -> "environment" * "FTD" -> "FDT" (for "flattened device tree") * "ommitted" -> "omitted" * "overriden" -> "overridden" * "partiton" -> "partition" * "propogate" -> "propagate" * "resourse" -> "resource" * "rest in piece" -> "rest in peace" * "suport" -> "support" * "varible" -> "variable" Signed-off-by: NRobert P. J. Day <rpjday@crashcourse.ca>
-
由 Tom Rini 提交于
The code had assumed 4 CPUS before and now we have this configurable. For now, set this to the previous default. Cc: Chander Kashyap <k.chander@samsung.com> Cc: Steve Rae <steve.rae@raedomain.com> Cc: Minkyu Kang <mk7.kang@samsung.com> Signed-off-by: NTom Rini <trini@konsulko.com> Reviewed-by: NHans de Goede <hdegoede@redhat.com>
-
由 York Sun 提交于
Introduce virtual and physical addresses in the mapping table. This change have no impact on existing boards because they all use idential mapping. Signed-off-by: NYork Sun <york.sun@nxp.com>
-
由 York Sun 提交于
When page tables are created, allow later table to be created on previous block entry. Splitting block feature is already working with current code. This patch only rearranges the code order and adds one condition to call split_block(). Signed-off-by: NYork Sun <york.sun@nxp.com>
-
由 York Sun 提交于
Make setup_pgtages() and get_tcr() available for platform code to customize MMU tables. Remove unintentional call of create_table(). Signed-off-by: NYork Sun <york.sun@nxp.com>
-
由 York Sun 提交于
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: NYork Sun <york.sun@nxp.com>
-
由 York Sun 提交于
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: NYork Sun <york.sun@nxp.com>
-
- 15 7月, 2016 12 次提交
-
-
-
由 Chen-Yu Tsai 提交于
Now that we have a secure data section for storing variables, there should be no need for platform code to get the stack address. Make psci_get_cpu_stack_top a local function, as it should only be used in armv7/psci.S and only by psci_stack_setup. Signed-off-by: NChen-Yu Tsai <wens@csie.org> Signed-off-by: NHans de Goede <hdegoede@redhat.com>
-
由 Chen-Yu Tsai 提交于
Now that we have a secure data section and space to store per-CPU target PC address, switch to it instead of storing the target PC on the stack. Also save clobbered r4-r7 registers on the stack and restore them on return in psci_cpu_on for Tegra, i.MX7, and LS102xA platforms. Signed-off-by: NChen-Yu Tsai <wens@csie.org> Signed-off-by: NHans de Goede <hdegoede@redhat.com>
-
由 Chen-Yu Tsai 提交于
Now that we have a data section, add helper functions to save and fetch per-CPU target PC. Signed-off-by: NChen-Yu Tsai <wens@csie.org> Signed-off-by: NHans de Goede <hdegoede@redhat.com>
-
由 Chen-Yu Tsai 提交于
The secure monitor may need to store global or static values within the secure section of memory, such as target PC or CPU power status. Signed-off-by: NChen-Yu Tsai <wens@csie.org> Signed-off-by: NHans de Goede <hdegoede@redhat.com>
-
由 Chen-Yu Tsai 提交于
sunxi and i.mx7 both define the __secure modifier to put functions in the secure section. Move this to a common place. Signed-off-by: NChen-Yu Tsai <wens@csie.org> Signed-off-by: NHans de Goede <hdegoede@redhat.com>
-
由 Chen-Yu Tsai 提交于
Both sun6i and sun7i have 64 KB of secure SRAM. Signed-off-by: NChen-Yu Tsai <wens@csie.org> Signed-off-by: NHans de Goede <hdegoede@redhat.com>
-
由 Chen-Yu Tsai 提交于
As the PSCI implementation grows, we might exceed the size of the secure memory that holds the firmware. Add a configurable CONFIG_ARMV7_SECURE_MAX_SIZE so platforms can define how much secure memory is available. The linker then checks the size of the whole secure section against this. Signed-off-by: NChen-Yu Tsai <wens@csie.org> Signed-off-by: NHans de Goede <hdegoede@redhat.com>
-
由 Chen-Yu Tsai 提交于
psci_text_end was used to calculate the PSCI stack address following the secure monitor text. Now that we have an explicit secure stack section, this is no longer used. Signed-off-by: NChen-Yu Tsai <wens@csie.org> Signed-off-by: NHans de Goede <hdegoede@redhat.com>
-
由 Chen-Yu Tsai 提交于
Now that we have a secure stack section that guarantees usable memory, allocate the PSCI stacks in that section. Also add a diagram detailing how the stacks are placed in memory. Reserved space for the target PC remains unchanged. This should be moved to global variables within a secure data section in the future. Signed-off-by: NChen-Yu Tsai <wens@csie.org> Signed-off-by: NHans de Goede <hdegoede@redhat.com>
-
由 Chen-Yu Tsai 提交于
Until now we've been using memory beyond psci_text_end as stack space for the secure monitor or PSCI implementation, even if space was not allocated for it. This was partially fixed in ("ARM: allocate extra space for PSCI stack in secure section during link phase"). However, calculating stack space from psci_text_end in one place, while allocating the space in another is error prone. This patch adds a separate empty secure stack section, with space for CONFIG_ARMV7_PSCI_NR_CPUS stacks, each 1 KB. There's also __secure_stack_start and __secure_stack_end symbols. The linker script handles calculating the correct VMAs for the stack section. For platforms that relocate/copy the secure monitor before using it, the space is not allocated in the executable, saving space. For platforms that do not define CONFIG_ARMV7_PSCI_NR_CPUS, a whole page of stack space for 4 CPUs is allocated, matching the previous behavior. Signed-off-by: NChen-Yu Tsai <wens@csie.org> Signed-off-by: NHans de Goede <hdegoede@redhat.com>
-
由 Chen-Yu Tsai 提交于
The original PSCI implementation assumed CONFIG_ARMV7_PSCI_NR_CPUS=4. Add this to platforms that have not defined it, using CONFIG_MAX_CPUS if it is defined, or the actual number of cores for the given platform. Signed-off-by: NChen-Yu Tsai <wens@csie.org> Signed-off-by: NHans de Goede <hdegoede@redhat.com>
-