Commit Graph

183 Commits

Author SHA1 Message Date
Tom Rini
03de305ec4 Restore patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"
As part of bringing the master branch back in to next, we need to allow
for all of these changes to exist here.

Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
2024-05-20 13:35:03 -06:00
Tom Rini
d678a59d2d Revert "Merge patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet""
When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay
Ethernet"' I failed to notice that b4 noticed it was based on next and
so took that as the base commit and merged that part of next to master.

This reverts commit c8ffd1356d, reversing
changes made to 2ee6f3a5f7.

Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
2024-05-19 08:16:36 -06:00
Tom Rini
df40c0e7e6 board: armltd: Remove <common.h> and add needed includes
Remove <common.h> from this board vendor directory and when needed
add missing include files directly.

Signed-off-by: Tom Rini <trini@konsulko.com>
2024-05-06 15:07:49 -06:00
Abdellatif El Khlifi
0d9a1262bb corstone1000: update maintainers
Update MAINTAINERS of corstone1000 board.

Signed-off-by: Xueliang Zhong <xueliang.zhong@arm.com>
Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
2023-08-17 12:29:21 -04:00
Tom Rini
b54fad3fe2 vexpress64: Rework MAINTAINERS file slightly
Given that we no longer have a configs/vexpress_aemv8a_defconfig file,
drop that and then include at least the aarch64-specific config.h file
here.  Also move Linus and Peter up to the main entry as well so that
they'll get tagged for the board code too and not literally only the
defconfig.

Signed-off-by: Tom Rini <trini@konsulko.com>
2023-08-03 15:30:53 -04:00
Rui Miguel Silva
3e41ebaa46 corstone1000: add nvmxip, fwu-mdata and gpt options
Enable the newest features: nvmxip, fwu-metadata and
gpt. Commands to print the partition info, gpt info
and fwu metadata will be available.

Adjust also env boot script the address of the
bootbank with the new gpt layout, and also remove
the not needed kernel address bank0 and bank1
and retrieve function that would test the bank flag
before and now we are getting the info from the fwu
metadata.

Signed-off-by: Rui Miguel Silva <rui.silva@linaro.org>
2023-06-19 14:34:16 -04:00
Rui Miguel Silva
17c744c3ea corstone1000: set kernel_addr based on boot_idx
We need to distinguish between boot banks and from which
partition to load the kernel+initramfs to memory.

For that, fetch the boot index, fetch the correspondent
partition, calculate the correct kernel address and
then set the env variable kernel_addr with that value.

Signed-off-by: Rui Miguel Silva <rui.silva@linaro.org>
2023-06-19 14:34:16 -04:00
Rui Miguel Silva
bc91ca4b8b corstone1000: add boot index
it is expected that the firmware that runs before
u-boot somehow provide the information of the bank
for now we will fetch the info from the metadata
since the Secure enclave is the one responsible for
this information.

Signed-off-by: Rui Miguel Silva <rui.silva@linaro.org>
2023-06-19 14:34:16 -04:00
Peter Hoyes
3e15be549c vexpress64: Enable VIRTIO_MMIO and RTC_PL031 in the base model
The Arm EBBR (Embedded Base Boot Requirements) require that the time
and basic networking EFI interfaces are available and working, so long
as the hardware has an RTC and network interface.

Arm FVPs typically have a memory-mapped PL031 RTC and a VIRTIO_NET
device defined in the device tree, so "imply" these in the Kconfig for
the FVP base model to simplify creating EBBR-compliant firmware.

Signed-off-by: Peter Hoyes <Peter.Hoyes@arm.com>
2023-04-25 15:31:27 -04:00
Peter Hoyes
3635df6bdf vexpress64: Use OF_HAS_PRIOR_STAGE for BASE_FVP variant
BASE_FVP now typically uses a devicetree provided by a prior boot stage
(typically Arm TF-A), so imply this option by default when
TARGET_VEXPRESS64_BASE_FVP is selected.

