March 2016 - U-Boot

[U-Boot] [PATCH] ARM: zynq: zybo: Enabling reading MAC address from EEPROM
by Michal Simek 31 Mar '16

31 Mar '16

From: Michal Simek <monstr(a)monstr.eu> Zybo has on board I2C EEPROM which contains preprogrammed MAC address. Signed-off-by: Michal Simek <monstr(a)monstr.eu> Signed-off-by: Michal Simek <michal.simek(a)xilinx.com> --- include/configs/zynq_zybo.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/configs/zynq_zybo.h b/include/configs/zynq_zybo.h index 0882fe36bd82..637b1c5ffe91 100644 --- a/include/configs/zynq_zybo.h +++ b/include/configs/zynq_zybo.h @@ -17,6 +17,9 @@ #define CONFIG_ZYNQ_I2C0 #define CONFIG_ZYNQ_I2C1 #define CONFIG_SYS_I2C_EEPROM_ADDR_LEN 1 +#define CONFIG_CMD_EEPROM +#define CONFIG_ZYNQ_GEM_EEPROM_ADDR 0x50 +#define CONFIG_ZYNQ_GEM_I2C_MAC_OFFSET 0xFA #define CONFIG_DISPLAY #define CONFIG_I2C_EDID -- 1.9.1

1 0

[U-Boot] Tegra-specific header file location
by Stephen Warren 31 Mar '16

31 Mar '16

Masahiro, I'm about to work on some refactoring of the Tegra-specific header files in U-Boot to enable support for another Tegra variant. I'd like to confirm where you think header files should be located before doing that. I believe you want Tegra-specific headers moved into arch/arm/mach-tegra/include. That would probably be a good location for headers currently in arch/arm/include/asm/arch-tegra/. Does that sound correct to you? What about SoC-specific headers currently in arch/arm/include/asm/arch-tegraNNN/; should they move to arch/arm/mach-tegra/tegraNNN/include? A number of those header files primarily contain driver-internal definitions such as HW register layouts. I'd like to propose moving this private information into the relevant drivers/ directories where the driver implementation already is. There is no need to place it in an include directory where any C file could include it. For example, 99% of arch/arm/include/asm/arch-tegra/tegra_mmc.h might move to drivers/mmc/tegra_mmc_{priv,internal}.h or even into drivers/mmc/tegra_mmc.c itself. The only thing that wouldn't move is the public prototype for pad_init_mmc(); a function the MMC driver calls and board code is expected to implement. I am considering making a single header that defines all those Tegra-specific function prototypes so we can reduce the number of header files too. What do you think about this.

2 1

Re: [U-Boot] [PATCH] arm: Fix order of CSU indexes in ns_access.h
by Huan Wang 31 Mar '16

31 Mar '16

> -------- Original Message -------- > Subject: [PATCH] arm: Fix order of CSU indexes in ns_access.h > Date: 03/29/2016 12:41 AM > From: Vincent Siles <vincent.siles(a)provenrun.com> > To: u-boot(a)lists.denx.de <u-boot(a)lists.denx.de> > CC: vincent.siles(a)provenrun.com <vincent.siles(a)provenrun.com>, > yorksun(a)freescale.com <yorksun(a)freescale.com>, Mingkai Hu > <Mingkai.Hu(a)freescale.com>, Gong Qianyu <Qianyu.Gong(a)freescale.com>, > Albert Aribaud <albert.u.boot(a)aribaud.net>, Hou Zhiqiang > <B48286(a)freescale.com> > > This patch aims to fix the order of CSU slave index for the LS1021a > board. > > Signed-off-by: Vincent Siles <vincent.siles(a)provenrun.com> > > --- > > arch/arm/include/asm/arch-ls102xa/ns_access.h | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/arch/arm/include/asm/arch-ls102xa/ns_access.h > b/arch/arm/include/asm/arch-ls102xa/ns_access.h > index a921fb6..44acfd2 100644 > --- a/arch/arm/include/asm/arch-ls102xa/ns_access.h > +++ b/arch/arm/include/asm/arch-ls102xa/ns_access.h > @@ -82,12 +82,12 @@ enum csu_cslx_ind { > CSU_CSLX_FTM5, > CSU_CSLX_FTM8, > CSU_CSLX_FTM7, > - CSU_CSLX_COP_DCSR, > CSU_CSLX_EPU, > - CSU_CSLX_GDI, > + CSU_CSLX_COP_DCSR, > CSU_CSLX_DDI, > + CSU_CSLX_GDI, > CSU_CSLX_RESERVED1, > - CSU_CSLX_USB3_PHY = 117, > + CSU_CSLX_USB3_PHY = 116, > CSU_CSLX_RESERVED2, > CSU_CSLX_MAX, > }; > -- Reviewed-by: Alison Wang <alison.wang(a)nxp.com> Best Regards, Alison Wang

