April 2016 - U-Boot

[U-Boot] [RFC PATCH] arm, m68k: fix out-of-range jump
by Heiko Schocher 18 Apr '16

18 Apr '16

fix the following build error for m68k boards: Building current source for 48 boards (2 threads, 1 job per thread) m68k: + M54455EVB_i66 +arch/m68k/cpu/mcf5445x/start.o: In function `_start': +arch/m68k/cpu/mcf5445x/start.S:668:(.text+0x45a): relocation truncated to fit: R_68K_PC16 against symbol `board_init_f' defined in .text.board_init_f section in common/built-in.o +make[1]: *** [u-boot] Error 1 +make: *** [sub-make] Error 2 Signed-off-by: Heiko Schocher <hs(a)denx.de> --- This commit fixes build error: https://travis-ci.org/hsdenx/u-boot/jobs/123254183 fixed log see: https://travis-ci.org/hsdenx/u-boot/jobs/123281032 Any ideas why the changes did not work for: arch/m68k/cpu/mcf523x/start.S arch/m68k/cpu/mcf52x2/start.S arch/m68k/cpu/mcf532x/start.S but work for arch/m68k/cpu/mcf5445x/start.S I have no real m68k experiences, so help is appreciated! arch/m68k/cpu/mcf523x/start.S | 4 ++-- arch/m68k/cpu/mcf52x2/start.S | 4 ++-- arch/m68k/cpu/mcf532x/start.S | 4 ++-- arch/m68k/cpu/mcf5445x/start.S | 4 ++-- 4 files changed, 8 insertions(+), 8 deletions(-) diff --git a/arch/m68k/cpu/mcf523x/start.S b/arch/m68k/cpu/mcf523x/start.S index 8a23e72..ad7bde4 100644 --- a/arch/m68k/cpu/mcf523x/start.S +++ b/arch/m68k/cpu/mcf523x/start.S @@ -141,8 +141,8 @@ _start: move.l #__got_start, %a5 /* put relocation table address to a5 */ - bsr cpu_init_f /* run low-level CPU init code (from flash) */ - bsr board_init_f /* run low-level board init code (from flash) */ + jbsr cpu_init_f /* run low-level CPU init code (from flash) */ + jbsr board_init_f /* run low-level board init code (from flash) */ /* board_init_f() does not return */ diff --git a/arch/m68k/cpu/mcf52x2/start.S b/arch/m68k/cpu/mcf52x2/start.S index 8a59496..a16b589 100644 --- a/arch/m68k/cpu/mcf52x2/start.S +++ b/arch/m68k/cpu/mcf52x2/start.S @@ -198,8 +198,8 @@ _after_flashbar_copy: move.l #__got_start, %a5 /* put relocation table address to a5 */ - bsr cpu_init_f /* run low-level CPU init code (from flash) */ - bsr board_init_f /* run low-level board init code (from flash) */ + jbsr cpu_init_f /* run low-level CPU init code (from flash) */ + jbsr board_init_f /* run low-level board init code (from flash) */ /* board_init_f() does not return */ diff --git a/arch/m68k/cpu/mcf532x/start.S b/arch/m68k/cpu/mcf532x/start.S index 3b9ede0..50d301c 100644 --- a/arch/m68k/cpu/mcf532x/start.S +++ b/arch/m68k/cpu/mcf532x/start.S @@ -155,8 +155,8 @@ _start: move.l #__got_start, %a5 /* put relocation table address to a5 */ - bsr cpu_init_f /* run low-level CPU init code (from flash) */ - bsr board_init_f /* run low-level board init code (from flash) */ + jbsr cpu_init_f /* run low-level CPU init code (from flash) */ + jbsr board_init_f /* run low-level board init code (from flash) */ /* board_init_f() does not return */ diff --git a/arch/m68k/cpu/mcf5445x/start.S b/arch/m68k/cpu/mcf5445x/start.S index ae261b1..ff8d627 100644 --- a/arch/m68k/cpu/mcf5445x/start.S +++ b/arch/m68k/cpu/mcf5445x/start.S @@ -664,8 +664,8 @@ _start: move.l #__got_start, %a5 /* put relocation table address to a5 */ - bsr cpu_init_f /* run low-level CPU init code (from flash) */ - bsr board_init_f /* run low-level board init code (from flash) */ + jbsr cpu_init_f /* run low-level CPU init code (from flash) */ + jbsr board_init_f /* run low-level board init code (from flash) */ /* board_init_f() does not return */ -- 2.5.0

