July 2012 - U-Boot

[U-Boot] [PATCH 0/17] tegra: Add display driver and LCD support for Seaboard
by Simon Glass 24 Jul '12

24 Jul '12

This series adds support for the Tegra2x's display peripheral. This supports the LCD display on Seaboard and we use this to enable console output in U-Boot on the LCD. Configuration is via the device tree. Proposed bindings are included in this series. To improve performance two optimisations are offered: 1. The LCD frame buffer is cached, with the cache being flushed after each call puts(). This dramatically increases performance (around 10x). This requires a few additions to the ARM cache support. 2. The console supports scrolling in steps of more than 1 line. This speeds up scrolling output considerably, particularly commands like 'printenv' which display a lot of output. This requires a new CONFIG and a change to the console_scrollup() function. Mayuresh Kulkarni (1): tegra: Enable display/lcd support on Seaboard Simon Glass (15): fdt: Add function to look up a phandle's register address fdt: Add header guard to fdtdec.h fdt: Correct GPIO name access in fdtdec tegra: Add display support to funcmux tegra: fdt: Add LCD definitions for Tegra tegra: Add support for PWFM tegra: Add LCD driver tegra: Add LCD support to Nvidia boards arm: Add control over cachability of memory regions lcd: Add CONFIG_ALIGN_LCD_TO_SECTION to align lcd for MMU lcd: Add support for flushing LCD fb from dcache after update tegra: Align LCD frame buffer to section boundary tegra: Support control of cache settings for LCD tegra: fdt: Add LCD definitions for Seaboard lcd: Add CONSOLE_SCROLL_LINES option to speed console Wei Ni (1): tegra: Add SOC support for display/lcd README | 16 + arch/arm/cpu/armv7/cache_v7.c | 11 + arch/arm/cpu/armv7/tegra2/Makefile | 1 + arch/arm/cpu/armv7/tegra2/display.c | 271 +++++++++++ arch/arm/cpu/armv7/tegra2/funcmux.c | 39 ++ arch/arm/cpu/armv7/tegra2/pwfm.c | 40 ++ arch/arm/dts/tegra20.dtsi | 25 + arch/arm/include/asm/arch-tegra2/dc.h | 544 +++++++++++++++++++++++ arch/arm/include/asm/arch-tegra2/display.h | 133 ++++++ arch/arm/include/asm/arch-tegra2/pwfm.h | 54 +++ arch/arm/include/asm/system.h | 30 ++ arch/arm/lib/cache-cp15.c | 62 +++- board/nvidia/common/board.c | 21 +- board/nvidia/dts/tegra2-seaboard.dts | 21 + common/cmd_echo.c | 3 +- common/lcd.c | 85 +++- doc/device-tree-bindings/video/nvidia-video.txt | 92 ++++ drivers/video/Makefile | 1 + drivers/video/tegra.c | 388 ++++++++++++++++ include/configs/seaboard.h | 12 +- include/configs/tegra2-common.h | 1 + include/fdtdec.h | 17 + include/lcd.h | 11 + lib/fdtdec.c | 15 +- 24 files changed, 1862 insertions(+), 31 deletions(-) create mode 100644 arch/arm/cpu/armv7/tegra2/display.c create mode 100644 arch/arm/cpu/armv7/tegra2/pwfm.c create mode 100644 arch/arm/include/asm/arch-tegra2/dc.h create mode 100644 arch/arm/include/asm/arch-tegra2/display.h create mode 100644 arch/arm/include/asm/arch-tegra2/pwfm.h create mode 100644 doc/device-tree-bindings/video/nvidia-video.txt create mode 100644 drivers/video/tegra.c -- 1.7.7.3

6 33

[U-Boot] RFC - PatchTrack Specification
by Graeme Russ 24 Jul '12

24 Jul '12

