January 2019 - U-Boot

[U-Boot] [PATCH 0/1] Extend malloc() pool for Zynq devices
by Anton Gerasimov 22 Jan '19

22 Jan '19

I'm getting -ENOMEM on Z-Turn board already, other boards are probably still allright if no one complains, but might hit the limit soon. Anton Gerasimov (1): zynq: Kconfig: extend the bootstrap malloc() pool arch/arm/mach-zynq/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.19.0

2 7

[U-Boot] [PATCH] arm: zynq: Enable CONFIG_REMAKE_ELF
by Michal Simek 22 Jan '19

22 Jan '19

From: Siva Durga Prasad Paladugu <siva.durga.paladugu(a)xilinx.com> This patch enables CONFIG_REMAKE_ELF for Zynq platform so that it generates u-boot.elf from binary which works for all Zynq boards with OF_SEPARATE option enabled. Signed-off-by: Siva Durga Prasad Paladugu <siva.durga.paladugu(a)xilinx.com> Signed-off-by: Michal Simek <michal.simek(a)xilinx.com> --- include/configs/zynq-common.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/configs/zynq-common.h b/include/configs/zynq-common.h index 8c9768b6571e..884f3cf01c8e 100644 --- a/include/configs/zynq-common.h +++ b/include/configs/zynq-common.h @@ -14,6 +14,8 @@ # define CONFIG_CPU_FREQ_HZ 800000000 #endif +#define CONFIG_REMAKE_ELF + /* Cache options */ #define CONFIG_SYS_L2CACHE_OFF #ifndef CONFIG_SYS_L2CACHE_OFF -- 1.9.1

1 0

[U-Boot] [PATCH 0/4] Topic board support updates
by Mike Looijmans 22 Jan '19

22 Jan '19

There have been hardware changes to a few topic-miami boards, these are included in these commits (the production version of the "lite" became cheaper, the "plus" was made faster). Also improvements for usability. @Michal: These also apply cleanly to u-boot-xlnx, it'd be great if they could be included there as well. Mike Looijmans (4): topic-miamiplus: Run CPU at 800MHz for speedgrade-2 board: topic_miamilite: Support cost-reduced version configs/topic_miami.h: Use same partitioning for USB boot as for SD board: topic-miamiplus: Run IO PLL at 1000 MHz arch/arm/dts/zynq-topic-miamilite.dts | 7 +++-- arch/arm/dts/zynq-topic-miamiplus.dts | 9 ++++++ .../topic/zynq/zynq-topic-miamilite/ps7_init_gpl.c | 14 ++++----- board/topic/zynq/zynq-topic-miamilite/ps7_regs.txt | 14 ++++----- .../topic/zynq/zynq-topic-miamiplus/ps7_init_gpl.c | 34 ++++++++++------------ include/configs/topic_miami.h | 19 +++++++----- include/configs/topic_miamilite.h | 11 +++++++ 7 files changed, 65 insertions(+), 43 deletions(-) create mode 100644 include/configs/topic_miamilite.h -- 1.9.1

3 10

[U-Boot] Bad block present before NAND flash partition offset
by Madhu koriginja 22 Jan '19

22 Jan '19

Hi All, In my NAND flash one bad block present before some 'X' binary offset, after this binary partition kernel and rootfs partitions are present. In U-Boot when I access this x binary using the offset address it is not getting binary file content, because of one bad block the 'X' binary flashed in next block after the offset. I used nand_read and nand_read_skip_bad functions, nand_read_skip_bad function is handling if bad block present between offset and the length of the data required after offset. I want to know is there any function in existing u-boot source code to handle the above issue(if bad blocks present before offset)? If there is no provision, there are two ways to solve it 1. it is working if I change the offset value of 'X' binary in U-boot source code based on the no. of bad blocks present before offset 'X' binary. 2. Check the no. of bad blocks present before offset at run time and add those many bad blocks length to the offset. First method does not work if different boards NAND flash have bad blocks in different places, but second method handles this. With the second method, the changes in my specific code to access my 'X' binary, it does not affect common code. After this U-boot is failing to load kernel, because the same issue for kernel also, U-boot is reading the kernel image from the kernel offset, but the kernel image also flashed after 1 block due to 1 bad block. If I follow the above second method here also, I need to do change in "nand read" command function. But with this change it may create some confusion to others in situation like, if some one debugging and wants to read the content from some offset, if bad block present before this offset, it does not read exactly from that offset, it reads after that due to bad block because nand read function is modified above. I want to address this issue in general way, to solve the problem in dynamic way to handle different bad blocks can present in different boards and do not create confusion. Please comment. I am thinking in nand read function while displaying the content it should print from which address it is displaying, so that if they observe it they know it is displaying after the specified offset due to bad blocks, but people may miss to see the address print. Thanks.

