December 2021 - U-Boot

[PATCH] Makefile: Add more files to clean list
by Adam Ford 13 Jan '22

13 Jan '22

When building for i.mx8m boards with binman, a few more additional files are created which should be removed when running 'make clean' Signed-off-by: Adam Ford <aford173(a)gmail.com> diff --git a/Makefile b/Makefile index ae9bfab91a..3c2b7008d4 100644 --- a/Makefile +++ b/Makefile @@ -2108,7 +2108,9 @@ CLEAN_FILES += include/bmp_logo.h include/bmp_logo_data.h tools/version.h \ u-boot* MLO* SPL System.map fit-dtb.blob* \ u-boot-ivt.img.log u-boot-dtb.imx.log SPL.log u-boot.imx.log \ lpc32xx-* bl31.c bl31.elf bl31_*.bin image.map tispl.bin* \ - idbloader.img flash.bin flash.log defconfig keep-syms-lto.c + idbloader.img flash.bin flash.log defconfig keep-syms-lto.c \ + mkimage-out.spl.mkimage mkimage.spl.mkimage imx-boot.map \ + itb.fit.fit itb.fit.itb itb.map spl.map # Directories & files removed with 'make mrproper' MRPROPER_DIRS += include/config include/generated spl tpl \ -- 2.32.0

2 1

[PATCH v4] timer: Add a migration message
by Simon Glass 13 Jan '22

13 Jan '22

Some boards still use the old timer mechanism. Set a deadline for them to update to driver model. Point to some examples as well. This needs a bit of a strange rule to avoid an error on some boards. Signed-off-by: Simon Glass <sjg(a)chromium.org> --- Changes in v4: - Fix alsol typo Changes in v3: - Push out the deadline Makefile | 4 ++++ doc/develop/driver-model/migration.rst | 12 ++++++++++++ 2 files changed, 16 insertions(+) diff --git a/Makefile b/Makefile index ab32efb4d11..7b24250103e 100644 --- a/Makefile +++ b/Makefile @@ -1124,6 +1124,10 @@ endif $(call deprecated,CONFIG_DM_ETH,Ethernet drivers,v2020.07,$(CONFIG_NET)) $(call deprecated,CONFIG_DM_I2C,I2C drivers,v2022.04,$(CONFIG_SYS_I2C_LEGACY)) $(call deprecated,CONFIG_DM_KEYBOARD,Keyboard drivers,v2022.10,$(CONFIG_KEYBOARD)) + @# CONFIG_SYS_TIMER_RATE has brackets in it for some boards which + @# confuses this rule. Use if() to send just a single character which + @# is enable to tell 'deprecated' that one of these symbols exists + $(call deprecated,CONFIG_TIMER,Timer drivers,v2023.01,$(if $(strip $(CONFIG_SYS_TIMER_RATE)$(CONFIG_SYS_TIMER_COUNTER)),x)) @# Check that this build does not use CONFIG options that we do not @# know about unless they are in Kconfig. All the existing CONFIG @# options are whitelisted, so new ones should not be added. diff --git a/doc/develop/driver-model/migration.rst b/doc/develop/driver-model/migration.rst index 3dbeea6537c..10f474e9cdf 100644 --- a/doc/develop/driver-model/migration.rst +++ b/doc/develop/driver-model/migration.rst @@ -106,3 +106,15 @@ Deadline: 2022.10 This is a legacy option which has been replaced by driver model. Maintainers should submit patches switching over to using CONFIG_DM_KEYBOARD and other base driver model options in time for inclusion in the 2022.10 release. + +CONFIG_SYS_TIMER_RATE and CONFIG_SYS_TIMER_COUNTER +-------------------------------------------------- +Deadline: 2023.01 + +These are legacy options which have been replaced by driver model. +Maintainers should submit patches switching over to using CONFIG_TIMER and +other base driver model options in time for inclusion in the 2022.10 release. + +There is only one method to implement, unless you want to support bootstage, +in which case you need an early timer also. For example drivers, see +sandbox_timer.c and rockchip_timer.c -- 2.34.1.173.g76aa8bc2d0-goog

