- Oct 09, 2022
-
-
Add gpmi nand clock. Those clock can be used in mxs nand driver to run nand to EDO mode 5, 4, ... Signed-off-by:
Michael Trimarchi <michael@amarulasolutions.com> Reviewed-by:
Dario Binacchi <dario.binacchi@amarulasolutions.com> Signed-off-by:
-
Add shared counter in order to avoid to swich off clock that are already used. Signed-off-by:
-
Dario Binacchi authored
Add missing stub for functions [devm_]clk_...() when CONFIG_CLK is deactivated. Signed-off-by:
Sean Anderson <seanga2@gmail.com>
-
- Oct 08, 2022
-
-
This fixes the below build error if nand.c is included in an SPL build. /work/u-boot/drivers/mtd/nand/raw/nand.c: In function ‘nand_init_chip’: /work/u-boot/drivers/mtd/nand/raw/nand.c:82:28: error: ‘nand_chip’ undeclared (first use in this function) 82 | struct nand_chip *nand = &nand_chip[i]; | ^~~~~~~~~ /work/u-boot/drivers/mtd/nand/raw/nand.c:82:28: note: each undeclared identifier is reported only once for each function it appears in /work/u-boot/drivers/mtd/nand/raw/nand.c:84:20: error: ‘base_address’ undeclared (first use in this function); did you mean ‘base_addr’? 84 | ulong base_addr = base_address[i]; | ^~~~~~~~~~~~ | base_addr Fixes: 068c41f1 ("Finish conversion CONFIG_SYS_NAND_SELF_INIT to Kconfig") Signed-off-by:Roger Quadros <rogerq@kernel.org> Reviewed-by:
-
- Oct 07, 2022
-
-
Tom Rini authored
- Update RISC-V to use 32bit or 64bit toolchains, depending on if we're building for 32bit or 64bit CPUs. This requires updating the Docker container as well to have the 32bit toolchain.
-
Tom Rini authored
- Assorted platform updates for developerbox, armv8 platforms in general, TI K3 and AM65 platforms, nuvoton NPCM845 SoC and then clock driver, ftgpio010 support, and common/board_f cleanups.
-
The following description is copied from the equivalent patch for the Linux Kernel proposed by Aurelien Jarno: >From version 2.38, binutils default to ISA spec version 20191213. This means that the csr read/write (csrr*/csrw*) instructions and fence.i instruction has separated from the `I` extension, become two standalone extensions: Zicsr and Zifencei. As the kernel uses those instruction, this causes the following build failure: arch/riscv/cpu/mtrap.S: Assembler messages: arch/riscv/cpu/mtrap.S:65: Error: unrecognized opcode `csrr a0,scause' arch/riscv/cpu/mtrap.S:66: Error: unrecognized opcode `csrr a1,sepc' arch/riscv/cpu/mtrap.S:67: Error: unrecognized opcode `csrr a2,stval' arch/riscv/cpu/mtrap.S:70: Error: unrecognized opcode `csrw sepc,a0' Signed-off-by:
Alexandre Ghiti <alexandre.ghiti@canonical.com> Reviewed-by:
Bin Meng <bmeng.cn@gmail.com>
Tested-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Tested-by:
Heiko Stuebner <heiko@sntech.de> Tested-by:
Christian Stewart <christian@paral.in> Reviewed-by:
Rick Chen <rick@andestech.com>
-
riscv32 needs a different toolchain than riscv64 Signed-off-by:
Simon Glass <sjg@chromium.org> Reviewed-by:
-
For building riscv32 targets we should use the riscv32 toolchain. Add it to the Docker image. Drop the riscv toolchain-alias as we do not need it in future. While in here, update to the latest "jammy" tag. Signed-off-by:
Tom Rini <trini@konsulko.com> Reviewed-by:
-
Add clock controller driver for NPCM845 Signed-off-by:
Jim Liu <JJLIU0@nuvoton.com> Acked-by:
-
Add basic support for the Nuvoton NPCM845 EVB (Arbel). Signed-off-by: -
For the TI SoCs affected by errata i2329, enable MDIO manual mode by default Signed-off-by:
Ravi Gunasekaran <r-gunasekaran@ti.com> Reviewed-by:
Ramon Fried <rfried.dev@gmail.com>
-
In certain TI SoCs, on the CPSW and ICSS peripherals, there is a possibility that the MDIO interface returns corrupt data on MDIO reads or writes incorrect data on MDIO writes. There is also a possibility for the MDIO interface to become unavailable until the next peripheral reset. The workaround is to configure the MDIO in manual mode and disable the MDIO state machine and emulate the MDIO protocol by reading and writing appropriate fields in MDIO_MANUAL_IF_REG register of the MDIO controller to manipulate the MDIO clock and data pins. More details about the errata i2329 and the workaround is available in: https://www.ti.com/lit/er/sprz487a/sprz487a.pdf Add implementation to disable MDIO state machine, configure MDIO in manual mode and provide software MDIO read and writes via MDIO bitbanging. Allow the MDIO to be initialized based on the need for manual mode. Signed-off-by:
-
Include linux/sizes.h because it defines SZ_64K which is used in many places inside k3-udma.c This fixes the error: ‘SZ_64K’ undeclared which appears during build time Signed-off-by:
Dhruva Gole <d-gole@ti.com> Reviewed-by:
-
When MMU is already enabled then dcache_enable() does not call mmu_setup() and so setup_all_pgtables() is also never called. In this situation when some driver calls mmu_set_region_dcache_behaviour() function then U-Boot crashes with error message: Emergency page table not setup. Fix this issue by explicitly calling setup_all_pgtables() in dcache_enable() function near condition for mmu_setup(). This change fixes chainloading U-Boot from U-Boot on Turris Mox board which uses mvneta ethernet driver which calls mmu_set_region_dcache_behaviour(). Signed-off-by:Pali Rohár <pali@kernel.org> Reviewed-by:
Marek Behún <kabel@kernel.org> Reviewed-by:
Stefan Roese <sr@denx.de>
-
Drop the remaining ifdef around spl.h include. Reviewed-by:
Ovidiu Panait <ovpanait@gmail.com>
-
In order to move ppc-specific code out of setup_dest_addr(), provide an arch-specific variant arch_setup_dest_addr(), that can be used by architecture code to fix up the initial reloc address. It is called at the end of setup_dest_addr() initcall and the default implementation is a nop stub. Reviewed-by:
-
asm/mach_type.h header and CONFIG_MACH_TYPE macro are arm-specific, so move related bdinfo logic to arch_setup_bdinfo() in arch/arm/lib/bdinfo.c. Reviewed-by:
-
The XTRN_DECLARE_GLOBAL_DATA_PTR declarations in ppc code are permanently commented out, so there are no users for this macro: #if 1 #define DECLARE_GLOBAL_DATA_PTR register volatile gd_t *gd asm ("r2") #else /* We could use plain global data, but the resulting code is bigger */ #define XTRN_DECLARE_GLOBAL_DATA_PTR extern #define DECLARE_GLOBAL_DATA_PTR XTRN_DECLARE_GLOBAL_DATA_PTR \ gd_t *gd #endif Remove all references to this macro, but add a documentation note regarding the possibility of using plain global data for the GD pointer. Signed-off-by: -
dram_init() can't modify global/static variables, so move the mem_map setup later when bss is available. Signed-off-by:Jassi Brar <jaswinder.singh@linaro.org>
-
Identity-map the second and later memory banks which are located >4GB. Signed-off-by: -
Add Faraday Technology's FTGPIO010 controller driver. Signed-off-by:Sergei Antonov <saproj@gmail.com>
-
- Oct 06, 2022
-
-
https://source.denx.de/u-boot/custodians/u-boot-marvellTom Rini authored
- Kirkwood: remove km/keymile kirkwood boards (Holger) - mtd: nand: pxa3xx: simplify ECC hardware parameters (Chris) - tools: kwbimage: Verify maximal kwbimage header size (Pali) - mvebu: Add support for programming LD eFuse on Armada 385 (Pali) - mvebu: Misc timer improvements / cleanup (Stefan)
-
VHV gpio is connected to MCU and only on updated board design. Without it eFUSE programming does not work. Omnia MCU driver exports this GPIO to U-Boot under name mcu_56 and only when it is supported by MCU. So U-Boot fuse command refuse eFUSE programming on older board design when VHV gpio is not available. We tested that Armada 385 without connected VHV gpio can do eFUSE programming but only for some bits and only sometimes - it is unstable. And better to be disabled on older board design without VHV gpio support. Signed-off-by: -
VHV_Enable GPIO is required to enable during eFuse programming on Armada SoCs not from 3700 family. Add support for enabling and disabling VHV pin via GPIO during eFuse programming, when specified. All details are in Marvell AN-389: ARMADA VHV Power document (Doc. No. MV-S302545-00 Rev. C, August 2, 2016). Note that due to HW Errata 3.6 eFuse erroneous burning (Ref #: HWE-3718342) VHV power must be disabled while core voltage is off to prevent erroneous eFuse programming. This is specified in Marvell ARMADA 380/385/388 Functional Errata, Guidelines, and Restrictions document (Doc. No. MV-S501377-00 Rev. D, December 1, 2016). Signed-off-by: -
This patch implements LD eFuse programming support. Armada 385 contains two LD eFuse lines, each is 256 bit long with one additional lock bit. LD 0 line is mapped to U-Boot fuse bank 64 and LD 1 line to fuse bank 65. U-Boot 32-bit fuse words 0-8 are mapped to LD eFuse line bits 0-255. U-Boot fuse word 9 is mapped to LD eFuse line lock bit. So to program LD 1 General Purpose Data line, use U-Boot fuse command: => fuse prog -y 65 0 0x76543210 => fuse prog -y 65 1 0xfedcba98 => fuse prog -y 65 2 0x76543210 => fuse prog -y 65 3 0xfedcba98 => fuse prog -y 65 4 0x76543210 => fuse prog -y 65 5 0xfedcba98 => fuse prog -y 65 6 0x76543210 => fuse prog -y 65 7 0xfedcba98 => fuse prog -y 65 8 0x1 Signed-off-by: -
Stefan Roese authored
Move the code making sure that the timer is initialized only once into orion_timer_init(), which is called from timer_early_init() and from orion_timer_probe(). This way the timer is not re-initialized. Signed-off-by: -
Stefan Roese authored
Since the move to CONFIG_TIMER with support for CONFIG_TIMER_EARLY, this platform specific init_timer() function is not needed any more. Let's remove it completely. Signed-off-by: -
BootROM loads kwbimage header to L2-SRAM and BootROM reserve only 192 kB for it. Signed-off-by:
-
Replace the if/else chain in pxa_ecc_init() with a lookup table. This makes the code more concise and hopefully easier to follow. Remove the unused ecc_layout tables and replace it with a single dummy one (the pxa3xx driver has never used this but the mtd subsystem expects it to be provided). Tested on an Allied Telesis x530 switch with Micron MT29F2G08ABAEAWP NAND Flash. Signed-off-by:Chris Packham <judge.packham@gmail.com>
-
These boards are out of maintenance and can be removed. Signed-off-by:
Holger Brunck <holger.brunck@hitachienergy.com> Reviewed-by:
-
- Oct 03, 2022
-
-
Tom Rini authored
-
Tom Rini authored
Signed-off-by: -
When the imx8mn.dtsi file was pulled in from Linux, the UARTs were moved into an spba sub-node which wasn't being included in the SPL device tree. This meant the references to the UART weren't being handled properly and when booting the system would constantly reboot. Fix this by adding the spba node to the spl device tree to restore normal booting. Based on the patch from Adam Ford for the imx8mn-beacon-kit-u-boot board. Fixes: 4e5114da ("imx8mn: synchronise device tree with linux") Signed-off-by:
Fabio Estevam <festevam@denx.de>
-
When the imx8mn.dtsi file was pulled in from Linux, the UARTs were moved into an spba sub-node which wasn't being included in the SPL device tree. This meant the references to the UART weren't being handled properly and when booting the system would constantly reboot. Fix this by adding the spba node to the spl device tree to restore normal booting. Based on the patch from Adam Ford for the imx8mn-beacon-kit-u-boot board. Fixes: 4e5114da ("imx8mn: synchronise device tree with linux") Signed-off-by:
-
- Sep 30, 2022
-
-
Tom Rini authored
To quote the author: At present the ofnode interface is somewhat limited, in that it cannot access the device tree provided by the OS, only the one used by U-Boot itself (assuming these are separate). This prevents using ofnode functions to handle device tree fixups, i.e. ft_board_setup() and the like. The ofnode interface was introduced to allow a consistent API to access the device tree, whether a flat tree or a live tree (OF_LIVE) is in use. With the flat tree, adding nodes and properties at the start of the tree (as often happens when writing to the /chosen node) requires copying a lot of data for each operation. With live tree, such operations are quite a bit faster, since there is no memory copying required. This has to be weighed against the required memory allocation with OF_LIVE, as well as the cost of unflattening and flattening the device tree which U-Boot is running. This series enables support for access to multiple device trees with the ofnode interface. This is already available to some extent with OF_LIVE, but some of the ofnode functions need changes to allow the tree to be specified. The mechanism works by using the top 1-4 bits of the device tree offset. The sign bit is not affected, since negative values must be supported. With this implemented, it becomes possible to use the ofnode interface to do device tree fixups. The only current user is the EVT_FT_FIXUP event. This has two main benefits: - ofnode can now be used everywhere, in preference to the libfdt calls - live tree can eventually be used everywhere, with potential speed improvements when larger number of fixups are used This series is only a step along the way. Firstly, while it is possible to access the 'fix-up' tree using OF_LIVE, most of the fixup functions use flat tree directly, rather than the ofnode interface. These need to be updated. Also the tree must be flattened again before it is passed to the OS. This is not currently implemented. With OFNODE_MULTI_TREE disabled this has almost no effect on code size: around 4 bytes if EVENT is enabled, 0 if not. With the feature enabled, the increase is around 700 bytes, e.g. on venice2: $ buildman -b ofn2a venice2 -sS --step 0 Summary of 2 commits for 1 boards (1 thread, 64 jobs per thread) 01: image: Drop some other #ifdefs in image-board.c arm: w+ venice2 48: wip arm: (for 1/1 boards) all +668.0 text +668.0 This size increase is not too bad, considering the extra functionality, but is too large to enable everywhere. So for now this features needs to be opt-in only, based on EVENT. -
https://source.denx.de/u-boot/custodians/u-boot-efiTom Rini authored
Pull request for efi-2022-10-rc6 Documentation: * doc: improve description of autostart UEFI: * prefix test functions with efi_st_ in the LoadImage unit test * avoid a warning message in efi_initrd_deregister()
-
Add a function to copy properties from one node to another. Signed-off-by: -
At present ofnode_write_prop() is inconsistent between livetree and flattree, in that livetree requires the caller to ensure the property value is stable (e.g. in rodata or allocated) but flattree does not, since it makes a copy. This makes the API call a bit painful to use, since the caller must do different things depending on OF_LIVE. Add a new 'copy' argument which tells the function to make a copy if needed. Add some tests to cover this behaviour. Signed-off-by: -
This test can operate in all conditions now. Update the test and comments. Signed-off-by:
-
