| Age | Commit message (Collapse) | Author |
|---|
|
Make hexdump.h work in host-tool builds by using 'uint8_t' instead
of 'u8', and including either user-space libc <ctype.h> for host-tools
or <linux/ctype.h> when building U-Boot itself.
Signed-off-by: Daniel Golle <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Add fit_verity_build_cmdline(): when a FILESYSTEM loadable carries a
dm-verity subnode, construct the dm-mod.create= kernel cmdline parameter
from the verity metadata (block-size, data-blocks, algo, root-hash,
salt) and append it to bootargs.
Also add dm-mod.waitfor=/dev/fit0[,/dev/fitN] for each dm-verity device
so the kernel waits for the underlying FIT block device to appear before
setting up device-mapper targets. This is needed when the block driver
probes late, e.g. because it depends on NVMEM calibration data.
The dm-verity target references /dev/fitN where N is the loadable's
index in the configuration -- matching the order Linux's FIT block
driver assigns block devices. hash-start-block is read directly from
the FIT dm-verity node; mkimage ensures its value equals num-data-blocks
by invoking veritysetup with --no-superblock.
Signed-off-by: Daniel Golle <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-stm
CI: https://source.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/30256
- Add support dynamic A/B bank bootup for STM32MP15
- Increase SYS_MALLOC_F_LEN for stm32mp15_defconfig to fix boot with optee-4.10.0
- Enable Arm SMC watchdog for STM32MP1
- Update part number for TM32MP251/3 SoC's family
|
|
update part number for STM32MP251/3 for last cut revision.
Signed-off-by: Patrice Chotard <[email protected]>
Reviewed-by: Patrick Delaunay <[email protected]>
|
|
For this configuration, the watchdog (iwdg1) is secured and managed by
OP-TEE. Add an watchdog node with arm,smc-wdt compatible, and disable
iwdg2 node which is then no more used.
Signed-off-by: Yann Gautier <[email protected]>
Reviewed-by: Patrice Chotard <[email protected]>
|
|
No watchdog was enabled for STM32MP13 platform. Add the required flags to
support it. As done for STM32MP15 (in SCMI config) and STM32MP2x, we use
the Arm SMC watchdog. The required nodes were already present in Linux
imported DT files (stm32mp13.dtsi & stm32mp135f-dk.dts).
To enable this SMC watchdog on other platforms based on STM32MP13, check
that both the following flags are enabled in the dedicated config file:
CONFIG_WDT=y
CONFIG_WDT_ARM_SMC=y
And that there is a node in Linux board DT that enables the feature, as
it is done in stm32mp135f-dk.dts:
&arm_wdt {
timeout-sec = <32>;
status = "okay";
};
Signed-off-by: Patrick Delaunay <[email protected]>
Signed-off-by: Yann Gautier <[email protected]>
Reviewed-by: Patrice Chotard <[email protected]>
|
|
Enable the arm watchdog over SMC driver. This allows using a secure
watchdog, based on IWDG1 peripheral and managed by OP-TEE.
The driver will be probed if a watchdog node with "arm,smc-wdt"
compatible is enabled.
Signed-off-by: Lionel Debieve <[email protected]>
Signed-off-by: Yann Gautier <[email protected]>
Reviewed-by: Patrice Chotard <[email protected]>
|
|
Using stm32mp15_defconfig with stm32mp157c-dk2-scmi.dtsi device tree
with optee-4.10.0, we got:
U-Boot 2026.07-rc2-00052-g215496fec59b (May 18 2026 - 15:05:34 +0200)
CPU: STM32MP157CAC Rev.B
Model: STMicroelectronics STM32MP157C-DK2 SCMI Discovery Board
Board: stm32mp1 in trusted mode (st,stm32mp157c-dk2-scmi)
alloc space exhausted ptr 80060 limit 80000
optee optee: PTA_BSEC invoke failed TEE err: 0, err:fffffff4
alloc space exhausted ptr 80040 limit 80000
alloc space exhausted ptr 80020 limit 80000
DRAM: alloc space exhausted ptr 80040 limit 80000
RAM init failed: -12
initcall_run_f(): initcall dram_init() failed
CONFIG_SYS_MALLOC_F_LEN need to be increased to fix this issue
Reported-by: Yann Gautier <[email protected]>
Signed-off-by: Patrice Chotard <[email protected]>
Reviewed-by: Patrick Delaunay <[email protected]>
|
|
Factorize FWU multi-bank support code common to STM32MP1 and
STM32MP2 platforms into a dedicated shared source file.
No functional change intended.
Signed-off-by: Dario Binacchi <[email protected]>
Reviewed-by: Patrice Chotard <[email protected]>
|
|
Following commit 4300f9f4c5d7 ("board: st: stm32mp25: support dynamic
A/B bank bootup"), this patch enables automatic detection of the active
A/B bank on STM32MP15 platforms by retrieving partition GUIDs from FWU
metadata.
This ensures the system correctly identifies the bootable partitions
even in multi-bank scenarios, falling back to a standard bootable flag
scan if the UUIDs are missing.
To enable A/B bank bootup on STM32MP15 boards, add the following Kconfig
options to the stm32mp15[_basic]_defconfig:
CONFIG_FWU_MULTI_BANK_UPDATE=y
CONFIG_FWU_MDATA=y
CONFIG_FWU_NUM_BANKS=2
CONFIG_FWU_NUM_IMAGES_PER_BANK=3
CONFIG_CMD_FWU_METADATA=y
CONFIG_FWU_MDATA_V2=y
Signed-off-by: Dario Binacchi <[email protected]>
Reviewed-by: Patrice Chotard <[email protected]>
|
|
The bcm2835 SDHCI driver sets up the MMC host configuration via
sdhci_setup_cfg(), but does not parse generic MMC device tree
properties.
As a result, properties such as bus-width are ignored. On Raspberry Pi
Compute Module 4, the eMMC node describes an 8-bit bus, but U-Boot
initialized the device as 4-bit.
Call mmc_of_parse() before sdhci_setup_cfg() so that generic MMC
properties are folded into the host configuration before the MMC core
selects the bus width.
Before this change, mmc info reported:
Bus Speed: 52000000
Bus Width: 4-bit
After this change, mmc info reports:
Bus Speed: 52000000
Bus Width: 8-bit
Tested on Raspberry Pi Compute Module 4 with onboard eMMC.
Signed-off-by: Liel Harel <[email protected]>
Reviewed-by: Peter Robinson <[email protected]>
Tested-by: Peter Robinson <[email protected]> # on the CM4 as well
|
|
Enable LWIP and HTTPS on the Raspberry Pi arm64 platform to be able to
use it in the boot process.
Signed-off-by: Peter Robinson <[email protected]>
Reviewed-by: Matthias Brugger <[email protected]>
|
|
The 'brcm,bcm2712-hdmi0' compatible string is used on RPi5.
There appears to be no change that impacts early boot output
on the display controller so add the RPi5 compatible string.
Signed-off-by: Peter Robinson <[email protected]>
Reviewed-by: Matthias Brugger <[email protected]>
|
|
This series from James Hilliard <[email protected]> converts the
static flags list for the environment to be configured via Kconfig and
updates the documentation.
Link: https://lore.kernel.org/r/[email protected]
|
|
The remaining configuration settings section is legacy README content.
Its details belong in Kconfig help or the rST documentation.
Remove the section instead of keeping partial stale configuration
documentation in README.
Suggested-by: Tom Rini <[email protected]>
Signed-off-by: James Hilliard <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Environment callbacks can already be configured from Kconfig with
CONFIG_ENV_CALLBACK_LIST_STATIC, but static environment flags still
require board headers to define CFG_ENV_FLAGS_LIST_STATIC.
Add CONFIG_ENV_FLAGS_LIST_STATIC and use it as the only board-provided
static environment flags list. Convert the remaining default-config users
from CFG_ENV_FLAGS_LIST_STATIC to defconfig settings and drop the legacy
header macro from ENV_FLAGS_LIST_STATIC.
Move the environment flags format documentation out of README and into
the developer environment documentation. Include the format in the
Kconfig help as well.
This lets boards configure writeable-list policy and type validation
from defconfig without adding a config header solely for env flags.
This preserves the behavior of default configs. Header-only cases that
were inactive in upstream defconfigs are not converted into defconfig
entries: iot2050 can add its list when enabling ENV_WRITEABLE_LIST, and
smegw01 can add mmcdev:dw support if the unlocked SYS_BOOT_LOCKED=n
configuration is needed.
Signed-off-by: James Hilliard <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Alexander Sverdlin <[email protected]>
Reviewed-by: Walter Schweizer <[email protected]>
|
|
Aristo Chen <[email protected]> says:
This series ends with replacing the verbose fdt_next_node() + ndepth
idiom in boot/image-fit.c with fdt_for_each_subnode(), bringing the
file in line with boot/image-fit-sig.c. Six of the seven sites in
image-fit.c predate the macro by 2-6 years; the seventh was
copy-pasted from a neighbour in 2015 just after the macro landed.
The old idiom is legacy, not a deliberate technical choice.
Converting straight to the macro turned out to need a prerequisite,
which is patch 1. fit_print_contents() reads the default-config
property using the loop variable left over after iterating /images
children. With /images defined first in the source (the conventional
layout) libfdt's walker happens to leave that variable pointing at
/configurations and the read works. With /configurations defined
first the read returns NULL and the "Default Configuration" line is
silently omitted. fdt_for_each_subnode()'s post-loop value is
unconditionally a negative error code, so a naive conversion would
have made the missing line the unconditional behaviour. Patch 1
reads the property from confs_noffset directly and removes the
layout dependency.
Patch 2 adds a regression test for the configs-before-images
layout, which had no coverage.
Patch 3 is the mechanical conversion at all seven sites,
equivalence-preserving as described in the per-patch message.
Link: https://lore.kernel.org/r/[email protected]
|
|
Replace the verbose fdt_next_node() + ndepth pattern with the
fdt_for_each_subnode() macro at all seven sites in boot/image-fit.c
where the loop only ever processes direct children. The macro is
already defined in <linux/libfdt.h> and used in boot/image-fit-sig.c,
so this brings image-fit.c in line with the rest of the FIT code.
The conversions are equivalence-preserving:
- fit_get_subimage_count(): the depth-1 filter and the macro are
both restricted to direct children.
- fit_conf_print(): the parameter is named noffset, so the loop
now uses sub_noffset to keep the parent reference stable.
- fit_print_contents(): the count reset that lived inside the for
initialiser is moved out as an explicit assignment before each
loop, so the second loop still starts from zero.
- fit_image_print(): straightforward replacement.
- fit_all_image_verify(): same shape as the print loops, with the
count reset moved out as an explicit assignment before the loop.
- fit_conf_find_compat(): the body's "if (ndepth > 1) continue"
guard is redundant once the macro is in use, and is dropped.
No behaviour changes outside of these mechanical reductions. Local
ndepth declarations that are no longer referenced are removed.
Signed-off-by: Aristo Chen <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Add a test that builds a FIT whose /configurations node is defined
before /images in the source, runs iminfo, and asserts that the
"Default Configuration: '<name>'" line appears in the output.
Before the fix in the preceding commit ("boot/fit: read default-config
property from the configurations node"), fit_print_contents() read the
default-config property using the loop variable left over from iterating
/images children. With /images defined first that variable accidentally
pointed at /configurations and the line printed correctly; with
/configurations defined first the read returned NULL and the line was
silently omitted. The new test exercises the latter layout, which had
no coverage.
iminfo and the fit_print_contents() path had no test coverage at all
before this commit.
Signed-off-by: Aristo Chen <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
In fit_print_contents() the default configuration's unit name is read by
calling fdt_getprop() with noffset rather than confs_noffset. Today this
happens to work by coincidence: the preceding loop walks /images using
fdt_next_node(), and when iteration leaves the subtree libfdt returns
the offset of the next sibling in DFS order, which by FIT layout
convention is /configurations. The depth counter then drops below zero
and the loop exits with noffset still pointing at /configurations.
This relies on /images and /configurations being adjacent siblings and
on the implementation detail of fdt_next_node()'s post-exhaustion
return value. It also blocks a follow-up conversion to
fdt_for_each_subnode(), whose post-loop loop variable is a negative
error code rather than a valid offset.
Use confs_noffset directly, which the comment immediately above the
call already names as the source.
Signed-off-by: Aristo Chen <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Sync include/ec_commands.h from upstream commit 4f3d17aa34
("skywalker: set SLEEP_TIMEOUT_MS to 50 seconds"). The new file makes
two build assumptions that do not hold for U-Boot.
It hides '<stdint.h>' from __KERNEL__ builds, leaving UINT16_MAX
(used by EC_RES_MAX) undefined for U-Boot; widen the gate to
'!defined(__KERNEL__) || defined(__UBOOT__)'
It gates '<linux/limits.h>' on '#ifdef __KERNEL__'; the matching
'#else' branch defines BIT()/BIT_ULL()/GENMASK()/GENMASK_ULL()
locally, assuming kernel headers provide those macros otherwise.
U-Boot defines __KERNEL__ too but has no <linux/limits.h>. Nest a
'!defined(__UBOOT__)' check around the include so the __UBOOT__ path
stays in the __KERNEL__ branch (no local BIT/GENMASK defines), which
avoids redefinition warnings against U-Boot's linux/bitops.h. Pull
in linux/bitops.h up front for U-Boot so the file's own BIT() and
GENMASK() uses still resolve.
Adapt callers to two interface changes. The 'ec_current_image' enum
tag is now 'ec_image' (EC_IMAGE_* constants unchanged); rename it in
affected files to match. The VBNV-context interface was dropped
upstream, but it still used in lab Chromebooks; keep those constants and
structs in cros_ec.h
Likewise, MEC_EMI_BASE and MEC_EMI_SIZE are a U-Boot-local addition to
ec_commands.h that the upstream sync removes; preserve them in cros_ec.h
next to the VBNV block, and switch the only consumer
(arch/x86/cpu/apollolake/cpu_spl.c) to include cros_ec.h
Signed-off-by: Simon Glass <[email protected]>
|
|
If the LED is in the ON state, it is briefly set to OFF
then to ON immediately due to falling-through in the default
case.
This commit ensures that no fall-through occurs and thus
a LED initially in the ON state is turned off before blinking.
Signed-off-by: Francois Berder <[email protected]>
Fixes: 9e3d83301e4f ("led: toggle LED on initial SW blink")
Acked-by: Quentin Schulz <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
gpio status -a does not have labels: the existing path walks
the per-bank requested label table.
Issue: The boards that populate the standard gpio-line-names
property in their device tree end up with anonymous entries,
which is not logic with the purpose of having those names in the DT.
No impact with boards that does not set gpio-line-names.
Signed-off-by: Vincent Jardin <[email protected]>
|
|
test_fs/test_erofs.py and test_fs/test_squashfs/sqfs_common.py both
defined a generate_file() helper that writes a file of a given size
filled with 'x'. The two functions were functionally identical and
differed only in parameter names and docstrings.
Move the helper into the existing test/py/utils.py module, which is
the established home for generic test utilities (md5sum_file,
PersistentRandomFile, attempt_to_open_file). Update both call sites
to use it.
Signed-off-by: Aristo Chen <[email protected]>
Reviewed-by: [email protected]
Reviewed-by: Simon Glass <[email protected]>
|
|
Prepare v2026.07-rc3
|
|
Signed-off-by: Tom Rini <[email protected]>
|
|
A file like rm-cfg.yaml accidentally left in the source tree root
shadows the board-specific copy. binman builds the wrong YAML, the
resulting rm-cfg.bin may match a different SoC, and we end up with
the following error:
k3_system_controller sysctrler: k3_sysctrler_start:
Boot Notification response failed. ret = -110
Move the board directory ahead of the srctree root so that the
most-specific match wins.
Signed-off-by: Wadim Egorov <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-microblaze
AMD/Xilinx/FPGA changes for v2026.07-rc3
versal/fpga:
- Fix unaligned buffer handling
versal2:
- Fix buffer overflow in SOC name array
|
|
Resync all defconfig files using qconfig.py
Signed-off-by: Tom Rini <[email protected]>
|
|
Our official domain is now u-boot-project.org, so update all in-tree
references to use the correct domain.
Reviewed-by: Tony Dinh <[email protected]>
Reviewed-by: Peter Robinson <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
Anshul Dalal <[email protected]> says:
This patch series fixes firewall exceptions observed on AM62 family of
devices due to speculative accesses made by the A53 core to secure DDR
regions.
Link: https://lore.kernel.org/r/[email protected]
|
|
Currently the sequence to enable caches for the A53/A72 core on K3
devices looks as follows:
1. Map entire DDR banks
2. Setup page tables (done by mmu_setup)
3. Enable MMU
4. Unmap reserved-memory regions
5. Enable caches
However there is a brief period of execution between #3 and #4 where the
core can issue speculative accesses to the entire DDR space (including
the reserved-memory regions) despite the caches being disabled.
A firewall exception is triggered whenever such speculative access is
made to secure DDR region of TFA or OP-TEE. This patch fixes the issue
by re-ordering the sequence as follows:
1. Map entire DDR banks
2. Setup page tables
3. Unmap reserved-memory regions
4. Enable MMU
5. Enable caches
Fixes: f1c694b8fdde ("mach-k3: map all banks using mem_map_from_dram_banks")
Reported-by: Suhaas Joshi <[email protected]>
Signed-off-by: Anshul Dalal <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
Currently mmu_setup for ARMv8 performs two functions, first it sets up
the page tables based the memory map provided by the board and then it
enables the MMU.
However for some platforms runtime fixes to the generated page tables
are required before the MMU can be enabled, such as K3 family of SoCs.
Therefore this patch moves the enablement of the MMU out of mmu_setup
and to a standalone mmu_enable function to give more granular control to
the platforms.
Note that no functional changes are intended from this patch.
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Anshul Dalal <[email protected]>
|
|
babae80169d removed bootm_size from ti_common.env to allow K3 boards
to process images larger than 256MB, but preserved it in
ti_armv7_keystone2.env for ARMv7 Keystone2 boards. AM57xx (also ARMv7)
was not covered by that preservation.
Without bootm_size, env_get_bootm_size() falls back to gd->ram_size,
causing initrd_high to be computed as the top of all RAM. On ARM32
boards with more RAM than the DMA zone (e.g. AM572x IDK with 2GiB),
this places the ramdisk above 0xafe00000 (HighMem), which is not
directly accessible by the kernel after MMU setup, causing a silent
crash.
With bootm_size=0x10000000, initrd_high is constrained to
0x80000000 + 0x10000000 = 0x90000000, keeping the ramdisk in the
DMA zone and allowing the kernel to access it correctly.
Fixes: babae80169dd ("include: env: ti_common: remove bootm_size")
Reviewed-by: Neha Malcom Francis <[email protected]>
Signed-off-by: Moteen Shah <[email protected]>
|
|
The size of name buffer was not computed correctly.
The suffix format is "--rel.-el" (9 chars instead of 6),
and the longest platform name is "emu-mmd" (7 chars instead of 4).
Fix comment and name size.
Fixes: 40f5046c221a ("arm64: versal2: Add support for AMD Versal Gen 2")
Signed-off-by: Francois Berder <[email protected]>
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/BESP194MB280513B376D54A815F3FD507DA0E2@BESP194MB2805.EURP194.PROD.OUTLOOK.COM
|
|
When fpga load is called with a misaligned buffer address, the
versal_align_dma_buffer() function shifts the pointer forward to the
next aligned boundary and uses memcpy() to copy the data. Since the
destination is ahead of the source and the regions overlap, memcpy()
produces undefined behavior; in practice U-Boot's generic memcpy()
copies forward, repeating the first ARCH_DMA_MINALIGN-aligned chunk
throughout the buffer.
Replace memcpy() with memmove() which correctly handles overlapping
regions by copying backwards when the destination is ahead of the
source.
Fixes: 26e054c943a7 ("arm64: versal: fpga: Add PL bit stream load support")
Signed-off-by: Pranav Tilak <[email protected]>
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Daniel Palmer <[email protected]> says:
Lets start making the m68k virt machine support useful.
First we need to fix some m68k endian issues.
Then allow virtio mmio driver instances to be created with
platform data and fix a minor endian issue.
Finally, add the code for the board to create the instances.
Link: https://lore.kernel.org/r/[email protected]
|
|
So that you can use virtio network, block etc create the virtio mmio
instances. There are 128 of these even if they are not all used, a
single mmio base value is passed via bootinfo.
Reviewed-by: Angelo Dureghello <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Kuan-Wei Chiu <[email protected]>
Tested-by: Kuan-Wei Chiu <[email protected]>
Signed-off-by: Daniel Palmer <[email protected]>
|
|
Currently we are trying to work out if the vendor id is from
a virtio-mmio device and then casting a u32 to a char* and using
it as a C-string. By chance there is usually a zero after the u32
and it works.
Since the vendor id we are trying to convert to a string is QEMU's
just define a value for the QEMU vendor id, check if the vendor
id matches and then use a predefined string for "QEMU".
I don't think we should have been assumming all virtio-mmio vendor
ids are printable ASCII chars in the first place so do this special
casing just for QEMU. If the vendor id isn't QEMU print the hex
value of it.
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Kuan-Wei Chiu <[email protected]>
Signed-off-by: Daniel Palmer <[email protected]>
|
|
The virtio command is calling virtio blk functions but currently
depends on CONFIG_VIRTIO only. This means disabling CONFIG_VIRTIO_BLK
causes the final link to fail.
Since CONFIG_VIRTIO_BLK depends on CONFIG_VIRTIO switch to depending
on just CONFIG_VIRTIO_BLK
Reviewed-by: Kuan-Wei Chiu <[email protected]>
Reviewed-by: Angelo Dureghello <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Daniel Palmer <[email protected]>
|
|
The m68k QEMU virt machine doesn't use devicetree, yet, so
allow it to create virtio-mmio instances via platform data.
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Kuan-Wei Chiu <[email protected]>
Reviewed-by: Angelo Dureghello <[email protected]>
Signed-off-by: Daniel Palmer <[email protected]>
|
|
In Linux these are meant to read a little-endian value and swap
to the CPU endian.
In u-boot for m68k this is currently broken and prevents
virtio-mmio from functioning.
This change is only for classic m68k. Coldfire has read big-endian,
no swap for these in u-boot and Linux and existing drivers probably
depend on this.
Tested-by: Angelo Dureghello <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Acked-by: Kuan-Wei Chiu <[email protected]>
Acked-by: Angelo Dureghello <[email protected]>
Signed-off-by: Daniel Palmer <[email protected]>
|
|
The Goldfish timer registers are native endian, so they act as
big-endian on the m68k virt machine. Currently, this driver uses
readl(), which works by luck because it's currently broken on m68k.
Use __raw_readl() instead to avoid breaking this driver when the
endianness of readl() is fixed.
Signed-off-by: Kuan-Wei Chiu <[email protected]>
Tested-by: Daniel Palmer <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Daniel Palmer <[email protected]>
|
|
In QEMU, the Goldfish RTC is explicitly instantiated as a big-endian
device on the m68k virt machine (via the 'big-endian=true' property).
Currently, this driver uses ioread32() and iowrite32(), which works
by luck because the underlying readl() and writel() are currently
broken on m68k.
Use __raw_readl() and __raw_writel() instead to avoid breaking this
driver when the endianness of readl() and writel() is fixed.
Signed-off-by: Kuan-Wei Chiu <[email protected]>
Tested-by: Daniel Palmer <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Daniel Palmer <[email protected]>
|
|
The virt ctrl register seems to be native endian, currently this driver
uses writel(), which works by luck because its currently broken on m68k.
Use __raw_writel() instead to avoid breaking this driver when the
endianness of writel() is fixed.
Acked-by: Kuan-Wei Chiu <[email protected]>
Reviewed-by: Angelo Dureghello <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Daniel Palmer <[email protected]>
|
|
In the platform data there is a phys_addr_t (an integer) for the address
of the register and we pass that as-is into writel() which is fine in most
places because we don't need to do any mapping and the macro for writel()
does a cast to a pointer.
If writel() is a static inline function the address argument is a pointer
so passing it in as an integer without casting it first causes warnings or
build failure.
map_sysmem() handles the casting part and if phys_addr_t is 32bits when
on a 64bit machine.
Signed-off-by: Daniel Palmer <[email protected]>
Acked-by: Kuan-Wei Chiu <[email protected]>
|
|
This is Renesas R-Car X5H support for U-Boot on its RSIP Cortex-M33 core
in addition to already support U-Boot on Cortex-A720AE core. The first
two patches also switch X5H to OF_UPSTREAM.
|
|
Add support for building U-Boot for Cortex-M33 RSIP core in Renesas
R-Car Gen5 R8A78000 X5H SoC. The main goal is to start U-Boot on the
Cortex-M33 RSIP core, which initializes the hardware and then starts
the Cortex-M33 SCP and Cortex-A720 cores which run the SCP firmware
and applications software respectively. The SCP is responsible for
platform resource management, and is used to start other CPU cores.
The Cortex-M33 build contains its own r8a78000_ironhide_cm33_defconfig
which configures the build for aarch32 instruction set compatible with
the ARMv8M core. The build also uses -cm33 DT and -u-boot.dtsi which
are derived from their non-CM33 counterparts, and add CM33 specifics.
The arch/arm/mach-renesas/u-boot-rsip.lds is derived from generic
arch/arm/cpu/u-boot.lds with adjustments to cater to the RSIP core,
those are entrypoint before vectors, __data_start/__data_end symbols
for data-only relocation, and placement of BSS into read-write SRAM
area.
Signed-off-by: Marek Vasut <[email protected]>
|
|
Add target to generate u-boot-elf.shdr for R-Car Gen5 Cortex-M33
RSIP core. The resulting .shdr SREC file can be written into the
HF at offset 0.
Signed-off-by: Marek Vasut <[email protected]>
|
|
Add target to generate u-boot-elf.scif for R-Car Gen5 Cortex-M33
RSIP core. The resulting .scif SREC file can be loaded using the
SCIF loader to start U-Boot on the RSIP core.
Signed-off-by: Marek Vasut <[email protected]>
|