2 1

[PATCH] LynxOS is no longer supported
by Thomas Huth 13 Jan '22

13 Jan '22

LynxOS needed the do_bootm_lynxkdi() function that got removed in 7e713067ee ("Remove LYNX KDI remainders") - and that function needed a lynxkdi_boot() function, where the last implementation had been removed in 98f705c9ce ("powerpc: remove 4xx support") already. Looks like this OS is definitely not supported anymore, so remove it from the corresponding lists. Signed-off-by: Thomas Huth <thuth(a)redhat.com> --- README | 3 +-- boot/image.c | 3 --- 2 files changed, 1 insertion(+), 5 deletions(-) diff --git a/README b/README index 9606a8b3ac..064e781d45 100644 --- a/README +++ b/README @@ -3359,8 +3359,7 @@ details; basically, the header defines the following image properties: * Target Operating System (Provisions for OpenBSD, NetBSD, FreeBSD, 4.4BSD, Linux, SVR4, Esix, Solaris, Irix, SCO, Dell, NCR, VxWorks, LynxOS, pSOS, QNX, RTEMS, INTEGRITY; - Currently supported: Linux, NetBSD, VxWorks, QNX, RTEMS, LynxOS, - INTEGRITY). + Currently supported: Linux, NetBSD, VxWorks, QNX, RTEMS, INTEGRITY). * Target CPU Architecture (Provisions for Alpha, ARM, Intel x86, IA64, MIPS, NDS32, Nios II, PowerPC, IBM S390, SuperH, Sparc, Sparc 64 Bit; Currently supported: ARM, Intel x86, MIPS, NDS32, Nios II, PowerPC). diff --git a/boot/image.c b/boot/image.c index 992e72991d..6ab827b2d4 100644 --- a/boot/image.c +++ b/boot/image.c @@ -106,9 +106,6 @@ static const table_entry_t uimage_os[] = { { IH_OS_INVALID, "invalid", "Invalid OS", }, { IH_OS_ARM_TRUSTED_FIRMWARE, "arm-trusted-firmware", "ARM Trusted Firmware" }, { IH_OS_LINUX, "linux", "Linux", }, -#if defined(USE_HOSTCC) - { IH_OS_LYNXOS, "lynxos", "LynxOS", }, -#endif { IH_OS_NETBSD, "netbsd", "NetBSD", }, { IH_OS_OSE, "ose", "Enea OSE", }, { IH_OS_PLAN9, "plan9", "Plan 9", }, -- 2.27.0

3 3

[PATCH] board: sama7g5ek: set blue led on at boot time
by Eugen Hristev 13 Jan '22

13 Jan '22

From: Mihai Sain <mihai.sain(a)microchip.com> Set blue led on at boot time in order to highlight that u-boot is loaded. Signed-off-by: Mihai Sain <mihai.sain(a)microchip.com> --- board/atmel/sama7g5ek/sama7g5ek.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/board/atmel/sama7g5ek/sama7g5ek.c b/board/atmel/sama7g5ek/sama7g5ek.c index 4df43d81f8..5444799dfb 100644 --- a/board/atmel/sama7g5ek/sama7g5ek.c +++ b/board/atmel/sama7g5ek/sama7g5ek.c @@ -17,6 +17,13 @@ DECLARE_GLOBAL_DATA_PTR; +static void board_leds_init(void) +{ + atmel_pio4_set_pio_output(AT91_PIO_PORTB, 8, 0); /* LED RED */ + atmel_pio4_set_pio_output(AT91_PIO_PORTA, 13, 0); /* LED GREEN */ + atmel_pio4_set_pio_output(AT91_PIO_PORTD, 20, 1); /* LED BLUE */ +} + int board_late_init(void) { return 0; @@ -65,6 +72,8 @@ int board_init(void) /* address of boot parameters */ gd->bd->bi_boot_params = CONFIG_SYS_SDRAM_BASE + 0x100; + board_leds_init(); + return 0; } -- 2.25.1

2 1

[PATCH u-boot-next 00/12] Common U-Boot macros for PCI Configuration Mechanism #1
by Pali Rohár 13 Jan '22

13 Jan '22

This patch series add new U-Boot macros for composing Config Address for PCI Configuration Mechanism #1 as defined in PCI Local Bus Specification, including extended variant (which do not have any formal specification) and then use these new macros (PCI_CONF1_ADDRESS and PCI_CONF1_EXT_ADDRESS) in all PCI drivers that use Config Address according to PCI Configuration Mechanism #1. PCI Configuration Mechanism #1 was originally specified for x86 platforms and it is still supported on x86 together with PCIe ECAM. Nowadays lot of non-ECAM-compliant ARM PCIe controllers use only extended variant of this address construction and some of them requires cleared Enable bit. Extended variant is also supported by x86 AMD Barcelona (and new) CPUs, but U-Boot code does not provide this support yet. Note that it exists also PCI Configuration Mechanism #2, but this one was removed from PCI Local Bus Specification revision 3.0 and seems that it is not used by any PCI driver in U-Boot. So I have not added macros for this mechanism in this patch series. Because lot of hardware still use this (rather old) mechanism, relevant U-Boot PCI and PCIe drivers have own ad-hoc code address construction, which is repeated and written in different ways. This patch series is code cleanup of these PCIe drivers to use common U-Boot macros for PCI Configuration Mechanism #1. The last change is fixing construction of Config Address in PCI driver sh7751. Construction with this change matches Linux kernel code and also U-Boot code prior commit mentioned in commit message. I have tested this patch series only for PCI mvebu driver on A385 board and it is working fine. So Please properly review all other changes. Ideally test them. I have run CI tests with these changes on github and everything passed: https://github.com/u-boot/u-boot/pull/101 Please let me know what do you think about this change. Pali Rohár (12): pci: Add standard PCI Config Address macros pci: gt64120: Use PCI_CONF1_ADDRESS() macro pci: mpc85xx: Use PCI_CONF1_EXT_ADDRESS() macro pci: msc01: Use PCI_CONF1_ADDRESS() macro pci: mvebu: Use PCI_CONF1_EXT_ADDRESS() macro pci: tegra: Use PCI_CONF1_EXT_ADDRESS() macro pci: fsl: Use PCI_CONF1_EXT_ADDRESS() macro pci: mediatek: Use PCI_CONF1_EXT_ADDRESS() macro pci: sh7780: Use PCI_CONF1_ADDRESS() macro x86: pci: Use PCI_CONF1_ADDRESS() macro m68k: mcf5445x: pci: Use PCI_CONF1_ADDRESS() macro pci: sh7751: Fix access to config space via PCI_CONF1_ADDRESS() macro arch/m68k/cpu/mcf5445x/pci.c | 7 +++--- arch/x86/cpu/pci.c | 4 ++-- drivers/pci/pci_gt64120.c | 7 ++---- drivers/pci/pci_mpc85xx.c | 4 ++-- drivers/pci/pci_msc01.c | 7 ++---- drivers/pci/pci_mvebu.c | 17 ++++---------- drivers/pci/pci_sh7751.c | 29 ++--------------------- drivers/pci/pci_sh7780.c | 8 +++---- drivers/pci/pci_tegra.c | 11 +++------ drivers/pci/pcie_fsl.c | 10 ++++---- drivers/pci/pcie_mediatek.c | 17 +++++++------- include/gt64120.h | 12 ---------- include/msc01.h | 9 -------- include/pci.h | 45 ++++++++++++++++++++++++++++++++++++ 14 files changed, 83 insertions(+), 104 deletions(-) -- 2.20.1

3 39

[PATCH] pci: When disabling pref MEM set all base bits
by Pali Rohár 13 Jan '22

13 Jan '22

It is common to set all base address bits to one and all limit address bits to zero for disabling address forwarding. Forwarding is disabled when base address is higher than limit address, so this change should not have any effect. Signed-off-by: Pali Rohár <pali(a)kernel.org> --- drivers/pci/pci_auto.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pci/pci_auto.c b/drivers/pci/pci_auto.c index 6e5ed194f247..c0acf331398d 100644 --- a/drivers/pci/pci_auto.c +++ b/drivers/pci/pci_auto.c @@ -243,7 +243,7 @@ void dm_pciauto_prescan_setup_bridge(struct udevice *dev, int sub_bus) cmdstat |= PCI_COMMAND_MEMORY; } else { /* We don't support prefetchable memory for now, so disable */ - dm_pci_write_config16(dev, PCI_PREF_MEMORY_BASE, 0x1000 | + dm_pci_write_config16(dev, PCI_PREF_MEMORY_BASE, 0xfff0 | prefechable_64); dm_pci_write_config16(dev, PCI_PREF_MEMORY_LIMIT, 0x0 | prefechable_64); -- 2.20.1

3 4

[PATCH] pci: Disable I/O forwarding during autoconfiguration if unsupported
by Pali Rohár 13 Jan '22

13 Jan '22

If U-Boot does not have any I/O resource for assignment then disable I/O forwarding in PCI bridge autoconfiguration code. Default initial state of PCI bridge IO registers is unspecified, therefore they can be in enabled if U-Boot does not touch them. Signed-off-by: Pali Rohár <pali(a)kernel.org> --- drivers/pci/pci_auto.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/pci/pci_auto.c b/drivers/pci/pci_auto.c index 7e6ee54be087..6e5ed194f247 100644 --- a/drivers/pci/pci_auto.c +++ b/drivers/pci/pci_auto.c @@ -265,6 +265,14 @@ void dm_pciauto_prescan_setup_bridge(struct udevice *dev, int sub_bus) (pci_io->bus_lower & 0xffff0000) >> 16); cmdstat |= PCI_COMMAND_IO; + } else { + /* Disable I/O if unsupported */ + dm_pci_write_config8(dev, PCI_IO_BASE, 0xf0 | io_32); + dm_pci_write_config8(dev, PCI_IO_LIMIT, 0x0 | io_32); + if (io_32 == PCI_IO_RANGE_TYPE_32) { + dm_pci_write_config16(dev, PCI_IO_BASE_UPPER16, 0x0); + dm_pci_write_config16(dev, PCI_IO_LIMIT_UPPER16, 0x0); + } } /* Enable memory and I/O accesses, enable bus master */ -- 2.20.1

