Tom Rini [Fri, 12 Apr 2024 18:57:13 +0000 (12:57 -0600)]
Merge patch series "zlib: Address CVE-2016-9841"
Michal Simek <michal.simek@amd.com> says:
It looks like that only CVE-2016-9841 is not fixed and this series is
trying to address it. The first two patches are just preparation based on
changes which happened in past. The third one is actual fix and the last
one is following what has been done in Linux kernel long time ago and don't
use incorrect zlib version string.
I tested it with and I can't see any issue.
./test/py/test.py --bd sandbox --build -s
Michal Simek [Wed, 27 Mar 2024 14:14:53 +0000 (15:14 +0100)]
zlib: Remove incorrect ZLIB_VERSION
Get rid of zlib version which is not correct because of U-Boot related
changes and various CVE backports.
The change in inspired by Linux kernel commit 4f3865fb57a0 ("[PATCH]
zlib_inflate: Upgrade library code to a recent version") which described
ZLIB_VERSION removal as
"This patch also removes ZLIB_VERSION as it no longer has a correct value.
We don't need version checks anyway as the kernel's module handling will
take care of that for us. This removal is also more in keeping with the
zlib author's wishes (http://www.zlib.net/zlib_faq.html#faq24) and I've
added something to the zlib.h header to note its a modified version."
Author describes wish to follow this guidance at
https://www.zlib.net/zlib_faq.html#faq24:
"The license says that altered source versions must be "plainly marked". So
what exactly do I need to do to meet that requirement?
You need to change the ZLIB_VERSION and ZLIB_VERNUM #defines in zlib.h. In
particular, the final version number needs to be changed to f, and an
identification string should be appended to ZLIB_VERSION. Version numbers
x.x.x.f are reserved for modifications to zlib by others than the zlib
maintainers. For example, if the version of the base zlib you are altering
is 1.2.3.4, then in zlib.h you should change ZLIB_VERNUM to 0x123f, and
ZLIB_VERSION to something like 1.2.3.f-zachary-mods-v3. You can also update
the version strings in deflate.c and inftrees.c."
But U-Boot is not exact version that's why following the same style which
has been used by Linux kernel where ZLIB_VERSION is completely removed.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Michal Simek [Wed, 27 Mar 2024 14:14:52 +0000 (15:14 +0100)]
zlib: Port fix for CVE-2016-9841 to U-Boot
The patch corresponds to zlib commit at
https://github.com/madler/zlib/commit/9aaec95e82117c1cb0f9624264c3618fc380cecb
which declares that it is fixing CVE-2016-9841.
Here is c&p description from zlib:
"Use post-increment only in inffast.c.
An old inffast.c optimization turns out to not be optimal anymore
with modern compilers, and furthermore was not compliant with the
C standard, for which decrementing a pointer before its allocated
memory is undefined. Per the recommendation of a security audit of
the zlib code by Trail of Bits and TrustInSoft, in support of the
Mozilla Foundation, this "optimization" was removed, in order to
avoid the possibility of undefined behavior."
Origin patch also updates the code when
INFLATE_ALLOW_INVALID_DISTANCE_TOOFAR_ARRR is present but this code is not
the part of U-Boot hence it is ignored.
Also do not deal with state->sane variable which requires other changes
which are also not the part of zlib.
Commit 92faa8b10918 ("zlib: handle overflow while calculating available
stream input size") is kept in inffast.c too not to break described case.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Michal Simek [Wed, 27 Mar 2024 14:14:51 +0000 (15:14 +0100)]
zlib: Rename write variable to wnext (window write index)
There is no particular patch/description which described the reason for
this change but it was done as the part of zlib 1.2.3.5 release done by
zlib commit d004b047838a ("zlib 1.2.3.5"). It is preparation for followup
patch.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Michal Simek [Wed, 27 Mar 2024 14:14:50 +0000 (15:14 +0100)]
zlib: Rename this variable to here (current decoding table entry)
There is no particular patch/description which described the reason for
this change but it was done as the part of zlib 1.2.3.5 release done by
zlib commit 639be997883d ("zlib 1.2.3.3") It is preparation for followup
patch.
Signed-off-by: Michal Simek <michal.simek@amd.com>
ARM: uniphier: Move uniphier_mem_map_init() call into dram_init()
The function uniphier_mem_map_init() is to change global variable
'mem_map', which is referenced to get_page_table_size() to calculate
the size of page table.
However, uniphier_mem_map_init() is called after get_page_table_size(),
so the size of page table and 'mem_map' become inconsist each other.
After all, U-Boot fails to boot on chip with memory map different from
default map,
uniphier_mem_map_init() should be moved to dram_init(), which is
called before get_page_table_size().
Sam Protsenko [Sat, 30 Mar 2024 00:55:53 +0000 (19:55 -0500)]
fdt: Fix fdt_pack_reg() on 64-bit platforms
When "memory" node is being processed in fdt_pack_reg() on ARM64
platforms, an unaligned bus access might happen, which leads to
"synchronous abort" CPU exception. Consider next dts example:
After fdt_pack_reg() reads the first addr/size entry from such memory
node, the "p" pointer becomes 12 bytes shifted from its original value
(8 bytes for two address cells + 4 bytes for one size cell). So now it's
not 64-bit aligned, and an attempt to do 64-bit bus access to that
address will cause an abort like this:
"Synchronous Abort" handler, esr 0x96000021, far 0xba235efc
This issue was originally reported by David Virag [1] who observed it
happening on Samsung Exynos7885 SoC (ARM64), and later the same issue
was observed on Samsung Exynos850 (ARM64).
Fix the issue by using put_unaligned_be64() helper, which takes care of
possible unaligned 64-bit accesses. That solution was proposed by Simon
Glass in the original thread [1].
Fixes: 739a01ed8e02 ("fdt_support: fix an endian bug of fdt_fixup_memory_banks") Suggested-by: Simon Glass <sjg@google.com> Reported-by: David Virag <virag.david003@gmail.com> Closes: https://lists.denx.de/pipermail/u-boot/2023-July/522074.html Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Sam Protsenko [Thu, 28 Mar 2024 22:29:50 +0000 (17:29 -0500)]
part: Check all partitions in part_get_info_by_name()
In part_get_info_by_name() the inability to get some partition info
shouldn't be a reason for dropping out of the loop. That might happen
e.g. if the partition is hidden or unused. An example of such case are
Samsung devices, where they use the "unused" GUID type
(00000000-0000-0000-0000-000000000000) to indicate that the partition
should be hidden from the OS. Such partitions might not be seen in
"part list" output, which creates "gaps" in numbering in between of the
visible partitions:
Part Start LBA End LBA Name
1 0x00000400 0x0000a3ff "efs"
5 0x00026420 0x00026c1f "dtbo"
12 0x0003f390 0x0074738f "super"
In that case, the loop in part_get_info_by_name() would break after
partition #1, so any attempt to obtain "dtbo" or "super" partition will
fail. Fix that by continuing to iterate over the remaining partitions to
make sure none of the visible ones is missed. That makes "part" command
(e.g. "part start", "part size") able to work with such tables.
Fixes: 87b8530fe244 ("disk: part: implement generic function part_get_info_by_name()") Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Hugo Cornelis [Thu, 21 Mar 2024 11:22:22 +0000 (12:22 +0100)]
image-host: Fix error value paths and emit error messages to stderr.
A recent refactoring in image-host.c messed up the return values of
the function that reads the encryptiong keys. This patch fixes this
and also makes sure that error output goes to stderr instead of to
stdout.
Signed-off-by: Hugo Cornelis <hugo.cornelis@essensium.com>
sandbox: missing return value checks in eth-raw-os
We should check the return value of fcntl().
Addresses-Coverity-ID: 131108 ("Unchecked return value from library")
Addresses-Coverity-ID: 131109 ("Unchecked return value from library") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
board: phycore-am62x: Extend for better environment handling
Select environment location based on the device we boot from.
Also, introduce a "boot" variable that represents the current boot
device and can be used by scripts.
arm: mach-k3: am625: Provide a way to obtain boot device for non SPLs
Introduce get_boot_device() to obtain the booting device. Make it also
available for non SPL builds so u-boot can also know the device it is
booting from.
Move verdin-am62 to OF_UPSTREAM:
- handle the fact that dtbs now have a 'ti/' prefix
- imply OF_UPSTREAM
- remove redundant files from arch/arm/dts leaving only the
*-u-boot.dtsi files
- update MAINTAINERS file
Andrew Davis [Tue, 2 Apr 2024 16:09:08 +0000 (11:09 -0500)]
arm: dts: k3: Remove unneeded ti, sci-sysreset binding and nodes
This extra binding is non-standard and now unneeded as we bind the
sysreset driver automatically. This matches what is done in Linux
and allows us to more closely match the DTBs. Remove the binding
and all users.
Signed-off-by: Andrew Davis <afd@ti.com> Reviewed-by: Neha Malcom Francis <n-francis@ti.com> Tested-by: Jonathan Humphreys <j-humphreys@ti.com>
Andrew Davis [Tue, 2 Apr 2024 16:09:07 +0000 (11:09 -0500)]
firmware: ti_sci: Bind sysreset driver when enabled
The sysreset TI-SCI API is available with TI-SCI always, there is no need
for a DT node to describe the availability of this. If the sysreset driver
is available then bind it during ti-sci probe.
Remove the unneeded device tree matching.
Signed-off-by: Andrew Davis <afd@ti.com> Tested-by: Jonathan Humphreys <j-humphreys@ti.com> Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Vitor Soares [Thu, 28 Mar 2024 10:05:48 +0000 (10:05 +0000)]
arm: mach-k3: common: EFI loader map memory below ram top
During the boot, the EFI loader maps the memory from ram_top to ram_end
as EFI_BOOT_SERVICES_DATA. When LMB does boot_fdt_add_mem_rsv_regions()
to OPTEE, TFA, R5, and M4F DMA/memory "no-map" for the kernel it produces
the following error message:
ERROR: reserving fdt memory region failed (addr=9cb00000 size=100000 flags=4)
ERROR: reserving fdt memory region failed (addr=9cc00000 size=e00000 flags=4)
ERROR: reserving fdt memory region failed (addr=9da00000 size=100000 flags=4)
ERROR: reserving fdt memory region failed (addr=9db00000 size=c00000 flags=4)
ERROR: reserving fdt memory region failed (addr=9e780000 size=80000 flags=4)
ERROR: reserving fdt memory region failed (addr=9e800000 size=1800000 flags=4)
To avoid this, don't flag with EFI_BOOT_SERVICES_DATA the memory from
ram_top to ram_end by the EFI loader.
Martyn Welch [Tue, 26 Mar 2024 14:26:33 +0000 (14:26 +0000)]
am625x_evm_a53: Tweak boot command to set fdt
With the current config for tha SK-AM62, fdtfile isn't set in the U-Boot
environment. When using bootflow to boot from a block device, where the
extlinux.conf file specifies `fdtdir`, a fallback device tree is being
constructed from the `soc` (`k3`) and `board` (`am62x`) environment
variables, resulting in u-Boot trying to retrieve
`/dtbs/6.8.1+/k3-am62x.dtb`. This file doesn't exist.
The environment variables `default_device_tree` and
`default_device_tree_arch` are set in the config, the `findfdt` script
can be called to construct `fdtfile` from the environment variables set
by these config options, however this script currently isn't being run.
Calling this script results in the correct device tree being retrieved:
Retrieving file: /dtbs/6.8.1+/ti/k3-am625-sk.dtb
Many boards are calling this script as part of their boot command. The
am62x currently isn't. Rectify this so that booting works correctly.
Signed-off-by: Martyn Welch <martyn.welch@collabora.com> Reviewed-by: Christopher Obbard <chris.obbard@collabora.com>
This isn't very helpful. Improve the message to tell the user that the
number is actually a line number and also tell the user in which file
they have to look.
Signed-off-by: Michael Walle <mwalle@kernel.org> Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
arm: mach-k3: am625: Fixup a53 cpu frequency by speed grade
The maximum frequency of the A53 CPU on the AM62 depends on the speed
grade of the SoC. However, this value is hardcoded in the DT for all
AM62 variants, potentially causing specifications to be exceeded. Moreover,
setting a common lower frequency for all variants increases boot time.
To prevent these issues, modify the DT at runtime from the R5 core to
adjust the A53 CPU frequency based on its speed grade.
Suggested-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Joao Paulo Goncalves <joao.goncalves@toradex.com>
arm: mach-k3: am62: Get a53 max cpu frequency by speed grade
AM62 SoC has multiple speed grades. Add function to return max A53 CPU
frequency based on grade. Fastest grade's max frequency also depends on
PMIC voltage, to simplify implementation use the smaller value.
Suggested-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Joao Paulo Goncalves <joao.goncalves@toradex.com>
Marek Vasut [Tue, 26 Mar 2024 22:13:15 +0000 (23:13 +0100)]
boot: fdt: Drop lmb_alloc*() typecasts
The lmb_alloc_base() returns phys_addr_t , map_sysmem() accepts
phys_addr_t as first parameter. Declare 'addr' as phys_addr_t and
get rid of the casts.
Marek Vasut [Tue, 26 Mar 2024 22:13:14 +0000 (23:13 +0100)]
boot: fdt: Clean up env_get_bootm_mapsize()
Reduce tmp variable use and remove unnecessary type cast in
env_get_bootm_mapsize(). This aligns the env variable parsing
with env_get_bootm_low(). No functional change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Marek Vasut [Tue, 26 Mar 2024 22:13:13 +0000 (23:13 +0100)]
boot: fdt: Fix tmp type in env_get_bootm_size() and rename to low
Change type of 'tmp' variable from phys_size_t to phys_addr_t and
rename it to 'low' to better describe what the variable represents,
which is either the bootm_low address from environment or start of
DRAM address.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Marek Vasut [Tue, 26 Mar 2024 22:13:12 +0000 (23:13 +0100)]
boot: fdt: Clean up env_get_bootm_size()
Reduce tmp variable use and remove unnecessary type cast in
env_get_bootm_size(). This aligns the env variable parsing
with env_get_bootm_low(). No functional change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Marek Vasut [Tue, 26 Mar 2024 22:13:11 +0000 (23:13 +0100)]
boot: fdt: Change type of env_get_bootm_low() to phys_addr_t
Change type of ulong env_get_bootm_low() to phys_addr_t env_get_bootm_low().
The PPC/LS systems already treat env_get_bootm_low() result as phys_addr_t,
while the function itself still returns ulong. This is potentially dangerous
on 64bit systems, where ulong might not be large enough to hold the content
of "bootm_low" environment variable. Fix it by using phys_addr_t, similar to
what env_get_bootm_size() does, which returns phys_size_t .
Simon Glass [Thu, 4 Jan 2024 15:10:39 +0000 (08:10 -0700)]
x86: Enable SSE in 64-bit mode
This is needed to support Truetype fonts. In any case, the compiler
expects SSE to be available in 64-bit mode. Provide an option to enable
SSE so that hardware floating-point arithmetic works.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> Suggested-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Thu, 4 Jan 2024 15:10:36 +0000 (08:10 -0700)]
x86: coreboot: Add a boot script
Provide the user with a list of available boot options. Selecting one
causes it to be booted. Pressing <ESC> causes U-Boot to return to the
command-line prompt.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tom Rini [Wed, 10 Apr 2024 23:06:27 +0000 (17:06 -0600)]
Merge patch series "pxe: Allow extlinux booting without CMDLINE enabled"
Simon Glass <sjg@chromium.org> says:
This series is the culmanation of the current line of refactoring
series. It adjusts pxe to call the booting functionality directly
rather than going through the command-line interface.
With this is is possible to boot using the extlinux bootmeth without
the command line enabled.
Simon Glass [Fri, 15 Dec 2023 04:19:06 +0000 (21:19 -0700)]
fastboot: Remove dependencies on CMDLINE
It is possible to boot a kernel without CMDLINE being enabled. Update
the implementation to handle this, and drop the condition from the
FASTBOOT config.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Simon Glass [Fri, 15 Dec 2023 04:19:01 +0000 (21:19 -0700)]
bootm: Make OS booting dependent on BOOTM
Booting an OS does not require the 'bootm' command, so change the
condition for these options.
Move them into boot/ so they don't depend on CMDLINE
Note that CMD_BOOTM_PRE_LOAD has been put directly into the bootm code
so will need some additional refactoring (and a test!) to allow it to
change over.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
Simon Glass [Fri, 15 Dec 2023 04:19:00 +0000 (21:19 -0700)]
bootm: Add a Kconfig option for bootm functionality
Create a separate Kconfig option which enables the bootm logic,
separate from the 'bootm' command. This will eventually allow booting
without CMDLINE enabled.
Update boards which disable CMD_BOOTM to disable BOOTM instead, since
CMD_BOOTM now depends on BOOTM
Simon Glass [Mon, 4 Dec 2023 00:29:31 +0000 (17:29 -0700)]
x86: zboot: Move environment setting into zboot_load()
The only difference between the command and the underlying logic is the
setting of envrionment variables. Move this out of the command
processing since it needs to be done in any case.
Simon Glass [Mon, 4 Dec 2023 00:29:28 +0000 (17:29 -0700)]
x86: zboot: Create a separate ZBOOT option for zboot logic
Most of the functionality of zboot is contained in the logic which
handles a zimage. Create a separate Kconfig for the logic so that it can
(later) be used without the command itself being enabled.
Enable ZBOOT by default on x86, with the command depending on that. The
existing 'imply' can therefore be removed.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
Simon Glass [Mon, 4 Dec 2023 00:29:27 +0000 (17:29 -0700)]
x86: zboot: Move command code into its own file
Much of the code in zimage.c deals with the zboot command. Move it into
a sepatate zboot.c file within the cmd/ directory. This will eventually
allow use of the zimage logic without the command being enabled.
Tom Rini [Wed, 10 Apr 2024 17:51:58 +0000 (11:51 -0600)]
Merge tag 'xilinx-for-v2024.07-rc1' of https://source.denx.de/u-boot/custodians/u-boot-microblaze
Xilinx changes for v2024.07-rc1
xilinx:
- Do not call env_get_location when !ENV_IS_NOWHERE
- Add FDT_FIXUP_PARTITIONS support
- Fix legacy format MAC decoding
zynqmp:
- Enable semihosting SPL support
- DT updates
- Kconfig resort/cleanup
- Don't describe second image/capsule if !SPL
- Add support for dfu/capsule description via MTD
- Support JTAG as alternative boot mode
- Add support for TEG soc variant
zynqmp-kria:
- Wire usb4 boot device
- Update SDIO tristate pin configuration
- Disable SPI_FLASH_BAR to avoid issue with SPI after update
mbv:
- Enable SPL and binman
- Small platform changes
zynqmp-nand:
- Error out in case of unsupported SW ECC
- Clean error path
versal-net:
- Support multiple locations for variables
Vincent Stehlé [Tue, 2 Apr 2024 11:29:16 +0000 (13:29 +0200)]
trace: use dynamic string buffer in make_flamegraph()
The str[] buffer declared in make_flamegraph() is used to hold strings
representing the full call-stacks recorded in traces. The size of this
buffer is currently 500 characters and this works well for the documented
examples.
However, it is possible to exhaust this buffer when processing traces
captured when running the UEFI shell on aarch64 sandbox for example.
Indeed, the maximum length needed for such traces can reach 780 characters.
As it is difficult to evaluate the maximum size that would ever be needed
for all the possible traces, let's use a dynamically allocated `abuf'
instead, which we reallocate when needed.
This fixes the following error:
String too short (500 chars)
While at it, fix a few typos in strings and comments.
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com> Cc: Tom Rini <trini@konsulko.com> Cc: Simon Glass <sjg@chromium.org> Cc: Michal Simek <michal.simek@amd.com>
U-Boot only knows absolute file paths. It is inconsistent to require that
saving to an ext4 file system should use a leading '/' while reading does
not. Remove the superfluous check.
The NFS protocol uses file handles to refer to file or directory.
In NFSv2 file handles have a fixed size of 32 bytes.
In NFSv3 file handles have a variable length up to 64 bytes. This is
also true for the MOUNT protocol. [1]
When the NFSv3 server replies with a file handle length > 32 bytes, U-Boot
only copies 32 bytes of that file handle and the next LOOKUP Call fails:
BIOS> nfs ${loadaddr} 192.168.1.51:/nfsroot/opos93dev-br/boot/Image
Using ethernet@428a0000 device
File transfer via NFS from server 192.168.1.51; our IP address is 192.168.1.133
Filename '/nfsroot/opos93dev-br/boot/Image'.
Load address: 0x80400000
Loading: *** ERROR: File lookup fail
done
BIOS>
Looking at this transfer in Wireshark, we can see that the server
replies with the following file handle:
Open for reading as O_RDONLY instead of O_RDWR:
the only usage of the fd is for the single read() below;
this prevented
mkimage -f auto -A arm64 \
-T kernel -C lz4 -d Image-6.6.15.lz4 \
-b mt8173-elm-hana-6.6.15.dtb outf
when the inputs were unwritable.
fs: ext4: make "File System is consistent\n" a debug message
When accessing an ext2 system the message "File System is consistent\n" is
shown after each write. This is superfluous noise. Only write a debug
message.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Greg Malysa [Wed, 20 Mar 2024 02:16:07 +0000 (22:16 -0400)]
build: Revive and update LDR format support
LDR format files are used primarily by Analog Devices processors but may
be of interest to other vendors. Previously support existed for this
format as part of the U-Boot build, but it has been unmaintained and
unused for a long time. In preparation for adding support for modern ADI
processors that use LDR, modernize the LDR support:
- Introduce CONFIG_LDR_CPU as the CPU string recognized by the LDR tool
may not be the same as CONFIG_CPU
- Add an SPL target that repackages u-boot-spl inside an LDR file
An almost identical target for packaging u-boot into an LDR file already
exists and did not need to be created.
Co-developed-by: Nathan Barrett-Morrison <nathan.morrison@timesys.com> Signed-off-by: Nathan Barrett-Morrison <nathan.morrison@timesys.com> Signed-off-by: Ian Roberts <ian.roberts@timesys.com> Signed-off-by: Greg Malysa <greg.malysa@timesys.com>
Tom Rini [Tue, 19 Mar 2024 16:51:31 +0000 (12:51 -0400)]
scripts/Makefile.spl: Use 'sort' in SHRUNK_ARCH_DTB rule
With configs such as "am64x_evm_a53" or "imx8mp_venice" which list
multiple device trees to build we get a warning such as:
scripts/Makefile.spl:578: target 'spl/dts/freescale/' given more than once in the same rule
If we sort this list first the warning goes away.
Tested-by: Michal Simek <michal.simek@amd.com> Signed-off-by: Tom Rini <trini@konsulko.com>
Jixiong Hu [Tue, 19 Mar 2024 09:20:40 +0000 (17:20 +0800)]
fs: ext4: Change the Settings of file permissions
When a file is created in the linux and corresponding file permission
is set, if the file needs to be modified in uboot during the startup
process, the modified file permission will be reset to 755. Therefore,
when the ext4fs_write() function is called, if the file already exists,
the file permission of the new file is equal to the file permission of
the existing file.
Caleb Connolly [Mon, 18 Mar 2024 23:16:36 +0000 (23:16 +0000)]
cmd: sysboot: null check filename
Currently if ${bootfile} is unset and sysboot is invoked with no
filename specified then U-Boot will crash will a null-pointer
dereference. Add the missing check and a matching error print.
arm64: Fix map_range() not splitting mapped blocks
The implementation of map_range() creates the requested mapping by
walking the page tables, iterating over multiple PTEs and/or descending
into existing table mappings as needed. When doing so, it assumes any
pre-existing valid PTE to be a table mapping. This assumption is wrong
if the platform code attempts to successively map two overlapping ranges
where the latter intersects a block mapping created for the former.
As a result, map_range() treats the existing block mapping as a table
mapping and descends into it i.e. starts interpreting the
previously-mapped range as an array of PTEs, writing to them and
potentially even descending further (extra fun with MMIO ranges!).
Instead, pass any valid non-table mapping to split_block(), which
ensures that it actually was a block mapping (calls panic() otherwise)
before splitting it.
Petr Zejdl [Thu, 4 Apr 2024 11:44:22 +0000 (13:44 +0200)]
xilinx: common: Fix MAC address read from EEPROM
The upper-to-lowercase character conversion now avoids altering the
MAC address field. In the previous version, this alteration corrupted
the MAC address.
The Kria board features a recovery application that activates
when the FW_EN button is pressed.
Upon power-up flash operates in 3B mode, However, the recovery
application changes it back to 4B mode.
Currently, after a reset, u-boot activates CONFIG_SPI_FLASH_BAR
and assumes the flash is in 3B mode. However, there's no code
or reset lines connected to the flash that could return it to
3B mode. To resolve this issue, changes were made to disable
CONFIG_SPI_FLASH_BAR, which activates 4-byte opcodes.
- RISC-V: Support backtrace and improve isa extension parsing
- cpu: Add cv1800b SoC support
- board: Add Milk-V Mars board support
- board: Add Milk-V Duo SD card support
The differences between the Milk-V Mars board and the VisionFive 2 board
are small enough that we can support both using the same U-Boot build.
* The model and compatible property are taken from proposed Linux patches.
* The EEPROM is atmel,24c02 according to the vendor U-Boot.
* The second Ethernet port is not available.
usb@10100000 does not exist in U-Boot yet. So we don't have to reflect
differences in usage here.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
projects / thirdparty / u-boot.git / log
