January 2017 - U-Boot

[U-Boot] [PATCH v5 0/9] rockchip: Add gmac Ethernet support
by Romain Perier 04 Jan '17

04 Jan '17

>From Simon: This v3 patch is an update on Sjoerd's original v2 series from Feburary. I have dealt with the changes requested at the time, and adjusted the way that the speed change is handled. Tested on firefly-rk3288, rock2. Original cover letter: To add support I've taken a slightly different approach then some of the other boards with a designware IP block, by creating a new driver to take care of the platfrom glue which subclasses the main designware driver instead of adding the compatibility string the designware driver directly and doing the SoC specific setup in the board files. This seems quite a bit more elegant in a device model based world. I've only tested this series on a Radxa Rock 2 board, it would be great if someone could test this on other boards with the designware IP especially for those with the reset GPIO in devicetree (e.g. some of the Allwinner boards). Compared to the first one round the pinctrl related bits were dropped as RK3288 now has a full pinctrl driver. Furthermore the started hook in the designware driver was renamed to fix_mac_speed in line with what linux uses and moved to the dw_link_adjust function. Changes in v5: - Changed the commit message for gmac - Added my Acked-by to few commits Changes in v4: - Fix commit message to say 'rk3399' Changes in v3: - Add a few new patches - Add comments for struct gmac_rk3288_platdata - Add new patch to adjust dw_adjust_link() to return an error - Add new patch to enable networking on evb-rk3399 - Add new patch to export the operation functions - Add new patch to split the link init into a separate function - Adjust binding to use r/tx-delay instead of r/tx_delay - Drop the 'net: designware: Add a fix_mac_speed hook' patch - Sort includes - Use debug() instead of printf() for error - Use function calls instead of fix_mac_speed() hook - Use new clk interface Changes in v2: - Adjust to new hook name - Fix various coding style nits Simon Glass (4): net: designware: Adjust dw_adjust_link() to return an error net: designware: Split the link init into a separate function net: designware: Export the operation functions rockchip: evb-rk3339: Enable DHCP Sjoerd Simons (5): net: designware: Export various functions/struct to allow subclassing net: gmac_rockchip: Add Rockchip GMAC driver rockchip: Enable networking support on rock2 and firefly rockchip: Add PXE and DHCP to the default boot targets rockchip: Drop Ethernet from the TODO configs/evb-rk3399_defconfig | 3 + configs/firefly-rk3288_defconfig | 4 + configs/rock2_defconfig | 4 + doc/README.rockchip | 1 - drivers/net/Kconfig | 7 ++ drivers/net/Makefile | 1 + drivers/net/designware.c | 57 ++++++++++---- drivers/net/designware.h | 13 ++++ drivers/net/gmac_rockchip.c | 154 ++++++++++++++++++++++++++++++++++++++ include/configs/rockchip-common.h | 4 +- 10 files changed, 230 insertions(+), 18 deletions(-) create mode 100644 drivers/net/gmac_rockchip.c -- 2.11.0

1 9

[U-Boot] [PATCH v3 0/6] arm: tegra: apalis-tk1, mmc and ext clock loopback
by Marcel Ziswiler 04 Jan '17

04 Jan '17

