April 2019 - U-Boot

[U-Boot] [PATCH] board: toradex: drop support.arm maintainer email
by Marcel Ziswiler 23 Apr '19

23 Apr '19

From: Marcel Ziswiler <marcel.ziswiler(a)toradex.com> Drop Toradex ARM Support <support.arm(a)toradex.com> from maintainer email list as this just clogs our support ticketing system. Signed-off-by: Marcel Ziswiler <marcel.ziswiler(a)toradex.com> --- board/toradex/colibri-imx6ull/MAINTAINERS | 1 - board/toradex/colibri_imx7/MAINTAINERS | 1 - 2 files changed, 2 deletions(-) diff --git a/board/toradex/colibri-imx6ull/MAINTAINERS b/board/toradex/colibri-imx6ull/MAINTAINERS index 7cda555984..626c1f94f9 100644 --- a/board/toradex/colibri-imx6ull/MAINTAINERS +++ b/board/toradex/colibri-imx6ull/MAINTAINERS @@ -1,6 +1,5 @@ Colibri iMX6ULL M: Stefan Agner <stefan.agner(a)toradex.com> -M: Toradex ARM Support <support.arm(a)toradex.com> W: http://developer.toradex.com/software/linux/linux-software W: https://www.toradex.com/community S: Maintained diff --git a/board/toradex/colibri_imx7/MAINTAINERS b/board/toradex/colibri_imx7/MAINTAINERS index f55f8045f4..cd0f9c9b2d 100644 --- a/board/toradex/colibri_imx7/MAINTAINERS +++ b/board/toradex/colibri_imx7/MAINTAINERS @@ -1,6 +1,5 @@ Colibri iMX7 M: Stefan Agner <stefan.agner(a)toradex.com> -M: Toradex ARM Support <support.arm(a)toradex.com> W: http://developer.toradex.com/software/linux/linux-software W: https://www.toradex.com/community S: Maintained -- 2.20.1

1 0

[U-Boot] listing apparently "bad" Kconfig options in Makefiles
by Robert P. J. Day 23 Apr '19

23 Apr '19

