Commit graph

21 commits

Author SHA1 Message Date
Marek Behún
61143f741e treewide: Fix Marek's name and change my e-mail address
Fix diacritics in some instances of my name and change my e-mail address
to kabel@kernel.org.

Add corresponding .mailmap entries.

Signed-off-by: Marek Behún <kabel@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
2022-07-21 10:14:04 +02:00
Pali Rohár
1fd54253bc arm: a37xx: pci: Fix a3700_fdt_fix_pcie_regions() function again
The a3700_fdt_fix_pcie_regions() function still computes nonsense.

It computes the fixup offset from the PCI address taken from the first
row of the "ranges" array, which means that:
- PCI address must equal CPU address (otherwise the computed fix offset
  will be wrong),
- the first row must contain the lowest address.

This is the case for the default device-tree, which is why we didn't
notice it.

It also adds the fixup offset to all PCI and CPU addresses, which is
wrong.

Instead:
1) The fixup offset must be computed from the CPU address, not PCI
   address.

2) The fixup offset must be computed from the row containing the lowest
   CPU address, which is not necessarily contained in the first row.

3) The PCI address - the address to which the PCIe controller remaps the
   address space as seen from the point of view of the PCIe device -
   must be fixed by the fix offset in the same way as the CPU address
   only in the special case when the CPU adn PCI addresses are the same.
   Same addresses means that remapping is disabled, and thus if we
   change the CPU address, we need also to change the PCI address so
   that the remapping is still disabled afterwards.

Consider an example:
  The ranges entries contain:
    PCI address   CPU address
    70000000      EA000000
    E9000000      E9000000
    EB000000      EB000000

  By default CPU PCIe window is at:        E8000000 - F0000000
  Consider the case when TF-A moves it to: F2000000 - FA000000

  Until now the function would take the PCI address of the first entry:
  70000000, and the new base, F2000000, to compute the fix offset:
  F2000000 - 70000000 = 82000000, and then add 8200000 to all addresses,
  resulting in
    PCI address   CPU address
    F2000000      6C000000
    6B000000      6B000000
    6D000000      6D000000
  which is complete nonsense - none of the CPU addresses is in the
  requested window.

  Now it will take the lowest CPU address, which is in second row,
  E9000000, and compute the fix offset F2000000 - E9000000 = 09000000,
  and then add it to all CPU addresses and those PCI addresses which
  equal to their corresponding CPU addresses, resulting in
    PCI address   CPU address
    70000000      F3000000
    F2000000      F2000000
    F4000000      F4000000
  where all of the CPU addresses are in the needed window.

Fixes: 4a82fca8e3 ("arm: a37xx: pci: Fix a3700_fdt_fix_pcie_regions() function")
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
2022-03-04 08:38:05 +01:00
Pali Rohár
18ab060288 arm: mvebu: a37xx: Fix comment with name of the function
Function is named build_mem_map, not a3700_build_mem_map.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
2022-02-17 14:17:07 +01:00
Pali Rohár
65375d026a arm: mvebu: a37xx: Map CCI-400 and AP BootROM address space
In function build_mem_map() prepare also mapping for CCI-400 and
BootROM windows.

BootROM window is 1 MB long and by default starts at address 0xfff00000.
A53 AP BootROM is 16 kB long and repeats in this BootROM window 64 times.
RVBAR_EL3 register is set to value 0xffff0000, so by default A53 AP BootROM
is accessed via range 0xffff0000-0xffff3fff.

CCI-400 window when new TF-A version is used, starts at address 0xfe000000
and when old TF-A version is used, starts at address 0xd8000000.

Physical addresses are read directly from mvebu registers, so if TF-A
remaps it in future (again) then it would not cause any issue for U-Boot.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
2022-02-17 14:17:07 +01:00
Pali Rohár
2fb7426cf0 arm: mvebu: a37xx: Fix calling build_mem_map()
Function build_mem_map() modifies global variable mem_map. This variable is
used by the get_page_table_size() function which is called by function
arm_reserve_mmu() (as aliased macro PGTABLE_SIZE). Function
arm_reserve_mmu() is called earlier than enable_caches() which calls
build_mem_map(). So arm_reserve_mmu() does not calculate reserved memory
correctly.