3 4

[PATCH] pci: Fix register for determining type of IO base address
by Pali Rohár 13 Jan '22

13 Jan '22

Function dm_pciauto_prescan_setup_bridge() configures base address registers, therefore it should read type of IO from base address registers (and not from limit address registers). Note that base and limit address registers should have same type, so this change is just usage correction and has no functional change on correctly working hardware. Fixes: 8e85f36a8fab ("pci: Fix configuring io/memory base and limit registers of PCI bridges") Signed-off-by: Pali Rohár <pali(a)kernel.org> --- drivers/pci/pci_auto.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pci/pci_auto.c b/drivers/pci/pci_auto.c index 5af4ee6e56df..7e6ee54be087 100644 --- a/drivers/pci/pci_auto.c +++ b/drivers/pci/pci_auto.c @@ -197,7 +197,7 @@ void dm_pciauto_prescan_setup_bridge(struct udevice *dev, int sub_bus) dm_pci_read_config16(dev, PCI_COMMAND, &cmdstat); dm_pci_read_config16(dev, PCI_PREF_MEMORY_BASE, &prefechable_64); prefechable_64 &= PCI_PREF_RANGE_TYPE_MASK; - dm_pci_read_config8(dev, PCI_IO_LIMIT, &io_32); + dm_pci_read_config8(dev, PCI_IO_BASE, &io_32); io_32 &= PCI_IO_RANGE_TYPE_MASK; /* Configure bus number registers */ -- 2.20.1