Hi All, Here's a quick-and-dirty specification for a patch tracking tool... PatchTrack is designed to help alleviate some of the load from custodians manging a email based work flow accepting patches from a large community of contributors Functionality: - Monitor an electronic mailing list, extracting patches as they are posted to the list - Group patchsets that are posted using x/y style numbering. The patches within the set are grouped under the 0/y patch - Run arbitrarily defined stand-alone sanity checks on each patch. For example, the 'checkpatch' script can be run to check that each incoming patch obeys the style rules of the project - Associate each patch with a git repository. Association is determined by tags in the patch subject header - Maintain the revision history of each patch - Maintain community comments sent to the mailing list for each patch - Collect Ack'd, Nack'd, Tested, etc. community feedback (the feedback tags are configurable) - Maintain a 'patch stack' of unapplied patches for each configure repository. The patch stack is maintained as a 'first in, first served' list of patches - Test that each patch stack applies to the HEAD of the associated git repository - Re-test that the patch stack applies whenever the HEAD of the associated git repository changes Interface: The primary interface to PatchTrack is emails extracted from a configured mailbox. PatchTrack also provides a web-based interface which allows a user to visualise the patch stack for each repository. For each configured repository, the web interface will display associated patches in chronologically ordered rows. Each row is a single patch. patch sets are grouped together using the timestamp of the fist patch. The following information is displayed in each row: - Patch name/subject - Author - Number of received Ack, Nack, Tested, etc. feedbacks The colour of each row indicates the 'quality' of the patch: - Red indicates the patch does not apply cleanly. Red patches are not actually in the patch stack but are displayed for completeness - Orange indicates that the patch does apply but has failed one or more of the configured sanity checks - Yellow indicates that the patch applies and passed all configured sanity checks - Green indicates that the patch has been accepted by a maintainer. All green patches are placed at the top of the stack (i.e. they are always applied first) in order of acceptance (not submission order) - White indicates that the patch has been applied to the repository Clicking on any row will expand the row (clicking again will collapse the row). An expanded row displays the following information: - Ack'd, Nack'd, Tested, etc. tags - Sanity check results - Patch apply result - Comments - Patch body The web interface will provide an authenticated login. When a maintainer of a repository is logged in, they can: - Reject a patch, removing it from the patch stack entirely - Accept a patch. When a patch is accepted, PatchTrack will check that the patch applies cleanly to the HEAD of previously accepted patches - Apply the top 'x' accepted patches the git repository - Purge applied patches from PatchTrack

3 2

[U-Boot] building tools/env
by Steve DeLaney 24 Jul '12

24 Jul '12

hi there, I'm attempting to build u-boot 1.1.1 tools/env and the build is failed. Any ideas on best way to enable it in the build. Here's what I did so far first, update tools/Makefile TOOLSUBDIRS = env then top level build make clobber mrproper make octeon_cn3010_evb_hs5_config make all the build in tools/env fails due to missing include files linux/mtd/mtd.h zlib.h add to tools/env/Makefile CPPFLAGS += ../../include and include CPPFLAGS here: fw_printenv : $(SOURCES) $(HEADERS) $(CROSS_COMPILE)gcc -Wall $(CPPFLAGS) -DUSE_HOSTCC $(SOURCES) -o fw_printenv but this leads to build error on definitions of uint32_t, phys_addr_t and erase_info_t Any ideas on preferred way to build tools/env? thanks in advance!

4 3

[U-Boot] V2 S3c64xx: Switch all I/O to use readl/writel functio and Clear variable
by Zhong Hongbo 24 Jul '12

24 Jul '12

V2: 1. Modify the type of return for s3c64xx_get_base_nand 2. Add patch 0014 to support s3c6410 board 3. Adjust patch for mix content. V1: This serial patch intent to: 1. Switch all I/O to use readl/writel function 2. Change nand_spl to use SPL framework 3. S3C64XX serial includes s3c6400 and s3c6410, Here seprate cpu and board file to support to board's of s3c6410. I test this patch on my s3c6410 development board. the log as following: U-Boot 2012.04.01-10905-g9fa0c77 (Jul 07 2012 - 15:50:57) for SMDK6400 CPU: S3C64XX@532MHz Fclk = 532MHz, Hclk = 133MHz, Pclk = 66MHz (ASYNC Mode) Board: DMATEK6410 DRAM: 128 MiB WARNING: Caches not enabled NAND: 128 MiB *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial Net: dm9000 Hit any key to stop autoboot: 0 DMATEK6410 #

