January 2019 - U-Boot

[U-Boot] [PATCH] arm: stm32mp1: deploy spl in root folder
by Patrick Delaunay 30 Jan '19

30 Jan '19

Update generation of spl binaries - continue to generate all SPL files in spl sub-directory - copy in root folder the needed file for user (YOCTO, buildroot): u-boot-spl.stm32 Signed-off-by: Patrick Delaunay <patrick.delaunay(a)st.com> --- Hi, This patch update http://patchwork.ozlabs.org/patch/1020706 already merged in u-boot/master. In fact, it is my v2 proposal to avoid to change the current behavior: I prefer to keep all the spl generation in spl directory but I agree to copy the generated file in root folder: it can be easier for end-user. This patch avoid to break current behavior, and current upstream effort of stm32mp1 bsp in YOCTO. Patrick arch/arm/mach-stm32mp/config.mk | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-stm32mp/config.mk b/arch/arm/mach-stm32mp/config.mk index 124729c..f371aac 100644 --- a/arch/arm/mach-stm32mp/config.mk +++ b/arch/arm/mach-stm32mp/config.mk @@ -7,7 +7,10 @@ ALL-$(CONFIG_SPL_BUILD) += u-boot-spl.stm32 MKIMAGEFLAGS_u-boot-spl.stm32 = -T stm32image -a $(CONFIG_SPL_TEXT_BASE) -e $(CONFIG_SPL_TEXT_BASE) -u-boot-spl.stm32: MKIMAGEOUTPUT = u-boot-spl.stm32.log +spl/u-boot-spl.stm32: MKIMAGEOUTPUT = spl/u-boot-spl.stm32.log -u-boot-spl.stm32: spl/u-boot-spl.bin FORCE +spl/u-boot-spl.stm32: spl/u-boot-spl.bin FORCE $(call if_changed,mkimage) + +u-boot-spl.stm32 : spl/u-boot-spl.stm32 + $(call if_changed,copy) -- 2.7.4

3 2

[U-Boot] [PULL u-boot] Please pull u-boot-amlogic-20190129
by Neil Armstrong 30 Jan '19

30 Jan '19

Hi Tom, Here is single patch adding support for pinconf on the amlogic pinctrl driver, fixed after a build failure report from Anatolij. This PR replaces u-boot-amlogic-20190128. Thanks, Neil The following changes since commit 0da90255083681a02b24528f80da9d4062ff634a: Merge branch '2019-01-25-master-imports' (2019-01-26 22:47:55 -0500) are available in the Git repository at: git://git.denx.de/u-boot-amlogic.git tags/u-boot-amlogic-20190129 for you to fetch changes up to c4c726c26bdc09a2c907e230fdf6c75adcc2b674: pinctrl: meson: add pinconf support (2019-01-29 11:19:15 +0100) ---------------------------------------------------------------- Adds pinconf support for the Amlogic pinctrl driver (fixed) ---------------------------------------------------------------- Jerome Brunet (1): pinctrl: meson: add pinconf support drivers/pinctrl/meson/Kconfig | 1 + drivers/pinctrl/meson/pinctrl-meson-axg-pmx.c | 10 +++ drivers/pinctrl/meson/pinctrl-meson-gx-pmx.c | 10 +++ drivers/pinctrl/meson/pinctrl-meson.c | 101 ++++++++++++++++++++++++-- drivers/pinctrl/meson/pinctrl-meson.h | 8 ++ 5 files changed, 123 insertions(+), 7 deletions(-)

2 1

[U-Boot] input in flex scanner failed (for rpi_0_w_defconfig)
by Belisko Marek 30 Jan '19

30 Jan '19