1 1

Re: [U-Boot] [PATCH v3 5/5] doc: device-tree-bindings: switch from spi-flash to jedec, spi-nor
by Rick Chen 22 Jan '19

22 Jan '19

Hi Neil > > From: U-Boot [mailto:u-boot-bounces@lists.denx.de] On Behalf Of Neil > > Armstrong > > Sent: Tuesday, January 15, 2019 8:59 PM > > To: jagan(a)openedev.com; u-boot(a)lists.denx.de; > > simon.k.r.goldschmidt(a)gmail.com > > Cc: uboot-stm32(a)st-md-mailman.stormreply.com; trini(a)konsulko.com > > Subject: [U-Boot] [PATCH v3 5/5] doc: device-tree-bindings: switch from spi-flash > > to jedec, spi-nor > > > > Since all DTS files has been switched to "jedec,spi-nor", remove the "spi-flash" > > compatible from the bindings examples. > > > > Signed-off-by: Neil Armstrong <narmstrong(a)baylibre.com> > > Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt(a)gmail.com> > > --- for spi-atcspi200 > > diff --git a/doc/device-tree-bindings/spi/spi-atcspi200.txt > > b/doc/device-tree-bindings/spi/spi-atcspi200.txt > > index 9c0630b500..e67b3425f0 100644 > > --- a/doc/device-tree-bindings/spi/spi-atcspi200.txt > > +++ b/doc/device-tree-bindings/spi/spi-atcspi200.txt > > @@ -28,7 +28,7 @@ Example: > > clocks = <&spiclk>; > > interrupts = <3 4>; > > flash@0 { > > - compatible = "spi-flash"; > > + compatible = "jedec,spi-nor"; > > spi-max-frequency = <50000000>; > > reg = <0>; > > spi-cpol; > > spi-tx-bus-width = <4>; > > spi-rx-bus-width = <4>; > > -- Reviewed-by: Rick Chen <rick(a)andestech.com>

1 0

Re: [U-Boot] [PATCH v3 2/5] dts: switch spi-flash to jedec, spi-nor compatible
by Rick Chen 22 Jan '19

22 Jan '19

Hi Neil > > From: Neil Armstrong [mailto:narmstrong@baylibre.com] > > Sent: Tuesday, January 15, 2019 8:59 PM > > To: jagan(a)openedev.com; u-boot(a)lists.denx.de; > > simon.k.r.goldschmidt(a)gmail.com > > Cc: Neil Armstrong; uboot-stm32(a)st-md-mailman.stormreply.com; > > uboot-snps-arc(a)synopsys.com; philipp.tomsich(a)theobroma-systems.com; > > klaus.goger(a)theobroma-systems.com; monstr(a)monstr.eu; > > macpaul(a)andestech.com; sjg(a)chromium.org; Rick Jian-Zhi Chen(陳建志); > > bmeng.cn(a)gmail.com; trini(a)konsulko.com; Stefan Roese > > Subject: [PATCH v3 2/5] dts: switch spi-flash to jedec,spi-nor compatible > > > > There is no reason not to use the Linux "jedec,spi-nor" binding in U-Boot > > dts files. This compatible has been added in sf_probe, let use it. > > > > This patch switches to jedec,spi-nor when spi-flash is used in the DTS > > and DTSI files, and removed spi-flash when jedec,spi-nor is already > > present. > > > > The x86 dts are switched in a separate commit since it depends on a change > > in fdtdec. > > > > Signed-off-by: Neil Armstrong <narmstrong(a)baylibre.com> > > Acked-by: Stefan Roese <sr(a)denx.de> > > Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt(a)gmail.com> > > --- for nds32 and riscv > > arch/nds32/dts/ae3xx.dts | 2 +- > > arch/riscv/dts/ae350_32.dts | 2 +- > > arch/riscv/dts/ae350_64.dts | 2 +- Reviewed-by: Rick Chen <rick(a)andestech.com>

1 0

[U-Boot] Please pull u-boot-marvell/master
by Stefan Roese 22 Jan '19

22 Jan '19

Hi Tom, please pull the first Marvell patches in this merge window with the following changes: ---------------------------------------------------------------- - Sync Armada-38x dts with Linux 4.20 from Chris - Misc changes and enhancements to Turris Mox (v4) from Marek - Reserve PSCI area for Armada 8k from Heinrich - New Allied Telesis x530 board (Armada-385) from Chris - Misc minor changes (defconfig etc) ---------------------------------------------------------------- Thanks, Stefan The following changes since commit 2acc24fc28ef782f4baef1aa0193d520ee9610b9: Kconfig: Migrate BOUNCE_BUFFER (2019-01-19 09:49:26 -0500) are available in the Git repository at: git://www.denx.de/git/u-boot-marvell.git for you to fetch changes up to 0e31666dfa043ab71fb1fbbba4feacfe8af3e06b: ARM: mvebu: add support for Allied Telesis x530 (2019-01-21 11:39:50 +0100) ---------------------------------------------------------------- Baruch Siach (1): board: mvebu: drop unused ETH_PHY macro definitions Chris Packham (2): ARM: mvebu: sync Armada-38x dts with Linux 4.20 ARM: mvebu: add support for Allied Telesis x530 Heinrich Schuchardt (2): arm64: dts: marvell: armada-ap806: reserve PSCI area arm64: mvebu: defconfig: enable CONFIG_CMD_NVME Marek Behún (10): arm: mvebu: turris_mox: Cosmetic restructurization arm: mvebu: turris_mox: Change SERDES map depending on module topology arm: mvebu: turris_mox: Check and configure modules arm: mvebu: dts: Fix Turris Mox device tree arm: mvebu: turris_mox: Update defconfig watchdog: armada_37xx: Fix compliance with kernel's driver MAINTAINERS: Add entry for CZ.NIC's Turris project arm: mvebu: turris_mox: Read info (and ethaddrs) from OTP arm: mvebu: turris_mox: Support 1 GB version of Turris Mox arm: mvebu: configs: turris_mox: Add 64 MiB of boot memory MAINTAINERS | 8 + arch/arm/dts/Makefile | 4 +- arch/arm/dts/armada-3720-turris-mox.dts | 23 +- arch/arm/dts/armada-380.dtsi | 44 +-- arch/arm/dts/armada-385-atl-x530-u-boot.dtsi | 13 + arch/arm/dts/armada-385-atl-x530.dts | 50 +++ arch/arm/dts/armada-385-atl-x530.dtsi | 266 +++++++++++++++ arch/arm/dts/armada-385-atl-x530DP.dts | 51 +++ arch/arm/dts/armada-385-atl-x530DP.dtsi | 149 +++++++++ arch/arm/dts/armada-385.dtsi | 63 +--- arch/arm/dts/armada-388-clearfog.dts | 25 +- arch/arm/dts/armada-388.dtsi | 43 +-- arch/arm/dts/armada-38x-controlcenterdc.dts | 68 ++-- arch/arm/dts/armada-38x.dtsi | 283 +++++++++------- arch/arm/dts/armada-ap806.dtsi | 11 + arch/arm/mach-mvebu/Kconfig | 7 + arch/arm/mach-mvebu/arm64-common.c | 4 +- board/CZ.NIC/turris_mox/Makefile | 2 +- board/CZ.NIC/turris_mox/mox_sp.c | 136 ++++++++ board/CZ.NIC/turris_mox/mox_sp.h | 15 + board/CZ.NIC/turris_mox/turris_mox.c | 462 +++++++++++++++++++++++--- board/Marvell/db-88f6820-amc/db-88f6820-amc.c | 4 - board/Marvell/db-88f6820-gp/db-88f6820-gp.c | 4 - board/alliedtelesis/common/gpio_hog.c | 36 ++ board/alliedtelesis/common/gpio_hog.h | 13 + board/alliedtelesis/x530/MAINTAINERS | 12 + board/alliedtelesis/x530/Makefile | 9 + board/alliedtelesis/x530/kwbimage.cfg | 12 + board/alliedtelesis/x530/x530.c | 161 +++++++++ board/gdsys/a38x/controlcenterdc.c | 4 - board/kobol/helios4/helios4.c | 4 - board/solidrun/clearfog/clearfog.c | 4 - configs/clearfog_gt_8k_defconfig | 2 + configs/mvebu_db_armada8k_defconfig | 2 + configs/mvebu_mcbin-88f8040_defconfig | 2 + configs/turris_mox_defconfig | 6 + configs/x530_defconfig | 71 ++++ drivers/watchdog/armada-37xx-wdt.c | 109 +++--- include/configs/turris_mox.h | 2 + include/configs/x530.h | 134 ++++++++ 40 files changed, 1918 insertions(+), 400 deletions(-) create mode 100644 arch/arm/dts/armada-385-atl-x530-u-boot.dtsi create mode 100644 arch/arm/dts/armada-385-atl-x530.dts create mode 100644 arch/arm/dts/armada-385-atl-x530.dtsi create mode 100644 arch/arm/dts/armada-385-atl-x530DP.dts create mode 100644 arch/arm/dts/armada-385-atl-x530DP.dtsi create mode 100644 board/CZ.NIC/turris_mox/mox_sp.c create mode 100644 board/CZ.NIC/turris_mox/mox_sp.h create mode 100644 board/alliedtelesis/common/gpio_hog.c create mode 100644 board/alliedtelesis/common/gpio_hog.h create mode 100644 board/alliedtelesis/x530/MAINTAINERS create mode 100644 board/alliedtelesis/x530/Makefile create mode 100644 board/alliedtelesis/x530/kwbimage.cfg create mode 100644 board/alliedtelesis/x530/x530.c create mode 100644 configs/x530_defconfig create mode 100644 include/configs/x530.h

2 1

[U-Boot] dumpimage: failure on null-padded image dumps
by Chris Renshaw 22 Jan '19

22 Jan '19

Hi, I maintain the Android Image Kitchen project, which has U-Boot uImage support for the handfull of Android devices that use uImage for their boot.img/recovery.img format. This support is achieved using cross-compiles of U-Boot's dumpimage and mkimage tools, to all the Android NDK architectures, as well as macOS, Linux and Cygwin. My users have pointed out what appears to be a major flaw in dumpimage. Generally - on an Android device at least - a dump of a partition will be made with `dd if=/dev/block/*/*/by-name/boot of=boot.img` so this boot.img is the size of the entire partition, but dumpimage won't read/extract these, where freshly built images work fine. The reason for this appears to be that dumpimage can only handle images that are exactly the size they're supposed to be, and not a single byte more of even \x00 padding on the end; anything more and it seems to misinterpret the file as a GP image. Here's me demoing that: 10,485,760 uimage-untrimmed-gb-boot.img (dump from device boot partition) 5,110,936 uimage-trimmed-gb-boot.img (correct size) 5,110,937 uimage-extrabyte-gb-boot.img (single extra \x00 byte added to end) : dumpimage -l uimage-untrimmed-gb-boot.img GP Header: Size 27051956 LoadAddr 6116d3f2 : dumpimage -l uimage-trimmed-gb-boot.img Image Name: Linux-2.6.35 Created: Thu Apr 19 13:05:52 2012 Image Type: ARM Linux Multi-File Image (uncompressed) Data Size: 5110872 Bytes = 4991.09 KiB = 4.87 MiB Load Address: 80008000 Entry Point: 80008000 Contents: Image 0: 3367356 Bytes = 3288.43 KiB = 3.21 MiB Image 1: 1743504 Bytes = 1702.64 KiB = 1.66 MiB : dumpimage -l uimage-extrabyte-gb-boot.img GP Header: Size 27051956 LoadAddr 6116d3f2 I took a look at the dumpimage source and couldn't find where/why this could be happening so I'm hoping someone more familiar here could take a look and perhaps help with a fix. Thanks! Chris

1 0

[U-Boot] [PATCH 1/6] watchdog: bcm6345: switch to raw I/O functions
by Philippe Reynes 22 Jan '19

22 Jan '19

Signed-off-by: Philippe Reynes <philippe.reynes(a)softathome.com> --- drivers/watchdog/bcm6345_wdt.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/watchdog/bcm6345_wdt.c b/drivers/watchdog/bcm6345_wdt.c index e1bd73d..44f5662 100644 --- a/drivers/watchdog/bcm6345_wdt.c +++ b/drivers/watchdog/bcm6345_wdt.c @@ -32,8 +32,8 @@ static int bcm6345_wdt_reset(struct udevice *dev) { struct bcm6345_wdt_priv *priv = dev_get_priv(dev); - writel_be(WDT_CTL_START1_MASK, priv->regs + WDT_CTL_REG); - writel_be(WDT_CTL_START2_MASK, priv->regs + WDT_CTL_REG); + writel(WDT_CTL_START1_MASK, priv->regs + WDT_CTL_REG); + writel(WDT_CTL_START2_MASK, priv->regs + WDT_CTL_REG); return 0; } @@ -50,7 +50,7 @@ static int bcm6345_wdt_start(struct udevice *dev, u64 timeout, ulong flags) timeout = WDT_VAL_MAX; } - writel_be(timeout, priv->regs + WDT_VAL_REG); + writel(timeout, priv->regs + WDT_VAL_REG); return bcm6345_wdt_reset(dev); } @@ -64,8 +64,8 @@ static int bcm6345_wdt_stop(struct udevice *dev) { struct bcm6345_wdt_priv *priv = dev_get_priv(dev); - writel_be(WDT_CTL_STOP1_MASK, priv->regs + WDT_CTL_REG); - writel_be(WDT_CTL_STOP2_MASK, priv->regs + WDT_CTL_REG); + writel(WDT_CTL_STOP1_MASK, priv->regs + WDT_CTL_REG); + writel(WDT_CTL_STOP2_MASK, priv->regs + WDT_CTL_REG); return 0; } -- 2.7.4

