- 05 6月, 2021 4 次提交
-
-
由 Alper Nebi Yasak 提交于
With commit 41575d8e ("dm: treewide: Rename auto_alloc_size members to be shorter") "priv_auto_alloc_size" was renamed to "priv_auto". This driver was sent to the mailing list before that change, merged after it, and still has the old form. Apply the rename here as well. Fixes: 1b9ee288 ("pwm: Add a driver for Chrome OS EC PWM") Signed-off-by: NAlper Nebi Yasak <alpernebiyasak@gmail.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Heinrich Schuchardt 提交于
os_find_text_base() assumes that first line of /proc/self/maps holds information about the text. Hence we must call the function before calling os_malloc() which calls mmap(0x10000000,). Failure to do so has led to incorrect values for pc_reloc when an exception was reported => exception undefined Illegal instruction pc = 0x5628d82e9d3c, pc_reloc = 0x5628c82e9d3c as well as incorrect output of the bdinfo command => bdinfo relocaddr = 0x0000000007858000 reloc off = 0x0000000010000000 Fixes: b308d9fd ("sandbox: Avoid using malloc() for system state") Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Bin Meng 提交于
In of_get_address(), there is: dev_count_cells(dev, &na, &ns); followed by: bus->count_cells(dev, &na, &ns); but no codes in between use na/ns, hence the first call is useless. By dropping the first call, dev_count_cells() is now useless too. Signed-off-by: NBin Meng <bmeng.cn@gmail.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Bin Meng 提交于
'dma-ranges' frequently exists without parent nodes having 'dma-ranges'. While this is an error for 'ranges', this is fine because DMA capable devices always have a translatable DMA address. Also, with no 'dma-ranges' at all, the assumption is that DMA addresses are 1:1 with no restrictions unless perhaps the device itself has implicit restrictions. This keeps in sync with Linux kernel commit: 81db12ee15cb: of/address: Translate 'dma-ranges' for parent nodes missing 'dma-ranges' Signed-off-by: NBin Meng <bmeng.cn@gmail.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
- 04 6月, 2021 10 次提交
-
-
https://source.denx.de/u-boot/custodians/u-boot-marvell由 Tom Rini 提交于
- mvebu: a37xx: PCI related enhancements and fixes (Pali) - mvebu: turris_omnia: Board specific updates, e.g. rescue boot cmd etc (Marek)
-
由 Marek Behún 提交于
Make it possible to invoke rescue boot from U-Boot console, without having to press the factory reset button. This is needed when accessing the device remotely, for example. Achieve this by putting rescue command into `bootcmd_rescue` default environment variable and setting some distroboot environment variables to their default values when the factory button is pressed. Rescue boot from console can be invoked by running run bootcmd_rescue Signed-off-by: NMarek Behún <marek.behun@nic.cz> Reviewed-by: NPali Rohár <pali@kernel.org> Reviewed-by: NStefan Roese <sr@denx.de>
-
由 Marek Behún 提交于
Update rescue mode boot command on Turris Omnia. We are compressing the image with lzma now. Signed-off-by: NMarek Behún <marek.behun@nic.cz> Reviewed-by: NPali Rohár <pali@kernel.org> Reviewed-by: NStefan Roese <sr@denx.de>
-
由 Pali Rohár 提交于
The `ranges` DT property of the PCIe node is currently ignored by Aardvark driver - all entries are used as transparent PCIe MEM, despite some of them being defined for IO in DT. This is because the driver does not setup PCIe outbound windows and thus a default configuration is used. This can cause an external abort on CPU when a device driver tries to access non-MEM space. Setup the PCIe windows according to the `ranges` property for all non-MEM resources (currently only IO) and also non-transparent MEM resources. Because Linux expects that bootloader does not setup Aardvark PCIe windows, disable them before booting Linux. Signed-off-by: NPali Rohár <pali@kernel.org> Reviewed-by: NMarek Behún <marek.behun@nic.cz> Reviewed-by: NStefan Roese <sr@denx.de>
-
由 Pali Rohár 提交于
For some configurations with more PCIe cards and PCIe bridges, 16 MiB of PCIe MEM space may not be enough. Since TF-A already allocates a 128 MiB CPU window for PCIe, and since IO port space is only 64 KiB in total, use all the remaining space (64 + 32 + 16 + 8 + 4 + 2 + 1 = 127 MiB) for PCIe MEM. Signed-off-by: NPali Rohár <pali@kernel.org> Reviewed-by: NMarek Behún <marek.behun@nic.cz> Reviewed-by: NStefan Roese <sr@denx.de>
-
由 Pali Rohár 提交于
Current version of this function uses a lot of incorrect assumptions about the `ranges` DT property: * parent(#address-cells) == 2 * #size-cells == 2 * number of entries == 2 * address size of first entry == 0x1000000 * second child address entry == base + 0x1000000 Trying to increase PCIe MEM space to more than 16 MiB leads to an overlap with PCIe IO space, and trying to define additional MEM space (as a third entry in the `ranges` DT property) causes U-Boot to crash when booting the kernel. ## Flattened Device Tree blob at 04f00000 Booting using the fdt blob at 0x4f00000 Loading Device Tree to 000000001fb01000, end 000000001fb08f12 ... OK ERROR: board-specific fdt fixup failed: <unknown error> - must RESET the board to recover. Fix a3700_fdt_fix_pcie_regions() to properly parse and update all addresses in the `ranges` property according to https://elinux.org/Device_Tree_Usage#PCI_Address_Translation Now it is possible to increase PCIe MEM space from 16 MiB to maximal value of 127 MiB. Signed-off-by: NPali Rohár <pali@kernel.org> Reviewed-by: NMarek Behún <marek.behun@nic.cz> Fixes: cb2ddb29 ("arm64: mvebu: a37xx: add device-tree fixer for PCIe regions") Reviewed-by: NStefan Roese <sr@denx.de>
-
由 Pali Rohár 提交于
Find PCIe DT node by compatible string instead of retrieving it by using hardcoded DT path. Signed-off-by: NPali Rohár <pali@kernel.org> Reviewed-by: NMarek Behún <marek.behun@nic.cz> Reviewed-by: NStefan Roese <sr@denx.de>
-
由 Pali Rohár 提交于
Change DT compatible string for A3700 PCIe from 'marvell,armada-37xx-pcie' to 'marvell,armada-3700-pcie' to make U-Boot A3700 PCIe DT node compatible with Linux' DT node. Signed-off-by: NPali Rohár <pali@kernel.org> Reviewed-by: NMarek Behún <marek.behun@nic.cz> Reviewed-by: NStefan Roese <sr@denx.de>
-
由 Pali Rohár 提交于
Disable Root Bridge I/O space, memory space and bus mastering in Aardvark's remove method, which is called before booting Linux kernel. This ensures that PCIe device which was initialized and used by U-Boot cannot do new DMA transfers until Linux initializes PCI subsystem and loads appropriate drivers for the device. During initialization of PCI subsystem Linux in fact disables this bus mastering on Root Bridge (and later enables it when driver is loaded and configured), but there is a possibility of a small window after U-Boot boots Linux when bus mastering is enabled, which is not correct. Signed-off-by: NPali Rohár <pali@kernel.org> Reviewed-by: NMarek Behún <marek.behun@nic.cz> Reviewed-by: NStefan Roese <sr@denx.de>
-
由 Pali Rohár 提交于
During our debugging of the Aardvark driver in Linux we have discovered that the PCIE_CORE_LINK_CTRL_STAT_REG register in fact controls standard PCIe Link Control Register for PCIe Root Bridge. This led us to discover that the name of the PCIE_CORE_LINK_TRAINING macro and the corresponding comment by this macro's usage is misleading; this bit in fact controls Retrain Link, which, according to PCIe base spec is defined as: A write of 1b to this bit initiates Link retraining by directing the Physical Layer LTSSM to the Recovery state. If the LTSSM is already in Recovery or Configuration, re-entering Recovery is permitted but not required. Entering Recovery state is normally done from LTSSM L0, L0s and L1 states. But since the pci-aardvark.c driver enables Link Training just a few lines above, the controller is not in L0 ready state yet. So setting aardvark bit PCIE_CORE_LINK_TRAINING does not actually enter Recovery state at this place. Moreover, trying to enter LTSSM Recovery state without other configuration is causing issues for some cards (e.g. Atheros AR9xxx and QCA9xxx). Since Recovery state is not entered, these issues are not triggered. Remove code which tries to enter LTSSM Recovery state completely. Signed-off-by: NPali Rohár <pali@kernel.org> Reviewed-by: NMarek Behún <marek.behun@nic.cz> Reviewed-by: NStefan Roese <sr@denx.de>
-
- 02 6月, 2021 1 次提交
-
-
由 Sean Anderson 提交于
If a chunk was larger than 4GiB, then chunk_data_sz would overflow and blkcnt would not be calculated correctly. Upgrade it to a u64 and cast its multiplicands as well. Also fix bytes_written while we're at it. Signed-off-by: NSean Anderson <sean.anderson@seco.com> Reviewed-by: NHeiko Schocher <hs@denx.de>
-
- 31 5月, 2021 13 次提交
-
-
https://source.denx.de/u-boot/custodians/u-boot-riscv由 Tom Rini 提交于
- SiFive FU740 and Unmatched support
-
https://source.denx.de/u-boot/custodians/u-boot-sunxi由 Tom Rini 提交于
This contains the fix to bring back the SD card as MMC0. In the long run we are looking into a more robust solution, but for now we need to fix this, as this breaks the user experience left, right, and centre. Also add the one MAINTAINERS path addition from Samuel.
-
由 Green Wan 提交于
Fix compilation error when Werror is turned on. The warning could possible break some CI builds. Signed-off-by: NGreen Wan <green.wan@sifive.com> Reviewed-by: NLeo Yu-Chi Liang <ycliang@andestech.com>
-
由 Green Wan 提交于
Clear feature disable CSR to turn on all features of hart. The detail is specified at section, 'SiFive Feature Disable CSR', in user manual https://sifive.cdn.prismic.io/sifive/aee0dd4c-d156-496e-a6c4-db0cf54bbe68_sifive_U74MC_rtl_full_20G1.03.00_manual.pdfSigned-off-by: NGreen Wan <green.wan@sifive.com> Reviewed-by: NSean Anderson <seanga2@gmail.com> Reviewed-by: NBin Meng <bmeng.cn@gmail.com> Reviewed-by: NRick Chen <rick@andestech.com>
-
由 Green Wan 提交于
Add defconfig and board support for HiFive Unmatched. Signed-off-by: NGreen Wan <green.wan@sifive.com> Reviewed-by: NBin Meng <bmeng.cn@gmail.com> Reviewed-by: NRick Chen <rick@andestech.com>
-
由 Green Wan 提交于
Add dts files for SiFive Unmatched board. Signed-off-by: NGreen Wan <green.wan@sifive.com> Reviewed-by: NRick Chen <rick@andestech.com>
-
由 Green Wan 提交于
Add dts support for fu740. The HiFive Unmatched support is based on fu740 cpu and drivers in following patch set. Signed-off-by: NGreen Wan <green.wan@sifive.com> [greentime.hu: set fu740 speed to 1.2GHz] Signed-off-by: NGreentime Hu <greentime.hu@sifive.com> Reviewed-by: NBin Meng <bmeng.cn@gmail.com> Reviewed-by: NRick Chen <rick@andestech.com>
-
由 Green Wan 提交于
Add pcie driver for SiFive fu740, the driver depends on fu740 gpio, clk and reset driver to do init. Force running at Gen1 for better capatible enumeration. Several devices are tested: a) M.2 NVMe SSD b) USB-to-PCI adapter c) Ethernet adapter (E1000 compatible) Signed-off-by: NGreen Wan <green.wan@sifive.com> Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com>
-
由 Green Wan 提交于
Rename fu540_ddr.c to sifive_ddr.c and add fu740 support Signed-off-by: NGreen Wan <green.wan@sifive.com> Reviewed-by: NBin Meng <bmeng.cn@gmail.com>
-
由 Green Wan 提交于
Add fu740 support. One abstract layer is added for supporting multiple chips such as fu540 and fu740. Signed-off-by: NGreen Wan <green.wan@sifive.com>
-
由 Green Wan 提交于
Add SiFive fu740 cpu to support RISC-V arch Signed-off-by: NGreen Wan <green.wan@sifive.com> Reviewed-by: NBin Meng <bmeng.cn@gmail.com>
-
由 Samuel Holland 提交于
These drivers are sunxi platform-specific, and so are of interest to the sunxi maintainers. In fact, as there is no PHY driver maintainer, drivers/phy/allwinner had no maintainer at all. Signed-off-by: NSamuel Holland <samuel@sholland.org> Acked-by: NAndre Przywara <andre.przywara@arm.com> Signed-off-by: NAndre Przywara <andre.przywara@arm.com>
-
由 Andre Przywara 提交于
Commit 2243d19e ("mmc: mmc-uclass: Use dev_seq() to read aliases node's index") now actually enforces U-Boot's device enumeration policy, where explicitly named devices come first, then any other non-named devices follow, without filling gaps. For quite a while we have had an "mmc1 = &mmc2;" alias in our sunxi-u-boot.dtsi, which now leads to the problem that the SD card (which was always mmc device 0) now gets to be number 2. This breaks quite some boot scripts, including our own distro boot commands, and some other features looking at $mmc_bootdev, also fastboot. Just add an explicit mmc0 alias in the very same file to fix this and restore the old behaviour. Signed-off-by: NAndre Przywara <andre.przywara@arm.com> Reported-by: NSamuel Holland <samuel@sholland.org> Tested-by: NSimon Baatz <gmbnomis@gmail.com>
-
- 29 5月, 2021 2 次提交
-
-
https://source.denx.de/u-boot/custodians/u-boot-stm由 Tom Rini 提交于
- DFU: MTD: fix for lock support - reset: stm32: fix bank bank and offset computation - enable UNZIP config in several stm32mp defconfig
-
https://source.denx.de/u-boot/custodians/u-boot-efi由 Tom Rini 提交于
Pull request for efi-2021-07-rc4-2 Simplify configuration using HASH functions Fix Coverity warnings related to EFI TCG2 protocol Enable PE/COFF image measurement
-
- 28 5月, 2021 10 次提交
-
-
由 Masahisa Kojima 提交于
"TCG PC Client Platform Firmware Profile Specification" requires to measure every attempt to load and execute a OS Loader(a UEFI application) into PCR[4]. This commit adds the PE/COFF image measurement, extends PCR, and appends measurement into Event Log. Acked-by: NIlias Apalodimas <ilias.apalodimas@linaro.org> Tested-by: NIlias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: NMasahisa Kojima <masahisa.kojima@linaro.org> Replace CONFIG_HASH_CALCULATE by CONFIG_HASH Fix conversions between pointers and u64. Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: NIlias Apalodimas <ilias.apalodimas@linaro.org>
-
由 Alexandru Gagniuc 提交于
The hash_calculate() symbol is provided by hash-checksum.c. It depends on hash_progressive_lookup_algo(), provided when CONFIG_HASH=y. The issue is that hash_calculate() is used by the efi_loader, irregardless of CONFIG_FIT_SIGNATURE. As pointed out in commit 87316da0 ("lib: introduce HASH_CALCULATE option"), enabling hash_calculate() based on CONFIG_FIT_SIGNATURE is incorrect. To resolve this, use CONFIG_HASH as the compile switch for hash-checksum.c. This ensures that all dependencies are compiled, and is the most natural Kconfig to use. There is the issue of having to 'select HASH' in a couple of places that already 'select SHA256'. This is a deeper problem with how hashes are organized, and fixing it is beyonf the scope of this change. Signed-off-by: NAlexandru Gagniuc <mr.nuke.me@gmail.com> Acked-by: NMasahisa Kojima <masahisa.kojima@linaro.org>
-
由 Alexandru Gagniuc 提交于
When we think of Kconfig, we usually think of features that we like to enable or not. Ideally, we wouldn't use Kconfig to fix a build issue, although sometimes it might make sense. With Kconfig it's hard to guarantee that the fix is universal. We can only say that it works for the set of tested configurations. In the majority of cases, it's preferable to let the linker figure things out for us. The reverted commit attempted to fix a build issue by adding an invisible Kconfig option. This is wrong in several ways: It invents a new Kconfig variable when CONFIG_HASH already exists for the same purpose. Second, hash-checksum.c makes use of the hash_progressive_lookup_algo() symbol, which is only provided with CONFIG_HASH, but this dependency was not expressed in the reverted patch. It feels like Kconfig is turning into a listing of all available source files, and a buffet to 'select' which ones to compile. The purpose of this revert is to enable the next change to make use of CONFIG_HASH instead of adding to Kconfig. This reverts commit 87316da0. Signed-off-by: NAlexandru Gagniuc <mr.nuke.me@gmail.com> Acked-by: NMasahisa Kojima <masahisa.kojima@linaro.org>
-
由 Ilias Apalodimas 提交于
Coverity reported 3 warnings on the current code. CID 331856, 331855, 331854 on the latest scan. Fix the rest of the warnings by initializing the variables before passing them to tpm2_get_pcr_info(). In order to avoid future warnings and errors initialize them to 0 within the function as well, since the values are always OR'ed after querying the hardware. Signed-off-by: NIlias Apalodimas <ilias.apalodimas@linaro.org>
-
由 Grzegorz Szymaszek 提交于
Enable the true random number generator. It can be used, for example, to generate partition UUIDs when partitioning with the gpt command. The generator is already enabled in the device trees of several other STM32MP1‐based boards, like DKx or DHCOM. Signed-off-by: NGrzegorz Szymaszek <gszymaszek@short.pl> Cc: Patrice Chotard <patrice.chotard@foss.st.com> Cc: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: NPatrick Delaunay <patrick.delaunay@foss.st.com>
-
由 Patrick Delaunay 提交于
The CMD_UNZIP provides the 'gzwrite' command, which is convenient for writing e.g. gz-compressed images to eMMC from U-Boot. Signed-off-by: NPatrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: NPatrice Chotard <patrice.chotard@foss.st.com>
-
由 Marek Vasut 提交于
The CMD_UNZIP provides the 'gzwrite' command, which is convenient for writing e.g. gz-compressed images to eMMC from U-Boot. Signed-off-by: NMarek Vasut <marex@denx.de> Cc: Patrice Chotard <patrice.chotard@foss.st.com> Cc: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: NPatrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: NPatrick Delaunay <patrick.delaunay@foss.st.com>
-
由 Marek Vasut 提交于
Currently the code sets eth1addr only if /ethernet1 alias exists in DT, the node pointed to by the alias has "micrel,ks8851-mll" compatible string, and the KSZ8851 CCR register read indicates programmed EEPROM is not connected. This is not sufficient to detect cases where the DT still contains the KSZ8851 nodes, but the chip itself is not present. Extend the detection to handle these cases. Signed-off-by: NMarek Vasut <marex@denx.de> Cc: Patrice Chotard <patrice.chotard@foss.st.com> Cc: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: NPatrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: NPatrick Delaunay <patrick.delaunay@foss.st.com>
-
由 Christoph Niedermaier 提交于
Adding new DH electronics mailing list. Signed-off-by: NChristoph Niedermaier <cniedermaier@dh-electronics.com> Reviewed-by: NPatrick Delaunay <patrick.delaunay@foss.st.com>
-
由 Patrice Chotard 提交于
BITS_PER_LONG is used to represent register's size which is 32. But when compiled on arch64, BITS_PER_LONG is then equal to 64. Fix bank and offset computation to make it work on arch32 and arch64 and ensure that register's size is always equal to 32. Signed-off-by: NPatrice Chotard <patrice.chotard@foss.st.com> Signed-off-by: NPankaj Dev <pankaj.dev@st.com> Reviewed-by: NPatrick Delaunay <patrick.delaunay@foss.st.com>
-