Hi, I'm trying to build u-boot in docker on osx (installed build-essentials + gcc-arm) but hit this issue (with verbose make) during config phase. I tried same on linux and it works fine. Any ideas what can cause this (or how to debug)? make ARCH=arm rpi_0_w_defconfig V=1 make -f ./scripts/Makefile.build obj=scripts/basic cc -Wp,-MD,scripts/basic/.fixdep.d -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/basic/fixdep scripts/basic/fixdep.c rm -f .tmp_quiet_recordmcount make -f ./scripts/Makefile.build obj=scripts/kconfig rpi_0_w_defconfig cc -Wp,-MD,scripts/kconfig/.conf.o.d -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -DCURSES_LOC="<curses.h>" -DLOCALE -c -o scripts/kconfig/conf.o scripts/kconfig/conf.c cc -Wp,-MD,scripts/kconfig/.zconf.tab.o.d -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -DCURSES_LOC="<curses.h>" -DLOCALE -Iscripts/kconfig -c -o scripts/kconfig/zconf.tab.o scripts/kconfig/zconf.tab.c cc -o scripts/kconfig/conf scripts/kconfig/conf.o scripts/kconfig/zconf.tab.o scripts/kconfig/conf --defconfig=arch/../configs/rpi_0_w_defconfig Kconfig input in flex scanner failed scripts/kconfig/Makefile:121: recipe for target 'rpi_0_w_defconfig' failed make[1]: *** [rpi_0_w_defconfig] Error 2 Makefile:478: recipe for target 'rpi_0_w_defconfig' failed make: *** [rpi_0_w_defconfig] Error 2 BR, marek -- as simple and primitive as possible ------------------------------------------------- Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com

2 1

[U-Boot] [PATCH v1 0/3] Add support for symlink creation in EXT4
by Jean-Jacques Hiblot 30 Jan '19

30 Jan '19

This series adds support for the creation of symbolic links on ext4 file-systems. The motivation behind this work is to have the ability to "do" the job of update-alternatives in u-boot. Firmware on TI's platform are usually managed with update-alternatives and are thus targeted by a symbolic link. In some situations we need the ability to select an alternate firmware before the linux kernel is started so that when a early driver needing the firmware comes up, it can be fed the firmware of our choice. Tested on a am57xx_evm, using a EXT4 partition on external SDcard. The filesystem can be checked later with: fsck.ext4 -f <dev> usage example: => ln mmc 0:2 zImage /boot/the_linux_kernel Jean-Jacques Hiblot (3): fs: ext4: constify the buffer passed to write functions fs: ext4: Add support for the creation of symbolic links fs: Add a new command to create symbolic links cmd/fs.c | 14 ++++++++++++ fs/ext4/ext4_common.c | 6 ++--- fs/ext4/ext4_common.h | 2 +- fs/ext4/ext4_write.c | 51 ++++++++++++++++++++++++++++++++----------- fs/fs.c | 44 +++++++++++++++++++++++++++++++++++++ include/ext4fs.h | 5 +++-- include/fs.h | 2 ++ 7 files changed, 105 insertions(+), 19 deletions(-) -- 2.17.1

3 5

[U-Boot] Two u boot environment on eMMC
by Сергей Сахно 30 Jan '19

30 Jan '19

Hello everyone. I have one question: do i can use two u boot environment on eMMC in raw mode? If yes, how?

2 1

[U-Boot] U-Boot OMAP3 memory map potential issues/questions
by Adam Ford 29 Jan '19

29 Jan '19