1 0

[U-Boot] [PATCH] sf: params: Add support for n25q016a
by Moritz Fischer 31 Mar '16

31 Mar '16

This commits adds support for the N25Q016A, a 16Mbit serial NOR flash from Micron. Signed-off-by: Moritz Fischer <moritz.fischer(a)ettus.com> --- drivers/mtd/spi/sf_params.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c index 4f37e33..8ae4eea 100644 --- a/drivers/mtd/spi/sf_params.c +++ b/drivers/mtd/spi/sf_params.c @@ -83,6 +83,7 @@ const struct spi_flash_params spi_flash_params_table[] = { {"M25P64", 0x202017, 0x0, 64 * 1024, 128, RD_NORM, 0}, {"M25P128", 0x202018, 0x0, 256 * 1024, 64, RD_NORM, 0}, {"M25PX64", 0x207117, 0x0, 64 * 1024, 128, RD_NORM, SECT_4K}, + {"N25Q016A", 0x20bb15, 0x1000, 64 * 1024, 32, RD_NORM, SECT_4K}, {"N25Q32", 0x20ba16, 0x0, 64 * 1024, 64, RD_FULL, WR_QPP | SECT_4K}, {"N25Q32A", 0x20bb16, 0x0, 64 * 1024, 64, RD_FULL, WR_QPP | SECT_4K}, {"N25Q64", 0x20ba17, 0x0, 64 * 1024, 128, RD_FULL, WR_QPP | SECT_4K}, -- 2.5.5

2 2

[U-Boot] [PATCH 01/11] arm: config: Introduce CONFIG_SYS_ARM_ARCH
by Marek Vasut 31 Mar '16

31 Mar '16

Introduce new helper Kconfig option, which is automatically set to the version of ARM architecture for which the U-Boot is built. This is useful when selecting tuning options in the libgcc imported from Linux kernel. Signed-off-by: Marek Vasut <marex(a)denx.de> Cc: Albert Aribaud <albert.u.boot(a)aribaud.net> Cc: Masahiro Yamada <yamada.masahiro(a)socionext.com> Cc: Simon Glass <sjg(a)chromium.org> Cc: Tom Rini <trini(a)konsulko.com> --- arch/arm/Kconfig | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 9851065..abbe33e 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -64,6 +64,20 @@ config SYS_CPU default "sa1100" if CPU_SA1100 default "armv8" if ARM64 +config SYS_ARM_ARCH + int + default 4 if CPU_ARM720T + default 4 if CPU_ARM920T + default 5 if CPU_ARM926EJS + default 5 if CPU_ARM946ES + default 6 if CPU_ARM1136 + default 6 if CPU_ARM1176 + default 7 if CPU_V7 + default 7 if CPU_V7M + default 5 if CPU_PXA + default 4 if CPU_SA1100 + default 8 if ARM64 + config SEMIHOSTING bool "support boot from semihosting" help -- 2.7.0

1 10

[U-Boot] [PATCH 0/5] Basic support for Amlogic GXBaby and ODROID-C2
by Beniamino Galvani 31 Mar '16

31 Mar '16

Hi, this series adds a very basic support for Amlogic S905 SoC (GXBaby) and for the ODROID-C2 board [1], and is based on u-boot sources available from the board vendor [2]. Mainline kernel support is still in early stages [3] and the plan is to add more features to u-boot (mmc, ethernet, ...) as soon as they are available in the kernel; this submission only includes definition of platform, board and UART support. Beniamino [1] http://www.hardkernel.com/main/products/prdt_info.php?g_code=G145457216438 [2] https://github.com/hardkernel/u-boot/tree/odroidc2-v2015.01 [3] https://lkml.org/lkml/2016/3/1/1401 Beniamino Galvani (5): arm: add initial support for Amlogic Meson and ODROID-C2 arm: dts: import Meson files serial: add support for Amlogic Meson UART arm: meson: use device tree meson: odroid-c2: enable serial arch/arm/Kconfig | 5 + arch/arm/Makefile | 1 + arch/arm/dts/Makefile | 2 + arch/arm/dts/meson-gxbb-odroidc2.dts | 65 ++++++++++ arch/arm/dts/meson-gxbb.dtsi | 211 +++++++++++++++++++++++++++++++++ arch/arm/include/asm/arch-meson/gxbb.h | 10 ++ arch/arm/mach-meson/Kconfig | 31 +++++ arch/arm/mach-meson/Makefile | 7 ++ arch/arm/mach-meson/board.c | 69 +++++++++++ board/hardkernel/odroid-c2/Kconfig | 12 ++ board/hardkernel/odroid-c2/MAINTAINERS | 6 + board/hardkernel/odroid-c2/Makefile | 7 ++ board/hardkernel/odroid-c2/README | 34 ++++++ board/hardkernel/odroid-c2/odroid-c2.c | 7 ++ configs/odroid-c2_defconfig | 18 +++ drivers/serial/Kconfig | 14 +++ drivers/serial/Makefile | 1 + drivers/serial/serial_meson.c | 162 +++++++++++++++++++++++++ include/configs/odroid-c2.h | 55 +++++++++ 19 files changed, 717 insertions(+) create mode 100644 arch/arm/dts/meson-gxbb-odroidc2.dts create mode 100644 arch/arm/dts/meson-gxbb.dtsi create mode 100644 arch/arm/include/asm/arch-meson/gxbb.h create mode 100644 arch/arm/mach-meson/Kconfig create mode 100644 arch/arm/mach-meson/Makefile create mode 100644 arch/arm/mach-meson/board.c create mode 100644 board/hardkernel/odroid-c2/Kconfig create mode 100644 board/hardkernel/odroid-c2/MAINTAINERS create mode 100644 board/hardkernel/odroid-c2/Makefile create mode 100644 board/hardkernel/odroid-c2/README create mode 100644 board/hardkernel/odroid-c2/odroid-c2.c create mode 100644 configs/odroid-c2_defconfig create mode 100644 drivers/serial/serial_meson.c create mode 100644 include/configs/odroid-c2.h -- 2.4.3

3 11

[U-Boot] Custom configurations
by Jan Danielsson 30 Mar '16

30 Mar '16

Hello, Is there a way to pass a custom out-of-tree configuration to the build system? This page seems to have an unofficial patch which outlines exactly what we'd like to do: https://boundarydevices.com/customizing-u-boot-on-i-mx/ We have a script which builds an embedded system; it's possible to pass an parameters to the build script to instruct it take different build routes (build for different operating systems, hardware platforms, etc, as well as development versions and production versions). I would like to be able to use a simple switch to the build script to enable "tftp mode", which would mean that it builds all the necessary files for booting from tftp, but more importantly, tell u-boot to automatically initialize and boot from tftp. Other factors play in as well, like which system it is being built on. To illustrate (in short) what I would like to do: rm myconf.h if [ "$BOOTMODE" = "tftp" ]; then if [ "`hostname`" = "maindevsys" ]; then SERVERIP="10.101.20.12" else SERVERIP="`getselfip`" fi echo CONFIG_BOOTCOMMAND="setenv serverip $SERVERIP ; dhcp ; tftpboot 0x10000000 uramdisk.image.gz ; tftpboot 0x13200000 uImage ; tftpboot 0x16400000 zynq-zed.dtb ; bootm 0x13200000 0x10000000 0x16400000" >> ~/tmp/myconf.h fi [---] CUSTOM_CONFIG=~/rmp/myconf.h make zynq_picozed_config make (Ignore missing escapes etc; this is just for illustration). As you can see, the configuration can be pretty dynamic, so this isn't something we'd like to host in a repository, and furthermore I would prefer not to modify any in-tree files if possible (it's not a problem for me to migrate our changes to a new official release branch, but I'm trying to make this as simple as possible for whoever takes over maintainership further down the road). I'd be surprised if others haven't encountered this need before; and in place of the CUSTOM_CONFIG feature, what other solutions have people come up with? The most straightforward solution, given the boundary conditions I set up, would currently, to me, be to make a copy of the picozed config and copy it into the include/configs directory, and make the appropriate dynamic modifications in the non-scm tracked file. This does however put some extra burden on the person updating the u-boot version used in the build. Looking for any helpful tips on how to accomplish this. -- Kind Regards, Jan

1 0

[U-Boot] Issue with ALLOC_CACHE_ALIGN_BUFFER in env_relocate_spec and
by Vincent 30 Mar '16

30 Mar '16

Hi, I am having some issue with several instances of ALLOC_CACHE_ALIGN_BUFFER in (at least): - common/env_mmc: env_relocate_spec - disk/part_dos: test_part_dos U-boot (ls1021atwr) is build in SPL mode, SPL part is in Secure World, u-boot is in Normal World. In the SPL part, there is no problem, MMC access are fine. In the normal world, I experience what I think is stack corruption: At these locations, calls to the MMC to read partition info mostly read 0 or garbages. Garbage looks like stack overflow/corruption. For example, in the first function, checking the CRC of u-boot's env stored in the MMC fails because the buffer is correct until the last kb where there is values instead of zeroes, which looks like RAM addresses and data. I tried several fix, but I still don't understand what's happening: - I tried to allocate the buffer where MMC data is read into the head -> it works fine - I tried to allocate more room to these buffer on the stack -> sometimes it works, but not always. Maybe it's my compiler (NXP's SDK 1.9, based on yocto) which is buggy, I don't know. I can provide some custom dump of memory if necessary, but the buffers at these locations are quite huge I'm afraid. Best regards, Vincent

1 1

[U-Boot] [PATCH v2 0/2] ARM: uniphier: add ARMv8 SoCs support
by Masahiro Yamada 30 Mar '16

30 Mar '16

Masahiro Yamada (2): ARM: uniphier: add PH1-LD20 SoC support ARM: uniphier: add PH1-LD11 SoC support arch/arm/mach-uniphier/Kconfig | 10 +++ arch/arm/mach-uniphier/Makefile | 1 + arch/arm/mach-uniphier/arm64/Makefile | 8 +++ arch/arm/mach-uniphier/arm64/mem_map.c | 28 +++++++++ arch/arm/mach-uniphier/board_late_init.c | 3 +- arch/arm/mach-uniphier/boards.c | 45 +++++++++++++ arch/arm/mach-uniphier/boot-mode/Makefile | 1 + arch/arm/mach-uniphier/boot-mode/boot-device.h | 2 + arch/arm/mach-uniphier/boot-mode/boot-mode-ld20.c | 77 +++++++++++++++++++++++ arch/arm/mach-uniphier/boot-mode/boot-mode.c | 4 ++ arch/arm/mach-uniphier/boot-mode/cmd_pinmon.c | 5 ++ arch/arm/mach-uniphier/cpu_info.c | 4 +- arch/arm/mach-uniphier/dram/Makefile | 2 + arch/arm/mach-uniphier/dram/umc-ld11.c | 14 +++++ arch/arm/mach-uniphier/dram/umc-ld20.c | 14 +++++ arch/arm/mach-uniphier/early-clk/Makefile | 1 + arch/arm/mach-uniphier/early-clk/early-clk-ld20.c | 30 +++++++++ arch/arm/mach-uniphier/init.h | 4 ++ arch/arm/mach-uniphier/init/Makefile | 2 + arch/arm/mach-uniphier/init/init-ld11.c | 56 +++++++++++++++++ arch/arm/mach-uniphier/init/init-ld20.c | 55 ++++++++++++++++ arch/arm/mach-uniphier/init/init.c | 5 ++ arch/arm/mach-uniphier/memconf/Makefile | 1 + arch/arm/mach-uniphier/memconf/memconf-pxs2.c | 3 + arch/arm/mach-uniphier/sbc/Makefile | 1 + arch/arm/mach-uniphier/sg-regs.h | 3 +- configs/uniphier_ld11_defconfig | 28 +++++++++ configs/uniphier_ld20_defconfig | 28 +++++++++ include/configs/uniphier.h | 43 +++++++++++-- 29 files changed, 469 insertions(+), 9 deletions(-) create mode 100644 arch/arm/mach-uniphier/arm64/Makefile create mode 100644 arch/arm/mach-uniphier/arm64/mem_map.c create mode 100644 arch/arm/mach-uniphier/boot-mode/boot-mode-ld20.c create mode 100644 arch/arm/mach-uniphier/dram/umc-ld11.c create mode 100644 arch/arm/mach-uniphier/dram/umc-ld20.c create mode 100644 arch/arm/mach-uniphier/early-clk/early-clk-ld20.c create mode 100644 arch/arm/mach-uniphier/init/init-ld11.c create mode 100644 arch/arm/mach-uniphier/init/init-ld20.c create mode 100644 configs/uniphier_ld11_defconfig create mode 100644 configs/uniphier_ld20_defconfig -- 1.9.1

1 2

[U-Boot] Pull request, u-boot-tegra/master
by Tom Warren 30 Mar '16

30 Mar '16

Tom, Please pull u-boot-tegra/master into U-Boot/master. Thanks! All tegra builds are OK (32-bit and 64-bit), and Stephen reports that tests of u-boot-tegra/master all pass. The following changes since commit f3c2cab87878d2ecd5bd796ee940dff814aa3255: Revert "pxa_lcd: make driver cache-aware" (2016-03-27 20:58:08 -0400) are available in the git repository at: git://git.denx.de/u-boot-tegra.git master for you to fetch changes up to 8f83759fac57cb25e23f6f75c001fe23aea47ee1: ARM: tegra210: set PLLE_PTS bit when enabling PLLE (2016-03-29 09:57:57 -0700) ---------------------------------------------------------------- Stephen Warren (1): ARM: tegra210: set PLLE_PTS bit when enabling PLLE arch/arm/mach-tegra/tegra210/clock.c | 2 ++ 1 file changed, 2 insertions(+)

2 1