2 3

[U-Boot] what's the minimal amount needed to define two *very* closely-related boards?
by Robert P. J. Day 17 Apr '16

17 Apr '16

in the midst of current project wherein i've ported u-boot to two fairly old (and extremely similar) powerpc systems, i duplicated a lot of content just to get things up and running; now i want to go back and condense as much as possible and remove every bit of duplication i can, so a few questions about config files and so on. first (just out of curiosity), is there any relationship between the *name* of a defconfig file and the target system it represents? i'm well aware that all the defconfig files are normally given names that represent the target system, but is that *necessary*? as in, is any part of the defconfig file name extracted and used during the build process? or could i, in an absurd example, call my two defconfig files, say, "derp_defconfig" and "gorp_defconfig", as long as all the content is correct? next, are there any circumstances where one could reasonably use a single defconfig file to represent more than one target board? or is every distinct target board expected to have its own defconfig file? one example i see is the pair of defconfig files: * xilinx_zynqmp_zcu102_defconfig * xilinx_zynqmp_zcu102_revB_defconfig whose *only* difference is: 7c7 < CONFIG_DEFAULT_DEVICE_TREE="zynqmp-zcu102" --- > CONFIG_DEFAULT_DEVICE_TREE="zynqmp-zcu102-revB" in a corner case like this, i guess one *could* have a single defconfig file, and pass "DEVICE_TREE=..." on the command line to distinguish between them, but that's an unusual case. are there *any* circumstances that would justify trying to pack more than one target board into a single defconfig file? or is that (as i suspect) just silly? now as for defconfig files, what is the absolute minimum info they need contain? AFAICT, one needs at least three lines equivalent to: CONFIG_ARM=y (arch) CONFIG_ARCH_MX6=y (processor) CONFIG_TARGET_XPRESS=y (board) i realize some defconfig files contain a lot more, but it appears that any further content can go into the board definition file in include/configs, yes? i see defconfig files that define prompts, and commands, and so on, but can *all* of that go equally well into the board defn file? next, if one pushes all the board info into the header file and two boards have much the same content, i can see several cases where a "common" header file is created, such as, say, "zynq-common.h", so that again cuts down on duplication. finally, if i define a board vendor directory, say, board/rday/, i can define a further "common" directory, board/rday/common/, for any board common code. is that about it? am i missing any other tricks? thanks muchly. rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================

1 0

[U-Boot] [PATCH] splash_source: add support for ubifs formatted nand
by Eran Matityahu 17 Apr '16

17 Apr '16

