February 2019 - U-Boot

[U-Boot] [PATCH 0/2] lib/vsprintf: print '?' for illegal Unicode sequence
by Heinrich Schuchardt 15 Feb '19

15 Feb '19

Commit 0e66c10a7d80 ("lib: vsprintf: avoid overflow printing UTF16 strings") broke the Unicode unit tests: an illegal UTF16 code point should be printed as '?'. Unfortunately the Unicode unit tests were never executed on Travis due to an unmet naming convention. So let's rename the Unicode test functions. Heinrich Schuchardt (2): lib/vsprintf: print '?' for illegal Unicode sequence test: adjust names of Unicode test functions lib/vsprintf.c | 2 + test/unicode_ut.c | 98 +++++++++++++++++++++++------------------------ 2 files changed, 51 insertions(+), 49 deletions(-) -- 2.20.1

1 2

[U-Boot] Porting to the HTG-Z920
by Patrick Schuetterle 15 Feb '19

15 Feb '19

Hello, I've been trying to compile U-boot for hi-tech global's HTG-Z920 board. It's SoC is the zynq ZU19EG ultrascale+. I'm mainly confused as to how I should configure Kbuild with the bare necessities -- UART, SD-LS, and DDR. I've managed to get things running via an FSBL generated with the xilinx sdk (ver. 2018.2), so I know it should be possible. Currently, I only receive the FSBL boot messages, even after enabling the early debug UART. I tried to match the addresses given by my hardware definition file (.hdf), but nothing's appearing. Should I try adapting one of the pre-set boards' configs (e.g. for the zcu104?), or are there some major pieces I'd still need? I also have the device tree derived from the .hdf file. Would it be simpler to use that? Any help you can spare would be greatly appreciated! Thanks in advance, -Patrick

1 0

[U-Boot] [PATCH v2 0/2] x530: Enable watchdog
by Chris Packham 15 Feb '19

15 Feb '19

We've seen some issues with the x530 under extreme conditions where the DDR gets into a bad state. Generally this results in an application crash followed by a lock-up in u-boot. Enabling the watchdog prevents the lock up and will let the DDR training have another go. Sometimes this recovers but even a reboot loop is better than a complete lockup. Changes in v2: - update commit message Chris Packham (2): watchdog: orion_wdt: support SPL usage arm: mvebu: x530: Enable watchdog in SPL and U-Boot arch/arm/dts/armada-385-atl-x530-u-boot.dtsi | 4 ++ board/alliedtelesis/x530/x530.c | 48 ++++++++++++++++++++ configs/x530_defconfig | 5 ++ drivers/watchdog/orion_wdt.c | 4 +- 4 files changed, 58 insertions(+), 3 deletions(-) -- 2.20.1

1 2

[U-Boot] [PATCH 0/2] x530: Enable watchdog
by Chris Packham 15 Feb '19

15 Feb '19

We've seen some issues with the x530 under extreme conditions where the DDR gets into a bad state. Generally this results in an application crash, kernel panic then a lock-up in u-boot (generally just as the SPL hands off to u-boot proper). Enabling the watchdog prevents the lock up and will let the DDR training have another go. Sometimes this recovers but even a reboot loop is better than a complete lockup. Chris Packham (2): watchdog: orion_wdt: support SPL usage arm: mvebu: x530: Enable watchdog in SPL and U-Boot arch/arm/dts/armada-385-atl-x530-u-boot.dtsi | 4 ++ board/alliedtelesis/x530/x530.c | 48 ++++++++++++++++++++ configs/x530_defconfig | 5 ++ drivers/watchdog/orion_wdt.c | 4 +- 4 files changed, 58 insertions(+), 3 deletions(-) -- 2.20.1

2 8

[U-Boot] PRs, Breakage architecture
by Stefano Babic 15 Feb '19

15 Feb '19

Hi Tom, my run on Travis reports errors with sun8i and sun50i (I do not think they are related to commits on u-boot-imx). I see on your travis that you have a "WIP-14Feb2019 u-boot-sunxi merged", and this runs succesfully (but not yet merged). So if I send a PR now, I have a broken run on Travis. What is your expectation I should do ? Simply send a PR because issues are known or wait until WIP-14Feb2019 goes to -master (but this means a rebase of u-boto-imx) ? Thanks, Stefano -- ===================================================================== DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic(a)denx.de =====================================================================

2 2

[U-Boot] [PATCH 1/3] videomodes: Allow EDID timings where hsync/vsync pulse is 0
by Priit Laes 15 Feb '19

15 Feb '19

