July 2016 - U-Boot

[U-Boot] [PATCH] video: allow version string to be optional when using LOGO
by Tim Harvey 11 Jul '16

11 Jul '16

The CONFIG_HIDE_LOGO_VERSION config can be used to disable putting the U-Boot version string on top of the logo. Signed-off-by: Tim Harvey <tharvey(a)gateworks.com> --- README | 3 +++ drivers/video/cfb_console.c | 4 +++- 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/README b/README index d881da2..a820079 100644 --- a/README +++ b/README @@ -840,6 +840,9 @@ The following options need to be configured: CONFIG_CONSOLE_EXTRA_INFO additional board info beside the logo + CONFIG_HIDE_LOGO_VERSION + do not display bootloader + version string When CONFIG_CFB_CONSOLE_ANSI is defined, console will support a limited number of ANSI escape sequences (cursor control, diff --git a/drivers/video/cfb_console.c b/drivers/video/cfb_console.c index ef4984b..b2b4a35 100644 --- a/drivers/video/cfb_console.c +++ b/drivers/video/cfb_console.c @@ -1929,7 +1929,6 @@ static void plot_logo_or_black(void *screen, int x, int y, int black) static void *video_logo(void) { char info[128]; - int space, len; __maybe_unused int y_off = 0; __maybe_unused ulong addr; __maybe_unused char *s; @@ -1978,6 +1977,8 @@ static void *video_logo(void) sprintf(info, " %s", version_string); +#ifndef CONFIG_HIDE_LOGO_VERSION + int space, len; space = (VIDEO_LINE_LEN / 2 - VIDEO_INFO_X) / VIDEO_FONT_WIDTH; len = strlen(info); @@ -1990,6 +1991,7 @@ static void *video_logo(void) y_off = 1; } else video_drawstring(VIDEO_INFO_X, VIDEO_INFO_Y, (uchar *) info); +#endif #ifdef CONFIG_CONSOLE_EXTRA_INFO { -- 1.9.1

2 3

[U-Boot] [PATCH 1/2] spi: ti_qspi: Fix failure on multiple READ_ID cmd
by Vignesh R 11 Jul '16

11 Jul '16

Populating QSPI_RD_SNGL bit(0x1) in priv->cmd means that value QSPI_INVAL (0x4) is not written to CMD field of QSPI_SPI_CMD_REG in ti_qspi_cs_deactivate(). Therefore CS is never deactivated between successive READ ID which results in sf probe to fail. Fix this by not populating priv->cmd with QSPI_RD_SNGL and OR it wih priv->cmd as required (similar to the convention followed in the driver). Signed-off-by: Vignesh R <vigneshr(a)ti.com> --- drivers/spi/ti_qspi.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/spi/ti_qspi.c b/drivers/spi/ti_qspi.c index 9a372ad31dae..376fe378ed63 100644 --- a/drivers/spi/ti_qspi.c +++ b/drivers/spi/ti_qspi.c @@ -247,13 +247,12 @@ static int __ti_qspi_xfer(struct ti_qspi_priv *priv, unsigned int bitlen, debug("tx done, status %08x\n", status); } if (rxp) { - priv->cmd |= QSPI_RD_SNGL; debug("rx cmd %08x dc %08x\n", priv->cmd, priv->dc); #ifdef CONFIG_DRA7XX udelay(500); #endif - writel(priv->cmd, &priv->base->cmd); + writel(priv->cmd | QSPI_RD_SNGL, &priv->base->cmd); status = readl(&priv->base->status); timeout = QSPI_TIMEOUT; while ((status & QSPI_WC_BUSY) != QSPI_XFER_DONE) { -- 2.9.0

3 3

[U-Boot] drivers/crypto/fsl/Makefile: strange assignment
by Fabio Estevam 11 Jul '16

11 Jul '16

Hi Raul, In commit 0200020bc2b8192 ("imx6: Added DEK blob generator command") you did: diff --git a/drivers/crypto/fsl/Makefile b/drivers/crypto/fsl/Makefile index c0cf642..4aa91e4 100644 --- a/drivers/crypto/fsl/Makefile +++ b/drivers/crypto/fsl/Makefile @@ -8,5 +8,5 @@ obj-y += sec.o obj-$(CONFIG_FSL_CAAM) += jr.o fsl_hash.o jobdesc.o error.o -obj-$(CONFIG_CMD_BLOB) += fsl_blob.o +obj-$(CONFIG_CMD_BLOB)$(CONFIG_CMD_DEKBLOB) += fsl_blob.o ,which does not seem correct. Could you please take a look at this? Thanks

2 4

[U-Boot] [PATCH] git-mailrc: add rockchip alias
by jk 11 Jul '16

11 Jul '16

It's easier to Cc rockchip maintainers on rockchip-releated patches. Signed-off-by: jk <jk.kernel(a)gmail.com> --- doc/git-mailrc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/git-mailrc b/doc/git-mailrc index 1d6f4fc..8f0724f 100644 --- a/doc/git-mailrc +++ b/doc/git-mailrc @@ -76,7 +76,7 @@ alias tegra2 tegra alias ti uboot, trini alias uniphier uboot, masahiro alias zynq uboot, monstr - +alias rockchip uboot, sjg, Lin huang <hl(a)rock-chips.com> alias avr32 uboot, abiessmann alias bfin uboot, vapier, sonic -- 1.9.1

2 1

[U-Boot] [PATCH for v2016.07] mkimage -l is broken for images after gpimage
by Stefano Babic 11 Jul '16

11 Jul '16

Because a gpimage cannot be detected, a false GP header is printed instead of checking for further image types. Move gpimage as last to be linked, letting check all other image types and printing a GP header just in case no image is detected. Signed-off-by: Stefano Babic <sbabic(a)denx.de> --- tools/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/Makefile b/tools/Makefile index 63355aa..f72294a 100644 --- a/tools/Makefile +++ b/tools/Makefile @@ -76,8 +76,6 @@ dumpimage-mkimage-objs := aisimage.o \ lib/fdtdec.o \ fit_common.o \ fit_image.o \ - gpimage.o \ - gpimage-common.o \ common/image-fit.o \ image-host.o \ common/image.o \ @@ -100,6 +98,8 @@ dumpimage-mkimage-objs := aisimage.o \ zynqimage.o \ zynqmpimage.o \ $(LIBFDT_OBJS) \ + gpimage.o \ + gpimage-common.o \ $(RSA_OBJS-y) dumpimage-objs := $(dumpimage-mkimage-objs) dumpimage.o -- 1.9.1

2 1

[U-Boot] [PATCH for v2016.07] doc: ARMv8: add README.pine64
by Andre Przywara 11 Jul '16

11 Jul '16

Since we lack information about the DRAM initialization for the Allwinner A64 SoC, booting any A64 based board like the Pine64 is a bit involved at the moment. Add a README file to explain the process. Signed-off-by: Andre Przywara <andre.przywara(a)arm.com> --- Hi, is there any chance we can stuff this README still into the release? Cheers, Andre. doc/README.pine64 | 98 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 98 insertions(+) create mode 100644 doc/README.pine64 diff --git a/doc/README.pine64 b/doc/README.pine64 new file mode 100644 index 0000000..5553415 --- /dev/null +++ b/doc/README.pine64 @@ -0,0 +1,98 @@ +Pine64 board README +==================== + +The Pine64(+) is a single board computer equipped with an AArch64 capable ARMv8 +compliant Allwinner A64 SoC. +This chip has ARM Cortex A-53 cores and thus can run both in AArch32 +(compatible to 32-bit ARMv7) and AArch64 modes. Upon reset the SoC starts +in AArch32 mode and executes 32-bit code from the Boot ROM (BROM). +This has some implications on U-Boot. + +Quick start +============ +- Get hold of a boot0.img file (see below for more details). +- Get the boot0img tool source from the tools directory in [1] and compile + that on your host. +- Build U-Boot: +$ export CROSS_COMPILE=aarch64-linux-gnu- +$ make pine64_plus_defconfig +$ make +- You also need a compiled ARM Trusted Firmware (ATF) binary. Checkout the + "allwinner" branch from the github repository [2] and build it: +$ export CROSS_COMPILE=aarch64-linux-gnu- +$ make PLAT=sun50iw1p1 DEBUG=1 bl31 + The resulting binary is build/sun50iw1p1/debug/bl31.bin. + +Now put an empty (or disposable) micro SD card in your card reader and learn +its device file name, replacing /dev/sd<x> below with the result (that could +be /dev/mmcblk<x> as well): + +$ ./boot0img --device /dev/sd<x> -e -u u-boot.bin -B boot0.img \ + -d trampoline64:0x44000 -s bl31.bin -a 0x44008 -p 100 +(either copying the respective files to the working directory or specifying +the paths directly) + +This will create a new partition table (with a 100 MB FAT boot partition), +copies boot0.img, ATF and U-Boot to the proper locations on the SD card and +will fill in the magic Allwinner header to be recognized by boot0. +Prefix the above call with "sudo" if you don't have write access to the +uSD card. You can also use "-o output.img" instead of "--device /dev/sd<x>" +to create an image file and "dd" that to the uSD card. +Omitting the "-p" option will skip the partition table. + +Now put this uSD card in the board and power it on. You should be greeted by +the U-Boot prompt. + + +Main U-Boot +============ +The main U-Boot proper is a real 64-bit ARMv8 port and runs entirely in the +64-bit AArch64 mode. It can load any AArch64 code, EFI applications or arm64 +Linux kernel images (often named "Image") using the booti command. +Launching 32-bit code and kernels is technically possible, though not without +drawbacks (or hacks to avoid them) and currently not implemented. + +SPL support +============ +The main task of the SPL support is to bring up the DRAM controller and make +DRAM actually accessible. At the moment there is no documentation or source +code available which would do this. +There are currently two ways to overcome this situation: using a tainted 32-bit +SPL (involving some hacks and resulting in a non-redistributable binary, thus +not described here) or using the Allwinner boot0 blob. + +boot0 method +------------- +boot0 is Allwiner's secondary program loader and it can be used as some kind +of SPL replacement to get U-Boot up and running. +The binary is a 32 KByte blob and contained on every Pine64 image distributed +so far. It can be easily extracted from a micro SD card or an image file: +# dd if=/dev/sd<x> of=boot0.bin bs=8k skip=1 count=4 +where /dev/sd<x> is the device name of the uSD card or the name of the image +file. Apparently Allwinner allows re-distribution of this proprietary code +as-is. +For the time being this boot0 blob is the only redistributable way of making +U-Boot work on the Pine64. Beside loading the various parts of the (original) +firmware it also switches the core into AArch64 mode. +The original boot0 code looks for U-Boot at a certain place on an uSD card +(at 19096 KB), also it expects a header with magic bytes and a checksum. +There is a tool called boot0img[1] which takes a boot0.bin image and a compiled +U-Boot binary (plus other binaries) and will populate that header accordingly. +To make space for the magic header, the pine64_plus_defconfig will make sure +there is sufficient space at the beginning of the U-Boot binary. +boot0img will also take care of putting the different binaries at the right +places on the uSD card and works around unused, but mandatory parts by using +trampoline code. See the output of "boot0img -h" for more information. +boot0img can also patch boot0 to avoid loading U-Boot from 19MB, instead +fetching it from just behind the boot0 binary (-B option). + +FEL boot +========= +FEL is the name of the Allwinner defined USB boot protocol built-in the +mask ROM of most Allwinner SoCs. It allows to bootstrap a board solely +by using the USB-OTG interface and a host port on another computer. +Since FEL boot does not work with boot0, it requires the libdram hack, which +is not described here. + +[1] https://github.com/apritzel/pine64/ +[2] https://github.com/apritzel/arm-trusted-firmware.git -- 2.8.2

2 2

[U-Boot] [PATCH] imx6: clock: typo fix
by Peng Fan 11 Jul '16

11 Jul '16

Typo fix, "PPL2 -> PLL2" Signed-off-by: Peng Fan <peng.fan(a)nxp.com> Cc: Stefano Babic <sbabic(a)denx.de> --- arch/arm/cpu/armv7/mx6/clock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/cpu/armv7/mx6/clock.c b/arch/arm/cpu/armv7/mx6/clock.c index ff932aa..9b4b69c 100644 --- a/arch/arm/cpu/armv7/mx6/clock.c +++ b/arch/arm/cpu/armv7/mx6/clock.c @@ -281,7 +281,7 @@ static u32 mxc_get_pll_pfd(enum pll_clocks pll, int pfd_num) case PLL_BUS: if (!is_mx6ul()) { if (pfd_num == 3) { - /* No PFD3 on PPL2 */ + /* No PFD3 on PLL2 */ return 0; } } -- 2.6.2

2 1

[U-Boot] SPL on ZynqMP ZCU102 evaluation board
by Oleksy, Adam (Nokia - PL/Wroclaw) 11 Jul '16

11 Jul '16

Hi all I'm working with zynqmp evalutation board (zcu102 revB) and currently I rely on FSBL generated by petalinux and I'm thinking of dropping it ans using u-boot's SPL. I have spent some time trying to configure and use SPL, but I've stuck on booting up the board. I've prepared SD card as described here: http://lists.denx.de/pipermail/u-boot/2016-May/254902.html Boot process has end with following message: <debug_uart> Debug uart enabled U-Boot SPL 2016.07-rc3 (Jul 11 2016 - 13:13:28) EL Level: EL3 Trying to boot from MMC1 reading u-boot.bin "Synchronous Abort" handler, esr 0x96000010 ELR: fffc65d8 LR: fffc6530 x0 : 00000001ffff0eb0 x1 : 00000000ffff8181 x2 : 00000000ffff8ce8 x3 : 00000000ffff7ff0 x4 : 0000000000000000 x5 : 0000000000000000 x6 : 00000000ffff7d18 x7 : 000000000000000f x8 : 00000000ffff7b80 x9 : 0000000000000080 x10: 00000000ffff73f3 x11: 0000000000000000 x12: 00000000ffffffff x13: 00000000ffffffff x14: 00000000ffff7d6c x15: 00000000fffd34b0 x16: 665400000500c006 x17: d800b24018c0082c x18: 00000000ffff7e80 x19: 0000000000000058 x20: 00000000ffff8d30 x21: 00000000ffff8d30 x22: 0000000000000210 x23: 0000000000000200 x24: 00000000ffff7d18 x25: 00000000fffcf000 x26: 00000000fffd9b40 x27: 0000000000000001 x28: 8521b220c0c38d88 x29: 00000000ffff7200 Resetting CPU ... resetting ... I use u-boot 2016.07-rc3 with psu_init_gpl, which is also used in FSBL (and FSBL boot up board correctly). I suppose that the loading u-boot.bin to the RAM fails, because DDR controller is not initialized correctly. Probably I've forgotten enable something in .config, but I do not have idea what. Could somebody help me with this issue? If I forgot to add some information, please inform me. BR, Adam Oleksy

1 0

[U-Boot] [PATCH] driver/net/fec: support fixed speed connection
by Hannes Schmelzer 11 Jul '16

11 Jul '16

If MAC is directly connected to another MAC (like a switch for example) we don't need to probe for a phy, autoneogation and so on. We simply have to setup speed. Signed-off-by: Hannes Schmelzer <oe5hpm(a)oevsv.at> --- doc/README.fec_mxc | 5 +++++ drivers/net/fec_mxc.c | 4 ++++ 2 files changed, 9 insertions(+) diff --git a/doc/README.fec_mxc b/doc/README.fec_mxc index ed7e47d..9ca6ac2 100644 --- a/doc/README.fec_mxc +++ b/doc/README.fec_mxc @@ -27,6 +27,11 @@ CONFIG_FEC_MXC_PHYADDR Optional, selects the exact phy address that should be connected and function fecmxc_initialize will try to initialize it. +CONFIG_FEC_FIXED_SPEED + Optional, selects a fixed speed on the MAC interface without asking some + phy. This is usefull if there is a direct MAC <-> MAC connection, for + example if the CPU is connected directly via the RGMII interface to a + ethernet-switch. Reading the ethaddr from the SoC eFuses: if CONFIG_FEC_MXC is defined and the U-Boot environment does not contain the diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c index 360f8e4..e871b3e 100644 --- a/drivers/net/fec_mxc.c +++ b/drivers/net/fec_mxc.c @@ -233,6 +233,7 @@ static int miiphy_restart_aneg(struct eth_device *dev) return ret; } +#ifndef CONFIG_FEC_FIXED_SPEED static int miiphy_wait_aneg(struct eth_device *dev) { uint32_t start; @@ -260,6 +261,7 @@ static int miiphy_wait_aneg(struct eth_device *dev) return 0; } +#endif /* CONFIG_FEC_FIXED_SPEED */ #endif static int fec_rx_task_enable(struct fec_priv *fec) @@ -502,6 +504,8 @@ static int fec_open(struct eth_device *edev) } speed = fec->phydev->speed; } +#elif CONFIG_FEC_FIXED_SPEED + speed = CONFIG_FEC_FIXED_SPEED; #else miiphy_wait_aneg(edev); speed = miiphy_speed(edev->name, fec->phy_id); -- 1.9.1

4 3

[U-Boot] SPL on ZynqMP ZCU102 evaluation board
by Oleksy, Adam (Nokia - PL/Wroclaw) 11 Jul '16

11 Jul '16

Hi all I'm working with zynqmp evalutation board (zcu102 revB) and currently I rely on FSBL generated by petalinux and I'm thinking of dropping it ans using u-boot's SPL. I have spent some time trying to configure and use SPL, but I've stuck on booting up the board. I've prepared SD card as described here: http://lists.denx.de/pipermail/u-boot/2016-May/254902.html Boot process has end with following message: <debug_uart> Debug uart enabled U-Boot SPL 2016.07-rc3 (Jul 11 2016 - 13:13:28) EL Level: EL3 Trying to boot from MMC1 reading u-boot.bin "Synchronous Abort" handler, esr 0x96000010 ELR: fffc65d8 LR: fffc6530 x0 : 00000001ffff0eb0 x1 : 00000000ffff8181 x2 : 00000000ffff8ce8 x3 : 00000000ffff7ff0 x4 : 0000000000000000 x5 : 0000000000000000 x6 : 00000000ffff7d18 x7 : 000000000000000f x8 : 00000000ffff7b80 x9 : 0000000000000080 x10: 00000000ffff73f3 x11: 0000000000000000 x12: 00000000ffffffff x13: 00000000ffffffff x14: 00000000ffff7d6c x15: 00000000fffd34b0 x16: 665400000500c006 x17: d800b24018c0082c x18: 00000000ffff7e80 x19: 0000000000000058 x20: 00000000ffff8d30 x21: 00000000ffff8d30 x22: 0000000000000210 x23: 0000000000000200 x24: 00000000ffff7d18 x25: 00000000fffcf000 x26: 00000000fffd9b40 x27: 0000000000000001 x28: 8521b220c0c38d88 x29: 00000000ffff7200 Resetting CPU ... resetting ... I use u-boot 2016.07-rc3 with psu_init_gpl, which is also used in FSBL. I suppose that the loading u-boot.bin to the RAM fails, because DDR controller is not initialized correctly (I can be wrong:). Probably I've forgotten enable something in .config, but I do not have idea what. Could somebody help me with this issue? If I forgot to add some information, please inform me. BR, Adam Oleksy

1 0