3 2

[PATCH u-boot-next 0/4] pci: Use PCIE_ECAM_OFFSET() macro
by Pali Rohár 13 Jan '22

13 Jan '22

This patch series replace usage of custom driver functions and macros by PCIE_ECAM_OFFSET() macro provided by U-Boot pci.h header file. Please properly review these patches as I do not have hardware with these drivers for testing. Support for PCIE_ECAM_OFFSET() macro is in U-Boot next branch. Pali Rohár (4): vexpress64: Remove unused macro XR3PCI_ECAM_OFFSET pci: pcie-brcmstb: Use PCIE_ECAM_OFFSET() macro pci: pcie_iproc: Use PCIE_ECAM_OFFSET() macro pci: pci_octeontx: Use PCIE_ECAM_OFFSET() macro board/armltd/vexpress64/pcie.c | 4 --- drivers/pci/pci_octeontx.c | 61 +++++++++++----------------------- drivers/pci/pcie_brcmstb.c | 7 +--- drivers/pci/pcie_iproc.c | 17 ++-------- 4 files changed, 24 insertions(+), 65 deletions(-) -- 2.20.1

4 11

[PATCH v2 1/4] rockchip: spl: change call condition rockchip_stimer_init()
by Johan Jonker 12 Jan '22

12 Jan '22

