aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-10-10log: Allow LOG_DEBUG to always enable log outputSimon Glass7-84/+129
At present if CONFIG_LOG enabled, putting LOG_DEBUG at the top of a file (before log.h inclusion) causes _log() to be executed for every log() call, regardless of the build- or run-time logging level. However there is no guarantee that the log record will actually be displayed. If the current log level is lower than LOGL_DEBUG then it will not be. Add a way to signal that the log record should always be displayed and update log_passes_filters() to handle this. With the new behaviour, log_debug() will always log if LOG_DEBUG is enabled. Move log_test_syslog_nodebug() into its own file since it cannot be made to work where it is, with LOG_DEBUG defined. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-10-09Merge branch '2020-10-09-kconfig-reorg'Tom Rini539-1872/+1878
- Re-organize a number of Kconfig related entries to be better organized for long term maintenance.
2020-10-09configs: Resync with savedefconfigTom Rini531-931/+924
Rsync all defconfig files using moveconfig.py Signed-off-by: Tom Rini <trini@konsulko.com>
2020-10-09Kconfig: Create a new tools menuSimon Glass3-9/+14
At present MKIMAGE_DTC_PATH is in the devicetree menu but not within 'devicetree control' since it does not relate to that. As a result it shows up in the top menu. It actually relates to the mkimage tool, so create a new tools menu for it and move it there. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-10-09Kconfig: Move BOARD_TYPES under init optionsSimon Glass1-8/+8
This actually relates to something displayed on start-up, so move it into that menu. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-10-09Kconfig: Move BOUNCE_BUFFER under driver optionsSimon Glass2-11/+11
This option does not belong at the top level. Move it under generic driver options. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-10-09Kconfig: Move VERSION_VARIABLE under environmentSimon Glass2-10/+9
This relates to the environment so should not be at the top level. Move it. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-10-09Kconfig: MISC_INIT_R and BOARD_LATE_INIT -> start-up hooksSimon Glass1-17/+17
These are start-up hooks so put them under that menu. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-10-09Kconfig: Move startup hooks under init optionsSimon Glass1-31/+31
These hooks relate to U-Boot init so move them under that menu. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-10-09Kconfig: Create a new 'init options' menuSimon Glass1-0/+4
There are quite a few options at the top level relating to U-Boot init. Move them into their own menu. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-10-09Kconfig: Move DEFAULT_FDT_FILE under boot optionsSimon Glass2-5/+5
This relates to booting since it is the default devicetree provided to Linux. Move it under the 'boot options' menu. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-10-09Kconfig: Move SUPPORT_RAW_INITRD under boot optionsSimon Glass2-8/+8
This relates to booting, so move it under the 'boot images' menu. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-10-09Kconfig: Move misc boot options under 'boot options'Simon Glass2-53/+53
There are a number of miscellaneous boot images at the top level of the kconfig menu. Move these into the 'boot options' menu. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-10-09Kconfig: Move CONFIG_BOOTDELAY under autoboot optionsSimon Glass2-16/+16
This option relates to autoboot, so move it there. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-10-09Kconfig: Move autoboot options under boot optionsSimon Glass2-117/+117
At present the autoboot options are in cmd/Kconfig but they don't really relate to commands. They relate to booting, so move this menu under the boot menu. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-10-09Kconfig: Move boot media under boot optionsSimon Glass2-63/+63
This relates to booting, so move it under the boot menu. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-10-09Kconfig: Move boot timing under boot optionsSimon Glass2-291/+291
This relates to booting, so move it under the boot menu. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-10-09Kconfig: Move boot menu into common/Simon Glass3-341/+342
Most of the boot options are in common/Kconfig but that file is already extremely large. Create a new Kconfig.boot to hold the boot options. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-10-09Kconfig: Add a 'Boot options' menuSimon Glass1-0/+4
There are quite a few boot-related menu options at the top level. Create a new menu to hold these and move 'Boot images' into it. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-10-09Merge branch '2020-10-08-misc-board-improvements'Tom Rini37-303/+2171
- Move ASPEED ram driver, update. - Exhance pinctrl/gpio support, update Kendryte K210 support - Enhance qemu_arm64 support for a single binary to work with and without TF-A
2020-10-08qemu-arm64: Enable POSITION_INDEPENDENTAndre Przywara2-0/+2
Now that PIE works when U-Boot is started from ROM, let's enable CONFIG_POSITION_INDEPENDENT, which allows to load U-Boot also via ARM Trusted-Firmware's fip.bin to DRAM, without tweaking the configuration. To get a writable initial stack, we need to keep the fixed initial stack pointer, which points to DRAM in our case. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Stephen Warren <swarren@nvidia.com>
2020-10-08qemu-arm: Drop ARCH_SUPPORT_TFABOOTAndre Przywara1-1/+0
CONFIG_ARCH_SUPPORT_TFABOOT was used on the qemu-arm64 platform to guard a tweak to the flash bank configuration. U-Boot now reads the current flash setup from the devicetree, so there is no need for this option anymore. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2020-10-08qemu-arm: Remove need to specify flash banksAndre Przywara1-7/+1
Currently we hard-code the number and initial addresses of QEMU's flash banks, even though our code is perfectly able to gather the same information from the DTB provided by QEMU. This is especially annoying, since we have two slightly different U-Boot configurations ("bare-metal" vs. loaded via Arm Trusted Firmware), which need to be selected at build time. Drop the two hard coded alternatives, and use CONFIG_SYS_MAX_FLASH_BANKS_DETECT instead, which relies on the DTB to figure out the actual flash configuration at runtime. Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2020-10-08arm64: PIE: Allow fixed stack pointerAndre Przywara1-1/+1
Currently selecting CONFIG_POSITION_INDEPENDENT also forces us to use an initial stack pointer relative to the beginning of the BSS section. This makes some sense, because this should be writable memory anyway. However the BSS section is not cleared or used until later in the setup process (after relocation), so memory nearby might not be available early enough to host the initial stack. This is an issue if U-Boot is loaded from (Flash-)ROM, for instance. Allow CONFIG_INIT_SP_RELATIVE to be turned off by a board's config, to be able to select a fixed stack pointer, for instance in known good DRAM. This will help QEMU utilising PIE, when it's loaded to (Flash-)ROM. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Stephen Warren <swarren@nvidia.com>
2020-10-08arm64: PIE: Skip fixups if distance is zeroAndre Przywara1-1/+2
When the actual offset between link and runtime address is zero, there is no need for patching up U-Boot early when running with CONFIG_POSITION_INDEPENDENT. Skip the whole routine when the distance is 0. This helps when U-Boot is loaded into ROM, or in otherwise sensitive memory locations. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Stephen Warren <swarren@nvidia.com>
2020-10-08arm64: PIE: Do not skip static relocationAndre Przywara1-1/+1
When we build an arm64 target and enable POSITION_INDEPENDENT, we were skipping our build-time dynamic relocation fixup routine (STATIC_RELA). This was probably done because we didn't need it in this case, as the PIE fixup routine in start.S would take care of that at runtime. However when we now skip this routine (upon detecting that the fixup offset is 0), this might lead to uninitialised pointers. Remove the exception, so that we always do the build-time relocation. NOTE: GNU binutils starting with v2.27.1 do this build-time relocation automatically, to be in-line with other architecures. So on newer toolchains our manual fixup is actually not needed. It doesn't hurt to have it, though, so that we keep compatibility with the popular Linaro toolchains, which lack this feature. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Stephen Warren <swarren@nvidia.com>
2020-10-08arm: Kconfig: Explain TFABOOTAndre Przywara1-2/+7
The CONFIG_TFABOOT option is more about what U-Boot DOES NOT need to do than to support some features. Explain a bit more in the Kconfig help text to avoid misunderstandings. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2020-10-08examples: make examples/ optionalHeinrich Schuchardt2-1/+9
Most users don't need the standalone API examples. Distributions like SUSE do not supply libgcc for cross-compiling and we cannot do without on ARMv8 for building examples/. Make examples selectable via symbol CONFIG_EXAMPLES. It defaults to yes on ARCH_QEMU to ensure that we compile the API as part of our continuous integration. Cc: Matthias Brugger <mbrugger@suse.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Matthias Brugger <mbrugger@suse.com>
2020-10-08wdt: designware: fix timeout calculation due to expecting KHzJack Mitchell1-1/+1
The timeout calculation is based on the clk being in KHz but the clk api returns the clk value in Hz. Convert this to KHz to calculate the correct timeout value. Signed-off-by: Jack Mitchell <ml@embed.me.uk>
2020-10-08riscv: Add FPIOA and GPIO support for Kendryte K210Sean Anderson2-2/+71
This patch adds the necessary configs and docs for FPIOA and GPIO support on the K210. Signed-off-by: Sean Anderson <seanga2@gmail.com>
2020-10-08riscv: add DT binding for BOOT button on Maix boardHeinrich Schuchardt1-0/+11
Add a device tree binding for the BOOT button on the Maix board. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Sean Anderson <seanga2@gmail.com> Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Rick Chen <rick@andestech.com>
2020-10-08riscv: Add pinmux and gpio bindings for Kendryte K210Sean Anderson2-0/+116
This patch adds the necessary device tree bindings. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Acked-by: Rick Chen <rick@andestech.com>
2020-10-08test: dm: Test for default led namingSean Anderson2-2/+3
This modifies the existing led test to check for default led naming as added in the previous patch. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-10-08led: gpio: Default to using node name if label is absentSean Anderson1-5/+2
This more closely mirrors Linux's behaviour, and will make it easier to transition to using function+color in the future. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-10-08gpio: dw: Return output value when direction is outSean Anderson1-7/+12
dm_gpio_ops.get_value can be called when the gpio is either input or output. The current dw code always returns the input value, which is invalid if the direction is set to out. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Ley Foon Tan <ley.foon.tan@intel.com>
2020-10-08gpio: dw: Add a trailing underscore to generated nameSean Anderson1-1/+9
Previously, if there was no bank-name property, it was easy to have confusing gpio names like "gpio1@08", instead of "gpio1@0_8". This patch follows the example of the sifive gpio driver. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-10-08gpio: dw: Fix warnings about casting int to pointerSean Anderson1-2/+2
Change the type of gpio_dwabp_platdata.base from fdt_addr_t to a void pointer, since we pass it to readl. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Ley Foon Tan <ley.foon.tan@intel.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-10-08pinctrl: Add support for Kendryte K210 FPIOASean Anderson6-0/+1126
The Fully-Programmable Input/Output Array (FPIOA) device controls pin multiplexing on the K210. The FPIOA can remap any supported function to any multifunctional IO pin. It can also perform basic GPIO functions, such as reading the current value of a pin. However, GPIO functionality remains largely unimplemented (in favor of the dedicated GPIO peripherals). Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-10-08test: pinmux: Add test for pin muxingSean Anderson7-73/+274
This extends the pinctrl-sandbox driver to support pin muxing, and adds a test for that behaviour. The test is done in C and not python (like the existing tests for the pinctrl uclass) because it needs to call pinctrl_select_state. Another option could be to add a command that invokes pinctrl_select_state and then test everything in test/py/tests/test_pinmux.py. The pinctrl-sandbox driver now mimics the way that many pinmux devices work. There are two groups of pins which are muxed together, as well as four pins which are muxed individually. I have tried to test all normal paths. However, very few error cases are explicitly checked for. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-10-08pinctrl: Reformat documentation in dm/pinctrl.hSean Anderson3-162/+347
This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-10-08pinctrl: Add pinmux property support to pinctrl-genericSean Anderson3-44/+169
The pinmux property allows for smaller and more compact device trees, especially when there are many pins which need to be assigned individually. Instead of specifying an array of strings to be parsed as pins and a function property, the pinmux property contains an array of integers representing pinmux groups. A pinmux group consists of the pin identifier and mux settings represented as a single integer or an array of integers. Each individual pin controller driver specifies the exact format of a pinmux group. As specified in the Linux documentation, a pinmux group may be multiple integers long. However, no existing drivers use multi-integer pinmux groups, so I have chosen to omit this feature. This makes the implementation easier, since there is no need to allocate a buffer to do endian conversions. Support for the pinmux property is done differently than in Linux. As far as I can tell, inversion of control is used when implementing support for the pins and groups properties to avoid allocating. This results in some duplication of effort; every property in a config node is parsed once for each pin in that node. This is not such an overhead with pins and groups properties, since having multiple pins in one config node does not occur especially often. However, the semantics of the pinmux property make such a configuration much more appealing. A future patch could parse all config properties at once and store them in an array. This would make it easier to create drivers which do not function solely as callbacks from pinctrl-generic. This commit increases the size of the sandbox build by approximately 48 bytes. However, it also decreases the size of the K210 device tree by 2 KiB from the previous version of this series. The documentation has been updated from the last Linux commit before it was split off into yaml files. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-10-08ram: add ddr4 dual x8 configurationDylan Hung3-1/+12
the aspeed ddr sdram controller needs to know if the memory chip mounted on the board is dual x8 die or not. Or it may get the wrong size of the memory space. Signed-off-by: Dylan Hung <dylan_hung@aspeedtech.com> Reviewed-by: Ryan Chen <ryan_chen@aspeedtech.com>
2020-10-08ram: move aspeed ram driver into drivers/ directoryDylan Hung4-1/+5
to improve the maintainability. It is more easier to modify and add configurations of the driver in the centralized ram driver directory. Signed-off-by: Dylan Hung <dylan_hung@aspeedtech.com> Reviewed-by: Ryan Chen <ryan_chen@aspeedtech.com>
2020-10-08Merge https://gitlab.denx.de/u-boot/custodians/u-boot-cfi-flashTom Rini3-21/+11
- Fix devicetree address determination seen on QEMU ARM64 - Use DMA for reads is available
2020-10-08cfi_flash: Fix devicetree address determinationAndre Przywara1-18/+6
The cfi-flash driver uses an open-coded version of the generic algorithm to decode and translate multiple frames of a "reg" property. This starts off the wrong foot by using the address-cells and size-cells properties of *this* very node, and not of the parent. This somewhat happened to work back when we were using a wrong default size of 2, but broke about a year ago with commit 0ba41ce1b781 ("libfdt: return correct value if #size-cells property is not present"). Instead of fixing the reinvented wheel, just use the generic function that does all of this properly. This fixes U-Boot on QEMU (-arm64), which was crashing due to decoding a wrong flash base address: DRAM: 1 GiB Flash: "Synchronous Abort" handler, esr 0x96000044 elr: 00000000000211dc lr : 00000000000211b0 (reloc) elr: 000000007ff5e1dc lr : 000000007ff5e1b0 x0 : 00000000000000f0 x1 : 000000007ff5e1d8 x2 : 000000007edfbc48 x3 : 0000000000000000 x4 : 0000000000000000 x5 : 00000000000000f0 x6 : 000000007edfbc2c x7 : 0000000000000000 x8 : 000000007ffd8d70 x9 : 000000000000000c x10: 0400000000000003 x11: 0000000000000055 ^^^^^^^^^^^^^^^^ Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Stefan Roese <sr@denx.de>
2020-10-08mtd: cfi_mtd: Use DMA for readsVignesh Raghavendra1-1/+3
When possible use DMA for reading from CFI flash, this provides upto 5x improvement in read performance with high speed CFI compliant flashes like HyperFlash. Code will gracefully fallback to CPU copy when DMA is unavailable. Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Stefan Roese <sr@denx.de>
2020-10-08dma: Reduce error level when DMA channel type does not existVignesh Raghavendra1-2/+2
Caller would need gracefully handle failures of dma_get_device(), therefore reduce pr_err() to pr_debug() when DMA device is not found. Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Stefan Roese <sr@denx.de>
2020-10-07Merge tag 'mips-pull-2020-10-07' of ↵Tom Rini37-23/+26127
https://gitlab.denx.de/u-boot/custodians/u-boot-mips - mips: octeon: add support for DDR4 memory controller - mips: octeon: add support for DWC3 USB - mips: octeon: add support for booting Linux
2020-10-07mips: octeon: octeon_common.h: Increase CONFIG_SYS_BOOTM_LENStefan Roese1-0/+2
Increase CONFIG_SYS_BOOTM_LEN to 64MiB for Linux kernel booting. Signed-off-by: Stefan Roese <sr@denx.de>
2020-10-07mips: octeon: Add bootoctlinux commandAaron Williams3-0/+716
Octeon needs a platform specific cmd to boot the Linux kernel, as specific parameters need to be passed and special handling for the multiple cores (SMP) is needed. Co-developed-by: Stefan Roese <sr@denx.de> Signed-off-by: Aaron Williams <awilliams@marvell.com> Signed-off-by: Stefan Roese <sr@denx.de> [use gd->ram_base instead of gd->bd->bi_memstart] Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
generated by cgit v1.1 at 2024-08-01 15:53:34 +0000