- 03 9月, 2021 1 次提交
-
-
由 Tom Rini 提交于
Per a request from Andre Przywara and agreed with by Peter Hoyes, the vexpress aemv8r support wasn't quite ready to be merged, but the discussion had moved off list. We should keep the first patch in the series for now, but revert the rest. This reverts the following commits: e0bd6f31 doc: Add documentation for the Arm vexpress board configs 30e5a449 arm: Use armv8_switch_to_el1 env to switch to EL1 b53bbca6 vexpress64: Add BASER_FVP vexpress board variant 2f5b7b74 armv8: Add ARMv8 MPU configuration logic 37a757e2 armv8: Ensure EL1&0 VMSA is enabled Signed-off-by: NTom Rini <trini@konsulko.com>
-
- 02 9月, 2021 1 次提交
-
-
由 Peter Hoyes 提交于
The BASER_FVP board variant is implemented on top of the BASE_FVP board config (which, in turn, is based on the Juno Versatile Express board config). They all share a similar memory map - for BASER_FVP the map is inverted from the BASE_FVP (https://developer.arm.com/documentation/100964/1114/Base-Platform/Base---memory/BaseR-Platform-memory-map) * Create new TARGET_VEXPRESS64_BASER_FVP target, which uses the same board config as BASE_FVP and JUNO * Adapt vexpress_aemv8a.h header file to support BASER_FVP (and rename to vexpress_aemv8.h) * Enable config to switch to EL1 for the BASER_FVP * Create vexpress_aemv8r defconfig * Provide an MPU memory map for the BASER_FVP For now, only single core boot is supported. Signed-off-by: NPeter Hoyes <Peter.Hoyes@arm.com> [trini: Add MAINTAINERS, move BOOTCOMMAND to defconfig] Signed-off-by: NTom Rini <trini@konsulko.com>
-
- 03 3月, 2021 1 次提交
-
-
由 Harald Seiler 提交于
Historically, the reset_cpu() function had an `addr` parameter which was meant to pass in an address of the reset vector location, where the CPU should reset to. This feature is no longer used anywhere in U-Boot as all reset_cpu() implementations now ignore the passed value. Generic code has been added which always calls reset_cpu() with `0` which means this feature can no longer be used easily anyway. Over time, many implementations seem to have "misunderstood" the existence of this parameter as a way to customize/parameterize the reset (e.g. COLD vs WARM resets). As this is not properly supported, the code will almost always not do what it is intended to (because all call-sites just call reset_cpu() with 0). To avoid confusion and to clean up the codebase from unused left-overs of the past, remove the `addr` parameter entirely. Code which intends to support different kinds of resets should be rewritten as a sysreset driver instead. This transformation was done with the following coccinelle patch: @@ expression argvalue; @@ - reset_cpu(argvalue) + reset_cpu() @@ identifier argname; type argtype; @@ - reset_cpu(argtype argname) + reset_cpu(void) { ... } Signed-off-by: NHarald Seiler <hws@denx.de> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
- 03 2月, 2021 1 次提交
-
-
由 Simon Glass 提交于
Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: NSimon Glass <sjg@chromium.org> Signed-off-by: NTom Rini <trini@konsulko.com>
-
- 06 1月, 2021 1 次提交
-
-
由 Simon Glass 提交于
The current macro is a misnomer since it does not declare a device directly. Instead, it declares driver_info record which U-Boot uses at runtime to create a device. The distinction seems somewhat minor most of the time, but is becomes quite confusing when we actually want to declare a device, with of-platdata. We are left trying to distinguish between a device which isn't actually device, and a device that is (perhaps an 'instance'?) It seems better to rename this macro to describe what it actually is. The macros is not widely used, since boards should use devicetree to declare devices. Rename it to U_BOOT_DRVINFO(), which indicates clearly that this is declaring a new driver_info record, not a device. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
- 14 12月, 2020 2 次提交
-
-
由 Simon Glass 提交于
Try to maintain some consistency between these variables by using _plat as a suffix for them. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
We use 'priv' for private data but often use 'platdata' for platform data. We can't really use 'pdata' since that is ambiguous (it could mean private or platform data). Rename some of the latter variables to end with 'plat' for consistency. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
- 17 7月, 2020 1 次提交
-
-
由 Masahiro Yamada 提交于
The Linux coding style guide (Documentation/process/coding-style.rst) clearly says: It's a **mistake** to use typedef for structures and pointers. Besides, using typedef for structures is annoying when you try to make headers self-contained. Let's say you have the following function declaration in a header: void foo(bd_t *bd); This is not self-contained since bd_t is not defined. To tell the compiler what 'bd_t' is, you need to include <asm/u-boot.h> #include <asm/u-boot.h> void foo(bd_t *bd); Then, the include direcective pulls in more bloat needlessly. If you use 'struct bd_info' instead, it is enough to put a forward declaration as follows: struct bd_info; void foo(struct bd_info *bd); Right, typedef'ing bd_t is a mistake. I used coccinelle to generate this commit. The semantic patch that makes this change is as follows: <smpl> @@ typedef bd_t; @@ -bd_t +struct bd_info </smpl> Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
-
- 08 7月, 2020 1 次提交
-
-
由 Andre Przywara 提交于
The smc911X driver is now DM enabled, so we can switch the Juno board over to use DM_ETH for the on-board Fast Ethernet device. Works out of the box by using the DT. Signed-off-by: NAndre Przywara <andre.przywara@arm.com> Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 19 5月, 2020 2 次提交
-
-
由 Simon Glass 提交于
Move this uncommon header out of the common header. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
- 07 5月, 2020 2 次提交
-
-
由 Andre Przywara 提交于
So far the Juno board wasn't implementing reset. Let's just use the already existing PSCI_RESET based method to avoid any extra code. Signed-off-by: NAndre Przywara <andre.przywara@arm.com> Acked-by: NLiviu Dudau <liviu.dudau@arm.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Andre Przywara 提交于
The Arm Juno board was still somewhat stuck in "hardcoded land", even though there are stable DTs around, and one happens to actually be on the memory mapped NOR flash. Enable the configuration options to let the board use OF_CONTROL, and add a routine to find the address of the DTB partition in NOR flash, to use that for U-Boot's own purposes. This can also passed on via $fdtcontroladdr to any kernel or EFI application, removing the need to actually load a device tree. Since the existing "afs" command and its flash routines require flash_init() to be called before being usable, and this is done much later in the boot process, we introduce a stripped-down partition finder routine in vexpress64.c, to scan the NOR flash partitions for the DT partition. This location is then used for U-Boot to find and probe devices. The name of the partition can be configured, if needed, but defaults to "board.dtb", which is used by Linaro's firmware image provided. Signed-off-by: NAndre Przywara <andre.przywara@arm.com> Reviewed-by: NLinus Walleij <linus.walleij@linaro.org> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
- 25 1月, 2020 1 次提交
-
-
由 Simon Glass 提交于
Move this function out of common.h and into a relevant header file. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
- 18 1月, 2020 1 次提交
-
-
由 Simon Glass 提交于
Move this function out of common.h and into a relevant header file. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
- 07 5月, 2018 1 次提交
-
-
由 Tom Rini 提交于
When U-Boot started using SPDX tags we were among the early adopters and there weren't a lot of other examples to borrow from. So we picked the area of the file that usually had a full license text and replaced it with an appropriate SPDX-License-Identifier: entry. Since then, the Linux Kernel has adopted SPDX tags and they place it as the very first line in a file (except where shebangs are used, then it's second line) and with slightly different comment styles than us. In part due to community overlap, in part due to better tag visibility and in part for other minor reasons, switch over to that style. This commit changes all instances where we have a single declared license in the tag as both the before and after are identical in tag contents. There's also a few places where I found we did not have a tag and have introduced one. Signed-off-by: NTom Rini <trini@konsulko.com>
-
- 01 6月, 2017 1 次提交
-
-
由 Simon Glass 提交于
This header includes things that are needed to make driver build. Adjust existing users to include that always, even if other dm/ includes are present Signed-off-by: NSimon Glass <sjg@chromium.org>
-
- 06 4月, 2017 1 次提交
-
-
由 Simon Glass 提交于
By making dram_init_banksize() return an error code we can drop the wrapper. Adjust this and clean up all implementations. Signed-off-by: NSimon Glass <sjg@chromium.org> Reviewed-by: NStefan Roese <sr@denx.de>
-
- 16 7月, 2016 1 次提交
-
-
由 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>
-
- 16 3月, 2016 1 次提交
-
-
由 Alexander Graf 提交于
There's no good excuse for running with caches disabled on AArch64, so let's just move the vexpress64 target to enable the MMU and run with caches on. Signed-off-by: NAlexander Graf <agraf@suse.de>
-
- 22 11月, 2015 2 次提交
-
-
由 Ryan Harkin 提交于
This patch makes the 2nd DRAM bank available on Juno only and not on other vexpress64 targets, eg. the FVP models. The commit below added a 2nd bank of NOR flash for Juno, but also for all vexpress64 targets: commit 2d0cee1c Author: Liviu Dudau <Liviu.Dudau@foss.arm.com> Date: Mon Oct 19 11:08:31 2015 +0100 vexpress64: Juno: Declare all 8GB of RAM and make them visible to the kernel. Juno comes with 8GB RAM, but U-Boot only passes 2GB to the kernel. Declare a secondary memory bank and set the sizes correctly. Signed-off-by: NLiviu Dudau <Liviu.Dudau@foss.arm.com> Reviewed-by: NLinus Walleij <linus.walleij@linaro.org> Reviewed-by: NRyan Harkin <ryan.harkin@linaro.org> Tested-by: NRyan Harkin <ryan.harkin@linaro.org> Unfortunately, I only fully tested on Juno R0, R1 and the FVP Foundation model. Whilst FVP Base AEMV8 models run U-Boot OK, they fail to boot the kernel. Signed-off-by: NRyan Harkin <ryan.harkin@linaro.org> Acked-by: NLiviu Dudau <liviu.dudau@foss.arm.com> Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Ryan Harkin 提交于
Only compile in PCIe support if the board really uses it. Provide a __weak stub for the init function if e.g. FVP is being built. Signed-off-by: NRyan Harkin <ryan.harkin@linaro.org> Acked-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 20 10月, 2015 2 次提交
-
-
由 Liviu Dudau 提交于
Juno R1 has an XpressRICH3 PCIe host bridge that needs to be initialised in order for the Linux kernel to be able to enumerate the bus. Add support code here that enables the host bridge, trains the links and sets up the Address Translation Tables. Signed-off-by: NLiviu Dudau <Liviu.Dudau@foss.arm.com> Tested-by: NRyan Harkin <ryan.harkin@linaro.org> [trini: Always declare vexpress64_pcie_init and continue handling logic inside the function] Signed-off-by: NTom Rini <trini@konsulko.com>
-
由 Liviu Dudau 提交于
Juno comes with 8GB RAM, but U-Boot only passes 2GB to the kernel. Declare a secondary memory bank and set the sizes correctly. Signed-off-by: NLiviu Dudau <Liviu.Dudau@foss.arm.com> Reviewed-by: NLinus Walleij <linus.walleij@linaro.org> Reviewed-by: NRyan Harkin <ryan.harkin@linaro.org> Tested-by: NRyan Harkin <ryan.harkin@linaro.org>
-
- 23 4月, 2015 1 次提交
-
-
由 Linus Walleij 提交于
Commit d8bafe13 "ARMv8: enable DM in vexpress64 board" only enabled DM for the simulated vexpress64 board (FVP) with the hardcoded clock value for the simulated board, causing a console regression on the Juno board which was using a different clock setting. Fix this by enabling DM for all vexpress64 boards, defining the clock frequency per-board, deleting the static array of PL01x ports from the config file and relying solely on the port defined in the boardfile using platform data. Cc: David Feng <fenghua@phytium.com.cn> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 29 3月, 2015 1 次提交
-
-
由 Linus Walleij 提交于
This removes the kludgy late board init from the FVP simulator version of Versatile Express 64bit (ARMv8), and replace it with a default boot command using the new smhload command to load the files using semihosting. Tested on the Foundation Model. Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 27 3月, 2015 1 次提交
-
-
由 David Feng 提交于
Signed-off-by: NDavid Feng <fenghua@phytium.com.cn>
-
- 09 3月, 2015 1 次提交
-
-
由 Linus Walleij 提交于
While the Freescale ARMv8 board LS2085A will enter U-Boot both on a master and a secondary (slave) CPU, this is not the common behaviour on ARMv8 platforms. The norm is that U-Boot is entered from the master CPU only, while the other CPUs are kept in WFI (wait for interrupt) state. The code determining which CPU we are running on is using the MPIDR register, but the definition of that register varies with platform to some extent, and handling multi-cluster platforms (such as the Juno) will become cumbersome. It is better to only enable the multiple entry code on machines that actually need it and disable it by default. Make the single entry default and add a special ARMV8_MULTIENTRY KConfig option to be used by the platforms that need multientry and set it for the LS2085A. Delete all use of the CPU_RELEASE_ADDR from the Vexpress64 boards as it is just totally unused and misleading, and make it conditional in the generic start.S code. This makes the Juno platform start U-Boot properly. Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 06 3月, 2015 1 次提交
-
-
由 Linus Walleij 提交于
This configures the Juno board to enable ethernet using the SMSC9118 ethernet controller found in the board. Tested by TFTP-booting a kernel over ethernet. Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 03 7月, 2014 1 次提交
-
-
由 Darwin Rambo 提交于
The armv8 ARM Trusted Firmware (ATF) can be used to load various ATF images and u-boot, and does this for virtual platforms by using semihosting. This commit extends this idea by allowing u-boot to also use semihosting to load the kernel/ramdisk/dtb. This eliminates the need for a bootwrapper and produces a more realistic boot sequence with virtual models. Though the semihosting code is quite generic, support for armv7 in fastmodel is less useful due to the wide range of available silicon and the lack of a free armv7 fastmodel, so this change contains an untested armv7 placeholder for the service trap opcode. Please refer to doc/README.semihosting for a more detailed description of semihosting and how it is used with the armv8 virtual platforms. Signed-off-by: NDarwin Rambo <drambo@broadcom.com> Cc: trini@ti.com Cc: fenghua@phytium.com.cn Cc: bhupesh.sharma@freescale.com
-
- 09 1月, 2014 1 次提交
-
-
由 David Feng 提交于
Signed-off-by: NDavid Feng <fenghua@phytium.com.cn> Signed-off-by: NBhupesh Sharma <bhupesh.sharma@freescale.com>
-