2 24

[U-Boot] [PATCH] net: Make sure the ethaddr is updated in net_init()
by Joe Hershberger 24 Jul '12

24 Jul '12

NetConsole may call NetSendUDPPacket before NetLoop is called. This will cause the source MAC address (NetOurEther) to be wrong. Instead of only changing it in NetLoop, move it to NetLoopInit so that it is also updated when net_init() is called (especially by nc_start()). Signed-off-by: Joe Hershberger <joe.hershberger(a)ni.com> Reported-by: Michael Walle <michael(a)walle.cc> --- net/net.c | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/net/net.c b/net/net.c index 9de7d92..e8ff066 100644 --- a/net/net.c +++ b/net/net.c @@ -256,6 +256,7 @@ static void NetInitLoop(void) #endif env_changed_id = env_id; } + memcpy(NetOurEther, eth_get_dev()->enetaddr, 6); return; } @@ -322,8 +323,6 @@ int NetLoop(enum proto_t protocol) } restart: - memcpy(NetOurEther, eth_get_dev()->enetaddr, 6); - net_set_state(NETLOOP_CONTINUE); /* -- 1.6.0.2

3 2

[U-Boot] [PATCH] ext2load: increase read speed
by Jason Cooper 24 Jul '12

24 Jul '12

This patch dramatically drops the amount of time u-boot needs to read a file from an ext2 partition. On a typical 2 to 5 MB file (kernels and initrds) it goes from tens of seconds to a couple seconds. All we are doing here is grouping contiguous blocks into one read. Boot tested on Globalscale Technologies Dreamplug (Kirkwood ARM SoC) with three different files. sha1sums were calculated in Linux userspace, and then confirmed after ext2load. Signed-off-by: Jason Cooper <u-boot(a)lakedaemon.net> --- fs/ext2/ext2fs.c | 26 ++++++++++++++++++++++++-- 1 files changed, 24 insertions(+), 2 deletions(-) diff --git a/fs/ext2/ext2fs.c b/fs/ext2/ext2fs.c index e119e13..8531db5 100644 --- a/fs/ext2/ext2fs.c +++ b/fs/ext2/ext2fs.c @@ -414,7 +414,6 @@ int ext2fs_read_file if (blknr < 0) { return (-1); } - blknr = blknr << log2blocksize; /* Last block. */ if (i == blockcnt - 1) { @@ -432,6 +431,29 @@ int ext2fs_read_file blockend -= skipfirst; } + /* grab middle blocks in one go */ + if (i != pos / blocksize && i != blockcnt - 1 && blockcnt > 3) { + int oldblk = blknr; + int blocknxt; + while (i < blockcnt - 1) { + blocknxt = ext2fs_read_block(node, i + 1); + if (blocknxt == (oldblk + 1)) { + oldblk = blocknxt; + i++; + } else { + blocknxt = ext2fs_read_block(node, i); + break; + } + } + + if (oldblk == blknr) + blockend = blocksize; + else + blockend = (1 + blocknxt - blknr) * blocksize; + } + + blknr = blknr << log2blocksize; + /* If the block number is 0 this block is not stored on disk but is zero filled instead. */ if (blknr) { @@ -444,7 +466,7 @@ int ext2fs_read_file } else { memset (buf, 0, blocksize - skipfirst); } - buf += blocksize - skipfirst; + buf += blockend - skipfirst; } return (len); } -- 1.7.3.4

7 19

[U-Boot] [PATCH] sh: modify checkcpu() for SH-4A
by Shimoda, Yoshihiro 24 Jul '12

24 Jul '12

