Commit graph

60 commits

Author SHA1 Message Date
Tom Rini
ecf1d2741d net: Remove smc91111 ethernet driver
This driver has not been converted to DM_ETH.  The migration deadline
passed 2 years ago.

Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: David Feng <fenghua@phytium.com.cn>
Cc: Liviu Dudau <liviu.dudau@foss.arm.com>
Cc: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Acked-by: Ramon Fried <rfried.dev@gmail.com>
2022-08-12 16:10:50 -04:00
Peter Hoyes
8d78a6b674 vexpress64: Add ARMv8R-64 board variant
The ARMv8-R64 architecture introduces optional VMSA (paging based MMU)
support in the EL1/0 translation regime, which makes that part mostly
compatible to ARMv8-A.

Add a new board variant to describe the "BASE-R64" FVP model, which
inherits a lot from the existing v8-A FVP support. One major difference
is that the memory map in "inverted": DRAM starts at 0x0, MMIO is at
2GB [1].

 * Create new TARGET_VEXPRESS64_BASER_FVP target, sharing most of the
   exising configuration.
 * Implement inverted memory map in vexpress_aemv8.h
 * Create vexpress_aemv8r defconfig
 * Provide an MMU memory map for the BASER_FVP
 * Update vexpress64 documentation

At the moment the boot-wrapper is the only supported secure firmware. As
there is no official DT for the board yet, we rely on it being supplied
by the boot-wrapper into U-Boot, so use OF_HAS_PRIOR_STAGE, and go with
a dummy DT for now.

[1] https://developer.arm.com/documentation/100964/1114/Base-Platform/Base---memory/BaseR-Platform-memory-map

Signed-off-by: Peter Hoyes <Peter.Hoyes@arm.com>
[Andre: rebase and add Linux kernel header]
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
[trini: Add MAINTAINERS entry for Peter]
2022-04-01 15:03:03 -04:00
Andre Przywara
1a1143a454 vexpress64: pick DRAM size from DT
So far the DRAM size for both the Juno and the FVP model were hardcoded
in our config header file. For the Juno this is fine, as all models have
8 GiB of DRAM, but the DRAM size can be configured on the model command
line.

Drop the fixed DRAM size setup, instead look up the size in the device
tree, that we now have for every board. This allows a user to inject
a DT with the proper size, and be able to use the full amount of DRAM.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2022-04-01 14:59:15 -04:00
Andre Przywara
30cacb8123 vexpress64: generalise page table generation
In preparation for the ARMv8-R64 FVP support, which has DRAM mapped at
0x0, generalise the page table generation, by using symbolic names for
the address ranges instead of fixed numbers.

We already define the base of the DRAM and MMIO regions, so just use
those symbols in the page table description. Rename V2M_BASE to the more
speaking V2M_DRAM_BASE on the way.

On the VExpress memory map, the address space right after 4GB is of no
particular interest to software, as the whole of DRAM is mapped at 32GB
instead. The first 2 GB alias to the lower 2GB of DRAM mapped below 4GB,
so we skip this part and map some more of the high DRAM, should anyone
need it.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2022-04-01 14:59:15 -04:00
Andre Przywara
5865038257 vexpress64: move hardware setting from defconfig to Kconfig
The defconfigs for the Arm Juno board and the FVP model are quite large,
setting a lot of platform-fixed variables like SYS_TEXT_BASE.
As those values are not really a user choice, let's provide default
values for them in our Kconfig file, so a lot of cruft can be removed
from the defconfig files.
This also moves the driver selection out of there, since this is again
not something a user should really decide on. Instead we allow users to
enable or disable subsystems, and select the appropriate drivers based
on that in the Kconfig file.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2022-04-01 14:57:46 -04:00
Andre Przywara
c0fce92956 vexpress64: fvp: enable OF_CONTROL
The FVP base model is relying on a DT for Linux operation, so there is
no reason we would need to rely on hardcoded information for U-Boot.
Letting U-Boot use a DT will open up the usage of actual peripherals,
beyond the support for semihosting only.

Enable OF_CONTROL in the Kconfig, and use the latest dts files from
Linux. Depending on whether we use the boot-wrapper or TF-A, there is
already a DTB provided or not, respectively.

To cover the boot-wrapper, we add an arm64 Linux kernel header, which
allows the boot-wrapper to treat U-Boot like a Linux kernel. U-Boot will
find the pointer to the DTB in x0, and will use it.