2 6

[U-Boot] [RFC PATCH] bitops: Fix GENMASK definition for Sandbox
by Vignesh R 21 Jan '19

21 Jan '19

In arch/sandbox/include/asm/types.h we have Therefore for 32 bit Sandbox build BITS_PER_LONG turns out to be 32 as CONFIG_PHYS64 is not set This messes up the current logic of GENMASK macro due to mismatch b/w size of unsigned long (64 bit) and that of BITS_PER_LONG. Fix this by using CONFIG_SANDBOX_BITS_PER_LONG which is set to 64/32 based on the host machine on which its being compiled. Without this patch: GENMASK(14,0) => 0x7fffffffffff After this patch: GENMASK(14,0) => 0x7fff Signed-off-by: Vignesh R <vigneshr(a)ti.com> --- I marked it as RFC because, I am not really sure if I am running Sandbox tests properly. My host machine is x86_64 (Ubuntu 18.04). Running below command[1] with some of my yet to be upstreamed patches that use GENMASK macro shows this issue. [1]: $ make check include/linux/bitops.h | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/include/linux/bitops.h b/include/linux/bitops.h index a47f6d17bb5f..259df43fb00f 100644 --- a/include/linux/bitops.h +++ b/include/linux/bitops.h @@ -21,8 +21,13 @@ * position @h. For example * GENMASK_ULL(39, 21) gives us the 64bit vector 0x000000ffffe00000. */ +#ifdef CONFIG_SANDBOX +#define GENMASK(h, l) \ + (((~0UL) << (l)) & (~0UL >> (CONFIG_SANDBOX_BITS_PER_LONG - 1 - (h)))) +#else #define GENMASK(h, l) \ (((~0UL) << (l)) & (~0UL >> (BITS_PER_LONG - 1 - (h)))) +#endif #define GENMASK_ULL(h, l) \ (((~0ULL) << (l)) & (~0ULL >> (BITS_PER_LONG_LONG - 1 - (h)))) -- 2.20.1

2 3