Add support for loading splash image from NAND Flash formatted with a (UBI) filesystem. I'm a little ambivalent about this patch, as it adds support for a specific filesystem rather than a device, due to the nature of NAND and UBI, but it does make some sense to me to add a NAND filesystem option here. It would be nice to get your input about this. Signed-off-by: Eran Matityahu <eran.m(a)variscite.com> Cc: Igor Grinberg <grinberg(a)compulab.co.il> Cc: Tom Rini <trini(a)konsulko.com> Cc: Nikita Kiryanov <nikita(a)compulab.co.il> --- common/splash_source.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++---- include/splash.h | 6 ++++-- 2 files changed, 50 insertions(+), 6 deletions(-) diff --git a/common/splash_source.c b/common/splash_source.c index a09dd4b..7762ee8 100644 --- a/common/splash_source.c +++ b/common/splash_source.c @@ -120,6 +120,9 @@ static int splash_select_fs_dev(struct splash_location *location) case SPLASH_STORAGE_SATA: res = fs_set_blk_dev("sata", location->devpart, FS_TYPE_ANY); break; + case SPLASH_STORAGE_NAND: + res = fs_set_blk_dev("ubi", NULL, FS_TYPE_ANY); + break; default: printf("Error: unsupported location storage.\n"); return -ENODEV; @@ -163,6 +166,35 @@ static inline int splash_init_sata(void) } #endif +#ifdef CONFIG_CMD_UBIFS +static int splash_mount_ubifs(struct splash_location *location) +{ + int res; + char cmd[32]; + + sprintf(cmd, "ubi part %s", location->mtdpart); + res = run_command(cmd, 0); + if (res) + return res; + + sprintf(cmd, "ubifsmount %s", location->ubi_volume); + res = run_command(cmd, 0); + + return res; +} +#else +static inline int splash_mount_ubifs(struct splash_location *location) +{ + printf("Cannot load splash image: no UBIFS support\n"); + return -ENOSYS; +} +#endif + +static inline int splash_umount_ubifs(void) +{ + return run_command("ubifsumount", 0); +} + #define SPLASH_SOURCE_DEFAULT_FILE_NAME "splash.bmp" static int splash_load_fs(struct splash_location *location, u32 bmp_load_addr) @@ -181,26 +213,36 @@ static int splash_load_fs(struct splash_location *location, u32 bmp_load_addr) if (location->storage == SPLASH_STORAGE_SATA) res = splash_init_sata(); + if (location->storage == SPLASH_STORAGE_NAND) + res = splash_mount_ubifs(location); + if (res) return res; res = splash_select_fs_dev(location); if (res) - return res; + goto out; res = fs_size(splash_file, &bmp_size); if (res) { printf("Error (%d): cannot determine file size\n", res); - return res; + goto out; } if (bmp_load_addr + bmp_size >= gd->start_addr_sp) { printf("Error: splashimage address too high. Data overwrites U-Boot and/or placed beyond DRAM boundaries.\n"); - return -EFAULT; + res = -EFAULT; + goto out; } splash_select_fs_dev(location); - return fs_read(splash_file, bmp_load_addr, 0, 0, NULL); + res = fs_read(splash_file, bmp_load_addr, 0, 0, NULL); + +out: + if (location->storage == SPLASH_STORAGE_NAND) + splash_umount_ubifs(); + + return res; } /** diff --git a/include/splash.h b/include/splash.h index f0755ca..5c0da85 100644 --- a/include/splash.h +++ b/include/splash.h @@ -41,8 +41,10 @@ struct splash_location { char *name; enum splash_storage storage; enum splash_flags flags; - u32 offset; /* offset from start of storage */ - char *devpart; /* Use the load command dev:part conventions */ + u32 offset; /* Offset from start of storage */ + char *devpart; /* Use the load command dev:part conventions */ + char *mtdpart; /* MTD partition for ubi part */ + char *ubi_volume; /* UBI volume-name for ubifsmount */ }; int splash_source_load(struct splash_location *locations, uint size); -- 1.9.1

2 1

[U-Boot] couple questions about tail end of common/Makefile
by Robert P. J. Day 16 Apr '16

16 Apr '16

