aboutsummaryrefslogtreecommitdiff
path: root/lib
AgeCommit message (Collapse)AuthorFilesLines
2024-04-13Fix references to trace docVincent Stehlé1-1/+1
The README.trace has been moved and converted to rst in commit dce26c7d56ed ("doc: move README.trace to HTML documentation"); fix all the remaining references to this file. Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com> Cc: Tom Rini <trini@konsulko.com> Cc: Simon Glass <sjg@chromium.org> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2024-04-13efi_loader: using EFI_UNSUPPORTED for private authenticated variablesWeizhao Ouyang1-0/+1
Improve error message for UEFI SCT tests. Signed-off-by: Weizhao Ouyang <o451686892@gmail.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2024-04-13efi_loader: 'EFI using ACPI tables at' should be debug messageHeinrich Schuchardt1-1/+1
The message "EFI using ACPI tables at %lx\n" is only of interest when debugging. Make it a debug message. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2024-04-13efi_loader: eliminate duplicate runtime section definitionsHeinrich Schuchardt1-0/+1
The following symbols are defined in two includes: * __efi_runtime_start[] * __efi_runtime_stop[] * __efi_runtime_rel_start[] * __efi_runtime_rel_stop[] Eliminate the definitions in efi_loader.h. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2024-04-13efi_loader: move efi_var_collect to common functionsIlias Apalodimas3-65/+75
efi_var_collect() was initially placed in efi_var_file.c, since back then we only supported efi variables stored in a file. Since then we support variables stored in an RPMB as well and use that function to collect variables that should be present at runtime. So let's move it around in efi_var_common.c which makes more sense Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Ilias Apalodimas <apalos@gmail.com> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2024-04-12Merge patch series "zlib: Address CVE-2016-9841"Tom Rini6-141/+84
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 And gitlab CI is also not showing any issue.
2024-04-12zlib: Remove incorrect ZLIB_VERSIONMichal Simek4-18/+7
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>
2024-04-12zlib: Port fix for CVE-2016-9841 to U-BootMichal Simek1-88/+42
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>
2024-04-12zlib: Rename write variable to wnext (window write index)Michal Simek3-22/+22
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>
2024-04-12zlib: Rename this variable to here (current decoding table entry)Michal Simek1-14/+14
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>
2024-04-10lib: add missing line breaks in debug messagesMaxim Moskalets1-4/+4
Add missing line breaks to improve debug log readability. Signed-off-by: Maxim Moskalets <maximmosk4@gmail.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2024-04-08efi_loader: access __efi_runtime_rel_start/stop without &Ilias Apalodimas1-3/+3
A symbol defined in a linker script (e.g. __efi_runtime_rel_start = .;) is only a symbol, not a variable and should not be dereferenced. The common practice is either define it as extern uint32_t __efi_runtime_rel_start or extern char __efi_runtime_rel_start[] and access it as &__efi_runtime_rel_start or __efi_runtime_rel_start respectively. So let's access it properly since we define it as an array Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2024-04-08efi_loader: access __efi_runtime_start/stop without &Ilias Apalodimas1-2/+2
A symbol defined in a linker script (e.g. __efi_runtime_start = .;) is only a symbol, not a variable and should not be dereferenced. The common practice is either define it as extern uint32_t __efi_runtime_start or extern char __efi_runtime_start[] and access it as &__efi_runtime_start or __efi_runtime_start respectively. So let's access it properly since we define it as an array Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2024-04-08efi_loader: move HOST_ARCH to version_autogenerated.hHeinrich Schuchardt1-2/+1
efi_default_filename.h requires HOST_ARCH to be defined. Up to now we defined it via a CFLAGS. This does not scale. Add the symbol to version_autogenerated.h instead. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2024-04-08boot: enable booting via EFI boot manager by defaultHeinrich Schuchardt1-1/+0
If UEFI is enabled in U-Boot, we want it to conform to the UEFI specification. This requires enabling the boot manager boot method. Reported-by: E Shattow <lucent@gmail.com> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2024-04-08efi_loader: Don't delete variable from memory if adding a new one failedIlias Apalodimas1-1/+2
Our efi_var_mem_xxx() functions don't have a replace variant. Instead we add a new variable and delete the old instance when trying to replace a variable. Currently we delete the old version without checking the new one got added Signed-off-by: Ilias Apalodimas <apalos@gmail.com> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2024-04-08efi_loader: handle EFI_VARIABLE_ENHANCED_AUTHENTICATED_ACCESSHeinrich Schuchardt1-2/+6
We don't yet support EFI_VARIABLE_ENHANCED_AUTHENTICATED_ACCESS for file based variables, but we should pass it to TEE based variable stores. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2024-04-08efi_loader: EFI_VARIABLE_READ_ONLY should be 32bitHeinrich Schuchardt1-2/+2
GetVariable() and SetVariable() only accept a 32bit value for attributes. It makes not sense to define EFI_VARIABLE_READ_ONLY as unsigned long. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2024-04-08efi_loader: all variable attributes are 32bitHeinrich Schuchardt2-3/+3
GetVariable() and SetVariable() use an uint32_t value for attributes. The UEFI specification defines the related constants as 32bit. Add the missing EFI_VARIABLE_ENHANCED_AUTHENTICATED_ACCESS constant. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2024-04-08efi_loader: fix append write behavior to non-existent variableMasahisa Kojima2-8/+66
Current "variables" efi_selftest result is inconsistent between the U-Boot file storage and the tee-based StandaloneMM RPMB secure storage. U-Boot file storage implementation does not accept SetVariale call to non-existent variable with EFI_VARIABLE_APPEND_WRITE, it return EFI_NOT_FOUND. However it is accepted and new variable is created in EDK II StandaloneMM implementation if valid data and size are specified. If data size is 0, EFI_SUCCESS is returned. Since UEFI specification does not clearly describe the behavior of the append write to non-existent variable, let's update the U-Boot file storage implementation to get aligned with the EDK II reference implementation. Signed-off-by: Masahisa Kojima <kojima.masahisa@socionext.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Tested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2024-03-29Merge patch series "Clean up arm linker scripts"WIP/29Mar2024-next-ldsTom Rini1-0/+1
Ilias Apalodimas <ilias.apalodimas@linaro.org> says: The arm linker scripts had a mix of symbols and C defined variables in an effort to emit relative references instead of absolute ones e.g [0]. A linker bug prevented us from doing so [1] -- fixed since 2016. This has led to confusion over the years, ending up with mixed section definitions. Some sections are defined with overlays and different definitions between v7 and v8 architectures. For example __efi_runtime_rel_start/end is defined as a linker symbol for armv8 and a C variable in armv7. Linker scripts nowadays can emit relative references, as long as the symbol definition is contained within the section definition. So let's switch most of the C defined variables and clean up the arm sections.c file. There's still a few symbols remaining -- __secure_start/end, __secure_stack_start/end and __end which can be cleaned up in a followup series. For both QEMU v7/v8 bloat-o-meter shows now size difference $~ ./scripts/bloat-o-meter u-boot u-boot.new add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0) Function old new delta Total: Before=798861, After=798861, chg +0.00% The symbols seem largely unchanged apart from a difference in .bss as well as the emited sections and object types of the affected variables. On the output below the first value is from -next and the second comes from -next + this patchset. The .bss_start/end sections have disappeared from the newer binaries. # For example on QEMU v8: efi_runtime_start 7945: 0000000000000178 0 OBJECT GLOBAL DEFAULT 2 __efi_runtime_start 7942: 0000000000000178 0 NOTYPE GLOBAL DEFAULT 2 __efi_runtime_start efi_runtime_stop 9050: 0000000000000d38 0 OBJECT GLOBAL DEFAULT 2 __efi_runtime_stop 9047: 0000000000000d38 0 NOTYPE GLOBAL DEFAULT 2 __efi_runtime_stop __efi_runtime_rel_start 7172: 00000000000dc2f0 0 OBJECT GLOBAL DEFAULT 10 __efi_runtime_rel_start 7169: 00000000000dc2f0 0 NOTYPE GLOBAL DEFAULT 10 __efi_runtime_rel_start __efi_runtime_rel_stop 7954: 00000000000dc4a0 0 OBJECT GLOBAL DEFAULT 10 __efi_runtime_rel_stop 7951: 00000000000dc4a0 0 NOTYPE GLOBAL DEFAULT 10 __efi_runtime_rel_stop __rel_dyn_start 7030: 00000000000dc4a0 0 OBJECT GLOBAL DEFAULT 11 __rel_dyn_start 7027: 00000000000dc4a0 0 NOTYPE GLOBAL DEFAULT 11 __rel_dyn_start __rel_dyn_end 8959: 0000000000102b10 0 OBJECT GLOBAL DEFAULT 12 __rel_dyn_end 8956: 0000000000102b10 0 NOTYPE GLOBAL DEFAULT 11 __rel_dyn_end image_copy_start 9051: 0000000000000000 0 OBJECT GLOBAL DEFAULT 1 __image_copy_start 9048: 0000000000000000 0 NOTYPE GLOBAL DEFAULT 1 __image_copy_start image_copy_end 7467: 00000000000dc4a0 0 OBJECT GLOBAL DEFAULT 11 __image_copy_end 7464: 00000000000dc4a0 0 NOTYPE GLOBAL DEFAULT 11 __image_copy_end bss_start 12: 0000000000102b10 0 SECTION LOCAL DEFAULT 12 .bss_start 8087: 0000000000000018 0 NOTYPE GLOBAL DEFAULT 1 _bss_start_ofs 8375: 0000000000102b10 0 OBJECT GLOBAL DEFAULT 12 __bss_start 8084: 0000000000000018 0 NOTYPE GLOBAL DEFAULT 1 _bss_start_ofs 8372: 0000000000102b10 0 NOTYPE GLOBAL DEFAULT 12 __bss_start bss_end 14: 000000000010bc30 0 SECTION LOCAL DEFAULT 14 .bss_end 7683: 000000000010bc30 0 OBJECT GLOBAL DEFAULT 14 __bss_end 8479: 0000000000000020 0 NOTYPE GLOBAL DEFAULT 1 _bss_end_ofs 7680: 000000000010bbb0 0 NOTYPE GLOBAL DEFAULT 12 __bss_end 8476: 0000000000000020 0 NOTYPE GLOBAL DEFAULT 1 _bss_end_ofs # For QEMU v7: efi_runtime_start 10703: 000003bc 0 OBJECT GLOBAL DEFAULT 2 __efi_runtime_start 10699: 000003c0 0 NOTYPE GLOBAL DEFAULT 2 __efi_runtime_start efi_runtime_stop 11796: 000012ec 0 OBJECT GLOBAL DEFAULT 2 __efi_runtime_stop 11792: 000012ec 0 NOTYPE GLOBAL DEFAULT 2 __efi_runtime_stop __efi_runtime_rel_start 9937: 000c40dc 0 OBJECT GLOBAL DEFAULT 8 __efi_runtime_rel_start 9935: 000c40dc 0 NOTYPE GLOBAL DEFAULT 9 __efi_runtime_rel_start __efi_runtime_rel_stop 10712: 000c41dc 0 OBJECT GLOBAL DEFAULT 10 __efi_runtime_rel_stop 10708: 000c41dc 0 NOTYPE GLOBAL DEFAULT 9 __efi_runtime_rel_stop __rel_dyn_start 9791: 000c41dc 0 OBJECT GLOBAL DEFAULT 10 __rel_dyn_start 9789: 000c41dc 0 NOTYPE GLOBAL DEFAULT 10 __rel_dyn_start __rel_dyn_end 11708: 000da5f4 0 OBJECT GLOBAL DEFAULT 10 __rel_dyn_end 11704: 000da5f4 0 NOTYPE GLOBAL DEFAULT 10 __rel_dyn_end image_copy_start 448: 0000177c 0 NOTYPE LOCAL DEFAULT 3 _image_copy_start_ofs 11797: 00000000 0 OBJECT GLOBAL DEFAULT 1 __image_copy_start 445: 0000177c 0 NOTYPE LOCAL DEFAULT 3 _image_copy_start_ofs 11793: 00000000 0 NOTYPE GLOBAL DEFAULT 1 __image_copy_start image_copy_end 450: 00001780 0 NOTYPE LOCAL DEFAULT 3 _image_copy_end_ofs 10225: 000c41dc 0 OBJECT GLOBAL DEFAULT 10 __image_copy_end 447: 00001780 0 NOTYPE LOCAL DEFAULT 3 _image_copy_end_ofs 10222: 000c41dc 0 NOTYPE GLOBAL DEFAULT 10 __image_copy_end bss_start 11: 000c41dc 0 SECTION LOCAL DEFAULT 11 .bss_start 11124: 000c41dc 0 OBJECT GLOBAL DEFAULT 11 __bss_start 11120: 000c41dc 0 NOTYPE GLOBAL DEFAULT 11 __bss_start bss_end 13: 000cbbf8 0 SECTION LOCAL DEFAULT 13 .bss_end 10442: 000cbbf8 0 OBJECT GLOBAL DEFAULT 13 __bss_end 10439: 000cbbf8 0 NOTYPE GLOBAL DEFAULT 11 __bss_end It's worth noting that since the efi regions are affected by the change, booting with EFI is preferable while testing. Booting the kernel only should be enough since the efi stub and the kernel proper do request boottime and runtime services respectively. Something along the lines of > virtio scan && load virtio 0 $kernel_addr_r Image && bootefi $kernel_addr_r will work for QEMU aarch64. Tested platforms: - QEMU aarch64 - Xilinx kv260 kria starter kit & zynq - QEMU armv7 - STM32MP157C-DK2 [0] commit 3ebd1cbc49f0 ("arm: make __bss_start and __bss_end__ compiler-generated") [1] binutils commit 6b3b0ab89663 ("Make linker assigned symbol dynamic only for shared object")
2024-03-29arm: fix __efi_runtime_rel_start/end definitionsIlias Apalodimas1-0/+1
__efi_runtime_rel_start/end are defined as c variables for arm7 only in order to force the compiler emit relative references. However, defining those within a section definition will do the same thing since [0]. On top of that the v8 linker scripts define it as a symbol. So let's remove the special sections from the linker scripts, the variable definitions from sections.c and define them as a symbols within the correct section. [0] binutils commit 6b3b0ab89663 ("Make linker assigned symbol dynamic only for shared object") Suggested-by: Sam Edwards <CFSworks@gmail.com> Reviewed-by: Sam Edwards <CFSworks@gmail.com> Tested-by: Sam Edwards <CFSworks@gmail.com> # Binary output identical Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2024-03-27smbios: fill wake-up typeHeinrich Schuchardt1-0/+1
We should not use the reserved value 0x00 for the wake up type but use 0x02 (Unknown). Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2024-03-27acpi: rename aslc_id, aslc_revisionHeinrich Schuchardt2-3/+3
The fields Creator ID and Creator Revision contain information about the tool that created an ACPI table. This may be the ASL compiler for some tables but it is not for others. Naming these fields aslc_id and aslc_revision is misleading. It is usual to see diverse values of Creator ID. On a laptop I saw these: 'AMD ', 'INTL, 'MSFT', 'PTEC'. Obviously not all relate to the Intel ASL compiler. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2024-03-25Merge tag 'v2024.04-rc5' into nextWIP/25Mar2024-nextTom Rini1-5/+11
Prepare v2024.04-rc5
2024-03-21efi_loader: correct handling of EFI binary return codeHeinrich Schuchardt1-5/+11
We should not try to remove protocol interfaces from a NULL handle. efi_run_image() should always return the return code of the executed EFI binary. Fixes: 6422820ac3e5 ("efi_loader: split unrelated code from efi_bootmgr.c") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2024-03-21efi_selftest: Update StrToFat() unit test after CP473 map extensionJanne Grunau1-0/+12
Test that Unicode code points which map to CP437 code points 1-31 are converted to '_'. This ensures no FAT file names do not contain chars which are control characters in other code pages (CP 1250 for example). Signed-off-by: Janne Grunau <j@jannau.net> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2024-03-21efi_selftest: Add geometric shapes character selftestJanne Grunau1-0/+13
Draw symbols from Unicode's "Geometric shapes" page which translate to code page 437 code points 1-31. These are used by UEFI applications to draw user interfaces using EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL. The output has to be checked manually on the screen for correctness. Signed-off-by: Janne Grunau <j@jannau.net> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2024-03-21efi_selftest: Add box drawing character selftestAndre Przywara1-0/+20
UEFI applications rely on Unicode output capability, and might use that for drawing pseudo-graphical interfaces using Unicode defined box drawing characters. Add a simple test to display the most basic box characters, which would need to be checked manually on the screen for correctness. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Janne Grunau <j@jannau.net> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2024-03-21efi_selftest: Add international characters testAndre Przywara1-0/+21
UEFI relies entirely on unicode output, which actual fonts displayed on the screen might not be ready for. Add a test displaying some international characters, to reveal missing glyphs, especially in our builtin fonts. This would be needed to be manually checked on the screen for correctness. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Janne Grunau <j@jannau.net> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2024-03-21lib/charset: Map Unicode code points to CP437 code points 1-31Janne Grunau2-4/+7
Code page 437 uses code points 1-31 for glyphs instead of control characters. Map the appropriate Unicode code points to this code points. Fixes rendering of grub2's menu as EFI application using the EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL on a console with bitmap fonts. Signed-off-by: Janne Grunau <j@jannau.net>
2024-03-19Merge tag 'u-boot-socfpga-next-20240319' of ↵WIP/19Mar2024-nextTom Rini1-4/+7
https://source.denx.de/u-boot/custodians/u-boot-socfpga into next - A new driver in the misc to register setting from device tree. This also provides user a clean interface and all register settings are centralized in one place, device tree. - Enable Agilex5 platform for Intel product. Changes, modification and new files are created for board, dts, configs and makefile to create the base for Agilex5. Build-tested on SoC64 boards, boot tested on some of them.
2024-03-13initcall: break loop immediately on failureCaleb Connolly1-1/+3
The current ordering always results in func pointing to the next function in the init_sequence. e.g. if fdtdec_setup() fails, ret will be set to the error code, then func will be updated to point to initf_malloc(), only then is ret checked and the loop broken. The end result of this is that the "initcall failed at ..." error will point you to initf_malloc(), when the error actually occured in fdtdec_setup()! This can be quite confusing and result in a lot of time wasted debugging code that has nothing to do with the failure (ask me how I know :P). Adjust the for loop to check ret immediately after the call and break early so that func will correctly reference the failed function. Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org> Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org>
2024-03-13efi_loader: Don't carve out memory reservations too earlyMark Kettenis1-4/+7
Moving the efi_carve_out_dt_rsv() call in commit 1be415b21b2d ("efi_loader: create memory reservations in ACPI case") broke boards that create additional memory reservations in ft_board_setup() since it is now called before those additional memory reservations are made. This is the case for the rk3588 boards and breaks booting OpenBSD on those boards. Move the call back to its original location and add a call in the code path used for ACPI. Fixes: 1be415b21b2d ("efi_loader: create memory reservations in ACPI case") Signed-off-by: Mark Kettenis <kettenis@openbsd.org> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2024-03-07Check curve_name for null to avoid crashBob Wolff1-0/+5
If mixed rsa and ecdsa keys are specified in dtsi, an rsa key can be sent into the ecdsa verify. Without the ecdsa,curve property, this function will crash due to lack of checking the null pointer return. Signed-off-by: Bob Wolff <bob.wolff68@gmail.com>
2024-02-28efi_driver: provide SBI based runtime system resetHeinrich Schuchardt3-1/+31
On RISC-V systems system the Supervisory Binary Interface provides system reset and poweroff. Use it at EFI runtime. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2024-02-12efi_loader: simplify error message in efi_disk_create_raw()Heinrich Schuchardt1-1/+2
The error message Adding disk for usb_mass_storage.lun0 failed (err=-9223372036854775788/0x8000000000000014) provides a decimal and a hexadecimal notation of the EFI status code EFI_ALREADY_STARTED which is defined as (EFI_ERROR_MASK | 20). The decimal output does not convey the value 20 clearly. With the patch we write Adding block device usb_mass_storage.lun0 failed, r = 20 similar to other EFI error messages. Fixes: 952018117ab4 ("dm: sandbox: Switch over to using the new host uclass") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2024-02-09lib: sparse: Fix error checking for write_sparse_chunk_rawSean Anderson1-1/+1
The return value of write_sparse_chunk_raw is unsigned, so the existing check has no effect. Use IS_ERR_VALUE to detect error instead, which is what write_sparse_chunk_raw does itself. Fixes: 62649165cb0 ("lib: sparse: Make CHUNK_TYPE_RAW buffer aligned") Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://lore.kernel.org/u-boot/1b323ec3-59b0-490b-a2f0-fd961dafcf49@moroto.mountain/ Signed-off-by: Sean Anderson <sean.anderson@seco.com> Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com> Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> Link: https://lore.kernel.org/r/20240201181851.221701-1-sean.anderson@seco.com Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
2024-02-02smbios: correctly name Structure Table Maximum Size fieldHeinrich Schuchardt4-7/+7
In the SMBIOS 3 entry point the Structure Table Maximum Size field was incorrectly named max_struct_size. A Maximum Structure Size field only exists in the SMBIOS 2.1 entry point and has a different meaning. Call the Structure Table Length field table_maximum_size. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2024-02-02smbios: do not determine maximum structure sizeHeinrich Schuchardt1-6/+1
Only the SMBIOS 2.1 entry point has a field for the maximum structure size. As we have switched to an SMBIOS 3 entry point remove the superfluous calculation. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2024-02-02smbios: correctly fill chassis handleHeinrich Schuchardt1-0/+2
The chassis handle field in the type 2 structure must point to the handle of the type 3 structure. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2024-02-02smbios: if a string value is unknown, use string number 0Heinrich Schuchardt1-15/+18
The SMBIOS specification describes: "If a string field references no string, a null (0) is placed in that string field." Accordingly we should avoid writing a string "Unknown" to the SMBIOS table. dmidecode displays 'Not Specified' if the string number is 0. Commit 00a871d34e2f ("smbios: empty strings in smbios_add_string()") correctly identified that strings may not have length 0 as two consecutive NULs indentify the end of the string list. But the suggested solution did not match the intent of the SMBIOS specification. Fixes: 00a871d34e2f ("smbios: empty strings in smbios_add_string()") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2024-02-02smbios: Fix table when no string is presentMatthias Brugger1-0/+4
When no string is present in a table, next_ptr points to the same location as eos. When calculating the string table length, we would only reserve one \0. By spec a SMBIOS table has to end with two \0\0 when no strings a present. Signed-off-by: Matthias Brugger <mbrugger@suse.com> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2024-02-02smbios: get_str_from_dt() - add sysinfo_id descriptionHeinrich Schuchardt1-0/+1
Add description for parameter sysinfo_id of function get_str_from_dt(). Fixes: 07c9e683a484 ("smbios: Allow a few values to come from sysinfo") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2024-02-02lib: smbios_entr() use logical or for booleansHeinrich Schuchardt1-1/+1
As a matter of programming style use logical or to combine two boolean results. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2024-01-29efi_loader: check efi_get_variable_int return valueMasahisa Kojima1-5/+5
efi_get_variable_int() may fail, the buffer should be cleared before using it. Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org> Addresses-Coverity-ID: 478333 ("Error handling issues")
2024-01-29efi_loader: replace find_smbios_table by library functionHeinrich Schuchardt1-18/+1
The code in find_smbios_table() is redundant to efi_get_configuration_table(). Replace it. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2024-01-29efi_loader: export efi_get_configuration_tableHeinrich Schuchardt1-3/+3
In multiple places we need a function to find an EFI configuration table. Rename get_config_table() to efi_get_configuration_table() and export it. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2024-01-29efi_selftest: add missing line feed in efi_selftest_miniapp_exitHeinrich Schuchardt1-1/+1
If an error occurs we may see an output like: EFI application calling Exit Could not open loaded image protocolLoaded image protocol missing Add the missing line feed. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2024-01-26lib: support SMBIOS3 table in uuid_guid_get_str()Heinrich Schuchardt1-0/+4
As we support installing SMBIOS3 tables in U-Boot we need to add this GUID to the translation table used buy uuid_guid_get_str(). Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Mark Kettenis <kettenis@openbsd.org>
generated by cgit v1.1 at 2024-07-14 00:58:47 +0000