Even though TF-A carries a DT, at the moment this is not made available
to non-secure world, so to not break users, we use the U-Boot provided
DTB copy in that case. For some reason TF-A puts some DT like structure
at the address x0 is pointing at, but that is very small and doesn't
carry any hardware information. Make the code to ignore those small DTBs.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2022-04-01 14:55:38 -04:00
Andre Przywara
fac7fc43cf vexpress64: Kconfig: move board definitions out of arch/arm
At the moment we define three "VExpress64" boards in arch/arm/Kconfig,
plus have a second Kconfig file in board/armltd/Kconfig.
One of those three boards is actually bogus (TARGET_VEXPRESS64_AEMV8A),
that stanza looks like being forgotten in a previous cleanup.

To remove the clutter from the generic Kconfig file, just define some
ARCH_VEXPRESS64 symbol there, enable some common options, and do the
board/model specific configuration in the board/armltd Kconfig file.

That allows to streamline and fine tune the configuration later, and
to also pull a lot of "non user choices" out of the defconfigs.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2022-04-01 14:55:38 -04:00
Pali Rohár
d7b904092d pci: Add defines for normal and subtractive PCI bridges
Add following two new PCI class codes defines into pci_ids.h include file:

  PCI_CLASS_BRIDGE_PCI_NORMAL
  PCI_CLASS_BRIDGE_PCI_SUBTRACTIVE

And use these defines in all U-Boot code for describing PCI class codes for
normal and subtractive PCI bridges.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
2022-03-25 13:35:50 -04:00
Pali Rohár
ca4b097d7b vexpress64: Remove unused macro XR3PCI_ECAM_OFFSET
Macro XR3PCI_ECAM_OFFSET is unused and in case it would be needed in future
it can be replaced by standard PCIE_ECAM_OFFSET macro from pci.h file.

Signed-off-by: Pali Rohár <pali@kernel.org>
2022-01-12 14:21:24 -05:00
Peter Hoyes
439581dca4 vexpress64: Enable VIRTIO_NET network driver
The SMSC driver is using the old driver model.

Init the virtio system in vexpress64.c so that the network device is
discovered.

Signed-off-by: Peter Hoyes <Peter.Hoyes@arm.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
2022-01-04 22:48:48 -05:00
Peter Hoyes
2661397464 vexpress64: Enable OF_CONTROL and OF_BOARD for VExpress64
Capture x0 in lowlevel_init.S as potential fdt address. Modify
board_fdt_blob_setup to use fdt address from either vexpress_aemv8.h
or lowlevel_init.S.

Signed-off-by: Peter Hoyes <Peter.Hoyes@arm.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
2022-01-04 22:48:48 -05:00
Peter Hoyes
17fe55fd6f vexpress64: Refactor header file to make it easier to add new FVPs
Rename from vexpress_aemv8a.h -> vepxress_aemv8.h as new FVPs may not be
v8-A. No change in behavior.

This is towards future work to enable support for the FVP_BaseR.

Signed-off-by: Peter Hoyes <Peter.Hoyes@arm.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
2022-01-04 22:48:48 -05:00
Ilias Apalodimas
e7fb789612 sandbox: Remove OF_HOSTFILE
OF_HOSTFILE is used on sandbox configs only.  Although it's pretty
unique and not causing any confusions,  we are better of having simpler
config options for the DTB.

