July 2013 - U-Boot

[U-Boot] bootm does not work if netconsole is enabled
by Michael Walle 21 Sep '13

21 Sep '13

Hi Joe, Hi Tom, If i have the netconsole enabled i cannot boot linux using the bootm command. This bug exists at least in 2013.01.01 and 2013.04-rc2 :/ Here is the output of the serial console of a successful startup: ## Booting kernel from Legacy Image at 00100000 ... Image Name: Linux-3.8.0-rc1-00004-g270c0a0-d Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 2799632 Bytes = 2.7 MiB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 00800000 ... Image Name: Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size: 636966 Bytes = 622 KiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 00700000 Booting using the fdt blob at 0x00700000 Loading Kernel Image ... OK OK Loading Ramdisk to 03aad000, end 03b48826 ... OK Loading Device Tree to 03aa8000, end 03aacedd ... OK Starting kernel ... [.. more linux kernel output ..] If the netconsole is enabled, eg. "stdin = stdout = stderr = nc", i see only the following output on the netconsole and then nothing more happens: ## Booting kernel from Legacy Image at 00100000 ... Image Name: Linux-3.8.0-rc1-00004-g270c0a0-d Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 2799632 Bytes = 2.7 MiB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 00800000 ... Image Name: Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size: 636966 Bytes = 622 KiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 00700000 Booting using the fdt blob at 0x00700000 I've tracked this down to the eth_halt() call in cmd_bootm.c:647. What is the purpose of this call? I guess the NIC should be shut down prior to booting linux. OTOH, there are still messages printed after this call, and i suppose the netconsole tries to bring the network back up. If i remove this call, everything works as expected. Anyway, i can definitely say, that the linux kernel is not starting. Eg. it is not only the output that stops working. FYI, i'm using the mvgbe driver. Let me know if i can do some more debugging or provide more information. Hopefully this will be fixed in 2013.04 :) -- Michael

5 13

[U-Boot] [PATCH 1/4] powerpc/83xx: remove staticness for qe_iop_conf_tab
by Holger Brunck 18 Sep '13

18 Sep '13

commit a5510058 powerpc/83xx/km: make local functions and structs static removed the staticness also from this struct. But this struct is needed in arch/powerpc/cpu/mpc83xx/cpu_init.c and declared as extern. Signed-off-by: Holger Brunck <holger.brunck(a)keymile.com> --- board/keymile/km83xx/km83xx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/keymile/km83xx/km83xx.c b/board/keymile/km83xx/km83xx.c index 812a436..47c40f5 100644 --- a/board/keymile/km83xx/km83xx.c +++ b/board/keymile/km83xx/km83xx.c @@ -31,7 +31,7 @@ #include "../common/common.h" -static const qe_iop_conf_t qe_iop_conf_tab[] = { +const qe_iop_conf_t qe_iop_conf_tab[] = { /* port pin dir open_drain assign */ #if defined(CONFIG_MPC8360) /* MDIO */ -- 1.8.0.1

1 4

[U-Boot] [PATCH] net: fec: Avoid MX28 bus sync issue
by Marek Vasut 15 Sep '13

15 Sep '13

The MX28 multi-layer AHB bus can be too slow and trigger the FEC DMA too early, before all the data hit the DRAM. This patch ensures the data are written in the RAM before the DMA starts. Please see the comment in the patch for full details. This patch was produced with an amazing help from Albert Aribaud, who pointed out it can possibly be such a bus synchronisation issue. Signed-off-by: Marek Vasut <marex(a)denx.de> Cc: Albert ARIBAUD <albert.u.boot(a)aribaud.net> Cc: Fabio Estevam <fabio.estevam(a)freescale.com> Cc: Stefano Babic <sbabic(a)denx.de> --- drivers/net/fec_mxc.c | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c index 97bf8fe..ec5b9db 100644 --- a/drivers/net/fec_mxc.c +++ b/drivers/net/fec_mxc.c @@ -737,6 +737,28 @@ static int fec_send(struct eth_device *dev, void *packet, int length) flush_dcache_range(addr, addr + size); /* + * Below we read the DMA descriptor's last four bytes back from the + * DRAM. This is important in order to make sure that all WRITE + * operations on the bus that were triggered by previous cache FLUSH + * have completed. + * + * Otherwise, on MX28, it is possible to observe a corruption of the + * DMA descriptors. Please refer to schematic "Figure 1-2" in MX28RM + * for the bus structure of MX28. The scenario is as follows: + * + * 1) ARM core triggers a series of WRITEs on the AHB_ARB2 bus going + * to DRAM due to flush_dcache_range() + * 2) ARM core writes the FEC registers via AHB_ARB2 + * 3) FEC DMA starts reading/writing from/to DRAM via AHB_ARB3 + * + * Note that 2) does sometimes finish before 1) due to reordering of + * WRITE accesses on the AHB bus, therefore triggering 3) before the + * DMA descriptor is fully written into DRAM. This results in occasional + * corruption of the DMA descriptor. + */ + readl(addr + size - 4); + + /* * Enable SmartDMA transmit task */ fec_tx_task_enable(fec); -- 1.7.10.4

