On eMMC device, the erase_grp_size > 1 so the address and size for the
erase block command in env/mmc.c can be unaligned on erase group size and
some strange trace occurs and the result is not guarantee by MMC devices.
The SD-Card behavior doesn't change as erase_grp_size = 1 for SD-Card.
For example, on eMMC present on STM32MP15C-EV1 and before the patch:
STM32MP> env erase
Erasing Environment on MMC...
Caution! Your devices Erase group is 0x400
The erase range would be change to 0x2000~0x27ff
16 blocks erased: OK
Caution! Your devices Erase group is 0x400
The erase range would be change to 0x2000~0x23ff
16 blocks erased: OK
OK
After this patch:
STM32MP> env erase
Erasing Environment on MMC...
1024 blocks erased at 0x2000: OK
1024 blocks erased at 0x2000: OK
OK
Here the 2 copies of U-Boot environment are in the same devices Erase
group: it is erased twice.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Fix the end address in the message for unaligned erase request in
mmc_berase() when start + blkcnt is aligned to erase_grp_size.
for example:
- start = 0x2000 - 26
- count = 26
- erase_grp_size = 0x400
Caution! Your devices Erase group is 0x400
The erase range would be change to 0x2000~0x27ff
But no issue when the end address is not aligned, for example
- start = 0x2000 - 2 * 26
- count = 26
- erase_grp_size = 0x400
Caution! Your devices Erase group is 0x400
The erase range would be change to 0x2000~0x23ff
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
This test was written to match up with the list of compatibles in
drivers/i2c/tegra_i2c.c so adding another one requires the test to be
updated to match.
Fixes: 0d2105ae5e ("arm: tegra: Update some DT compatibles")
Signed-off-by: Tom Rini <trini@konsulko.com>
Use device tree to set MAC address of the Ethernet chip.
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Some of the DT compatibles have changed upstream so add new DT compatibles
to ensure things continue to keep working if the device trees are
updated.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Add new lines to make errorr messages easier to read.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Add new lines for error messages to make them easier to read.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
UEFI:
* Ignore OsIndications if CONFIG_EFI_IGNORE_OSINDICATIONS=y
* Correct UEFI default binary name
* Let efidebug create boot options without file path
* Support booting with a boot option with shortened device only device path
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEbcT5xx8ppvoGt20zxIHbvCwFGsQFAmKm12gACgkQxIHbvCwF
GsTYDQ/+P4s0HdA8mb05PdInq2NZs1nSX89sHYLt9yC9ElBdZ3O399GmfOVDRpfa
qBjh+N0p2B6PwQc4xN0b+pn/Rj+PV8aqG06hV3ASY63xpLxq2tKvnwUKexTyb7Wz
l+StEUz63NO1PNNdSz/uDUFkLqdjV28ys6Qz8N0tUNNE63lVtxO7oNhyARc3/VRh
+Rry4/iO3tCvEr6EUGOWzWbOwt4AVUk0bBSpoBG0CvmOTjtS8lKAJXDYYqOxZxXi
J+tLramOUHgEbZmGLSFBvx9WOFHnIvAV7H4dJ19d7V2YZUwXcBNinSNjwgTDVXJ+
o5NXyxnpsyrUTdm0g9lE2hmmhz/LlrlYzIQ4Rz6v0b4Gk1ZS5fFeUVhNp6B1hTL9
hN8lJ2Jn3+inGrIRkCiG30b6qEU14YmjBpJ3Z5nZZSOkx6ce4TZNKb0VUD2DFeYc
JCHg8Cecv361cM5LS2BVT2a2+1zghEWpv4xHh0m+xAccUM3E3kdDZGo2EiLQXGvp
wPF0hX2K0LqZt6lD2Vyk5aBKTxz9XRDjzXXVKJCnLFcCSBlASRAymQu53xHd5/7L
jAtvwVhDw//IWo9bA+5qjJqdDD9zgUE0ujrVOqU9/L3Oa55hYyM0WMBiDtM0xiSY
GiPvmdDXqhCyNEfZNPcoAE6GUG1mq5Qdwt1NVQOhg85+TdvvcGI=
=Ylyv
-----END PGP SIGNATURE-----
Merge tag 'efi-2022-07-rc5' of https://source.denx.de/u-boot/custodians/u-boot-efi
Pull request for efi-2022-07-rc5
UEFI:
* Ignore OsIndications if CONFIG_EFI_IGNORE_OSINDICATIONS=y
* Correct UEFI default binary name
* Let efidebug create boot options without file path
* Support booting with a boot option with shortened device only device path
Allow booting from a short form device-path without file path, e.g.
/HD(1,GPT,5ef79931-a1aa-4c70-9d67-611e8f69eafd,0x800,0x1000)
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Only on the sandbox the default EFI binary name (e.g. BOOTX64.EFI) must
match the host architecture.
In all other cases we must use the target architecture.
Use #elif where appropriate.
Reported-by: Vagrant Cascadian <vagrant@reproducible-builds.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
The GetImageInfo function definitions for the FIT images and raw
images are the same. Use a common function for the both the Firmware
Management Protocol(FMP) instances for raw and FIT images.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
The EFI_IGNORE_OSINDICATIONS config symbol was introduced as a
mechanism to have capsule updates work even on platforms where the
SetVariable runtime service was not supported. The current logic
requires the OsIndications variable to have been set to a 64 bit value
even when the EFI_IGNORE_OSINDICATIONS config is enabled. Return an
error code on not being able to read the variable only when
EFI_IGNORE_OSINDICATIONS is not enabled.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
This patch adds a driver for configuration of the Microchip USB251xB/xBi
USB 2.0 hub controller series with USB 2.0 upstream connectivity, SMBus
configuration interface and two to four USB 2.0 downstream ports.
This is ported from Linux as of Linux kernel commit
5c2b9c61ae5d8 ("usb: usb251xb: add boost-up property support")
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Bin Meng <bmeng.cn@gmail.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: Simon Glass <sjg@chromium.org>
This is used to avoid the ports status of IPPC being brought in kernel
stage, it may cause ports error especially when the xhci controller is
a component of dual-role controller.
Reported-by: Yun-Chien Yu <yun-chien.yu@mediatek.com>
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Allow to compile assembler files in SPL build which calls WATCHDOG_RESET
function when watchdog is disabled in SPL and enabled in U-Boot proper.
This issue was fixed in past by commit 7fbd42f5af ("watchdog: Handle SPL
build with watchdog disabled") for C source files, but not for assembler
source files.
Currently the only assembler source file which calls WATCHDOG_RESET is
arch/powerpc/lib/ticks.S, so this patch affects and fixes powerpc SPL
builds.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Two defconfigs were missed when transitioning the SYS_FMAN_FW_ADDR
symbol to Kconfig. CONFIG_SYS_FMAN_FW_ADDR is currently initialized to
0 by default on these builds, which prevents the firmware from loading.
Add the correct symbols to these defconfigs.
Fixes: a97a071d10 ("configs: fsl: migrate FMAN/QE specific defines to Kconfig")
Signed-off-by: Camelia Groza <camelia.groza@nxp.com>
UEFI:
* Fix the implementation of the firmware management protocol
* Fix the unit tests for signed update capsules
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEbcT5xx8ppvoGt20zxIHbvCwFGsQFAmKbUokACgkQxIHbvCwF
GsT28A/+OWQm641wcLnt88KfTX31lI7suJK+E75wmLK205lUQT8EtqMCg/YAI1Ck
oHrEzjjmoaiGQGFtZ466adpVerRETLyJBAAWVxClzoVwqhnvfQnHuHUWRwjTVffr
FT89LQphHMQOfOPC0JIxFl9NHRQLc4cWxIskN2AfavyD+PC2PuL1g5lxPtTYlUS/
2vCyE6Hi5xZSBWv9qJDsM6DsIZF4hGgOuov8Bk/WRCuA3+rXzAtU8pSy25Q55H3C
f+shgZagpIVTSmS4+VRScGXPfTmTsM2B/Gs93bIAuGCqz/TYR9a11eHZkf7jg7Kq
UDeTVm/+VaIVThNent+KBGvrl9c/4S9iuYUv04U54FoNQz9eim98P5ELctW1mI5M
TTZy8CRblDupFKjLnJeqmjrJuNFak2jgp9T6n/X9FdiJR3EnugV+x+iGpiEyfNxq
meYi55/H0pgKaD2MCRaUeuY9LZznLQ1ZDyRxQ31+kYPU9/GEYmHS+HoiLDDuIDlF
Ok2wGRsw/hSkGbSvzdZTY+m8QAOIq0dSvV57H5kS/T48hv46NeJYmgmlIP4TUWl4
ClkElIEIOt10fRcPQC81wtzip9DuuTHnYqwXCR0XlqO27jcnw5dAN8CH7l1y7gWp
kxnPkhIVfk7jk/hyix6yVTKrn04OMWsRRa+F1ibJFTVBICdAMW8=
=Eb4i
-----END PGP SIGNATURE-----
Merge tag 'efi-2022-07-rc4-4' of https://source.denx.de/u-boot/custodians/u-boot-efi
Pull request for efi-2022-07-rc4-4
UEFI:
* Fix the implementation of the firmware management protocol
* Fix the unit tests for signed update capsules
Add support for the authentication of UEFI capsules containing FIT images.
The authentication code is moved out of the function handling raw images
into a new function efi_firmware_capsule_authenticate(). The special case
for the FMP header coming from edk2 tools is preserved. There is no
functional change for capsules containing raw images.
The python test for signed capsules with raw images is renamed with no
functional change and a new test is added for signed capsules containing
FIT images.
This can be tested with sandbox64_defconfig or sandbox_flattree_defconfig,
plus CONFIG_EFI_CAPSULE_AUTHENTICATE=y.
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Repair the python tests for authenticated EFI capsules, which can be run
with sandbox_defconfig plus CONFIG_EFI_CAPSULE_AUTHENTICATE=y.
- Account for the reset changes done by commit 3e6f810006 ("efi_loader:
test/py: Reset system after capsule update on disk").
- Fix the capsule GUID typo introduced by commit 2e9c3c6965 ("test:
capsule: Modify the capsule tests to use GUID values for sandbox").
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
The OsIndications is a 64 bit variable, and the current code expects
the value of the variable to be 64 bit. Update the documentation to
reflect this fact.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
The GetImageInfo function of the Firmware Mangement Protocol(FMP) gets
called initially to query the size of the image descriptor array that
would have to be allocated. During this call, the rest of the function
arguments, specifically pointers might be passed as NULL. Do not
populate the descriptor_count value before it is known that the call
to GetImageInfo has been made with the allocated buffer for the image
descriptors.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
"valu" should be "value".
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Since the power domain driver default select CONFIG_CLK, so we will
meet lots failures without CLK_IMX8MQ, so default select it.
Fixes: commit 4eb82c2e56 ("imx: power-domain: Get rid of SMCCC dependency")
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Add a new device tree property "u-boot,version" in the chosen node to
pass the U-Boot version to the operating system.
This can be useful to implement a firmware upgrade procedure from the
operating system.
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Nicolas Bidron and Nicolas Guigo reported the two bugs below:
"
----------BUG 1----------
In compiled versions of U-Boot that define CONFIG_IP_DEFRAG, a value of
`ip->ip_len` (IP packet header's Total Length) higher than `IP_HDR_SIZE`
and strictly lower than `IP_HDR_SIZE+8` will lead to a value for `len`
comprised between `0` and `7`. This will ultimately result in a
truncated division by `8` resulting value of `0` forcing the hole
metadata and fragment to point to the same location. The subsequent
memcopy will overwrite the hole metadata with the fragment data. Through
a second fragment, this can be exploited to write to an arbitrary offset
controlled by that overwritten hole metadata value.
This bug is only exploitable locally as it requires crafting two packets
the first of which would most likely be dropped through routing due to
its unexpectedly low Total Length. However, this bug can potentially be
exploited to root linux based embedded devices locally.
```C
static struct ip_udp_hdr *__net_defragment(struct ip_udp_hdr *ip, int *lenp)
{
static uchar pkt_buff[IP_PKTSIZE] __aligned(PKTALIGN);
static u16 first_hole, total_len;
struct hole *payload, *thisfrag, *h, *newh;
struct ip_udp_hdr *localip = (struct ip_udp_hdr *)pkt_buff;
uchar *indata = (uchar *)ip;
int offset8, start, len, done = 0;
u16 ip_off = ntohs(ip->ip_off);
/* payload starts after IP header, this fragment is in there */
payload = (struct hole *)(pkt_buff + IP_HDR_SIZE);
offset8 = (ip_off & IP_OFFS);
thisfrag = payload + offset8;
start = offset8 * 8;
len = ntohs(ip->ip_len) - IP_HDR_SIZE;
```
The last line of the previous excerpt from `u-boot/net/net.c` shows how
the attacker can control the value of `len` to be strictly lower than
`8` by issuing a packet with `ip_len` between `21` and `27`
(`IP_HDR_SIZE` has a value of `20`).
Also note that `offset8` here is `0` which leads to `thisfrag = payload`.
```C
} else if (h >= thisfrag) {
/* overlaps with initial part of the hole: move this hole */
newh = thisfrag + (len / 8);
*newh = *h;
h = newh;
if (h->next_hole)
payload[h->next_hole].prev_hole = (h - payload);
if (h->prev_hole)
payload[h->prev_hole].next_hole = (h - payload);
else
first_hole = (h - payload);
} else {
```
Lower down the same function, execution reaches the above code path.
Here, `len / 8` evaluates to `0` leading to `newh = thisfrag`. Also note
that `first_hole` here is `0` since `h` and `payload` point to the same
location.
```C
/* finally copy this fragment and possibly return whole packet */
memcpy((uchar *)thisfrag, indata + IP_HDR_SIZE, len);
```
Finally, in the above excerpt the `memcpy` overwrites the hole metadata
since `thisfrag` and `h` both point to the same location. The hole
metadata is effectively overwritten with arbitrary data from the
fragmented IP packet data. If `len` was crafted to be `6`, `last_byte`,
`next_hole`, and `prev_hole` of the `first_hole` can be controlled by
the attacker.
Finally the arbitrary offset write occurs through a second fragment that
only needs to be crafted to write data in the hole pointed to by the
previously controlled hole metadata (`next_hole`) from the first packet.
### Recommendation
Handle cases where `len` is strictly lower than 8 by preventing the
overwrite of the hole metadata during the memcpy of the fragment. This
could be achieved by either:
* Moving the location where the hole metadata is stored when `len` is
lower than `8`.
* Or outright rejecting fragmented IP datagram with a Total Length
(`ip_len`) lower than 28 bytes which is the minimum valid fragmented IP
datagram size (as defined as the minimum fragment of 8 octets in the IP
Specification Document:
[RFC791](https://datatracker.ietf.org/doc/html/rfc791) page 25).
----------BUG 2----------
In compiled versions of U-Boot that define CONFIG_IP_DEFRAG, a value of
`ip->ip_len` (IP packet header's Total Length) lower than `IP_HDR_SIZE`
will lead to a negative value for `len` which will ultimately result in
a buffer overflow during the subsequent `memcpy` that uses `len` as it's
`count` parameter.
This bug is only exploitable on local ethernet as it requires crafting
an invalid packet to include an unexpected `ip_len` value in the IP UDP
header that's lower than the minimum accepted Total Length of a packet
(21 as defined in the IP Specification Document:
[RFC791](https://datatracker.ietf.org/doc/html/rfc791)). Such packet
would in all likelihood be dropped while being routed to its final
destination through most routing equipment and as such requires the
attacker to be in a local position in order to be exploited.
```C
static struct ip_udp_hdr *__net_defragment(struct ip_udp_hdr *ip, int *lenp)
{
static uchar pkt_buff[IP_PKTSIZE] __aligned(PKTALIGN);
static u16 first_hole, total_len;
struct hole *payload, *thisfrag, *h, *newh;
struct ip_udp_hdr *localip = (struct ip_udp_hdr *)pkt_buff;
uchar *indata = (uchar *)ip;
int offset8, start, len, done = 0;
u16 ip_off = ntohs(ip->ip_off);
/* payload starts after IP header, this fragment is in there */
payload = (struct hole *)(pkt_buff + IP_HDR_SIZE);
offset8 = (ip_off & IP_OFFS);
thisfrag = payload + offset8;
start = offset8 * 8;
len = ntohs(ip->ip_len) - IP_HDR_SIZE;
```
The last line of the previous excerpt from `u-boot/net/net.c` shows
where the underflow to a negative `len` value occurs if `ip_len` is set
to a value strictly lower than 20 (`IP_HDR_SIZE` being 20). Also note
that in the above excerpt the `pkt_buff` buffer has a size of
`CONFIG_NET_MAXDEFRAG` which defaults to 16 KB but can range from 1KB to
64 KB depending on configurations.
```C
/* finally copy this fragment and possibly return whole packet */
memcpy((uchar *)thisfrag, indata + IP_HDR_SIZE, len);
```
In the above excerpt the `memcpy` overflows the destination by
attempting to make a copy of nearly 4 gigabytes in a buffer that's
designed to hold `CONFIG_NET_MAXDEFRAG` bytes at most which leads to a DoS.
### Recommendation
Stop processing of the packet if `ip_len` is lower than 21 (as defined
by the minimum length of a data carrying datagram in the IP
Specification Document:
[RFC791](https://datatracker.ietf.org/doc/html/rfc791) page 34)."
Add a check for ip_len lesser than 28 and stop processing the packet
in this case.
Such a check covers the two reported bugs.
Reported-by: Nicolas Bidron <nicolas.bidron@nccgroup.com>
Signed-off-by: Fabio Estevam <festevam@denx.de>
The AArch64 TCR_ELx register is a 64-bit register, and many newer
architecture features use bits in the upper half. So far U-Boot was
igorant of those bits, trying to leave them alone.
However, in an effort to set bit 31 to 1, it failed doing so, because
the compiler sign-extended "1 << 31", so that all bits[63:31] got set.
Older ARMv8.0 cores don't define anything dangerous up there, but newer
architecture revisions do, and setting all those bits will end badly:
=================
$ qemu-system-aarch64 -cpu max ....
U-Boot 2022.07-rc1 (May 09 2022 - 15:21:00 +0100)
DRAM: 1.5 GiB
================= (hangs here)
Defining TCR_ELx_RSVD to "1U << 31" avoids the sign-extension, so all
upper bits stay at a safe 0 value. This means no more surprises when
U-Boot runs on a more capable CPU core.
Reported-by: Balaji Anandapadmanaban <Balaji.Anandapadmanaban@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Tested-by: Peter Collingbourne <pcc@google.com>
Reviewed-by: Peter Collingbourne <pcc@google.com>
If the device fails to probe - for example, when there is no
ethaddr set - then the private data is automatically freed
but the mdiobus remains registered.
Fixes: 1e354cb393 ("drivers: net: fsl_enetc: register internal MDIO bus")
Signed-off-by: Michael Walle <michael@walle.cc>
Commit b1a14f8a1c ("UBIFS: Change ubifsload to not read beyond the
requested size") added optimization to do not read more bytes than it is
really needed. But this commit introduced incorrect handling of the hole at
the end of file. This logic cause U-Boot to crash or lockup when trying to
read from the ubifs filesystem.
When read_block() call returns -ENOENT error (not an error, but the hole)
then dn-> structure is not filled and contain garbage. So using of dn->size
for memcpy() argument cause that U-Boot tries to copy unspecified amount of
bytes from possible unmapped memory. Which randomly cause lockup of P2020
CPU.
Fix this issue by copying UBIFS_BLOCK_SIZE bytes from read buffer when
dn->size is not available. UBIFS_BLOCK_SIZE is the size of the buffer
itself and read_block() fills buffer by zeros when it returns -ENOENT.
This patch fixes ubifsload on P2020.
Fixes: b1a14f8a1c ("UBIFS: Change ubifsload to not read beyond the requested size")
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
UEFI:
* fix a problem in loading an image from a short-path
* fix building the bootmenu command for CONFIG_EFI_LOADER=n
* correct the bootefi command syntax
* add firmware management protocol to the documentation
Others:
* bootmenu: fix bootmenu title handling
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEbcT5xx8ppvoGt20zxIHbvCwFGsQFAmKVrnUACgkQxIHbvCwF
GsRzqA//Wrr9DzoYEdOHlRUc87SN3AjVGSwH6GvD6AJZY5aLQxc5crg2dNtf2YvD
NmWXBLb58a2iyA2QO2KSJB8+Of/4ZhXi3chmw5KOxRVw2NFQGLYEmKjgPWRbg46X
ijygtI4XmcNQSPgKe+IcXHu5rED4YtmvK55bfD60Zg1qeWXrlNtQw7MI0HI7o6ct
+1YGG6aXbqyobzGdDGTpXRzwNlrkqqnBw3u+ckpDvnNMrEHSYKJZQ9KBd2fnlnvY
vLM7MnwbZaIBdd9bG6dlNUgRsvzjTmUCoye0llZ0teo8VjIRNiyeXbPgJvuMB074
4Kw23dfHvvQnMehuqORJ0rFMJN4LqwlageHfb0hTZsLSfDDhTMLbNcGJQbWbfMBp
3i5KUtNDMs8Go4ODQV9QNvW0jk+VPE2O9Q6uT1bZMDVuG0fTvJDCxopeoEn8UZFl
kc3IyukPH8G7l0TL5JGR4wtFitBjBNWtpMuOUO8GHtjZAi6j32pS5oG7z2lrz2l7
cYuLJYYYP+Tw3N4/LI5R6lEbMMCLTDZvTiUOWaYjCz8A5tL/HntgZ7AAP6bSnarD
rujnUkYFoYc5VIaDftVm/MVzU9Dn1Mr/wAySSOUrmDJBa45DIs/MV1JnRO+VxjOA
jIFWRt5l1ckWRvancZuKp9uwrGoZXYe18oya3l24/qaTkUSuZ4k=
=LXcP
-----END PGP SIGNATURE-----
Merge tag 'efi-2022-07-rc4-3' of https://source.denx.de/u-boot/custodians/u-boot-efi
Pull request for efi-2022-07-rc4-3
UEFI:
* fix a problem in loading an image from a short-path
* fix building the bootmenu command for CONFIG_EFI_LOADER=n
* correct the bootefi command syntax
* add firmware management protocol to the documentation
Others:
* bootmenu: fix bootmenu title handling
Tested-by: Pali Rohár <pali@kernel.org> [n900, for bootmenu working as before]
The commit a3d0aa87ac ("bootmenu: update bootmenu_entry structure")
changes the bootmenu title type from char to u16(UTF16 string)
to support EFI based system. If EFI_LOADER is not enabled,
printf("%ls") is not supported, so bootmenu does not appear
correctly.
This commit changes the type of menu title from u16(UTF16) to
utf-8 string and EFI strings is conveted into utf-8.
Fixes: a3d0aa87ac ("bootmenu: update bootmenu_entry structure")
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Tested-by: Pali Rohar <pali@kernel.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
The firmware management protocol can be used to manage device firmware.
U-Boot can be configured to provide an implementation.
Document the related functions in the API section.
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
This fixes the following warnings:
./lib/efi_loader/efi_firmware.c:283: warning: Function parameter or member 'package_version' not described in 'efi_firmware_fit_get_image_info'
./lib/efi_loader/efi_firmware.c:283: warning: Function parameter or member 'package_version_name' not described in 'efi_firmware_fit_get_image_info'
./lib/efi_loader/efi_firmware.c:369: warning: bad line: firmware image
./lib/efi_loader/efi_firmware.c:395: warning: Function parameter or member 'package_version' not described in 'efi_firmware_raw_get_image_info'
./lib/efi_loader/efi_firmware.c:395: warning: Function parameter or member 'package_version_name' not described in 'efi_firmware_raw_get_image_info'
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
This commit fixes the following compile warnings
for the documentation.
./include/charset.h:276: warning: Function parameter or member 'size' not described in 'u16_strlcat'
./include/charset.h:276: warning: Excess function parameter 'count' description in 'u16_strlcat'
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Booting from a short-form device path which starts with the first element
being a File Path Media Device Path failed because it doesn't contain
any valid device with simple file system protocol and efi_dp_find_obj()
in efi_load_image_from_path() will return NULL.
For instance,
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(0,0)/\helloworld.efi
-> shortened version: /\helloworld.efi
With this patch applied, all the media devices with simple file system
protocol are enumerated and the boot manager attempts to boot temporarily
generated device paths one-by-one.
This new implementation is still a bit incompatible with the UEFI
specification in terms of:
* not creating real boot options
* not try
"If a device does not support the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL, but
supports the EFI_BLOCK_IO_PROTOCOL protocol, then the EFI Boot Service
ConnectController must be called for this device with DriverImageHandle
and RemainingDevicePath set to NULL and the Recursive flag is set to TRUE."
(See section 3.1.2 "Load Option Processing".)
But it still gives us a closer and better solution than the current.
Fixes: commit 9cdf470274 ("efi_loader: support booting via short-form device-path")
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
This helper function will be used to determine if the device is
removable media, initially for handling a short-path loading.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
For indicating the address and size of a memory region other commands use a
<addr>[:<size>] syntax. Do the same for bootefi.
Fixes: 2058983689 ("cmd: bootefi: restore ability to boot arbitrary blob")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Changing the console timeout to 500 ms without restoring the original value
leads to failures in other tests. As the console timeout change is not
necessary for the text input protocol tests remove it.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