first, this related to CONFIG_FASTBOOT_FLASH: # This option is not just y/n - it can have a numeric value ifdef CONFIG_FASTBOOT_FLASH obj-y += image-sparse.o ifdef CONFIG_FASTBOOT_FLASH_MMC_DEV obj-y += fb_mmc.o endif ifdef CONFIG_FASTBOOT_FLASH_NAND_DEV obj-y += fb_nand.o endif endif i don't think CONFIG_FASTBOOT_FLASH ever makes use of being assigned a numeric value, does it? the top-level README file certainly doesn't seem to think so: CONFIG_FASTBOOT_FLASH The fastboot protocol includes a "flash" command for writing the downloaded image to a non-volatile storage device. Define this to enable the "fastboot flash" command. and it's never used in that context as far as I can tell: $ grep -rw CONFIG_FASTBOOT_FLASH * common/Makefile:ifdef CONFIG_FASTBOOT_FLASH drivers/usb/gadget/f_fastboot.c:#ifdef CONFIG_FASTBOOT_FLASH drivers/usb/gadget/f_fastboot.c:#ifdef CONFIG_FASTBOOT_FLASH drivers/usb/gadget/f_fastboot.c:#ifdef CONFIG_FASTBOOT_FLASH include/configs/kc1.h:#define CONFIG_FASTBOOT_FLASH include/configs/sniper.h:#define CONFIG_FASTBOOT_FLASH include/configs/bcm28155_ap.h:#define CONFIG_FASTBOOT_FLASH include/configs/sunxi-common.h:#define CONFIG_FASTBOOT_FLASH include/configs/dra7xx_evm.h:#define CONFIG_FASTBOOT_FLASH README: CONFIG_FASTBOOT_FLASH $ and second, just below that in common/Makefile (almost at the end): # We always have this since drivers/ddr/fs/interactive.c needs it obj-$(CONFIG_CMDLINE) += cli_simple.o obj-y += cli.o obj-$(CONFIG_CMDLINE) += cli_readline.o apart from the typo in that comment (should be "ddr/fsl", not "ddr/fs"), why does the comment insist that "We always have this" when that file is conditionally compiled? What does cli_simple.o have to do with that ddr-related source file? one suspects this could be simplified as: obj-y += cli.o obj-$(CONFIG_CMDLINE) += cli_simple.o cli_readline.o or something equally simple. or am i missing something? rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================

2 1

[U-Boot] [PATCH] ARM: rpi: fix 64-bit CONFIG_SYS_TEXT_BASE
by Stephen Warren 16 Apr '16

16 Apr '16

The Pi firmware has changed the default "kernel" load address for 64-bit mode. The authors have confirmed that this is a deliberate and long-term change. Adapt U-Boot to the new value. Signed-off-by: Stephen Warren <swarren(a)wwwdotorg.org> --- include/configs/rpi.h | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/include/configs/rpi.h b/include/configs/rpi.h index b83d622b9784..19ca606214d5 100644 --- a/include/configs/rpi.h +++ b/include/configs/rpi.h @@ -48,7 +48,11 @@ /* Memory layout */ #define CONFIG_NR_DRAM_BANKS 1 #define CONFIG_SYS_SDRAM_BASE 0x00000000 +#ifdef CONFIG_ARM64 +#define CONFIG_SYS_TEXT_BASE 0x00080000 +#else #define CONFIG_SYS_TEXT_BASE 0x00008000 +#endif #define CONFIG_SYS_UBOOT_BASE CONFIG_SYS_TEXT_BASE /* * The board really has 256M. However, the VC (VideoCore co-processor) shares -- 2.7.4

2 1

[U-Boot] Please pull u-boot-dm
by Simon Glass 16 Apr '16

16 Apr '16

