- Mar 04, 2022
-
-
Commit 5534fb4f ("arm64: a37xx: pinctrl: Correct PWM pins definitions") introduced bogus definitions os PWM pins: all 4 pins have index 11, instead of having indexes 11, 12, 13, 14. Fix this. Signed-off-by:
Marek Behún <marek.behun@nic.cz> Reviewed-by:
Pali Rohár <pali@kernel.org> Reviewed-by:
Stefan Roese <sr@denx.de>
-
Replace null pointer by pointer to device registers when calling armada38x_rtc_write. Signed-off-by:
Francois Berder <fberder@outlook.fr> Reviewed-by:
-
The a3700_fdt_fix_pcie_regions() function still computes nonsense. It computes the fixup offset from the PCI address taken from the first row of the "ranges" array, which means that: - PCI address must equal CPU address (otherwise the computed fix offset will be wrong), - the first row must contain the lowest address. This is the case for the default device-tree, which is why we didn't notice it. It also adds the fixup offset to all PCI and CPU addresses, which is wrong. Instead: 1) The fixup offset must be computed from the CPU address, not PCI address. 2) The fixup offset must be computed from the row containing the lowest CPU address, which is not necessarily contained in the first row. 3) The PCI address - the address to which the PCIe controller remaps the address space as seen from the point of view of the PCIe device - must be fixed by the fix offset in the same way as the CPU address only in the special case when the CPU adn PCI addresses are the same. Same addresses means that remapping is disabled, and thus if we change the CPU address, we need also to change the PCI address so that the remapping is still disabled afterwards. Consider an example: The ranges entries contain: PCI address CPU address 70000000 EA000000 E9000000 E9000000 EB000000 EB000000 By default CPU PCIe window is at: E8000000 - F0000000 Consider the case when TF-A moves it to: F2000000 - FA000000 Until now the function would take the PCI address of the first entry: 70000000, and the new base, F2000000, to compute the fix offset: F2000000 - 70000000 = 82000000, and then add 8200000 to all addresses, resulting in PCI address CPU address F2000000 6C000000 6B000000 6B000000 6D000000 6D000000 which is complete nonsense - none of the CPU addresses is in the requested window. Now it will take the lowest CPU address, which is in second row, E9000000, and compute the fix offset F2000000 - E9000000 = 09000000, and then add it to all CPU addresses and those PCI addresses which equal to their corresponding CPU addresses, resulting in PCI address CPU address 70000000 F3000000 F2000000 F2000000 F4000000 F4000000 where all of the CPU addresses are in the needed window. Fixes: 4a82fca8 ("arm: a37xx: pci: Fix a3700_fdt_fix_pcie_regions() function") Signed-off-by: -
Enable ext4 write support in Turris Omnia's defconfig. Some users find it useful. Signed-off-by:
-
Use "MVPCIE_" prefix instead of generic "PCIE_" prefix for pci_mvebu.c specific macros. Define offset macros for Root Port registers and use standard register macros from pci.h when accessing Root Port registers. Signed-off-by:
-
Macro SELECT() is unused and struct mvebu_pcie field lane_mask is unused too. Remove them. Signed-off-by:
-
Sometimes kwboot after quitting terminal prints error message: terminal: Bad address This is caused by trying to call write() syscall with count of (size_t)-1 bytes. When quit sequence is split into more read() calls then number of input bytes (nin) at the end of cycle can underflow and be negative. Fix it. Fixes: de751404 ("tools: kwboot: Fix detection of quit esc sequence") Signed-off-by:
-
- Mar 03, 2022
-
-
https://source.denx.de/u-boot/custodians/u-boot-at91Tom Rini authored
First set of u-boot-atmel fixes for the 2022.04 cycle: This fixes set includes only a single fix for the Ethernet on sama7g5ek board which is broken at the moment.
-
https://gitlab.denx.de/u-boot/custodians/u-boot-fsl-qoriqTom Rini authored
Update and fixes for sl28, lx2, pblimage generation for some powerpc products
-
- Mar 01, 2022
-
-
- Feb 28, 2022
-
-
Ensure there is a valid reset-gpio defined before using it. Fixes: f9852acd ("phy: nop-phy: Fix enabling reset") Cc: Adam Ford <aford173@gmail.com> Signed-off-by:
Tim Harvey <tharvey@gateworks.com>
-
Tom Rini authored
Signed-off-by:Tom Rini <trini@konsulko.com>
-
Tom Rini authored
- Assorted bugfixes
-
This patch scans the cmdline from the Samsung SBL (second stage bootloader) and stores the parameters board_id=N and lcdtype=N in order to augment the DTB for different board and LCD types. We then add a custom ft_board_setup() callback that will inspect the DTB and patch it using the stored LCD type. At this point we know which product we are dealing with, so using the passed board_id we can also print the board variant for diagnostics. We patch the Codina, Skomer and Kyle DTBs to use the right LCD type as passed in lcdtype from the SBL. This also creates an infrastructure for handling any other Samsung U8500 board variants that may need a slightly augmented DTB. Cc: Markuss Broks <markuss.broks@gmail.com> Cc: Stephan Gerhold <stephan@gerhold.net> Signed-off-by:Linus Walleij <linus.walleij@linaro.org>
-
Support for Apple M1 Pro and Max will allow using a single binary for all M1 SoCs. The M1 Pro/Max have a different memory layout. The RAM start address is 0x100_0000_0000 instead of 0x8_0000_0000. Replace the hardcoded memory layout with dynamic initialized environment variables in board_late_init(). Tested on Mac Mini (2020) and Macbook Pro 14-inch (2021). Signed-off-by:
Janne Grunau <j@jannau.net> Reviewed-by:
Mark Kettenis <kettenis@openbsd.org>
-
To make sure we get a working console as soon as possible in the SPL the UART pins require to be configured earlier. This is especially true for the pins of UART3, since the PDU001 board uses this UART for the console by default. Signed-off-by:Felix Brack <fb@ltec.ch>
-
The changes from commit 0dba4586 ("arm: Init the debug UART") prevent the early debug UART from being initialized correctly. To fix this we not just configure the pin multiplexer but add setting up early clocks. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Currently -l option for mkimage and dumpimage ignores option -T and always tries to autodetect image type. With this change it is possible to tell mkimage and dumpimage to parse image file as specific type (and not random autodetected type). This allows to use mkimage -l or dumpimage -l as tool for validating image. params.type for -l option is now by default initialized to zero (IH_TYPE_INVALID) instead of IH_TYPE_KERNEL. imagetool_get_type() for IH_TYPE_INVALID returns NULL, which is assigned to tparams. mkimage and dumpimage code is extended to handle tparams with NULL for -l option. And imagetool_verify_print_header() is extended to do validation via tparams if is not NULL. Signed-off-by:
-
The Layerscape platforms have different RCW header value from FSL PowerPC platforms, the current image header verification callback is only working on PowerPC, it will fail on Layerscape, this patch is to fix this issue. This is a historical problem and exposed by the following patch: http://patchwork.ozlabs.org/project/uboot/patch/20220114173443.9877-1-pali@kernel.org Signed-off-by:
Hou Zhiqiang <Zhiqiang.Hou@nxp.com> Reviewed-by:
Priyanka Jain <priyanka.jain@nxp.com>
-
The BOOT_TARGET_DEVICES list for distro_bootcmd was hard-coded to assume that all boot devices are available/enabled in the configuration, thus ignoring the actual config settings. The config_distro_bootcmd.h header file specifically has compile-time checks to detect such problems. To allow disabling USB, SCSI, etc. in custom lx2160a board configs, make it depend on the config settings and use only the enabled features. Signed-off-by:
Daniel Klauer <daniel.klauer@gin.de> Reviewed-by:
-
Simplify the binman config and fdt nodes by using the "@..-SEQ" substitutions and CONFIG_OF_LIST. Signed-off-by:
Michael Walle <michael@walle.cc> [Rebased] Signed-off-by:
-
Nowadays, u-boot (when CONFIG_NET_RANDOM_ETHADDR is set) will set enetaddr to a random value if not set and then pass the randomly generated MAC address to linux. This is bad for the following reasons: (1) it makes it impossible for linux to detect this error (2) linux won't trigger any fallback mechanism for the case where it didn't find any valid MAC address (3) a saveenv will store this randomly generated MAC address in the environment Probably, the user will also be unaware that something is wrong. He will just get different MAC addresses on each reboot, asking himself why this is the case. As this board usually have a serial port, the user can just fix this by setting the MAC address manually in the environment. Also disable the netconsole just in case, because it cannot be guaranteed that it will work in any case. After all, this was just a convenience option, because the bootloader - right now - doesn't have the ability to read the MAC address, which is stored in the OTP. But it is far more important to have a clear view of whats wrong with a board and that means we can no longer use this Kconfig option. Signed-off-by: -
They are no longer needed, because we now have proper driver support for the sl28cpld management controller. Signed-off-by:
-
This board has an internal watchdog which supervises the board startup. Although, the initial state of the watchdog is configurable, it is enabled by default. In board_late_init(), which means almost everything worked as expected, disable the watchdog. Signed-off-by:
-
The SoC provides two additional watchdogs integrated in the SoC. Enable support for these. Signed-off-by:
-
Enable the GPIO and watchdog driver. Don't start the watchdog automatically, though. Signed-off-by:
-
Most of the time it is very useful to have the version of the board management controller. Now that we have a driver, print it during startup. Signed-off-by:
-
The current console output is: DRAM: 4 GiB DDR 4 GiB (DDR3, 32-bit, CL=11, ECC on) The size is printed twice and we can save one line of console output if we join both lines. The new output is as follows: DRAM: 4 GiB (DDR3, 32-bit, CL=11, ECC on) Signed-off-by:
-
The gpio block is part of the sl28cpld sl28cpld management controller. There are three different flavors: the usual input and output where the direction is configurable, but also input only and output only variants. Signed-off-by:
-
The watchdog timer is part of the sl28cpld management controller. The watchdog timer usually supervises the bootloader boot-up and if it bites the failsafe bootloader will be activated. Apart from that it supports the usual board level reset and one SMARC speciality: driving the WDT_TIMEOUT# signal. Signed-off-by:
-
Add a multi-function device driver which will probe its children and provides methods to access the device. Signed-off-by:
-
- Feb 26, 2022
-
-
https://source.denx.de/u-boot/custodians/u-boot-efiTom Rini authored
Pull request for efi-2022-04-rc3 Documentation: * add man-page for fatload * add SMBIOS table page UEFI: * partial fix for UEFI secure boot with intermediate certs * disable watchdog when returning to command line * reset system after capsule update
-
-
UEFI specification requires that 5 minutes watchdog timer is armed before the firmware's boot manager invokes an EFI boot option. This watchdog timer is updated as follows, according to the UEFI specification. 1) The EFI Image may reset or disable the watchdog timer as needed. 2) If control is returned to the firmware's boot manager, the watchdog timer must be disabled. 3) On successful completion of EFI_BOOT_SERVICES.ExitBootServices() the watchdog timer is disabled. 1) is up to the EFI image, and 3) is already implemented in U-Boot. This patch implements 2), the watchdog is disabled when control is returned to U-Boot. In addition, current implementation arms the EFI watchdog at only the first "bootefi" invocation. The EFI watchdog must be armed in every EFI boot option invocation. Signed-off-by:Masahisa Kojima <masahisa.kojima@linaro.org> Reviewed-by:
Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
-
Add a cold reset soon after processing capsule update on disk. This is required in UEFI specification 2.9 Section 8.5.5 "Delivery of Capsules via file on Mass Storage device" as; In all cases that a capsule is identified for processing the system is restarted after capsule processing is completed. This also reports the result of each capsule update so that the user can notice that the capsule update has been succeeded or not from console log. Signed-off-by:Masami Hiramatsu <masami.hiramatsu@linaro.org> Reviewed-by:
-
Add expected_reset optional argument to ConsoleBase::ensure_spawned(), ConsoleBase::restart_uboot() and ConsoleSandbox::restart_uboot_with_flags() so that it can handle a reset while the 1st boot process after main boot logo before prompt correctly. Signed-off-by:
-
Add wait_for_reboot optional argument to ConsoleBase::run_command() so that it can handle an expected reset by command execution. This is useful if a command will reset the sandbox while testing such commands, e.g. run_command("reset", wait_for_reboot = True) Signed-off-by: -
Since the efi_update_capsule() represents the UpdateCapsule() runtime service, it has to handle the capsule flags and update ESRT. However the capsule-on-disk doesn't need to care about such things. Thus, the capsule-on-disk should use the efi_capsule_update_firmware() directly instead of calling efi_update_capsule(). This means the roles of the efi_update_capsule() and capsule-on-disk are different. We have to keep the efi_update_capsule() for providing runtime service API at boot time. Suggested-by:
AKASHI Takahiro <takahiro.akashi@linaro.org> Signed-off-by:
Heinrich Schuchardt <xypron.glpk@gmx.de>
-
The general rule of accepting or rejecting an image is 1. Is the sha256 of the image in dbx 2. Is the image signed with a certificate that's found in db and not in dbx 3. The image carries a cert which is signed by a cert in db (and not in dbx) and the image can be verified against the former 4. Is the sha256 of the image in db For example SHIM is signed by "CN=Microsoft Windows UEFI Driver Publisher", which is issued by "CN=Microsoft Corporation UEFI CA 2011", which in it's turn is issued by "CN=Microsoft Corporation Third Party Marketplace Root". The latter is a self-signed CA certificate and with our current implementation allows shim to execute if we insert it in db. However it's the CA cert in the middle of the chain which usually ends up in the system's db. pkcs7_verify_one() might or might not return the root certificate for a given chain. But when verifying executables in UEFI, the trust anchor can be in the middle of the chain, as long as that certificate is present in db. Currently we only allow this check on self-signed certificates, so let's remove that check and allow all certs to try a match an entry in db. Open questions: - Does this break any aspect of variable authentication since efi_signature_verify() is used on those as well? Signed-off-by:Ilias Apalodimas <ilias.apalodimas@linaro.org>
-
That code is mistakenly duplicated due to copy-and-paste error. Just remove it. Fixes: CID 348360 Signed-off-by:
-