From: Marcel Ziswiler <marcel.ziswiler(a)toradex.com> This series adds support for the Toradex Apalis TK1 as well as moves the CONFIG_TEGRA_MMC to Kconfig and introduces a new option to disable the external clock loopback on SDMMC3. The whole series is also available here: http://git.toradex.com/cgit/u-boot-toradex.git/log/?h=for-next Changes in v3: - My recent fresh install of Fedora 25 was missing an aarch64 toolchain which made moveconfig.py not properly handle the 6 newer Tegras. I now re-run moveconfig.py after installing an aarch64 toolchain and it all looks sane. Sorry about that, Tom. - Cleaned-up defconfig using savedefconfig. Changes in v2: - Added Simon's reviewed-by. - Added Simon's reviewed-by. - Added Simon's reviewed-by. - Added Simon's reviewed-by. - Added TODO(email) as suggested by Simon so it is clear this is temporary and will be moved to device tree controlled approach once proper kernel integration made it mainline. Marcel Ziswiler (6): arm: tegra: initial support for apalis tk1 mmc: tegra: introduce CONFIG_TEGRA_MMC to Kconfig mmc: tegra: move CONFIG_TEGRA_MMC from headers to defconfigs mmc: tegra: allow disabling external clock loopback apalis-tk1: disable external clock loopback on SDMMC3 apalis-tk1: clean-up defconfig arch/arm/dts/Makefile | 1 + arch/arm/dts/tegra124-apalis.dts | 2203 ++++++++++++++++++++ arch/arm/include/asm/arch-tegra/tegra_mmc.h | 2 + arch/arm/mach-tegra/tegra124/Kconfig | 7 + board/toradex/apalis-tk1/Kconfig | 30 + board/toradex/apalis-tk1/MAINTAINERS | 7 + board/toradex/apalis-tk1/Makefile | 5 + board/toradex/apalis-tk1/apalis-tk1.c | 175 ++ board/toradex/apalis-tk1/as3722_init.c | 117 ++ board/toradex/apalis-tk1/as3722_init.h | 41 + .../toradex/apalis-tk1/pinmux-config-apalis-tk1.h | 287 +++ configs/apalis-tk1_defconfig | 46 + configs/apalis_t30_defconfig | 1 + configs/beaver_defconfig | 1 + configs/cardhu_defconfig | 1 + configs/cei-tk1-som_defconfig | 1 + configs/colibri_t20_defconfig | 1 + configs/colibri_t30_defconfig | 1 + configs/dalmore_defconfig | 1 + configs/e2220-1170_defconfig | 9 +- configs/harmony_defconfig | 1 + configs/jetson-tk1_defconfig | 1 + configs/medcom-wide_defconfig | 1 + configs/nyan-big_defconfig | 1 + configs/p2371-0000_defconfig | 9 +- configs/p2371-2180_defconfig | 9 +- configs/p2571_defconfig | 9 +- configs/p2771-0000-000_defconfig | 9 +- configs/p2771-0000-500_defconfig | 9 +- configs/paz00_defconfig | 1 + configs/plutux_defconfig | 1 + configs/seaboard_defconfig | 1 + configs/tec-ng_defconfig | 1 + configs/tec_defconfig | 1 + configs/trimslice_defconfig | 1 + configs/venice2_defconfig | 1 + configs/ventana_defconfig | 1 + configs/whistler_defconfig | 1 + drivers/mmc/Kconfig | 17 + drivers/mmc/tegra_mmc.c | 16 + include/configs/apalis-tk1.h | 180 ++ include/configs/apalis_t30.h | 1 - include/configs/beaver.h | 1 - include/configs/cardhu.h | 1 - include/configs/cei-tk1-som.h | 1 - include/configs/colibri_t20.h | 1 - include/configs/colibri_t30.h | 1 - include/configs/dalmore.h | 1 - include/configs/e2220-1170.h | 1 - include/configs/harmony.h | 1 - include/configs/jetson-tk1.h | 1 - include/configs/medcom-wide.h | 1 - include/configs/nyan-big.h | 1 - include/configs/p2371-0000.h | 1 - include/configs/p2371-2180.h | 1 - include/configs/p2571.h | 1 - include/configs/p2771-0000.h | 1 - include/configs/paz00.h | 1 - include/configs/plutux.h | 1 - include/configs/seaboard.h | 1 - include/configs/tec-ng.h | 1 - include/configs/tec.h | 1 - include/configs/trimslice.h | 1 - include/configs/venice2.h | 1 - include/configs/ventana.h | 1 - include/configs/whistler.h | 1 - scripts/config_whitelist.txt | 1 - 67 files changed, 3160 insertions(+), 74 deletions(-) create mode 100644 arch/arm/dts/tegra124-apalis.dts create mode 100644 board/toradex/apalis-tk1/Kconfig create mode 100644 board/toradex/apalis-tk1/MAINTAINERS create mode 100644 board/toradex/apalis-tk1/Makefile create mode 100644 board/toradex/apalis-tk1/apalis-tk1.c create mode 100644 board/toradex/apalis-tk1/as3722_init.c create mode 100644 board/toradex/apalis-tk1/as3722_init.h create mode 100644 board/toradex/apalis-tk1/pinmux-config-apalis-tk1.h create mode 100644 configs/apalis-tk1_defconfig create mode 100644 include/configs/apalis-tk1.h -- 2.9.3

4 13

[U-Boot] a couple questions about "CONFIG_*" variables and the whitelist
by Robert P. J. Day 04 Jan '17

04 Jan '17