OF_HAS_PRIOR_STAGE selects OF_BOARD so this change is minor, but aligns
TARGET_VEXPRESS64_BASE_FVP with TARGET_VEXPRESS64_BASER_FVP.

Signed-off-by: Peter Hoyes <Peter.Hoyes@arm.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
2023-04-25 15:31:27 -04:00
Tom Rini
f5131e80fc arm: Correct cpu_reset function prototype on some platforms
Some platforms were not including <cpu_func.h> which sets the prototype
for reset_cpu, and in turn had it set wrong. Correct these cases.

Signed-off-by: Tom Rini <trini@konsulko.com>
2023-03-22 15:22:48 -04:00
Tom Rini
6e7df1d151 global: Finish CONFIG -> CFG migration
At this point, the remaining places where we have a symbol that is
defined as CONFIG_... are in fairly odd locations. While as much dead
code has been removed as possible, some of these locations are simply
less obvious at first. In other cases, this code is used, but was
defined in such a way as to have been missed by earlier checks.  Perform
a rename of all such remaining symbols to be CFG_... rather than
CONFIG_...

Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2023-01-20 12:27:24 -05:00
Tom Rini
f410d0ac8a global: Migrate CONFIG_PL011_CLOCK to CFG
Perform a simple rename of CONFIG_PL011_CLOCK to CFG_PL011_CLOCK

Signed-off-by: Tom Rini <trini@konsulko.com>
2022-12-23 10:14:51 -05:00
Tom Rini
8457d023b8 global: Remove extraneous DM_ETH imply/select
We only need to enable DM_ETH if we have a networking driver. All
networking drivers depend on DM_ETH being enabled, and their selection
ensures DM_ETH will be enabled.

Signed-off-by: Tom Rini <trini@konsulko.com>
2022-12-07 16:04:16 -05:00
Tom Rini
65cc0e2a65 global: Move remaining CONFIG_SYS_* to CFG_SYS_*
The rest of the unmigrated CONFIG symbols in the CONFIG_SYS namespace do
not easily transition to Kconfig. In many cases they likely should come
from the device tree instead. Move these out of CONFIG namespace and in
to CFG namespace.

Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2022-12-05 16:06:08 -05:00
Tom Rini
aa6e94deab global: Move remaining CONFIG_SYS_SDRAM_* to CFG_SYS_SDRAM_*
The rest of the unmigrated CONFIG symbols in the CONFIG_SYS_SDRAM
namespace do not easily transition to Kconfig. In many cases they likely
should come from the device tree instead. Move these out of CONFIG
namespace and in to CFG namespace.

Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2022-12-05 16:06:07 -05:00
Simon Glass
984639039f Rename CONFIG_SYS_TEXT_BASE to CONFIG_TEXT_BASE
The current name is inconsistent with SPL which uses CONFIG_SPL_TEXT_BASE
and this makes it imposible to use CONFIG_VAL().

Rename it to resolve this problem.

Signed-off-by: Simon Glass <sjg@chromium.org>
2022-10-31 11:01:31 -04:00
Andre Przywara
c47bb10a4d vexpress64: also consider DTB pointer in x1
Commit c0fce929564f("vexpress64: fvp: enable OF_CONTROL") added code to
consider a potential DTB address being passed in the x0 register, or
revert to the built-in DTB otherwise.
The former case was used when using the boot-wrapper, to which we sell
U-Boot as a Linux kernel. The latter was meant for TF-A, for which we
couldn't find an easy way to use the DTB it uses itself. We have some
quirk to filter for a valid DTB, as TF-A happens to pass a pointer to
some special devicetree blob in x0 as well.

Now the TF-A case is broken, when enabling proper emulation of secure
memory (-C bp.secure_memory=1). TF-A carves out some memory at the top
of the first DRAM bank for its own purposes, and configures the
TrustZone DRAM controller to make this region secure-only. U-Boot will
then hang when it tries to relocate itself exactly to the end of DRAM.
TF-A announces this by carving out that region of the /memory node, in
the DT it passes on to BL33 in x1, but we miss that so far.

