aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Merge https://source.denx.de/u-boot/custodians/u-boot-marvellTom Rini2021-11-033-234/+451
|\ | | | | | | | | | | - pci_mvebu: Fix access to config space and PCIe Root Port (Pali) - a37xx: pci: Program the data strobe for config read requests (Pali) - kwboot: Misc improvements and fixes (Pali)
| * arm: a37xx: pci: Program the data strobe for config read requestsPali Rohár2021-11-031-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to the Armada 3720 Functional Specification Data Strobe applies for both read and write config requests. Data strobe bits configure which bytes from the start address should be returned for read request. Set value 0xf (all 4 bits) into Data Strobe register to read all four bytes from specified 32-bit config space register. Same value for Data Strobe register is programmed by Linux pci-aardvark.c driver for config read requests. Without this patch pci-aardvark driver sets data strobe register only during config write operations. So any followup config read operations could result with just partial datai returned (if previous write operation was not 32-bit wide). This patch fixes it and ensures that config read operations always read all bytes from requested register. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de>
| * tools: kwboot: Do not send magic seq when changing baudrate back to 115200Pali Rohár2021-11-031-55/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After successful transfer of whole image only two things can happen: - BootROM starts execution of data block, which changes UART baudrate back to 115200 Bd, - board crashes and causes CPU reset In both cases UART baudrate is reset to the default speed. So there is no need to send special magic sequence to inform kwboot that baudrate is going to be reset and kwboot does not need to wait for this event and can do it immediately after BootROM acknowledges end of xmodem transfer. Move ARM code for sending magic sequence from main baudrate change section to binhdr_pre section which is executed only before changing baudrate from the default value of 115200 Bd to some new value. Remove kwboot code waiting for magic sequence after successful xmodem transfer. Rationale: sometimes when using very high UART speeds, magic sequence is damaged and kwboot fails at this last stage. Removal of this magic sequence makes booting more stable. Data transfer protocol (xmodem) is using checksums and retransmit, so it already deals with possible errors on transfer line. Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de>
| * tools: kwboot: Do not use stack when setting baudrate back to default valuePali Rohár2021-11-031-47/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ARM code we inject into the image to change baudrate back to the default value of 115200 Baud, which is run after successful UART transfer of the whole image, cannot use stack as at this stage stack pointer is not initialized yet. Stack can only be used when BootROM is executing binary header, to preserve state of registers, since BootROM expects that. Change the ARM baudrate code to not use stack at all and put binary header specific pre + post code (which stores and restores registers) into separate arrays. The baudrate change code now jumps at it's end and expects that there is either code which returns to the BootROM or jumps to the original exec address. 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>
| * tools: kwboot: Replace ARM mov + movt instruction pair by mov + orrPali Rohár2021-11-031-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Older Armada SoCs have custom ARMv5te compatible core which does not support movt instruction. So replace mov + movt instruction pair used for immediate move construction by mov + orr instructions which are supported also by ARMv5te. After this change kwboot ARM code should be compatible with any 32-bit ARM core compatible by ARMv2 or new. At least GNU AS does not throw any error or warning. 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>
| * tools: kwboot: Increase delay after changing baudrate in ARM codePali Rohár2021-11-031-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | Increase loop cycles from 600000 to 2998272, which should increase delay from 1ms to about 5ms on 1200 MHz CPU. The Number 2998272 was chosen as the nearest value around 3000000 which can be encoded into one ARM mov instruction. It avoids usage of movt instruction which is not supported by ARMv5te cores. 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>
| * tools: kwboot: Do not call tcdrain() after each sent packetPali Rohár2021-11-031-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Kwboot puts each xmodem packet to kernel queue, then waits until all bytes of that packet are transmitted over UART and then waits for xmodem reply until it is received into kernel queue. If some reply is received during the time we are waiting until all bytes are transmitted, then kernel puts them into the queue and returns it to kwboot in next read() call. So there is no need to wait (with tcdrain() function) until all bytes from xmodem packet are transmitted over UART, since any reply received either during that time or after is returned to kwboot with the next read(). Therefore do not call tcdrain() after each xmodem packet sent. Instead directly wait for any reply after putting xmodem packet into write kernel queue. This change could speed up xmodem transfer in case tcdrain() function waits for a longer time. 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>
| * tools: kwboot: Fix sending retry of last header packetPali Rohár2021-11-031-5/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After the trasfer of last header packet, it is possible that baudrate change pattern is received, and also that NAK byte is received so that the packet should be sent again. Thus we should not clear the baudrate change state when sending retry of that packet. Move code for initializing state variables from kwboot_xm_recv_reply() to kwboot_xm_sendblock(). 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>
| * tools: kwboot: Resend first 3 xmodem retry packets immediatelyPali Rohár2021-11-031-3/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently when kwboot receive some garbage reply which does not understand, it waits 1s before it tries to resend packet again. The most common error on UART is that receiver sees some bit flipped which results in invalid reply. This behavior slows down xmodem transfer over UART as basically on every error kwboot is waiting one second. To fix this, try to resend xmodem packet for first 3 attempts immediately without any delay. If broken reply is received also after the 3 attempts, continue retrying with 1s delay like it was before. 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>
| * tools: kwboot: Change retry loop from decreasing to increasingPali Rohár2021-11-031-4/+4
| | | | | | | | | | | | | | | | | | This patch does not change behavior of the code, just allows to implement new changes more easily. 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>
| * tools: kwboot: Calculate real used space in kwbimage header when calling ↵Pali Rohár2021-11-031-3/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | kwboot_img_grow_hdr() Size of the header stored in kwbimage may be larger than real used size in the kwbimage header. If there is unused space in kwbimage header then use it for growing it. So update code to calculate used space of kwbimage header. 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>
| * tools: kwboot: Do not modify kwbimage header before increasing its sizePali Rohár2021-11-031-3/+6
| | | | | | | | | | | | | | | | | | This ensures that kwboot_img_grow_hdr() function still sees valid kwbimage header. 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>
| * tools: kwboot: Simplify code for aligning image headerPali Rohár2021-11-031-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | Expression (hdrsz % KWBOOT_XM_BLKSZ) is non-zero therefore expression (KWBOOT_XM_BLKSZ - hdrsz % KWBOOT_XM_BLKSZ) is always less than value KWBOOT_XM_BLKSZ. So there is no need to add another modulo. Also rename variable `offset` to `grow` which better describes what is stored in this variable. 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>
| * tools: kwboot: Show verbose message when waiting for baudrate change magicPali Rohár2021-11-031-1/+1
| | | | | | | | | | | | | | | | | | | | 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>
| * tools: kwboot: Correctly set configuration of UART for BootROM messagesPali Rohár2021-11-031-0/+11
| | | | | | | | | | | | | | | | | | | | 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>
| * tools: kwboot: Recalculate 4-byte data checksum after injecting baudrate codePali Rohár2021-11-031-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * tools: kwboot: Inject baudrate change back code after data partPali Rohár2021-11-031-41/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * tools: kwboot: Validate 4-byte image data checksumPali Rohár2021-11-031-0/+34
| | | | | | | | | | | | | | | | | | | | 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>
| * tools: kwboot: Reserve enough space for patching kwbimage in memoryPali Rohár2021-11-031-1/+3
| | | | | | | | | | | | | | | | | | | | 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>
| * tools: kwboot: Fix initialization of tty devicePali Rohár2021-11-031-0/+1
| | | | | | | | | | | | | | | | | | | | 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>
| * tools: kwboot: Initialize rfds to zeroPali Rohár2021-11-031-0/+1
| | | | | | | | | | | | | | | | 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>
| * pci: pci_mvebu: Fix comment about driver class namePali Rohár2021-11-031-1/+1
| | | | | | | | | | | | | | | | 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>
| * pci: pci_mvebu: Setup PCI controller to Root Complex modePali Rohár2021-11-031-0/+6
| | | | | | | | | | | | | | | | 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>
| * pci: pci_mvebu: Do not automatically enable bus mastering on PCI BridgePali Rohár2021-11-031-8/+0
| | | | | | | | | | | | | | | | | | | | 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>
| * pci: pci_mvebu: Fix place of link up detectionPali Rohár2021-11-031-10/+4
| | | | | | | | | | | | | | | | | | | | 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>
| * pci: pci_mvebu: Remove unused functionsPali Rohár2021-11-031-16/+0
| | | | | | | | | | | | | | | | | | 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>
| * pci: pci_mvebu: Properly configure and use PCI Bridge (PCIe Root Port)Pali Rohár2021-11-031-35/+164
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * pci: pci_mvebu: Fix read_config() with PCI_SIZE_8 or PCI_SIZE_16Pali Rohár2021-11-031-2/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * pci: pci_mvebu: Fix write_config() with PCI_SIZE_8 or PCI_SIZE_16Pali Rohár2021-11-031-2/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge tag 'u-boot-amlogic-20211102' of ↵Tom Rini2021-11-026-3/+125
|\ \ | |/ |/| | | | | | | | | https://source.denx.de/u-boot/custodians/u-boot-amlogic - add sm efuse write support and cmd for read/write efuse - add JetHub D1 eth mac generation with manufacturer OUI
| * ARM: amlogic: add JetHub D1 eth mac generation with manufacturer OUIVyacheslav Bocharov2021-10-295-2/+58
| | | | | | | | | | | | | | JetHome has own MAC OUI. Add jethub-j100 board file. Update config. Signed-off-by: Vyacheslav Bocharov <adeep@lexina.in> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
| * ARM: amlogic: add sm efuse write support and cmd for read/write efuseVyacheslav Bocharov2021-10-291-1/+67
| | | | | | | | | | | | | | | | | | | | This adds support for amlogic efuse write and provides two subcommands of "sm" command: "efuseread" and "efusewrite" to read/write bytes between memory and efuse. Signed-off-by: Vyacheslav Bocharov <adeep@lexina.in> [narmstrong: fixed indent at end of patch] Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
* | Prepare v2022.01-rc1v2022.01-rc1Tom Rini2021-11-011-3/+3
| | | | | | | | Signed-off-by: Tom Rini <trini@konsulko.com>
* | configs: Resync with savedefconfigTom Rini2021-11-01725-965/+870
| | | | | | | | | | | | Rsync all defconfig files using moveconfig.py Signed-off-by: Tom Rini <trini@konsulko.com>
* | Merge https://source.denx.de/u-boot/custodians/u-boot-x86Tom Rini2021-11-017-96/+112
|\ \ | | | | | | | | | | | | | | | | | | | | | - 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
| * | x86: tangier: pinmux: Move error message to the callerAndy Shevchenko2021-11-011-7/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | x86: tangier: pinmux: Move is_protected assignment closer to its userAndy Shevchenko2021-11-011-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | x86: edison: Don't take SD card detect pin into considerationAndy Shevchenko2021-11-011-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | x86: tangier: Enable support for SD/SDIO family in the pinmux driverAndy Shevchenko2021-11-011-5/+34
| | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | x86: Fix i8254 ifdef include guardAlistair Delva2021-11-011-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | x86: chromebook_coral: fix C block commentAlistair Delva2021-11-011-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | x86: tangier: Replace Method() by Name() for _STA objectAndy Shevchenko2021-11-011-64/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | pxe_utils: Clean up {bootm,zboot}_argv generationZhaofeng Li2021-11-011-18/+27
| | | | | | | | | | | | | | | | | | | | | 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>
| * | pxe_utils: Fix arguments to x86 zbootZhaofeng Li2021-11-011-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | docs: uefi: Update stale U-Boot on EFI docBin Meng2021-11-011-5/+7
|/ / | | | | | | | | | | | | | | 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>
* | Merge tag 'dm-pull-boo21' of https://source.denx.de/u-boot/custodians/u-boot-dmTom Rini2021-10-3135-75/+66
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * | bootstage: Add SPL supportMarek Vasut2021-10-316-5/+14
| | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | patman: Add "postfix" support to patch subjectsSean Anderson2021-10-315-4/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | env: Use static_assert() to check if default_environment is too largeMarek Behún2021-10-312-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | env: Always use char for default_environmentMarek Behún2021-10-314-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | 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>
generated by cgit v1.2.3 (git 2.39.1) at 2025-06-01 03:28:51 +0000