From: Priit Laes <priit.laes(a)paf.com> Current EDID detailed timing parser errors out when either horizontal or vertical pulse sync width is 0, thus not allowing a display with EDID listed below work properly. Of-course, this is somewhat quirky HDMI display with following anti-features: - HPD pin is not usable - although resolution is 640x480, only top 240 pixels are visible $ xxd -p display.edid 00ffffffffffff0005a1e00301000000150f0103800f05780a0f6ea05748 9a2610474f200000010101010101010101010101010101012a08804520e0 0b1020004000953600000018000000fd0034441a2403000a202020202020 0000001000310a20202020202020202020200000001000002a4030701300 782d1100001e006b $ edid-decode display.edid EDID version: 1.3 Manufacturer: AMA Model 3e0 Serial Number 1 Digital display Maximum image size: 15 cm x 5 cm Gamma: 2.20 RGB color display First detailed timing is preferred timing Display x,y Chromaticity: Red: 0.6250, 0.3398 Green: 0.2841, 0.6044 Blue: 0.1494, 0.0644 White: 0.2802, 0.3105 Established timings supported: 640x480@60Hz 4:3 HorFreq: 31469 Hz Clock: 25.175 MHz Standard timings supported: Detailed mode: Clock 20.900 MHz, 149 mm x 54 mm 640 672 672 709 hborder 0 480 484 484 491 vborder 0 -hsync -vsync VertFreq: 60 Hz, HorFreq: 29478 Hz Monitor ranges (GTF): 52-68Hz V, 26-36kHz H, max dotclock 30MHz Dummy block Dummy block Checksum: 0x6b (valid) Signed-off-by: Priit Laes <priit.laes(a)paf.com> --- drivers/video/videomodes.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/video/videomodes.c b/drivers/video/videomodes.c index 74bafff011..1cfeaa980f 100644 --- a/drivers/video/videomodes.c +++ b/drivers/video/videomodes.c @@ -396,9 +396,7 @@ int video_edid_dtd_to_ctfb_res_modes(struct edid_detailed_timing *t, EDID_DETAILED_TIMING_VERTICAL_ACTIVE(*t) == 0 || EDID_DETAILED_TIMING_VERTICAL_BLANKING(*t) == 0 || EDID_DETAILED_TIMING_HSYNC_OFFSET(*t) == 0 || - EDID_DETAILED_TIMING_HSYNC_PULSE_WIDTH(*t) == 0 || EDID_DETAILED_TIMING_VSYNC_OFFSET(*t) == 0 || - EDID_DETAILED_TIMING_VSYNC_PULSE_WIDTH(*t) == 0 || /* 3d formats are not supported*/ EDID_DETAILED_TIMING_FLAG_STEREO(*t) != 0) return -EINVAL; -- 2.11.0

3 7

[U-Boot] [PATCH v1 0/4] Add STMFX gpio expander support for stm32mp157c-ev1 board
by Patrice Chotard 15 Feb '19

15 Feb '19

This series adds: - STMFX pinctrl driver - update STM32MP15 basic and trusted config - Add stmfx node in stm32mp157c-ev1 DT - Update stm32mp1 board to probe pinctrl drivers early to be able to hog pins. There are dependencies with : - http://patchwork.ozlabs.org/project/uboot/list/?series=92268 - http://patchwork.ozlabs.org/project/uboot/list/?series=91422 which must be merged first. Patrice Chotard (1): board: stm32mp1: Force pinctrl driver probe in board_init() Patrick Delaunay (3): pinctrl: Add STMFX GPIO expander Pinctrl/GPIO driver config: stm32mp15: Enable STMFX support ARM: dts: Add STMFX gpio expander support for stm32mp157c-ev1 arch/arm/dts/stm32mp157c-ev1-u-boot.dtsi | 3 + arch/arm/dts/stm32mp157c-ev1.dts | 18 ++ board/st/stm32mp1/stm32mp1.c | 9 + configs/stm32mp15_basic_defconfig | 5 +- configs/stm32mp15_trusted_defconfig | 5 +- drivers/pinctrl/Kconfig | 19 ++ drivers/pinctrl/Makefile | 1 + drivers/pinctrl/pinctrl-stmfx.c | 431 +++++++++++++++++++++++++++++++ 8 files changed, 487 insertions(+), 4 deletions(-) create mode 100644 drivers/pinctrl/pinctrl-stmfx.c -- 1.9.1

1 4

Re: [U-Boot] Clock drivers for SiFive FU540
by Simon Glass 15 Feb '19

15 Feb '19

On Thu, 14 Feb 2019 at 06:29, Anup Patel <Anup.Patel(a)wdc.com> wrote: > > Hi Simon, > > I have addressed your comments on fixed-factor clock driver. > > Can you please re-look at clock driver patches for SiFive FU540? > https://patchwork.ozlabs.org/patch/1039635/ > https://patchwork.ozlabs.org/patch/1039638/ > > Is it possible to include these patches for U-Boot-2019.04? > > Regards, > Anup

1 0

[U-Boot] [PATCH 0/4] Marvell DB-XC3-24G4XG board support
by Chris Packham 15 Feb '19

15 Feb '19