I am trying to track down the memory map and what I believe to be some memory corruption in SPL. I have a few findings that I am not sure are issues or not, so I am hoping someone who know the OMAP3 family better might shed some light on it. Looking at README.omap3, I can see two suggested maps, one for SPL and one for SPL & X-Loader. It shows SRAM 0x40200000 - 0x4020FFFF. Both of tables show: 0x40200800 - 0x4020BBFF: Area for SPL text, data and rodata 0x4020E000 - 0x4020FFFC: Area for the SPL stack. Looking at arch/arm/include/asm/arch-omap3/omap.h, it seems like it's defining the beginning of SRAM to be NON_SECURE_SRAM_START 0x40208000 I wonder if this should be 0x40200800 instead.? Question 2: That same file defines SRAM_SCRATCH_SPACE_ADDR as the top 1K of RAM down from NON_SECURE_SRAM_IMG_END We then point OMAP3_PUBLIC_SRAM_SCRATCH_AREA to NON_SECURE_SRAM_START I am wondering if OMAP3_PUBLIC_SRAM_SCRATCH_AREA should point to SRAM_SCRATCH_SPACE_ADDR instead. Currently, the reference to OMAP3_PUBLIC_SRAM_SCRATCH_AREA is checked in arch/arm/mach-omap2/boot-common.c aginst NON_SECURE_SRAM_START and NON_SECURE_SRAM_END to make sure the data is inside a valid memory address. Since OMAP3_PUBLIC_SRAM_SCRATCH_AREA is already defined to be NON_SECURE_SRAM_START, this comparison seems like it would be unnecessary, however if we're going to point boot_params to this address it seems like other data written/stored to NON_SECURE_SRAM_START would be over written. I think it would be safer to point SRAM_SCRATCH_SPACE_ADDR so we don't clobber data that the linker may be putting there. Any thoughts? Third Question: I noticed a bunch of boards, including my own, un-define CONFIG_SPL_TEXT_BASE and redefine it to 0x40200000. It seems like it would give us 2k of SRAM. I 'think' making all boards use 0x40200000 instead of 40200800 is a bad idea, especially for secure parts. Since there is a flag called CONFIG_TI_SECURE_DEVICE. I would like to propse using it to set the CONFIG_SPL_TEXT_BASE to 0x40200000 if is not set. Would that be acceptable? This way, we can dump the extra lines of code in the board files hat undef this and redefine it. I also wonder if the same could be said about NON_SECURE_SRAM_START depending on th answers to questions 1 and 3. I have more questions, but I'll start there. Thanks adam

1 0

[U-Boot] [PATCH] sunxi: amarula_a64_relic: Enable USB host
by Jagan Teki 29 Jan '19

29 Jan '19

Enable USB host controllers for Amarula A64-Relic board, the respective nodes are already present in DTS. Signed-off-by: Jagan Teki <jagan(a)amarulasolutions.com> --- configs/amarula_a64_relic_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/amarula_a64_relic_defconfig b/configs/amarula_a64_relic_defconfig index f5857cfbb3..2e6011fa45 100644 --- a/configs/amarula_a64_relic_defconfig +++ b/configs/amarula_a64_relic_defconfig @@ -11,5 +11,7 @@ CONFIG_NR_DRAM_BANKS=1 # CONFIG_SPL_DOS_PARTITION is not set # CONFIG_SPL_EFI_PARTITION is not set CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-amarula-relic" +CONFIG_USB_OHCI_HCD=y +CONFIG_USB_EHCI_HCD=y CONFIG_USB_MUSB_GADGET=y CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y -- 2.18.0.321.gffc6fa0e3

1 1

[U-Boot] [PATCH] sunxi: A64: pinebook-u-boot: Include sunxi-u-boot.dtsi
by Jagan Teki 29 Jan '19

29 Jan '19

Like other Allwinner A64 boards, pinebook also need altering auto-numbering of mmc2 to mmc1 which is available in common sunxi dsti file, sunxi-u-boot.dtsi Pinebook has a separate sun50i-a64-pinebook-u-boot.dtsi which takes more precedence for u-boot.dtsi inclusion and it eventually failed to include the sunxi-u-boot.dtsi. So, this patch add support to include the sunxi-u-boot.dtsi in the sun50i-a64-pinebook-u-boot.dtsi Signed-off-by: Jagan Teki <jagan(a)amarulasolutions.com> --- arch/arm/dts/sun50i-a64-pinebook-u-boot.dtsi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/dts/sun50i-a64-pinebook-u-boot.dtsi b/arch/arm/dts/sun50i-a64-pinebook-u-boot.dtsi index a99b7171d0..650ab97ec9 100644 --- a/arch/arm/dts/sun50i-a64-pinebook-u-boot.dtsi +++ b/arch/arm/dts/sun50i-a64-pinebook-u-boot.dtsi @@ -4,6 +4,8 @@ * */ +#include "sunxi-u-boot.dtsi" + /* The ANX6345 eDP-bridge is on r_i2c */ &r_i2c { anx6345: edp-bridge@38 { -- 2.18.0.321.gffc6fa0e3