The Rockchip SoCs rk3066/rk3188 have no CONFIG_ROCKCHIP_STIMER_BASE defined. Currently only rk3188 has an exception. Make this more generic and call the function rockchip_stimer_init() only when CONFIG_ROCKCHIP_STIMER_BASE is available. Signed-off-by: Johan Jonker <jbx6244(a)gmail.com> --- Changed V2: use IS_ENABLED add include kconfig.h move define location so that rockchip_stimer_init() is always visible to the compiler --- arch/arm/mach-rockchip/spl.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/arch/arm/mach-rockchip/spl.c b/arch/arm/mach-rockchip/spl.c index 02c40fb3..31558415 100644 --- a/arch/arm/mach-rockchip/spl.c +++ b/arch/arm/mach-rockchip/spl.c @@ -16,6 +16,7 @@ #include <asm/global_data.h> #include <asm/io.h> #include <linux/bitops.h> +#include <linux/kconfig.h> DECLARE_GLOBAL_DATA_PTR; @@ -70,7 +71,6 @@ u32 spl_mmc_boot_mode(const u32 boot_device) return MMCSD_MODE_RAW; } -#if !defined(CONFIG_ROCKCHIP_RK3188) #define TIMER_LOAD_COUNT_L 0x00 #define TIMER_LOAD_COUNT_H 0x04 #define TIMER_CONTROL_REG 0x10 @@ -80,6 +80,7 @@ u32 spl_mmc_boot_mode(const u32 boot_device) __weak void rockchip_stimer_init(void) { +#if defined(CONFIG_ROCKCHIP_STIMER_BASE) /* If Timer already enabled, don't re-init it */ u32 reg = readl(CONFIG_ROCKCHIP_STIMER_BASE + TIMER_CONTROL_REG); @@ -94,8 +95,8 @@ __weak void rockchip_stimer_init(void) writel(0xffffffff, CONFIG_ROCKCHIP_STIMER_BASE + 4); writel(TIMER_EN | TIMER_FMODE, CONFIG_ROCKCHIP_STIMER_BASE + TIMER_CONTROL_REG); -} #endif +} __weak int board_early_init_f(void) { @@ -132,9 +133,11 @@ void board_init_f(ulong dummy) hang(); } arch_cpu_init(); -#if !defined(CONFIG_ROCKCHIP_RK3188) - rockchip_stimer_init(); -#endif + + /* Init secure timer */ + if (IS_ENABLED(CONFIG_ROCKCHIP_STIMER_BASE)) + rockchip_stimer_init(); + #ifdef CONFIG_SYS_ARCH_TIMER /* Init ARM arch timer in arch/arm/cpu/armv7/arch_timer.c */ timer_init(); -- 2.20.1

2 6