So let's replace that with the existing OF_BOARD.  U-Boot would then
have only three config options for the DTB origin.
- OF_SEPARATE, build separately from U-Boot
- OF_BOARD, board specific way of providing the DTB
- OF_EMBED embedded in the u-boot binary(should not be used in production

Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
2021-10-27 16:38:26 -04:00
Harald Seiler
35b65dd8ef reset: Remove addr parameter from reset_cpu()
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: Harald Seiler <hws@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
2021-03-02 14:03:02 -05:00
Simon Glass
401d1c4f5d common: Drop asm/global_data.h from common header
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: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
2021-02-02 15:33:42 -05:00
Simon Glass
20e442ab2d dm: Rename U_BOOT_DEVICE() to U_BOOT_DRVINFO()
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: Simon Glass <sjg@chromium.org>
2021-01-05 12:26:35 -07:00
Simon Glass
8a8d24bdf1 dm: treewide: Rename ..._platdata variables to just ..._plat
Try to maintain some consistency between these variables by using _plat as
a suffix for them.

Signed-off-by: Simon Glass <sjg@chromium.org>
2020-12-13 16:51:09 -07:00
Simon Glass
caa4daa2ae dm: treewide: Rename 'platdata' variables to just 'plat'
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: Simon Glass <sjg@chromium.org>
2020-12-13 16:51:08 -07:00
Masahiro Yamada
b75d8dc564 treewide: convert bd_t to struct bd_info by coccinelle
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: Masahiro Yamada <masahiroy@kernel.org>
2020-07-17 09:30:13 -04:00
Andre Przywara
eb6211171d arm: juno: Enable PCI
The ARM Juno boards in their -r1 and -r2 variants sport a PCIe
controller, which we configure already in board specific code to be ECAM
compliant. Hence we can just enable the generic ECAM driver to let
U-Boot use PCIe devices.

Add the respective options to the Juno defconfig to enable the PCI
framework and the generic ECAM driver, and initialise the driver upon
loading U-Boot.

Make some functions in the Juno PCIe init code static on the way.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
2020-07-07 18:23:48 -04:00
Andre Przywara
cc696e7cae arm: juno: Enable DM_ETH
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: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
2020-07-07 18:23:48 -04:00
Simon Glass
c05ed00afb common: Drop linux/delay.h from common header
Move this uncommon header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>
2020-05-18 21:19:23 -04:00
Simon Glass
f7ae49fc4f common: Drop log.h from common header
Move this header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>
2020-05-18 21:19:18 -04:00
Simon Glass
691d719db7 common: Drop init.h from common header
Move this uncommon header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>
2020-05-18 17:33:33 -04:00
Simon Glass
90526e9fba common: Drop net.h from common header
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-18 17:33:31 -04:00
Andre Przywara
be0d09695d arm: juno: Use PSCI based reset
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-07 09:01:42 -04:00
Andre Przywara
b3270e9138 arm: juno: Enable OF_CONTROL
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-05-07 09:01:42 -04:00
Simon Glass
9a3b4ceb37 common: Move reset_cpu() to the CPU header
Move this function out of common.h and into a relevant header file.

Signed-off-by: Simon Glass <sjg@chromium.org>
2020-01-17 14:02:31 -05:00
Ryan Harkin
296439e0b1 Revert "vexpress64: fvp dram: add DRAM configuration"
This reverts commit fc04b92354 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-08-31 09:27:19 -04:00
Masahiro Yamada
7700b13ce9 vexpress64: fix a typo of SPDX-License-Identifier
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>
2019-06-21 10:07:11 -04:00
Tom Rini
83d290c56f SPDX: Convert all of our single license tags to Linux Kernel style
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>
2018-05-07 09:34:12 -04:00
Simon Glass
9d922450aa dm: Use dm.h header when driver mode is used
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-06-01 06:57:52 -06:00
Simon Glass
76b00aca4f board_f: Drop setup_dram_config() wrapper
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>
2017-04-05 16:36:51 -04:00
Liviu Dudau
88e0d59315 vexpress64: Juno: Change PCI buss addresses for IO to start from zero.
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-11-29 08:15:30 -05:00
York Sun
cd4b0c5fea armv8: mmu: Add support of non-identical mapping
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-07-15 09:01:43 -07:00
Alexander Graf
e593bf5eb3 vexpress64: Add MMU tables
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>
2016-03-15 15:13:04 -04:00
Ryan Harkin
2c2b218383 vexpress64: use 2nd DRAM bank only on juno
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 2d0cee1ca2
    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-21 21:50:28 -05:00
Ryan Harkin
bc8d3bc023 vexpress64: compile Juno PCIe conditionally
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-21 21:50:27 -05:00
Andre Przywara
0ee1a22b6d Juno: don't print PCI debug information by default
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-11-21 21:50:27 -05:00
Liviu Dudau
2fdc9b741b vexpress64: Juno: Add initialisation code for Juno R1 PCIe host bridge.
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-19 17:05:46 -04:00
Liviu Dudau
2d0cee1ca2 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>
2015-10-19 17:05:28 -04:00
Ryan Harkin
fc04b92354 vexpress64: fvp dram: add DRAM configuration
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-11 17:11:47 -04:00
Ryan Harkin
b483cb5a94 vexpress64: Kconfig: tidy up
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-10-11 09:17:03 -04:00
Linus Walleij
d280ea00ef vexpress64: use DM for all vexpress64 boards
Commit d8bafe1310
"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-23 08:52:26 -04:00
Tom Rini
692e5c4e7e Merge branch 'master' of git://git.denx.de/u-boot-tegra
Conflicts:
	board/armltd/vexpress64/vexpress64.c

Signed-off-by: Tom Rini <trini@konsulko.com>
2015-04-03 09:14:38 -04:00
Linus Walleij
03314f0e24 vexpress64: cut config and defaults for unclear variant
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-28 12:07:46 -04:00
Linus Walleij
49995ffe81 vexpress64: remove board late init, use smhload
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-28 12:07:45 -04:00
David Feng
d8bafe1310 ARMv8: enable DM in vexpress64 board
Signed-off-by: David Feng <fenghua@phytium.com.cn>
2015-03-27 16:33:51 +01:00
Linus Walleij
23b5877c64 armv8/vexpress64: make multientry conditional
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-09 11:13:29 -04:00
Linus Walleij
b31f9d7a4a vexpress64: juno: support SMC9118 ethernet
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-03-05 20:49:42 -05:00