Hi Tom, Unfortunately I'm still unable to apply many of the patches in my queue due to build errors. But in the meantime, here are the ones that are OK. The following changes since commit ff6552e8cc13c9b2283002144e297d63b30ac400: R xpress: Update <usb/ehci-fsl.h> include (2016-04-13 15:45:50 -0400) are available in the git repository at: git://git.denx.de/u-boot-dm.git for you to fetch changes up to 7e019daf7ab9dca3bf782d6de866b36d44ede95e: drivers/tpm/tpm_tis_sandbox.c: Fix uninitialized variable use (2016-04-15 08:14:37 -0600) ---------------------------------------------------------------- Jagan Teki (2): doc: driver-model: Update dm tests run using test.py board: README.sandbox: Update dm test command Nishanth Menon (1): dm: part: fix missing driver name in debug print Peng Fan (1): dm: core: device: set pinctrl state for pinctrl device Stefan Roese (1): dm: device.c: Minor coding-style fix Stephen Warren (1): fdt: implement dev_get_addr_name() Tom Rini (3): test/dm/core.c: Make pre-reloc test use pre-reloc struct sandbox: Enable many more commands drivers/tpm/tpm_tis_sandbox.c: Fix uninitialized variable use arch/sandbox/include/asm/cache.h | 1 + arch/sandbox/include/asm/io.h | 1 + board/sandbox/README.sandbox | 3 +- configs/sandbox_defconfig | 63 +++++++++++++++++++++++--- disk/part.c | 3 +- doc/driver-model/README.txt | 229 ++++++++++++++++++++++++++++++++++++++++++++++++++++----------------------------------------- drivers/core/device.c | 31 ++++++++++--- drivers/tpm/tpm_tis_sandbox.c | 2 +- include/dm/device.h | 12 +++++ test/dm/core.c | 2 +- 10 files changed, 230 insertions(+), 117 deletions(-) Regards, Simon

2 1

[U-Boot] [PATCH] jetson-tk1: Set fdtfile environment variable
by Andreas Färber 15 Apr '16

15 Apr '16

The 4.5.0 kernel cannot cope with U-Boot's internal device tree, and the distro boot commands are looking for $fdtfile, so provide it to avoid having users supply a dumb boot.scr doing a setenv fdtfile ...; boot, defeating the purpose of generic EFI boot. Cc: Stephen Warren <swarren(a)nvidia.com> Cc: Alexander Graf <agraf(a)suse.de> Signed-off-by: Andreas Färber <afaerber(a)suse.de> --- include/configs/jetson-tk1.h | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/include/configs/jetson-tk1.h b/include/configs/jetson-tk1.h index 59dbb20..82a4be4 100644 --- a/include/configs/jetson-tk1.h +++ b/include/configs/jetson-tk1.h @@ -63,6 +63,10 @@ /* General networking support */ #define CONFIG_CMD_DHCP +#define BOARD_EXTRA_ENV_SETTINGS \ + "fdtfile=tegra124-jetson-tk1.dtb\0" \ + "" + #include "tegra-common-usb-gadget.h" #include "tegra-common-post.h" -- 2.6.6

4 26

[U-Boot] [PATCH v2] fastboot: OUT transaction length must be aligned to wMaxPacketSize
by Steve Rae 15 Apr '16

15 Apr '16