more random questions about stuff ... i see in the top-level README the explanation: "There are two classes of configuration variables: * Configuration _OPTIONS_: These are selectable by the user and have names beginning with "CONFIG_". * Configuration _SETTINGS_: These depend on the hardware etc. and should not be meddled with if you don't know what you're doing; they have names beginning with "CONFIG_SYS_". so, perhaps put another way, regular CONFIG_ variables represent things that a user has the right to configure to affect the end result, while CONFIG_SYS_ variables represent values tied somehow to the underlying hardware that u-boot *needs* to know to function properly on that hardware? is that a remotely accurate description? but that's not a really hard-and-fast rule, is it? as one example from cmd/Kconfig: config SYS_PROMPT string "Shell prompt" default "=> " help This string is displayed in the command line to the left of the cursor. obviously, the user has the right to set the prompt to whatever he or she wants, and i'm sure there are other examples. so the distinction between those two classes of config variables is not as sharp as the README suggests, is it? or am i misreading the explanation? second question -- i'm pretty sure the standard policy is that *any* config variables that start with "CONFIG_" are supposed to be defined somewhere in a Kconfig file, correct? given the history of u-boot, this clearly isn't true, but in a perfect world, it would be, yes? so that if one wanted to define some local macro names in a header file or something, it should never start with the prefix "CONFIG_" unless it comes from the Kbuild structure. at least that's the standard i remember from the linux kernel. now the whitelist -- i'd never looked at it before, read the first part of scripts/build-whitelist.sh, so apparently, the whitelist represents all of the "CONFIG_"-prefixed variables found scattered throughout the code base, or constructed via CONFIG_SYS_EXTRA_OPTIONS. and i can see there are over 8,000 of them. yeesh. however, given that CONFIG_SYS_EXTRA_OPTIONS is deprecated, and if one follows the rule i mentioned earlier (that CONFIG_ prefixed variables should always be defined in a Kconfig file), in a perfect world, that whitelist would be empty, would it not? and, finally, i'm currently digging through the mtdparts code, and noticed that "CONFIG_MTDPARTS" is in the whitelist file, but there is no Kbuild entry "config MTDPARTS", so i did a quick grep to see: $ grep -r CONFIG_MTDPARTS * include/configs/sheevaplug.h:#define CONFIG_MTDPARTS \ include/configs/sheevaplug.h: "=ttyS0,115200 mtdparts="CONFIG_MTDPARTS \ include/configs/sheevaplug.h: "mtdparts="CONFIG_MTDPARTS include/configs/iconnect.h:#define CONFIG_MTDPARTS \ include/configs/iconnect.h: "mtdparts="CONFIG_MTDPARTS \ include/configs/guruplug.h:#define CONFIG_MTDPARTS \ include/configs/guruplug.h: "mtdparts="CONFIG_MTDPARTS \ include/configs/guruplug.h: "mtdparts="CONFIG_MTDPARTS include/configs/nsa310s.h:#define CONFIG_MTDPARTS \ include/configs/nsa310s.h: "mtdparts="CONFIG_MTDPARTS \ include/configs/ib62x0.h:#define CONFIG_MTDPARTS \ include/configs/ib62x0.h: "mtdparts="CONFIG_MTDPARTS \ include/configs/dockstar.h:#define CONFIG_MTDPARTS "mtdparts=orion_nand:1m(uboot),-(root)\0" include/configs/dockstar.h: "mtdparts="CONFIG_MTDPARTS \ include/configs/goflexhome.h:#define CONFIG_MTDPARTS \ include/configs/goflexhome.h: "mtdparts="CONFIG_MTDPARTS \ scripts/config_whitelist.txt:CONFIG_MTDPARTS $ the above suggests that CONFIG_MTDPARTS is an entirely local variable in a small number of header files, whose scope is never seen outside each of those header files. in that case, it would seem inappropriate to have used that name for that variable, since it gives the impression of being part of the Kbuild structure. i'm not suggesting changing any of that (or maybe i am :-), it just seems silly that using that name causes that variable to end up in the whitelist file for no obvious reason. rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================

2 1

[U-Boot] [PATCH] spl: sunxi: Fix build error with CONFIG_SPL_SPI_SUNXI
by Priit Laes 04 Jan '17

04 Jan '17

Fix typo introduced in ebc4ef61d76fc182773fe225151adc9b913c62eb Signed-off-by: Priit Laes <plaes(a)plaes.org> --- drivers/mtd/spi/sunxi_spi_spl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/spi/sunxi_spi_spl.c b/drivers/mtd/spi/sunxi_spi_spl.c index e70064c..a24c115 100644 --- a/drivers/mtd/spi/sunxi_spi_spl.c +++ b/drivers/mtd/spi/sunxi_spi_spl.c @@ -284,4 +284,4 @@ static int spl_spi_load_image(struct spl_image_info *spl_image, return 0; } /* Use priorty 0 to override the default if it happens to be linked in */ -SPL_LOAD_IMAGE_METHOD("sunxi SPI" 0, BOOT_DEVICE_SPI, spl_spi_load_image); +SPL_LOAD_IMAGE_METHOD("sunxi SPI", 0, BOOT_DEVICE_SPI, spl_spi_load_image); -- 2.9.3

