June 2014 - U-Boot

[U-Boot] [PATCH v3 1/3] mx28evk: Fix warning when CONFIG_ENV_IS_IN_SPI_FLASH is selected
by Fabio Estevam 17 Jun '14

17 Jun '14

From: Fabio Estevam <fabio.estevam(a)freescale.com> When building a target with CONFIG_ENV_IS_IN_SPI_FLASH the following warning is seen: include/configs/mx28evk.h:73:0: warning: "CONFIG_ENV_SIZE" redefined [enabled by default] Protect the definition of CONFIG_ENV_SIZE to avoid the warning. Signed-off-by: Fabio Estevam <fabio.estevam(a)freescale.com> --- Change since v2: - Avoid build breakage for mx28evk and mx28evk_nand targets include/configs/mx28evk.h | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h index 9b9124a..9daa0bf 100644 --- a/include/configs/mx28evk.h +++ b/include/configs/mx28evk.h @@ -48,7 +48,11 @@ #define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1 /* Environment */ +#ifndef CONFIG_ENV_IS_IN_SPI_FLASH #define CONFIG_ENV_SIZE (16 * 1024) +#else +#define CONFIG_ENV_SIZE (4 * 1024) +#endif #define CONFIG_ENV_OVERWRITE /* Environment is in MMC */ @@ -70,7 +74,6 @@ /* Environemnt is in SPI flash */ #if defined(CONFIG_CMD_SF) && defined(CONFIG_ENV_IS_IN_SPI_FLASH) #define CONFIG_SYS_REDUNDAND_ENVIRONMENT -#define CONFIG_ENV_SIZE 0x1000 /* 4KB */ #define CONFIG_ENV_OFFSET 0x40000 /* 256K */ #define CONFIG_ENV_OFFSET_REDUND (CONFIG_ENV_OFFSET + CONFIG_ENV_SIZE) #define CONFIG_ENV_SECT_SIZE 0x1000 -- 1.8.3.2

2 4

[U-Boot] [PATCH] embestmx6boards: Fix the dtb file name for riotboard
by Fabio Estevam 17 Jun '14

17 Jun '14

The name of the dtb file used in the kernel is 'imx6dl-riotboard.dtb', so fix it accordingly. Signed-off-by: Fabio Estevam <fabio.estevam(a)freescale.com> --- include/configs/embestmx6boards.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/embestmx6boards.h b/include/configs/embestmx6boards.h index 1d5fde6..f1000f3 100644 --- a/include/configs/embestmx6boards.h +++ b/include/configs/embestmx6boards.h @@ -293,7 +293,7 @@ #if defined(CONFIG_ENV_IS_IN_MMC) /* RiOTboard */ -#define CONFIG_DEFAULT_FDT_FILE "imx6s-riotboard.dtb" +#define CONFIG_DEFAULT_FDT_FILE "imx6dl-riotboard.dtb" #define CONFIG_SYS_FSL_USDHC_NUM 3 #define CONFIG_SYS_MMC_ENV_DEV 2 /* SDHC4 */ #define CONFIG_ENV_OFFSET (6 * 64 * 1024) -- 1.8.3.2

3 2

[U-Boot] [PATCH] embestmx6boards: Fix CONFIG_CONSOLE_DEV
by Fabio Estevam 17 Jun '14

17 Jun '14

mars and riot boards use UART2 as console, so CONFIG_CONSOLE_DEV should point to 'ttymxc1' instead. Signed-off-by: Fabio Estevam <fabio.estevam(a)freescale.com> --- Untested as I don't have access to this board. include/configs/embestmx6boards.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/embestmx6boards.h b/include/configs/embestmx6boards.h index eb91c44..1d5fde6 100644 --- a/include/configs/embestmx6boards.h +++ b/include/configs/embestmx6boards.h @@ -20,7 +20,7 @@ #include <linux/sizes.h> #define CONFIG_MXC_UART_BASE UART2_BASE -#define CONFIG_CONSOLE_DEV "ttymxc0" +#define CONFIG_CONSOLE_DEV "ttymxc1" #define CONFIG_MMCROOT "/dev/mmcblk1p2" #define PHYS_SDRAM_SIZE (1u * 1024 * 1024 * 1024) -- 1.8.3.2

