- 23 12月, 2021 28 次提交
-
-
由 Simon Glass 提交于
When U-Boot is started from another firmware program, not just a prior phase of U-Boot, special behaviour is typically used. In particular, the device tree may come from that prior stage. At present this is sort-of indicated by OF_BOARD, although the correlation is not 1:1, since that option simply means that the board has a custom mechanism for obtaining the device tree. For example, sandbox defines OF_BOARD. Also the board_fdt_blob_setup() function can in fact make use of the devicetree in U-Boot if it wishes, as used by dragonboard410c until very recently. Add an explicit Kconfig for this situation. Update the OF_BOARD option to more-accurately reflect what it is doing, e.g. for sandbox. Drop the docs in the README as it is out of date. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
It can be confusing to figure out where the devicetree came from. It seems important enough to warrant a message during boot. Add information about the number of devices and uclasses too since it is helpful to have some idea what is going on with driver model. Report the devicetree source in bdinfo too. This looks something like this, with > marking the new line. U-Boot 2021.10-00190 (Oct 30 2021 - 09:01:29 -0600) DRAM: 128 MiB > Core: 42 devices, 11 uclasses, devicetree: passage Flash: 64 MiB Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
Keep track of where the devicetree came from, so we can report this later. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
Add a function that returns some basic stats about driver model. For now we only have two. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
At present this override function is called even when OF_BOARD is not enabled. This makes it impossible to disable this feature and in fact makes the OF_BOARD option useless. Reinstate its intended purpose, so that it is possible to switch between the appended devicetree and one provided by the board's custom function. A follower patch adds warnings for this scenario, but for now we don't have a Kconfig that definitively tells us that OF_BOARD should be used. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
We only have two choices for obtaining the devicetree. Simplify the code to make that clear. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
This function should only be called when OF_CONTROL is enabled. It fails in fdtdec_prepare_fdt() anyway, since gd->fdt_blob stays as NULL if OF_CONTROL is not enabled. Drop this useless check. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
Change this to use if() instead of #if Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
This serves no purpose. Drop it. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
Move this to the header file to clean up the C code. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
Refactor the code to drop the #ifdefs for this feature. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
This logic is a bit convoluted for one function. Move the mulit-FIT part into its own function. Signed-off-by: NSimon Glass <sjg@chromium.org> Reviewed-by: NIlias Apalodimas <ilias.apalodimas@linaro.org>
-
由 Simon Glass 提交于
At present one must hack the Makefile to see what is going on with these files. Also it doesn't quite work correctly. Fix this by using an environment variable for debugging. Update the docs also. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
This was added as a hack to work around not having an in-tree devicetree. Now that this is fixed it is not needed. Drop it. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
This should not be a separate option from OF_SEPARATE. It is a run-time option to override the devicetree, even if present. Move the option out of the choice. Disable BINMAN_FDT for a few boards which don't actually use it. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
Add an empty version of this file, so that we can at least build this board when devicetrees are required. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
This uses QEMU virt which creates its own devicetree. Add an empty version of this file, so that we can at least build this board when devicetrees are required. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
Add an empty devicetree file for these boards. It seems to be possible to obtain a real one from another bootloader called 'bolt' but I will leave this to the maintainer. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
Add an empty file to prevent build errors when building with CONFIG_OF_SEPARATE enabled. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
Add an empty file to prevent build errors when building with CONFIG_OF_SEPARATE enabled. Unfortunately there are no build instructions in the U-Boot tree to enable a real file to be created. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
Add an empty version of this file, so that we can at least build this board when devicetrees are required. The real devicetree is created by the Xen project on-the-fly. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
Sync these file, obtained from Linux v5.15. Add a note for the maintainer, and SPDX lines where they are missing. The added lines are: SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause Note, this matches the text in those files, but is not the same as the GPL-2.0 of some files. [1] https://releases.linaro.org/android/reference-lcr/juno/7.1-17.05/Signed-off-by: NSimon Glass <sjg@chromium.org> Acked-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Simon Glass 提交于
Sync these files, obtained from Linux v5.15. This adds a devicetree file for rpi_4 which was not there before. Testing shows no change so far as I can see: - boots to U-Boot prompt on rpi0, rpi2 - boots to distro on rpi3 - boots to distro on rpi4 I am assuming that syncing with Linux is safe, but the maintainer should know for sure. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
This uses QEMU virt which creates its own devicetree. Copy the existing empty version of this file, so splitting the existing qemu-virt into two, since anyone actually trying to use this will need a different devicetree for 32- and 64-bit machines. Tested-by: NHeinrich Schuchardt <heinrich.schuchardt@canaonical.com> Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
This uses QEMU virt which creates its own devicetree. Add an empty version of this file, so that we can at least build this board when devicetrees are required. Tested-by: NHeinrich Schuchardt <heinrich.schuchardt@canaonical.com> Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
This uses QEMU virt which creates its own devicetree. Add an empty version of this file, so that we can at least build this board when devicetrees are required. Tested-by: NHeinrich Schuchardt <heinrich.schuchardt@canaonical.com> Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
QEMU currently generates a devicetree for use with U-Boot. Explain how to obtain it. Also explain how to merge it to produce a devicetree with the U-Boot features included. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
Without this option QEMU appears to hang. Add it to avoid confusion. Signed-off-by: NSimon Glass <sjg@chromium.org> Reviewed-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
-
- 21 12月, 2021 8 次提交
-
-
https://source.denx.de/u-boot/custodians/u-boot-marvell由 Tom Rini 提交于
- pci_mvebu: Misc improvements and cleanup (Pali) - turris_mox: Remove extra newline after module topology (Marek)
-
由 Heinrich Schuchardt 提交于
doc/usage/index.rst in branch origin/next includes usage/environment twice. Remove the duplicate entry. Signed-off-by: NHeinrich Schuchardt <heinrich.schuchardt@canonical.com>
-
由 Marek Behún 提交于
Remove extra newline after module topology is printed. Signed-off-by: NMarek Behún <marek.behun@nic.cz> Reviewed-by: NStefan Roese <sr@denx.de>
-
由 Pali Rohár 提交于
The global data pointer is not used in this driver, remove it's declaration. Signed-off-by: NPali Rohár <pali@kernel.org> Signed-off-by: NMarek Behún <marek.behun@nic.cz> Reviewed-by: NStefan Roese <sr@denx.de>
-
由 Pali Rohár 提交于
Use more appropriate resource_size() function when working with data in struct resource. Signed-off-by: NPali Rohár <pali@kernel.org> Signed-off-by: NMarek Behún <marek.behun@nic.cz> Reviewed-by: NStefan Roese <sr@denx.de>
-
由 Pali Rohár 提交于
Function mvebu_pcie_setup_wins() sets up all other BARs, so move setup of BAR[0] to this function to have common code at one place. In the past, commit 193a1e9f ("pci: pci_mvebu: set BAR0 after memory space is set") moved setup of BAR[0] to another location, due to ath10k not working in kernel, but the reason why was unknown, but it seems to work now, and we think the issue then was cause by the PCIe Root Port presenting itself as a Memory Controller and therefore U-Boot's code have overwritten the BAR. Since the driver now ignores any write operations to PCIe Root Port BARs, this should not be an issue anymore. Signed-off-by: NPali Rohár <pali@kernel.org> Signed-off-by: NMarek Behún <marek.behun@nic.cz> Reviewed-by: NStefan Roese <sr@denx.de>
-
由 Tom Rini 提交于
Prepare v2022.01-rc4
-
由 Tom Rini 提交于
Signed-off-by: NTom Rini <trini@konsulko.com>
-
- 20 12月, 2021 4 次提交
-
-
由 Tom Rini 提交于
This reverts commit f33a2c1b. This causes a crash on some platforms as seen here: https://lore.kernel.org/r/f153017b-c41a-0d32-67b9-f288e695f900@baylibre.com/Reported-by: NNeil Armstrong <narmstrong@baylibre.com> Signed-off-by: NTom Rini <trini@konsulko.com>
-
由 Joakim Tjernlund 提交于
Commit "fw_setenv: lock the flash only if it was locked before" checks for Locked status with uninitialized erase data. Address by moving the test for MEMISLOCKED. Fixes: 8a726b852502 ("fw_setenv: lock the flash only if it was locked before") Signed-off-by: NJoakim Tjernlund <joakim.tjernlund@infinera.com>
-
https://source.denx.de/u-boot/custodians/u-boot-i2c由 Tom Rini 提交于
i2c changes for 20211220-fixes-for-2022.01 - mvtwsi: Swab the register address if its size is > 1
-
由 Stefan Roese 提交于
Testing on Armada XP with an EEPROM using register address with size of 2 has shown, that the register address bytes are sent to the I2C EEPROM in the incorrect order. This patch swabs the address bytes so that the correct address is transferred to the I2C device. BTW: This worked without any issues before migrating Armada XP to DM I2C. Signed-off-by: NStefan Roese <sr@denx.de> Cc: Heiko Schocher <hs@denx.de> Cc: Samuel Holland <samuel@sholland.org> Cc: Baruch Siach <baruch@tkos.co.il> Cc: Pali Rohár <pali@kernel.org> Cc: Marek Behún <marek.behun@nic.cz> Tested-by: NMarek Behún <marek.behun@nic.cz>
-