Align R-Car Gen2/Gen3/Gen4 configuration header file to look
basically the same way across these three SoC generations.
There are subtle difference between the remaining bits in
those files across SoC generations, but the common bits are
now aligned. There is not much left in those headers either,
most of the configuration is now converted to Kconfig.
Specifically for R-Car Gen3, GIC registers have been moved
to architecture specific header file rcar-gen3-base.h , the
rest of the changes here are comment changes and indentation
changes.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
(cherry picked from commit 2fd7a04e7c)
Add support for building U-Boot SPL for Renesas R-Car Gen4 R8A779G0 V4H SoC.
The SPL initializes the DBSC5 DRAM controller, RT-VRAM and loads and starts
U-Boot proper on the Cortex-A76 core.
The SoC BootROM can not boot the CA76 core directly, instead the SPL starts
on the CR52 core which immediately brings up the CA76 core, which in turn
starts executing the actual SPL. This is achieved by placing a tiny bit of
precompiled Aarch32 code at the very beginning of the SPL. The code consists
of some 32 instructions, uses APMU to configure CA76 start address to offset
0x80 Bytes from start of the SPL, and uses APMU to start the CA76 core. The
code parts the CR52 core in an endless loop once the CA76 core got started.
The 32 instructions are completely arbitrary number, so is the offset 0x80
Bytes from start of SPL, because 0x80 = 128 decimal and 128 / 4 bytes per
instruction is 32 instructions. The 32 instructions turned out to be enough
to started the CA76 and 0x80 is nicely aligned.
Once the SPL completes hardware initialization, the SPL loads U-Boot proper.
The u-boot.itb proper fitImage contains 64bit build on u-boot-nodtb.bin and
a DT for R8A779G0 V4H White Hawk board and is generated by binman. The
u-boot.itb is loaded from SPI NOR offset 0x80000.
In order to install this setup on an existing R8A779G0 V4H White Hawk board,
build using r8a779g0_whitehawk_defconfig, generate SPI NOR image flash.bin
and write flash.bin to SPI NOR offset 0x0 . Finally, configure board MD pin
switches according to the R8A779G0 V4H White Hawk board documentation for
40 MHz SPI NOR boot using DMA and restart the board.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
(cherry picked from commit ec53fdee5b)
In case U-Boot runs in EL3, which is the highest privilege level on ARM64,
there can be no firmware running that would restrict access to the bottom
128 MiB of DRAM. In fact, it is likely that U-Boot would have to load that
firmware into those bottom 128 MiB of DRAM and start that firmware.
Make those bottom 128 MiB of DRAM available in case U-Boot runs in EL3 to
allow loading the firmware to that area.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
(cherry picked from commit 6a32d5b54f)
Split common board code for R-Car Gen3 and Gen4 into separate files.
The R-Car Gen3 board code contains fixups specific to TFA which are
no longer required on R-Car Gen4, keep those fixups in its own file
so they would not interfere with Gen4.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
(cherry picked from commit cf096e7d73)
All R-Car Gen4 board files are copies of one another at this point.
Deduplicate them into single board/renesas/rcar-common/gen4-common.c
and remove all the duplicates. The one exception is R-Car V3U Falcon
board, which enables RWDT reset in board_init(), conditionally build
RWDT enablement in board_init() in the new common code for V3U.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
(cherry picked from commit caefe8a1b4)
Make the R-Car V3U stub PSCI implementation available on 64bit R-Car SoCs.
This implementation is useful during early board bring up, where it can
supplant missing fully-featured PSCI implementation. Note that this PSCI
implementation is very basic and offers only SoC reset functionality. It
is unable to enable or disable secondary CPU cores nor does it offer any
suspend/resume functionality.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
(cherry picked from commit 67440c8642)
Describe DBSC5 DRAM controller and RT-VRAM configuration interface
as two new DT nodes in R-Car Gen4 R8A779G0 U-Boot DT extras file.
This node is used by the U-Boot SPL for R8A779G0 SoC, where the
DBSC5 and RT-VRAM drivers bind to these nodes and bring up the
DRAM controller and RT-VRAM settings respectively, so U-Boot
proper can be loaded into DRAM and started on Cortex A76 core.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
(cherry picked from commit 94255316db)
Add Renesas R-Car Gen4 DBSC5 DRAM controller driver. This driver is currently
capable of bringing LPDDR5 DRAM on Renesas R-Car V4H Whitehawk board. Further
boards can be supported by supplying board specific DRAM configuration data
via dbsc5_get_board_data(). Support for R-Car V4M is not implemented, however
the driver is already mostly prepared to support this SoC.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
(cherry picked from commit 7366aacf8e)
Use the IS_ENABLED() macro to reduce amount of #ifdef use in the driver
and improve code coverage. With IS_ENABLED() macro, the code is compiled
and then optimized out, which prevents bitrot.
In case no PFC table matches the SoC in use, do not probe the driver
and instead exit with -ENODEV. This should never happen under normal
conditions, because this would mean the driver DT compatible string
match happened, but the list in probe() cannot match the model listed
in match data associated with the compatible string on which the match
did happen.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
(cherry picked from commit 476b886a6f)
This commit is empty because status_led.h is not present in ci/master.
The include ordering is already correct in this tree.
Signed-off-by: Simon Glass <simon.glass@canonical.com>
According to HTTP/1.0 standard the HTTP reply consist of
* Status Line + CRLF
* Zero or more Response Header Fields (each ended with CRLF)
* CRLF on new line (Response Header Fields end marker)
* Optional Entity Body.
Thus in response headers we state:
Content-Length = 30
but actual transferred file data is:
"\r\n<html><body>Hi</body></html>\r\n".
This is 32 bytes of data.
So we get and check for correctness 32 bytes of data, but
* The response we are used is incorrect, real server will
set Content-Length to 32.
* default_wget_info->hdr_cont_len will be set to wrong
value 30 (used for efi http booting).
Fix an issue by:
* replace bogus response with an actual response from the HTTP server
* format response to show HTTP response structure
* recalculate md5sum as transferred file data has been changed.
The server response was captured with the commands
echo -ne "<html><body>Hi</body></html>\n" > ~/public_html/test.html
echo -ne "GET /~${USER}/test.html HTTP/1.0\r\n\r\n" | netcat localhost 80 >reply.txt
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
(cherry picked from commit ece1631f5e)
The GW7905 was renamed to GW7500 before release. Change the various
names in the dt files and references.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
(cherry picked from commit aa233d26bd)
Reduce the PFC tables by ifdeffing out pinmux settings which are
unlikely to be used by U-Boot. This helps reduce the size of the
bootloader in the 10 kiB range. This includes conditional build
of these PFC additions:
- Audio
- CAN/CANFD
- INTC/INTC-EX
- MSIOF
- PWM
- SSI
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
(cherry picked from commit 545208247d)
Reduce the PFC tables by ifdeffing out pinmux settings which are
unlikely to be used by U-Boot. This helps reduce the size of the
bootloader in the 10 kiB range. This includes conditional build
of these PFC additions:
- Audio
- CAN/CANFD
- DU
- INTC-EX
- MSIOF
- PWM
- SSI
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
(cherry picked from commit a69f8cb9e2)
Reduce the PFC tables by ifdeffing out pinmux settings which are
unlikely to be used by U-Boot. This helps reduce the size of the
bootloader in the 10 kiB range. This includes conditional build
of these PFC additions:
- INTC-EX
- MSIOF
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
(cherry picked from commit 35c5ac0d53)
Reduce the PFC tables by ifdeffing out pinmux settings which are
unlikely to be used by U-Boot. This helps reduce the size of the
bootloader in the 10 kiB range. This includes conditional build
of these PFC additions:
- CAN/CANFD
- DU
- INTC-EX
- MSIOF
- PWM
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
(cherry picked from commit 15c51cc62d)
Reduce the PFC tables by ifdeffing out pinmux settings which are
unlikely to be used by U-Boot. This helps reduce the size of the
bootloader in the 10 kiB range. This includes conditional build
of these PFC additions:
- Audio
- CAN/CANFD
- DU
- MSIOF
- PWM
- SSI
- VIN
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
(cherry picked from commit 59c9ca0ba3)
Reduce the PFC tables by ifdeffing out pinmux settings which are
unlikely to be used by U-Boot. This helps reduce the size of the
bootloader in the 10 kiB range. This includes conditional build
of these PFC additions:
- Audio
- CAN/CANFD
- DU
- INTC/INTC-EX
- MSIOF
- PWM
- SSI
- VIN
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
(cherry picked from commit 1ee288a6aa)
Reduce the PFC tables by ifdeffing out pinmux settings which are
unlikely to be used by U-Boot. This helps reduce the size of the
bootloader in the 10 kiB range. This includes conditional build
of these PFC additions:
- CANFD
- DU
- INTC-EX
- MSIOF
- PWM
- VIN
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
(cherry picked from commit fa51edbab6)
Reduce the PFC tables by ifdeffing out pinmux settings which are
unlikely to be used by U-Boot. This helps reduce the size of the
bootloader in the 10 kiB range. This includes conditional build
of these PFC additions:
- CANFD
- DU
- INTC-EX
- MSIOF
- PWM
- VIN
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
(cherry picked from commit a046f58f33)
Reduce the PFC tables by ifdeffing out pinmux settings which are
unlikely to be used by U-Boot. This helps reduce the size of the
bootloader in the 10 kiB range. This includes conditional build
of these PFC additions:
- Audio
- CAN/CANFD
- DU
- INTC-EX
- MSIOF
- PWM
- SSI
- VIN
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
(cherry picked from commit d020179cf0)
Reduce the PFC tables by ifdeffing out pinmux settings which are
unlikely to be used by U-Boot. This helps reduce the size of the
bootloader in the 10 kiB range. This includes conditional build
of these PFC additions:
- Audio
- CAN/CANFD
- DU
- INTC-EX
- MSIOF
- PWM
- SSI
- VIN
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
(cherry picked from commit 0edacf1a41)
Reduce the PFC tables by ifdeffing out pinmux settings which are
unlikely to be used by U-Boot. This helps reduce the size of the
bootloader in the 10 kiB range. This includes conditional build
of these PFC additions:
- Audio
- CAN/CANFD
- DU
- INTC-EX
- MSIOF
- PWM
- SSI
- VIN
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
(cherry picked from commit 2890251ead)
Reduce the PFC tables by ifdeffing out pinmux settings which are
unlikely to be used by U-Boot. This helps reduce the size of the
bootloader in the 10 kiB range. This includes conditional build
of these PFC additions:
- Audio
- CAN
- DU
- INTC
- MSIOF
- PWM
- SSI
- VIN
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
(cherry picked from commit 7f19150405)
Reduce the PFC tables by ifdeffing out pinmux settings which are
unlikely to be used by U-Boot. This helps reduce the size of the
bootloader in the 10 kiB range. This includes conditional build
of these PFC additions:
- CAN
- DU
- INTC
- MSIOF
- VIN
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
(cherry picked from commit 7db1d1fadf)
Reduce the PFC tables by ifdeffing out pinmux settings which are
unlikely to be used by U-Boot. This helps reduce the size of the
bootloader in the 10 kiB range. This includes conditional build
of these PFC additions:
- Audio
- CAN
- DU
- INTC
- MSIOF
- PWM
- SSI
- VIN
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
(cherry picked from commit 6671e9aebd)
Reduce the PFC tables by ifdeffing out pinmux settings which are
unlikely to be used by U-Boot. This helps reduce the size of the
bootloader in the 10 kiB range. This includes conditional build
of these PFC additions:
- Audio
- CAN
- DU
- INTC
- MSIOF
- PWM
- SSI
- VIN
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
(cherry picked from commit 2f3bd7ca26)
By default the pin multiplexing tables used by U-Boot are reduced
to keep the size of the bootloader low. This option allows build of
full pin multiplexing tables the same way they are included in the
Linux kernel. This includes pin multiplexing options for Audio, CAN,
CANFD, DU, INTC, INTC-EX, MSIOF, PWM, SSI, for which there is no
U-Boot driver. This option is disabled by default.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
(cherry picked from commit e6e3d70632)
CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/23987
- imx8m: Remove global ddrphy_trained_csr as it is a per board
configuration.
- Add DM_FLAG_ACTIVE_DMA flag for FEC network driver to avoid potential
kernel crash.
- Miscellaneous improvements for i.MX8M Venice Gateworks platforms.
(cherry picked from commit 68736cf8e3)
Drop global ddrphy_trained_csr which maybe different with per board
ddrphy_trained_csr. DDR TOOL generates ddrphy_trained_csr for each
board, using the global ddrphy_trained_csr has risk that values may
be not up to date.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
(cherry picked from commit 6016960ceb)
When FEC network card works as the prime one in u-boot, and is in
active status, kernel might crash during booting up stage, especially
working with grub. Because the DMA of FEC is still in active status, and
copy data into memory if there is network data received. In this case, if
kernel allocated a part of memory that has overlay with the memory
used by DMA, kernel memory may be destroyed and cause kernel crashes.
Because before kernel boots up really, u-boot dm_remove_devices_flags()
can call the remove callback of FEC driver with DM_FLAG_ACTIVE_DMA
flag. In fecmxc_remove(), phy power is disabled, so there is no data
received. In this way, it makes sure that there is no DMA action, so
that avoid kernel crashing occurs.
Signed-off-by: Meng Li <Meng.Li@windriver.com>
(cherry picked from commit 2f74cac8c3)
With an IMX8MP based SOM the SPI RST is gpio4_9 instead of gpio1_11.
Fix this.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
(cherry picked from commit 7f02219eb6)
define a suitable default address for CONFIG_SPL_LOAD_FIT_ADDRESS
to make it easier on folks enabling HABv4.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
(cherry picked from commit b0b8f8586f)
Add support for Gateworks System Controller pre-scaled ADC input.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
(cherry picked from commit 87bdb4e8a7)
The mxc_get_clock function is around for compatibility with older
drivers that are not clock aware. In this case asking for the clk for
MXC_CSPI_CLK does not take into account there are multiple SPI busses on
modern IMX SoC's and it will return the clock for the first bus which
may not be used or configured.
In the case you are not using the first bus you will not get the proper
clock. Fix this by obtaining the clock rate from the bus clock.
This resolves an invalid SPI clock frequency configuration for SPI2 on a
board where SPI1 is not used.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
(cherry picked from commit f331967b3d)
First, thanks to Simon Glass and also Linaro, we now have access to a
few fast arm64 host machines in our Gitlab instance, to use as CI
runners. This series finishes the work that I pushed earlier and Simon
had started that enables arm64 hosts to be used for most things now.
The first notable change, especially if you use this on your own Gitlab
instance is that "DEFAULT_TAG" is now unused and we instead have:
- DEFAULT_ALL_TAG:
- DEFAULT_ARM64_TAG:
- DEFAULT_AMD64_TAG:
- DEFAULT_FAST_AMD64_TAG:
This lets us say that some jobs can be run on all runners, because they
are small enough that anything we'd connect to CI is fast enough and it
also does not depend on the underlying host architecture. Next we have
tags for any arm64 host, or any amd64 host. Finally, we have a tag for
fast amd64 hosts. What these last three are for is that we have a few
jobs that need to run on amd64 hosts and so we have to restrict them
there, but we also have now reworked the world build jobs to build
(almost) everything in a single job and on the fast amd64 machines this
is still as quick as the old way was, in practice.
To reach this point, we say that the Xtensa jobs can only run on amd64
hosts. Our targets only work with the binary-only toolchain and so this
is a reasonable limit and we exclude them from the world build jobs. We
also need to deal with ensuring the right toolchain is used regardless
what the host architecture is and that we don't use the host toolchain
by accident. Finally, because some of these changes needed to be worked
out in the linter, fix some of the general warnings that notes as well.
(cherry picked from commit 5947cd76ac)
Dropped tag changes:
Signed-off-by: Simon Glass <simon.glass@canonical.com>
First, try and be slightly clearer about what "buildx" is with respect
to the docker build process.
Second, now that we build the container for both amd64 and arm64, we
should document how to make a docker "builder" that has multiple nodes.
With this one node should be amd64 and one node arm64, and with
reasonably fast arm64 hardware this will be much quicker than using
QEMU.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
(cherry picked from commit e82922ae11)
We should always look in our downloaded toolchains first and then for
host-provided toolchains.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
(cherry picked from commit 9a87362962)
In the test.py stage of the build we mark the pytest results as
artifacts to save, so that they can be used for reports. This however
leads to all of the artifacts being downloaded (and then not used) in
later stages. Optimize this out by using an empty list of dependencies
here (which is the keyword for which artifacts are needed).
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
(cherry picked from commit d3bb245855)
The xtensa architecture is interesting in that the platforms we support
are only valid on the binary-only toolchains as the DC233C instruction
set requires those toolchains (and not the FSF instruction set). Only
install the binary toolchain on amd64 hosts and only run the tests on
them as well.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
(cherry picked from commit 12d7be498a)
For new PowerPC developments, it will be useful to borrow devicetrees
from Linux. This patch makes it possible.
Signed-off-by: J. Neuschäfer <j.ne@posteo.net>
Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
(cherry picked from commit 337bfdce5a)
In generic_phy_get_bulk(), if 'phys' property is absent in
the device node then it is not an error condition.
Change print message verbosity to debug to avoid spamming
console in such cases.
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Reviewed-by: Siddharth Vadapalli <s-vadapalli@ti.com>
(cherry picked from commit 6f99dc241d)
The current value of CONFIG_FASTBOOT_BUF_ADDR is incorrect for hardware
with 512MB and 1GB of RAM. The RAM address ranges for these devices are:
- 512MB:
- Start: 0x80000000
- End: 0xA0000000
- 1GB:
- Start: 0x80000000
- End: 0xC0000000
The current buffer address makes fastboot downloads work only on
hardware with 2GB of RAM.
To fix this issue:
1. Lower CONFIG_FASTBOOT_BUF_ADDR to 0x88200000. This makes the buffer
to be equal ot CONFIG_SYS_LOAD_ADDR, which is a safe address to
download files using fastboot.
2. Reduce the size of the download buffer to 128MB, avoiding overlaps
with RAMDISK_ADDR_R. This is a good enough value for individual
downloads.
These changes make fastboot downloads work with 512MB and 1GB devices.
Fixes: defe30a78b ("verdin-am62: add DFU, USB and UUU fastboot support")
Signed-off-by: Hiago De Franco <hiago.franco@toradex.com>
Acked-by: Francesco Dolcini <francesco.dolcini@toradex.com>
(cherry picked from commit 9c5399a73d)
Support of legacy 64-bit entry point was already present when booting a bzimage
with 'zboot' but not supported with 'bootm' when the x86_64 Linux kernel is
embedded in a FIT image.
Signed-off-by: Paul HENRYS <paul.henrys_ext@softathome.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
(cherry picked from commit 37f0c32ca2)
Evgeny Bachinin <EABachinin@salutedevices.com> says:
This patch-set repairs ability to use sandbox with CONFIG_OF_EMBED=y.
For now, to use OF_EMBED, the following must be done
1) sandbox64_defconfig should have:
```
-CONFIG_OF_LIVE=y
+CONFIG_OF_EMBED=y
```
2) On sandbox when CONFIG_OF_EMBED=y, the u-boot process can't start
due to:
```
Bloblist at b000 not found (err=-2)
initcall failed at call 000000000011829c (err=-2: No such file or \
directory)
### ERROR ### Please RESET the board ###
```
So, it is natural desire to disable CONFIG_BLOBLIST just to test
sandbox with OF_EMBED=y (disable it one way or another):
```
config SANDBOX
- select BLOBLIST
+ select BLOBLIST if SOME_NON_EXISTING_OPTION
```
3) As a result, having such changes (CONFIG_OF_EMBED=y &&
CONFIG_BLOBLIST=n) leads to the link & run-time errors, being fixed
by this patch series.
Link: https://lore.kernel.org/r/20241202-sandbox_repair_of_embed-v1-0-05aff4b0ccf7@salutedevices.com
[trini: The final patch is dropped as no longer relevant with Simon's
rework to that function which is now applied.]
(cherry picked from commit 511b8dea97)
This series is from Simon Glass <sjg@chromium.org>.
It first corrects the test for checking if a bloblist could have come
from TPL and so we check for a device tree, and then changes the
argument order for board_fdt_blob_setup() to be more inline with our
usual argument ordering.
Link: https://lore.kernel.org/r/20241102174944.412088-1-sjg@chromium.org
(cherry picked from commit b6e1ac89dc)
Having CONFIG_OF_EMBED=y && CONFIG_BLOBLIST=n leads to the link
error:
```
ld: /tmp/ccRVty.ltrans40.ltrans.o: in function `lib_test_is_enabled':
test/lib/kconfig.c:24: undefined reference to \
`invalid_use_of_IF_ENABLED_INT'
ld: test/lib/kconfig.c:26: undefined reference to \
`invalid_use_of_CONFIG_IF_ENABLED_INT'
```
Fixes: 29784d62ed ("test: Add some tests for kconfig.h")
Signed-off-by: Evgeny Bachinin <EABachinin@salutedevices.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
(cherry picked from commit 844f87366e)