2 2

[U-Boot] are DM/SPL dependencies in drivers/core/Kconfig correct?
by Robert P. J. Day 03 Jan '17

03 Jan '17

quite prepared to be told i'm totally off-base here, but the DM/SPL dependencies in the drivers/core/Kconfig file seem a bit odd, but that might be just my misunderstanding of how DM and SPL work together. first quick observation -- based on the naming convention i read somewhere, it seems that the Kbuild variable "SPL_DM" should actually be "DM_SPL". i'm sure i remember reading that the naming standard for DM-related variables should be "CONFIG_DM_*" but that's not a big deal. onward ... using a wandboard configuration, and enabling SPL, then driver model *and* driver model for SPL, one sees (partial list only) the Kbuild entries: [*] Enable Driver Model [*] Enable Driver Model for SPL [*] Support numbered aliases in device tree [ ] Support numbered aliases in device tree in SPL [*] Support register maps [*] Support register maps in SPL [*] Support system controllers [*] Support system controllers in SPL [*] Support simple-bus driver [ ] Support simple-bus driver in SPL [*] Translate addresses using fdt_translate_address [ ] Translate addresses using fdt_translate_address in SPL where the list above represents pairs of settings, one non-SPL, one for SPL. so far, so good. but if one then deselects "Enable Driver Model for SPL", one is still left with some of those (ostensibly) SPL-related entries: [ ] Support numbered aliases in device tree in SPL [*] Support register maps in SPL [*] Support system controllers in SPL a quick look at the Kconfig file shows that some of those "for SPL" entries depend on SPL_DM, while the others depend only on DM. is that the way it's meant to be? i don't know enough about how the driver model relates to SPL, so it's entirely possible the above is entirely correct, it just looks a bit weird. in any event, that Kconfig file could still be refactored to avoid new entries popping up in arbitrary places depending on what you select or deselect. thoughts? rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================

1 0

[U-Boot] [PATCH v2 0/3] LS1046A secure boot target addition
by Sumit Garg 03 Jan '17

03 Jan '17

The patch-set does the following: 1. Add NOR secure boot target on ls1046aqds platform. 2. Add QSPI secure boot target on ls1046ardb platform. Changes in v2: Split patches logically from 2 to 3. Sumit Garg (3): SECURE_BOOT: Enable chain of trust on LS1046A platform LS1046AQDS: Add NOR Secure Boot Target LS1046ARDB: Add QSPI Secure Boot target arch/arm/include/asm/arch-fsl-layerscape/config.h | 2 +- arch/arm/include/asm/fsl_secure_boot.h | 37 ++++++++++++++++------- board/freescale/ls1046aqds/MAINTAINERS | 4 +++ board/freescale/ls1046aqds/ls1046aqds.c | 18 +++++++++++ board/freescale/ls1046ardb/MAINTAINERS | 4 +++ board/freescale/ls1046ardb/ls1046ardb.c | 19 ++++++++++++ configs/ls1046aqds_SECURE_BOOT_defconfig | 29 ++++++++++++++++++ configs/ls1046ardb_qspi_SECURE_BOOT_defconfig | 27 +++++++++++++++++ include/configs/ls1046ardb.h | 2 ++ 9 files changed, 130 insertions(+), 12 deletions(-) create mode 100644 configs/ls1046aqds_SECURE_BOOT_defconfig create mode 100644 configs/ls1046ardb_qspi_SECURE_BOOT_defconfig -- 1.8.1.4

4 9

[U-Boot] [PATCH] ARM: zynqmp: Make SYS_VENDOR configurable
by Mike Looijmans 03 Jan '17

03 Jan '17

Add a string description for SYS_VENDOR to allow configuring boards from other vendors than just "xilinx". --- arch/arm/cpu/armv8/zynqmp/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/cpu/armv8/zynqmp/Kconfig b/arch/arm/cpu/armv8/zynqmp/Kconfig index e175e6e..499e1dd 100644 --- a/arch/arm/cpu/armv8/zynqmp/Kconfig +++ b/arch/arm/cpu/armv8/zynqmp/Kconfig @@ -28,6 +28,7 @@ config SYS_BOARD default "zynqmp" config SYS_VENDOR + string "Vendor name" default "xilinx" config SYS_SOC -- 1.9.1

2 1

[U-Boot] [PATCH] example: api: ARM example needs memset
by Emmanuel Vadot 03 Jan '17

03 Jan '17