Instead of repeating this carveout in our DT copy, let's try to look for
a DTB at the address x1 points to as well. This will let U-Boot pick up
the DTB provided by TF-A, which has the correct carveout in place,
avoiding the hang.
While we are at it, make the detection more robust: the length test (is
the DT larger than 256 bytes?) is too fragile, in fact the TF-A port for
a new FVP model already exceeds this. So we test x1 first, consider 0
an invalid address, and also require a /memory node to detect a valid DTB.

And for the records:
Some asking around revealed what is really going on with TF-A and that
ominous DTB pointer in x0: TF-A expects EDK-2 as its non-secure payload
(BL33), and there apparently was some long-standing ad-hoc boot protocol
defined just between the two: x0 would carry the MPIDR register value of
the boot CPU, and the hardware DTB address would be stored in x1.
Now the MPIDR of CPU 0 is typically 0, plus bit 31 set, which is defined
as RES1 in the ARMv7 and ARMv8 architectures. This gives 0x80000000,
which is the same value as the address of the beginning of DRAM (2GB).
And coincidentally TF-A put some DTB structure exactly there, for its
own purposes (passing it between stages). So U-Boot was trying to use
this DTB, which requires the quirk to check for its validity.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Peter Hoyes <peter.hoyes@arm.com>
2022-09-29 10:10:39 -04:00
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
Tom Rini
929e581a62 corstone1000: Convert to text file environment
Convert this platform to using the text file environment rather than
defining CONFIG_EXTRA_ENV_SETTINGS.

Signed-off-by: Tom Rini <trini@konsulko.com>
2022-06-22 21:30:05 -04:00
Rui Miguel Silva
f98457d70a arm: add support to corstone1000 platform
Corstone1000 is a platform from arm, which includes pre
verified Corstone SSE710 sub-system that combines Cortex-A and
Cortex-M processors [0].

This code adds the support for the Cortex-A35 implementation
at host side, it contains also the necessary bits to support
the Corstone 1000 FVP (Fixed Virtual Platform) [1] and also the
FPGA MPS3 board implementation of this platform. [2]

0: https://developer.arm.com/documentation/102360/0000
1: https://developer.arm.com/tools-and-software/open-source-software/arm-platforms-software/arm-ecosystem-fvps
2: https://developer.arm.com/documentation/dai0550/c/

Signed-off-by: Rui Miguel Silva <rui.silva@linaro.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
2022-06-22 12:35:15 -04:00
Tom Rini
f01928e232 arm: integrator: Migrate platform-specific options and cleanup armcoremodule.h
This converts the following to Kconfig:
   CONFIG_CM_INIT
   CONFIG_CM_REMAP
   CONFIG_CM_SPD_DETECT
   CONFIG_CM_MULTIPLE_SSRAM
   CONFIG_CM_TCRAM

We make the first three of these options be always enabled, as that
matches usage.  We select the last two based on how they were defined in
armcoremodule.h.  This also allows us to remove some unused code in
board/armltd/integrator/lowlevel_init.S

Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
2022-04-08 09:05:19 -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
Usama Arif
b20b16a794 arm: total_compute: increase DRAM to 8GB
The extra 6GB start at 0x8080000000.

Signed-off-by: Usama Arif <usama.arif@arm.com>
2021-10-19 11:25:25 -04:00
Kristian Amlie
15e30106ce ARM: vexpress_ca9x4: Reintroduce board in order to use with QEMU.
vexpress_ca9x4 is seemingly the only board except for qemu_arm which
is able to run U-Boot correctly, using the `-M vexpress-a9` option to
QEMU. Building for qemu_arm and running qemu-system-arm with the `-M
virt` argument has a number of downsides, most importantly that it
only supports virtio storage drivers. This significantly reduces its
usefulness in testing memory card and Flash solutions, especially when
the tested images are from a third party source.

