This was used by the old sLD3 SoC, the support of which was removed
by commit 00aa453ebf ("ARM: uniphier: remove sLD3 SoC support").
There is no more user of this function.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Currently, the supports for the following two ARMv7 SoC groups
are exclusive, because the boot ROM loads the SPL to a different
address:
- LD4, sLD8 (SPL is loaded at 0x00040000)
- Pro4, Pro5, PXs2, LD6b (SPL is loaded at 0x00100000)
This limitation exists only when CONFIG_SPL=y.
Instead of using crappy CONFIG options, checking SPL and SPL_TEXT_BASE
is cleaner.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
I increased the maximum U-Boot proper size from time to time, but
configs/uniphier_v7_defconfig hit the current limit 832KB.
Some historical info:
In the initial support, the max size was 512MB.
Commit 58d702274c ("ARM: uniphier: increase CONFIG_SYS_MONITOR_LEN")
increased it to 576KB, and commit 3ce5b1a8d8 ("ARM: uniphier: move
SPL stack address") moved the SPL stack location to avoid the memory
map conflict. It was the solution to increase the size without changing
the NOR boot image map.
commit 1a4bd3a095 ("ARM: uniphier: increase CONFIG_SYS_MONITOR_LEN
again") ended up with increasing the max size again, breaking the NOR
boot image map. The limit was set to 832KB, otherwise the SPL stack
would overwrite the U-Boot proper image:
CONFIG_SPL_STACK - CONFIG_SYS_UBOOT_BASE + sizeof(struct image_header) = 0xd0000
To increase CONFIG_SYS_MONITOR_LEN even more, the SPL stack must be
moved somewhere. I put it back to the original location prior to
commit 3ce5b1a8d8.
With this change, there is no more practical size limit.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
This reverts commit 45f41c134b.
This weird workaround was the best I came up with at that time
to boot U-Boot from TF-A.
I noticed U-Boot successfully boots on LD20 (i.e. CA72 CPU) by using
the latest TF-A.
Specifically, since the following TF-A commit, U-Boot runs at EL2
instead of EL1, and this issue went away as a side-effect.
|commit f998a052fd94ea082833109f25b94ed5bfa24e8b
|Author: Masahiro Yamada <yamada.masahiro@socionext.com>
|Date: Thu Jul 25 10:57:38 2019 +0900
|
| uniphier: run BL33 at EL2
|
| All the SoCs in 64-bit UniPhier SoC family support EL2.
|
| Just hard-code MODE_EL2 instead of using el_implemented() helper.
|
| Change-Id: I7ab48002c5205bc8c013e1b46313b57d6c431db0
| Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
However, if I reverted that, this problem would come back, presumably
because some EL1 code in U-Boot triggers this issue.
Now that commit f8ddd8cbb5 ("arm64: issue ISB after updating system
registers") fixed this issue properly, this weird workaround is no
longer needed irrespective of the exception level at which U-Boot runs.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
This requires enabling BRCMSTB PCIe and XHCI_PCI drivers as well as PCI
and USB commands. To get it working one has to call the following commands:
"pci enum; usb start;", thus such commands have been added to the default
"preboot" environment variable. One has to update their environment if it
is already configured to get this feature working out of the box.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Create a non-cacheable mapping for the 0x600000000 physical memory region,
where MMIO registers for the PCIe XHCI controller are instantiated by the
PCIe bridge. Due to 32bit limit in the CPU virtual address space in ARM
32bit mode, this region is mapped at 0xff800000 CPU virtual address.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
On build with 32 bit, there is a warning for int-to-pointer-cast.
Fix the int to pointer cast by using uintptr_t.
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Provide function for setting arbitrary virtual-physical MMU mapping
and cache settings for the given region.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Update the comments in include/asm/system.h to the common style.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Move ADDR_MAP related config options from include/configs/*.h to the
proper place in lib/Kconfig. This has been done using
./tools/moveconfig.py and manual inspection of the generated changes.
This is a preparation to use ADDR_MAP helper on ARM 32bit Raspberry Pi4
board for mapping the PCIe XHCI MMIO, which is above the 4GiB identity
mapping limit.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Supporting USB keyboards out of the box is both handy for development
and production. Notably if u-boot is used to boot into GRUB.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
[mb: drop rpi_4_32b_defconfig hunk]
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
Some atypical users of xhci might need to manually reset their xHCI
controller before starting the HCD setup. Check if a reset controller
device is available to the PCI bus and trigger a reset.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
[mb: squash fix to only build xhci_reset_hw() if CONFIG_DM_BUS]
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
This is required in order to access the reset controller used to
initialize the board's xHCI chip.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
Raspberry Pi 4's co-processor controls some of the board's HW
initialization process, but it's up to Linux to trigger it when
relevant. Introduce a reset controller capable of interfacing with
RPi4's co-processor that models these firmware initialization routines as
reset lines.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
On the Raspberry Pi 4, after a PCI reset, VL805's (a xHCI chip) firmware
may either be loaded directly from an EEPROM or, if not present, by the
SoC's VideCore (the SoC's co-processor). Introduce the function that
informs VideCore that VL805 may need its firmware loaded.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
This requires enabling BRCMSTB PCIe and XHCI_PCI drivers as well as PCI
and USB commands. To get it working one has to call the following commands:
"pci enum; usb start;", thus such commands have been added to the default
"preboot" environment variable. One has to update their environment if it
is already configured to get this feature working out of the box.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
This patch adds basic driver PCI Express controller found on Broadcom
set-top-box SoCs, e.g. BCM2711.
The code is based on Linux upstream driver (pcie-brcmstb.c) with MSI
handling removed. The inbound access memory region is not currently
parsed from dma-ranges DT property and a fixed 3GB region is used.
The patch has been tested on RPI4 board, i.e. on BCM2711 SoC with VL805
USB Host Controller.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
Imports Al Viro's original Linux commit 00b0c9b82663a, which contains
an in depth explanation and two fixes from Johannes Berg:
e7d4a95da86e0 "bitfield: fix *_encode_bits()",
37a3862e12382 "bitfield: add u8 helpers".
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
[s.nawrocki: added empty lines between functions and macros]
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
[mb: squash fix including byteorder.h]
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
- Add two- and three-argument versions of CONFIG_IS_ENABLED in
linux/kconfig.h
- Adds a new feature which supports copying modified parts of
the frame buffer to the uncached hardware buffer
- Enable the copy framebuffer on various x86 targets
Create a non-cacheable mapping for the 0x600000000 physical memory region,
where MMIO registers for the PCIe XHCI controller are instantiated by the
PCIe bridge.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Reviewed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
Remove the overlap between DRAM and device's IO area.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Reviewed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
Some PCI Express register offsets are currently defined in multiple
drivers, move them to a common header to avoid re-definitions and
as a pre-requisite for adding new PCIe driver.
While at it replace some spaces with tabs.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
There might be hardware configurations where 64-bit data accesses
to XHCI registers are not supported properly. This patch removes
the readq/writeq so always two 32-bit accesses are used to read/write
64-bit XHCI registers, similarly as it is done in Linux kernel.
This patch fixes operation of the XHCI controller on RPI4 Broadcom
BCM2711 SoC based board, where the VL805 USB XHCI controller is
connected to the PCIe Root Complex, which is attached to the system
through the SCB bridge.
Even though the architecture is 64-bit the PCIe BAR is 32-bit and likely
the 64-bit wide register accesses initiated by the CPU are not properly
translated to a sequence of 32-bit PCIe accesses.
xhci_readq(), for example, always returns same value in upper and lower
32-bits, e.g. 0xabcd1234abcd1234 instead of 0x00000000abcd1234.
Cc: Sergey Temerkhanov <s.temerkhanov@gmail.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
In current code there is no cache flush after initializing the scratchpad
buffer array with the scratchpad buffer pointers. This leads to a failure
of the "slot enable" command on the rpi4 board (Broadcom STB PCIe
controller + VL805 USB hub) - the very first TRB transfer on the command
ring fails and there is a timeout while waiting for the command completion
event. After adding the missing cache flush everything seems to be working
as expected.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
i2c changes for v2020.10
- Add support for I2C controllers found on Octeon II/III and Octeon TX
TX2 SoC platforms.
- Add I2C controller support for Cortina Access CAxxxx SoCs
- new rtc methods, rtc command, and tests
- imx_lpi2c: Improve the codes to use private data
- stm32f7_i2c.c: Add new compatible "st,stm32mp15-i2c"
- stm32f7_i2c.c: Add Fast Mode Plus support
- pwm: Add PWM driver for SiFive SoC
Since the mdio code got upstreamed it is not possible
to activate network ports on CP110 Master and Slave.
The problem is in mvpp2_base_probe which is called for each
CP110 and it initializes the buffer area for descs and rx_buffers.
This should only happen once though and the bd space is actually
set to 0 after the first run of the function.
This leads to an error when the second CP110 tries the initialization
again and disables all network ports on this CP110.
This patch adds a static variable to check if the buffer area is
initialized only once globally.
Signed-off-by: Sven Auhagen <sven.auhagen@voleatech.de>
Reviewed-by: Stefan Roese <sr@denx.de>
This patch enables DM_ETH for the following Kirkwood-based LaCie boards:
- d2 Network v2
- Internet Space v2
- 2Big Network v2
- Network Space v2
- Network Space Lite v2
- Network Space Max v2
- Network Space Mini v2
Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
Reviewed-by: Stefan Roese <sr@denx.de>
This patch enables DM_USB and USB_STORAGE for the following
Kirkwood-based LaCie boards:
- d2 Network v2
- Internet Space v2
- 2Big Network v2
- Network Space v2
- Network Space Lite v2
- Network Space Max v2
Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
Reviewed-by: Stefan Roese <sr@denx.de>
This patch switches the SATA driver from mvsata_ide to sata_mv for the
following Kirkwood-based LaCie boards:
- d2 Network v2
- Internet Space v2
- 2Big Network v2
- Network Space v2
- Network Space Lite v2
- Network Space Max v2
- Network Space Mini v2
Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
Reviewed-by: Stefan Roese <sr@denx.de>
This patch converts the following Kirkwood-based LaCie boards to DM,
DM_SPI and DM_SPI_FLASH:
- d2 Network v2
- Internet Space v2
- 2Big Network v2
- Network Space v2
- Network Space Lite v2
- Network Space Max v2
- Network Space Mini v2
Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
The spi0 alias is needed by the environment code to retrieve the SPI
flash. This patch adds some -u-boot.dtsi files, providing the spi0
aliases, for all the following Kirkwood-based LaCie boards:
- d2 Network v2
- Internet Space v2
- 2Big Network v2
- Network Space v2
- Network Space Lite v2
- Network Space Max v2
- Network Space Mini v2
Note that this -u-boot.dtsi files will be removed as soon as the spi0
aliases will be available in the upstream Linux dtsi files.
Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
The helios4 is built on the same microsom as the clearfog, by syncing the config
we enable the same featureset that exists in the som on the helios4. The current
config does not boot as some of the clearfog changes needed to be made on the
helios4 also, generally speaking most changes for the clearfog should also be
made on the helios4.
Signed-off-by: Dennis Gilmore <dennis@ausil.us>
Reviewed-by: Stefan Roese <sr@denx.de>
When running USB compliance tests on our Armada-385 hardware platforms
we have seen some eye mask violations. Marvell's internal documentation
says: Based on silicon test results, it is recommended to change the
impedance calibration threshold setting to 0x6 prior to calibration.
Port changes from Marvell's u-boot fork[1] to address this.
[1] - https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/commit/a6221551
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Measurements on actual hardware shown that the read ODT is early by 3
clocks. Adjust the calculation to avoid this.
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
[upstream https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell/pull/22]
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Tested-by: Baruch Siach <baruch@tkos.co.il>
Reviewed-by: Stefan Roese <sr@denx.de>
In the Armada 385 functional spec (MV-S109094-00 Rev. C) the read sample
delay fields are 5 bits wide. Use the correct bitmask of 0x1f when
extracting the value.
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
[upstream https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell/pull/22]
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
At present the SPL loader is not included in the TPL image so SPL cannot
be loaded. Fix it by including this file for both SPL and TPL.
Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: c87f9ce227 ("x86: Don't build some unused objects in TPL")
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
These prevent use of compile-time checks such as:
if (CONFIG_IS_ENABLED(DM_SPI))
since, for example, if CONFIG_SPL_DM_SPI is not enabled then the
definitions are not included by spi.h and the C code will not build.
The #ifdefs are unnecessary since there are no conflicts with the pre-DM
code. In any case we have almost switched over to driver model for SPI.
Drop these #ifdefs from spi.h to fix a build warning on chromebook_coral
in the following patch.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This adds a bunch of preprocessor magic to extend the capabilities of
CONFIG_IS_ENABLED. The existing semantics of
CONFIG_IS_ENABLED(FOO)
expanding to a 1 or 0 (depending on build context and the defined-ness
or not of the appropriate CONFIG_FOO/CONFIG_SPL_FOO/CONFIG_TPL_FOO)
are of course preserved. With this, one is also allowed a two-argument
form
CONFIG_IS_ENABLED(FOO, (something))
which expands to something precisely when CONFIG_IS_ENABLED(FOO) would
expand to 1, and expands to nothing otherwise. It is, in other words,
completely equivalent to the three lines
#if CONFIG_IS_ENABLED(FOO)
something
#endif
The second argument must be parenthesized in order to allow any
tokens, including a trailing comma, to appear - one use case for this
is precisely to make it a bit more ergonomic to build an array and
only include certain items depending on .config. That should increase
both readability and not least "git grep"ability.
A third variant is also introduced,
CONFIG_IS_ENABLED(FOO, (xxx), (yyy))
which corresponds to
#if CONFIG_IS_ENABLED(FOO)
xxx
#else
yyy
#endif
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
U-Boot does not have loadable modules, and nothing currently uses any
of the (CONFIG_)?IS_(BUILTIN|MODULE) macros - only
the (CONFIG_)?IS_ENABLED variants are ever used.
While I understand the desire to keep this somewhat synchronized with
linux, we've already departed by the introduction of the
CONFIG_IS_ENABLED extra logic, and deleting these makes the next patch
much simpler, since I won't have to duplicate a lot of logic for no
real gain (as there are no users).
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
Instead of using the arg1_or_junk trick to pick between two choices,
with a bit of duplication between the branches (and most of the
CONFIG_TPL_BUILD case being redundant, as _IS_TPL is known to be
defined to 1 in that case), simply define a prefix that we inject
between CONFIG_ and the given config symbol.
This only requires one level of indirection (to get the
_CONFIG_PREFIX macro expanded before the token concatenation takes
place), and makes it easy to, say, introduce a CONFIG_HOSTTOOL_
prefix. [I would expect most HOSTTOOL_ symbols to just be def_bool y,
but it would allow us to clean up some of the ifdef HOSTCC mess in the
sources shared between U-Boot and host tools.]
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
Add parentheses around CONFIG_IS_ENABLED() in the if statement, to
fix potential build failures.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com>
This seems like a more reasonable resolution for this board, since it is
quite slow. It also allows it to work with a 5" LCD display in my lab.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
