aboutsummaryrefslogtreecommitdiff
path: root/board/armltd/vexpress64
AgeCommit message (Collapse)AuthorFilesLines
2020-05-18common: Drop net.h from common headerSimon Glass1-0/+1
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: Simon Glass <sjg@chromium.org>
2020-05-07arm: juno: Use PSCI based resetAndre Przywara1-3/+1
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: Andre Przywara <andre.przywara@arm.com> Acked-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-05-07arm: juno: Enable OF_CONTROLAndre Przywara2-0/+64
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: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-01-17common: Move reset_cpu() to the CPU headerSimon Glass1-0/+1
Move this function out of common.h and into a relevant header file. Signed-off-by: Simon Glass <sjg@chromium.org>
2019-08-31Revert "vexpress64: fvp dram: add DRAM configuration"Ryan Harkin2-6/+1
This reverts commit fc04b923541d984b1544056fd3bfa8129d4e5aac where the FVP DRAM configuration was added. Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Sudeep Holla <sudeep.holla@arm.com>
2019-06-21vexpress64: fix a typo of SPDX-License-IdentifierMasahiro Yamada1-2/+1
Misspelling of SPDX-License-Identifier is rather fatal than other general typos, so must be fixed. This file spells SPDX-Licence-Identifier. ^ I also moved it to the very top of the file with // comment style. Detected by grepping the source tree: $ git grep --not -e SPDX-License-Identifier --and -e SPDX- board/armltd/vexpress64/pcie.c: * SPDX-Licence-Identifier: GPL-2.0+ Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Liviu Dudau <liviu.dudau@foss.arm.com>
2018-05-07SPDX: Convert all of our single license tags to Linux Kernel styleTom Rini2-5/+2
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: Tom Rini <trini@konsulko.com>
2017-06-01dm: Use dm.h header when driver mode is usedSimon Glass1-1/+1
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: Simon Glass <sjg@chromium.org>
2017-04-05board_f: Drop setup_dram_config() wrapperSimon Glass1-1/+3
By making dram_init_banksize() return an error code we can drop the wrapper. Adjust this and clean up all implementations. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Stefan Roese <sr@denx.de>
2016-11-29vexpress64: Juno: Change PCI buss addresses for IO to start from zero.Liviu Dudau1-1/+1
Juno uses a 1:1 mapping between CPU and PCI addresses for IO. First, that will trip devices that cannot use more than 16 bits of addresses for IO, second it is un-necessary as the system can handle zero-based PCI addresses just fine. Change the mapping to start IO bus addresses from zero. Signed-off-by: Liviu Dudau <Liviu.Dudau@foss.arm.com>
2016-07-15armv8: mmu: Add support of non-identical mappingYork Sun1-2/+4
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: York Sun <york.sun@nxp.com>
2016-03-15vexpress64: Add MMU tablesAlexander Graf1-0/+21
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: Alexander Graf <agraf@suse.de>
2015-11-21vexpress64: use 2nd DRAM bank only on junoRyan Harkin1-0/+2
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 2d0cee1ca2b9d977fa3214896bb2e30cfec77059 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: Liviu Dudau <Liviu.Dudau@foss.arm.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Ryan Harkin <ryan.harkin@linaro.org> Tested-by: Ryan 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: Ryan Harkin <ryan.harkin@linaro.org> Acked-by: Liviu Dudau <liviu.dudau@foss.arm.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
2015-11-21vexpress64: compile Juno PCIe conditionallyRyan Harkin3-3/+9
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: Ryan Harkin <ryan.harkin@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org>
2015-11-21Juno: don't print PCI debug information by defaultAndre Przywara1-1/+1
On a Juno r1 the PCI controller init routine outputs the rather boring ATR entry information. Do this only with DEBUG defined to avoid cluttering the user's terminal. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Acked-by: Ryan Harkin <ryan.harkin@linaro.org>
2015-10-19vexpress64: Juno: Add initialisation code for Juno R1 PCIe host bridge.Liviu Dudau4-1/+206
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: Liviu Dudau <Liviu.Dudau@foss.arm.com> Tested-by: Ryan Harkin <ryan.harkin@linaro.org> [trini: Always declare vexpress64_pcie_init and continue handling logic inside the function] Signed-off-by: Tom Rini <trini@konsulko.com>
2015-10-19vexpress64: Juno: Declare all 8GB of RAM and make them visible to the kernel.Liviu Dudau1-0/+8
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: Liviu Dudau <Liviu.Dudau@foss.arm.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Ryan Harkin <ryan.harkin@linaro.org> Tested-by: Ryan Harkin <ryan.harkin@linaro.org>
2015-10-11vexpress64: fvp dram: add DRAM configurationRyan Harkin2-1/+6
Create an additional FVP configuration to boot images pre-loaded into DRAM. Sometimes it's preferential to boot the model by loading the files directly into DRAM via model parameters, rather than using SemiHosting. An example of model parmaters that are used to pre-load the files into DRAM: --data cluster0.cpu0=Image@0x80080000 \ --data cluster0.cpu0=fvp-base-gicv2-psci.dtb@0x83000000 \ --data cluster0.cpu0=uInitrd@0x84000000 Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> [trini: Update board/armltd/vexpress64/Kconfig logic] Signed-off-by: Tom Rini <trini@konsulko.com>
2015-10-11vexpress64: Kconfig: tidy upRyan Harkin1-14/+1
The FVP and Juno settings were identical, but duplicated, so I removed the duplication with this patch. Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> [trini: Adjust logic to keep if/endif in the file] Signed-off-by: Tom Rini <trini@konsulko.com>
2015-04-23vexpress64: use DM for all vexpress64 boardsLinus Walleij1-1/+1
Commit d8bafe1310487ba0e0785997726b4792072178d3 "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: Linus Walleij <linus.walleij@linaro.org>
2015-04-03Merge branch 'master' of git://git.denx.de/u-boot-tegraTom Rini1-0/+13
Conflicts: board/armltd/vexpress64/vexpress64.c Signed-off-by: Tom Rini <trini@konsulko.com>
2015-03-28vexpress64: cut config and defaults for unclear variantLinus Walleij1-13/+0
This variant that is neither FVP / Base Model or Juno Versatile Express 64bit is confusing. Get rid of it unless someone can point out what machine that really is. Seems to be an evolutional artifact in the config base. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-03-28vexpress64: remove board late init, use smhloadLinus Walleij1-96/+0
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: Linus Walleij <linus.walleij@linaro.org>
2015-03-27ARMv8: enable DM in vexpress64 boardDavid Feng1-0/+13
Signed-off-by: David Feng <fenghua@phytium.com.cn>
2015-03-09armv8/vexpress64: make multientry conditionalLinus Walleij1-6/+0
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: Linus Walleij <linus.walleij@linaro.org>
2015-03-05vexpress64: juno: support SMC9118 ethernetLinus Walleij1-0/+3
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: Linus Walleij <linus.walleij@linaro.org>
2015-01-30vexpress64: support the Juno Development PlatformLinus Walleij2-0/+18
The Juno Development Platform is a physical Versatile Express device with some differences from the emulated semihosting models. The main difference is that the system is split in a SoC and an FPGA where the SoC hosts the serial ports at totally different adresses. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-01-30vexpress64: get rid of CONFIG_SYS_EXTRA_OPTIONSLinus Walleij1-1/+14
The Versatile Express ARMv8 semihosted FVP platform is still using the legacy CONFIG_SYS_EXTRA_OPTIONS method to configure some compile-time flags. Get rid of this and create a Kconfig entry for the FVP model, and a selectable bool for the semihosting library. The FVP subboard is now modeled as a target choice so we can eventually choose between different ARMv8 versatile express boards (FVP, base model, Juno...) this way. All dependent symbols are updated to reflect this. The 64bit Versatile Express board symbols are renamed VEXPRESS64 so we have some chance to see what is actually going on. Tested on the FVP fast model. Acked-by: Steve Rae <srae@broadcom.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-12-29vexpress64: take over maintenance of the semi vexpress64Linus Walleij1-1/+1
As agreed with Steve Rae I'm taking over maintenance of the semihosted, emulated FVP/foundation model Versatile Express 64 bit board variant. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Steve Rae <srae@broadcom.com>
2014-09-16kconfig: armv8: move CONFIG_ARM64 to KconfigMasahiro Yamada1-3/+0
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2014-09-16vexpress64: kconfig: consolidate CONFIG_TARGET_VEXPRESS_AEMV8A_SEMIMasahiro Yamada1-16/+0
We do not have to distinguish CONFIG_TARGET_VEXPRESS_AEMV8A_SEMI from CONFIG_TARGET_VEXPRESS_AEMV8A. Rename the former to the latter. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Reviewed-by: Steve Rae <srae@broadcom.com> Cc: David Feng <fenghua@phytium.com.cn>
2014-09-13kconfig: remove redundant "string" type in arch and board KconfigsMasahiro Yamada1-8/+0
Now the types of CONFIG_SYS_{ARCH, CPU, SOC, VENDOR, BOARD, CONFIG_NAME} are specified in arch/Kconfig. We can delete the ones in arch and board Kconfig files. This commit can be easily reproduced by the following command: find . -name Kconfig -a ! -path ./arch/Kconfig | xargs sed -i -e ' /config[[:space:]]SYS_\(ARCH\|CPU\|SOC\|\VENDOR\|BOARD\|CONFIG_NAME\)/ { N s/\n[[:space:]]*string// } ' Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2014-07-30Add board MAINTAINERS filesMasahiro Yamada1-0/+11
We have switched to Kconfig and the boards.cfg file is going to be removed. We have to retrieve the board status and maintainers information from it. The MAINTAINERS format as in Linux Kernel would be nice because we can crib the scripts/get_maintainer.pl script. After some discussion, we chose to put a MAINTAINERS file under each board directory, not the top-level one because we want to collect relevant information for a board into a single place. TODO: Modify get_maintainer.pl to scan multiple MAINTAINERS files. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Suggested-by: Tom Rini <trini@ti.com> Acked-by: Simon Glass <sjg@chromium.org>
2014-07-30kconfig: add board Kconfig and defconfig filesMasahiro Yamada1-0/+39
This commit adds: - arch/${ARCH}/Kconfig provide a menu to select target boards - board/${VENDOR}/${BOARD}/Kconfig or board/${BOARD}/Kconfig set CONFIG macros to the appropriate values for each board - configs/${TARGET_BOARD}_defconfig default setting of each board (This commit was automatically generated by a conversion script based on boards.cfg) In Linux Kernel, defconfig files are located under arch/${ARCH}/configs/ directory. It works in Linux Kernel since ARCH is always given from the command line for cross compile. But in U-Boot, ARCH is not given from the command line. Which means we cannot know ARCH until the board configuration is done. That is why all the "*_defconfig" files should be gathered into a single directory ./configs/. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Acked-by: Simon Glass <sjg@chromium.org>
2014-07-03arm: Add support for semihosting for armv8 fastmodel targets.Darwin Rambo1-5/+96
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: Darwin Rambo <drambo@broadcom.com> Cc: trini@ti.com Cc: fenghua@phytium.com.cn Cc: bhupesh.sharma@freescale.com
2014-01-09arm64: board support of vexpress_aemv8aDavid Feng2-0/+64
Signed-off-by: David Feng <fenghua@phytium.com.cn> Signed-off-by: Bhupesh Sharma <bhupesh.sharma@freescale.com>
generated by cgit v1.1 at 2024-07-15 01:02:10 +0000