as a final(?) example of one of my originally Linux kernel-related Kbuild cleanup scripts, i have one that identifies Makefile entries that refer to Kbuild options that are not defined in any Kconfig file (IIRC, they might be defined manually in a defconfig file, i'll have to refresh my memory, but tradition suggests that "CONFIG_"-prefixed variables are meant to be defined in Kconfig files). i ran this script on the entire u-boot code base, and posted the results here (not overly long): https://crashcourse.ca/dokuwiki/doku.php?id=u-boot_make_badref so let me elaborate with a couple examples. first, there's this output: >>>>> NATSEMI ./drivers/net/Makefile:obj-$(CONFIG_NATSEMI) += natsemi.o so what's the story with CONFIG_NATSEMI? first, it clearly is not defined in a Kconfig file anywhere: $ git grep "config NATSEMI" $ so where does it occur? $ git grep CONFIG_NATSEMI README: CONFIG_NATSEMI drivers/net/Makefile:obj-$(CONFIG_NATSEMI) += natsemi.o include/netdev.h:#ifdef CONFIG_NATSEMI scripts/config_whitelist.txt:CONFIG_NATSEMI $ pretty clearly(?), it's documented and tested and whitelisted, while never being defined anywhere. a wild guess suggests it really should say CONFIG_PHY_NATSEMI: $ git grep CONFIG_PHY_NATSEMI configs/brppt1_mmc_defconfig:CONFIG_PHY_NATSEMI=y configs/brppt1_nand_defconfig:CONFIG_PHY_NATSEMI=y configs/brppt1_spi_defconfig:CONFIG_PHY_NATSEMI=y configs/microblaze-generic_defconfig:CONFIG_PHY_NATSEMI=y configs/xilinx_versal_virt_defconfig:CONFIG_PHY_NATSEMI=y configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig:CONFIG_PHY_NATSEMI=y configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig:CONFIG_PHY_NATSEMI=y configs/xilinx_zynqmp_zc1751_xm017_dc3_defconfig:CONFIG_PHY_NATSEMI=y configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig:CONFIG_PHY_NATSEMI=y configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig:CONFIG_PHY_NATSEMI=y configs/xilinx_zynqmp_zcu102_rev1_0_defconfig:CONFIG_PHY_NATSEMI=y configs/xilinx_zynqmp_zcu102_revA_defconfig:CONFIG_PHY_NATSEMI=y configs/xilinx_zynqmp_zcu102_revB_defconfig:CONFIG_PHY_NATSEMI=y configs/xilinx_zynqmp_zcu104_revA_defconfig:CONFIG_PHY_NATSEMI=y configs/xilinx_zynqmp_zcu104_revC_defconfig:CONFIG_PHY_NATSEMI=y configs/xilinx_zynqmp_zcu106_revA_defconfig:CONFIG_PHY_NATSEMI=y configs/xilinx_zynqmp_zcu111_revA_defconfig:CONFIG_PHY_NATSEMI=y drivers/net/phy/Makefile:obj-$(CONFIG_PHY_NATSEMI) += natsemi.o drivers/net/phy/phy.c:#ifdef CONFIG_PHY_NATSEMI include/config_phylib_all_drivers.h:#define CONFIG_PHY_NATSEMI include/configs/pengwyn.h:#define CONFIG_PHY_NATSEMI include/configs/rut.h:#define CONFIG_PHY_NATSEMI include/configs/spear6xx_evb.h:#define CONFIG_PHY_NATSEMI $ as established back in 2015: commit f96fe2c0a8a72d675532d79df49cbfe3464154a5 Author: Michal Simek <michal.simek(a)xilinx.com> Date: Wed Sep 23 19:35:31 2015 +0200 ARM64: zynqmp: Enable NATSEMI phys Signed-off-by: Michal Simek <michal.simek(a)xilinx.com> diff --git a/include/configs/xilinx_zynqmp.h b/include/configs/xilinx_zynqmp.h index 5008722bf4..eae1a4988b 100644 --- a/include/configs/xilinx_zynqmp.h +++ b/include/configs/xilinx_zynqmp.h @@ -193,6 +193,7 @@ # define CONFIG_MII # define CONFIG_SYS_FAULT_ECHO_LINK_DOWN # define CONFIG_PHY_MARVELL +# define CONFIG_PHY_NATSEMI # define CONFIG_PHY_TI #endif and as a second (far more trivial) example, there's this: >>>>> RTC_DAVINCI ./drivers/rtc/Makefile:obj-$(CONFIG_RTC_DAVINCI) += davinci.o where does that string occur? apparently, in only one place so it clearly is utterly worthless as it is currently spelled: $ git grep RTC_DAVINCI drivers/rtc/Makefile:obj-$(CONFIG_RTC_DAVINCI) += davinci.o $ anyway, people are free to peruse that page to see if anything jumps out at them. i'll spend a few minutes today wiki'ing all of the scripts so people can run them on whatever part of the code base amuses them. thanks for your patience. 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] Zynq: delete long-dead CONFIG_USB_CABLE_CHECK
by Robert P. J. Day 23 Apr '19

23 Apr '19

This Kbuild option disappeared way back in 2014: commit 75504e9592745021006cb8905b5ff5a51d9d1cb3 Author: Mateusz Zalega <m.zalega(a)samsung.com> Date: Wed Apr 30 13:07:48 2014 +0200 ... snip ... CONFIG_USB_CABLE_CHECK was removed. Signed-off-by: Robert P. J. Day <rpjday(a)crashcourse.ca> --- diff --git a/include/configs/xilinx_zynqmp.h b/include/configs/xilinx_zynqmp.h index 27a8e4d490..c9b56fb9cf 100644 --- a/include/configs/xilinx_zynqmp.h +++ b/include/configs/xilinx_zynqmp.h @@ -66,7 +66,6 @@ #if defined(CONFIG_ZYNQMP_USB) #define CONFIG_SYS_DFU_DATA_BUF_SIZE 0x1800000 #define DFU_DEFAULT_POLL_TIMEOUT 300 -#define CONFIG_USB_CABLE_CHECK #define CONFIG_THOR_RESET_OFF #define DFU_ALT_INFO_RAM \ "dfu_ram_info=" \ diff --git a/include/configs/zynq-common.h b/include/configs/zynq-common.h index 94177c6fcb..2f5126c38d 100644 --- a/include/configs/zynq-common.h +++ b/include/configs/zynq-common.h @@ -65,7 +65,6 @@ # define CONFIG_SYS_DFU_DATA_BUF_SIZE 0x600000 # define DFU_DEFAULT_POLL_TIMEOUT 300 -# define CONFIG_USB_CABLE_CHECK # define CONFIG_THOR_RESET_OFF # define DFU_ALT_INFO_RAM \ "dfu_ram_info=" \ diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt index 31c1ba3477..fdf3cd1cfd 100644 --- a/scripts/config_whitelist.txt +++ b/scripts/config_whitelist.txt @@ -4497,7 +4497,6 @@ CONFIG_USB_ATMEL_CLK_SEL_PLLB CONFIG_USB_ATMEL_CLK_SEL_UPLL CONFIG_USB_BIN_FIXUP CONFIG_USB_BOOTING -CONFIG_USB_CABLE_CHECK CONFIG_USB_DEVICE CONFIG_USB_DEV_BASE CONFIG_USB_DEV_PULLUP_GPIO -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================

2 1

Re: [U-Boot] [PATCH v2 00/10] clk: imx: Add i.MX6 CLK support
by Peng Fan 23 Apr '19

23 Apr '19

> On Fri, 19 Apr 2019 11:56:25 +0530 > Jagan Teki <jagan(a)amarulasolutions.com> wrote: > > > On Fri, Apr 5, 2019 at 2:20 AM Lukasz Majewski <lukma(a)denx.de> wrote: > > > > > > Hi Jagan, > > > > > > > On Thu, Apr 4, 2019 at 3:31 PM Lukasz Majewski <lukma(a)denx.de> > > > > wrote: > > > > > > > > > > On Thu, 4 Apr 2019 14:56:36 +0530 Jagan Teki > > > > > <jagan(a)amarulasolutions.com> wrote: > > > > > > > > > > > On Thu, Apr 4, 2019 at 2:31 PM Lukasz Majewski <lukma(a)denx.de> > > > > > > wrote: > > > > > > > > > > > > > > On Tue, 2 Apr 2019 16:58:33 +0530 Jagan Teki > > > > > > > <jagan(a)amarulasolutions.com> wrote: > > > > > > > > > > > > > > > This is revised version of previous i.MX6 clock management > > > > > > > > [1]. > > > > > > > > > > > > > > > > The main difference between previous version is > > > > > > > > - Group the i.MX6 ccm clocks into gates and tree instead > > > > > > > > of handling the clocks in simple way using case statement. > > > > > > > > - use gate clocks for enable/disable management. > > > > > > > > - use tree clocks for get/set rate or parent traverse > > > > > > > > management. > > > > > > > > - parent clock handling via clock type. > > > > > > > > - traverse the parent clock using recursive functionlaity. > > > > > > > > > > > > > > > > The main motive behind this tree framework is to make the > > > > > > > > clock tree management simple and useful for U-Boot > > > > > > > > requirements instead of garbing Linux clock management > > > > > > > > code. > > > > > > > > > > > > > > > > We are trying to manage the Allwinner clocks with similar > > > > > > > > kind, so having this would really help i.MX6 as well. > > > > > > > > > > > > > > > > Added simple names for clock macros, but will update it in > > > > > > > > future version. > > > > > > > > > > > > > > > > I have skipped ENET clocks from previous series, will add > > > > > > > > it in future patches. > > > > > > > > > > > > > > > > Changes for v2: > > > > > > > > - changed framework patches. > > > > > > > > - add support for imx6qdl and imx6ul boards > > > > > > > > - add clock gates, tree. > > > > > > > > > > > > > > > > [1] https://patchwork.ozlabs.org/cover/950964/ > > > > > > > > > > > > > > > > Any inputs? > > > > > > > > > > > > > > Hmm.... It looks like we are doing some development in > > > > > > > parallel. > > > > > > > > > > > > > > Please look into following commit [1]: > > > > > > > https://patchwork.ozlabs.org/patch/1034051/ > > > > > > > > > > > > > > It ports from Linux 5.0 the CCF framework for iMX6Q, which > > > > > > > IMHO in the long term is a better approach. > > > > > > > The code is kept simple and resembles the code from Barebox. > > > > > > > > > > > > > > Please correct me if I'm wrong, but the code from your work > > > > > > > is not modeling muxes, gates and other components from Linux > > > > > > > CCF. > > > > > > > > > > > > The U-Boot implementation of CLK would require as minimal and > > > > > > simple as possible due to requirement of U-Boot itself. Hope > > > > > > you agree this point? > > > > > > > > > > Now i.MX6 is using clock.c CLK implementation. If we decide to > > > > > replace it - we shall do it in a way, which would allow us to > > > > > follow Linux kernel. (the barebox implementation is a stripped > > > > > CCF from Linux, the same is in patch [1]). > > > > > > > > > > > if yes having CCF stack code to handle all clock with > > > > > > respective separate drivers management is may not require as > > > > > > of now, IMHO. > > > > > > > > > > I do have a gut feeling, that we will end up with the need to > > > > > have the CCF framework ported anyway. As for example imx7/8 can > > > > > re-use muxes, gates code. > > > > > > > > As per my experience the main the over-ahead to handle clocks in > > > > U-Boot if we go with separate clock drivers is for Video and > > > > Ethernet peripherals. these are key IP's which use more clocks > > > > from U-Boot point-of-view, others can be handle pretty > > > > straight-forward unless if they don't have too much tree chain. > > > > > > > > On this series, the tree management is already supported ENET in > > > > i.MX6, and Allwinner platforms. > > > > > > > > As of now, I'm thinking I can handle reset of the clocks with > > > > similar way. > > > > > > But this code also supports ENET and ESDHCI clocks on i.MX6Q (as > > > supporting those was the motivator for this work). > > > > > > One important thing to be aware of - the problem with SPL's > > > footprint. The implementation with clock.c is small and simple, but > > > doesn't scale well. > > > > > > > > > > > > > > > > > However, those are only my "feelings" after a glimpse look - I > > > > > will look into your code more thoroughly and provide feedback. > > > > > > > > Please have a look, if possible check even the code size by adding > > > > USDHC clocks. > > > > > > Yes, code size (especially in SPL) is an _important_ factor here. > > > > > > > > > > > > > > > > > > > > > > > > This series is using recursive calls for handling parenting > > > > > > stuff to handle get or set rates, which is fine for handling > > > > > > clock tree management as far as U-Boot point-of-view. We have > > > > > > faced similar situation as I explained in commit message about > > > > > > Allwinner clocks [2] and we ended up going this way. > > > > > > > > > > I'm not Allwinner expert - but if I may ask - how far away is > > > > > this implementation from mainline Linux kernel? > > > > > > > > > > How difficult is it to port the new code (or update it)? > > > > > > > > Allwinner clocks also has similar gates, muxs, and with other > > > > platform stuff which has too much scope in Linux to use CCM. > > > > > > For example the barebox managed to get subset of Linux CCF ported, > > > without loosing the CCF similarity. > > > > > > > > > Important factors/requirements for the i.MX clock code: > > > > > > 1. Easy maintenance in long-term > > > > > > 2. Reusing the code in SPL (with a very important factor of > > > _code_size_). > > > > > > 3. Reuse the code for other i.MX SoCs (imx7, imx8) > > > > > > 4. Effort needed to use DM with this code > > > > I understand your points, I was managed this series based on these > > requirements as well. > > Ok. > > Could you share the delta of footprint size (u-boot.img/SPL) with and without > your patch (on imx6q) ? > > In my case the CCF caused increase of u-boot.img proper (as it was not yet > adapted to SPL): > > 415KiB -> 421KiB = 6KiB increase of size (< 2%). > > (This can be further reduced by using OF_PLATDATA). > > This CCF code hasn't been ported to SPL (yet) > > > We even consider the foot-print, atleast for recursive calls of > > handling parenting scale well. > > With CCF porting v3 I'm going to provide some caching, so the descending > would be done at most once. > > > May be we can > > consider to design based on this as per U-Boot. > > > > Please look into point 1. Having code ported from Linux is IMHO better in the > long term. Agree. > > > Let me come-back with another series or do you have any inputs or > > questions, please post it. > > I will post CCF port for imx6q v3 in a few days. Looking forward your new patchset. Working on enabling i.MX8MM CCF support. Regards, Peng. > > > > > Jagan. > > > > > Best regards, > > Lukasz Majewski > > -- > > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: > lukma(a)denx.de

3 6

[U-Boot] "optee" Kbuild seems to have weird dependencies
by Robert P. J. Day 23 Apr '19

23 Apr '19

going over the u-boot.cfg generated from zynq_zed_defconfig, and noticed the following: #define CONFIG_OPTEE_TZDRAM_BASE 0x00000000 #define CONFIG_OPTEE_TZDRAM_SIZE 0x0000000 i thought that was strange as CONFIG_OPTEE was not selected, so i checked, and here's the relevant snippet from lib/optee/Kconfig: config OPTEE bool "Support OPTEE images" help U-Boot can be configured to boot OPTEE images. Selecting this option will enable shared OPTEE library code and enable an OPTEE specific bootm command that will perform additional OPTEE specific checks before booting an OPTEE image created with mkimage. config OPTEE_TZDRAM_SIZE hex "Amount of Trust-Zone RAM for the OPTEE image" default 0x0000000 help The size of pre-allocated Trust Zone DRAM to allocate for the OPTEE runtime. config OPTEE_TZDRAM_BASE hex "Base address of Trust-Zone RAM for the OPTEE image" default 0x00000000 help The base address of pre-allocated Trust Zone DRAM for the OPTEE runtime. those two Kbuild directives are (strangely?) not dependent on OPTEE, which is why they show up in u-boot.cfg. is this deliberate? i know nothing about TEE, but it seems odd that OPTEE-related settings don't depend on OPTEE. am i misreading something? rday p.s. the MAINTAINERS entry for TEE seems incomplete as well: TEE M: Jens Wiklander <jens.wiklander(a)linaro.org> S: Maintained F: drivers/tee/ F: include/tee.h F: include/tee/ one suspects that should include, at the very least: * lib/optee * include/config/optee

3 2

[U-Boot] [PATCH v2] regmap: fix regmap_read_poll_timeout warning about sandbox_timer_add_offset
by Neil Armstrong 23 Apr '19

23 Apr '19

When fixing sandbox test for regmap_read_poll_timeout(), the sandbox_timer_add_offset was introduced but only defined in sandbox code thus generating warnings when used out of sandbox : include/regmap.h:289:2: note: in expansion of macro 'regmap_read_poll_timeout_test' regmap_read_poll_timeout_test(map, addr, val, cond, sleep_us, \ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/spi/meson_spifc.c:169:8: note: in expansion of macro 'regmap_read_poll_timeout' ret = regmap_read_poll_timeout(spifc->regmap, REG_SLAVE, data, ^~~~~~~~~~~~~~~~~~~~~~~~ drivers/spi/meson_spifc.c: In function 'meson_spifc_txrx': include/regmap.h:277:4: warning: implicit declaration of function 'sandbox_timer_add_offset' [-Wimplicit-function-declaration] This fix renames the sandbox_timer_add_offset() to a generic timer_test_add_offset() function defined in time.h and renames the implementation and test usages. Cc: Simon Glass <sjg(a)chromium.org> Reported-by: Tom Rini <trini(a)konsulko.com> Fixes: df9cf1cc08 ("test: dm: regmap: Fix the long test delay") Signed-off-by: Neil Armstrong <narmstrong(a)baylibre.com> --- arch/sandbox/include/asm/test.h | 8 -------- board/sandbox/sandbox.c | 2 +- drivers/net/sandbox.c | 2 +- drivers/timer/sandbox_timer.c | 2 +- include/regmap.h | 2 +- include/time.h | 8 ++++++++ 6 files changed, 12 insertions(+), 12 deletions(-) diff --git a/arch/sandbox/include/asm/test.h b/arch/sandbox/include/asm/test.h index fc52f47f82..e956a05262 100644 --- a/arch/sandbox/include/asm/test.h +++ b/arch/sandbox/include/asm/test.h @@ -59,14 +59,6 @@ void sandbox_i2c_eeprom_set_test_mode(struct udevice *dev, void sandbox_i2c_eeprom_set_offset_len(struct udevice *dev, int offset_len); -/* - * sandbox_timer_add_offset() - * - * Allow tests to add to the time reported through lib/time.c functions - * offset: number of milliseconds to advance the system time - */ -void sandbox_timer_add_offset(unsigned long offset); - /** * sandbox_i2c_rtc_set_offset() - set the time offset from system/base time * diff --git a/board/sandbox/sandbox.c b/board/sandbox/sandbox.c index 397e7561d4..9ca1eca027 100644 --- a/board/sandbox/sandbox.c +++ b/board/sandbox/sandbox.c @@ -31,7 +31,7 @@ void flush_cache(unsigned long start, unsigned long size) /* system timer offset in ms */ static unsigned long sandbox_timer_offset; -void sandbox_timer_add_offset(unsigned long offset) +void timer_test_add_offset(unsigned long offset) { sandbox_timer_offset += offset; } diff --git a/drivers/net/sandbox.c b/drivers/net/sandbox.c index decce2fa59..c136392350 100644 --- a/drivers/net/sandbox.c +++ b/drivers/net/sandbox.c @@ -350,7 +350,7 @@ static int sb_eth_recv(struct udevice *dev, int flags, uchar **packetp) struct eth_sandbox_priv *priv = dev_get_priv(dev); if (skip_timeout) { - sandbox_timer_add_offset(11000UL); + timer_test_add_offset(11000UL); skip_timeout = false; } diff --git a/drivers/timer/sandbox_timer.c b/drivers/timer/sandbox_timer.c index 6d2b045fe8..5228486082 100644 --- a/drivers/timer/sandbox_timer.c +++ b/drivers/timer/sandbox_timer.c @@ -14,7 +14,7 @@ /* system timer offset in ms */ static unsigned long sandbox_timer_offset; -void sandbox_timer_add_offset(unsigned long offset) +void timer_test_add_offset(unsigned long offset) { sandbox_timer_offset += offset; } diff --git a/include/regmap.h b/include/regmap.h index 8359c511d2..3cd7a66cea 100644 --- a/include/regmap.h +++ b/include/regmap.h @@ -274,7 +274,7 @@ int regmap_raw_read_range(struct regmap *map, uint range_num, uint offset, if (cond) \ break; \ if (IS_ENABLED(CONFIG_SANDBOX) && test_add_time) \ - sandbox_timer_add_offset(test_add_time); \ + timer_test_add_offset(test_add_time); \ if ((timeout_ms) && get_timer(__start) > (timeout_ms)) { \ __ret = regmap_read((map), (addr), &(val)); \ break; \ diff --git a/include/time.h b/include/time.h index 825991e222..9fd0d73fb4 100644 --- a/include/time.h +++ b/include/time.h @@ -13,6 +13,14 @@ unsigned long get_timer(unsigned long base); */ unsigned long timer_get_us(void); +/* + * timer_test_add_offset() + * + * Allow tests to add to the time reported through lib/time.c functions + * offset: number of milliseconds to advance the system time + */ +void timer_test_add_offset(unsigned long offset); + /* * These inlines deal with timer wrapping correctly. You are * strongly encouraged to use them -- 2.21.0

2 2

[U-Boot] [PATCH] board: amlogic: enable PHY_REALTEK for selected boards
by Neil Armstrong 23 Apr '19

23 Apr '19

When using the generic PHY on boards using an RGMII Realtek PHY, gigabit speed is not always reliable. This patch enables the Realtek PHY driver for such boards. Signed-off-by: Neil Armstrong <narmstrong(a)baylibre.com> --- configs/khadas-vim2_defconfig | 1 + configs/nanopi-k2_defconfig | 1 + configs/odroid-c2_defconfig | 1 + configs/s400_defconfig | 1 + 4 files changed, 4 insertions(+) diff --git a/configs/khadas-vim2_defconfig b/configs/khadas-vim2_defconfig index 080dd19590..f7fb9338e2 100644 --- a/configs/khadas-vim2_defconfig +++ b/configs/khadas-vim2_defconfig @@ -31,6 +31,7 @@ CONFIG_MMC_MESON_GX=y CONFIG_MTD=y CONFIG_DM_ETH=y CONFIG_ETH_DESIGNWARE=y +CONFIG_PHY_REALTEK=y CONFIG_PHY=y CONFIG_MESON_GXL_USB_PHY=y CONFIG_PINCTRL=y diff --git a/configs/nanopi-k2_defconfig b/configs/nanopi-k2_defconfig index 8bbf48f41f..106c5c0193 100644 --- a/configs/nanopi-k2_defconfig +++ b/configs/nanopi-k2_defconfig @@ -28,6 +28,7 @@ CONFIG_DM_MMC=y CONFIG_MMC_MESON_GX=y CONFIG_DM_ETH=y CONFIG_ETH_DESIGNWARE=y +CONFIG_PHY_REALTEK=y CONFIG_PINCTRL=y CONFIG_PINCTRL_MESON_GXBB=y CONFIG_DM_REGULATOR=y diff --git a/configs/odroid-c2_defconfig b/configs/odroid-c2_defconfig index 747da184b3..91baddbb60 100644 --- a/configs/odroid-c2_defconfig +++ b/configs/odroid-c2_defconfig @@ -29,6 +29,7 @@ CONFIG_DM_MMC=y CONFIG_MMC_MESON_GX=y CONFIG_DM_ETH=y CONFIG_ETH_DESIGNWARE=y +CONFIG_PHY_REALTEK=y CONFIG_PINCTRL=y CONFIG_PINCTRL_MESON_GXBB=y CONFIG_DM_REGULATOR=y diff --git a/configs/s400_defconfig b/configs/s400_defconfig index 1bd4b7127b..9b8448e003 100644 --- a/configs/s400_defconfig +++ b/configs/s400_defconfig @@ -26,6 +26,7 @@ CONFIG_DM_MMC=y CONFIG_MMC_MESON_GX=y CONFIG_DM_ETH=y CONFIG_ETH_DESIGNWARE=y +CONFIG_PHY_REALTEK=y CONFIG_PINCTRL=y CONFIG_PINCTRL_MESON_AXG=y CONFIG_DM_REGULATOR=y -- 2.21.0

1 1

[U-Boot] [PATCH] board: amlogic-q200: fix Khadas VIM2 README
by Neil Armstrong 23 Apr '19

23 Apr '19

The vendor U-boot branch and defconfig was wrong for the Khadas VIM2, fix this. Signed-off-by: Neil Armstrong <narmstrong(a)baylibre.com> --- board/amlogic/q200/README.khadas-vim2 | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/board/amlogic/q200/README.khadas-vim2 b/board/amlogic/q200/README.khadas-vim2 index 578693fd2d..8bcfc296f3 100644 --- a/board/amlogic/q200/README.khadas-vim2 +++ b/board/amlogic/q200/README.khadas-vim2 @@ -48,9 +48,9 @@ the git tree published by the board vendor: > tar xvfJ gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz > tar xvfJ gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz > export PATH=$PWD/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux/bin:$PWD/gcc-linaro-arm-none-eabi-4.8-2013.11_linux/bin:$PATH - > git clone https://github.com/khadas/u-boot -b Vim vim-u-boot + > git clone https://github.com/khadas/u-boot -b khadas-vim-v2015.01 vim-u-boot > cd vim-u-boot - > make kvim_defconfig + > make kvim2_defconfig > make > export FIPDIR=$PWD/fip -- 2.21.0

1 1

[U-Boot] [PATCH v2 0/6] ARM: meson: Add support for G12A based U200 board
by Neil Armstrong 23 Apr '19

23 Apr '19

This patchset adds basic support for the recent Amlogic G12A SoC family. This SoC family embeds 4xCortex A53 CPUs, and is very similar to the AXG SoC Family with the multimedia features of previous families. This patchset adds : - pinctrl support - clk driver atfer a rework of the drivers files - import Linux 5.1-rc1 G12A & U200 DT files - add board/amlogic/u200 to support the U200 reference design Changes since v1: - add fixup for pinctrl like for AXG Jerome Brunet (5): pinctrl: meson: add g12a support clk: create meson directory and move related drivers clk: meson: add g12a support ARM: meson: add G12a support boards: meson: add g12a u200 Neil Armstrong (1): ARM: dts: Import Amlogic G12A u200 DT from Linux 5.1-rc1 MAINTAINERS | 2 +- arch/arm/dts/Makefile | 3 +- arch/arm/dts/meson-g12a-u200.dts | 29 + arch/arm/dts/meson-g12a.dtsi | 192 +++ arch/arm/include/asm/arch-meson/clock-g12a.h | 104 ++ arch/arm/include/asm/arch-meson/g12a.h | 66 + arch/arm/mach-meson/Kconfig | 9 +- arch/arm/mach-meson/Makefile | 1 + arch/arm/mach-meson/board-g12a.c | 150 ++ board/amlogic/u200/MAINTAINERS | 5 + board/amlogic/u200/Makefile | 6 + board/amlogic/u200/README | 128 ++ board/amlogic/u200/u200.c | 22 + configs/u200_defconfig | 40 + drivers/clk/Kconfig | 1 + drivers/clk/Makefile | 2 +- drivers/clk/meson/Kconfig | 23 + drivers/clk/meson/Makefile | 9 + drivers/clk/{clk_meson_axg.c => meson/axg.c} | 0 drivers/clk/{ => meson}/clk_meson.h | 0 drivers/clk/meson/g12a.c | 315 ++++ drivers/clk/{clk_meson.c => meson/gxbb.c} | 0 drivers/pinctrl/meson/Kconfig | 4 + drivers/pinctrl/meson/Makefile | 1 + drivers/pinctrl/meson/pinctrl-meson-g12a.c | 1294 +++++++++++++++++ drivers/pinctrl/meson/pinctrl-meson.c | 17 +- drivers/pinctrl/meson/pinctrl-meson.h | 1 + include/dt-bindings/clock/g12a-aoclkc.h | 34 + include/dt-bindings/clock/g12a-clkc.h | 135 ++ include/dt-bindings/gpio/meson-g12a-gpio.h | 114 ++ .../reset/amlogic,meson-g12a-reset.h | 134 ++ include/dt-bindings/reset/g12a-aoclkc.h | 18 + 32 files changed, 2850 insertions(+), 9 deletions(-) create mode 100644 arch/arm/dts/meson-g12a-u200.dts create mode 100644 arch/arm/dts/meson-g12a.dtsi create mode 100644 arch/arm/include/asm/arch-meson/clock-g12a.h create mode 100644 arch/arm/include/asm/arch-meson/g12a.h create mode 100644 arch/arm/mach-meson/board-g12a.c create mode 100644 board/amlogic/u200/MAINTAINERS create mode 100644 board/amlogic/u200/Makefile create mode 100644 board/amlogic/u200/README create mode 100644 board/amlogic/u200/u200.c create mode 100644 configs/u200_defconfig create mode 100644 drivers/clk/meson/Kconfig create mode 100644 drivers/clk/meson/Makefile rename drivers/clk/{clk_meson_axg.c => meson/axg.c} (100%) rename drivers/clk/{ => meson}/clk_meson.h (100%) create mode 100644 drivers/clk/meson/g12a.c rename drivers/clk/{clk_meson.c => meson/gxbb.c} (100%) create mode 100644 drivers/pinctrl/meson/pinctrl-meson-g12a.c create mode 100644 include/dt-bindings/clock/g12a-aoclkc.h create mode 100644 include/dt-bindings/clock/g12a-clkc.h create mode 100644 include/dt-bindings/gpio/meson-g12a-gpio.h create mode 100644 include/dt-bindings/reset/amlogic,meson-g12a-reset.h create mode 100644 include/dt-bindings/reset/g12a-aoclkc.h -- 2.21.0

1 7

[U-Boot] [ANN] U-Boot v2019.04 released
by Tom Rini 23 Apr '19

23 Apr '19

Hey all, So it is release day and despite a few last minute regression fixes, I think I'm overall comfortable doing the release today. Our next release is v2019.07 so we once again have time to stabilize things prior to release and not feel rushed. With this release, we've hit the deadline for DM_MMC conversion (setting aside SPL/TPL) and SPI (but not SPI_FLASH). What does that mean in practice? Well, in some cases we won't be deleting the compatible code yet as other block devices have their deadline being v2019.07 and you cannot mix-and-match DM and not DM block. That was even a last minute regression fix this time. So on those platforms I am confident that people will be finishing related conversions ASAP. And then, if we don't need the code for SPL/TPL, it can go away. In other cases, where things aren't migrated at all, soon some patches will get posted that will require enabling BROKEN to select non-migrated code paths. This isn't happening right away as I know people are working on finishing things up for migration, and again, that whole other block devices thing too. I'm mentioning this here as v2019.07 has deadlines for the rest of the block drivers as well as video and PCI and SPI flash, and I want expectations to be set. So with that, the merge window is open and we're looking at doing the v2019.07 release on July 8th, 2019. Thanks all! -- Tom

3 2