Add memset.S to the needed object for the API example and do not hardcode powerpc as the arch for library assembly files. Signed-off-by: Emmanuel Vadot <manu(a)bidouilliste.com> --- examples/api/Makefile | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/examples/api/Makefile b/examples/api/Makefile index 6cffee7465..a1bb6eff95 100644 --- a/examples/api/Makefile +++ b/examples/api/Makefile @@ -34,7 +34,10 @@ EXT_COBJ-y += lib/div64.o EXT_COBJ-y += lib/string.o EXT_COBJ-y += lib/time.o EXT_COBJ-y += lib/vsprintf.o +EXT_SOBJDIR-$(CONFIG_PPC) = arch/powerpc +EXT_SOBJDIR-$(CONFIG_ARM) = arch/arm EXT_SOBJ-$(CONFIG_PPC) += arch/powerpc/lib/ppcstring.o +EXT_SOBJ-$(CONFIG_ARM) += arch/arm/lib/memset.o # Create a list of object files to be compiled OBJS := $(OBJ-y) $(notdir $(EXT_COBJ-y) $(EXT_SOBJ-y)) @@ -60,5 +63,5 @@ $(addprefix $(obj)/,$(notdir $(EXT_COBJ-y))): $(obj)/%.o: lib/%.c FORCE $(call if_changed_rule,cc_o_c) # Rule to build architecture-specific library assembly files -$(addprefix $(obj)/,$(notdir $(EXT_SOBJ-y))): $(obj)/%.o: arch/powerpc/lib/%.S FORCE +$(addprefix $(obj)/,$(notdir $(EXT_SOBJ-y))): $(obj)/%.o: $(EXT_SOBJDIR-y)/lib/%.S FORCE $(call if_changed_dep,as_o_S) -- 2.11.0

2 2

[U-Boot] [PATCH v2 01/30] arm: socfpga: arria10: add additional i2c nodes for Arria10
by Chee Tien Fong 03 Jan '17

03 Jan '17

From: Dinh Nguyen <dinguyen(a)opensource.altera.com> Add remaining 3 I2C base addresses for the Arria10. Signed-off-by: Dinh Nguyen <dinguyen(a)opensource.altera.com> Reviewed-by: Stefan Roese <sr(a)denx.de> --- arch/arm/mach-socfpga/include/mach/base_addr_a10.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/mach-socfpga/include/mach/base_addr_a10.h b/arch/arm/mach-socfpga/include/mach/base_addr_a10.h index a7056d4..902c321 100644 --- a/arch/arm/mach-socfpga/include/mach/base_addr_a10.h +++ b/arch/arm/mach-socfpga/include/mach/base_addr_a10.h @@ -29,6 +29,9 @@ #define SOCFPGA_MPUL2_ADDRESS 0xfffff000 #define SOCFPGA_I2C0_ADDRESS 0xffc02200 #define SOCFPGA_I2C1_ADDRESS 0xffc02300 +#define SOCFPGA_I2C2_ADDRESS 0xffc02400 +#define SOCFPGA_I2C3_ADDRESS 0xffc02500 +#define SOCFPGA_I2C4_ADDRESS 0xffc02600 #define SOCFPGA_ECC_OCRAM_ADDRESS 0xff8c3000 #define SOCFPGA_UART0_ADDRESS 0xffc02000 -- 2.2.2

4 35

[U-Boot] [PATCH] mmc: uniphier-sd: fix Kconfig dependency
by Masahiro Yamada 03 Jan '17

03 Jan '17

Some MMC drivers describe operations with the DM_MMC_OPS form, but there are still several drivers with older implementation. We can not compile drivers from different groups at the same time because the core framework is shared with #ifdef CONFIG_DM_MMC_OPS. Every driver should have "depends on DM_MMC_OPS" (or !DM_MMC_OPS) explicitly to express which framework it is based on. This will avoid enabling drivers with incompatible interface at the same time. It is incorrect to make a driver "select DM_MMC_OPS". While we are here, add "depends on OF_CONTROL" as well because this driver can be configured only by Device Tree. Signed-off-by: Masahiro Yamada <yamada.masahiro(a)socionext.com> --- drivers/mmc/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig index ff4344f..75b6ba1 100644 --- a/drivers/mmc/Kconfig +++ b/drivers/mmc/Kconfig @@ -107,8 +107,8 @@ config ROCKCHIP_SDHCI config MMC_UNIPHIER bool "UniPhier SD/MMC Host Controller support" depends on ARCH_UNIPHIER - depends on BLK - select DM_MMC_OPS + depends on BLK && DM_MMC_OPS + depends on OF_CONTROL help This selects support for the SD/MMC Host Controller on UniPhier SoCs. -- 2.7.4

2 1