3 2

[U-Boot] [PATCH] mx6: drop ARM errata 742230
by Shawn Guo 17 Jun '14

17 Jun '14

Commit e9fd66defd7e (ARM: mx6: define CONFIG_ARM_ERRATA_742230) enables errata 742230 for imx6, because it helps remove one reboot issue. However, this errata does not really apply on imx6, because Cortex-A9 on imx6 is r2p10 while the errata only applies to revisions r1p0..r2p2. At a later time, commit f71cbfe3ca5d (ARM: Add workaround for Cortex-A9 errata 794072) adds support of errata 794072, which applies to all Cortex-A9 revisions. As the workaround for both errata are exactly same, it makes a lot more sense to select 794072 instead of 742230 for imx6. Since we already enable 794072 for imx6, it's time to drop errata 742230 to avoid confusion. Signed-off-by: Shawn Guo <shawn.guo(a)freescale.com> --- include/configs/mx6_common.h | 1 - 1 file changed, 1 deletion(-) diff --git a/include/configs/mx6_common.h b/include/configs/mx6_common.h index 8a8920f6cc8a..e4a5cc5be1a6 100644 --- a/include/configs/mx6_common.h +++ b/include/configs/mx6_common.h @@ -17,7 +17,6 @@ #ifndef __MX6_COMMON_H #define __MX6_COMMON_H -#define CONFIG_ARM_ERRATA_742230 #define CONFIG_ARM_ERRATA_743622 #define CONFIG_ARM_ERRATA_751472 #define CONFIG_ARM_ERRATA_794072 -- 1.8.3.2

3 2

[U-Boot] [PATCH 1/2] arm: mxs: Enable CONFIG_SYS_GENERIC_BOARD on M28EVK
by Marek Vasut 17 Jun '14

17 Jun '14

Signed-off-by: Marek Vasut <marex(a)denx.de> --- include/configs/m28evk.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/m28evk.h b/include/configs/m28evk.h index bb1fa44..8f31467 100644 --- a/include/configs/m28evk.h +++ b/include/configs/m28evk.h @@ -7,9 +7,9 @@ #ifndef __CONFIGS_M28EVK_H__ #define __CONFIGS_M28EVK_H__ - /* System configurations */ #define CONFIG_MX28 /* i.MX28 SoC */ +#define CONFIG_SYS_GENERIC_BOARD #define MACH_TYPE_M28EVK 3613 #define CONFIG_MACH_TYPE MACH_TYPE_M28EVK -- 1.9.0

3 7

[U-Boot] [PATCH] mx6: Fix definition of IOMUXC_GPR12_DEVICE_TYPE_RC
by Fabio Estevam 17 Jun '14

17 Jun '14

From: Fabio Estevam <fabio.estevam(a)freescale.com> mx6 reference manual incorrectly states that the DEVICE_TYPE field of IOMUXC_GPR12 register should be configured as '0010' for setting the PCI controller in RC mode. The correct value should be '0100' instead. This also aligns with the same value used in the mx6 pci kernel driver. Signed-off-by: Fabio Estevam <fabio.estevam(a)freescale.com> --- arch/arm/include/asm/arch-mx6/iomux.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/include/asm/arch-mx6/iomux.h b/arch/arm/include/asm/arch-mx6/iomux.h index f9ee0d9..6a4a632 100644 --- a/arch/arm/include/asm/arch-mx6/iomux.h +++ b/arch/arm/include/asm/arch-mx6/iomux.h @@ -39,7 +39,7 @@ #define IOMUXC_GPR12_LOS_LEVEL_MASK (0x1f << 4) #define IOMUXC_GPR12_APPS_LTSSM_ENABLE (1 << 10) #define IOMUXC_GPR12_DEVICE_TYPE_EP (0x0 << 12) -#define IOMUXC_GPR12_DEVICE_TYPE_RC (0x2 << 12) +#define IOMUXC_GPR12_DEVICE_TYPE_RC (0x4 << 12) #define IOMUXC_GPR12_DEVICE_TYPE_MASK (0xf << 12) /* -- 1.8.3.2