10 54

[U-Boot] [PATCH] arm: spl: Do not set the stack pointer twice
by Masahiro Yamada 14 Sep '13

14 Sep '13

Because the stack pointer is already set in arch/arm/lib/crt0.S, we do not need to set it in arch/arm/lib/spl.c. Signed-off-by: Masahiro Yamada <yamada.m(a)jp.panasonic.com> --- arch/arm/lib/spl.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/arch/arm/lib/spl.c b/arch/arm/lib/spl.c index 301f082..b5a1324 100644 --- a/arch/arm/lib/spl.c +++ b/arch/arm/lib/spl.c @@ -41,9 +41,6 @@ gd_t gdata __attribute__ ((section(".data"))); */ void __weak board_init_f(ulong dummy) { - /* Set the stack pointer. */ - asm volatile("mov sp, %0\n" : : "r"(CONFIG_SPL_STACK)); - /* Clear the BSS. */ memset(__bss_start, 0, __bss_end - __bss_start); -- 1.8.1.2

2 1

[U-Boot] Possible GPL violation
by Mateusz Kulikowski 12 Sep '13

12 Sep '13

Hi, Short version: Is there anyone that can support me with enforcing GPL compliance on company that ships product with binary u-boot? Or did that in the past? Long version: Polish market is flooded with cheap DVB-T receivers (we're switching to digital tv now), android tablets etc. They're "made" (branded is probably better word) by local companies, and my guess is that most of them is violating GPL. Some time ago I've bought WIWA HD100 DVB-T receiver. I have coverage issues, so I decided to play a bit with this device, just to have fun (also to try to port Linux there). I already knew that other models made by this vendor are using u-boot, so I played a bit with HW, found serial port and: <log> Hello U-Boot U-Boot 1.1.6 (Oct 13 2011 - 00:32:14) Board: MSTAR KRNOUS (CPU Speed 552 MHz) DRAM: 64 X 0 MBytes U-Boot is running at DRAM 0x87600000 </log> I also disassembled parts of asm code (AFAIR it was mips_cache_reset, but I may be wrong). I'd love to have sources (porting Linux to unknown, closed SOC is painful without documentation, u-boot sources are very helpful), so I wrote to manufacturer and called them several times. Unfortunately they either don't understand what I'm asking for, or deliberately ignoring my requests. I can't do much myself (except for nagging them for source code), as it's not my copyrights that they're infringing. Is there a chance that you can help me or should I try using GPL-Violations mailing list? Regards, Mateusz

6 10

[U-Boot] U-Boot mini-summit at ELCE 2013 in Edinburgh - call for participation!
by Detlev Zundel 12 Sep '13

12 Sep '13

Hi fellow U-Boot developers, people meeting us at our booth at the Embedded World trade show in Nürnberg this year may already have heard rumours about it but now it is official - there will be an U-Boot mini-summit at the Emdedd Linux Conference Europe in Edinburgh, UK [1]. Thanks to the wonderful people at the Linux Foundation, we will have some space in the afternoon of thursday 24th that we can use to present and discuss topics of interest for the immediate future of the project. Currently we believe that it makes sense to plan for 4-5 short talks in the range of 20-30 minutes with following Q&A. The audience will very likely be "tech level" and the presentations are thus allowed to have "indecent technical content" :) Of course everybody is invited to suggest a presentation, but an informal poll turned up these topics of interest: - Driver model - Kconfig - Patman tutorial - U-Boot configuration through device tree - Falcon boot for everybody - DFU - Android fastboot The organization of the mini-summit is up to our discretion and thus somewhat less formal than the "regular" ELCE tracks, but we would like to encourage people to also submit U-Boot related talks through the regular CFP[2] if they are of wide interest. Having agreed on our schedule, we will be able to get it included in the official conference schedule and thus hopefully get a broader visibility. To make this work we should finalize our schedule around the end of the official CFP which is July 21st, but of course the sooner, the better. Please inform us if you would like to attend in order to get an idea of the expected presence. If neccessary we will have to look for a larger place early on. Next to the official program I'm sure that we will be able to find a place in the evening to taste local culinary specialities (in solid and liquid form), so be sure to book your return flight no sooner than friday evening ;) Thanks Detlev [1] http://events.linuxfoundation.org/events/embedded-linux-conference-europe [2] http://events.linuxfoundation.org/events/embedded-linux-conference-europe/c… -- The only thing worse than generalizing from one example is generalizing from no examples at all. -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu(a)denx.de

9 13

[U-Boot] [PATCH v1 0/7] The patchset fixes some issue in the generation of the imx image
by Stefano Babic 11 Sep '13

11 Sep '13

(header for Freescale's i.MX processors) to allow the usage of Freescale's tools to sign the u-boot image and provide a secure boot. This has nothing to do with the Secure Boot extensions implemented by Simon Glass, that can be in any case used to boot later a secure image. Freescale's secure boot ensures that a signed bootloader is started only if it is verified with a key that is burned into the iMX fuses. Documentation about the Freescale's secure process can be read from the AN4591, available on the Freescale's Website. The patchset allows to add to the imx Header the CSF (command Sequence File) generated by the tools provided by Freescale. The CSF is then simply concatenated to the u-boot image, making a signed bootloader, that the processor can verify if the fuses for the keys are burned. The processor (i.MX53 / i.MX6x) will not start a bootloader that cannot be verified - further infos how to configure the SOC to verify the bootloader can be found in the User Manual of the specific SOC. Next step is to verify the kernel, that can be still done using Simon's patches for verified boot (CONFIG_OF_CONTROL must be set in the board configuarion file). Stefano Babic (7): tools: imx_header should not include flash_offset tools: rename mximage_flash_offset to imximage_ivt_offset tools: dynamically allocate imx_header in imximage tools: add variable padding of data image in mkimage tools: add padding of data image file for imximage tools: add support for setting the CSF into imximage imx: add status reporting for HAB status arch/arm/cpu/armv7/mx6/Makefile | 2 +- arch/arm/cpu/armv7/mx6/hab.c | 127 ++++++++++++++++++++++ arch/arm/include/asm/arch-mx6/hab.h | 80 ++++++++++++++ arch/arm/include/asm/arch-mx6/imx-regs.h | 8 +- doc/README.imximage | 18 +++- doc/README.mxc_hab | 48 +++++++++ tools/imximage.c | 168 +++++++++++++++++++++++++++--- tools/imximage.h | 20 +++- tools/mkimage.c | 24 ++++- tools/mkimage.h | 5 +- 10 files changed, 471 insertions(+), 29 deletions(-) create mode 100644 arch/arm/cpu/armv7/mx6/hab.c create mode 100644 arch/arm/include/asm/arch-mx6/hab.h create mode 100644 doc/README.mxc_hab -- 1.7.9.5

9 49

[U-Boot] [PATCH] imx: nitrogen6x/mx6qsabrelite: Fix bug in board_video_skip
by Robert Winkler 10 Sep '13

10 Sep '13

Signed-off-by: Robert Winkler <robert.winkler(a)boundarydevices.com> --- board/boundary/nitrogen6x/nitrogen6x.c | 4 +++- board/freescale/mx6qsabrelite/mx6qsabrelite.c | 4 +++- 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/board/boundary/nitrogen6x/nitrogen6x.c b/board/boundary/nitrogen6x/nitrogen6x.c index 0e2ab04..da0698d 100644 --- a/board/boundary/nitrogen6x/nitrogen6x.c +++ b/board/boundary/nitrogen6x/nitrogen6x.c @@ -660,6 +660,7 @@ int board_video_skip(void) if (!panel) { panel = displays[0].mode.name; printf("No panel detected: default to %s\n", panel); + i = 0; } } else { for (i = 0; i < ARRAY_SIZE(displays); i++) { @@ -676,9 +677,10 @@ int board_video_skip(void) displays[i].mode.name, displays[i].mode.xres, displays[i].mode.yres); - } else + } else { printf("LCD %s cannot be configured: %d\n", displays[i].mode.name, ret); + } } else { printf("unsupported panel %s\n", panel); ret = -EINVAL; diff --git a/board/freescale/mx6qsabrelite/mx6qsabrelite.c b/board/freescale/mx6qsabrelite/mx6qsabrelite.c index 191084b..2a81165 100644 --- a/board/freescale/mx6qsabrelite/mx6qsabrelite.c +++ b/board/freescale/mx6qsabrelite/mx6qsabrelite.c @@ -595,6 +595,7 @@ int board_video_skip(void) if (!panel) { panel = displays[0].mode.name; printf("No panel detected: default to %s\n", panel); + i = 0; } } else { for (i = 0; i < ARRAY_SIZE(displays); i++) { @@ -611,9 +612,10 @@ int board_video_skip(void) displays[i].mode.name, displays[i].mode.xres, displays[i].mode.yres); - } else + } else { printf("LCD %s cannot be configured: %d\n", displays[i].mode.name, ret); + } } else { printf("unsupported panel %s\n", panel); ret = -EINVAL; -- 1.8.3

2 1

[U-Boot] [PATCH] mx6: Fix calculation of emi_slow clock rate
by Andrew Gabbasov 10 Sep '13

10 Sep '13

This is porting of Freescale's patch from version imx_v2009.08_3.0.35_4.0.0, that fixes the obvious mistype of bits offset macro name (ACLK_EMI_PODF_OFFSET was used instead of ACLK_EMI_SLOW_PODF_OFFSET). Using the occasion, change the variable name 'emi_slow_pof' to more consistent 'emi_slow_podf'. Signed-off-by: Jason Liu <r64343(a)freescale.com> Signed-off-by: Andrew Gabbasov <andrew_gabbasov(a)mentor.com> --- arch/arm/cpu/armv7/mx6/clock.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm/cpu/armv7/mx6/clock.c b/arch/arm/cpu/armv7/mx6/clock.c index 3c0d908..064f8c8 100644 --- a/arch/arm/cpu/armv7/mx6/clock.c +++ b/arch/arm/cpu/armv7/mx6/clock.c @@ -244,13 +244,13 @@ static u32 get_axi_clk(void) static u32 get_emi_slow_clk(void) { - u32 emi_clk_sel, emi_slow_pof, cscmr1, root_freq = 0; + u32 emi_clk_sel, emi_slow_podf, cscmr1, root_freq = 0; cscmr1 = __raw_readl(&imx_ccm->cscmr1); emi_clk_sel = cscmr1 & MXC_CCM_CSCMR1_ACLK_EMI_SLOW_MASK; emi_clk_sel >>= MXC_CCM_CSCMR1_ACLK_EMI_SLOW_OFFSET; - emi_slow_pof = cscmr1 & MXC_CCM_CSCMR1_ACLK_EMI_SLOW_PODF_MASK; - emi_slow_pof >>= MXC_CCM_CSCMR1_ACLK_EMI_PODF_OFFSET; + emi_slow_podf = cscmr1 & MXC_CCM_CSCMR1_ACLK_EMI_SLOW_PODF_MASK; + emi_slow_podf >>= MXC_CCM_CSCMR1_ACLK_EMI_SLOW_PODF_OFFSET; switch (emi_clk_sel) { case 0: @@ -267,7 +267,7 @@ static u32 get_emi_slow_clk(void) break; } - return root_freq / (emi_slow_pof + 1); + return root_freq / (emi_slow_podf + 1); } #ifdef CONFIG_MX6SL -- 1.7.10.4

3 2

[U-Boot] standalone-examples: support custom GCC lib
by Jack Mitchell 10 Sep '13

10 Sep '13

Fighting with compiling u-boot today and dealing with problems related to using a custom built openembedded toolchain, I found the need to specify a custom location for the GCC lib. This is well supported when building u-boot, but my compile was failing in the standalone examples, as there was no support for a custom GCC lib in the standalone examples Makefile. I am no toolchain or u-boot expert, and as such to avoid the firey pits of flamewar hell, this is an RFC ;) -- Jack Mitchell (jack(a)embed.me.uk) Embedded Systems Engineer http://www.embed.me.uk --

3 5