This series adds support for Marvell's Switches with integrated CPUs and the DB-XC3-24G4XG board. The CPU side is similar to the Armada range. For now the DDR training code needs to come from the Marvell bin_hdr. It's one area where the integrated SoCs differ from the Armada range so neither the Armada-XP nor Armada-38x training code will work as-is. I'm asking Marvell about the possibility of re-licensing the code under a Proprietary/BSD/GPL as they did with Armada-38x. I also have access to a DB-DXBC2-MM board with a different chip. I'll look at adding support for that as well at some point. It's harder to work with because it has no USB, but other than that it's similar to the DB-XC3. Chris Packham (4): arm: sync armada-xp dts files from Linux 5.0 arm: mvebu: Add Marvell's integrated CPUs arm: mvebu: NAND clock support for MSYS devices arm: mvebu: Add DB-XC3-24G4XG board arch/arm/dts/Makefile | 3 +- arch/arm/dts/armada-370-xp.dtsi | 133 ++++---- arch/arm/dts/armada-xp-98dx3236.dtsi | 343 ++++++++++++++++++++ arch/arm/dts/armada-xp-98dx3336.dtsi | 39 +++ arch/arm/dts/armada-xp-98dx4251.dtsi | 54 +++ arch/arm/dts/armada-xp-db-xc3-24g4xg.dts | 122 +++++++ arch/arm/dts/armada-xp-gp.dts | 167 ++++------ arch/arm/dts/armada-xp-maxbcm.dts | 24 +- arch/arm/dts/armada-xp-mv78230.dtsi | 55 +--- arch/arm/dts/armada-xp-mv78260.dtsi | 58 +--- arch/arm/dts/armada-xp-mv78460.dtsi | 58 +--- arch/arm/dts/armada-xp-synology-ds414.dts | 199 ++++++------ arch/arm/dts/armada-xp-theadorable.dts | 69 ++-- arch/arm/dts/armada-xp.dtsi | 214 ++++++------ arch/arm/mach-mvebu/Kconfig | 26 +- arch/arm/mach-mvebu/Makefile | 1 + arch/arm/mach-mvebu/cpu.c | 34 +- arch/arm/mach-mvebu/include/mach/config.h | 2 +- arch/arm/mach-mvebu/include/mach/cpu.h | 3 + arch/arm/mach-mvebu/include/mach/soc.h | 31 ++ board/Marvell/db-xc3-24g4xg/MAINTAINERS | 7 + board/Marvell/db-xc3-24g4xg/Makefile | 5 + board/Marvell/db-xc3-24g4xg/README | 4 + board/Marvell/db-xc3-24g4xg/binary.0 | 11 + board/Marvell/db-xc3-24g4xg/db-xc3-24g4xg.c | 71 ++++ board/Marvell/db-xc3-24g4xg/kwbimage.cfg | 12 + configs/db-xc3-24g4xg_defconfig | 55 ++++ drivers/ddr/marvell/axp/xor_regs.h | 4 + include/configs/db-xc3-24g4xg.h | 45 +++ tools/Makefile | 4 + tools/kwbimage.c | 4 + 31 files changed, 1310 insertions(+), 547 deletions(-) create mode 100644 arch/arm/dts/armada-xp-98dx3236.dtsi create mode 100644 arch/arm/dts/armada-xp-98dx3336.dtsi create mode 100644 arch/arm/dts/armada-xp-98dx4251.dtsi create mode 100644 arch/arm/dts/armada-xp-db-xc3-24g4xg.dts create mode 100644 board/Marvell/db-xc3-24g4xg/MAINTAINERS create mode 100644 board/Marvell/db-xc3-24g4xg/Makefile create mode 100644 board/Marvell/db-xc3-24g4xg/README create mode 100644 board/Marvell/db-xc3-24g4xg/binary.0 create mode 100644 board/Marvell/db-xc3-24g4xg/db-xc3-24g4xg.c create mode 100644 board/Marvell/db-xc3-24g4xg/kwbimage.cfg create mode 100644 configs/db-xc3-24g4xg_defconfig create mode 100644 include/configs/db-xc3-24g4xg.h -- 2.20.1

2 9

[U-Boot] [PATCH RESEND 6/6] doc: imx: habv4: Remove secure_boot.txt guide
by Breno Matheus Lima 15 Feb '19

15 Feb '19

The secure_boot.txt guide was replaced by mx6_mx7_secure_boot.txt and mx6_mx7_spl_secure_boot.txt documents. Both documents covers all steps needed for SPL and non-SPL tagets, so remove secure_boot.txt file to avoid duplicated content. Signed-off-by: Breno Lima <breno.lima(a)nxp.com> --- doc/imx/habv4/secure_boot.txt | 100 ---------------------------------- 1 file changed, 100 deletions(-) delete mode 100644 doc/imx/habv4/secure_boot.txt diff --git a/doc/imx/habv4/secure_boot.txt b/doc/imx/habv4/secure_boot.txt deleted file mode 100644 index ae68dc8040..0000000000 -- 2.17.1

1 0