Fix this issue by calling build_mem_map() from a3700_dram_init() which is
called before arm_reserve_mmu().

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
2022-02-17 14:17:07 +01:00
Pali Rohár
cbd7ef70bc arm: a37xx: pci: Optimize a3700_fdt_fix_pcie_regions() when fixup offset is zero
If fixup offset is zero then there is nothing to fix. All calculation in
this case just increase addresses by value zero which results in identity.
So in this case skip whole fixup re-calculation as it is not needed.

This is just an optimization for special case when fix_offset is zero which
skips code path which does only identity operations (meaning nothing). No
functional changes.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Konstantin Porotchkin <kostap@marvell.com>
Reviewed-by: Stefan Roese <sr@denx.de>
2021-07-15 10:53:05 +02:00
Pali Rohár
4a82fca8e3 arm: a37xx: pci: Fix a3700_fdt_fix_pcie_regions() function
Current version of this function uses a lot of incorrect assumptions about
the `ranges` DT property:

 * parent(#address-cells) == 2
 * #size-cells == 2
 * number of entries == 2
 * address size of first entry == 0x1000000
 * second child address entry == base + 0x1000000

Trying to increase PCIe MEM space to more than 16 MiB leads to an overlap
with PCIe IO space, and trying to define additional MEM space (as a third
entry in the `ranges` DT property) causes U-Boot to crash when booting the
kernel.

  ## Flattened Device Tree blob at 04f00000
     Booting using the fdt blob at 0x4f00000
     Loading Device Tree to 000000001fb01000, end 000000001fb08f12 ... OK
  ERROR: board-specific fdt fixup failed: <unknown error>
   - must RESET the board to recover.

Fix a3700_fdt_fix_pcie_regions() to properly parse and update all addresses
in the `ranges` property according to
https://elinux.org/Device_Tree_Usage#PCI_Address_Translation

Now it is possible to increase PCIe MEM space from 16 MiB to maximal value
of 127 MiB.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Fixes: cb2ddb291e ("arm64: mvebu: a37xx: add device-tree fixer for PCIe regions")
Reviewed-by: Stefan Roese <sr@denx.de>
2021-06-04 11:32:41 +02:00
Pali Rohár
46b679e3ec arm: a37xx: pci: Find PCIe controller node by compatible instead of path
Find PCIe DT node by compatible string instead of retrieving it by using
hardcoded DT path.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
2021-06-04 11:32:41 +02: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
cd93d625fd common: Drop linux/bitops.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
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
Marek Behún
cb2ddb291e arm64: mvebu: a37xx: add device-tree fixer for PCIe regions
In case when ARM Trusted Firmware changes the default address of PCIe
regions (which can be done for devices with 4 GB RAM to maximize the
amount of RAM the device can use) we add code that looks at how ATF
changed the PCIe windows in the CPU Address Decoder and changes given
device-tree blob accordingly.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
2020-04-14 13:16:42 +02:00
Marek Behún
a129f64fb0 arm64: mvebu: a37xx: improve code determining memory info structures
Currently on Armada-37xx the mem_map structure is statically defined to
map first 2 GB of memory as RAM region, and system registers and PCIe
region device region.

This is insufficient for when there is more RAM or when for example the
PCIe windows is mapped to another address by the CPU Address Decoder.
In the case when the board has 4 GB RAM, on some boards the ARM Trusted
Firmware can move the PCIe window to another address, in order to
maximize possible usable RAM.

Also the dram_init and dram_init_banksize looks for information in
device-tree, and therefore different device trees are needed for boards
with different RAM sizes.

Therefore we add code that looks at how the ARM Trusted Firmware has
configured the CPU Address Decoder windows, and then we update the
mem_map structure and compute gd->ram_size and gd->bd->bi_dram bank
base addresses and sizes accordingly.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
2020-04-14 13:16:42 +02: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
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
Tom Rini
d024236e5a Remove unnecessary instances of DECLARE_GLOBAL_DATA_PTR
We have a large number of places where while we historically referenced
gd in the code we no longer do, as well as cases where the code added
that line "just in case" during development and never dropped it.

Signed-off-by: Tom Rini <trini@konsulko.com>
2018-04-27 14:54:48 -04:00
Wilson Ding
92e7a6814c arm64: a37xx: populate pcie memory region
This patch added a new region of 32MiB AT 0xe800.0000
to Armada37x0's memory map. This region is supposed to
be mapped in MMU in order to enable the access to the
PCI I/O or MEM resources.

Signed-off-by: Wilson Ding <dingwei@marvell.com>
Reviewed-on: http://vgitil04.il.marvell.com:8080/38724
Tested-by: iSoC Platform CI <ykjenk@marvell.com>
Reviewed-by: Victor Gu <xigu@marvell.com>
Signed-off-by: Ken Ma <make@marvell.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>
2018-03-30 12:52:49 +02:00
Masahiro Yamada
b08c8c4870 libfdt: move headers to <linux/libfdt.h> and <linux/libfdt_env.h>
Thomas reported U-Boot failed to build host tools if libfdt-devel
package is installed because tools include libfdt headers from
/usr/include/ instead of using internal ones.

This commit moves the header code:
  include/libfdt.h         -> include/linux/libfdt.h
  include/libfdt_env.h     -> include/linux/libfdt_env.h

and replaces include directives:
  #include <libfdt.h>      -> #include <linux/libfdt.h>
  #include <libfdt_env.h>  -> #include <linux/libfdt_env.h>

Reported-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-03-05 10:16:28 -05:00
Stefan Roese
21b29fc64e arm64: mvebu: Add basic support for the Marvell Armada 7K/8K SoC
Compared to the Armada 3700, the Armada 7K and 8K are much more on the
high-end side: they use a dual Cortex-A72 or a quad Cortex-A72, as
opposed to the Cortex-A53 for the Armada 3700.

The Armada 7K and 8K also use a fairly unique architecture, internally
they are composed of several components:

- One AP (Application Processor), which contains the processor itself
  and a few core hardware blocks. The AP used in the Armada 7K and 8K
  is called AP806, and is available in two configurations:
  dual Cortex-A72 and quad Cortex-A72.
- One or two CP (Communication Processor), which contain most of the I/O
  interfaces (SATA, PCIe, Ethernet, etc.). The 7K family chips have one
  CP, while the 8K family chips integrate two CPs, providing two times
  the number of I/O interfaces available in the CP.
  The CP used in the 7K and 8K is called CP110.

All in all, this gives the following combinations:

- Armada 7020, which is a dual Cortex-A72 with one CP
- Armada 7040, which is a quad Cortex-A72 with one CP
- Armada 8020, which is a dual Cortex-A72 with two CPs
- Armada 8040, which is a quad Cortex-A72 with two CPs

This patch adds basic support for this ARMv8 based SoC into U-Boot.
Future patches will integrate other device drivers and board support,
starting with the Marvell DB-88F7040 development board.

Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Nadav Haklai <nadavh@marvell.com>
Cc: Neta Zur Hershkovits <neta@marvell.com>
Cc: Kostya Porotchkin <kostap@marvell.com>
Cc: Omri Itach <omrii@marvell.com>
Cc: Igal Liberman <igall@marvell.com>
Cc: Haim Boot <hayim@marvell.com>
Cc: Hanna Hawa <hannah@marvell.com>
2016-09-27 17:29:54 +02:00
Stefan Roese
f61aefc150 arm64: mvebu: Add support for the Marvell Armada 3700 SoC
The Armada 3700 integrates the following interfaces (not complete list):
- Dual Cortex-A53 ARMv8
- USB 3.0
- SATA 3.0
- PCIe 2.0
- 2 x Gigabit Ethernet 1Gbps / 2.5Gbps
- ...

This patch adds basic support for this ARMv8 based SoC into U-Boot.
Future patches will integrate other device drivers and board support
for the Marvell DB-88F3720 development board.

Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Nadav Haklai <nadavh@marvell.com>
Cc: Kostya Porotchkin <kostap@marvell.com>
Cc: Wilson Ding <dingwei@marvell.com>
Cc: Victor Gu <xigu@marvell.com>
Cc: Hua Jing <jinghua@marvell.com>
Cc: Terry Zhou <bjzhou@marvell.com>
Cc: Hanna Hawa <hannah@marvell.com>
Cc: Haim Boot <hayim@marvell.com>
2016-09-27 17:29:53 +02:00