| Age | Commit message (Collapse) | Author |
|---|
|
dhcp_fine_tmr() was called every 10ms, but lwIP expects it to be
called every DHCP_FINE_TIMER_MSECS (500ms).
Since the fine timer ticks are currently 50 times faster than lwIP
expects, the client burns through the bounded exponential backoff
sequence for the DHCPREQUEST messages in 2.44 seconds rather than 122
seconds, after which it uses a new xid and returns to sending
DHCPDISCOVER messages. If there is enough latency in the server, the
client could receive an ACK response within DHCP_TIMEOUT_MS (10
seconds), but reject it because it has already moved on with another
xid after 2.44 seconds.
We have seen this occur with our boards. When our rack of 16 boards
get powered on together, they all request for an address from the
network switch's DHCP server in near lock-step and we see that only a
few of the boards actually obtain a lease. Fixing the timing to 500ms
allowed all of the boards to obtain a lease consistently.
Fixes: 98ad145db61a ("net: lwip: add DHCP support and dhcp commmand")
Signed-off-by: Luca Jones <[email protected]>
|
|
read_slotted_partition() loads an Android boot/vendor_boot image into the
load address, sizing the read from the image header:
num_blks = DIV_ROUND_UP(image_size, desc->blksz);
...
blk_dread(desc, partition.start, num_blks, map_sysmem(addr, 0));
image_size is priv->boot_img_size / priv->vendor_boot_img_size, taken from
the boot image header and never bounded by the partition. A header
claiming a size larger than the partition makes blk_dread read past the
partition and write past the load buffer: an out-of-bounds write of
attacker-controlled length on media a physical attacker can supply. It is
reached during boot on a device where AVB does not gate the read (AVB
disabled, or an unlocked device).
Reject an image that does not fit in its partition before issuing the read.
Both the boot and vendor_boot reads go through this function.
Fixes: abadcda24b10 ("bootstd: android: don't read whole partition sizes")
Signed-off-by: Shahriyar Jalayeri <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Mattijs Korpershoek <[email protected]>
|
|
Versal Gen 2 and especially march-versal2 is not covered by own fragment
that's why add it.
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/11956eca5ebd0b3626b7e2d0fa52331cbd3dc1ec.1786361819.git.michal.simek@amd.com
|
|
There are EEMI firmware hooks available but they are also IO versions of it
that's why remove ZYNQMP_FIRMWARE depency from UFS driver.
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/85cbacdc7492890c76396974d24fff607c2088ad.1785394153.git.michal.simek@amd.com
|
|
The M-PHY and SRAM readiness poll loops move out of the UFS controller
driver and into the firmware backend, exposed as blocking waits with
a caller-owned timeout budget. This keeps the UFS driver backend-agnostic
and lets an other backends offload the wait to the platform in a single
call instead of round-tripping every poll.
set_sram_bypass() now performs the SRAM_CSR read-modify-write in the
firmware layer.
Hook up functions are also update to reflect their usage.
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/26bc9aa2c02921690e126ab3401f7974ef04ad6e.1785394153.git.michal.simek@amd.com
|
|
Move the controller/PHY reset and SRAM-bypass sequence from
hce_enable_notify(PRE_CHANGE) into ufs_versal2_init().
The reset sequence releases the host controller from reset, and the UFS
core reads the capability and version registers right after .init() and
before ufshcd_hba_enable() (the only caller of hce_enable_notify()).
Doing the reset in .init() ensures those registers are read after the
controller is out of reset, and keeps the driver aligned with Linux.
ufs_versal2_phy_init() stays in POST_CHANGE.
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/6b4cbfa6cc58bef86da86971e4b27726a4e510f0.1785394153.git.michal.simek@amd.com
|
|
Add firmware interface for UFS access but also keep IO interface when
firmware is not enabled.
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/6419fe4f6f1f451aee624c7762b7aa690d50e498.1784870711.git.michal.simek@amd.com
|
|
asm/arch/sys_proto.h is included twice that's why remove one.
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/cd3c11a7e09ed8db3945910cdfed0eb860dcd61e.1784870326.git.michal.simek@amd.com
|
|
The only purpose to enable SPL is to simplify testing of mini
configuration. SPL initializes the system also with DDR that mini
configuration can directly run.
psu_init already targets zcu102 like for mini_qspi
(symlink zynqmp-mini -> zynqmp-zcu102-rev1.0).
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/9c9a2699c97241fa599b65fd336699ace7577833.1784722595.git.michal.simek@amd.com
|
|
Setup BOARD_SIZE_LIMIT to 128KB (131072 bytes) for ZynqMP mini/qspi
configurations and enable CONFIG_SKIP_RELOCATE as there is no need
for relocation.
For configurations running from OCM (xilinx_zynqmp_mini_defconfig and
xilinx_zynqmp_mini_qspi_defconfig), move TEXT_BASE from 0xFFFC0000 to
0xFFFE0000. The initial 128KB of OCM (0xFFFC0000-0xFFFDFFFF) is used
for data buffer.
Memory layout in OCM (256KB total):
- 0xFFFC0000 - 0xFFFDFFFF: Data buffer (128KB)
- 0xFFFE0000 - 0xFFFFFFFF: U-Boot code + stack (128KB)
- TEXT_BASE at 0xFFFE0000 (code grows up)
- EARLY SP at 0xFFFE0000 (stack grows down)
EARLY SP is released when new stack location is calculated before U-Boot
prompt that's why no conflict with Data buffer location.
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/6d91337d971fa9e22f6f57371f8bc656ea6bb4a3.1784722595.git.michal.simek@amd.com
|
|
For MicroBlaze-V SPI boot, the u-boot-spl.elf should be embedded into
the BRAM (Block RAM) of bitstream or rcdo. This requires SPL_REMAKE_ELF
to be enabled so that the SPL ELF is generated during the build.
Enable SPL_REMAKE_ELF for MB-V devices to support this flow.
Signed-off-by: Sandeep Gundlupet Raju <[email protected]>
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/aa144c8002ba86154dcb62624a1d9d7cbe8c2cdf.1777962845.git.michal.simek@amd.com
|
|
Disable CONFIG_SPL_USE_ARCH_MEMCPY, CONFIG_SPL_USE_ARCH_MEMMOVE, and
CONFIG_SPL_USE_ARCH_MEMSET to use generic C implementations instead
of RISC-V assembly versions. The generic implementations are smaller
for SPL's constrained code size requirements.
spl/u-boot-spl: all -446 text -446
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/4885b1983ec158ed98e727091be38f7de104108e.1777550623.git.michal.simek@amd.com
|
|
Disable CONFIG_SPL_CPU to remove the CPU driver from SPL. The CPU
driver provides runtime CPU information and enumeration which is not
needed during the early SPL boot phase, saving significant code space.
spl/u-boot-spl: all -922 data -208 rodata -100 text -614
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/96dcbd196206f48aa4552624b562124c11cafbce.1777550623.git.michal.simek@amd.com
|
|
Starting the GENFIFO after each CMD and ADDR entry creates a gap
between the address phase (TX) and data phase (RX). For read commands
without dummy cycles, the controller is still driving DQ2/DQ3 HIGH
when the flash switches to output mode, causing a bus conflict.
Split the GENFIFO helper into a write-only variant and a
start-and-wait variant. Queue CMD, ADDR and dummy entries without
starting the GENFIFO. The data phase appends its entry and starts
the queued sequence, keeping the address-to-data transition
continuous.
Since genfifo_cmd() no longer triggers after each entry, operations
without a data phase have no trigger path. Call start_gen_fifo()
from exec_op() before deasserting chip select to execute the queued
CMD and ADDR entries.
Fixes: 22cca1730ec4 ("spi: zynqmp_gqspi: Add support for ZynqMP qspi driver")
Signed-off-by: Suraj Kakade <[email protected]>
Signed-off-by: Padmarao Begari <[email protected]>
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/[email protected]
|
|
Commit 371a6c1744f3 ("board: xilinx: Add capsule and FWU support") and
commit 818c06faa119 ("board: amd: Add capsule and FWU support")
introduced a separate set_dfu_alt_info() for the FWU multi-bank case
(Versal and Versal Gen 2 respectively) which set the dfu_alt_info
environment variable directly, while configure_capsule_updates() handled
the non-FWU case by filling update_info.dfu_string.
Fold the FWU multi-bank generation (fwu_gen_alt_info_from_mtd() over the
nor0 MTD partitions) into fwu_platform_hook() and drop the
standalone set_dfu_alt_info().
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/33c118b8177f8d0dc182a6f4c5cffedca4e02448.1782986903.git.michal.simek@amd.com
|
|
The GIC redistributor base address depends on the part: the 2VM3654
device has 4 APU cores and 3 GIC ITS blocks, which shifts the
redistributor region up compared to the base 8 core / single ITS part.
A single U-Boot binary must therefore pick the right base at runtime
instead of relying on the compile-time GICR_BASE used by the generic
lowlevel_init().
Add a SoC specific lowlevel_init() that reads the PMC TAP IDCODE and
selects GICR_BASE_2VM3654 for the 2VM3654 device, otherwise keeps the
default GICR_BASE. CONFIG_ARMV8_MULTIENTRY is not supported on Versal
Gen 2 so the generic slave handling is intentionally dropped.
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/4c0dc2b6e29d300db15be0844879ab4d028d98a9.1783493630.git.michal.simek@amd.com
|
|
The register address and bootmode defines in this header are useful from
early assembly (e.g. lowlevel_init reading PMC_TAP_IDCODE), but the file
could not be included from .S because the C-only declarations were not
guarded.
Reorder the header so all plain address/value defines are visible to both
C and assembly, and move every C-only construct (the linux/bitops.h
include, the register structs, the base pointer-cast macros and the
platform enum) into a single #ifndef __ASSEMBLY__ block.
No functional change for C consumers.
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/de4de47ea457b285c5870e7ba25b4baf554561e7.1783493630.git.michal.simek@amd.com
|
|
Rockchip SoCs can automatically switch between jtag and sdmmc based on
the following rules:
- all the SDMMC pins including SDMMC_DET set as SDMMC function in GRF,
- force_jtag bit in GRF is 1,
- SDMMC_DET is low (no card detected),
Note that the BootROM may mux all SDMMC pins in their SDMMC function or
not, depending on the boot medium that were tried.
Because SDMMC_DET pin is not guaranteed to be used as an SD card card
detect pin, it could be low at boot or even switch at runtime, which
would enable the jtag function and render the SD card unusable.
Or boards using cd-gpios may switch the SDMMC_DET pin to GPIO function,
which would enable the jtag function and render the SD card unusable.
With commit d0a838bdc629 ("Subtree merge tag 'v7.1-dts' of dts repo [1]
into dts/upstream") there are now RK3576 boards that have changed to use
cd-gpios for the SDMMC_DET pin, e.g. NanoPi R76S, that may have issues
detecting SD card unless force_jtag is disabled.
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Quentin Schulz <[email protected]>
|
|
Hardware of various vendors, but very notably Rockchip, often uses
32-bit registers where the upper 16-bit half of the register is a
write-enable mask for the lower half.
Add hw_bitfield.h with two macros: FIELD_PREP_WM16, and
FIELD_PREP_WM16_CONST. The latter is a version that can be used in
initializers, like FIELD_PREP_CONST.
Import hw_bitfield.h from Linux commit 21368fcbb124 ("bitmap: introduce
hardware-specific bitfield operations"), first introduced in v6.18-rc1.
This contains two changes compared to the Linux version:
- include of linux/limit.h was dropped
- use of const_true() in FIELD_PREP_WM16_CONST() was dropped
Signed-off-by: Jonas Karlman <[email protected]>
Acked-by: Quentin Schulz <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Quentin Schulz <[email protected]>
|
|
https://git.u-boot-project.org/u-boot/custodians/u-boot-fsl-qoriq
CI: https://git.u-boot-project.org/u-boot/custodians/u-boot-fsl-qoriq/-/pipelines/946
- Add support for vendor protocol IDs 0x81 for SCMI
- Fix LDO selector boundaries and make the driver fail gracefully when
the
- regulators DT node is absent for TPS65219 PMIC/Regulator:
- Fix a hotplug issue with pci_iommu_extra on Layerscape platforms for
PCIe Layerscape.
- Fix a GIC LPI table corruption on LS1028A boards with 2 GiB of RAM
caused by an unbounded TF-A DRAM bank loop and an integer underflow
when gd->arch.resv_ram is inadvertently left at zero due to empty DRAM
banks.
- Also includes a minor DT cosmetic cleanup.
|
|
The TF-A DRAM bank setup currently assumes that the number of
banks reported by TF-A matches the number of entries available in
gd->bd->bi_dram[]. Limit the loop by CONFIG_NR_DRAM_BANKS so that
a platform with fewer configured DRAM banks does not write past the
array.
The reserved RAM setup also checks higher DRAM banks before falling
back to bank 0. When a higher bank is empty and board_reserve_ram_top()
returns 0, the old test succeeds for a zero-sized bank. This can set
gd->arch.resv_ram to 0.
On systems with CONFIG_GIC_V3_ITS this value is later used by
ls_gic_rd_tables_init() to place the GIC LPI tables:
gd->arch.resv_ram - GIC_LPI_SIZE
If gd->arch.resv_ram is 0, the subtraction underflows and the GIC LPI
tables are placed at an invalid high address.
Skip empty banks when selecting the reserved RAM area and fail GIC LPI
table setup if no reserved RAM address was established.
This fixes LS1028A systems with 2 GiB of RAM, where TF-A reports only
one populated DRAM bank.
Tested on an LS1028ARDB with TF-A modified to report 2 GiB of RAM, and
on a custom LS1028A-based board equipped with 2 GiB of RAM.
Signed-off-by: Patryk Biel <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
Fix typo in enum scmi_config_type in include/scmi_protocols.h.
The enum value SCMI_PIN_DEFUALT was misspelled and should be
SCMI_PIN_DEFAULT to match the correct English spelling. This fixes
potential compilation issues and improves code clarity for any code
that references this enum value
Fixes: 0cb160f1b629 ("scmi: pinctrl: add pinctrl driver for SCMI")
Signed-off-by: Udit Kumar <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
According to the TPS65219 datasheet, selectors 0x38 through 0x3f
saturate at 3.4 V for LDO1 and LDO2.
For LDO3 and LDO4, selectors 0x00 through 0x0c saturate at
1.2 V, while selectors 0x36 through 0x3f saturate at 3.3 V.
The driver currently uses 0x56, 0x12, and 0x54 as selector boundary
values. These values do not match the selector boundaries defined by
the datasheet.
Use the correct selector boundary values of 0x38, 0x0c, and 0x36
for interpolation.
Fixes: b5cfa0c7ca4f ("power: add driver for the TPS65219 PMIC")
Signed-off-by: Kumara Bhimeswararao Matsa <[email protected]>
Acked-by: Maarten Brock <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
We can have many pci hotplug groups, each introduced
by a "pci@<addr>" token such as,
pci_iommu_extra=pci@0x3600000,1.0.0,hp,pci@0x3700000,1.0.0,hp,
pci@0x3800000,1.0.0,hp,pci@0x3900000,1.0.0,hp
Without this fix, we have the error:
Added iommu map for hotplug 1.0.0
ERROR: invalid action in extra iommu entry
ERROR: invalid action in extra iommu entry
ERROR: invalid action in extra iommu entry
Fixes: 2a5bbb13cc39 ("pci: layerscape: add a way of specifying additional iommu mappings")
Signed-off-by: Vincent Jardin <[email protected]>
Reviewed-by: Neil Armstrong <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
Fix many dtc warning for the Layerscape device trees with W=1.
Without this fix, it emits over 30 unit_address_format warnings.
No functional change.
Signed-off-by: Vincent Jardin <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
The TPS65219 bind function continues when the regulators subnode is
missing. This causes pmic_bind_children() to be called with an invalid
ofnode and permits a misleading message indicating that the subnode
was found.
Return -ENXIO when the regulators subnode is absent, matching the
behavior of other TI PMIC drivers.
Signed-off-by: Kumara Bhimeswararao Matsa <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
Preparing to add the AMD/Xilinx SCMI vendor protocol driver, support probe
of SCMI vendor ID 0x81. Add the protocol ID, the per-agent protocol device
slot, the probe/lookup switch cases and the scmi command name, gated by a
Kconfig option for conditional compilation.
The same wiring has been done by commit 7830ccc77a13 ("firmware: scmi:
Support probe vendor ID 0x80 and 0x82").
Signed-off-by: Michal Simek <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
The generic SCMI vendor protocol IDs (0x80, 0x82) were listed by
"scmi info" as <NULL>. Add human readable names so the
vendor protocols are easier to identify.
Signed-off-by: Michal Simek <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
Signed-off-by: Tom Rini <[email protected]>
|
|
In case MULTI_DTB_FIT_GZIP is enabled, fdtdec_setup() does uncompress
the compressed DTs in uncompress_blob() using gunzip(), which invokes
malloc() internally. The early simple malloc is initialized in board_f
initf_malloc() call, which sets up the early simple malloc limit and
offset pointer in global data. Currently, the initf_malloc() is called
after fdtdec_setup(), which leads to malloc failure in fdtdec_setup()
during the gzip decompression, because the early simple malloc is not
initialized yet.
Call initf_malloc() before fdtdec_setup() to assure fdtdec_setup() can
use malloc() during gzip decompression of the DTs.
The impact of this change on boot time is negligible, because the
initf_malloc() only assigns two fields in global data.
Signed-off-by: Marek Vasut <[email protected]>
Fixes: 95f4bbd581cf ("lib: fdt: Allow LZO and GZIP DT compression in U-Boot")
Reviewed-by: Simon Glass <[email protected]>
[trini: Update test/py/tests/test_trace.py]
Signed-off-by: Tom Rini <[email protected]>
|
|
When CONFIG_MULTI_DTB_FIT is enabled, fit-dtb.blob is produced by
mkimage with one "-b " argument for every entry in CONFIG_OF_LIST.
The make rule, however, only listed dts/dt.dtb (i.e. the
CONFIG_DEFAULT_DEVICE_TREE blob) as a prerequisite:
fit-dtb.blob: dts/dt.dtb FORCE
$(call if_changed,mkimage)
Because FORCE is PHONY, if_changed ignores it and rebuilds only when
any-prereq or arg-check is non-empty. Editing a non-default dts in
OF_LIST rebuilds its .dtb (tracked correctly via fixdep), but that
.dtb was not a prerequisite of fit-dtb.blob, so $? stayed empty; the
mkimage command line was unchanged too, so arg-check was empty as
well. if_changed therefore skipped mkimage and fit-dtb.blob kept the
stale dtbs. u-boot.bin, which appends fit-dtb.blob, then shipped the
old device tree and the dts change did not take effect.
A previous attempt to fix this added every OF_LIST .dtb *output* as a
prerequisite. That is wrong on two counts:
- Clean build regression: the OF_LIST .dtb files are produced only
by the recursive dts/dt.dtb -> arch-dtbs sub-make descent and have
no rule at the top make level, so listing them as prerequisites
makes them rule-less/intermediate. After a from-scratch rebuild
(e.g. wiping an out-of-tree build directory) it fails:
make[1]: *** No rule to make target 'arch/arm/dts/.dtb',
needed by 'fit-dtb.blob'. Stop.
- Incremental two-build race still present: the .dtb outputs are
written by a child sub-make descent while the parent make level
checks prerequisites, so under `make -j` an edit can still need
two make invocations to take effect.
List the .dts *sources* instead, which the top make level can see via
VPATH in both objtree and srctree. Use $(dt_dir), as
MKIMAGEFLAGS_fit-dtb.blob already does just below, so that
CONFIG_OF_UPSTREAM boards (whose sources live under dts/upstream/src/)
are handled too; a helper variable keeps the rule under 80 columns.
Limitation: this only catches edits to the top-level .dts files in
OF_LIST. An edit to an included .dtsi (including the *-u-boot.dtsi
files) rebuilds the .dtb but leaves fit-dtb.blob stale, so the
two-build problem remains in that case. Fixing that fully would need
the .dtb outputs (rather than the .dts sources) as prerequisites,
which reintroduces the clean-build problem above; covering top-level
.dts edits is already a worthwhile improvement.
Signed-off-by: Lianghong Liu <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
touched
Commit aa5ef3c0a752 ("bootretry: check for bootretry variable changes")
broke the feature where one can define different keys for "delaying"
versus "stopping" boot. The way the latter is implemented is by the code
in autoboot.c calling bootretry_dont_retry() when the stop sequence
has been detected, and that simply sets the retry_time variable in
bootretry.c to -1.
However, with the mentioned commit, that is unconditionally overridden
on every command, since it gets re-initialized from either the
bootretry environment variable or CONFIG_BOOT_RETRY_TIME, thus making
"delay" and "stop" effectively the same.
To fix that, while still picking up changes to the bootretry
environment variable, use the proper mechanism for C code to be
notified about changes to environment variables.
Since the callback is invoked before the change has actually been done
to the environment (callbacks can reject the change from taking
effect), we cannot simply call the existing
bootretry_init_cmd_timeout() from the callback, as its env_get() would
not see the new value. Instead, refactor most of it to an internal
bootretry_parse(), and call that with the new value (which is NULL in
the case bootretry is being deleted, so that works exactly as it
should).
Signed-off-by: Rasmus Villemoes <[email protected]>
|
|
Enable main_uart2 and main_uart3 for console log functionality.
Add clk and device data for main_uart2 and main_uart3
which can be used by main_uart driver to configure clocks and PSC.
Signed-off-by: Gokul <[email protected]>
Reviewed-by: Neha Malcom Francis <[email protected]>
|
|
U-Boot running as a coreboot payload obtains serial console
information either from the coreboot table or from the ACPI DBG2
table.
When serial console support is disabled in coreboot, the coreboot
table does not contain serial information. In this case U-Boot falls
back to parsing the DBG2 table.
Some AMD platforms or any other platforms that uses memory-mapped I/O
advertise the debug UART using DBG2 subtype 0x0012 ("16550-compatible
with parameters defined in Generic Address Structure"). U-Boot
currently accepts only subtype 0x0000, causing DBG2 UART detection to
fail and leaving no console output.
Accept subtype 0x0012 as well and keep the existing handling logic.
Signed-off-by: Desapogu Jayaramudu <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
The SCSI command currently prints the following duplicate prefix:
"
=> scsi
scsi - SCSI sub-system
Usage:
scsi scsi info - show available SCSI devices
^^^^^^^^^
scsi scan - (re-)scan SCSI bus
"
Drop one copy of the scsi prefix.
Fixes: 460c322f13ec ("(re)enabled scsi commands do_scsi() and do_scsiboot() Patch by Denis Peter, 06 Dec 2004")
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Neil Armstrong <[email protected]>
Reviewed-by: David Lechner <[email protected]>
|
|
Simplify the code, replace env_get_f() with env_get_yesno(). The
env_get_yesno() internally calls env_get() which may fall back to
env_get_f() if the environment access is not initialized yet.
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Stefan Roese <[email protected]>
|
|
Cole Munz <[email protected]> says:
As agreed on the v1 thread, the fix and the cleanups are now separate
patches:
- patch 1 is the fix in the v1 shape
- patch 2 makes btrfs_search_slot() release the path on error like
the kernel version does. That is where the btrfs_size() leak came
from. Suggested by Qu.
- patch 3 is the dedup Alexey asked about. One helper shared by
btrfs_readdir() and btrfs_size().
The pending btrfs test suite still passes on top of the readdir
series: 5 passed.
Link: https://lore.kernel.org/r/[email protected]
|
|
btrfs_readdir() and btrfs_size() both open code the same search for an
inode item to read its size field. Move it into one helper.
Signed-off-by: Cole Munz <[email protected]>
Reviewed-by: Qu Wenruo <[email protected]>
|
|
The U-Boot copy of btrfs_search_slot() returns on error with the nodes
it has descended through still attached to the path. The kernel one
releases the path on any error unless p->skip_release_on_error is set,
and callers written against that convention treat a failed search as
owning nothing. btrfs_size() is one: it returns straight away on a
search error and never reaches its btrfs_release_path() call, so the
attached extent buffer references leak.
Route both error exits through a release of the path. The error
returns of read_node_slot() carry no extra reference, so the path is
the only thing to clean up.
Suggested-by: Qu Wenruo <[email protected]>
Signed-off-by: Cole Munz <[email protected]>
Reviewed-by: Qu Wenruo <[email protected]>
|
|
btrfs_readdir() zeroes the dirent and fills in only the name and the
type, so dent->size stays 0 and every file is listed as zero bytes:
=> ls host 0 /
0 f_192k.bin
0 small_3k.bin
Reads themselves are fine, since btrfs_read() takes the size from
btrfs_size(), which does its own inode item lookup. It affects EFI
too: dir_read() in lib/efi_loader/efi_file.c copies dent->size into
both file_size and physical_size, so an EFI application enumerating a
directory on btrfs sees every file as empty, which is the generic-code
path Alexey's readdir series moves btrfs onto.
The custom listing that fs_ls_generic() replaced looked the inode item
up and printed the real size, and every other filesystem in the tree
fills dent->size in its own readdir: ext4fs.c:327, exfat io.c:805,
erofs fs.c:186, squashfs sqfs.c:1095 and fat.c:1555.
btrfs_next_dir_entry() already has the dir item mapped, so read the
key it points at while we are there and hand it back to the caller,
and use that to reach the inode item. A subvolume entry points at a
root item instead and has no size of its own, so leave that one at 0.
=> ls host 0 /
196608 f_192k.bin
3000 small_3k.bin
Fixes: 31cf3f177823 ("fs: btrfs: use fs_ls_generic() and drop custom implementation")
Signed-off-by: Cole Munz <[email protected]>
Reviewed-by: Qu Wenruo <[email protected]>
|
|
Daniel Golle <[email protected]> says:
A signed FIT configuration can delegate the integrity of a (potentially
large) root filesystem image to the kernel's dm-verity instead of having
U-Boot hash the whole payload at boot: the FIT carries a "dm-verity"
subnode with the roothash, salt and block parameters, U-Boot passes the
roothash to Linux through the dm-mod.create bootargs, and dm-verity then
validates the filesystem block by block against it.
For that to be safe the roothash has to be trusted, and in a signed
configuration the only thing that establishes trust is the configuration
signature. The roothash was not covered by it. fit_config_add_hash()
collected the image node, its hash subnodes and its cipher subnode into
the signed region, but not the dm-verity subnode, so the roothash, the
sole integrity anchor for the filesystem, was left unsigned.
The result is a verified-boot bypass for the root filesystem: an
attacker who can rewrite the boot medium can replace the filesystem,
recompute a matching dm-verity tree, write the new roothash into the
unsigned dm-verity subnode, and the configuration signature still
verifies. dm-verity then faithfully validates the malicious filesystem
against the attacker's roothash.
This series closes the gap.
Link: https://lore.kernel.org/r/[email protected]
|
|
A dm-verity protected filesystem image is not hashed by U-Boot; its
integrity is delegated to the kernel, which trusts the roothash taken
from the FIT dm-verity subnode. For that chain of trust to hold, the
roothash (and salt) must be part of the region covered by the
configuration signature, otherwise an attacker can replace both the
filesystem and the roothash while keeping the signature valid.
Add two independent checks of this property:
- test/py/tests/test_fit_verity_sign.py signs a configuration that
references a filesystem image carrying a dm-verity subnode, then
confirms that tampering the roothash or the salt is rejected by
fit_check_sign. A control that tampers a byte known to be signed
proves the check can fail. A matching page is added under
doc/develop/pytest/ so the module documentation is rendered with
the rest of the generated docs.
- test/boot/fit_verity.c gains a runtime unit test that builds the
exact node list the configuration signature is computed over,
turns it into hashed regions and checks both that the roothash
bytes fall inside a signed region and that tampering them changes
the hash. It needs no private key, so it also runs on real devices
and uses the same hash path a device would.
To let the unit test build the signed-region node list, rename the
config node-list helper to fit_config_get_signed_nodes(), make it
non-static and declare it in image.h.
Signed-off-by: Daniel Golle <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
A dm-verity protected filesystem image is not hashed by U-Boot when it
is loaded; its integrity is delegated to the kernel, which validates the
filesystem on the fly against the roothash taken from the FIT dm-verity
subnode. The roothash is therefore the sole integrity anchor for the
filesystem, yet fit_config_add_hash() only adds the image node, its
hash subnodes and its cipher subnode to the signed region, leaving the
dm-verity subnode (roothash, salt and block parameters) unsigned.
An attacker able to rewrite the boot medium could then replace both the
filesystem and the roothash, recompute a matching dm-verity tree and
keep the configuration signature valid, defeating verified boot for the
root filesystem.
Add the dm-verity subnode to the list of nodes covered by the
configuration signature, both when signing (tools/image-host.c) and when
verifying (boot/image-fit-sig.c), so the roothash and salt are
authenticated together with the rest of the configuration.
Signed-off-by: Daniel Golle <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Both the boot-side and host-side fit_config_add_hash() repeat the same
sequence to append a node's path to the hashed-node list three times:
for the image node, for each hash subnode and for the cipher subnode.
Extract it into a helper, fit_config_add_node(), in each file, with no
functional change.
Signed-off-by: Daniel Golle <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
https://git.u-boot-project.org/u-boot/custodians/u-boot-usb
- MTU3 DT bindings alignment with Linux DT bindings.
|
|
MediaTek platforms may need the MTU3 controller before U-Boot proper is
available, but the driver is currently selected and built only with the
main U-Boot configuration symbols.
Add an explicit SPL controller option with host and gadget modes. Make
the driver build and its role checks phase-aware so each phase can select
the MTU3 role it needs without coupling it to the U-Boot proper controller
configuration.
The upstream binding locates the xHCI child registers through the parent
ranges property. Select SPL_OF_TRANSLATE for host mode so SPL can resolve
that address before mapping it.
Signed-off-by: Julien Masson <[email protected]>
Signed-off-by: Carlo Caione <[email protected]>
Reviewed-by: Marek Vasut <[email protected]>
|
|
The MTU3 glue driver expects a synthetic mediatek,ssusb child that
combines the device and xHCI register windows. Upstream devicetrees
instead put the device resources on the controller node and describe the
xHCI window with a standard child node, so U-Boot cannot use an upstream
topology.
Switch to the upstream layout. The controller owns the shared resources
and the device MAC, with the device register offsets relative to it as in
Linux. The gadget role binds as a node-less internal device, while the
host role binds to an enabled xHCI child and uses its own clocks,
supplies and register window. dr_mode selects the role and defaults to
otg, and the Kconfig choice constrains which role the build provides.
The legacy child layout is rejected explicitly so its combined register
window cannot be mistaken for the device MAC.
Convert the in-tree MT8183 and MT8512 devicetrees in the same commit so
neither platform is left without USB. MT8512 stays peripheral-only
because its xHCI host interrupt is not documented and the
mediatek,mtk-xhci binding requires it.
Reviewed-by: Marek Vasut <[email protected]>
Signed-off-by: Carlo Caione <[email protected]>
|
|
The MediaTek MTU3 and xHCI text bindings describe legacy U-Boot layouts
which have been superseded by the canonical Linux schemas. Those schemas
are already synchronized into `dts/upstream/Bindings/usb`.
Remove the duplicate text bindings so new devicetrees and driver changes
use the maintained YAML definitions.
Reviewed-by: Marek Vasut <[email protected]>
Signed-off-by: Carlo Caione <[email protected]>
|
|
https://git.u-boot-project.org/u-boot/custodians/u-boot-sh
This includes temporary U-Boot DT ECC carveouts for R-Car Gen5, they
will be dropped from U-Boot DTs once OF_UPSTREAM DTs get re-synced.
This also includes RPC-IF support for R-Car Gen5 and env storage in RPC
HF.
This also includes an update for R-Car Gen5 UFS controller driver.
|
|
The DBSC5 DRAM controller protects DRAM content using inline ECC.
The inline ECC utilizes areas of DRAM for its operation, which are
in the DRAM address range, but must not be accessed or modified.
Describe the inline ECC carveout areas used by the DBSC5 controller
on this hardware as reserved-memory, which must not be accessed.
Include DRAM areas which are unprotected by ECC as well, those are
parts of the DRAM which directly precede the ECC carveout.
In case of high DRAM utilization, unless the inline ECC carveouts
are properly reserved, Linux may use and corrupt the memory used
by the DBSC5 DRAM controller for inline ECC, which would lead to
the system becoming unstable.
Ported from Linux 7.2-rc5 commit
6fa6ee724d8d ("arm64: dts: renesas: ironhide: Describe inline ECC carveouts")
Signed-off-by: Marek Vasut <[email protected]>
|
