[U-Boot] [PATCH v3] timer: Add High Precision Event Timers (HPET) support
Add HPET driver as an alternative timer for x86 (default is TSC). HPET counter has constant frequency and does not need calibration. This change also makes TSC timer driver optional on x86. New HPET driver can also be selected as the early timer on x86. HPET can be selected as the tick timer in the Device Tree "chosen" node: /include/ "hpet.dtsi" ... chosen { tick-timer = "/hpet"; }; Signed-off-by: Ivan Gorinov--- arch/Kconfig | 2 +- arch/x86/Kconfig | 21 + arch/x86/dts/hpet.dtsi | 7 ++ drivers/timer/Kconfig | 9 +++ drivers/timer/Makefile | 1 + drivers/timer/hpet_timer.c | 190 + drivers/timer/tsc_timer.c | 8 ++ 7 files changed, 237 insertions(+), 1 deletion(-) create mode 100644 arch/x86/dts/hpet.dtsi create mode 100644 drivers/timer/hpet_timer.c diff --git a/arch/Kconfig b/arch/Kconfig index e599e7a..37dabae 100644 --- a/arch/Kconfig +++ b/arch/Kconfig @@ -104,7 +104,7 @@ config X86 select DM_PCI select PCI select TIMER - select X86_TSC_TIMER + imply X86_TSC_TIMER imply BLK imply DM_ETH imply DM_GPIO diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 5c23b2c..bd1a644 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -119,6 +119,27 @@ source "arch/x86/cpu/tangier/Kconfig" # architecture-specific options below +choice + prompt "Select which timer to use early on x86" + depends on X86 + default X86_EARLY_TIMER_TSC + +config X86_EARLY_TIMER_TSC + bool "TSC" + depends on X86_TSC_TIMER + help + This selects x86 Time Stamp Counter (TSC) as the early timer. + See CONFIG_TIMER_EARLY for the early timer description. + +config X86_EARLY_TIMER_HPET + bool "HPET" + depends on HPET_TIMER + help + This selects High Precision Event Timers as the early timer. + Early HPET base address is specified by CONFIG_HPET_ADDRESS. + +endchoice + config AHCI default y diff --git a/arch/x86/dts/hpet.dtsi b/arch/x86/dts/hpet.dtsi new file mode 100644 index 000..a74f739 --- /dev/null +++ b/arch/x86/dts/hpet.dtsi @@ -0,0 +1,7 @@ +/ { + hpet: hpet@fed0 { + compatible = "hpet-x86"; + u-boot,dm-pre-reloc; + reg = <0xfed0 0x1000>; + }; +}; diff --git a/drivers/timer/Kconfig b/drivers/timer/Kconfig index 2c96896..26743b7 100644 --- a/drivers/timer/Kconfig +++ b/drivers/timer/Kconfig @@ -65,6 +65,15 @@ config X86_TSC_TIMER help Select this to enable Time-Stamp Counter (TSC) timer for x86. +config HPET_TIMER + bool "High Precision Event Timers (HPET) support" + depends on TIMER + default y if X86 + help + Select this to enable High Precision Event Timers (HPET) on x86. + HPET main counter increments at constant rate and does not need + calibration. + config OMAP_TIMER bool "Omap timer support" depends on TIMER diff --git a/drivers/timer/Makefile b/drivers/timer/Makefile index a6e7832..557fecc 100644 --- a/drivers/timer/Makefile +++ b/drivers/timer/Makefile @@ -8,6 +8,7 @@ obj-y += timer-uclass.o obj-$(CONFIG_ALTERA_TIMER) += altera_timer.o obj-$(CONFIG_SANDBOX_TIMER)+= sandbox_timer.o obj-$(CONFIG_X86_TSC_TIMER)+= tsc_timer.o +obj-$(CONFIG_HPET_TIMER) += hpet_timer.o obj-$(CONFIG_OMAP_TIMER) += omap-timer.o obj-$(CONFIG_AST_TIMER)+= ast_timer.o obj-$(CONFIG_STI_TIMER)+= sti-timer.o diff --git a/drivers/timer/hpet_timer.c b/drivers/timer/hpet_timer.c new file mode 100644 index 000..7287589 --- /dev/null +++ b/drivers/timer/hpet_timer.c @@ -0,0 +1,190 @@ +/* + * Copyright (c) 2017 Intel Corporation + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#include +#include +#include +#include +#include +#include +#include + +#define HPET_PERIOD_REG 0x004 +#define HPET_CONFIG_REG 0x010 +#define HPET_MAIN_COUNT_L 0x0f0 +#define HPET_MAIN_COUNT_H 0x0f4 + +#define ENABLE_CNF 1 + +#define HPET_MAX_PERIOD 1 + +struct hpet_timer_priv { + void *regs; +}; + +/* + * Returns HPET clock frequency in HZ + * (rounding to the nearest integer), + * or 0 if HPET is not available. + */ +static inline u32 get_clock_frequency(void *regs) +{ + u64 d = 1000ull; + u32 period; + + period = readl(regs + HPET_PERIOD_REG); + if (period == 0) + return 0; + if (period > HPET_MAX_PERIOD) + return 0; + + d += period / 2; + + return d / period; +} + +/* Reset and start the main counter. */ +static void start_main_counter(void *regs) +{ + u32 config; + + config = readl(regs + HPET_CONFIG_REG); + config &= ~ENABLE_CNF; + writel(config, regs + HPET_CONFIG_REG); + writel(0, regs + HPET_MAIN_COUNT_L); + writel(0, regs
[U-Boot] [PATCH v3] timer: Add High Precision Event Timers (HPET) support
Add HPET driver as an alternative timer for x86 (default is TSC). HPET counter has constant frequency and does not need calibration. This change also makes TSC timer driver optional on x86. New HPET driver can also be selected as the early timer on x86. v3: Added early timer choice in x86-specific configuration. v2: Moved duplicated code to static functions. Ivan Gorinov (1): timer: Add High Precision Event Timers (HPET) support arch/Kconfig | 2 +- arch/x86/Kconfig | 21 + arch/x86/dts/hpet.dtsi | 7 ++ drivers/timer/Kconfig | 9 +++ drivers/timer/Makefile | 1 + drivers/timer/hpet_timer.c | 190 + drivers/timer/tsc_timer.c | 8 ++ 7 files changed, 237 insertions(+), 1 deletion(-) create mode 100644 arch/x86/dts/hpet.dtsi create mode 100644 drivers/timer/hpet_timer.c -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] timer: add High Precision Event Timers (HPET) support
On Fri, Mar 30, 2018 at 10:46:40PM +0300, Andy Shevchenko wrote: > > + writel(0, regs + HPET_MAIN_COUNT_L); > > + writel(0, regs + HPET_MAIN_COUNT_H); > > Can we use writeq() here? I don't see readq/writeq defined for x86, even x86_64. > > + tl = readl(regs + HPET_MAIN_COUNT_L); > > + th = readl(regs + HPET_MAIN_COUNT_H); > > Ditto. If readq() is defined as two read operations in 32-bit code, main counter rollover (low part overflow, high part increment) can happen between them. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] timer: Add High Precision Event Timers (HPET) support
On Fri, Mar 30, 2018 at 10:42:57PM +0300, Andy Shevchenko wrote: > On Fri, Mar 30, 2018 at 1:39 AM, Simon Glasswrote: > > On 29 March 2018 at 18:52, Andy Shevchenko > > wrote: > > >> First question is how this will work in case of Broadwell and Ivybridge > >> that have something to do with HPET in their CPU code, i.e. > >> > >> arch/x86/cpu/broadwell/pch.c > >> arch/x86/cpu/ivybridge/lpc.c > >> > >> ? > >> > >> Look for > >> > >> clrsetbits_le32(RCB_REG(HPTC), 3, 1 << 7); > > > > Perhaps that code can be removed in favour of this driver? I am happy > > to test on these platforms if it helps. > > That's my point. > This code performs platform-specific enabling and may be required for the generic HPET driver and OS kernel to work. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] ARC: HSDK: add platform-specific commands
Hi Tom, On Mon, 2018-03-26 at 15:57 +0300, Eugeniy Paltsev wrote: > This patch add support of hsdk platform-specific commands: > > hsdk_clock set - set clock from axi_freq, cpu_freq and tun_freq > environment variables/command line arguments > > hsdk_clock get - save clock frequencies to axi_freq, cpu_freq > and tun_freq environment variables > > hsdk_clock print - show CPU, AXI, DDR and TUNNEL current > clock frequencies. > > hsdk_clock print_all - show all currently used clock frequencies. > > hsdk_init - setup board HW in one of pre-defined configuration > (hsdk_hs34 / hsdk_hs36 / hsdk_hs36_ccm / hsdk_hs38 / > hsdk_hs38_ccm / hsdk_hs38x2 / hsdk_hs38x3 / hsdk_hs38x4) > > hsdk_go - run baremetal application on hsdk configured > by hsdk_init command. > > This patch changes default behaviour of 'bootm' command: > now we are able to set number of CPUs to be kicked by setting > 'core_mask' environment variable before 'bootm' command run. > > Signed-off-by: Eugeniy Paltsev> --- I was about to send you a pull-request containing this one but decided to give TravisCI a shot. And what I got was a warning due to not yet supported "naked" attribute in GCC 6.x for ARC, see https://travis-ci.org/abrodkin/u-boot/jobs/360259472 Ok I bumped ARC tools to the most recent arc-2017.09 based on GCC 7.1 where "naked" attr for ARC is already supported. But then I got another warning: ->8--- board/synopsys/hsdk/hsdk.c: In function "hsdk_core_init_f": board/synopsys/hsdk/hsdk.c:345:1: error: stack usage computation not supported for this target [-Werror] } ^ ->8--- see https://travis-ci.org/abrodkin/u-boot/jobs/360274604 That happens because GCC for ARC unconditionally tries to compute stack requirements for all functions even if they are "naked". And for "naked" computed value is negative thus the warning above. So far I didn't manage to find a simple way to disable that warning. And my question would be how to proceed with this [patch]? Given we're seeing a problem in GCC it most probably won't be fixed in U-Boot and we'll need to wait before new tools are available. Or otherwise we'll start to see "failing" ARC jobs in TravisCI. -Alexey ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] timer: add High Precision Event Timers (HPET) support
On Fri, Mar 30, 2018 at 1:29 AM, Ivan Gorinovwrote: > Adding HPET as an alternative timer for x86 (default is TSC). > HPET counter has constant frequency and does not need calibration. > This change also makes TSC timer driver optional on x86. > If X86_TSC is disabled, early timer functions are provided by HPET. > > Signed-off-by: Ivan Gorinov > --- Changelog? > arch/Kconfig | 2 +- > +config HPET_TIMER > + bool "High Precision Event Timers (HPET) support" > + depends on TIMER && X86 Does X86 makes any difference from building point of view? > + config = readl(regs + HPET_CONFIG_REG); > + config &= ~1; > + writel(config, regs + HPET_CONFIG_REG); 1 or BIT(0) is magic. Can be fixed in all places? > + writel(0, regs + HPET_MAIN_COUNT_L); > + writel(0, regs + HPET_MAIN_COUNT_H); Can we use writeq() here? > + tl = readl(regs + HPET_MAIN_COUNT_L); > + th = readl(regs + HPET_MAIN_COUNT_H); Ditto. -- With Best Regards, Andy Shevchenko ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] reset: socfpga: add reset driver for SoCFPGA platform
On 03/30/2018 06:53 PM, Dinh Nguyen wrote: > Add a DM compatible reset driver for the SoCFPGA platform. > > Signed-off-by: Dinh Nguyen> --- > drivers/reset/Kconfig | 7 +++ > drivers/reset/Makefile| 1 + > drivers/reset/reset-socfpga.c | 111 > ++ > 3 files changed, 119 insertions(+) > create mode 100644 drivers/reset/reset-socfpga.c > > diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig > index 3964b9e..90b021f 100644 > --- a/drivers/reset/Kconfig > +++ b/drivers/reset/Kconfig > @@ -83,4 +83,11 @@ config RESET_ROCKCHIP > though is that some reset signals, like I2C or MISC reset multiple > devices. > > +config RESET_SOCFPGA > + bool "Reset controller driver for SoCFPGA" > + depends on DM_RESET && ARCH_SOCFPGA > + default y > + help > + Support for reset controller on SoCFPGA platform. > + > endmenu > diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile > index 7d7e080..6f791ee 100644 > --- a/drivers/reset/Makefile > +++ b/drivers/reset/Makefile > @@ -13,3 +13,4 @@ obj-$(CONFIG_RESET_BCM6345) += reset-bcm6345.o > obj-$(CONFIG_RESET_UNIPHIER) += reset-uniphier.o > obj-$(CONFIG_AST2500_RESET) += ast2500-reset.o > obj-$(CONFIG_RESET_ROCKCHIP) += reset-rockchip.o > +obj-$(CONFIG_RESET_SOCFPGA) += reset-socfpga.o > diff --git a/drivers/reset/reset-socfpga.c b/drivers/reset/reset-socfpga.c > new file mode 100644 > index 000..af585ec > --- /dev/null > +++ b/drivers/reset/reset-socfpga.c > @@ -0,0 +1,111 @@ > +/* > + * Socfpga Reset Controller Driver > + * > + * Copyright 2014 Steffen Trumtrar > + * > + * based on > + * Allwinner SoCs Reset Controller driver > + * > + * Copyright 2013 Maxime Ripard > + * > + * Maxime Ripard > + * > + * SPDX-License-Identifier: GPL-2.0+ > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define BANK_INCREMENT 4 > +#define NR_BANKS 8 > + > +struct socfpga_reset_data { > + void __iomem *membase; > +}; > + > +static int socfpga_reset_assert(struct reset_ctl *reset_ctl) > +{ > + struct socfpga_reset_data *data = dev_get_priv(reset_ctl->dev); > + int id = reset_ctl->id; > + int reg_width = sizeof(u32); > + int bank = id / (reg_width * BITS_PER_BYTE); > + int offset = id % (reg_width * BITS_PER_BYTE); > + unsigned long flags; > + u32 reg; > + > + reg = readl(data->membase + (bank * BANK_INCREMENT)); > + writel(reg | BIT(offset), data->membase + (bank * BANK_INCREMENT)); setbits_le32() ? > + return 0; > +} > + > +static int socfpga_reset_deassert(struct reset_ctl *reset_ctl) > +{ > + struct socfpga_reset_data *data = dev_get_priv(reset_ctl->dev); > + int id = reset_ctl->id; > + int reg_width = sizeof(u32); > + int bank = id / (reg_width * BITS_PER_BYTE); > + int offset = id % (reg_width * BITS_PER_BYTE); > + unsigned long flags; > + u32 reg; > + > + reg = readl(data->membase + (bank * BANK_INCREMENT)); > + writel(reg & ~BIT(offset), data->membase + (bank * BANK_INCREMENT)); clrbits_le32() ? [...] What I do not see is any user of this code, nor any conversion of existing systems to use this code. Is that expected to happen ? I do not want to see dead code piling up in U-Boot. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] timer: Add High Precision Event Timers (HPET) support
On Fri, Mar 30, 2018 at 1:39 AM, Simon Glasswrote: > On 29 March 2018 at 18:52, Andy Shevchenko > wrote: >> On Wed, 2018-03-28 at 17:58 -0700, Ivan Gorinov wrote: >> First question is how this will work in case of Broadwell and Ivybridge >> that have something to do with HPET in their CPU code, i.e. >> >> arch/x86/cpu/broadwell/pch.c >> arch/x86/cpu/ivybridge/lpc.c >> >> ? >> >> Look for >> >> clrsetbits_le32(RCB_REG(HPTC), 3, 1 << 7); > Perhaps that code can be removed in favour of this driver? I am happy > to test on these platforms if it helps. That's my point. -- With Best Regards, Andy Shevchenko ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 26/36] rockchip: rk1108: remove rockchip timer for sys timer
Hello, Kevel! I can confirm, that rk3188 doesn’t have arch timer. I made test, see below. By the way, could you tell what git head to use to apply your patch series? I want to test other changes as well. I failed to apply to this one head: commit eef11acebaa48e241e9187c717dc92d3e175c119 Author: Tom RiniDate: Mon Jan 29 20:12:33 2018 -0500 Prepare v2018.03-rc1 Signed-off-by: Tom Rini I took get_ticks() code from arch_timer.c into board file and tried to execute it: diff --git a/arch/arm/mach-rockchip/rk3188-board.c b/arch/arm/mach-rockchip/rk3188-board.c index fc58aeb..b5d0984 100644 --- a/arch/arm/mach-rockchip/rk3188-board.c +++ b/arch/arm/mach-rockchip/rk3188-board.c @@ -25,9 +25,28 @@ __weak int rk_board_late_init(void) return 0; } +#define CONFIG_SYS_HZ_CLOCK2400 + +ulong arch_tbl = 0; +ulong arch_tbu = 0; +ulong arch_timer_rate_hz = CONFIG_SYS_HZ_CLOCK / CONFIG_SYS_HZ; + +unsigned long long arch_get_ticks(void) +{ + ulong nowl, nowu; + + asm volatile("mrrc p15, 0, %0, %1, c14" : "=r" (nowl), "=r" (nowu)); + + arch_tbl = nowl; + arch_tbu = nowu; + + return (((unsigned long long)arch_tbu) << 32) | arch_tbl; +} + int board_late_init(void) { struct rk3188_grf *grf; + ulong val0, val1; setup_boot_mode(); grf = syscon_get_first_range(ROCKCHIP_SYSCON_GRF); @@ -40,6 +59,12 @@ int board_late_init(void) NOC_REMAP_MASK << NOC_REMAP_SHIFT); } + val0 = arch_get_ticks(); + udelay(100); + val1 = arch_get_ticks(); + + pr_err("val0 %lu; val1 %lu\n", val0, val1); + return rk_board_late_init(); } And I get undefined instruction error on rk3188 board: undefined instruction pc : [<9ff760d6>] lr : [<9ff76129>] reloc pc : [<600010d6>]lr : [<60001129>] sp : 9df669d8 ip : 9df66918 fp : 0017 r10: 6003d648 r9 : 9df6cee8 r8 : 10080228 r7 : 9ffb0654 r6 : 9ffb05e4 r5 : 9ffb0658 r4 : 3ff75000 r3 : 10001000 r2 : 8000 r1 : 20008000 r0 : 20008000 Flags: nzcv IRQs off FIQs off Mode SVC_32 Regards, Alexander. > 28 марта 2018 г., в 5:33, Kever Yang написал(а): > > Hi Alexander, > > > On 03/28/2018 12:21 AM, Alexander Kochetkov wrote: >> The question is: does rk3066 and rk3188 have arch timer? If no, than >> removing rk_timer >> will break u-boot for these chips. > > Thanks for your comment, I will double check about if this two chips > have arch > timer, I think it should be, but I don't have boards now. > > Thanks, > - Kever >> >> And my comment was about global timer, not arch timer. And I failed to >> enable arch >> timer for rk3188 in the kernel. >> >> Alexander. >> >>> 27 марта 2018 г., в 19:07, Alexander Kochetkov >>> написал(а): >>> 27 марта 2018 г., в 12:29, Kever Yang написал(а): We use ARM arch timer instead. >>> Hi, Kever! >>> >>> Just let you know, that arch timer rate on rk3066 and rk3188 depends on CPU >>> frequency. >>> I’ve made patch[1] for fixing that in kernel. >>> If u-boot do arm clock changes after timer initialization, timer can >>> provide inaccurate delays. >>> >>> [1] >>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/clocksource/rockchip_timer.c?id=5e0a39d0f727b35c8b7ef56ba0724c8ceb006297 >>> >>> Alexander. >> > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] Move CONFIG_PHY_ADDR to Kconfig
On Fri, Mar 30, 2018 at 2:49 AM, Bin Mengwrote: > Hi Joe, > > On Thu, Mar 29, 2018 at 2:17 AM, Joe Hershberger > wrote: >> On Sun, Mar 25, 2018 at 8:40 PM, Bin Meng wrote: >>> Hi Joe, >>> >>> On Sat, Mar 24, 2018 at 1:11 AM, Joe Hershberger >>> wrote: On Thu, Mar 22, 2018 at 9:46 AM, Bin Meng wrote: > Hi, > > On Fri, Feb 2, 2018 at 9:53 PM, Stefan Mavrodiev > wrote: >> CONFIG_PHY_ADDR is used for old-style configuration. This makes >> impossible changing the PHY address, if multiple boards share a same >> config header file (for example include/configs/sunxi-common.h). >> >> Moving this to Kconfig helps overcoming this issue. It's defined >> as entry inside PHYLIB section. >> >> After the implemention, moveconfig was run. The issues are: >> - edb9315a - CONFIG_PHYLIB is not enabled. Entry is >> deleted. >> >> - ds414 - CONFIG_PHYLIB is in incompatible format: >> { 0x1, 0x0 }. This entry is also deleted. >> >> - devkit3250- The PHY_ADDR is in hex format (0x1F). >> Manually CONFIG_PHY_ADDR=31 is added in >> the defconfig. >> >> After the changes the suspicious defconfigs passes building. >> >> Signed-off-by: Stefan Mavrodiev >> Acked-by: Maxime Ripard >> --- >> Changes for v2: >>- Replaced CONFIG_SUNXI_PHY_ADDR with a common one >> CONFIG_PHY_ADDR, using moveconfig. >> >> README | 4 >> configs/devkit3250_defconfig | 1 + >> configs/khadas-vim_defconfig | 1 + >> configs/libretech-cc_defconfig | 1 + >> configs/p212_defconfig | 1 + >> drivers/net/phy/Kconfig| 7 +++ >> include/configs/am335x_shc.h | 1 - >> include/configs/baltos.h | 1 - >> include/configs/devkit3250.h | 1 - >> include/configs/ds414.h| 1 - >> include/configs/edb93xx.h | 1 - >> include/configs/khadas-vim.h | 2 -- >> include/configs/libretech-cc.h | 2 -- >> include/configs/p212.h | 2 -- >> include/configs/pepper.h | 1 - >> include/configs/sunxi-common.h | 2 -- >> include/configs/work_92105.h | 1 - >> include/configs/x600.h | 1 - >> scripts/config_whitelist.txt | 1 - >> 19 files changed, 11 insertions(+), 21 deletions(-) >> > > [snip] > >> diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig >> index 95b7534..c934aed 100644 >> --- a/drivers/net/phy/Kconfig >> +++ b/drivers/net/phy/Kconfig >> @@ -12,6 +12,13 @@ menuconfig PHYLIB >> >> if PHYLIB >> >> +config PHY_ADDR >> + int "PHY address" >> + default 1 if ARCH_SUNXI >> + default 0 >> + help >> + The address of PHY on MII bus. Usually in range of 0 to 31. >> + > > Sorry for jumping out so late, but this commit breaks Intel Galileo > ethernet. Previously the board boots with the following log: > > Net: eth0: eth_designware#0, eth1: eth_designware#1 > > With this commit it becomes: > > Net: No ethernet found. > > The reason is that the board has two designware ethernet controllers, > and PHY_ADDR has been set to zero for both. A simple fix is to: > > diff --git a/drivers/net/designware.c b/drivers/net/designware.c > index 43670a7..1394119 100644 > --- a/drivers/net/designware.c > +++ b/drivers/net/designware.c > @@ -471,10 +471,6 @@ static int dw_phy_init(struct dw_eth_dev *priv, void > *dev) > struct phy_device *phydev; > int mask = 0x, ret; > > -#ifdef CONFIG_PHY_ADDR > - mask = 1 << CONFIG_PHY_ADDR; > -#endif > - > phydev = phy_find_by_mask(priv->bus, mask, priv->interface); > if (!phydev) > return -ENODEV; > > But the real question is that: why do we introduce this PHY_ADDR > Kconfig? It for sure won't work for multiple ethernet controllers.This > should be eliminated IMHO. Comments? This should be able to come from the device tree, ultimately. Can you undefine the phy addr for the Galileo board? > [snip] > >>> >>> #undf the PHY_ADDR in Galileo board looks weird. This to me is a workaround. >> >> I didn't mean to add a #undef. I was just saying that if the "default >> 0" in the Kconfig were instead "default 0 if !X86" or something (or >> maybe if the board defconfig explicitly does unselects it). >> > > This cannot be done as CONFIG_PHY_ADDR is an "int", not a "bool". We > cannot do "#
[U-Boot] [RFC PATCH] net: phy: Don't limit phy addresses by default
Some boards expect to find more than one phy while other boards are old and need to be limited to a specific phy address. Only limit the phy address for boards that opt in. Signed-off-by: Joe Hershberger--- configs/am335x_baltos_defconfig| 1 + configs/am335x_shc_defconfig | 1 + configs/am335x_shc_ict_defconfig | 1 + configs/am335x_shc_netboot_defconfig | 1 + configs/am335x_shc_prompt_defconfig| 1 + configs/am335x_shc_sdboot_defconfig| 1 + configs/am335x_shc_sdboot_prompt_defconfig | 1 + configs/devkit3250_defconfig | 1 + configs/ds414_defconfig| 1 + configs/khadas-vim_defconfig | 1 + configs/libretech-cc_defconfig | 1 + configs/p212_defconfig | 1 + configs/pepper_defconfig | 1 + configs/work_92105_defconfig | 1 + configs/x600_defconfig | 1 + drivers/net/phy/Kconfig| 8 16 files changed, 23 insertions(+) diff --git a/configs/am335x_baltos_defconfig b/configs/am335x_baltos_defconfig index ab7d96d..ed7d3a7 100644 --- a/configs/am335x_baltos_defconfig +++ b/configs/am335x_baltos_defconfig @@ -42,6 +42,7 @@ CONFIG_BOOTCOUNT_LIMIT=y CONFIG_SYS_OMAP24_I2C_SPEED=1000 CONFIG_MMC_OMAP_HS=y CONFIG_NAND=y +CONFIG_PHY_ADDR_ENABLE=y CONFIG_PHYLIB=y CONFIG_SYS_NS16550=y CONFIG_OMAP3_SPI=y diff --git a/configs/am335x_shc_defconfig b/configs/am335x_shc_defconfig index fb714da..ade16b9 100644 --- a/configs/am335x_shc_defconfig +++ b/configs/am335x_shc_defconfig @@ -35,6 +35,7 @@ CONFIG_CMD_MMC=y # CONFIG_SPL_ISO_PARTITION is not set CONFIG_ENV_IS_IN_MMC=y CONFIG_MMC_OMAP_HS=y +CONFIG_PHY_ADDR_ENABLE=y CONFIG_PHYLIB=y CONFIG_SYS_NS16550=y CONFIG_OMAP3_SPI=y diff --git a/configs/am335x_shc_ict_defconfig b/configs/am335x_shc_ict_defconfig index 2568e3d..ac19a74 100644 --- a/configs/am335x_shc_ict_defconfig +++ b/configs/am335x_shc_ict_defconfig @@ -36,6 +36,7 @@ CONFIG_CMD_MMC=y # CONFIG_SPL_ISO_PARTITION is not set CONFIG_ENV_IS_IN_MMC=y CONFIG_MMC_OMAP_HS=y +CONFIG_PHY_ADDR_ENABLE=y CONFIG_PHYLIB=y CONFIG_SYS_NS16550=y CONFIG_OMAP3_SPI=y diff --git a/configs/am335x_shc_netboot_defconfig b/configs/am335x_shc_netboot_defconfig index 16071fb..31f1847 100644 --- a/configs/am335x_shc_netboot_defconfig +++ b/configs/am335x_shc_netboot_defconfig @@ -37,6 +37,7 @@ CONFIG_CMD_MMC=y # CONFIG_SPL_ISO_PARTITION is not set CONFIG_ENV_IS_IN_MMC=y CONFIG_MMC_OMAP_HS=y +CONFIG_PHY_ADDR_ENABLE=y CONFIG_PHYLIB=y CONFIG_SYS_NS16550=y CONFIG_OMAP3_SPI=y diff --git a/configs/am335x_shc_prompt_defconfig b/configs/am335x_shc_prompt_defconfig index bbad6dd..803304e 100644 --- a/configs/am335x_shc_prompt_defconfig +++ b/configs/am335x_shc_prompt_defconfig @@ -34,6 +34,7 @@ CONFIG_CMD_MMC=y # CONFIG_SPL_ISO_PARTITION is not set CONFIG_ENV_IS_IN_MMC=y CONFIG_MMC_OMAP_HS=y +CONFIG_PHY_ADDR_ENABLE=y CONFIG_PHYLIB=y CONFIG_SYS_NS16550=y CONFIG_OMAP3_SPI=y diff --git a/configs/am335x_shc_sdboot_defconfig b/configs/am335x_shc_sdboot_defconfig index 82a61a3..2d4f4d1 100644 --- a/configs/am335x_shc_sdboot_defconfig +++ b/configs/am335x_shc_sdboot_defconfig @@ -36,6 +36,7 @@ CONFIG_CMD_MMC=y # CONFIG_SPL_ISO_PARTITION is not set CONFIG_ENV_IS_IN_MMC=y CONFIG_MMC_OMAP_HS=y +CONFIG_PHY_ADDR_ENABLE=y CONFIG_PHYLIB=y CONFIG_SYS_NS16550=y CONFIG_OMAP3_SPI=y diff --git a/configs/am335x_shc_sdboot_prompt_defconfig b/configs/am335x_shc_sdboot_prompt_defconfig index 82a61a3..2d4f4d1 100644 --- a/configs/am335x_shc_sdboot_prompt_defconfig +++ b/configs/am335x_shc_sdboot_prompt_defconfig @@ -36,6 +36,7 @@ CONFIG_CMD_MMC=y # CONFIG_SPL_ISO_PARTITION is not set CONFIG_ENV_IS_IN_MMC=y CONFIG_MMC_OMAP_HS=y +CONFIG_PHY_ADDR_ENABLE=y CONFIG_PHYLIB=y CONFIG_SYS_NS16550=y CONFIG_OMAP3_SPI=y diff --git a/configs/devkit3250_defconfig b/configs/devkit3250_defconfig index e1a9b49..b69808c 100644 --- a/configs/devkit3250_defconfig +++ b/configs/devkit3250_defconfig @@ -36,6 +36,7 @@ CONFIG_MTD_NOR_FLASH=y CONFIG_NAND=y CONFIG_SPL_NAND_SIMPLE=y CONFIG_PHYLIB=y +CONFIG_PHY_ADDR_ENABLE=y CONFIG_PHY_ADDR=31 CONFIG_DM_SERIAL=y CONFIG_SYS_NS16550=y diff --git a/configs/ds414_defconfig b/configs/ds414_defconfig index 5d1d6ab..d68e64e 100644 --- a/configs/ds414_defconfig +++ b/configs/ds414_defconfig @@ -39,6 +39,7 @@ CONFIG_SPL_OF_TRANSLATE=y CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_STMICRO=y +CONFIG_PHY_ADDR_ENABLE=y CONFIG_PHY_GIGE=y CONFIG_MVNETA=y CONFIG_PCI=y diff --git a/configs/khadas-vim_defconfig b/configs/khadas-vim_defconfig index f4674ef..0bfb594 100644 --- a/configs/khadas-vim_defconfig +++ b/configs/khadas-vim_defconfig @@ -20,6 +20,7 @@ CONFIG_NET_RANDOM_ETHADDR=y CONFIG_DM_GPIO=y CONFIG_DM_MMC=y CONFIG_MMC_MESON_GX=y +CONFIG_PHY_ADDR_ENABLE=y CONFIG_PHY_ADDR=8 CONFIG_PHY_MESON_GXL=y CONFIG_DM_ETH=y diff --git
[U-Boot] [PATCH] reset: socfpga: add reset driver for SoCFPGA platform
Add a DM compatible reset driver for the SoCFPGA platform. Signed-off-by: Dinh Nguyen--- drivers/reset/Kconfig | 7 +++ drivers/reset/Makefile| 1 + drivers/reset/reset-socfpga.c | 111 ++ 3 files changed, 119 insertions(+) create mode 100644 drivers/reset/reset-socfpga.c diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig index 3964b9e..90b021f 100644 --- a/drivers/reset/Kconfig +++ b/drivers/reset/Kconfig @@ -83,4 +83,11 @@ config RESET_ROCKCHIP though is that some reset signals, like I2C or MISC reset multiple devices. +config RESET_SOCFPGA + bool "Reset controller driver for SoCFPGA" + depends on DM_RESET && ARCH_SOCFPGA + default y + help + Support for reset controller on SoCFPGA platform. + endmenu diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile index 7d7e080..6f791ee 100644 --- a/drivers/reset/Makefile +++ b/drivers/reset/Makefile @@ -13,3 +13,4 @@ obj-$(CONFIG_RESET_BCM6345) += reset-bcm6345.o obj-$(CONFIG_RESET_UNIPHIER) += reset-uniphier.o obj-$(CONFIG_AST2500_RESET) += ast2500-reset.o obj-$(CONFIG_RESET_ROCKCHIP) += reset-rockchip.o +obj-$(CONFIG_RESET_SOCFPGA) += reset-socfpga.o diff --git a/drivers/reset/reset-socfpga.c b/drivers/reset/reset-socfpga.c new file mode 100644 index 000..af585ec --- /dev/null +++ b/drivers/reset/reset-socfpga.c @@ -0,0 +1,111 @@ +/* + * Socfpga Reset Controller Driver + * + * Copyright 2014 Steffen Trumtrar + * + * based on + * Allwinner SoCs Reset Controller driver + * + * Copyright 2013 Maxime Ripard + * + * Maxime Ripard + * + * SPDX-License-Identifier: GPL-2.0+ + */ + +#include +#include +#include +#include +#include +#include +#include + +#define BANK_INCREMENT 4 +#define NR_BANKS 8 + +struct socfpga_reset_data { + void __iomem *membase; +}; + +static int socfpga_reset_assert(struct reset_ctl *reset_ctl) +{ + struct socfpga_reset_data *data = dev_get_priv(reset_ctl->dev); + int id = reset_ctl->id; + int reg_width = sizeof(u32); + int bank = id / (reg_width * BITS_PER_BYTE); + int offset = id % (reg_width * BITS_PER_BYTE); + unsigned long flags; + u32 reg; + + reg = readl(data->membase + (bank * BANK_INCREMENT)); + writel(reg | BIT(offset), data->membase + (bank * BANK_INCREMENT)); + return 0; +} + +static int socfpga_reset_deassert(struct reset_ctl *reset_ctl) +{ + struct socfpga_reset_data *data = dev_get_priv(reset_ctl->dev); + int id = reset_ctl->id; + int reg_width = sizeof(u32); + int bank = id / (reg_width * BITS_PER_BYTE); + int offset = id % (reg_width * BITS_PER_BYTE); + unsigned long flags; + u32 reg; + + reg = readl(data->membase + (bank * BANK_INCREMENT)); + writel(reg & ~BIT(offset), data->membase + (bank * BANK_INCREMENT)); + return 0; +} + +static int socfpga_reset_request(struct reset_ctl *reset_ctl) +{ + debug("%s(reset_ctl=%p) (dev=%p, id=%lu)\n", __func__, + reset_ctl, reset_ctl->dev, reset_ctl->id); + + return 0; +} + +static int socfpga_reset_free(struct reset_ctl *reset_ctl) +{ + debug("%s(reset_ctl=%p) (dev=%p, id=%lu)\n", __func__, reset_ctl, + reset_ctl->dev, reset_ctl->id); + + return 0; +} + +static const struct reset_ops socfpga_reset_ops = { + .request = socfpga_reset_request, + .free = socfpga_reset_free, + .rst_assert = socfpga_reset_assert, + .rst_deassert = socfpga_reset_deassert, +}; + +static int socfpga_reset_probe(struct udevice *dev) +{ + struct socfpga_reset_data *data = dev_get_priv(dev); + const void *blob = gd->fdt_blob; + int node = dev_of_offset(dev); + u32 modrst_offset; + + data->membase = devfdt_get_addr_ptr(dev); + + modrst_offset = fdtdec_get_int(blob, node, "altr,modrst-offset", 0x10); + data->membase += modrst_offset; + + return 0; +} + +static const struct udevice_id socfpga_reset_match[] = { + { .compatible = "altr,rst-mgr" }, + { /* sentinel */ }, +}; + +U_BOOT_DRIVER(socfpga_reset) = { + .name = "socfpga-reset", + .id = UCLASS_RESET, + .of_match = socfpga_reset_match, + .probe = socfpga_reset_probe, + .priv_auto_alloc_size = sizeof(struct socfpga_reset_data), + .ops = _reset_ops, +}; -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 15/18] warp7: Make load command an environment variable
On 30/03/18 16:05, Fabio Estevam wrote: This will conflict with Pierre-Jean's recent patch series that makes use of the generic load command: https://lists.denx.de/pipermail/u-boot/2018-March/324065.html and https://lists.denx.de/pipermail/u-boot/2018-March/324066.html Would his approach work for you? If it does I'll redo my patchset on top of that and give a RB-tag on the series. Thanks for point this out --- bod ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: mx6: ddr: Add write leveling correction code
Hi Marek, Thanks for this update and the detailed notes. On 03/29/2018 06:04 PM, Marek Vasut wrote: When the DDR calibration is enabled, a situation may happen that it will fail on a few select boards out of a whole production lot. In particular, after the first write leveling stage, the MPWLDECTRLx registers will contain a value 0x1nn , for nn usually being 0x7f or slightly lower. What this means is that the HW write leveling detected that the DQS rising edge on one or more bundles arrives slightly _after_ CLK and therefore when the DDR DRAM samples CLK on the DQS rising edge, the CLK signal is already high (cfr. AN4467 rev2 Figure 7 on page 18). The HW write leveling then ends up adding almost an entire cycle (thus the 0x17f) to the DQS delay, which indeed aligns it, but also triggers subsequent calibration failure in DQS gating due to this massive offset. There are two observations here: - If the MPWLDECTRLx value is corrected from 0x17f to 0x0 , then the DQS gating passes, the entire calibration passes as well and the DRAM is perfectly stable even under massive load. - When using the NXP DRAM calibrator for iMX6/7, the value 0x17f or so in MPWLDECTRx register is not there, but it is replaced by 0x0 as one would expect. Someone from NXP finally explains why, quoting [1]: " Having said all that, the DDR Stress Test does something that we do not advertise to the users. The Stress Test iself looks at the values of the MPWLDECTRL0/1 fields before reporting results, and if it sees any filed with a value greater than 200/256 delay (reported as half-cycle = 0x1 and ABS_OFFSET > 0x48), the DDR Stress test will reset the Write Leveling delay for this lane to 0x000 and not report it in the log. The reason that the DDR Stress test does this is because a delay of more than 78% a clock cycle means that the DQS edge is arriving within the JEDEC tolerence of 25% of the clock edge. In most cases, DQS is arriving < 5% tCK of the SDCLK edge in the early case, and it does not make sense to delay the DQS strobe almost a full clock cycle and add extra latency to each Write burst just to make the two edges align exactly. In this case, we are guilty of making a decision for the customer without telling them we are doing it so that we don't have to provide the above explanation to every customer. They don't need to know it. " This patch adds the correction described above, that is if the MPWLDECTRx value is over 0x148, the value is corrected back to 0x0. [1] https://community.nxp.com/thread/456246 Signed-off-by: Marek VasutCc: Stefano Babic --- arch/arm/mach-imx/mx6/ddr.c | 24 1 file changed, 24 insertions(+) diff --git a/arch/arm/mach-imx/mx6/ddr.c b/arch/arm/mach-imx/mx6/ddr.c index 43b77cfa41..6e5e40dd1a 100644 --- a/arch/arm/mach-imx/mx6/ddr.c +++ b/arch/arm/mach-imx/mx6/ddr.c @@ -85,6 +85,23 @@ static void modify_dg_result(u32 *reg_st0, u32 *reg_st1, u32 *reg_ctrl) writel(val_ctrl, reg_ctrl); } +static void correct_mpwldectr_result(void *reg) +{ + /* Limit is 200/256 of CK, which is WL_HC_DELx | 0x48. */ + const unsigned int limit = 0x148; + u32 val = readl(reg); + u32 old = val; + Nit: I think "val &= 0x" would be slightly easier to read instead of the "<< 16": + if ((val & 0x17f) > limit) + val &= 0x << 16; + + if (((val >> 16) & 0x17f) > limit) + val &= 0x; + + if (old != val) + writel(val, reg); +} + int mmdc_do_write_level_calibration(struct mx6_ddr_sysinfo const *sysinfo) { struct mmdc_p_regs *mmdc0 = (struct mmdc_p_regs *)MMDC_P0_BASE_ADDR; @@ -176,6 +193,13 @@ int mmdc_do_write_level_calibration(struct mx6_ddr_sysinfo const *sysinfo) errors |= 4; } + correct_mpwldectr_result(>mpwldectrl0); + correct_mpwldectr_result(>mpwldectrl1); + if (sysinfo->dsize == 2) { + correct_mpwldectr_result(>mpwldectrl0); + correct_mpwldectr_result(>mpwldectrl1); + } + /* * User should issue MRS command to exit write leveling mode * through Load Mode Register command Otherwise, Reviewed-by: Eric Nelson ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] configs: warp7: Fix CAAM on boot with tip-of-tree
On 30/03/18 15:53, Fabio Estevam wrote: Hi Bryan, On Fri, Mar 30, 2018 at 7:55 AM, Bryan O'Donoghuewrote: Booting the following image with tip-of-tree we get a CAAM DECO error (and subsequent crash due to a kernel bug in 4.1). For booting NXP based kernel you should use warp7_secure_defconfig instead, which selects CONFIG_ARMV7_BOOT_SEC_DEFAULT=y. Please see commit 375d199114c1 ("warp7: Add a secure mode target"). Also if using CONFIG_ARMV7_BOOT_SEC_DEFAULT=y is safe for booting both mainline and NXP kernels then I think you are patch is OK and we can get rid of warp7_secure_defconfig. I don't have access to my warp7 board at the moment to give it a try. Please confirm that this patch can successfully boot both mainline and NXP kernels. Thanks Hi Fabio, I can confirm I can boot the NXP 4.1, Linaro and a mainline 4.16-rcx kernels with CONFIG_ARMV7_BOOT_SEC_DEFAULT=y I'll reconfirm to be sure and redo this patch CONFIG_ARMV7_BOOT_SEC_DEFAULT=y and subtract warp7_secure_defconfig ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: mx6: ddr: Add write leveling correction code
Hi Marek, On Thu, Mar 29, 2018 at 10:04 PM, Marek Vasutwrote: > When the DDR calibration is enabled, a situation may happen that it > will fail on a few select boards out of a whole production lot. In > particular, after the first write leveling stage, the MPWLDECTRLx > registers will contain a value 0x1nn , for nn usually being 0x7f or > slightly lower. > > What this means is that the HW write leveling detected that the DQS > rising edge on one or more bundles arrives slightly _after_ CLK and > therefore when the DDR DRAM samples CLK on the DQS rising edge, the > CLK signal is already high (cfr. AN4467 rev2 Figure 7 on page 18). > > The HW write leveling then ends up adding almost an entire cycle (thus > the 0x17f) to the DQS delay, which indeed aligns it, but also triggers > subsequent calibration failure in DQS gating due to this massive offset. > > There are two observations here: > - If the MPWLDECTRLx value is corrected from 0x17f to 0x0 , then the > DQS gating passes, the entire calibration passes as well and the > DRAM is perfectly stable even under massive load. > - When using the NXP DRAM calibrator for iMX6/7, the value 0x17f or so > in MPWLDECTRx register is not there, but it is replaced by 0x0 as one > would expect. > > Someone from NXP finally explains why, quoting [1]: > > " > Having said all that, the DDR Stress Test does something that we > do not advertise to the users. The Stress Test iself looks at the > values of the MPWLDECTRL0/1 fields before reporting results, and > if it sees any filed with a value greater than 200/256 delay > (reported as half-cycle = 0x1 and ABS_OFFSET > 0x48), the DDR > Stress test will reset the Write Leveling delay for this lane > to 0x000 and not report it in the log. > > The reason that the DDR Stress test does this is because a delay > of more than 78% a clock cycle means that the DQS edge is arriving > within the JEDEC tolerence of 25% of the clock edge. In most cases, > DQS is arriving < 5% tCK of the SDCLK edge in the early case, and > it does not make sense to delay the DQS strobe almost a full clock > cycle and add extra latency to each Write burst just to make the > two edges align exactly. In this case, we are guilty of making a > decision for the customer without telling them we are doing it so > that we don't have to provide the above explanation to every customer. > They don't need to know it. > " > > This patch adds the correction described above, that is if the MPWLDECTRx > value is over 0x148, the value is corrected back to 0x0. > > [1] https://community.nxp.com/thread/456246 > > Signed-off-by: Marek Vasut > Cc: Stefano Babic Thanks for the fix and for the detailed commit log! Reviewed-by: Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 15/18] warp7: Make load command an environment variable
Hi Bryan, On Fri, Mar 30, 2018 at 11:18 AM, Bryan O'Donoghuewrote: > This patch replaces the current "fatload" command with an environment > variable. Making the load command into an environment variable means we can > change filesystem type in boot.scr and reuse existing commands within that > boot script. > > Signed-off-by: Bryan O'Donoghue > --- > include/configs/warp7.h | 7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/include/configs/warp7.h b/include/configs/warp7.h > index c957b2d..712850e 100644 > --- a/include/configs/warp7.h > +++ b/include/configs/warp7.h > @@ -51,12 +51,13 @@ > "mmcargs=setenv bootargs console=${console},${baudrate} " \ > "root=PARTUUID=${uuid} rootwait rw\0" \ > "warp7_auth_or_fail=hab_auth_img_or_fail ${hab_ivt_addr} ${filesize} > 0;\0" \ > + "loadcmd=fatload\0" \ > "loadbootscript=" \ > - "fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \ > + "${loadcmd} mmc ${mmcdev}:${mmcpart} ${loadaddr} > ${script};\0" \ > "bootscript=echo Running bootscript from mmc ...; " \ > "source\0" \ > - "loadimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${image}\0" \ > - "loadfdt=fatload mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0" \ > + "loadimage=${loadcmd} mmc ${mmcdev}:${mmcpart} ${loadaddr} > ${image}\0" \ > + "loadfdt=${loadcmd} mmc ${mmcdev}:${mmcpart} ${fdt_addr} > ${fdt_file}\0" \ > "mmcboot=echo Booting from mmc ...; " \ This will conflict with Pierre-Jean's recent patch series that makes use of the generic load command: https://lists.denx.de/pipermail/u-boot/2018-March/324065.html and https://lists.denx.de/pipermail/u-boot/2018-March/324066.html Would his approach work for you? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 11/18] warp7: Add Kconfig WARP7_ROOT_PART
Hi Bryan, On Fri, Mar 30, 2018 at 11:18 AM, Bryan O'Donoghuewrote: > Adding CONFIG_WARP7_ROOT_PART allows a defconfig to specify which partition > is use as the root partition on WaRP7, this is a desirable change in order > to support a different partitioning schemes. The default is the current > partition #1. I think you meant "partition #2" here instead. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] configs: warp7: Fix CAAM on boot with tip-of-tree
Hi Bryan, On Fri, Mar 30, 2018 at 7:55 AM, Bryan O'Donoghuewrote: > Booting the following image with tip-of-tree we get a CAAM DECO error (and > subsequent crash due to a kernel bug in 4.1). For booting NXP based kernel you should use warp7_secure_defconfig instead, which selects CONFIG_ARMV7_BOOT_SEC_DEFAULT=y. Please see commit 375d199114c1 ("warp7: Add a secure mode target"). Also if using CONFIG_ARMV7_BOOT_SEC_DEFAULT=y is safe for booting both mainline and NXP kernels then I think you are patch is OK and we can get rid of warp7_secure_defconfig. I don't have access to my warp7 board at the moment to give it a try. Please confirm that this patch can successfully boot both mainline and NXP kernels. Thanks ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 10/18] warp7: Make CONFIG_SYS_FDT_ADDR a define
In order to sign images with the IMX code-signing-tool (CST) we need to know the load address of a given image. The best way to derive this load address is to make it into a define - so that u-boot.cfg contains the address - which we can then parse when generating the IMX CST headers. Signed-off-by: Bryan O'DonoghueReviewed-by: Ryan Harkin --- board/warp7/Kconfig | 6 ++ include/configs/warp7.h | 2 +- 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/board/warp7/Kconfig b/board/warp7/Kconfig index 61c33fb..00df19d 100644 --- a/board/warp7/Kconfig +++ b/board/warp7/Kconfig @@ -6,4 +6,10 @@ config SYS_BOARD config SYS_CONFIG_NAME default "warp7" +config SYS_FDT_ADDR + hex "FDT load address" + default 0x8300 + help + The address the FDT file should be loaded to. + endif diff --git a/include/configs/warp7.h b/include/configs/warp7.h index 9ae2ca4..a92e675 100644 --- a/include/configs/warp7.h +++ b/include/configs/warp7.h @@ -39,7 +39,7 @@ "fdt_high=0x\0" \ "initrd_high=0x\0" \ "fdt_file=imx7s-warp.dtb\0" \ - "fdt_addr=0x8300\0" \ + "fdt_addr=" __stringify(CONFIG_SYS_FDT_ADDR)"\0" \ "optee_addr=" __stringify(CONFIG_OPTEE_LOAD_ADDR)"\0" \ "boot_fdt=try\0" \ "ip_dyn=yes\0" \ -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] clk: add Amlogic meson clock driver
Hi guys, Am 30.03.2018 um 10:41 schrieb Simon Glass: > On 30 March 2018 at 15:53, Neil Armstrongwrote: >> On 30/03/2018 00:41, Simon Glass wrote: >>> On 29 March 2018 at 16:42, Neil Armstrong wrote: On 03/12/2017 10:17, Beniamino Galvani wrote: > + > + gate = [clk->id]; > + > + if (gate->reg == 0) > + return -ENOENT; Same here -ENOSYS >> >> Here thsi means it's not a gate. > > Yes, but the driver still supports the operation. The problem is that > its inputs are invalid. So use -ENOENT to mean that. Isn't that the definition of -EINVAL? Cheers, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 18/18] warp7: Add support for automated secure boot.scr verification
This patch adds support for verifying a signed boot.scr. With this in place it's possible for run-time Linux to update boot.scr to set different variables such as switching between different boot partitions, pointing to different kernels etc and for u-boot to verify these changes via the HAB prior to executing the commands contained in boot.scr. Signed-off-by: Bryan O'Donoghue--- include/configs/warp7.h | 9 + 1 file changed, 9 insertions(+) diff --git a/include/configs/warp7.h b/include/configs/warp7.h index adf25ac..2a2d431 100644 --- a/include/configs/warp7.h +++ b/include/configs/warp7.h @@ -54,6 +54,14 @@ "ivt_offset=" __stringify(BOOTROM_IVT_HDR_OFFSET)"\0"\ "warp7_auth_or_fail=hab_auth_img_or_fail ${hab_ivt_addr} ${filesize} 0;\0" \ "loadcmd=fatload\0" \ + "do_bootscript_hab=" \ + "if test ${hab_enabled} -eq 1; then " \ + "setexpr hab_ivt_addr ${loadaddr} - ${ivt_offset}; " \ + "setenv script ${script_signed}; " \ + "${loadcmd} mmc ${mmcdev}:${mmcpart} ${hab_ivt_addr} ${script}; " \ + "run warp7_auth_or_fail; " \ + "run bootscript; "\ + "fi;\0" \ "loadbootscript=" \ "${loadcmd} mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \ "bootscript=echo Running bootscript from mmc ...; " \ @@ -80,6 +88,7 @@ #define CONFIG_BOOTCOMMAND \ "mmc dev ${mmcdev};" \ "mmc dev ${mmcdev}; if mmc rescan; then " \ + "run do_bootscript_hab;" \ "if run loadbootscript; then " \ "run bootscript; " \ "else " \ -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 07/18] warp7: Specify CONFIG_OPTEE_LOAD_ADDR
In order to sign images with the IMX code-signing-tool (CST) we need to know the load address of a given image. The best way to derive this load address is to make it into a define - so that u-boot.cfg contains the address - which we can then parse when generating the IMX CST headers. This patch makes the OPTEE_LOAD_ADDR available via u-boot.cfg for further parsing by external tools. Signed-off-by: Bryan O'DonoghueReviewed-by: Ryan Harkin --- configs/warp7_secure_defconfig | 1 + include/configs/warp7.h| 1 + 2 files changed, 2 insertions(+) diff --git a/configs/warp7_secure_defconfig b/configs/warp7_secure_defconfig index 538f9ab..81b297f 100644 --- a/configs/warp7_secure_defconfig +++ b/configs/warp7_secure_defconfig @@ -41,3 +41,4 @@ CONFIG_USB_ETH_CDC=y CONFIG_USBNET_HOST_ADDR="de:ad:be:af:00:00" CONFIG_OF_LIBFDT=y CONFIG_OPTEE=y +CONFIG_OPTEE_LOAD_ADDR=0x8400 diff --git a/include/configs/warp7.h b/include/configs/warp7.h index c6ab29a..9ae2ca4 100644 --- a/include/configs/warp7.h +++ b/include/configs/warp7.h @@ -40,6 +40,7 @@ "initrd_high=0x\0" \ "fdt_file=imx7s-warp.dtb\0" \ "fdt_addr=0x8300\0" \ + "optee_addr=" __stringify(CONFIG_OPTEE_LOAD_ADDR)"\0" \ "boot_fdt=try\0" \ "ip_dyn=yes\0" \ "mmcdev="__stringify(CONFIG_SYS_MMC_ENV_DEV)"\0" \ -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 05/18] warp7: Allocate specific region of memory to OPTEE
Subtracts CONFIG_OPTEE_TZDRAM_SIZE from the available DRAM size. On WaRP7 we simply define the OPTEE region as from the maximum DRAM address minus CONFIG_OPTEE_TZDRAM_SIZE bytes. Note the OPTEE boot process will itself subtract the DRAM region it lives in from the memory map passed to Linux. Signed-off-by: Bryan O'Donoghue--- board/warp7/warp7.c | 5 + 1 file changed, 5 insertions(+) diff --git a/board/warp7/warp7.c b/board/warp7/warp7.c index 0d3d324..56f0cdd 100644 --- a/board/warp7/warp7.c +++ b/board/warp7/warp7.c @@ -58,6 +58,11 @@ int dram_init(void) { gd->ram_size = PHYS_SDRAM_SIZE; + /* Subtract the defined OPTEE runtime firmware length */ +#ifdef CONFIG_OPTEE_TZDRAM_SIZE + gd->ram_size -= CONFIG_OPTEE_TZDRAM_SIZE; +#endif + return 0; } -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 12/18] warp7: select uuid partition based on rootpart
Assigning the UUID discovery path to a tweakable environment variable means that later steps in the boot process - particularly a boot script can change the target root partition of a particular Linux boot. Retargeting the rootfs is an important feature when doing ping/pong upgrades allowing a boot script to select ping or pong as necessary without reprogramming the bootloader. Signed-off-by: Bryan O'Donoghue--- include/configs/warp7.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/configs/warp7.h b/include/configs/warp7.h index a92e675..f2ee09b 100644 --- a/include/configs/warp7.h +++ b/include/configs/warp7.h @@ -45,7 +45,8 @@ "ip_dyn=yes\0" \ "mmcdev="__stringify(CONFIG_SYS_MMC_ENV_DEV)"\0" \ "mmcpart=" __stringify(CONFIG_SYS_MMC_IMG_LOAD_PART) "\0" \ - "finduuid=part uuid mmc 0:2 uuid\0" \ + "rootpart=" __stringify(CONFIG_WARP7_ROOT_PART) "\0" \ + "finduuid=part uuid mmc 0:${rootpart} uuid\0" \ "mmcargs=setenv bootargs console=${console},${baudrate} " \ "root=PARTUUID=${uuid} rootwait rw\0" \ "loadbootscript=" \ -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 11/18] warp7: Add Kconfig WARP7_ROOT_PART
Adding CONFIG_WARP7_ROOT_PART allows a defconfig to specify which partition is use as the root partition on WaRP7, this is a desirable change in order to support a different partitioning schemes. The default is the current partition #1. Signed-off-by: Bryan O'Donoghue--- board/warp7/Kconfig | 8 1 file changed, 8 insertions(+) diff --git a/board/warp7/Kconfig b/board/warp7/Kconfig index 00df19d..c089bca 100644 --- a/board/warp7/Kconfig +++ b/board/warp7/Kconfig @@ -6,6 +6,14 @@ config SYS_BOARD config SYS_CONFIG_NAME default "warp7" +config WARP7_ROOT_PART + int "Partition number to use for root filesystem" + default 2 + help + The partition number to use for root filesystem this is the + partition that is typically specified with root=/dev/sdaX or + which gets converted into a root=PARTUUID=some_uuid. + config SYS_FDT_ADDR hex "FDT load address" default 0x8300 -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 03/18] warp7: hab: Set environment variable indicating HAB enable
This patch adds an environment variable called "hab_enabled" which gets set to a boolean status indicating whether HAB is enabled or not. Subsequent patches can use this environment variable to determine if its necessary to run a given binary through the hab_auth_img console command. Signed-off-by: Bryan O'Donoghue--- board/warp7/warp7.c | 8 include/configs/warp7.h | 3 +++ 2 files changed, 11 insertions(+) diff --git a/board/warp7/warp7.c b/board/warp7/warp7.c index 327f656..0d3d324 100644 --- a/board/warp7/warp7.c +++ b/board/warp7/warp7.c @@ -10,6 +10,7 @@ #include #include #include +#include #include #include #include @@ -203,6 +204,13 @@ int board_late_init(void) */ clrsetbits_le16(>wcr, 0, 0x10); +#ifdef CONFIG_SECURE_BOOT + /* Determine HAB state */ + env_set_ulong(HAB_ENABLED_ENVNAME, imx_hab_is_enabled()); +#else + env_set_ulong(HAB_ENABLED_ENVNAME, 0); +#endif + #ifdef CONFIG_SERIAL_TAG /* Set serial# standard environment variable based on OTP settings */ get_board_serial(); diff --git a/include/configs/warp7.h b/include/configs/warp7.h index 0c3b605..c6ab29a 100644 --- a/include/configs/warp7.h +++ b/include/configs/warp7.h @@ -139,4 +139,7 @@ #define CONFIG_USBNET_DEV_ADDR "de:ad:be:af:00:01" +/* Environment variable name to represent HAB enable state */ +#define HAB_ENABLED_ENVNAME"hab_enabled" + #endif -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 14/18] warp7: add warp7_auth_or_fail
Doing secure boot on the WaRP7 using a common image format and the same variable to represent the base address for each call means we can reduce down the command to a single environment command. This patch adds warp7_auth_or_fail as a wrapper around "hab_auth_img_or_fail ${hab_ivt_addr} ${filesize} 0". Signed-off-by: Bryan O'Donoghue--- include/configs/warp7.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/warp7.h b/include/configs/warp7.h index 53fbcb2..c957b2d 100644 --- a/include/configs/warp7.h +++ b/include/configs/warp7.h @@ -50,6 +50,7 @@ "finduuid=part uuid mmc 0:${rootpart} uuid\0" \ "mmcargs=setenv bootargs console=${console},${baudrate} " \ "root=PARTUUID=${uuid} rootwait rw\0" \ + "warp7_auth_or_fail=hab_auth_img_or_fail ${hab_ivt_addr} ${filesize} 0;\0" \ "loadbootscript=" \ "fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \ "bootscript=echo Running bootscript from mmc ...; " \ -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 17/18] warp7_secure: defconfig: Enable CMD_SETEXPR
setexpr allows us to do arithmetic for env variables - something that is both useful and required when doing HAB authentication without hard-coding HAB load addresses. Enable setexpr in the secure defconfig - it's not required for the unsecure version. Signed-off-by: Bryan O'Donoghue--- configs/warp7_secure_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configs/warp7_secure_defconfig b/configs/warp7_secure_defconfig index 0d46aa7..3342f54 100644 --- a/configs/warp7_secure_defconfig +++ b/configs/warp7_secure_defconfig @@ -21,7 +21,7 @@ CONFIG_CMD_MMC=y CONFIG_CMD_PART=y CONFIG_CMD_USB=y CONFIG_CMD_USB_MASS_STORAGE=y -# CONFIG_CMD_SETEXPR is not set +CONFIG_CMD_SETEXPR=y CONFIG_CMD_CACHE=y CONFIG_CMD_EXT2=y CONFIG_CMD_EXT4=y -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 13/18] warp7: Define the name of a signed boot-script file
We need to know the name of a signed boot-script, its better to have a separate variable for this then to simply append some fixed string to an existing image name. Signed-off-by: Bryan O'Donoghue--- include/configs/warp7.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/warp7.h b/include/configs/warp7.h index f2ee09b..53fbcb2 100644 --- a/include/configs/warp7.h +++ b/include/configs/warp7.h @@ -33,6 +33,7 @@ #define CONFIG_EXTRA_ENV_SETTINGS \ CONFIG_DFU_ENV_SETTINGS \ "script=boot.scr\0" \ + "script_signed=boot.scr.imx-signed\0" \ "image=zImage\0" \ "console=ttymxc0\0" \ "ethact=usb_ether\0" \ -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 16/18] warp7: hab: Set environment variable indicating IVT offset
This patch introduces the environment variable ivt_offset. When we define a load address for Linux or DTB or any file the IVT associated with that file is prepended. We extract the actual load addresses from u-boot.cfg and feed these values into the code-signing process - hence we want u-boot to have the real load addresses exported in uboot.cfg. ivt_offset represents the addition or subtraction from the load address that must happen to find an IVT header. Signed-off-by: Bryan O'Donoghue--- include/configs/warp7.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/configs/warp7.h b/include/configs/warp7.h index 712850e..adf25ac 100644 --- a/include/configs/warp7.h +++ b/include/configs/warp7.h @@ -10,6 +10,7 @@ #define __WARP7_CONFIG_H #include "mx7_common.h" +#include #define PHYS_SDRAM_SIZESZ_512M @@ -50,6 +51,7 @@ "finduuid=part uuid mmc 0:${rootpart} uuid\0" \ "mmcargs=setenv bootargs console=${console},${baudrate} " \ "root=PARTUUID=${uuid} rootwait rw\0" \ + "ivt_offset=" __stringify(BOOTROM_IVT_HDR_OFFSET)"\0"\ "warp7_auth_or_fail=hab_auth_img_or_fail ${hab_ivt_addr} ${filesize} 0;\0" \ "loadcmd=fatload\0" \ "loadbootscript=" \ -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 08/18] warp7: defconfig: Enable CONFIG_SECURE_BOOT
Various function associated with booting the WaRP7 in High Assurance Boot (HAB) mode are enabled by switching on CONFIG_SECURE_BOOT. This patch enables CONFIG_SECURE_BOOT for the WaRP7 defconfig. Signed-off-by: Bryan O'Donoghue--- configs/warp7_secure_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/warp7_secure_defconfig b/configs/warp7_secure_defconfig index 81b297f..d1d2495 100644 --- a/configs/warp7_secure_defconfig +++ b/configs/warp7_secure_defconfig @@ -1,5 +1,6 @@ CONFIG_ARM=y CONFIG_ARCH_MX7=y +CONFIG_SECURE_BOOT=y CONFIG_SYS_TEXT_BASE=0x8780 CONFIG_TARGET_WARP7=y CONFIG_ARMV7_BOOT_SEC_DEFAULT=y -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 00/18] warp7: Enable automated OPTEE/HAB boot flow
+ Breno Forget to add you to the CC Breno bod < sleep ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 04/18] warp7: defconfig: Enable OPTEE for WaRP7
Requires setting CONFIG_OPTEE=y and setting an OPTEE TrustZone DRAM base in include/configs/warp7.h. Signed-off-by: Bryan O'Donoghue--- configs/warp7_secure_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/warp7_secure_defconfig b/configs/warp7_secure_defconfig index 7310855..538f9ab 100644 --- a/configs/warp7_secure_defconfig +++ b/configs/warp7_secure_defconfig @@ -40,3 +40,4 @@ CONFIG_USB_ETHER=y CONFIG_USB_ETH_CDC=y CONFIG_USBNET_HOST_ADDR="de:ad:be:af:00:00" CONFIG_OF_LIBFDT=y +CONFIG_OPTEE=y -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 15/18] warp7: Make load command an environment variable
This patch replaces the current "fatload" command with an environment variable. Making the load command into an environment variable means we can change filesystem type in boot.scr and reuse existing commands within that boot script. Signed-off-by: Bryan O'Donoghue--- include/configs/warp7.h | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/include/configs/warp7.h b/include/configs/warp7.h index c957b2d..712850e 100644 --- a/include/configs/warp7.h +++ b/include/configs/warp7.h @@ -51,12 +51,13 @@ "mmcargs=setenv bootargs console=${console},${baudrate} " \ "root=PARTUUID=${uuid} rootwait rw\0" \ "warp7_auth_or_fail=hab_auth_img_or_fail ${hab_ivt_addr} ${filesize} 0;\0" \ + "loadcmd=fatload\0" \ "loadbootscript=" \ - "fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \ + "${loadcmd} mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \ "bootscript=echo Running bootscript from mmc ...; " \ "source\0" \ - "loadimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${image}\0" \ - "loadfdt=fatload mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0" \ + "loadimage=${loadcmd} mmc ${mmcdev}:${mmcpart} ${loadaddr} ${image}\0" \ + "loadfdt=${loadcmd} mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0" \ "mmcboot=echo Booting from mmc ...; " \ "run finduuid; " \ "run mmcargs; " \ -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 06/18] warp7: Print out the OPTEE DRAM region
Right now a region of 0x30 bytes is allocated at the end of DRAM for the purposes of loading an OPTEE firmware inside of it. This patch adds the printout of the relevant address ranges. Signed-off-by: Bryan O'Donoghue--- board/warp7/warp7.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/board/warp7/warp7.c b/board/warp7/warp7.c index 56f0cdd..da52b18 100644 --- a/board/warp7/warp7.c +++ b/board/warp7/warp7.c @@ -181,7 +181,17 @@ int checkboard(void) else mode = "non-secure"; +#ifdef CONFIG_OPTEE_TZDRAM_SIZE + unsigned long optee_start, optee_end; + + optee_end = PHYS_SDRAM + PHYS_SDRAM_SIZE; + optee_start = optee_end - CONFIG_OPTEE_TZDRAM_SIZE; + + printf("Board: WARP7 in %s mode OPTEE DRAM 0x%08lx-0x%08lx\n", + mode, optee_start, optee_end); +#else printf("Board: WARP7 in %s mode\n", mode); +#endif return 0; } -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 02/18] warp7: hab: Add a CSF location definition
In order to correctly produce an image with a IVT/DCD header we need to define a CSF in imximage.cfg. We just use the mx7 default here. All we have to do with this option switched on is "make u-boot.imx" and we then will get - u-boot.imx - u-boot.imx.log The log file is really important because it gives the addresses for the HAB that we will require to sign the u-boot image using the CST. Since the addresses can change this logfile is a critical output. Signed-off-by: Bryan O'Donoghue--- board/warp7/imximage.cfg | 4 1 file changed, 4 insertions(+) diff --git a/board/warp7/imximage.cfg b/board/warp7/imximage.cfg index 5b42793..51a5bff 100644 --- a/board/warp7/imximage.cfg +++ b/board/warp7/imximage.cfg @@ -13,6 +13,10 @@ #include IMAGE_VERSION 2 +#ifdef CONFIG_SECURE_BOOT +CSF CONFIG_CSF_SIZE +#endif + BOOT_FROM sd /* -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 09/18] warp7: defconfig: Enable CONFIG_BOOTM_TEE
This patch enables CONFIG_BOOTM_TEE. Once enabled its possible to chain-load Linux through OPTEE. Loading kernel to 0x8080 => run loadimage Load FDT to 0x8300 => run loadfdt Load OPTEE to 0x8400 => fatload mmc 0:5 0x8400 /lib/firmware/uTee.optee Then chain-load to the kernel via OPTEE => bootm 0x8400 - 0x8300 Image Name: Image Type: ARM Trusted Execution Environment Kernel Image (uncompressed) Data Size:249844 Bytes = 244 KiB Load Address: 9de4 Entry Point: 9e00 Verifying Checksum ... OK Loading Kernel Image ... OK Signed-off-by: Bryan O'Donoghue--- configs/warp7_secure_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/warp7_secure_defconfig b/configs/warp7_secure_defconfig index d1d2495..0d46aa7 100644 --- a/configs/warp7_secure_defconfig +++ b/configs/warp7_secure_defconfig @@ -43,3 +43,4 @@ CONFIG_USBNET_HOST_ADDR="de:ad:be:af:00:00" CONFIG_OF_LIBFDT=y CONFIG_OPTEE=y CONFIG_OPTEE_LOAD_ADDR=0x8400 +CONFIG_BOOTM_OPTEE=y -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 00/18] warp7: Enable automated OPTEE/HAB boot flow
This series enables an automated HAB verified secure boot which chain-loads via OPTEE see `git show 5cf3251..c225e7c` for details. This set depends on three in-flight patchsets 1. [PATCH v3 0/3] NXP WaARP7 set serial# from OTP fuses for USB iSerial Already has a Reviewed-by from Fabio 2. [PATCH v3 0/2] imx: hab: Add helper functions for scripted HAB auth Has a Reviewed-by: from Breno 3. [PATCH] configs: warp7: Fix CAAM on boot with tip-of-tree I'm trying not to make this cover email too long. So - once this set is applied it is possible to boot from the BootROM using HAB to verify - u-boot - boot.scr - Kernel - DTB Chainload via OPTEE and boot up to Linux. If there is a HAB failure at any stage of the process we force-drop down to the USB HID failover mode, from which we can send up a recovery image to unblock. I've run the WaRP7 default u-boot and this new version on NXP's reference yocto image and verified that that yocto image boots with both versions of the WaRP7 -> warp7_defconfig and warp7_secure_defconfig. http://freescale.github.io/#download -> BoardsWaRPboard community - WaRP - Wearable Reference PlatformFSL Community BSP 2.3fsl-image-multimediawayland In addition the modifications targeting warp7_secure_defconfig mean it is possible to chain-load via OPTEE using scripted HAB to verify images prior to exiting the u-boot domain. Here is an example of the scripting we are doing which shows further reuse of shell functions introduced in previous patches. Example secure-boot boot.scr.imx-signed # This section is responsbile for loading a signed Linux kernel setenv image_signed zImage.imx-signed if test ${hab_enabled} -eq 1; then setexpr hab_ivt_addr ${loadaddr} - ${ivt_offset} ${loadcmd} mmc ${mmcdev}:${mmcpart} ${hab_ivt_addr} ${image_signed} run warp7_auth_or_fail else run loadimage; fi # This section is responsbile for loading a signed FDT image setenv fdt_file_signed imx7s-warp.dtb.imx-signed if test ${hab_enabled} -eq 1; then setexpr hab_ivt_addr ${fdt_addr} - ${ivt_offset} ${loadcmd} mmc ${mmcdev}:${mmcpart} ${hab_ivt_addr} ${fdt_file_signed} run warp7_auth_or_fail else run loadfdt; fi # Set the filesystem type and partition target setenv loadcmd ext4load # Boot from rootfs1 by default setenv mmcpart 3 # But if the rootfs2 file exists in partition 2, boot from rootfs2 ext4size mmc 0:2 rootfs2 && setenv mmcpart 5 # This section is responsbile for loading a signed OPTEE image setenv optee_file /lib/firmware/uTee.optee setenv optee_file_signed /lib/firmware/uTee.optee.imx-signed setenv loadoptee "${loadcmd} mmc ${mmcdev}:${mmcpart} ${optee_addr} ${optee_file}" if test ${hab_enabled} -eq 1; then setexpr hab_ivt_addr ${optee_addr} - ${ivt_offset} ${loadcmd} mmc ${mmcdev}:${mmcpart} ${hab_ivt_addr} ${optee_file_signed} run warp7_auth_or_fail else run loadoptee; fi # Set UUID mmcpart will be used to pass root id to kernel setenv rootpart ${mmcpart} run finduuid; run mmcargs; # Now boot echo Booting secure Linux/OPTEE OS from mmc ...; bootm ${optee_addr} - ${fdt_addr}; # Failsafe if something goes wrong hab_failsafe Bryan O'Donoghue (18): imximage: Specify default IVT offset in IMX image warp7: hab: Add a CSF location definition warp7: hab: Set environment variable indicating HAB enable warp7: defconfig: Enable OPTEE for WaRP7 warp7: Allocate specific region of memory to OPTEE warp7: Print out the OPTEE DRAM region warp7: Specify CONFIG_OPTEE_LOAD_ADDR warp7: defconfig: Enable CONFIG_SECURE_BOOT warp7: defconfig: Enable CONFIG_BOOTM_TEE warp7: Make CONFIG_SYS_FDT_ADDR a define warp7: Add Kconfig WARP7_ROOT_PART warp7: select uuid partition based on rootpart warp7: Define the name of a signed boot-script file warp7: add warp7_auth_or_fail warp7: Make load command an environment variable warp7: hab: Set environment variable indicating IVT offset warp7_secure: defconfig: Enable CMD_SETEXPR warp7: Add support for automated secure boot.scr verification board/warp7/Kconfig| 14 ++ board/warp7/imximage.cfg | 4 board/warp7/warp7.c| 23 +++ configs/warp7_secure_defconfig | 6 +- include/configs/warp7.h| 29 - include/imximage.h | 3 +++ 6 files changed, 73 insertions(+), 6 deletions(-) -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 01/18] imximage: Specify default IVT offset in IMX image
This patch adds BOOTROM_IVT_HDR_OFFSET at 0xC00. The BootROM expects to find the IVT header at a particular offset in an i.MX image. Defining the expected offset of the IVT header in the first-stage BootROM image format is of use of later stage authentication routines where those routines continue to follow the first-stage authentication layout. This patch defines the first stage offset which later patch make use of. Signed-off-by: Bryan O'DonoghueCc: Utkarsh Gupta Cc: Breno Lima Cc: Fabio Estevam --- include/imximage.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/imximage.h b/include/imximage.h index 553b852..800fd63 100644 --- a/include/imximage.h +++ b/include/imximage.h @@ -14,6 +14,9 @@ #define APP_CODE_BARKER0xB1 #define DCD_BARKER 0xB17219E9 +/* Specify the offset of the IVT in the IMX header as expected by BootROM */ +#define BOOTROM_IVT_HDR_OFFSET 0xC00 + /* * NOTE: This file must be kept in sync with arch/arm/include/asm/\ * mach-imx/imximage.cfg because tools/imximage.c can not -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Please pull u-.boot-marvell/master
Hi Tom, please pull the first batch of Marvell related patches. Thanks, Stefan The following changes since commit 81cf7c8d45935a295991fe2cd1df286f0f47511f: Merge git://git.denx.de/u-boot-ubi (2018-03-25 12:02:13 -0400) are available in the Git repository at: git://www.denx.de/git/u-boot-marvell.git for you to fetch changes up to 25db371e17d64c7a50f0f75e77a675651e5a2d4c: arm64: a37xx: defconfigs: enable PCI_CMD and E1000 driver (2018-03-30 12:52:49 +0200) Alexander Graf (1): kwbimage: Fix out of bounds access Baruch Siach (1): configs: clearfog: enable random random MAC address Igal Liberman (1): dm: pcie: designware: add correct ATU handling Ken Ma (14): arm64: a37xx: dts: add gpio head file including arm64: a37xx: defconfig: Enable PINCTRL and GPIO support for ESPRESSOBin board arm64: a37xx: dts: Add pinctrl configuration for ESPRESSOBin board arm64: a37xx: dts: Add additional pinctrl definition arm64: a37xx: pinctrl: Fix number of pin in south bridge arm64: a37xx: dts: Fix the number of GPIO on south bridge arm64: a37xx: pinctrl: Fix the pin 23 on south bridge arm64: a37xx: pinctrl: Fix gpio pin offset in register arm64: a37xx: pinctrl: Correct mpp definitions arm64: a37xx: dts: Correct mpp definitions doc: a37xx: Introduce pinctrl device tree binding Revert "arm64: a37xx: dts: Add pin control nodes to DT" arm64: a37xx: remove old pinctrl implementation arm64: a37xx: defconfigs: enable PCI_CMD and E1000 driver Mark Kettenis (1): arm64: mvebu: a8k: Add distro boot support Wilson Ding (4): arm64: a37xx: populate pcie memory region arm64: a37xx: pci: add support for aardvark pcie driver arm64: a37xx: defconfigs: enable aardvark pcie driver arm64: a37xx: dts: enable pcie port arch/arm/dts/armada-3720-db.dts| 14 +- arch/arm/dts/armada-3720-espressobin.dts | 15 + arch/arm/dts/armada-37xx.dtsi | 52 +- arch/arm/mach-mvebu/armada3700/cpu.c | 8 + board/Marvell/mvebu_armada-37xx/board.c| 23 - configs/clearfog_defconfig | 1 + configs/mvebu_db-88f3720_defconfig | 5 + configs/mvebu_espressobin-88f3720_defconfig| 9 + .../pinctrl/marvell,armada-37xx-pinctrl.txt| 186 ++ drivers/pci/Kconfig| 10 + drivers/pci/Makefile | 1 + drivers/pci/pci-aardvark.c | 690 + drivers/pci/pcie_dw_mvebu.c| 91 ++- drivers/pinctrl/mvebu/pinctrl-armada-37xx.c| 52 +- include/configs/mvebu_armada-8k.h | 19 + tools/kwbimage.c | 4 + 16 files changed, 1088 insertions(+), 92 deletions(-) create mode 100644 doc/device-tree-bindings/pinctrl/marvell,armada-37xx-pinctrl.txt create mode 100644 drivers/pci/pci-aardvark.c ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] configs: clearfog: enable random random MAC address
On 19.02.2018 07:17, Baruch Siach wrote: This makes the network devices usable when booting a blank board over UART, with no pre-configured MAC address stored in the environment area. Signed-off-by: Baruch Siach--- configs/clearfog_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/clearfog_defconfig b/configs/clearfog_defconfig index a5ed3b20a63a..e2f1b635152f 100644 --- a/configs/clearfog_defconfig +++ b/configs/clearfog_defconfig @@ -30,6 +30,7 @@ CONFIG_CMD_CACHE=y CONFIG_CMD_TIME=y # CONFIG_SPL_PARTITION_UUIDS is not set CONFIG_ENV_IS_IN_MMC=y +CONFIG_NET_RANDOM_ETHADDR=y CONFIG_SPL_OF_TRANSLATE=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_SDMA=y Applied to u-boot-marvell/master. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] dm: pcie: designware: add correct ATU handling
On 14.02.2018 18:25, ig...@marvell.com wrote: From: Igal LibermanCurrently, ATU (address translation unit) implementation doesn't support translate addresses > 32 bits. This patch allows to configure ATU correctly for different memory accesses (memory, configuration and IO). The same approach is used in Linux Kernel. Signed-off-by: Igal Liberman --- drivers/pci/pcie_dw_mvebu.c | 91 + 1 file changed, 58 insertions(+), 33 deletions(-) diff --git a/drivers/pci/pcie_dw_mvebu.c b/drivers/pci/pcie_dw_mvebu.c index a198855..a0032b7 100644 --- a/drivers/pci/pcie_dw_mvebu.c +++ b/drivers/pci/pcie_dw_mvebu.c @@ -111,6 +111,10 @@ struct pcie_dw_mvebu { void *cfg_base; fdt_size_t cfg_size; int first_busno; + + /* IO and MEM PCI regions */ + struct pci_region io; + struct pci_region mem; }; static int pcie_dw_get_link_speed(const void *regs_base) @@ -126,6 +130,34 @@ static int pcie_dw_get_link_width(const void *regs_base) } /** + * pcie_dw_prog_outbound_atu() - Configure ATU for outbound accesses + * + * @pcie: Pointer to the PCI controller state + * @index: ATU region index + * @type: ATU accsess type + * @cpu_addr: the physical address for the translation entry + * @pci_addr: the pcie bus address for the translation entry + * @size: the size of the translation entry + */ +static void pcie_dw_prog_outbound_atu(struct pcie_dw_mvebu *pcie, int index, + int type, u64 cpu_addr, u64 pci_addr, + u32 size) +{ + writel(PCIE_ATU_REGION_OUTBOUND | index, + pcie->ctrl_base + PCIE_ATU_VIEWPORT); + writel(lower_32_bits(cpu_addr), pcie->ctrl_base + PCIE_ATU_LOWER_BASE); + writel(upper_32_bits(cpu_addr), pcie->ctrl_base + PCIE_ATU_UPPER_BASE); + writel(lower_32_bits(cpu_addr + size - 1), + pcie->ctrl_base + PCIE_ATU_LIMIT); + writel(lower_32_bits(pci_addr), + pcie->ctrl_base + PCIE_ATU_LOWER_TARGET); + writel(upper_32_bits(pci_addr), + pcie->ctrl_base + PCIE_ATU_UPPER_TARGET); + writel(type, pcie->ctrl_base + PCIE_ATU_CR1); + writel(PCIE_ATU_ENABLE, pcie->ctrl_base + PCIE_ATU_CR2); +} + +/** * set_cfg_address() - Configure the PCIe controller config space access * * @pcie: Pointer to the PCI controller state @@ -143,27 +175,29 @@ static uintptr_t set_cfg_address(struct pcie_dw_mvebu *pcie, pci_dev_t d, uint where) { uintptr_t va_address; + u32 atu_type; /* * Region #0 is used for Outbound CFG space access. * Direction = Outbound * Region Index = 0 */ - writel(0, pcie->ctrl_base + PCIE_ATU_VIEWPORT); if (PCI_BUS(d) == (pcie->first_busno + 1)) /* For local bus, change TLP Type field to 4. */ - writel(PCIE_ATU_TYPE_CFG0, pcie->ctrl_base + PCIE_ATU_CR1); + atu_type = PCIE_ATU_TYPE_CFG0; else /* Otherwise, change TLP Type field to 5. */ - writel(PCIE_ATU_TYPE_CFG1, pcie->ctrl_base + PCIE_ATU_CR1); + atu_type = PCIE_ATU_TYPE_CFG1; if (PCI_BUS(d) == pcie->first_busno) { /* Accessing root port configuration space. */ va_address = (uintptr_t)pcie->ctrl_base; } else { d = PCI_MASK_BUS(d) | (PCI_BUS(d) - pcie->first_busno); - writel(d << 8, pcie->ctrl_base + PCIE_ATU_LOWER_TARGET); + pcie_dw_prog_outbound_atu(pcie, PCIE_ATU_REGION_INDEX0, + atu_type, (u64)pcie->cfg_base, + d << 8, pcie->cfg_size); va_address = (uintptr_t)pcie->cfg_base; } @@ -231,6 +265,10 @@ static int pcie_dw_mvebu_read_config(struct udevice *bus, pci_dev_t bdf, debug("(addr,val)=(0x%04x, 0x%08lx)\n", offset, value); *valuep = pci_conv_32_to_size(value, offset, size); + pcie_dw_prog_outbound_atu(pcie, PCIE_ATU_REGION_INDEX0, + PCIE_ATU_TYPE_IO, pcie->io.phys_start, + pcie->io.bus_start, pcie->io.size); + return 0; } @@ -272,6 +310,10 @@ static int pcie_dw_mvebu_write_config(struct udevice *bus, pci_dev_t bdf, value = pci_conv_size_to_32(old, value, offset, size); writel(value, va_address); + pcie_dw_prog_outbound_atu(pcie, PCIE_ATU_REGION_INDEX0, + PCIE_ATU_TYPE_IO, pcie->io.phys_start, + pcie->io.bus_start, pcie->io.size); + return 0; } @@ -388,34 +430,6 @@ static int pcie_dw_mvebu_pcie_link_up(const void *regs_base, u32 cap_speed) } /** - * pcie_dw_regions_setup() - iATU region setup - * - * @pcie: Pointer to the PCI controller state - * - *
Re: [U-Boot] [PATCH] arm64: mvebu: a8k: Add distro boot support
On 17.03.2018 09:34, Mark Kettenis wrote: The various load address values are taken from the a37xx configuration and match the dowstream 'u-boot-2017.03-armada-17.10' release where appropriate. Signed-off-by: Mark Kettenis--- include/configs/mvebu_armada-8k.h | 19 +++ 1 file changed, 19 insertions(+) diff --git a/include/configs/mvebu_armada-8k.h b/include/configs/mvebu_armada-8k.h index f288cf5b17..1cd0fa93d3 100644 --- a/include/configs/mvebu_armada-8k.h +++ b/include/configs/mvebu_armada-8k.h @@ -106,4 +106,23 @@ #define CONFIG_E1000 #endif +#define BOOT_TARGET_DEVICES(func) \ + func(MMC, mmc, 1) \ + func(MMC, mmc, 0) \ + func(USB, usb, 0) \ + func(SCSI, scsi, 0) \ + func(PXE, pxe, na) \ + func(DHCP, dhcp, na) + +#include + +#define CONFIG_EXTRA_ENV_SETTINGS \ + "scriptaddr=0x4d0\0" \ + "pxefile_addr_r=0x4e0\0" \ + "fdt_addr_r=0x4f0\0" \ + "kernel_addr_r=0x500\0" \ + "ramdisk_addr_r=0x800\0" \ + "fdtfile=marvell/" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \ + BOOTENV + #endif /* _CONFIG_MVEBU_ARMADA_8K_H */ Applied to u-boot-marvell/master. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] kwbimage: Fix out of bounds access
On 15.03.2018 11:14, Alexander Graf wrote: The kwbimage format is reading beyond its header structure if it misdetects a Xilinx Zynq image and tries to read it. Fix it by sanity checking that the header we want to read fits inside our file size. Signed-off-by: Alexander Graf--- tools/kwbimage.c | 4 1 file changed, 4 insertions(+) diff --git a/tools/kwbimage.c b/tools/kwbimage.c index 3ca3b3b4a6..26686ad30f 100644 --- a/tools/kwbimage.c +++ b/tools/kwbimage.c @@ -1616,6 +1616,10 @@ static int kwbimage_verify_header(unsigned char *ptr, int image_size, struct image_tool_params *params) { uint8_t checksum; + size_t header_size = kwbimage_header_size(ptr); + + if (header_size > image_size) + return -FDT_ERR_BADSTRUCTURE; if (!main_hdr_checksum_ok(ptr)) return -FDT_ERR_BADSTRUCTURE; Applied to u-boot-marvell/master. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] arm64: a37xx: populate pcie memory region
On 26.03.2018 09:57, m...@marvell.com wrote: From: Wilson DingThis patch added a new region of 32MiB AT 0xe800. to Armada37x0's memory map. This region is supposed to be mapped in MMU in order to enable the access to the PCI I/O or MEM resources. Signed-off-by: Wilson Ding Reviewed-on: http://vgitil04.il.marvell.com:8080/38724 Tested-by: iSoC Platform CI Reviewed-by: Victor Gu Signed-off-by: Ken Ma Cc: Simon Glass Cc: Stefan Roese --- arch/arm/mach-mvebu/armada3700/cpu.c | 8 1 file changed, 8 insertions(+) diff --git a/arch/arm/mach-mvebu/armada3700/cpu.c b/arch/arm/mach-mvebu/armada3700/cpu.c index 6499eec..cfe4469 100644 --- a/arch/arm/mach-mvebu/armada3700/cpu.c +++ b/arch/arm/mach-mvebu/armada3700/cpu.c @@ -46,6 +46,14 @@ static struct mm_region mvebu_mem_map[] = { PTE_BLOCK_NON_SHARE }, { + /* PCI regions */ + .phys = 0xe800UL, + .virt = 0xe800UL, + .size = 0x0200UL, /* 32MiB master PCI space */ + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) | +PTE_BLOCK_NON_SHARE + }, + { /* List terminator */ 0, } Complete series applied to u-boot-marvell/master. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 01/13] arm64: a37xx: dts: add gpio head file including
On 26.03.2018 09:55, m...@marvell.com wrote: From: Ken MaCc: Simon Glass Cc: Stefan Roese Signed-off-by: Ken Ma --- arch/arm/dts/armada-37xx.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/dts/armada-37xx.dtsi b/arch/arm/dts/armada-37xx.dtsi index 6902342..75a22de 100644 --- a/arch/arm/dts/armada-37xx.dtsi +++ b/arch/arm/dts/armada-37xx.dtsi @@ -46,6 +46,7 @@ #include #include +#include / { model = "Marvell Armada 37xx SoC"; Complete series applied to u-boot-marvell/master. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [uboot-snps-arc] [PATCH v2 0/2] SF: add support for sst26wf016, sst26wf032, sst26wf064
Hi Jagan, On Mon, 2018-03-26 at 14:08 +0300, Eugeniy Paltsev wrote: > Add support for the SST sst26wf016, sst26wf032 and sst26wf064 flash IC: > > sst26wf*** flash series block protection implementation differs from other > SST series, so we add implementation for sst26wf*** lock/unlock/is_locked > functions. > > Add sst26wf016, sst26wf032 and sst26wf064 flash IC info to spi_flash_ids list. > > > Changes v1->v2: > * Use generic defines from linux/sizes.h instead of custom ones. > > Eugeniy Paltsev (2): > SPI Flash: add support of sst26wf* flash series > SF: add support for sst26wf016, sst26wf032, sst26wf064 > > drivers/mtd/spi/spi_flash.c | 188 > > drivers/mtd/spi/spi_flash_ids.c | 3 + > 2 files changed, 191 insertions(+) Any chance for this series to hit your's and then Tom's repos before RC1 gets cut on Monday April 2nd? -Alexey ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] configs: warp7: Fix CAAM on boot with tip-of-tree
Booting the following image with tip-of-tree we get a CAAM DECO error (and subsequent crash due to a kernel bug in 4.1). http://freescale.github.io/#download -> BoardsWaRPboard community - WaRP - Wearable Reference PlatformFSL Community BSP 2.3fsl-image-multimediawayland Image: fsl-image-multimedia-imx7s-warp-20180323-90.rootfs.sdcard Error: caam 3090.caam: Entropy delay = 3200 caam 3090.caam: failed to acquire DECO 0 caam 3090.caam: failed to acquire DECO 0 caam 3090.caam: Entropy delay = 12400 caam 3090.caam: failed to acquire DECO 0 caam 3090.caam: failed to instantiate RNG [ cut here ] WARNING: CPU: 0 PID: 1 at /home/jenkins/workspace/fsl-community-bsp-pyro_xwayland_2/build/tmp/work-shared/imx7s-warp/kernel-source/mm/vmalloc.c:1465 caam_remove+0x6) Trying to vfree() nonexistent vm area (88047000) Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.1.36-4.1-1.0.x-imx-warp7+ga543d1b #1 Hardware name: Freescale i.MX7 Dual (Device Tree) [<80015d54>] (unwind_backtrace) from [<80012688>] (show_stack+0x10/0x14) [<80012688>] (show_stack) from [<8076e810>] (dump_stack+0x78/0x8c) [<8076e810>] (dump_stack) from [<800346a0>] (warn_slowpath_common+0x80/0xb0) [<800346a0>] (warn_slowpath_common) from [<80034700>] (warn_slowpath_fmt+0x30/0x40) [<80034700>] (warn_slowpath_fmt) from [<8054c278>] (caam_remove+0x6c/0x3f4) [<8054c278>] (caam_remove) from [<8054ce74>] (caam_probe+0x874/0xfa8) [<8054ce74>] (caam_probe) from [<80382a7c>] (platform_drv_probe+0x48/0xa4) [<80382a7c>] (platform_drv_probe) from [<80381328>] (driver_probe_device+0x174/0x2a8) [<80381328>] (driver_probe_device) from [<8038152c>] (__driver_attach+0x8c/0x90) [<8038152c>] (__driver_attach) from [<8037f9d4>] (bus_for_each_dev+0x68/0x9c) [<8037f9d4>] (bus_for_each_dev) from [<80380a68>] (bus_add_driver+0xf4/0x1e8) [<80380a68>] (bus_add_driver) from [<80381b38>] (driver_register+0x78/0xf4) [<80381b38>] (driver_register) from [<80009738>] (do_one_initcall+0x8c/0x1d0) [<80009738>] (do_one_initcall) from [<80a66dac>] (kernel_init_freeable+0x140/0x1d0) [<80a66dac>] (kernel_init_freeable) from [<8076aa38>] (kernel_init+0x8/0xe8) [<8076aa38>] (kernel_init) from [<8000f468>] (ret_from_fork+0x14/0x2c) ---[ end trace d5f941204ed8cb28 ]--- caam: probe of 3090.caam failed with error -11 Unable to handle kernel NULL pointer dereference at virtual address 0004 pgd = 80004000 [0004] *pgd= Internal error: Oops: 805 [#1] PREEMPT SMP ARM [<8055cdf8>] (caam_sm_startup) from [<80aa83c8>] (caam_sm_init+0x50/0x58) [<80aa83c8>] (caam_sm_init) from [<80009738>] (do_one_initcall+0x8c/0x1d0) [<80009738>] (do_one_initcall) from [<80a66dac>] (kernel_init_freeable+0x140/0x1d0) [<80a66dac>] (kernel_init_freeable) from [<8076aa38>] (kernel_init+0x8/0xe8) [<8076aa38>] (kernel_init) from [<8000f468>] (ret_from_fork+0x14/0x2c) Code: e59d300c e2832010 e5843008 e5834068 (e58a2004) ---[ end trace d5f941204ed8cb29 ]--- Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b Fix: Enable the CAAM correctly by setting CONFIG_ARMV7_BOOT_SEC_DEFAULT=y in the upstream defconfig. Signed-off-by: Bryan O'DonoghueCc: Fabio Estevam Cc: Breno Lima --- configs/warp7_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/warp7_defconfig b/configs/warp7_defconfig index 29c4512..228f7d9 100644 --- a/configs/warp7_defconfig +++ b/configs/warp7_defconfig @@ -2,6 +2,7 @@ CONFIG_ARM=y CONFIG_ARCH_MX7=y CONFIG_SYS_TEXT_BASE=0x8780 CONFIG_TARGET_WARP7=y +CONFIG_ARMV7_BOOT_SEC_DEFAULT=y # CONFIG_ARMV7_VIRT is not set CONFIG_IMX_RDC=y CONFIG_IMX_BOOTAUX=y -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] timer: add High Precision Event Timers (HPET) support
Hi Ivan, On Fri, Mar 30, 2018 at 6:29 AM, Ivan Gorinovwrote: > Adding HPET as an alternative timer for x86 (default is TSC). > HPET counter has constant frequency and does not need calibration. > This change also makes TSC timer driver optional on x86. > If X86_TSC is disabled, early timer functions are provided by HPET. > > Signed-off-by: Ivan Gorinov > --- > arch/Kconfig | 2 +- > arch/x86/dts/hpet.dtsi | 7 ++ > drivers/timer/Kconfig | 6 ++ > drivers/timer/Makefile | 1 + > drivers/timer/hpet_timer.c | 191 > + > 5 files changed, 206 insertions(+), 1 deletion(-) > create mode 100644 arch/x86/dts/hpet.dtsi > create mode 100644 drivers/timer/hpet_timer.c > > diff --git a/arch/Kconfig b/arch/Kconfig > index e599e7a..37dabae 100644 > --- a/arch/Kconfig > +++ b/arch/Kconfig > @@ -104,7 +104,7 @@ config X86 > select DM_PCI > select PCI > select TIMER > - select X86_TSC_TIMER > + imply X86_TSC_TIMER > imply BLK > imply DM_ETH > imply DM_GPIO > diff --git a/arch/x86/dts/hpet.dtsi b/arch/x86/dts/hpet.dtsi > new file mode 100644 > index 000..037dc7e > --- /dev/null > +++ b/arch/x86/dts/hpet.dtsi > @@ -0,0 +1,7 @@ > +/ { > + hpet0: hpet@fed0 { nits: use 'hpet' instead of 'hpet0'? since there is only one hpet timer in the system. > + compatible = "hpet-x86"; > + u-boot,dm-pre-reloc; > + reg = <0xfed0 0x1000>; > + }; > +}; > diff --git a/drivers/timer/Kconfig b/drivers/timer/Kconfig > index 2c96896..72ae6c5 100644 > --- a/drivers/timer/Kconfig > +++ b/drivers/timer/Kconfig > @@ -65,6 +65,12 @@ config X86_TSC_TIMER > help > Select this to enable Time-Stamp Counter (TSC) timer for x86. > > +config HPET_TIMER > + bool "High Precision Event Timers (HPET) support" > + depends on TIMER && X86 > + help > + Select this to enable High Precision Event Timers (HPET) for x86. > + > config OMAP_TIMER > bool "Omap timer support" > depends on TIMER > diff --git a/drivers/timer/Makefile b/drivers/timer/Makefile > index a6e7832..557fecc 100644 > --- a/drivers/timer/Makefile > +++ b/drivers/timer/Makefile > @@ -8,6 +8,7 @@ obj-y += timer-uclass.o > obj-$(CONFIG_ALTERA_TIMER) += altera_timer.o > obj-$(CONFIG_SANDBOX_TIMER)+= sandbox_timer.o > obj-$(CONFIG_X86_TSC_TIMER)+= tsc_timer.o > +obj-$(CONFIG_HPET_TIMER) += hpet_timer.o > obj-$(CONFIG_OMAP_TIMER) += omap-timer.o > obj-$(CONFIG_AST_TIMER)+= ast_timer.o > obj-$(CONFIG_STI_TIMER)+= sti-timer.o > diff --git a/drivers/timer/hpet_timer.c b/drivers/timer/hpet_timer.c > new file mode 100644 > index 000..0bef859 > --- /dev/null > +++ b/drivers/timer/hpet_timer.c > @@ -0,0 +1,191 @@ > +/* > + * Copyright (c) 2017 Intel Corporation > + * > + * SPDX-License-Identifier:GPL-2.0+ > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define HPET_PERIOD_REG 0x004 > +#define HPET_CONFIG_REG 0x010 > +#define HPET_MAIN_COUNT_L 0x0f0 > +#define HPET_MAIN_COUNT_H 0x0f4 > + > +#define HPET_MAX_PERIOD 1 > + > +DECLARE_GLOBAL_DATA_PTR; This is not needed. > + > +struct hpet_timer_priv { > + void *regs; > +}; > + > +/* > + * Returns HPET clock frequency in HZ > + * (rounding to the nearest integer), > + * or 0 if HPET is not available. > + */ > +static inline u32 get_clock_frequency(void *regs) > +{ > + u64 d = 1000ull; > + u32 period; > + > + period = readl(regs + HPET_PERIOD_REG); > + if (period == 0) > + return 0; > + if (period > HPET_MAX_PERIOD) > + return 0; > + > + d += period / 2; > + > + return d / period; > +} > + > +/* > + * Reset and start the main counter. > + */ nits: use one line comment format > +static void start_main_counter(void *regs) > +{ > + u32 config; > + > + config = readl(regs + HPET_CONFIG_REG); > + config &= ~1; > + writel(config, regs + HPET_CONFIG_REG); > + writel(0, regs + HPET_MAIN_COUNT_L); > + writel(0, regs + HPET_MAIN_COUNT_H); > + config |= 1; > + writel(config, regs + HPET_CONFIG_REG); > +} > + > +/* > + * Read the main counter as two 32-bit registers, > + * repeat if rollover happens. > + */ > +static u64 read_main_counter(void *regs) > +{ > + u64 now_tick; > + u32 tl, th, th0; > + > + th = readl(regs + HPET_MAIN_COUNT_H); > + do { > + th0 = th; > + tl = readl(regs + HPET_MAIN_COUNT_L); > + th = readl(regs + HPET_MAIN_COUNT_H); > + } while (th != th0); > + > + now_tick = th; > + now_tick <<= 32; > + now_tick |= tl; > + > + return now_tick; > +} > + > +static int hpet_timer_get_count(struct
[U-Boot] [PATCH u-boot] clk: Add get/enable/disable/release for a bulk of clocks
This patch adds a "bulk" API to the clock API in order to get/enable/disable /release a group of clocks associated with a device. This bulk API will avoid adding a copy of the same code to manage a group of clocks in drivers. Signed-off-by: Neil Armstrong--- This serie and the "reset bulk" serie is necessary and suggested by Marek Vasut for the "Add USB Support for Amlogic Meson GXL SoCs" to avoid adding the same code to manage a bulk of clocks and resets in another driver. I will push a RFC code to update the other drivers having a similar code pattern when these patches are merged. drivers/clk/clk-uclass.c | 59 +++ include/clk.h| 72 +++- 2 files changed, 130 insertions(+), 1 deletion(-) diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c index ad76379..6e99b3b 100644 --- a/drivers/clk/clk-uclass.c +++ b/drivers/clk/clk-uclass.c @@ -104,6 +104,39 @@ int clk_get_by_index(struct udevice *dev, int index, struct clk *clk) return clk_get_by_indexed_prop(dev, "clocks", index, clk); } +int clk_get_bulk(struct udevice *dev, struct clk_bulk *bulk) +{ + int i, ret, err, count; + + bulk->count = 0; + + count = dev_count_phandle_with_args(dev, "clocks", "#clock-cells"); + if (!count) + return 0; + + bulk->clks = devm_kcalloc(dev, count, sizeof(struct clk), GFP_KERNEL); + if (!bulk->clks) + return -ENOMEM; + + for (i = 0; i < count; i++) { + ret = clk_get_by_index(dev, i, >clks[i]); + if (ret < 0) + goto bulk_get_err; + + ++bulk->count; + } + + return 0; + +bulk_get_err: + err = clk_release_all(bulk->clks, bulk->count); + if (err) + debug("%s: could release all clocks for %p\n", + __func__, dev); + + return ret; +} + static int clk_set_default_parents(struct udevice *dev) { struct clk clk, parent_clk; @@ -336,6 +369,19 @@ int clk_enable(struct clk *clk) return ops->enable(clk); } +int clk_enable_bulk(struct clk_bulk *bulk) +{ + int i, ret; + + for (i = 0; i < bulk->count; i++) { + ret = clk_enable(>clks[i]); + if (ret < 0 && ret != -ENOSYS) + return ret; + } + + return 0; +} + int clk_disable(struct clk *clk) { const struct clk_ops *ops = clk_dev_ops(clk->dev); @@ -348,6 +394,19 @@ int clk_disable(struct clk *clk) return ops->disable(clk); } +int clk_disable_bulk(struct clk_bulk *bulk) +{ + int i, ret; + + for (i = 0; i < bulk->count; i++) { + ret = clk_disable(>clks[i]); + if (ret < 0 && ret != -ENOSYS) + return ret; + } + + return 0; +} + UCLASS_DRIVER(clk) = { .id = UCLASS_CLK, .name = "clk", diff --git a/include/clk.h b/include/clk.h index a7d95d3..b3a9fce 100644 --- a/include/clk.h +++ b/include/clk.h @@ -60,6 +60,23 @@ struct clk { unsigned long id; }; +/** + * struct clk_bulk - A handle to (allowing control of) a bulk of clocks. + * + * Clients provide storage for the clock bulk. The content of the structure is + * managed solely by the clock API. A clock bulk struct is + * initialized by "get"ing the clock bulk struct. + * The clock bulk struct is passed to all other bulk clock APIs to apply + * the API to all the clock in the bulk struct. + * + * @clks: An array of clock handles. + * @count: The number of clock handles in the clks array. + */ +struct clk_bulk { + struct clk *clks; + unsigned int count; +}; + #if CONFIG_IS_ENABLED(OF_CONTROL) && CONFIG_IS_ENABLED(CLK) struct phandle_1_arg; int clk_get_by_index_platdata(struct udevice *dev, int index, @@ -83,6 +100,21 @@ int clk_get_by_index_platdata(struct udevice *dev, int index, int clk_get_by_index(struct udevice *dev, int index, struct clk *clk); /** + * clock_get_bulk - Get/request all clocks of a device. + * + * This looks up and requests all clocks of the client device; each device is + * assumed to have n clocks associated with it somehow, and this function finds + * and requests all of them in a separate structure. The mapping of client + * device clock indices to provider clocks may be via device-tree properties, + * board-provided mapping tables, or some other mechanism. + * + * @dev: The client device. + * @bulk A pointer to a clock bulk struct to initialize. + * @return 0 if OK, or a negative error code. + */ +int clk_get_bulk(struct udevice *dev, struct clk_bulk *bulk); + +/** * clock_get_by_name - Get/request a clock by name. * * This looks up and requests a clock. The name is relative to the client @@ -120,6 +152,11 @@ static inline int clk_get_by_index(struct udevice *dev, int index, return -ENOSYS; } +static
[U-Boot] [PATCH u-boot] reset: Add get/assert/deassert/release for bulk of reset signals
This patch adds a "bulk" API to the reset API in order to get/deassert/ assert/release a group of reset signals associated with a device. This bulk API will avoid adding a copy of the same code to manage a group of reset signals in drivers. Signed-off-by: Neil Armstrong--- This serie and the "clk bulk" serie is necessary and suggested by Marek Vasut for the "Add USB Support for Amlogic Meson GXL SoCs" to avoid adding the same code to manage a bulk of clocks and resets in another driver. I will push a RFC code to update the other drivers having a similar code pattern when these patches are merged. drivers/reset/reset-uclass.c | 60 +++ include/reset.h | 99 2 files changed, 159 insertions(+) diff --git a/drivers/reset/reset-uclass.c b/drivers/reset/reset-uclass.c index 307a297..9a5c9c9 100644 --- a/drivers/reset/reset-uclass.c +++ b/drivers/reset/reset-uclass.c @@ -81,6 +81,40 @@ int reset_get_by_index(struct udevice *dev, int index, return 0; } +int reset_get_bulk(struct udevice *dev, struct reset_ctl_bulk *bulk) +{ + int i, ret, err, count; + + bulk->count = 0; + + count = dev_count_phandle_with_args(dev, "resets", "#reset-cells"); + if (!count) + return 0; + + bulk->resets = devm_kcalloc(dev, count, sizeof(struct reset_ctl), + GFP_KERNEL); + if (!bulk->resets) + return -ENOMEM; + + for (i = 0; i < count; i++) { + ret = reset_get_by_index(dev, i, >resets[i]); + if (ret < 0) + goto bulk_get_err; + + ++bulk->count; + } + + return 0; + +bulk_get_err: + err = reset_release_all(bulk->resets, bulk->count); + if (err) + debug("%s: could release all resets for %p\n", + __func__, dev); + + return ret; +} + int reset_get_by_name(struct udevice *dev, const char *name, struct reset_ctl *reset_ctl) { @@ -126,6 +160,19 @@ int reset_assert(struct reset_ctl *reset_ctl) return ops->rst_assert(reset_ctl); } +int reset_assert_bulk(struct reset_ctl_bulk *bulk) +{ + int i, ret; + + for (i = 0; i < bulk->count; i++) { + ret = reset_assert(>resets[i]); + if (ret < 0) + return ret; + } + + return 0; +} + int reset_deassert(struct reset_ctl *reset_ctl) { struct reset_ops *ops = reset_dev_ops(reset_ctl->dev); @@ -135,6 +182,19 @@ int reset_deassert(struct reset_ctl *reset_ctl) return ops->rst_deassert(reset_ctl); } +int reset_deassert_bulk(struct reset_ctl_bulk *bulk) +{ + int i, ret; + + for (i = 0; i < bulk->count; i++) { + ret = reset_deassert(>resets[i]); + if (ret < 0) + return ret; + } + + return 0; +} + int reset_release_all(struct reset_ctl *reset_ctl, int count) { int i, ret; diff --git a/include/reset.h b/include/reset.h index 7185ade..d38f176 100644 --- a/include/reset.h +++ b/include/reset.h @@ -60,6 +60,24 @@ struct reset_ctl { unsigned long id; }; +/** + * struct reset_ctl_bulk - A handle to (allowing control of) a bulk of reset + * signals. + * + * Clients provide storage for the reset control bulk. The content of the + * structure is managed solely by the reset API. A reset control bulk struct is + * initialized by "get"ing the reset control bulk struct. + * The reset control bulk struct is passed to all other bulk reset APIs to apply + * the API to all the reset signals in the bulk struct. + * + * @resets: An array of reset signal handles handles. + * @count: The number of reset signal handles in the reset array. + */ +struct reset_ctl_bulk { + struct reset_ctl *resets; + unsigned int count; +}; + #ifdef CONFIG_DM_RESET /** * reset_get_by_index - Get/request a reset signal by integer index. @@ -81,6 +99,22 @@ int reset_get_by_index(struct udevice *dev, int index, struct reset_ctl *reset_ctl); /** + * reset_get_bulk - Get/request all reset signals of a device. + * + * This looks up and requests all reset signals of the client device; each + * device is assumed to have n reset signals associated with it somehow, + * and this function finds and requests all of them in a separate structure. + * The mapping of client device reset signals indices to provider reset signals + * may be via device-tree properties, board-provided mapping tables, or some + * other mechanism. + * + * @dev: The client device. + * @bulk A pointer to a reset control bulk struct to initialize. + * @return 0 if OK, or a negative error code. + */ +int reset_get_bulk(struct udevice *dev, struct reset_ctl_bulk *bulk); + +/** * reset_get_by_name - Get/request a reset signal by name. * * This looks up and requests a
Re: [U-Boot] [PATCH] mkimage: do not fail if there is no print_header function
> On 30 Mar 2018, at 10:28, Guillaume GARDETwrote: > > Commit 253c60a breaks the exit value of 'mkimage -T rkimage' > and print the following error: > mkimage: Can't print header for Rockchip Boot Image support: Success > > It is not a failure to not print headers, so just display the warning message, > and finish the function properly. > > Signed-off-by: Guillaume GARDET Reviewed-by: Philipp Tomsich > Cc: Philipp Tomsich > Cc: Simon Glass > Cc: Tom Rini > --- > tools/mkimage.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/tools/mkimage.c b/tools/mkimage.c > index 28ff35e670..4e561820e7 100644 > --- a/tools/mkimage.c > +++ b/tools/mkimage.c > @@ -588,9 +588,8 @@ int main(int argc, char **argv) > if (tparams->print_header) > tparams->print_header (ptr); > else { > - fprintf (stderr, "%s: Can't print header for %s: %s\n", > - params.cmdname, tparams->name, strerror(errno)); > - exit (EXIT_FAILURE); > + fprintf (stderr, "%s: Can't print header for %s\n", > + params.cmdname, tparams->name); > } > > (void) munmap((void *)ptr, sbuf.st_size); > -- > 2.13.6 > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/8] cpu: Add cpu_print_info function
Hi, On 28 March 2018 at 20:38, Mario Sixwrote: > Add a cpu_print_info function to the CPU uclass to emulate the behavior > of some current non-DM drivers (e.g. MPC83xx) to print CPU information > during startup. > > Signed-off-by: Mario Six > --- > drivers/cpu/cpu-uclass.c | 10 ++ > include/cpu.h| 15 +++ > 2 files changed, 25 insertions(+) > I really don't want drivers printing stuff. Can you use the existing get_info() method? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/7] axi: Add AXI sandbox driver and simple emulator
Hi Mario, On 28 March 2018 at 20:40, Mario Sixwrote: > Add test infrastructure and tests for the AXI uclass. > > Signed-off-by: Mario Six > --- > drivers/axi/Kconfig | 6 +++ > drivers/axi/Makefile | 3 ++ > drivers/axi/axi-emul-uclass.c | 68 > drivers/axi/axi_sandbox.c | 61 ++ > drivers/axi/sandbox_store.c | 118 > ++ > include/axi.h | 51 ++ > include/dm/uclass-id.h| 1 + > 7 files changed, 308 insertions(+) > create mode 100644 drivers/axi/axi-emul-uclass.c > create mode 100644 drivers/axi/axi_sandbox.c > create mode 100644 drivers/axi/sandbox_store.c > > diff --git a/drivers/axi/Kconfig b/drivers/axi/Kconfig > index 19e1b7fd2f..a0333782cf 100644 > --- a/drivers/axi/Kconfig > +++ b/drivers/axi/Kconfig > @@ -21,4 +21,10 @@ config IHS_AXI > Support for IHS AXI bus on a gdsys IHS FPGA used to communicate with > IP cores in the FPGA (e.g. video transmitter cores). > > +config AXI_SANDBOX > + bool "Enable AXI sandbox driver" > + depends on DM > + help > + Support the AXI emulation for the sandbox environment. Please spell out abbreviations > + > endif > diff --git a/drivers/axi/Makefile b/drivers/axi/Makefile > index 18d9380e9b..66b6c5a28f 100644 > --- a/drivers/axi/Makefile > +++ b/drivers/axi/Makefile > @@ -7,3 +7,6 @@ > > obj-$(CONFIG_AXI) += axi-uclass.o > obj-$(CONFIG_IHS_AXI) += ihs_axi.o > +obj-$(CONFIG_SANDBOX) += axi-emul-uclass.o > +obj-$(CONFIG_SANDBOX) += sandbox_store.o > +obj-$(CONFIG_AXI_SANDBOX) += axi_sandbox.o > diff --git a/drivers/axi/axi-emul-uclass.c b/drivers/axi/axi-emul-uclass.c > new file mode 100644 > index 00..bf60c40518 > --- /dev/null > +++ b/drivers/axi/axi-emul-uclass.c > @@ -0,0 +1,68 @@ > +/* > + * (C) Copyright 2018 > + * Mario Six, Guntermann & Drunck GmbH, mario@gdsys.cc > + * > + * SPDX-License-Identifier:GPL-2.0+ > + */ > + > +#include > +#include > +#include > +#include > + > +int axi_sandbox_get_emul(struct udevice *bus, ulong address, enum axi_size_t > size, > +struct udevice **emulp) > +{ > + struct udevice *dev; > + u32 reg[2]; > + uint offset; > + > + switch (size) { > + case AXI_SIZE_8: > + offset = 1; > + break; > + case AXI_SIZE_16: > + offset = 2; > + break; > + case AXI_SIZE_32: > + offset = 4; > + break; > + default: > + offset = 0; > + } > + > + for (device_find_first_child(bus, ); > +dev; > +device_find_next_child()) { > + int ret; > + > + ret = dev_read_u32_array(dev, "reg", reg, ARRAY_SIZE(reg)); > + if (ret) > + continue; > + > + if (address >= reg[0] && address <= reg[0] + reg[1] - offset) > { > + if (device_probe(dev)) > + return -ENODEV; > + > + *emulp = dev; > + return 0; > + } > + } > + > + return -ENODEV; > +} > + > +int axi_get_store(struct udevice *dev, u8 **store) > +{ > + struct axi_emul_ops *ops = axi_emul_get_ops(dev); > + > + if (!ops->get_store) > + return -ENOSYS; > + > + return ops->get_store(dev, store); > +} > + > +UCLASS_DRIVER(axi_emul) = { > + .id = UCLASS_AXI_EMUL, > + .name = "axi_emul", > +}; > diff --git a/drivers/axi/axi_sandbox.c b/drivers/axi/axi_sandbox.c > new file mode 100644 > index 00..b0f24bdd9d > --- /dev/null > +++ b/drivers/axi/axi_sandbox.c > @@ -0,0 +1,61 @@ > +/* > + * (C) Copyright 2018 > + * Mario Six, Guntermann & Drunck GmbH, mario@gdsys.cc > + * > + * SPDX-License-Identifier:GPL-2.0+ > + */ > + > +#include > +#include > +#include > + > +int axi_sandbox_read(struct udevice *bus, ulong address, void *data, > +enum axi_size_t size) > +{ > + struct axi_emul_ops *ops; > + struct udevice *emul; > + int ret; > + > + ret = axi_sandbox_get_emul(bus, address, size, ); > + if (ret) > + return ret == -ENODEV ? 0 : ret; Please add a comment as to why you are doing this. > + ops = axi_emul_get_ops(emul); > + if (!ops || !ops->read) > + return -ENOSYS; > + > + return ops->read(emul, address, data, size); > +} > + > +int axi_sandbox_write(struct udevice *bus, ulong address, void *data, > + enum axi_size_t size) > +{ > + struct axi_emul_ops *ops; > + struct udevice *emul; > + int ret; > + > + ret = axi_sandbox_get_emul(bus, address, size, ); > + if (ret) > + return ret == -ENODEV ? 0 : ret; > + ops =
Re: [U-Boot] [PATCH 1/1] log: fix typo LOGL_EFI
On 24 March 2018 at 04:12, Heinrich Schuchardtwrote: > According to the documentation the EFI log category is called LOGC_EFI. > All other categories start with LOGC_. So let's fix it. > > Fixes: 1973b381a1b3 ("log: add category LOGC_EFI") > Signed-off-by: Heinrich Schuchardt > --- > include/log.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/7] sandbox: Add and build AXI bus and device
On 28 March 2018 at 20:40, Mario Sixwrote: > Add test AXI drivers to the sandbox. > > Signed-off-by: Mario Six > --- > arch/sandbox/dts/sandbox.dts | 11 +++ > arch/sandbox/dts/test.dts| 11 +++ > configs/sandbox_defconfig| 3 +++ > 3 files changed, 25 insertions(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC] net: eth_write_hwaddr hides ENOSYS
Hi Heinrich, On 24 March 2018 at 21:41, Heinrich Schuchardtwrote: > Hello Simon, > > in patch > db9391e165dd ("net: Move driver-model code into its own file") > function eth_write_hwaddr hides() you chose to introduce the follwing lines: > > static int eth_write_hwaddr(struct udevice *dev) > ... > /* > * Drivers are allowed to decide not to implement this at > * run-time. E.g. Some devices may use it and some may not. > */ > ret = eth_get_ops(dev)->write_hwaddr(dev); > if (ret == -ENOSYS) > ret = 0; > > For implementing efi_net_station_address() it would be preferable if the > function would return -ENOSYS to signal that changing the MAC address > failed. Actually -ENOSYS if the method is not implemented, and -ENXIO or something if the write failed. There is a clear distinction between: * -ENOSYS the method is not implemented (so you might choose to not worry about the error) * -Esomething_else - the method is implemented, but failed (so you probably want to return an error) > > I could not find any caller of the driver model version of > eth_write_hwaddr(). Do you remember why you made this choice? > > Best regards > > Heinrich Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] env: Properly check for BLK support
On 23 March 2018 at 05:53, Sjoerd Simonswrote: > Use CONFIG_IS_ENABLED to see if CONFIG_BLK is enabled. Otherwise > SPL compilation breaks on boards which do have CONFIG_BLK enabled but > not DM_MMC for the SPL as follows: > > env/mmc.c: In function ‘init_mmc_for_env’: > env/mmc.c:164:6: warning: implicit declaration of function > ‘blk_get_from_parent’; did you mean ‘efi_get_ram_base’? > [-Wimplicit-function-declaration] > if (blk_get_from_parent(mmc->dev, )) > ^~~ > efi_get_ram_base > env/mmc.c:164:29: error: ‘struct mmc’ has no member named ‘dev’ > if (blk_get_from_parent(mmc->dev, )) > ^~ > > Signed-off-by: Sjoerd Simons > --- > > env/mmc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/7] video_display: Add power_on function
Hi Mario, On 28 March 2018 at 20:40, Mario Sixwrote: > Add a power_on function to the display uclass to allow devices to be > probed and powered-on separately. Is this different from the 'enable' method? Also note that we have a panel uclass that might be useful. > > Signed-off-by: Mario Six > --- > drivers/video/display-uclass.c | 10 ++ > include/display.h | 18 ++ > 2 files changed, 28 insertions(+) > > diff --git a/drivers/video/display-uclass.c b/drivers/video/display-uclass.c > index e752eb07c4..4865057e94 100644 > --- a/drivers/video/display-uclass.c > +++ b/drivers/video/display-uclass.c > @@ -57,6 +57,16 @@ int display_read_timing(struct udevice *dev, struct > display_timing *timing) > return edid_get_timing(buf, ret, timing, _bits_per_colour); > } > > +int display_power_on(struct udevice *dev, void *data) > +{ > + struct dm_display_ops *ops = display_get_ops(dev); > + > + if (!ops || !ops->power_on) > + return -ENOSYS; > + > + return ops->power_on(dev, data); > +} > + > bool display_in_use(struct udevice *dev) > { > struct display_plat *disp_uc_plat = dev_get_uclass_platdata(dev); > diff --git a/include/display.h b/include/display.h > index d0a08d4aaa..bb263be246 100644 > --- a/include/display.h > +++ b/include/display.h > @@ -51,6 +51,15 @@ int display_enable(struct udevice *dev, int panel_bpp, > */ > bool display_in_use(struct udevice *dev); > > +/** > + * display_power_on() - Power on display port device > + * > + * @dev: Device to power on > + * @data: Optional data needed to power on the display correctly > + * @return 0 if OK, -ve on error > + */ > +int display_power_on(struct udevice *dev, void *data); > + > struct dm_display_ops { > /** > * read_timing() - Read information directly > @@ -81,6 +90,15 @@ struct dm_display_ops { > */ > int (*enable)(struct udevice *dev, int panel_bpp, > const struct display_timing *timing); > + > + /** > +* power_on() - Power on display port device > +* > +* @dev:Device to power on > +* @data: Optional data needed to power on the display correctly > +* @return 0 if OK, -ve on error > +*/ > + int (*power_on)(struct udevice *dev, void *data); > }; > > #define display_get_ops(dev) ((struct dm_display_ops *)(dev)->driver->ops) > -- > 2.16.1 > Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/8] core: Add uclass_{first, next}_device_compat
Hi Mario, On 28 March 2018 at 20:38, Mario Sixwrote: > A lot of times one wants to cycle through the devices in a uclass, but > only certain ones, especially ones identified by their compatibility > string, and ignore all others (in the best case this procedure should > not even activate the devices one is not interested in). > > Hence, we add a pair of functions similar to uclass_{first,next}_device, > but taking a compatibility string as an additional argument, which cycle > through the devices of a uclass that conform to this compatibility > string. Can we not use a phandle to find the device? Using raw compatible strings feel bad (and slow to me). If not, a please add a sandbox test. > > Signed-off-by: Mario Six > --- > drivers/core/uclass.c | 33 + > include/dm/uclass.h | 37 + > 2 files changed, 70 insertions(+) Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/7] drivers: Add AXI uclass and ihs_axi driver
Hi Mario, On 28 March 2018 at 20:40, Mario Sixwrote: > Add a uclass for AXI (Advanced eXtensible Interface) busses, and a > driver for the gdsys IHS AXI bus on IHS FPGAs. > > Signed-off-by: Mario Six > --- > drivers/Kconfig | 2 + > drivers/Makefile | 1 + > drivers/axi/Kconfig | 24 ++ > drivers/axi/Makefile | 9 +++ > drivers/axi/axi-uclass.c | 40 ++ > drivers/axi/ihs_axi.c| 199 > +++ > include/axi.h| 75 ++ > include/dm/uclass-id.h | 1 + > 8 files changed, 351 insertions(+) > create mode 100644 drivers/axi/Kconfig > create mode 100644 drivers/axi/Makefile > create mode 100644 drivers/axi/axi-uclass.c > create mode 100644 drivers/axi/ihs_axi.c > create mode 100644 include/axi.h Would UCLASS_MAILBOX be suitable here? It's fine if you want a new uclass, just checking. Please split out your driver into a separate patch. Adding the new uclass should be in its own patch. > > diff --git a/drivers/Kconfig b/drivers/Kconfig > index c2e813f5ad..eeaaa7575c 100644 > --- a/drivers/Kconfig > +++ b/drivers/Kconfig > @@ -8,6 +8,8 @@ source "drivers/adc/Kconfig" > > source "drivers/ata/Kconfig" > > +source "drivers/axi/Kconfig" > + > source "drivers/block/Kconfig" > > source "drivers/bootcount/Kconfig" > diff --git a/drivers/Makefile b/drivers/Makefile > index 6846d181aa..f54a10f3ad 100644 > --- a/drivers/Makefile > +++ b/drivers/Makefile > @@ -100,6 +100,7 @@ obj-y += input/ > obj-y += soc/ > obj-$(CONFIG_REMOTEPROC) += remoteproc/ > obj-y += thermal/ > +obj-y += axi/ > > obj-$(CONFIG_MACH_PIC32) += ddr/microchip/ > endif > diff --git a/drivers/axi/Kconfig b/drivers/axi/Kconfig > new file mode 100644 > index 00..19e1b7fd2f > --- /dev/null > +++ b/drivers/axi/Kconfig > @@ -0,0 +1,24 @@ > +menuconfig AXI > + bool "AXI bus drivers" > + help > + Support AXI (Advanced eXtensible Interface) busses, a on-chip > + interconnect specification for managing functional blocks in SoC > + designs, which is also often used in designs involving FPGAs (e.g. > + communication with IP cores in Xilinx FPGAs). > + > + These types of busses expose a virtual address space that can be > + accessed using different address widths (8, 16, and 32 are supported > + for now). > + > + Other similar bus architectures may be compatible as well. > + > +if AXI > + > +config IHS_AXI > + bool "Enable IHS AXI driver" > + depends on DM > + help > + Support for IHS AXI bus on a gdsys IHS FPGA used to communicate with > + IP cores in the FPGA (e.g. video transmitter cores). Please also spell out the abbreviations in the help [...] Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 7/7] video_display: Add Xilinx LogiCore DP TX
Hi Mario, On 28 March 2018 at 20:40, Mario Sixwrote: > Add a driver for the Xilinx LogiCORE DisplayPort IP core. > > Signed-off-by: Mario Six > --- > drivers/video/Kconfig|8 + > drivers/video/Makefile |1 + > drivers/video/logicore_dp_dpcd.h | 342 ++ > drivers/video/logicore_dp_tx.c | 1974 > ++ > drivers/video/logicore_dp_tx.h | 40 + > drivers/video/logicore_dp_tx_regif.h | 365 +++ > 6 files changed, 2730 insertions(+) > create mode 100644 drivers/video/logicore_dp_dpcd.h > create mode 100644 drivers/video/logicore_dp_tx.c > create mode 100644 drivers/video/logicore_dp_tx.h > create mode 100644 drivers/video/logicore_dp_tx_regif.h Is it possible to have common code with the other DP drivers? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] clk: add Amlogic meson clock driver
Hi Neil, On 30 March 2018 at 15:53, Neil Armstrongwrote: > On 30/03/2018 00:41, Simon Glass wrote: >> Hi Neil, >> >> On 29 March 2018 at 16:42, Neil Armstrong wrote: >>> Hi Beniamino, >>> >>> On 03/12/2017 10:17, Beniamino Galvani wrote: Introduce a basic clock driver for Amlogic Meson SoCs which supports enabling/disabling clock gates and getting their frequency. Signed-off-by: Beniamino Galvani --- arch/arm/mach-meson/Kconfig | 2 + drivers/clk/Makefile| 1 + drivers/clk/clk_meson.c | 196 3 files changed, 199 insertions(+) create mode 100644 drivers/clk/clk_meson.c diff --git a/arch/arm/mach-meson/Kconfig b/arch/arm/mach-meson/Kconfig index d4bd230be3..7acee3bc5c 100644 --- a/arch/arm/mach-meson/Kconfig +++ b/arch/arm/mach-meson/Kconfig >>> >>> [...] + +static int meson_set_gate(struct clk *clk, bool on) +{ + struct meson_clk *priv = dev_get_priv(clk->dev); + struct meson_gate *gate; + + if (clk->id >= ARRAY_SIZE(gates)) + return -ENOENT; >>> >>> This should be -ENOSYS, otherwise it breaks the ethernet driver since it >>> waits -ENOSYS if clock cannot be enabled. >> >> Perhaps, but this is a genuine error, so it is OK to break the >> Ethernet driver, isn't it? We don't want errors to be silently >> ignored. >> >> Not having a device is one thing, but having a device that does not work is >> bad. >> > > The driver only manages the gates, enabling and disabling them and getting > their freq. > The missing clocks of the ethernet driver in this case are dividers of the > PLL, thus > we don't need to enable them, and for now the driver don't need the freq. Yes but -ENOSYS means that the driver does not support the operation at all. Put it another way: you can't return -ENOSYS for some parameters and not for others. > >> Also I have tried to keep -ENOSYS for cases where the driver does not >> support the operation. We should be very clear in clk-uclass.h as to >> what errors are returned. At present I don't see ENOSYS mentioned. At >> the very least we should update the docs if certain behaviour is >> expected. I would also expect us to have a sandbox test for it. > > In this case, the driver does not support the operation for these clocks, but > maybe it would be > better to add them with reg=0 and return -ENOSYS in the following return : I don't like that - ENOENT seems better. > >> >>> + + gate = [clk->id]; + + if (gate->reg == 0) + return -ENOENT; >>> >>> Same here -ENOSYS > > Here thsi means it's not a gate. Yes, but the driver still supports the operation. The problem is that its inputs are invalid. So use -ENOENT to mean that. > >>> + + clrsetbits_le32(priv->addr + gate->reg, + BIT(gate->bit), on ? BIT(gate->bit) : 0); + return 0; +} + +static int meson_clk_enable(struct clk *clk) +{ + return meson_set_gate(clk, true); +} + +static int meson_clk_disable(struct clk *clk) +{ + return meson_set_gate(clk, false); +} + +static ulong meson_clk_get_rate(struct clk *clk) +{ + struct meson_clk *priv = dev_get_priv(clk->dev); + + if (clk->id != CLKID_CLK81) { + if (clk->id >= ARRAY_SIZE(gates)) + return -ENOENT; >>> >>> Same here -ENOSYS >>> + if (gates[clk->id].reg == 0) + return -ENOENT; >>> >>> Same here -ENOSYS >>> + } + + /* Use cached value if available */ + if (priv->rate) + return priv->rate; + + priv->rate = meson_measure_clk_rate(CLK_81); + + return priv->rate; +} + >>> >>> [...] >>> >>> Neil >> >> Regards, >> Simon >> > Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] misc: uclass: Add enable/disable functions
Hi Mario, On 28 March 2018 at 20:38, Mario Sixwrote: > Add generic enable/disable functions to the misc uclass. > > Signed-off-by: Mario Six > --- > drivers/misc/misc-uclass.c | 20 > include/misc.h | 30 ++ > 2 files changed, 50 insertions(+) > > diff --git a/drivers/misc/misc-uclass.c b/drivers/misc/misc-uclass.c > index d9eea3dac5..942fa8da94 100644 > --- a/drivers/misc/misc-uclass.c > +++ b/drivers/misc/misc-uclass.c > @@ -56,6 +56,26 @@ int misc_call(struct udevice *dev, int msgid, void > *tx_msg, int tx_size, > return ops->call(dev, msgid, tx_msg, tx_size, rx_msg, rx_size); > } > > +int misc_enable(struct udevice *dev) > +{ > + const struct misc_ops *ops = device_get_ops(dev); > + > + if (!ops->enable) > + return -ENOSYS; > + > + return ops->enable(dev); > +} > + > +int misc_disable(struct udevice *dev) > +{ > + const struct misc_ops *ops = device_get_ops(dev); > + > + if (!ops->enable) > + return -ENOSYS; > + > + return ops->disable(dev); > +} > + > UCLASS_DRIVER(misc) = { > .id = UCLASS_MISC, > .name = "misc", > diff --git a/include/misc.h b/include/misc.h > index 03ef55cdc8..6f86396443 100644 > --- a/include/misc.h > +++ b/include/misc.h > @@ -58,6 +58,22 @@ int misc_ioctl(struct udevice *dev, unsigned long request, > void *buf); > int misc_call(struct udevice *dev, int msgid, void *tx_msg, int tx_size, > void *rx_msg, int rx_size); > > +/* > + * Enable a device. > + * > + * @dev: the device to enable. > + * @return: 0 if OK, -ve on error > + */ > +int misc_enable(struct udevice *dev); How about a single function like: int misc_set_enable(struct udevice *dev, bool enable); Also please state in the comment what exactly it means to enable/disable a device. > + > +/* > + * Disable a device. > + * > + * @dev: the device to disable. > + * @return: 0 if OK, -ve on error > + */ > +int misc_disable(struct udevice *dev); > + > /* > * struct misc_ops - Driver model Misc operations > * > @@ -109,6 +125,20 @@ struct misc_ops { > */ > int (*call)(struct udevice *dev, int msgid, void *tx_msg, int tx_size, > void *rx_msg, int rx_size); > + /* > +* Enable a device, optional. > +* > +* @dev: the device to enable. > +* @return: 0 if OK, -ve on error > +*/ > + int (*enable)(struct udevice *dev); > + /* > +* Disable a device, optional. > +* > +* @dev: the device to disable. > +* @return: 0 if OK, -ve on error > +*/ > + int (*disable)(struct udevice *dev); > }; > > #endif /* _MISC_H_ */ > -- > 2.16.1 > Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 01/10] syscon: dm: Add a new method to get a regmap from DTS
Hi Jean-Jacques, On 26 March 2018 at 21:50, Jean-Jacques Hiblotwrote: > syscon_regmap_lookup_by_phandle() can be used to the regmap of a syscon used to ... the > device from a reference in the DTS. It operates similarly to the linux > version of the namesake function. > > Signed-off-by: Jean-Jacques Hiblot > > --- > > Changes in v3: > - in syscon_regmap_lookup_by_phandle(), use dev_dbg() instead of printf() > - added unit test for syscon_regmap_lookup_by_phandle() > > Changes in v2: None > > arch/sandbox/dts/test.dts| 6 -- > drivers/core/syscon-uclass.c | 23 +++ > include/syscon.h | 13 + > test/dm/syscon.c | 29 + > 4 files changed, 69 insertions(+), 2 deletions(-) > Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] devinfo: Add gazerbeam info driver
Hi Mario, On 28 March 2018 at 20:36, Mario Sixwrote: > Add a device information driver for the upcoming gdsys Gazerbeam board. > > Signed-off-by: Mario Six > --- > drivers/devinfo/gazerbeam.c | 151 > > drivers/devinfo/gazerbeam.h | 17 + > 2 files changed, 168 insertions(+) > create mode 100644 drivers/devinfo/gazerbeam.c > create mode 100644 drivers/devinfo/gazerbeam.h > > diff --git a/drivers/devinfo/gazerbeam.c b/drivers/devinfo/gazerbeam.c > new file mode 100644 > index 00..10226aa254 > --- /dev/null > +++ b/drivers/devinfo/gazerbeam.c > @@ -0,0 +1,151 @@ > +/* > + * (C) Copyright 2017 > + * Mario Six, Guntermann & Drunck GmbH, mario@gdsys.cc > + * > + * SPDX-License-Identifier:GPL-2.0+ > + */ > + > +#include > +#include > +#include > +#include > +#include > + > +#include "gazerbeam.h" > + > +const int VER_GPIOS_COUNT = 4; > + > +struct devinfo_gazerbeam_priv { > + struct gpio_desc var_gpios[2]; > + struct gpio_desc ver_gpios[4]; > + int variant; > + int multichannel; > + int hwversion; > +}; > + > +static int _read_multichannel_variant(struct udevice *dev) > +{ > + struct devinfo_gazerbeam_priv *priv = dev_get_priv(dev); > + struct udevice *i2c_bus; > + struct udevice *dummy; > + char *listname; > + bool mc4, mc2, sc, con; > + > + uclass_get_device_by_seq(UCLASS_I2C, 1, _bus); Please pass the error through unless there is a good reason not to. ret = uclass ... if (ret) { debug(...) return ret } > + > + if (!i2c_bus) { > + puts("Could not get I2C bus\n"); > + return -EIO; > + } > + > + mc2 = !dm_i2c_probe(i2c_bus, 0x20, 0, ); > + mc4 = !dm_i2c_probe(i2c_bus, 0x22, 0, ); Same here > + > + if (mc2 && mc4) { > + puts("Board hardware configuration inconsistent.\n"); > + return -EINVAL; > + } > + > + listname = mc2 ? "var_gpios_mc2" : "var_gpios_mc4"; If these are DT properties they should use hyphen instead of underscore > + > + if (!gpio_request_list_by_name(dev, listname, priv->var_gpios, > + 2, GPIOD_IS_IN)) { > + printf("Requesting gpio list %s failed.\n", listname); > + return -ENODEV; Return correct error > + } > + > + sc = dm_gpio_get_value(>var_gpios[0]); > + con = dm_gpio_get_value(>var_gpios[1]); And here > + > + if ((sc && mc2) || (sc && mc4) || (!sc && !mc2 && !mc4)) { > + puts("Board hardware configuration inconsistent.\n"); > + return -EINVAL; > + } > + > + priv->variant = con ? VAR_CON : VAR_CPU; > + > + priv->multichannel = mc4 ? 4 : (mc2 ? 2 : (sc ? 1 : 0)); > + > + return 0; > +} > + > +static int _read_hwversion(struct udevice *dev) > +{ > + struct devinfo_gazerbeam_priv *priv = dev_get_priv(dev); > + int value; > + > + if (!gpio_request_list_by_name(dev, "ver_gpios", priv->ver_gpios, ver-gpios ? > + VER_GPIOS_COUNT, GPIOD_IS_IN)) > + return -ENODEV; > + > + value = dm_gpio_get_values_as_int(priv->ver_gpios, VER_GPIOS_COUNT); > + > + if (value < 0) > + return value; > + > + priv->hwversion = value; > + > + gpio_free_list(dev, priv->ver_gpios, VER_GPIOS_COUNT); > + > + return 0; > +} > + > +int devinfo_gazerbeam_detect(struct udevice *dev) > +{ > + int res; > + > + res = _read_multichannel_variant(dev); > + if (res) > + return res; > + > + res = _read_hwversion(dev); > + if (res) > + return res; > + > + return 0; > +} > + > +int devinfo_gazerbeam_get_int(struct udevice *dev, int id, int *val) > +{ > + struct devinfo_gazerbeam_priv *priv = dev_get_priv(dev); > + > + switch (id) { > + case DEVINFO_MULTICHANNEL: > + *val = priv->multichannel; > + break; > + case DEVINFO_VARIANT: > + *val = priv->variant; > + break; > + case DEVINFO_HWVERSION: > + *val = priv->hwversion; > + break; > + default: > + return -EINVAL; > + } > + > + return 0; > +} > + > +static const struct udevice_id devinfo_gazerbeam_ids[] = { > + { .compatible = "gdsys,devinfo_gazerbeam" }, > + { /* sentinel */ } > +}; > + > +static const struct devinfo_ops devinfo_gazerbeam_ops = { > + .detect = devinfo_gazerbeam_detect, > + .get_int = devinfo_gazerbeam_get_int, > +}; > + > +int devinfo_gazerbeam_probe(struct udevice *dev) > +{ > + return 0; > +} > + > +U_BOOT_DRIVER(devinfo_gazerbeam) = { > + .name = "devinfo_gazerbeam", > + .id = UCLASS_DEVINFO, > + .of_match = devinfo_gazerbeam_ids, > +
Re: [U-Boot] [PATCH 1/3] drivers: Add FPGA register map uclass
Hi Mario, On 28 March 2018 at 20:37, Mario Sixwrote: > The FPGA (as a device) and the register map supplied by a FPGA are two > different entities. There are U-Boot drivers for the former, but not for > the later. > > Add a uclass that makes it possible to read from and write to FPGA > memory maps. The interface provided emulates the PCI interface, with one > function for reading/writing plus a size parameter. > > Signed-off-by: Mario Six > --- > drivers/Kconfig | 2 + > drivers/Makefile | 1 + > drivers/fpgamap/Kconfig | 9 +++ > drivers/fpgamap/Makefile | 8 +++ > drivers/fpgamap/fpgamap-uclass.c | 53 > include/dm/uclass-id.h | 1 + > include/fpgamap.h| 131 > +++ > 7 files changed, 205 insertions(+) > create mode 100644 drivers/fpgamap/Kconfig > create mode 100644 drivers/fpgamap/Makefile > create mode 100644 drivers/fpgamap/fpgamap-uclass.c > create mode 100644 include/fpgamap.h > Could we use regmap for this? That uclass really could use being enhanced to do the things you do here. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] drivers: Add devinfo uclass
Hi Mario, On 28 March 2018 at 20:36, Mario Sixwrote: > Some boards have encoded information, e.g. hard-wired GPIOs on a GPIO > expander, read-only memory ICs, etc. that carry information about the > hardware. > > Add a uclass that encapsulates device information of such a kind and > makes them accessible in a uniform manner. The devices of this uclass > expose methods to read generic data types (integers, strings, booleans) > to encode the information provided by the hardware. > > Signed-off-by: Mario Six > --- > drivers/Kconfig | 2 ++ > drivers/Makefile | 1 + > drivers/devinfo/Kconfig | 17 > drivers/devinfo/Makefile | 9 +++ > drivers/devinfo/devinfo-uclass.c | 55 +++ > include/devinfo.h| 56 > > include/dm/uclass-id.h | 1 + > 7 files changed, 141 insertions(+) > create mode 100644 drivers/devinfo/Kconfig > create mode 100644 drivers/devinfo/Makefile > create mode 100644 drivers/devinfo/devinfo-uclass.c > create mode 100644 include/devinfo.h Please can you add a sandbox driver for this and a test? > > diff --git a/drivers/Kconfig b/drivers/Kconfig > index c2e813f5ad..34777d9013 100644 > --- a/drivers/Kconfig > +++ b/drivers/Kconfig > @@ -22,6 +22,8 @@ source "drivers/ddr/Kconfig" > > source "drivers/demo/Kconfig" > > +source "drivers/devinfo/Kconfig" > + > source "drivers/ddr/fsl/Kconfig" > > source "drivers/dfu/Kconfig" > diff --git a/drivers/Makefile b/drivers/Makefile > index 6846d181aa..208b68081e 100644 > --- a/drivers/Makefile > +++ b/drivers/Makefile > @@ -72,6 +72,7 @@ obj-y += block/ > obj-$(CONFIG_BOOTCOUNT_LIMIT) += bootcount/ > obj-$(CONFIG_CPU) += cpu/ > obj-y += crypto/ > +obj-y += devinfo/ > obj-y += firmware/ > obj-$(CONFIG_FPGA) += fpga/ > obj-y += misc/ > diff --git a/drivers/devinfo/Kconfig b/drivers/devinfo/Kconfig > new file mode 100644 > index 00..0de70b410e > --- /dev/null > +++ b/drivers/devinfo/Kconfig > @@ -0,0 +1,17 @@ > +menuconfig DEVINFO > + bool "Device Information" > + help > + Support methods to query hardware configurations from internal > + mechanisms (e.g. reading GPIO values, determining the presence of > + devices on busses, etc.). This enables the usage of U-Boot with > + modular board architectures. > + > +if DEVINFO > + > + > +config DEVINFO_GAZERBEAM > + bool "Enable device information for the Gazerbeam board" > + help > + Support querying device information for the gdsys Gazerbeam board. > + > +endif > diff --git a/drivers/devinfo/Makefile b/drivers/devinfo/Makefile > new file mode 100644 > index 00..0a9cad4a15 > --- /dev/null > +++ b/drivers/devinfo/Makefile > @@ -0,0 +1,9 @@ > +# > +# (C) Copyright 2017 > +# Mario Six, Guntermann & Drunck GmbH, mario@gdsys.cc > +# > +# SPDX-License-Identifier: GPL-2.0+ > +# > + > +obj-$(CONFIG_DEVINFO) += devinfo-uclass.o > +obj-$(CONFIG_DEVINFO_GAZERBEAM) += gazerbeam.o > diff --git a/drivers/devinfo/devinfo-uclass.c > b/drivers/devinfo/devinfo-uclass.c > new file mode 100644 > index 00..89bbe8f343 > --- /dev/null > +++ b/drivers/devinfo/devinfo-uclass.c > @@ -0,0 +1,55 @@ > +/* > + * (C) Copyright 2017 > + * Mario Six, Guntermann & Drunck GmbH, mario@gdsys.cc > + * > + * SPDX-License-Identifier:GPL-2.0+ > + */ > + > +#include > +#include > +#include > + > +int devinfo_detect(struct udevice *dev) > +{ > + struct devinfo_ops *ops = devinfo_get_ops(dev); > + > + if (!ops->detect) > + return -ENOSYS; > + > + return ops->detect(dev); > +} > + > +int devinfo_get_bool(struct udevice *dev, int id, bool *val) > +{ > + struct devinfo_ops *ops = devinfo_get_ops(dev); > + > + if (!ops->get_bool) > + return -ENOSYS; > + > + return ops->get_bool(dev, id, val); > +} > + > +int devinfo_get_int(struct udevice *dev, int id, int *val) > +{ > + struct devinfo_ops *ops = devinfo_get_ops(dev); > + > + if (!ops->get_int) > + return -ENOSYS; > + > + return ops->get_int(dev, id, val); > +} > + > +int devinfo_get_str(struct udevice *dev, int id, char *val) > +{ > + struct devinfo_ops *ops = devinfo_get_ops(dev); > + > + if (!ops->get_str) > + return -ENOSYS; > + > + return ops->get_str(dev, id, val); > +} > + > +UCLASS_DRIVER(devinfo) = { > + .id = UCLASS_DEVINFO, > + .name = "devinfo", > +}; > diff --git a/include/devinfo.h b/include/devinfo.h > new file mode 100644 > index 00..90014c27c4 > --- /dev/null > +++ b/include/devinfo.h > @@ -0,0 +1,56 @@ > +/* > + * (C) Copyright 2017 > + * Mario Six, Guntermann & Drunck GmbH, mario@gdsys.cc > + * > + * SPDX-License-Identifier:GPL-2.0+ > + */ > + > +struct devinfo_ops { > + int
Re: [U-Boot] [PATCH 2/2] image: fit: Show information about OS type in firwmare case too
On 26 March 2018 at 22:31, Michal Simekwrote: > SPL ATF implementation requires FIT image with partitions where the one > is Firmware/ATF and another one Firmware/U-Boot. OS field is used for > recording that difference that's why make sense to show values there for > Firmware types. > > For example: > Image 0 (atf) > Description: ATF bl31.bin > Created: Mon Mar 26 15:58:14 2018 > Type: Firmware > Compression: uncompressed > Data Size:51152 Bytes = 49.95 KiB = 0.05 MiB > Architecture: ARM > OS: ARM Trusted Firmware > Load Address: 0xfffe > Hash algo:md5 > Hash value: 36a4212bbb698126bf5a248f0f4b5336 > Image 1 (uboot) > Description: u-boot.bin > Created: Mon Mar 26 15:58:14 2018 > Type: Firmware > Compression: uncompressed > Data Size:761216 Bytes = 743.38 KiB = 0.73 MiB > Architecture: ARM > OS: U-Boot > Load Address: 0x0800 > Hash algo:md5 > Hash value: f22960fe429be72296dc8dc59a47d566 > > Signed-off-by: Michal Simek > --- > > common/image-fit.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) Reviewed-by: Simon Glass But please fix the commit subject 'firwmare'. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] image: fit: Show firmware configuration property if present
On 26 March 2018 at 22:31, Michal Simekwrote: > SPL ATF support requires to have firmware property which should be also > listed by mkimage -l when images is created. > > The patch is also using this macro in spl_fit to match keyword. > > When image is created: > Default Configuration: 'config' > Configuration 0 (config) > Description: ATF with full u-boot > Kernel: unavailable > Firmware: atf > FDT: dtb > > Signed-off-by: Michal Simek > --- > > common/image-fit.c | 4 > common/spl/spl_fit.c | 3 ++- > include/image.h | 1 + > 3 files changed, 7 insertions(+), 1 deletion(-) > Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] mkimage: do not fail if there is no print_header function
Commit 253c60a breaks the exit value of 'mkimage -T rkimage' and print the following error: mkimage: Can't print header for Rockchip Boot Image support: Success It is not a failure to not print headers, so just display the warning message, and finish the function properly. Signed-off-by: Guillaume GARDETCc: Philipp Tomsich Cc: Simon Glass Cc: Tom Rini --- tools/mkimage.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/tools/mkimage.c b/tools/mkimage.c index 28ff35e670..4e561820e7 100644 --- a/tools/mkimage.c +++ b/tools/mkimage.c @@ -588,9 +588,8 @@ int main(int argc, char **argv) if (tparams->print_header) tparams->print_header (ptr); else { - fprintf (stderr, "%s: Can't print header for %s: %s\n", - params.cmdname, tparams->name, strerror(errno)); - exit (EXIT_FAILURE); + fprintf (stderr, "%s: Can't print header for %s\n", + params.cmdname, tparams->name); } (void) munmap((void *)ptr, sbuf.st_size); -- 2.13.6 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Please pull u-boot-x86
Hi Tom, The following changes since commit 81cf7c8d45935a295991fe2cd1df286f0f47511f: Merge git://git.denx.de/u-boot-ubi (2018-03-25 12:02:13 -0400) are available in the git repository at: git://git.denx.de/u-boot-x86.git for you to fetch changes up to 5d73292cf84db1e8f7d99dd27100ef2e8ac15c4e: x86: zImage: Pass working device tree data to the kernel (2018-03-30 16:06:58 +0800) Alexander Graf (1): efi_stub: Fix GDT_NOTSYS check Bernhard Messerklinger (1): x86: mmc: Fix mapping of BAR memory Bin Meng (2): dm: pci: Check board information pointer in decode_regions() dm: pci: Avoid setting a PCI region that has 0 size Ivan Gorinov (1): x86: zImage: Pass working device tree data to the kernel arch/x86/include/asm/bootparam.h | 7 +-- arch/x86/lib/zimage.c| 35 +++ drivers/mmc/pci_mmc.c| 5 ++--- drivers/pci/pci-uclass.c | 8 ++-- lib/efi/efi_stub.c | 2 +- 5 files changed, 49 insertions(+), 8 deletions(-) Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3] x86: zImage: Pass working device tree data to the kernel
On Tue, Mar 27, 2018 at 9:06 AM, Ivan Gorinovwrote: > On x86 platforms, U-Boot does not pass Device Tree data to the kernel. > This prevents the kernel from using FDT loaded by U-Boot. > > Read the working FDT address from the "fdtaddr" environment variable > and add a copy of the FDT data to the kernel setup_data list. > > Signed-off-by: Ivan Gorinov > --- > arch/x86/include/asm/bootparam.h | 7 +-- > arch/x86/lib/zimage.c| 34 ++ > 2 files changed, 39 insertions(+), 2 deletions(-) > > diff --git a/arch/x86/include/asm/bootparam.h > b/arch/x86/include/asm/bootparam.h > index 90768a9..6aba614 100644 > --- a/arch/x86/include/asm/bootparam.h > +++ b/arch/x86/include/asm/bootparam.h > @@ -10,8 +10,11 @@ > #include > > /* setup data types */ > -#define SETUP_NONE 0 > -#define SETUP_E820_EXT 1 > +enum { > + SETUP_NONE = 0, > + SETUP_E820_EXT, > + SETUP_DTB, > +}; > > /* extensible setup data list node */ > struct setup_data { > diff --git a/arch/x86/lib/zimage.c b/arch/x86/lib/zimage.c > index 2a82bc8..1ff77e9 100644 > --- a/arch/x86/lib/zimage.c > +++ b/arch/x86/lib/zimage.c > @@ -14,6 +14,7 @@ > */ > > #include > +#include > #include > #include > #include Sorry to mention that I added "#include " here to fix build error seen on several x86 boards during a buildman testing. Changed applied to u-boot-x86. > @@ -95,6 +96,38 @@ static int get_boot_protocol(struct setup_header *hdr) > } > } > Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] efi_stub: Fix GDT_NOTSYS check
Hi Alex, On Thu, Feb 15, 2018 at 11:03 PM, Alexander Grafwrote: > > > On 12.02.18 07:26, Bin Meng wrote: >> Hi Alexander, >> >> On Tue, Dec 5, 2017 at 7:20 AM, Bin Meng wrote: >>> On Mon, Dec 4, 2017 at 11:33 PM, Alexander Graf wrote: The get_codeseg32() wants to know if a passed in descriptor has flag GDT_NOTSYS set (desc & GDT_NOTSYS), not whether desc and GDT_NOTSYS are not != 0 (desk && GDT_NOTSYS). This is an obvious typo. Fix it up. Signed-off-by: Alexander Graf --- lib/efi/efi_stub.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> Reviewed-by: Bin Meng >> >> Looks this one is applied nowhere? > > lib/efi is something you maintain, no? > > I only want to run U-Boot as UEFI firmware, I don't particularly care > about running U-Boot as UEFI payload :). Since I see on patchwork, this patch was assigned to you so I did not take it. I will pick this patch to x86. Thanks. applied to u-boot-x86, thanks! Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] clk: add Amlogic meson clock driver
On 30/03/2018 00:41, Simon Glass wrote: > Hi Neil, > > On 29 March 2018 at 16:42, Neil Armstrongwrote: >> Hi Beniamino, >> >> On 03/12/2017 10:17, Beniamino Galvani wrote: >>> Introduce a basic clock driver for Amlogic Meson SoCs which supports >>> enabling/disabling clock gates and getting their frequency. >>> >>> Signed-off-by: Beniamino Galvani >>> --- >>> arch/arm/mach-meson/Kconfig | 2 + >>> drivers/clk/Makefile| 1 + >>> drivers/clk/clk_meson.c | 196 >>> >>> 3 files changed, 199 insertions(+) >>> create mode 100644 drivers/clk/clk_meson.c >>> >>> diff --git a/arch/arm/mach-meson/Kconfig b/arch/arm/mach-meson/Kconfig >>> index d4bd230be3..7acee3bc5c 100644 >>> --- a/arch/arm/mach-meson/Kconfig >>> +++ b/arch/arm/mach-meson/Kconfig >> >> [...] >>> + >>> +static int meson_set_gate(struct clk *clk, bool on) >>> +{ >>> + struct meson_clk *priv = dev_get_priv(clk->dev); >>> + struct meson_gate *gate; >>> + >>> + if (clk->id >= ARRAY_SIZE(gates)) >>> + return -ENOENT; >> >> This should be -ENOSYS, otherwise it breaks the ethernet driver since it >> waits -ENOSYS if clock cannot be enabled. > > Perhaps, but this is a genuine error, so it is OK to break the > Ethernet driver, isn't it? We don't want errors to be silently > ignored. > > Not having a device is one thing, but having a device that does not work is > bad. > The driver only manages the gates, enabling and disabling them and getting their freq. The missing clocks of the ethernet driver in this case are dividers of the PLL, thus we don't need to enable them, and for now the driver don't need the freq. > Also I have tried to keep -ENOSYS for cases where the driver does not > support the operation. We should be very clear in clk-uclass.h as to > what errors are returned. At present I don't see ENOSYS mentioned. At > the very least we should update the docs if certain behaviour is > expected. I would also expect us to have a sandbox test for it. In this case, the driver does not support the operation for these clocks, but maybe it would be better to add them with reg=0 and return -ENOSYS in the following return : > >> >>> + >>> + gate = [clk->id]; >>> + >>> + if (gate->reg == 0) >>> + return -ENOENT; >> >> Same here -ENOSYS Here thsi means it's not a gate. >> >>> + >>> + clrsetbits_le32(priv->addr + gate->reg, >>> + BIT(gate->bit), on ? BIT(gate->bit) : 0); >>> + return 0; >>> +} >>> + >>> +static int meson_clk_enable(struct clk *clk) >>> +{ >>> + return meson_set_gate(clk, true); >>> +} >>> + >>> +static int meson_clk_disable(struct clk *clk) >>> +{ >>> + return meson_set_gate(clk, false); >>> +} >>> + >>> +static ulong meson_clk_get_rate(struct clk *clk) >>> +{ >>> + struct meson_clk *priv = dev_get_priv(clk->dev); >>> + >>> + if (clk->id != CLKID_CLK81) { >>> + if (clk->id >= ARRAY_SIZE(gates)) >>> + return -ENOENT; >> >> Same here -ENOSYS >> >>> + if (gates[clk->id].reg == 0) >>> + return -ENOENT; >> >> Same here -ENOSYS >> >>> + } >>> + >>> + /* Use cached value if available */ >>> + if (priv->rate) >>> + return priv->rate; >>> + >>> + priv->rate = meson_measure_clk_rate(CLK_81); >>> + >>> + return priv->rate; >>> +} >>> + >> >> [...] >> >> Neil > > Regards, > Simon > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] Move CONFIG_PHY_ADDR to Kconfig
Hi Joe, On Thu, Mar 29, 2018 at 2:17 AM, Joe Hershbergerwrote: > On Sun, Mar 25, 2018 at 8:40 PM, Bin Meng wrote: >> Hi Joe, >> >> On Sat, Mar 24, 2018 at 1:11 AM, Joe Hershberger >> wrote: >>> On Thu, Mar 22, 2018 at 9:46 AM, Bin Meng wrote: Hi, On Fri, Feb 2, 2018 at 9:53 PM, Stefan Mavrodiev wrote: > CONFIG_PHY_ADDR is used for old-style configuration. This makes > impossible changing the PHY address, if multiple boards share a same > config header file (for example include/configs/sunxi-common.h). > > Moving this to Kconfig helps overcoming this issue. It's defined > as entry inside PHYLIB section. > > After the implemention, moveconfig was run. The issues are: > - edb9315a - CONFIG_PHYLIB is not enabled. Entry is > deleted. > > - ds414 - CONFIG_PHYLIB is in incompatible format: > { 0x1, 0x0 }. This entry is also deleted. > > - devkit3250- The PHY_ADDR is in hex format (0x1F). > Manually CONFIG_PHY_ADDR=31 is added in > the defconfig. > > After the changes the suspicious defconfigs passes building. > > Signed-off-by: Stefan Mavrodiev > Acked-by: Maxime Ripard > --- > Changes for v2: >- Replaced CONFIG_SUNXI_PHY_ADDR with a common one > CONFIG_PHY_ADDR, using moveconfig. > > README | 4 > configs/devkit3250_defconfig | 1 + > configs/khadas-vim_defconfig | 1 + > configs/libretech-cc_defconfig | 1 + > configs/p212_defconfig | 1 + > drivers/net/phy/Kconfig| 7 +++ > include/configs/am335x_shc.h | 1 - > include/configs/baltos.h | 1 - > include/configs/devkit3250.h | 1 - > include/configs/ds414.h| 1 - > include/configs/edb93xx.h | 1 - > include/configs/khadas-vim.h | 2 -- > include/configs/libretech-cc.h | 2 -- > include/configs/p212.h | 2 -- > include/configs/pepper.h | 1 - > include/configs/sunxi-common.h | 2 -- > include/configs/work_92105.h | 1 - > include/configs/x600.h | 1 - > scripts/config_whitelist.txt | 1 - > 19 files changed, 11 insertions(+), 21 deletions(-) > [snip] > diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig > index 95b7534..c934aed 100644 > --- a/drivers/net/phy/Kconfig > +++ b/drivers/net/phy/Kconfig > @@ -12,6 +12,13 @@ menuconfig PHYLIB > > if PHYLIB > > +config PHY_ADDR > + int "PHY address" > + default 1 if ARCH_SUNXI > + default 0 > + help > + The address of PHY on MII bus. Usually in range of 0 to 31. > + Sorry for jumping out so late, but this commit breaks Intel Galileo ethernet. Previously the board boots with the following log: Net: eth0: eth_designware#0, eth1: eth_designware#1 With this commit it becomes: Net: No ethernet found. The reason is that the board has two designware ethernet controllers, and PHY_ADDR has been set to zero for both. A simple fix is to: diff --git a/drivers/net/designware.c b/drivers/net/designware.c index 43670a7..1394119 100644 --- a/drivers/net/designware.c +++ b/drivers/net/designware.c @@ -471,10 +471,6 @@ static int dw_phy_init(struct dw_eth_dev *priv, void *dev) struct phy_device *phydev; int mask = 0x, ret; -#ifdef CONFIG_PHY_ADDR - mask = 1 << CONFIG_PHY_ADDR; -#endif - phydev = phy_find_by_mask(priv->bus, mask, priv->interface); if (!phydev) return -ENODEV; But the real question is that: why do we introduce this PHY_ADDR Kconfig? It for sure won't work for multiple ethernet controllers.This should be eliminated IMHO. Comments? >>> >>> This should be able to come from the device tree, ultimately. Can you >>> undefine the phy addr for the Galileo board? >>> [snip] >> >> #undf the PHY_ADDR in Galileo board looks weird. This to me is a workaround. > > I didn't mean to add a #undef. I was just saying that if the "default > 0" in the Kconfig were instead "default 0 if !X86" or something (or > maybe if the board defconfig explicitly does unselects it). > This cannot be done as CONFIG_PHY_ADDR is an "int", not a "bool". We cannot do "# CONFIG_PHY_ADDR is not set" in the galileo_defconfig. >> Since the designware ethernet controller driver supports finding any >> PHY attached to its mdio bus, the changes suggested above can be a >> proper fix. > >
Re: [U-Boot] [PATCH v3] x86: zImage: Pass working device tree data to the kernel
On Tue, Mar 27, 2018 at 9:58 AM, Bin Mengwrote: > On Tue, Mar 27, 2018 at 9:06 AM, Ivan Gorinov wrote: >> On x86 platforms, U-Boot does not pass Device Tree data to the kernel. >> This prevents the kernel from using FDT loaded by U-Boot. >> >> Read the working FDT address from the "fdtaddr" environment variable >> and add a copy of the FDT data to the kernel setup_data list. >> >> Signed-off-by: Ivan Gorinov >> --- >> arch/x86/include/asm/bootparam.h | 7 +-- >> arch/x86/lib/zimage.c| 34 ++ >> 2 files changed, 39 insertions(+), 2 deletions(-) >> > > Reviewed-by: Bin Meng applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] x86: mmc: Fix mapping of BAR memory
On Mon, Mar 19, 2018 at 11:43 AM, Bin Mengwrote: > On Thu, Feb 15, 2018 at 4:09 PM, Bernhard Messerklinger > wrote: >> Use dm_pci_map_bar function for BAR mapping. This has the advantage >> of clearing BAR flags and and only accepting mapped memory. >> >> Signed-off-by: Bernhard Messerklinger >> >> --- >> >> drivers/mmc/pci_mmc.c | 5 ++--- >> 1 file changed, 2 insertions(+), 3 deletions(-) >> > > Reviewed-by: Bin Meng applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] dm: pci: Avoid setting a PCI region that has 0 size
On Fri, Mar 30, 2018 at 6:43 AM, Simon Glasswrote: > On 27 March 2018 at 15:46, Bin Meng wrote: >> It makes no sense to set a PCI region that has 0 size. >> >> Signed-off-by: Bin Meng >> --- >> >> drivers/pci/pci-uclass.c | 5 +++-- >> 1 file changed, 3 insertions(+), 2 deletions(-) > > Reviewed-by: Simon Glass applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] dm: pci: Check board information pointer in decode_regions()
On Fri, Mar 30, 2018 at 6:43 AM, Simon Glasswrote: > On 27 March 2018 at 15:46, Bin Meng wrote: >> PCI enumeration may happen very early on an x86 board. The board >> information pointer should have been checked in decode_regions() >> as its space may not be allocated yet. >> >> With this commit, Intel Galileo board boots again. >> >> Fixes: 664758c ("pci: Fix decode regions for memory banks") >> Signed-off-by: Bin Meng >> --- >> >> drivers/pci/pci-uclass.c | 3 +++ >> 1 file changed, 3 insertions(+) > > Reviewed-by: Simon Glass applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] armv7m: disable icache before linux booting
Similarly to ARMV7, on ARMV7M instruction cache memory needs to be disabled before running linux kernel to avoid kernel to be stuck. Signed-off-by: Patrice Chotard--- arch/arm/cpu/armv7m/cpu.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/cpu/armv7m/cpu.c b/arch/arm/cpu/armv7m/cpu.c index a424babde547..29597750f8be 100644 --- a/arch/arm/cpu/armv7m/cpu.c +++ b/arch/arm/cpu/armv7m/cpu.c @@ -37,6 +37,9 @@ int cleanup_before_linux(void) * dcache flushing and disabling dcache */ invalidate_dcache_all(); + icache_disable(); + invalidate_icache_all(); + return 0; } -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Uboot send pull request
Hi Tom, Please pull the following patch from u-boot-riscv into your tree. Thanks! The following changes since commit 81cf7c8d45935a295991fe2cd1df286f0f47511f: Merge git://git.denx.de/u-boot-ubi (2018-03-25 12:02:13 -0400) are available in the Git repository at: git://git.denx.de/u-boot-riscv.git for you to fetch changes up to d58717e42559189a226ea800173147399c8edef9: riscv: ae250: Support DT provided by the board at runtime (2018-03-30 13:13:56 +0800) Rick Chen (20): riscv: checkpatch: Fix Macro argument reuse riscv: checkpatch: Fix use of volatile riscv: checkpatch: Fix alignment should match open parenthesis riscv: checkpatch: Fix missing a blank line after declarations riscv: checkpatch: Fix static const char * array declarations riscv: bootm: Support to boot riscv-linux riscv: bootm: Remove ATAGS tools: mkimage: Support RISC-V arch doc: ae250: Describe riscv-linux booting via u-boot mmc: ftsdc010: Support High-Speed mode riscv: dts: AE250 support sd High-Speed mode nds32: dts: AG101P support sd High-Speed mode mmc: ftsdc010: Drop non-dm code board: Drop ftsdc010 non-dm code Drop CONFIG_FTSDC010_BASE Drop CONFIG_FTSDC010_NUMBER mmc: ftsdc010: Migrate CONFIG_FTSDC010_SDIO to Kconfig mmc: ftsdc010: Merge nds32_mmc to ftsdc010 configs: Drop CONFIG_MMC_NDS32 riscv: ae250: Support DT provided by the board at runtime arch/nds32/dts/ag101p.dts | 1 + arch/nds32/include/asm/arch-ae3xx/ae3xx.h | 2 - arch/nds32/include/asm/arch-ag101/ag101.h | 2 - arch/nds32/include/asm/arch-ag102/ag102.h | 2 - arch/riscv/cpu/nx25/start.S | 2 + arch/riscv/dts/ae250.dts | 1 + arch/riscv/include/asm/bootm.h| 49 arch/riscv/include/asm/encoding.h | 16 +--- arch/riscv/include/asm/global_data.h | 2 +- arch/riscv/include/asm/io.h | 23 +--- arch/riscv/include/asm/posix_types.h | 12 -- arch/riscv/include/asm/ptrace.h | 9 ++--- arch/riscv/include/asm/setup.h| 10 +++-- arch/riscv/include/asm/string.h | 12 -- arch/riscv/lib/bootm.c| 185 +++--- arch/riscv/lib/interrupts.c | 2 +- board/AndesTech/adp-ae3xx/adp-ae3xx.c | 11 -- board/AndesTech/adp-ag101p/adp-ag101p.c | 11 -- board/AndesTech/nx25-ae250/nx25-ae250.c | 14 +++ common/image.c| 1 + configs/adp-ae3xx_defconfig | 2 +- configs/adp-ag101p_defconfig | 2 +- configs/nx25-ae250_defconfig | 3 +- doc/README.ae250 | 148 +--- drivers/mmc/Kconfig | 14 +++ drivers/mmc/Makefile | 1 - drivers/mmc/ftsdc010_mci.c| 219 +-- drivers/mmc/ftsdc010_mci.h| 15 drivers/mmc/nds32_mmc.c | 136 -- include/configs/adp-ae3xx.h | 6 --- include/configs/adp-ag101p.h | 6 --- include/configs/nx25-ae250.h | 18 ++--- scripts/config_whitelist.txt | 4 -- 33 files changed, 347 insertions(+), 594 deletions(-) delete mode 100644 drivers/mmc/nds32_mmc.c ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot