December 2014 - U-Boot

[U-Boot] [PATCH 0/2] mtd: nand: fix two problems related to BBT scan
by Masahiro Yamada 26 Dec '14

26 Dec '14

Masahiro Yamada (2): mtd: nand: Mark the BBT as scanned prior to calling scan_bbt again mtd: nand: do not scan BBT after scrub drivers/mtd/nand/nand_base.c | 9 +++------ drivers/mtd/nand/nand_util.c | 4 +--- 2 files changed, 4 insertions(+), 9 deletions(-) -- 1.9.1

1 2

[U-Boot] [PATCH] sunxi: Fix CONFIG_UART0_PORT_F build and add it to menuconfig
by Siarhei Siamashka 25 Dec '14

25 Dec '14

The CONFIG_UART0_PORT_F option has been supported since http://git.denx.de/?p=u-boot.git;a=commit;h=ff2b47f6a9cc1025 This option is primarily useful only for low level u-boot debugging on tablets, where normal UART0 is difficult to access and requires device disassembly and/or soldering. This patch now allows it to be selected from menuconfig. A dependency on SPL_FEL is added because u-boot does not support booting from NAND yet and also booting from SD card is impossible when a MicroSD breakout board is plugged into the SD slot. Additionally a compilation problem is fixed: common/spl/built-in.o: In function `spl_mmc_load_image': /tmp/u-boot-sunxi/common/spl/spl_mmc.c:94: undefined reference to `mmc_initialize' /tmp/u-boot-sunxi/common/spl/spl_mmc.c:96: undefined reference to `find_mmc_device' /tmp/u-boot-sunxi/common/spl/spl_mmc.c:104: undefined reference to `mmc_init' scripts/Makefile.spl:206: recipe for target 'spl/u-boot-spl' failed Signed-off-by: Siarhei Siamashka <siarhei.siamashka(a)gmail.com> --- board/sunxi/Kconfig | 12 ++++++++++++ include/configs/sunxi-common.h | 3 +++ 2 files changed, 15 insertions(+) diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig index 5a88ba0..7140b80 100644 --- a/board/sunxi/Kconfig +++ b/board/sunxi/Kconfig @@ -178,6 +178,18 @@ config SPL_FEL depends on SPL default n +config UART0_PORT_F + bool "UART0 on MicroSD breakout board" + depends on SPL_FEL + default n + ---help--- + Repurpose the SD card slot for getting access to the UART0 serial + console. Primarily useful only for low level u-boot debugging on + tablets, where normal UART0 is difficult to access and requires + device disassembly and/or soldering. As the SD card can't be used + at the same time, the system can be only booted in the FEL mode. + Only enable this if you really know what you are doing. + config FDTFILE string "Default fdtfile env setting for this board" diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index 3f890b2..f7e87a2 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -160,7 +160,10 @@ #define CONFIG_SPL_MAX_SIZE 0x5fe0 /* 24KB on sun4i/sun7i */ #define CONFIG_SPL_LIBDISK_SUPPORT + +#if !defined(CONFIG_UART0_PORT_F) #define CONFIG_SPL_MMC_SUPPORT +#endif #define CONFIG_SPL_LDSCRIPT "arch/arm/cpu/armv7/sunxi/u-boot-spl.lds" -- 2.0.4

2 1

[U-Boot] [PATCH v2 0/4] i2c: UniPhier: add I2C drivers based on driver model
by Masahiro Yamada 25 Dec '14

25 Dec '14

Masahiro Yamada (4): i2c: UniPhier: add driver for UniPhier i2c controller i2c: UniPhier: add driver for UniPhier FIFO-builtin i2c controller ARM: UniPhier: enable UniPhier I2C driver ARM: UniPhier: enable CONFIG_I2C_EEPROM configs/ph1_ld4_defconfig | 2 + configs/ph1_pro4_defconfig | 2 + configs/ph1_sld8_defconfig | 2 + drivers/i2c/Kconfig | 22 +++ drivers/i2c/Makefile | 2 + drivers/i2c/i2c-uniphier-f.c | 358 +++++++++++++++++++++++++++++++++++++++++++ drivers/i2c/i2c-uniphier.c | 233 ++++++++++++++++++++++++++++ include/configs/uniphier.h | 3 + 8 files changed, 624 insertions(+) create mode 100644 drivers/i2c/i2c-uniphier-f.c create mode 100644 drivers/i2c/i2c-uniphier.c -- 1.9.1

1 4

[U-Boot] buildman reports error of script/binutils-version.sh
by York Sun 25 Dec '14

25 Dec '14

Simon, Shall we consider host error to be an error reported by buildman? I happen to try a newer version of toolchain from Linaro. Buildman reports this error +../scripts/binutils-version.sh: line 20: printf: 09: invalid octal number The root cause is this version of AS reports version string differently GNU assembler (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro GCC 4.9-2014.09) 2.24.0.20140829 Linaro 2014.09 It has "Linaro 2014.09" at the back, so script/binutils-version.sh cannot parse it correctly (the error is not handling zero-leading numbers, but not in the scope of this discussion). Another angle of this question is, why do we need this script? It doesn't sound stable to me to parse the version string this way. York

4 3

[U-Boot] [PATCH 0/7] Crazy patches (Nightmare of <stdint.h>)
by Masahiro Yamada 24 Dec '14

24 Dec '14

Commit 0d296cc2d3b (Provide option to avoid defining a custome version of uintptr_t) and commit 4166ecb247 (Add some standard headers external code might need) made a horrible decision. I raised a flag in the following threads: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/203954 http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/198550/focus=205880 It looks like Simon is not understanding me. Nor does anybody else have any interest in this topic. This series is here to show what will happen next and how horrible it is. Masahiro Yamada (7): types.h: define (u)int8_t, (u)int16_t, (u)int32_t based on compiler info (MAD) types.h: define s8, s16, s32, s64, u8, u16, u32, u64 based on compiler info (MAD) types: defined __s8, __16, __s32, __s64, __u8, __u16, __u32, __u64 based on compiler info (MAD) Check if compiler-provided <stdint.h> and <inttypes.h> are available if CONFIG_USE_STDINT=y (MAD) Replace "llx" with PRIx64 to fix warnings on sandbox (MAD) Use PRIx32 etc. to print out 32bit-width variable (MAD) Make BITS_PER_LONG compiler-dependent (MAD) Makefile | 2 +- arch/arc/include/asm/types.h | 34 +++++ arch/arm/include/asm/types.h | 37 +++++ arch/avr32/include/asm/types.h | 36 +++++ arch/blackfin/include/asm/types.h | 36 +++++ arch/m68k/include/asm/types.h | 37 +++++ arch/microblaze/include/asm/types.h | 36 +++++ arch/mips/include/asm/types.h | 36 +++++ arch/nds32/include/asm/types.h | 36 ++++- arch/nios2/include/asm/types.h | 35 +++++ arch/openrisc/include/asm/types.h | 35 +++++ arch/powerpc/include/asm/types.h | 36 +++++ arch/sandbox/include/asm/types.h | 34 +++++ arch/sh/include/asm/types.h | 35 +++++ arch/sparc/include/asm/types.h | 35 +++++ arch/x86/include/asm/types.h | 35 +++++ common/fdt_support.c | 2 +- config.mk | 12 ++ disk/part_efi.c | 12 +- fs/fat/fat.c | 35 ++--- include/inttypes.h | 287 ------------------------------------ include/linux/types.h | 15 ++ include/u-boot/zlib.h | 2 +- scripts/gcc-have-stdint.sh | 21 +++ 24 files changed, 607 insertions(+), 314 deletions(-) delete mode 100644 include/inttypes.h create mode 100755 scripts/gcc-have-stdint.sh -- 1.9.1

3 16

[U-Boot] [PATCH] arm: exynos: clock: support SPLL as mmc source clock for exynos5420
by Joonyoung Shim 24 Dec '14

24 Dec '14

MMC of exynos5420 can select SPLL as source clock, so add to support SPLL in exynos5420_get_mmc_clk(). It was tested on Odroid-XU3 board. Signed-off-by: Joonyoung Shim <jy0922.shim(a)samsung.com> --- arch/arm/cpu/armv7/exynos/clock.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/cpu/armv7/exynos/clock.c b/arch/arm/cpu/armv7/exynos/clock.c index 8fab135..b31c13b 100644 --- a/arch/arm/cpu/armv7/exynos/clock.c +++ b/arch/arm/cpu/armv7/exynos/clock.c @@ -848,6 +848,8 @@ static unsigned long exynos5420_get_mmc_clk(int dev_index) if (sel == 0x3) sclk = get_pll_clk(MPLL); + else if (sel == 0x4) + sclk = get_pll_clk(SPLL); else if (sel == 0x6) sclk = get_pll_clk(EPLL); else -- 1.9.1

3 2

[U-Boot] mystery boot code in MPC8247-based device
by Ben Gelb 23 Dec '14

23 Dec '14

I am working on a MPC8247-based device that is not booting. I can see that the CPU is properly powered and gets out of reset, but that the software watchdog is timing out every ~1.3 sec and sending the device back into reset again. The board has a 1Mbit flash EEPROM used for booting, and a larger 32Mbit NAND device that contains the full OS and firmware. I can see that the boot ROM is being accessed, and that the flash is never accessed. Also, the serial port on the board never has any output. I managed to dump the boot EEPROM using JTAG boundary scan, and so have been poking around inside to see if it has any obvious corruption. The boot code is indeed based on U-Boot, and inspecting the first few instructions I can see that the reset vector routine (located at 0x100) is pretty much an exact match with the mpc8260/start.S from the U-Boot tree. There is one major exception though - there are 6 dwords, starting from 0x100, that are not found in U-Boot (The U-Boot start.S code actually begins at 0x118). The first dword does not appear to actually be an instruction. See below: (omitting HRCW) // what is this first part??? 100: 04 a0 00 01 .long 0x4a00001 104: 60 00 00 00 nop 108: 48 00 00 10 b 0x118 10c: 00 00 00 00 .long 0x0 110: 3a a0 00 02 li r21,2 114: 48 00 00 04 b 0x118 // below matches _start: in mpc8260/start.S 118: 7c a0 00 a6 mfmsr r5 11c: 3c 60 f0 00 lis r3,-4096 // r3 <- 0xf0000000 120: 60 63 00 00 ori r3,r3,0 124: 3c 80 0f 01 lis r4,3841 // r4 <- 0x0f010000 128: 90 64 01 a8 stw r3,424(r4) // MEM(0x0f0101a8) <- 0xf0000000 (load new IMMR base addr) .... and so on. (compare to http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=arch/powerpc/cp…, line 137) Does anybody have any thoughts on what the first "instruction" 0x04a00001 would cause the CPU to do when it is sent to 0x100 on reset? I'm not much of a PPC expert, but that doesn't seem to correspond to a legal instruction. Seems like it was probably put there for a reason, but I'd be interested to know how its supposed to work. Thanks, Ben

1 0

Re: [U-Boot] Implementing the uBoot SYSCALL interface for MIPS
by Matthew Fortune 23 Dec '14

23 Dec '14

