summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2021-11-03tools: kwboot: Show verbose message when waiting for baudrate change magicPali Rohár
It is hard to debug why kwboot is failing when the last message is 'Finishing transfer' and no additional output. So show verbose message when kwboot finished transfer and is waiting for baudrate change magic sequence. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de>
2021-11-03tools: kwboot: Correctly set configuration of UART for BootROM messagesPali Rohár
For kwbimage v1, tell BootROM to send BootROM messages to UART port number 0 (used also for UART booting) with default baudrate (which should be 115200) and do not touch UART MPP configuration. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de>
2021-11-03tools: kwboot: Recalculate 4-byte data checksum after injecting baudrate codePali Rohár
If data part of image is modified, update 4-byte data checksum. It looks like A385 BootROM does not verify this checksum for image loaded via UART, but we do not know if other BootROMs are also ignoring it. It is always better to provide correct checksum. Signed-off-by: Pali Rohár <pali@kernel.org> [ refactored ] Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de>
2021-11-03tools: kwboot: Inject baudrate change back code after data partPali Rohár
Some vendor U-Boot kwbimage binaries (e.g. those for A375) have load address set to zero. Therefore it is not possible to inject code which changes baudrate back to 115200 Bd before the data part. So instead inject it after the data part and change kwbimage execution address to that offset. Also store original execution address into baudrate change code, so after it changes baudrate back to 115200 Bd, it can jump to orignal address. Signed-off-by: Pali Rohár <pali@kernel.org> [ refactored ] Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de>
2021-11-03tools: kwboot: Validate 4-byte image data checksumPali Rohár
Data part of the image contains 4-byte checksum. Validate it when processing the image. Signed-off-by: Pali Rohár <pali@kernel.org> [ refactored ] Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de>
2021-11-03tools: kwboot: Reserve enough space for patching kwbimage in memoryPali Rohár
SPI image header and data parts do not have to be aligned to 128 byte xmodem block size. So reserve additional memory for aligning header part and additional memory for aligning data part. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de>
2021-11-03tools: kwboot: Fix initialization of tty devicePali Rohár
Explicitly disable 2 stop bits by clearing CSTOPB flag, disable modem control flow by clearing CRTSCTS flag and do not send hangup after closing device by clearing HUPCL flag. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de>
2021-11-03tools: kwboot: Initialize rfds to zeroPali Rohár
Explicitly zero out the rfds fd_set with FD_ZERO() before using it. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de>
2021-11-03pci: pci_mvebu: Fix comment about driver class namePali Rohár
This is a pci driver, not an eth driver. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de>
2021-11-03pci: pci_mvebu: Setup PCI controller to Root Complex modePali Rohár
Root Complex should be the default mode, let's set it explicitly. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de>
2021-11-03pci: pci_mvebu: Do not automatically enable bus mastering on PCI BridgePali Rohár
Now that PCI Bridge is working, U-Boot's CONFIG_PCI_PNP code automatically enables memory access and bus mastering when it is needed. So do not prematurely enable memory access and bus mastering. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de>
2021-11-03pci: pci_mvebu: Fix place of link up detectionPali Rohár
PCI Bridge is always accessible also when link is down. So move detection of link up from mvebu_pcie_of_to_plat() function to mvebu_pcie_valid_addr() function which is used when accessing PCI config space. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de>
2021-11-03pci: pci_mvebu: Remove unused functionsPali Rohár
Functions mvebu_pcie_get_local_bus_nr() and mvebu_pcie_get_local_dev_nr() are not used, so remove them. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de>
2021-11-03pci: pci_mvebu: Properly configure and use PCI Bridge (PCIe Root Port)Pali Rohár
The mysterious "Memory controller" PCI device which is present in PCI config space is improperly configured and crippled PCI Bridge which acts as PCIe Root Port for endpoint PCIe card. This PCI Bridge reports in PCI config space incorrect Class Code (Memory Controller) and incorrect Header Type (Type 0). It looks like HW bug in mvebu PCIe controller but apparently it can be changed via mvebu registers to correct values. The worst thing is that this PCI Bridge is crippled and its PCI config registers in range 0x10-0x34 alias access to internal mvebu registers which have different functionality as PCI Bridge registers. Moreover, configuration of PCI primary and secondary bus numbers (registers 0x18 and 0x19) is done via totally different mvebu registers via totally strange method and cannot be done via PCI Bridge config space. Due to above fact about PCI config range 0x10-0x34, allocate a private cfgcache[] buffer in the driver, to which PCI config access requests to the 0x10-0x34 space will be redirected in mvebu_pcie_read_config() and mvebu_pcie_write_config() functions. Function mvebu_pcie_write_config() will also catch writes to PCI_PRIMARY_BUS (0x18) and PCI_SECONDARY_BUS (0x19) registers and set PCI Bridge primary and secondary bus numbers via mvebu's own method. Also, Expansion ROM Base Address register (0x38) is available, but at different offset 0x30. So recalculate register offset before accessing PCI config space. After these steps U-Boot sees working PCI Bridge and CONFIG_PCI_PNP code can finally start enumerating all PCIe devices correctly, even with more complicated PCI topology. So update also mvebu_pcie_valid_addr() function to reflect state of the real device topology. Each PCIe port is de-facto isolated and every PCI Bridge which is part of PCIe Root Complex is also isolated, so put them on separate PCI buses as (local) device 0. U-Boot already supports enumerating separate PCI buses, real (HW) bus number can be retrieved by "PCI_BUS(bdf) - dev_seq(bus)" code, so update config read/write functions to properly handle more complicated tree topologies (e.g. when a PCIe switch with multiple PCI buses is connected to the PCIe port). Local bus number and local device number on mvebu are used for determining which config request type is used (Type 0 vs Type 1). On normal non-broken PCIe hardware it is done by primary and secondary bus numbers. So correctly translate settings between these numbers to ensure that correct config requests are sent over the PCIe bus. As bus numbers are correctly re-configured, it does not make sense to print some initial bogus configuration during probe, so remove this debug code. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de>
2021-11-03pci: pci_mvebu: Fix read_config() with PCI_SIZE_8 or PCI_SIZE_16Pali Rohár
When reading 8 or 16 bits from config space, use appropriate readb() or readw() calls. This ensures that PCIe controller does not read more bits from endpoint card as asked by read_config() function. Technically there should not be an issue with reading data from config space which are not later used as there are no clear-by-read registers. But it is better to use correct read operation based on requested size. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de>
2021-11-03pci: pci_mvebu: Fix write_config() with PCI_SIZE_8 or PCI_SIZE_16Pali Rohár
Current implementation of write_config() is broken for PCI_SIZE_8 or PCI_SIZE_16 as it always uses writel(), which means that write operation is always 32-bit, so upper 24 bits for PCI_SIZE_8 and upper 16 bits for PCI_SIZE_16 are cleared. Fix this by using writeb() and writew(), respectively. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de>
2021-11-01Prepare v2022.01-rc1v2022.01-rc1Tom Rini
Signed-off-by: Tom Rini <trini@konsulko.com>
2021-11-01configs: Resync with savedefconfigTom Rini
Rsync all defconfig files using moveconfig.py Signed-off-by: Tom Rini <trini@konsulko.com>
2021-11-01Merge https://source.denx.de/u-boot/custodians/u-boot-x86Tom Rini
- Fixes for x86 build with Clang/LLVM compiler - Tangier ACPI changes - Edison SD card detect pin fix - EFI on x86 doc update with latest instructions - PXE utility fixes to align with latest x86 zboot implementation
2021-11-01x86: tangier: pinmux: Move error message to the callerAndy Shevchenko
Move error message to the caller of mrfld_pinconfig*() in order to unify them in the future. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2021-11-01x86: tangier: pinmux: Move is_protected assignment closer to its userAndy Shevchenko
Move is_protected assignment closer to its user. This increases readability and makes maintenance easier. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2021-11-01x86: edison: Don't take SD card detect pin into considerationAndy Shevchenko
There are two PCB designs in the wild which use the opposite signaling for SD card detection. This makes U-Boot working in one case and failing in the other. Quirk this out by disconnecting SD card detection pin from the PCB by switching it to mode 3. In the disconnected state the read value is always the same and inverted to what we are expecting in the code. BugLink: https://github.com/edison-fw/meta-intel-edison/issues/136 Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2021-11-01x86: tangier: Enable support for SD/SDIO family in the pinmux driverAndy Shevchenko
We would need to quirk out the Card Detect case and for that we allow configuring the SD/SDIO family of pins. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2021-11-01x86: Fix i8254 ifdef include guardAlistair Delva
When building U-Boot with clang, it notices that the i8254.h include guard does not work correctly due to a typo. Fix it. Signed-off-by: Alistair Delva <adelva@google.com> Cc: Simon Glass <sjg@chromium.org> Cc: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> [bmeng: fixed the other same typo at the end of the same file] Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
2021-11-01x86: chromebook_coral: fix C block commentAlistair Delva
Fix a warning seen when compiling this dts file. Signed-off-by: Alistair Delva <adelva@google.com> Cc: Simon Glass <sjg@chromium.org> Cc: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2021-11-01x86: tangier: Replace Method() by Name() for _STA objectAndy Shevchenko
There is no point to use Method() for the constant. Replace it with Name() defined object. For the _STA case it saves 3 bytes per each entry. Before: 2881 After: 2833 Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2021-11-01pxe_utils: Clean up {bootm,zboot}_argv generationZhaofeng Li
Signed-off-by: Zhaofeng Li <hello@zhaofeng.li> Cc: Simon Glass <sjg@chromium.org> Cc: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-11-01pxe_utils: Fix arguments to x86 zbootZhaofeng Li
bootm and zboot accept different arguments: > bootm [addr [arg ...]] > - boot application image stored in memory > passing arguments 'arg ...'; when booting a Linux kernel, > 'arg' can be the address of an initrd image > zboot [addr] [size] [initrd addr] [initrd size] [setup] [cmdline] > addr - The optional starting address of the bzimage. > If not set it defaults to the environment > variable "fileaddr". > size - The optional size of the bzimage. Defaults to > zero. > initrd addr - The address of the initrd image to use, if any. > initrd size - The size of the initrd image to use, if any. In the zboot flow, the current code will reuse the bootm args and attempt to pass the initrd arg (argv[2]) as the kernel size (should be argv[3]). zboot also expects the initrd address and size to be separate arguments. Let's untangle them and have separate argv/argc locals. Signed-off-by: Zhaofeng Li <hello@zhaofeng.li> Cc: Simon Glass <sjg@chromium.org> Cc: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-11-01docs: uefi: Update stale U-Boot on EFI docBin Meng
The existing intructions in the U-Boot on EFI doc do not work with the latest QEMU. Update the doc with the correct instructions, as well as using the new OVMF URL link. Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
2021-10-31Merge tag 'dm-pull-boo21' of https://source.denx.de/u-boot/custodians/u-boot-dmTom Rini
Environment tidy-ups patman 'postfix' support fix binman test race condition causing a timeout error # gpg: Signature made Sun 31 Oct 2021 03:36:55 PM EDT # gpg: using RSA key B25C0022AF86A7CC1655B6277F173A3E9008ADE6 # gpg: issuer "sjg@chromium.org" # gpg: Good signature from "Simon Glass <sjg@chromium.org>" [unknown] # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: B25C 0022 AF86 A7CC 1655 B627 7F17 3A3E 9008 ADE6
2021-10-31bootstage: Add SPL supportMarek Vasut
Allow usage of the bootstage facilities in SPL. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Simon Glass <sjg@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-10-31patman: Add "postfix" support to patch subjectsSean Anderson
In some communities, it may be necessary to append something after PATCH in the subject line. For example, the Linux networking subsystem expects [1] patch subject prefixes like [RFC PATCH net-next 0/99]. This adds support for such "postfix"s to patman. Although entirely cosmetic, it is still nice to have. [1] https://www.kernel.org/doc/html/latest/networking/netdev-FAQ.html#how-do-i-indicate-which-tree-net-vs-net-next-my-patch-should-be-in Signed-off-by: Sean Anderson <sean.anderson@seco.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-10-31env: Use static_assert() to check if default_environment is too largeMarek Behún
Check sizeof(default_environment) against ENV_SIZE in a static_assert() instead of runtime. Only check if !USE_HOSTCC (for in fw_env tool ENV_SIZE expands to a variable, and cannot be checked statically) nad !DEFAULT_ENV_INSTANCE_EMBEDDED, for in that case the default_environment variable is not set. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-10-31env: Always use char for default_environmentMarek Behún
Sometimes we use uchar and sometimes char for the default environment array. By always using char, we can get rid of some explicit casts. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-10-31board: freescale: various boards: Let env subsystem set gd->env_addrMarek Behún
Various freescale boards set gd->env_addr to default_environment in board_init(), conditional on CONFIG_ENV_IS_NOWHERE, but this is redundant, since it is done by env_init() before board_init() is called. Let the env subsystem handle this. Signed-off-by: Marek Behún <marek.behun@nic.cz> Cc: Ramon Fried <rfried.dev@gmail.com> Cc: Priyanka Jain <priyanka.jain@nxp.com> Cc: Mian Yousaf Kaukab <ykaukab@suse.de> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-10-31board: synquacer: developerbox: Don't set gd->env_addr to default_environmentMarek Behún
This board sets gd->env_addr to default_environment in board_init(), but the board has environment in SPI flash according to defconfig. Let the env API handle environment automatically. Signed-off-by: Marek Behún <marek.behun@nic.cz> Cc: Masami Hiramatsu <masami.hiramatsu@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-10-31env: flash: Cosmetic fixMarek Behún
Change tab to space in env_flash_init(). Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-10-31env: flash: Let generic env_init() assign default environmentMarek Behún
env_flash_init() (both implementations) assigns default environment if ENV_INVALID, but this is done in the generic env_init() function, which calls this initializer, so drop it from here. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-10-31env: nowhere: Cosmetic fixMarek Behún
Use spaces instead of tabs in assignments, since there are no lines to align assignment values to. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-10-31env: nowhere: Let generic env_init() assign default environmentMarek Behún
env_nowhere_init() assigns default environment if ENV_INVALID, but this is done in the generic env_init() function, which calls this initializer, so drop it from here. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-10-31env: nvram: Cosmetic fix in env_nvram_init()Marek Behún
Use spaces consistently in assignments instead of tabs. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-10-31env: nvram: Let generic env_init() assign default environmentMarek Behún
env_nvram_init() assigns default environment if ENV_INVALID, but this is done in the generic env_init() function, which calls this initializer, so drop it from here. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-10-31env: nand: Put ENV_INVALID into gd->env_valid if default environmentMarek Behún
env_nand_init() says the environment is valid even if it is assigning default environment due to not being able to access nand pre-reloaction (determined by macro values). Change this to ENV_INVALID and let the generic env_init() function, which calls this initializer, assign the default environment. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-10-31env: sf: Put ENV_INVALID into gd->env_valid on CRC failureMarek Behún
env_sf_init_addr() says the environment is valid even if it is assigning default environment due to CRC failure. Change this to ENV_INVALID and let the generic env_init() function, which calls this initializer, assign the default environment. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-10-31env: sf: Use ENV_VALID enum names instead of literalsMarek Behún
The function env_sf_init_addr() assigns number literals (1) instead of ENV_VALID to gd->env_valid. Fix this. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-10-31env: sf: Cosmetic fix in env_sf_init_addr()Marek Behún
In the if clause we use tabs and in the else clause spaces. Let's use spaces in the if clause too. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-10-31x86: Fix linking u-boot with ld.lldAlistair Delva
When linking the final u-boot binary with LLD, the following link errors are seen: ld.lld: error: can't create dynamic relocation R_386_32 against local symbol in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output >>> defined in arch/x86/cpu/start.o >>> referenced by arch/x86/cpu/start.o:(.text.start+0x32) [...] >>> defined in arch/x86/cpu/start16.o >>> referenced by arch/x86/cpu/start16.o:(.start16+0x1C) According to Nick Desaulniers: "This is a known difference between GNU and LLVM linkers; the GNU linkers permit relocations in readonly segments (making them not read only), LLVM does not (by default)." Since U-Boot apparently seems to use relocations in readonly segments, change the global linker flags to permit them when linking with LLD by specifying '-z notext'. Signed-off-by: Alistair Delva <adelva@google.com> Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: Simon Glass <sjg@chromium.org> Cc: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-10-31sandbox: Migrate ARCH_MAP_SYSMEM to KconfigTom Rini
Move this from a hard-coded define in config.mk to Kconfig. Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-10-31binman: Allow timeout to occur in the image or its sectionSimon Glass
At present testThreadTimeout() assumes that the expected timeout happens first when building the section, but it can just as easily happen at the top-level image. Update the test to cope with both. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Marek Behún <marek.behun@nic.cz>
2021-10-31image.h: make image_sign_info.fit point to constHannu Lounento
The data blob apparently does not need to be modified through the fit field of the image_sign_info struct so make it point to const to avoid the need to cast away constness in functions that assign a pointer to const data to the field. fit_image_setup_verify already had to cast away constness as it assigned a const void * argument to the field. The cast can now be removed. Signed-off-by: Hannu Lounento <hannu.lounento@vaisala.com> Reviewed-by: Simon Glass <sjg@chromium.org>