commit 9e4b510 fastboot: OUT transaction length must be aligned to wMaxPacketSize breaks some boards... Therefore add a conditional Kconfig to optionally enable this feature. Signed-off-by: Steve Rae <srae(a)broadcom.com> --- Changes in v2: - ammendment to the original patch drivers/usb/gadget/Kconfig | 7 +++++++ drivers/usb/gadget/f_fastboot.c | 4 +++- 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig index f4698f4..ab1c605 100644 --- a/drivers/usb/gadget/Kconfig +++ b/drivers/usb/gadget/Kconfig @@ -33,3 +33,10 @@ menuconfig USB_GADGET a USB peripheral device. Configure one hardware driver for your peripheral/device side bus controller, and a "gadget driver" for your peripheral protocol. + +config USB_GADGET_FASTBOOT_DOWNLOAD_ALIGNMENT_REQUIRED + bool "fastboot download requires alignment with wMaxPacketSize" + help + By default, the fastboot download OUT transactions are aligned + to "ep->maxpacket". This option causes the fastboot download OUT + transactions to be aligned with "wMaxPacketSize". diff --git a/drivers/usb/gadget/f_fastboot.c b/drivers/usb/gadget/f_fastboot.c index 2e87fee..130b5d0 100644 --- a/drivers/usb/gadget/f_fastboot.c +++ b/drivers/usb/gadget/f_fastboot.c @@ -430,17 +430,19 @@ static void cb_getvar(struct usb_ep *ep, struct usb_request *req) static unsigned int rx_bytes_expected(unsigned int maxpacket) { int rx_remain = download_size - download_bytes; - int rem = 0; + int __maybe_unused rem = 0; if (rx_remain < 0) return 0; if (rx_remain > EP_BUFFER_SIZE) return EP_BUFFER_SIZE; +#ifdef CONFIG_USB_GADGET_FASTBOOT_DOWNLOAD_ALIGNMENT_REQUIRED if (rx_remain < maxpacket) { rx_remain = maxpacket; } else if (rx_remain % maxpacket != 0) { rem = rx_remain % maxpacket; rx_remain = rx_remain + (maxpacket - rem); } +#endif return rx_remain; } -- 1.8.5

9 29

[U-Boot] [PATCH] arm64: add missing gic_init_secure_percpu for non multi-entry
by Masahiro Yamada 15 Apr '16

15 Apr '16

Per-CPU initialization of GIC is necessary even when CONFIG_ARMV8_MULTIENTRY is undefined. Signed-off-by: Masahiro Yamada <yamada.masahiro(a)socionext.com> --- arch/arm/cpu/armv8/start.S | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S index dceedd7..124a274 100644 --- a/arch/arm/cpu/armv8/start.S +++ b/arch/arm/cpu/armv8/start.S @@ -208,6 +208,8 @@ WEAK(lowlevel_init) */ ldr x0, =GICD_BASE bl gic_init_secure + ldr x0, =GICR_BASE + bl gic_init_secure_percpu #endif #else /* CONFIG_ARMV8_MULTIENTRY is set */ #if defined(CONFIG_GICV2) || defined(CONFIG_GICV3) -- 1.9.1

2 2

[U-Boot] [PATCH] fdt: implement dev_get_addr_name()
by Stephen Warren 15 Apr '16

15 Apr '16

From: Stephen Warren <swarren(a)nvidia.com> This function parses the reg property based on an index found in the reg-names property. This is required for bindings that are written using reg-names rather than hard-coding indices in reg. Signed-off-by: Stephen Warren <swarren(a)nvidia.com> --- drivers/core/device.c | 16 ++++++++++++++++ include/dm/device.h | 12 ++++++++++++ 2 files changed, 28 insertions(+) diff --git a/drivers/core/device.c b/drivers/core/device.c index cb24a617ceef..87755f514ba4 100644 --- a/drivers/core/device.c +++ b/drivers/core/device.c @@ -649,6 +649,22 @@ fdt_addr_t dev_get_addr_index(struct udevice *dev, int index) #endif } +fdt_addr_t dev_get_addr_name(struct udevice *dev, const char *name) +{ +#if CONFIG_IS_ENABLED(OF_CONTROL) + int index; + + index = fdt_find_string(gd->fdt_blob, dev->parent->of_offset, + "reg-names", name); + if (index < 0) + return index; + + return dev_get_addr_index(dev, index); +#else + return FDT_ADDR_T_NONE; +#endif +} + fdt_addr_t dev_get_addr(struct udevice *dev) { return dev_get_addr_index(dev, 0); diff --git a/include/dm/device.h b/include/dm/device.h index 1cf81501ed92..dad7591dfacb 100644 --- a/include/dm/device.h +++ b/include/dm/device.h @@ -465,6 +465,18 @@ fdt_addr_t dev_get_addr(struct udevice *dev); fdt_addr_t dev_get_addr_index(struct udevice *dev, int index); /** + * dev_get_addr_name() - Get the reg property of a device, indexed by name + * + * @dev: Pointer to a device + * @name: the 'reg' property can hold a list of <addr, size> pairs, with the + * 'reg-names' property providing named-based identification. @index + * indicates the value to search for in 'reg-names'. + * + * @return addr + */ +fdt_addr_t dev_get_addr_name(struct udevice *dev, const char *name); + +/** * device_has_children() - check if a device has any children * * @dev: Device to check -- 2.8.1

2 2