3 3

[U-Boot] Powerpc/lib: wait_ticks function hangs(u-boot-2014.04 )
by ranjini Raveendran 17 Jun '14

17 Jun '14

Hi, We are using u-boot-2014.04 for the Freescale COM Express Evaluation board. We compiled it for SD card boot option . uboot hangs due to wait_ticks function . We went through the mailing list. Found out that a patch for this function had done around 28 Jan 2013 . But in our board still it hangs . When we commented the function and the uboot came up . But I know this is not the fix for the problem. Can You suggest any patch up for the same ? Regards Ranjini

1 0

[U-Boot] Atmel SAMA5D31 NOR boot - sanity check required
by Andy Pont 17 Jun '14

17 Jun '14

Hello! I am currently working on an implementation of NOR boot support for the Atmel SAMA5D31-EK reference platform as a precursor to a custom hardware platform. When tested and working I will push the support back to the community but what I have at the moment doesn't appear to do anything so I would appreciate a sanity check on the work done so far. For reference the documentation for the Atmel SoC says: If BMS signal is tied to 0, BMS_BIT is read at 1. The ROM code allows execution of the code contained in the memory connected to Chip Select 0 of the External Bus Interface (J828F128P33TF70A) and then goes on to detail the startup mode and changes that need to be made to the PLL and SMC. For simplicity sake, I have taken the standard SAMA5D31-EK configuration of SPL+U-Boot and have added NOR boot support to SPL based on one of the other boards. The board header file has the following configuration: #define CONFIG_SPL_NOR_SUPPORT #define CONFIG_SYS_FLASH_CFI 1 #define CONFIG_FLASH_CFI_DRIVER 1 #define CONFIG_SYS_FLASH_BASE 0x00000000 #define CONFIG_SYS_MONITOR_BASE CONFIG_SYS_FLASH_BASE As per the standard SPL build for this hardware platform the CONFIG_SYS_INIT_SP_ADDR value is set to 0x310000 but I haven't found a definitive statement that confirms that the internal SRAM is mapped to that location when in this boot mode. So my questions are... Is the SPL+U-Boot implementation the best way for NOR booting or should it all just be built as a single U-Boot image? Do the settings above look correct, particularly the value for the initial stack pointer? How best do I debug SPL to determine where it is getting lost in the weeds? Many thanks, Andy.

1 0

Re: [U-Boot] [ELDK] U-Boot default CONFIG_AUTOBOOT_DELAY_STR
by Wolfgang Denk 17 Jun '14

17 Jun '14