Even if using CPU is SH-4A, the previous code always put "SH4". This patch fixes it. Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com> --- arch/sh/cpu/sh4/cpu.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/sh/cpu/sh4/cpu.c b/arch/sh/cpu/sh4/cpu.c index f136758..7da1ef7 100644 --- a/arch/sh/cpu/sh4/cpu.c +++ b/arch/sh/cpu/sh4/cpu.c @@ -29,7 +29,11 @@ int checkcpu(void) { +#ifdef CONFIG_SH4A + puts("CPU: SH-4A\n"); +#else puts("CPU: SH4\n"); +#endif return 0; } -- 1.7.1

2 1

[U-Boot] [PATCH] arm: rmobile: kzm9g: Fix CONFIG_BAUDRATE setting
by Tetsuyuki Kobayshi 24 Jul '12

24 Jul '12

From: Tetsuyuki Kobayashi <koba(a)kmckk.co.jp> The value of CONFIG_BAUDRATE is treated as string and put as initial value of environment variable. If it begin with '(', it is wrongly parsed to 0 in number. So I removed '(' and ')'. Signed-off-by: Tetsuyuki Kobayashi <koba(a)kmckk.co.jp> --- Hi, Iwamatsu-san This is a kind of regression. The initial value of environment variable of barud rate is wrong. When you flash U-Boot to a new board, serial console doesn't work because board rate is set to 0. If you save environment variables in old version U-Boot, you don't aware this problem. include/configs/kzm9g.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/kzm9g.h b/include/configs/kzm9g.h index bd157d9..14f088f 100644 --- a/include/configs/kzm9g.h +++ b/include/configs/kzm9g.h @@ -46,7 +46,7 @@ #define CONFIG_CMD_FAT #define CONFIG_CMD_BOOTZ -#define CONFIG_BAUDRATE (115200) +#define CONFIG_BAUDRATE 115200 #define CONFIG_BOOTARGS "root=/dev/null console=ttySC4,115200" #define CONFIG_INTEGRATOR #define CONFIG_ARCH_CINTEGRATOR -- 1.7.9.5

2 1

Re: [U-Boot] Notes from the U-Boot BOF Meeting in Geneva 2012/07/12
by Marek Vasut 24 Jul '12

24 Jul '12

Dear Eric Nelson, > > Yea ... I think our community is kinda broken :-( > > Hey. We heard that... > > Careful what you say on an open mic! Oh man ... I guess it sounded bad indeed, I should have though about the wording more, sorry. I mean, we messed up the management (and I wonder who'll start bashing me for this one), resulting in the community being misguided sometimes. Making it hard to learn how to contribute too (too many rules etc). Custodians being overloaded, warding people off because the review takes too long ... stuff like that is what I meant. So we have too much to improve, yet too less time to do that. Ad community, there's a lot of people obviously, who contribute regularly (of course, such as yourself for example). But I wonder if there's enough of us to maintain such a big codebase we have. Besides, people care about linux a lot more than about uboot, pushing many more of the maintaining tasks on custodians. Or maybe it's the structure that doesn't work well enough to handle the flow. Honestly, I'm getting lost in it myself. Best regards, Marek Vasut

2 1

[U-Boot] NetConsole & TFTP
by Thomas Pohl 24 Jul '12

24 Jul '12

Hi all, I am trying to use the NetConsole to configure the U-Boot and to send command to it. Everything works fine, but I also need to transfer files via TFTP. It looks like that is a problem and I hope the members of this mailing list can give me some answers and maybe solutions. Is it possible to use NetConsole and TFTP parallel at one Ethernet interface? My fist thoughts were that this could be possible, because TFTP and NetConsole use different ports. But out of the box the behavior is different. In my tests TFTP tries to use another Ethernet interface (eTSEC1) as the NetConsole (eTSEC0), but the final Hardware has only one Ethernet and no serial interface. By the way, I tried the functionality with a second Ethernet interface and it also does not work. I see only less character at the NetConsole and it seems that the communication is going wrong and after a short time the communication is dead. Therefore I need a possibility to communicate with a target (via NetConsole) and transfer the flash images (via TFTP). Has anybody experiences with this? Is this possible with U-Boot? Maybe I am doing something wrong? Thank you for helping. Regards, Thomas SICK AG - Sitz: Waldkirch i. Br. - Handelsregister: Freiburg i. Br. HRB 280355 Vorstand: Dr. Robert Bauer (Vorsitzender) - Reinhard Bösl - Markus Paschmann - Markus Vatter Aufsichtsrat: Gisela Sick (Ehrenvorsitzende) - Klaus M. Bukenberger (Vorsitzender)

3 3