Hi Daniel, I'm looking for a bit of feedback on my query below. Unless there is a major problem I'll start to organise an implementation for review. Thanks, Matthew > -----Original Message----- > From: Matthew Fortune > Sent: 08 December 2014 12:43 > To: 'u-boot(a)lists.denx.de' > Subject: Implementing the uBoot SYSCALL interface for MIPS > > Hi all, > > I've been recently working on and promoting a common bare-metal semi- > hosting interface for the MIPS architecture. The main goal of this is to > allow a bare-metal MIPS application to run on the maximum number of > simulation and hardware platforms without (much/any) modification. The > interface uses the MIPS SYSCALL interface and a custom ABI to request > operations from an OS or monitor. > > As far as I can see uBoot's new(ish) API as not yet been mapped onto the > MIPS architecture. I would like to find out if it will be acceptable to > access some map some of the operations from the semi-hosting interface > onto the uBoot API. > > In particular I'd like to get: open, read, write, close, fstat > implemented such that FD 0/1 behave as if attached to a serial port. > Open/close and fstat wouldn't do anything special as they would just say > that FD 0/1 exist. > Read and write would map to getc and putc for FD 0 and FD 1 > respectively. > > The interface is being implemented directly in qemu, and as part of > libgloss on the consumer side (not upstream yet). I will be promoting > its use in any other open source simulators and hosting libraries too as > I find them. I'm also boldly trying to abstract away from any ABI issues > (O32/N32/N64) to potentially allow the consumer and producer side of the > interface to have different ABIs to some extent. I am also trying to > create a well-defined entry-point interface to reduce the variance in > how arguments are passed from bootloader to application, at least one > person has shown interest in this from the kernel list. > > If it sounds like it will be acceptable then I'll send more details of > the interface as a follow up but I would really like to include uBoot in > the list of supported environments. There is of course scope to add any > number of extra operations to the interface to cover more of the uBoot > API but I generally agree with the principle that exploiting too much of > uBoot is bad form if an application is non-GPL. > > Thanks, > Matthew

2 1

[U-Boot] [PATCH 0/5] x86: Support PCI based UART as the U-Boot serial console
by Bin Meng 23 Dec '14

23 Dec '14

Newer x86 Platform Controller Hub chipset (like Topcliff, BayTrail) starts to integrate NS16550 compatible PCI UART devices. In order to use them, we have to scan the PCI bus and allocate memory/io address in the early phase. On Intel Crown Bay board, there are 4 UART DB9 connectors, one of which is from the superio legacy serial port while the other 3 are connected to the Topcliff PCH UART devices. The board configuration file needs to supply the PCI UART vendor ID and device ID via CONFIG_PCI_UART_DEV if we want to use the PCI UART as the U-Boot serial console. Bin Meng (5): x86: Add missing DECLARE_GLOBAL_DATA_PTR for pci.c x86: Support pci bus scan in the early phase x86: Add an API for finding pci devices in the early phase x86: Support PCI UART in the x86_serial driver x86: Add PCI UART related defines in crownbay.h arch/x86/cpu/pci.c | 44 ++++++++++++++++++++++++++++++++++++++++++++ arch/x86/include/asm/pci.h | 2 ++ drivers/serial/serial_x86.c | 30 ++++++++++++++++++++++++++++++ include/configs/crownbay.h | 5 +++++ 4 files changed, 81 insertions(+) -- 1.8.2.1

2 18

[U-Boot] [PATCH v2 0/3] Serial Flash: call spi_flash_free more coherently
by Valentin Longchamp 23 Dec '14

23 Dec '14

Some board require spi_flash_free to be called after all the accesses, in order, for instance, to restore the pin multiplexing configuration in the case where the SPI pins are multiplexed. This patch series tries to enhance this. Patch 1 adds spi_flash_free calls to env_sf so that the SPI interface is always "cleaned up" after the env read/writes. Patch 2 adds a 'sf release' command that implicitly calls spi_flash_free and is thus the pendant of 'sf probe'. Patch 3 uses the 'sf command' for the km_arm board scripts. The whole series had already been sent more than a year ago [1] but it was rejected without any feedback. So I send this rebased v2 so that it finally gets reviewed and merged. [1] http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/169723 Changes in v2: - Rebased on v2014.10 Valentin Longchamp (3): env_sf: generalize call to spi_flash_free after accesses cmd_sf: add 'release' command km_arm: call 'sf release' in the newenv and update scripts common/cmd_sf.c | 13 ++++++++++++- common/env_sf.c | 34 ++++++++++++++++------------------ include/configs/km/km_arm.h | 6 ++++-- 3 files changed, 32 insertions(+), 21 deletions(-) -- 1.8.0.1

2 5