2 2

[U-Boot] [PATCH v3.1 9/9] arm: dts: sunxi: Alter mmc2 auto-numbering to mmc1
by Jagan Teki 29 Jan '19

29 Jan '19

Environment and fastboot mmc devices are configured based on the number of mmc slots defined on particular board configs, MMC_SUNXI_SLOT_EXTRA. If MMC_SUNXI_SLOT_EXTRA is more than 1, the default env and fastboot mmc devices is mmc1 by assuming mmc0 is SD and mmc1 is emmc device. But with DM_MMC the mmc devices are numbered as per the dts node enablement. If there is a chance of having enabling all mmc nodes in dts say mmc0, mmc1, mmc2 then the default env and fastboot devices will failed to assign proper emmc device since mmc2 is emmc in most of the Allwinner platforms. So, we need to alter the auto-numbering by aliasing mmc2 to mmc1 since aliases take precedence over auto-numbering. If the dts enables mmc0, mmc1, mmc2, then all the nodes will probe sequentially and auto-numbered as it is. but when aliases mmc1 with mmc2 the resulting number should be that mmc0 is till mmc0, mmc2 become mmc1 and mmc2 become mmc1 Without aliases of mmc1 = &mmc2; ================================ MMC: mmc@1c0f000: 0, mmc@1c10000: 1, mmc@1c11000: 2 With aliases of mmc1 = &mmc2; ================================ MMC: Device 'mmc@1c11000': seq 1 is in use by 'mmc@1c10000' mmc@1c0f000: 0, mmc@1c10000: 2, mmc@1c11000: 1 Loading Environment from FAT... OK Some platforms like A20 has mmc0...mmc3, but there is no usecases now for enabling all mmc controllers in any of A20 board dts files. Signed-off-by: Jagan Teki <jagan(a)amarulasolutions.com> --- Changes for v3.1: - add proper commit message details along with example of how aliases alter the mmc numbering. arch/arm/dts/sunxi-u-boot.dtsi | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/arm/dts/sunxi-u-boot.dtsi b/arch/arm/dts/sunxi-u-boot.dtsi index 8a9f2a6417..fdd4c80aa4 100644 --- a/arch/arm/dts/sunxi-u-boot.dtsi +++ b/arch/arm/dts/sunxi-u-boot.dtsi @@ -1,6 +1,10 @@ #include <config.h> / { + aliases { + mmc1 = &mmc2; + }; + binman { filename = "u-boot-sunxi-with-spl.bin"; pad-byte = <0xff>; -- 2.18.0.321.gffc6fa0e3

1 1

[U-Boot] Probing flash before Env setup (Env in UBI)
by Dominik Vogt 29 Jan '19

29 Jan '19

Hi folks, I'm new to uboot and couldn't figure out how to get "CONFIG_ENV_IS_IN_UBI" to work (on a nor flash) yet. Basically, ubi and ubifs work fine. The mtd device (a nor flash) is supported and works. It is formatted with ubiformat and contains two volumes with a ubifs on each of them. The "partition" is named "nor0" and the volumes are "env-uboot" and "env-uboot-redund". -- Now, when the board boots, it tries to load the envorinment and fails: -- snip -- Loading Environment from SPI Flash... SF: Detected n25q128 with page size 256 Bytes, erase size 64 KiB, total 16 MiB *** Warning - bad CRC, using default environment Loading Environment from UBI... Partition nor0 not found! ** Cannot find mtd partition "nor0" -- snip -- The first line looks like the output from "sf probe", but "mtd list" just says: List of MTD devices: No MTD device found Well, I guess I just have to run sf probe ubi part nor0 before loading he environment, but I couldn't figure out how to do that, except by adding some C code to board_init_f(). Ciao Dominik ^_^ ^_^ -- Dominik Vogt

1 0