summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2021-12-23fdt: Add a Kconfig for boards with a prior stageSimon 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: Simon Glass <sjg@chromium.org>
2021-12-23fdt: Report the devicetree sourceSimon 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: Simon Glass <sjg@chromium.org>
2021-12-23fdt: Record where the devicetree came fromSimon Glass
Keep track of where the devicetree came from, so we can report this later. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-12-23dm: core: Allow getting some basic statsSimon Glass
Add a function that returns some basic stats about driver model. For now we only have two. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-12-23fdt: Don't call board_fdt_blob_setup() without OF_BOARDSimon 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: Simon Glass <sjg@chromium.org>
2021-12-23fdt: Drop remaining preprocessor macros in fdtdec_setup()Simon Glass
We only have two choices for obtaining the devicetree. Simplify the code to make that clear. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-12-23fdt: Drop OF_CONTROL check in fdtdec_setup()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: Simon Glass <sjg@chromium.org>
2021-12-23fdt: Use if() for fdtcontroladdr checkSimon Glass
Change this to use if() instead of #if Signed-off-by: Simon Glass <sjg@chromium.org>
2021-12-23fdt: Drop #ifdef around board_fdt_blob_setup()Simon Glass
This serves no purpose. Drop it. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-12-23fdt: Drop CONFIG_SPL_BUILD check in fdtdec_setup()Simon Glass
Move this to the header file to clean up the C code. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-12-23fdt: Drop #ifdefs with MULTI_DTB_FITSimon Glass
Refactor the code to drop the #ifdefs for this feature. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-12-23fdt: Move MULTI_DTB_FIT handling out of fdtdec_setup()Simon Glass
This logic is a bit convoluted for one function. Move the mulit-FIT part into its own function. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2021-12-23fdt: Make it easier to debug u-boot.dtsi filesSimon 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: Simon Glass <sjg@chromium.org>
2021-12-23fdt: Drop CONFIG_BINMAN_STANDALONE_FDTSimon 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: Simon Glass <sjg@chromium.org>
2021-12-23fdt: Make OF_BOARD a bool optionSimon 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: Simon Glass <sjg@chromium.org>
2021-12-23arm: highbank: Add devicetree filesSimon Glass
Add an empty version of this file, so that we can at least build this board when devicetrees are required. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-12-23arm: qemu-ppce500: Add a devicetree fileSimon 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: Simon Glass <sjg@chromium.org>
2021-12-23arm: bcm7xxx: Add a devicetree fileSimon 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: Simon Glass <sjg@chromium.org>
2021-12-23arm: xilinx_versal_virt: Add a devicetree fileSimon Glass
Add an empty file to prevent build errors when building with CONFIG_OF_SEPARATE enabled. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-12-23arm: octeontx: Add an empty devicetree fileSimon 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: Simon Glass <sjg@chromium.org>
2021-12-23arm: xenguest_arm64: Add a empty devicetree fileSimon 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: Simon Glass <sjg@chromium.org>
2021-12-23arm: vexpress: Add a devicetree files for junoSimon 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: Simon Glass <sjg@chromium.org> Acked-by: Linus Walleij <linus.walleij@linaro.org>
2021-12-23arm: rpi: Sync rpi dts files from LinuxSimon 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: Simon Glass <sjg@chromium.org>
2021-12-23riscv: qemu: Split devicetree files for qemu_riscv32/64Simon 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: Heinrich Schuchardt <heinrich.schuchardt@canaonical.com> Signed-off-by: Simon Glass <sjg@chromium.org>
2021-12-23arm: qemu: Add a devicetree file for qemu_arm64 virtSimon 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: Heinrich Schuchardt <heinrich.schuchardt@canaonical.com> Signed-off-by: Simon Glass <sjg@chromium.org>
2021-12-23arm: qemu: Add a devicetree file for qemu_armSimon 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: Heinrich Schuchardt <heinrich.schuchardt@canaonical.com> Signed-off-by: Simon Glass <sjg@chromium.org>
2021-12-23arm: riscv: qemu: Explain how to extract the generated dtSimon 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: Simon Glass <sjg@chromium.org>
2021-12-23arm: qemu: Mention -nographic in the docsSimon Glass
Without this option QEMU appears to hang. Add it to avoid confusion. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2021-12-21Merge branch 'next' of ↵Tom Rini
https://source.denx.de/u-boot/custodians/u-boot-marvell into next - pci_mvebu: Misc improvements and cleanup (Pali) - turris_mox: Remove extra newline after module topology (Marek)
2021-12-21doc: remove duplicate page inclusionHeinrich Schuchardt
doc/usage/index.rst in branch origin/next includes usage/environment twice. Remove the duplicate entry. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2021-12-21arm: mvebu: turris_mox: Remove extra newline after module topologyMarek Behún
Remove extra newline after module topology is printed. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de>
2021-12-21pci: pci_mvebu: Remove unused DECLARE_GLOBAL_DATA_PTRPali Rohár
The global data pointer is not used in this driver, remove it's declaration. 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>
2021-12-21pci: pci_mvebu: Replace MBUS_PCI_*_SIZE by resource_size()Pali Rohár
Use more appropriate resource_size() function when working with data in struct resource. 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>
2021-12-21pci: pci_mvebu: Move setup for BAR[0] where other BARs are setupPali 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 193a1e9f196b ("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: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de>
2021-12-20Merge tag 'v2022.01-rc4' into nextTom Rini
Prepare v2022.01-rc4
2021-12-20Prepare v2022.01-rc4Tom Rini
Signed-off-by: Tom Rini <trini@konsulko.com>
2021-12-20Revert "image: Remove #ifdefs from select_ramdisk()"Tom Rini
This reverts commit f33a2c1bd0fb371511a485cac1f182ba50db51be. This causes a crash on some platforms as seen here: https://lore.kernel.org/r/f153017b-c41a-0d32-67b9-f288e695f900@baylibre.com/ Reported-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Tom Rini <trini@konsulko.com>
2021-12-20fw_setenv: Unbreak fw_setenv caused by buggy MEMISLOCKED useJoakim 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: Joakim Tjernlund <joakim.tjernlund@infinera.com>
2021-12-20Merge tag '20211220-fixes-for-2022.01' of ↵Tom Rini
https://source.denx.de/u-boot/custodians/u-boot-i2c i2c changes for 20211220-fixes-for-2022.01 - mvtwsi: Swab the register address if its size is > 1
2021-12-20i2c: mvtwsi: Swab the register address if its size is > 1Stefan 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: Stefan 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: Marek Behún <marek.behun@nic.cz>
2021-12-19Merge branch 'next' of ↵Tom Rini
https://source.denx.de/u-boot/custodians/u-boot-marvell into next - Armada XP etc: Move to DM_I2C (Stefan) - Some mvebu comphy + mox + fdt_support changes (Marek & Pali) - mvebu: a38x: improve USB3 serdes configuration (Stefan Eichenberger) - mvebu: Some maintainer updates (Pali) - mvebu: Misc minor cleanup (Pali)
2021-12-19arm: mvebu: Use printf for printing fatal errorsPali Rohár
There is no point to hide/disable fatal errors via debug() macro. Print fatal errors loudly. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de>
2021-12-19arm: mvebu: Remove commented example codePali Rohár
Include file debug_uart.h already contains documentation how to use it. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de>
2021-12-19arm: mvebu: serial: Add me as co-maintainer and author of Marvell serial driversPali Rohár
There is no maintainer entry for serial_mvebu_a3700.c. Add entry with Pali and Stefan as maintainers. Signed-off-by: Pali Rohár <pali@kernel.org> Acked-by: Stefan Roese <sr@denx.de> Reviewed-by: Stefan Roese <sr@denx.de>
2021-12-19arm: mvebu: pci: Add me as co-maintainer and author of Marvell PCIe driversPali Rohár
There is no maintainer entry for pci-aardvark.c. Add entry for pci-aardvark.c and pci_mvebu.c with Pali and Stefan as maintainers. Signed-off-by: Pali Rohár <pali@kernel.org> Acked-by: Stefan Roese <sr@denx.de> Reviewed-by: Stefan Roese <sr@denx.de>
2021-12-19arm: mvebu: a38x: serdes: improve USB3 electrical configurationStefan Eichenberger
This is a backport from Marvell U-Boot: https://github.com/MarvellEmbeddedProcessors/u-boot-marvell commit 381d029e7a ("fix: serdes: a38x, a39x: Improve USB3 electrical configuration") Improves electrical USB3 receiver jitter tolerance test: - De-Emphasize force, in functional mode the transmitter should always have 3.5db de-emphasize, so we are forcing it. - After forcing De-Emphasize, choose 3.5db (After forcing, default is 6dB so need to change it to 3.5dB). - Align90 set to 0x58 - this is the sample point in the receiver, after the clock is recovered this sampler samples at the chosen value, usually it is supposed to be 0x60(which is the center of the eye), but sometimes after adding jitter and ISI the center of the eye can move slightly and the sample point is not necessarily the exact center, and after optimization (searching the middle of the eye manually) it was seen that the center of the eye is actually 0x58 and not 0x60. - FFE Res and FFE Cap set to 0xE & 0xF respectively: improves this settings is adequate according to how the USB3 spec defines the interconnect, thus improves USB3 jitter tolerance settings. - Change the resolution of the DFE to 0x3 which is 6mV(highest resolution) , this avoids the DFE to saturate and cease to work. - HPF set to 0x3 which is 5Khz high pass filter, the function of the HPF is to filter the low frequency patterns(below 5Khz) to make sure that the signal is not a noise, the setting before was 0x1(205Khz), and the change came since the USB3 CP0 pattern, that is used in the USB3 jitter tolerance testing, is similar to PRBS15, which has 2^15=32768bits which is 32768*200ps (200ps is one Unit interval in USB3(5Gbps)) = 6.5us, which is in frequency terms: 152Khz. since the PRBS15 is a random pattern and can theoretically have once in a while a pattern that will be at frequency of 152Khz, hence the previous setting (205khz HPF) can possibly filter this pattern which can cause to an error in the receiver, thus this change to avoid such scenarios. Signed-off-by: Stefan Eichenberger <eichest@gmail.com> Signed-off-by: René Straub <rene.straub@netmodule.com> Reviewed-by: Stefan Roese <sr@denx.de>
2021-12-19arm: mvebu: a38x: serdes: fix serdes config for USB3Stefan Eichenberger
The electrical serdes configuration for USB3 expects an array as data argument. For USB3 the second value is used (see data_arr_idx = USB3 = 1). However, because only one value is inside the array mv_seq_exec is accessing an invalid element and the serdes is configured wrongly. This wrong initialization is leading to an unreliable detection mechanism for some USB3 devices. We were able to reproduce the issue regularly with an LTE modem from Sierra Wireless (SM7455) where it was not detected as USB3 device in 1/3 of all tests. This commit fixes the issue by setting data_arr_idx to 0. This is the same value as the original U-Boot from Marvell is using. There it is called FIRST_CELL which is a define for 0. See: https://github.com/MarvellEmbeddedProcessors/u-boot-marvell commit 56f963ce4c ("fix: serdes: a38x, a39x: Fix USB3 serdes DB initialization") Signed-off-by: Stefan Eichenberger <eichest@gmail.com> Signed-off-by: René Straub <rene.straub@netmodule.com> Reviewed-by: Stefan Roese <sr@denx.de>
2021-12-19fdt_support: Add fdt_delete_disabled_nodes() and use in Turris MOXMarek Behún
Move Turris MOX specific remove_disabled_nodes() to fdt_support with name fdt_delete_disabled_nodes(), so that others can potentially use it. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de>
2021-12-19arm: mvebu: turris_mox: Fix unstable board topology readingMarek Behún
The pre-relocation board topology reading in board_fix_fdt() is unstable: sometimes wrong data are read from the SPI bus. This is due to wrong order of SPI bus configuration instructions: we first need to set the pins to SPI mode, and only after that configure the bus. Also add a 1ms delay before enabling chip-select, so that the clock pin is high for some time before reading the bus. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de>
2021-12-19phy: marvell: a3700: Convert to official DT bindings in COMPHY driverPali Rohár
Convert A3720 common PHY driver to official DT bindings. This puts us closer to be able to synchronize A3720 device-trees with those from Linux. Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <marek.behun@nic.cz> Cc: Konstantin Porotchkin <kostap@marvell.com> Cc: Robert Marko <robert.marko@sartura.hr> Cc: Luka Perkov <luka.perkov@sartura.hr> Cc: Marcin Wojtas <mw@semihalf.com> Cc: Grzegorz Jaszczyk <jaz@semihalf.com> Reviewed-by: Stefan Roese <sr@denx.de>
generated by cgit v1.2.3 (git 2.0.4) at 2024-07-02 13:56:38 +0000