So therefore we reintroduce the vexpress_ca9x4 board in this commit,
with the explicit goal of using it with QEMU.

A number of differences to note from the original:

* Since the board was apparently unmaintained, I have now set myself
  as the maintainer.

* The board has been converted to use the driver model, which was the
  reason it was removed in the first place.

* The vexpress_ca15_tc2 and vexpress_ca5x2 boards, which were removed
  in the same commit, are not necessary for the QEMU use case, and
  have been omitted.

* An `mmc0` alias was introduced in the dts file. The mmc is not
  detected correctly without this, now that it's based on the device
  tree instead of the board's init function.

* A couple of other nodes were removed because they were problematic
  when trying to run the UEFI bootmgr. Once again, the primary use
  case here is QEMU, and these nodes are not needed for that to work.

* Unnecessary board init code has been removed, thanks to driver model
  and device tree.

* `CONFIG_OF_EMBED` has been enabled. I know this goes against
  recommended practice, but there doesn't seem to be any other way to
  pass the dtb to U-Boot in the QEMU scenario. Using the -dtb argument
  does not work, I suppose because U-Boot doesn't use the same
  mechanics as the kernel when it's booting.

* Load addresses have been changed to fit QEMU use case.

People wanting to get a more detailed, yet somewhat isolated, diff
between this and the original, can run this command:

  git diff c6c26a05b89f25a06e7562f8c2071b60fd0c9eac~1 -- \
      $( git diff-tree --diff-filter=A -r --name-only HEAD~1 HEAD)

(Make sure to either check out this commit first, or replace HEAD with
the commit ID of this commit)

Signed-off-by: Kristian Amlie <kristian.amlie@northern.tech>
2021-09-24 14:30:46 -04:00
Tom Rini
0017931971 Revert most of the series for adding vexpress_aemv8r support
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:

e0bd6f31ce doc: Add documentation for the Arm vexpress board configs
30e5a449e8 arm: Use armv8_switch_to_el1 env to switch to EL1
b53bbca63b vexpress64: Add BASER_FVP vexpress board variant
2f5b7b7490 armv8: Add ARMv8 MPU configuration logic
37a757e227 armv8: Ensure EL1&0 VMSA is enabled

Signed-off-by: Tom Rini <trini@konsulko.com>
2021-09-03 10:42:15 -04:00
Peter Hoyes
b53bbca63b vexpress64: Add BASER_FVP vexpress board variant
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: Peter Hoyes <Peter.Hoyes@arm.com>
[trini: Add MAINTAINERS, move BOOTCOMMAND to defconfig]
Signed-off-by: Tom Rini <trini@konsulko.com>
2021-09-02 10:17:45 -04:00
Linus Walleij
7dd42be9f9 ARM: integrator: Drop PCI support
We didn't convert the Integrator to use DM for PCI in
time, and we don't use it either so let's just drop
PCI support from the Integrator.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
2021-07-06 14:07:36 -04:00
Tom Rini
c6c26a05b8 arm: Remove vexpress_ca15_tc2 board
This board has not been converted to CONFIG_DM_MMC by the deadline.
Remove it.

Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
2021-04-10 08:00:12 -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
Arnaud Aujon Chevallier
5a7885cca5 arm: vexpress: don't reset flags in board_init to avoid losing previous ones
Re-submitted because of missing description and signed-off.

flags reset in board_init caused bugs when executing command like editenv
because the reallocated flag was lost.

Tested-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Arnaud Aujon Chevallier <arnaud@intelibre.fr>
2020-11-19 09:45:49 -05:00
Usama Arif
565add124d board: armltd: Add support for Total Compute platform
Total Compute is based on ARM architecture and has
the following features enabled in u-boot:
- PL011 UART
- PL180 MMC
- NOR Flash
- FIT image with Signature
- AVB

Signed-off-by: Usama Arif <usama.arif@arm.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
2020-08-24 14:11:31 -04: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