Dear Larry, In message <5070A944-CC27-4388-91E5-78B0792E590C(a)usgs.gov> you wrote: > > A recent situation has awakened me to a a behavior of U-Boot that maybe should be changed. U-Boot related questions should better be discussed on the U-Boot (rather than the ELDK) mailing list. I'm adding the U-Boot list on Cc. > I am experimenting with a BeagleBone Black (BBB) single-board > computer. Occasionally when I perform a reboot, the BBB never > finishes booting Linux. When I happen to have a console cable > connected, I see the U-Boot prompt. This explains why the BBB has not > booted Linux. But it is a mystery why U-Boot is waiting for a command > when I did not request interrupting the autoboot sequence. > > I found many others reporting the same experience -- and no solution. > Until I found Andrew Glen's 10/28/2013 post at > https://groups.google.com/forum/#!topic/beagleboard/aXv6An1xfqI about > U-Boot hangs likely due to noise on the UART0 port. The solution he > applied was to rebuild U-Boot to require specific text -- "uboot" -- > to interrupt the autoboot sequence. (BBB have no flash, so there is > no opportunity to permanently alter any U-Boot environment variables, > if this is settable.) You should be able to store the environment on SDCard. > It occurs to me that this might be a more common occurrence on any > number of circuit boards. No, this is in no way a common issue. If you have any such line noise on a serial port, you should start looking for hardware (design) problems. This is _not_ normal. IF several boards of a specific brand show such a problem, then I'm willing to bet that it's caused by broken (or simply too cheap) hardware design. No industrial grade board I've ever seen has any such issues. > I have used many ARM single-board computers that have U-Boot. As far > as I recall, they all prompt "Hit any key to stop autoboot:". It is > probably not such a good idea that ANY character can interrupt the > U-Boot autoboot sequence. Perhaps the default should be to require an > unusual character, like F2 or DEL for BIOS. Or a multi-character > sequence within a short period of time, like the "+++" to enter > command mode on the old Hayes modems. U-Boot allows you to do that, if you really need/want to. > As I said, this awakening only occurred to me because of my recent > experience with boot failures. My realization is that U-Boot could > probably do a little better job of protecting our (likely unattended, > embedded) systems with a minimum of change to the code. I plan to > make it my practice to #define CONFIG_AUTOBOOT_DELAY_STR. I'm > thinking that should probably be the default. U-Boot allows you such customization. But I disagree that this should be the default. Actually you are just papering over a hardware problem. Line noise on a serial port that inserts phantom characters is something that should be fixed, not ignored. And on ony well- behaving hardware the problem that bothers you simply does not exist. > Thank you for your valuable contributions (U-Boot and more). You are welcome. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd(a)denx.de "We don't have to protect the environment -- the Second Coming is at hand." - James Watt

4 3

[U-Boot] [PATCH 0/6] FPGA changes
by Michal Simek 17 Jun '14

17 Jun '14

Hi, This series is based on FPGA changes I have sent http://lists.denx.de/pipermail/u-boot/2014-April/178204.html Series contain fpga chagnes for cleaning up full and partial bitstream loading. Also compressed bitstreams are supported. Bitstream detection was done based on device size but it doesn't work for compressed bitstreams. That's why user has to decide which bitstream works with. For that purpose LOADP/LOADBP commands have been created. LOADMK was guarded to have an option to disable it for systems with limited amount of memory. For easier testing full branch with all patches and patman description is available here. http://git.denx.de/?p=u-boot/u-boot-microblaze.git;a=shortlog;h=refs/heads/… Thanks, Michal Michal Simek (5): configs: iocom: Fix typo on CMD_FPGA command fpga: Define bitstream type based on command selection fpga: Add support to load partial bitstreams fpga: zynqpl: Clean partial bitstream handling zynq: Enable fpga loadp and loadbp commands Siva Durga Prasad Paladugu (1): fpga: Guard the LOADMK functionality with CMD_FPGA_LOADMK README | 13 +++++++++ board/matrix_vision/common/mv_common.c | 2 +- common/cmd_fpga.c | 51 +++++++++++++++++++++++++++++++--- drivers/fpga/fpga.c | 8 ++++-- drivers/fpga/spartan2.c | 3 +- drivers/fpga/spartan3.c | 3 +- drivers/fpga/virtex2.c | 3 +- drivers/fpga/xilinx.c | 10 ++++--- drivers/fpga/zynqpl.c | 22 ++++++--------- include/configs/GEN860T.h | 1 + include/configs/MVBC_P.h | 1 + include/configs/MVBLM7.h | 1 + include/configs/MVSMR.h | 1 + include/configs/alpr.h | 1 + include/configs/astro_mcf5373l.h | 1 + include/configs/balloon3.h | 1 + include/configs/coreboot.h | 1 + include/configs/grsim.h | 1 + include/configs/grsim_leon2.h | 1 + include/configs/iocon.h | 3 +- include/configs/mt_ventoux.h | 1 + include/configs/omap3_mvblx.h | 1 + include/configs/x600.h | 1 + include/configs/zynq-common.h | 3 ++ include/fpga.h | 11 ++++++-- include/xilinx.h | 5 ++-- 26 files changed, 116 insertions(+), 34 deletions(-) -- 1.8.2.3

3 8