July 2013 - U-Boot

[U-Boot] [PATCH] mx28evk: Convert to phylib framework
by Fabio Estevam 12 Jul '13

12 Jul '13

From: Fabio Estevam <fabio.estevam(a)freescale.com> mx28evk has a LAN8270 ethernet phy and we can use the phylib framework. One of the advantages of converting to phylib is that we no longer see a timeout prior to the first transfer in the 'tftp' command. Signed-off-by: Fabio Estevam <fabio.estevam(a)freescale.com> --- After applying this patch I get: U-Boot 2013.04-11810-gd6d75ec-dirty (Jul 12 2013 - 01:15:03) CPU: Freescale i.MX28 rev1.2 at 454 MHz BOOT: SSP SD/MMC #0, 3V3 DRAM: 128 MiB MMC: MXS MMC: 0 Video: MXSFB: 'videomode' variable not set! In: serial Out: serial Err: serial Net: Phy not found I still get this 'Phy not found' message, but I think this is not related to the board code. board/freescale/mx28evk/mx28evk.c | 15 +-------------- include/configs/mx28evk.h | 3 ++- 2 files changed, 3 insertions(+), 15 deletions(-) diff --git a/board/freescale/mx28evk/mx28evk.c b/board/freescale/mx28evk/mx28evk.c index 4edd9f4..cd81d58 100644 --- a/board/freescale/mx28evk/mx28evk.c +++ b/board/freescale/mx28evk/mx28evk.c @@ -110,7 +110,6 @@ int board_eth_init(bd_t *bis) { struct mxs_clkctrl_regs *clkctrl_regs = (struct mxs_clkctrl_regs *)MXS_CLKCTRL_BASE; - struct eth_device *dev; int ret; ret = cpu_eth_init(bis); @@ -133,24 +132,12 @@ int board_eth_init(bd_t *bis) return ret; } - ret = fecmxc_initialize_multi(bis, 1, 3, MXS_ENET1_BASE); + ret = fecmxc_initialize_multi(bis, 1, 1, MXS_ENET1_BASE); if (ret) { puts("FEC MXS: Unable to init FEC1\n"); return ret; } - dev = eth_get_dev_by_name("FEC0"); - if (!dev) { - puts("FEC MXS: Unable to get FEC0 device entry\n"); - return -EINVAL; - } - - dev = eth_get_dev_by_name("FEC1"); - if (!dev) { - puts("FEC MXS: Unable to get FEC1 device entry\n"); - return -EINVAL; - } - return ret; } diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h index de69182..2431b83 100644 --- a/include/configs/mx28evk.h +++ b/include/configs/mx28evk.h @@ -170,12 +170,13 @@ /* Ethernet on SOC (FEC) */ #ifdef CONFIG_CMD_NET -#define CONFIG_NET_MULTI #define CONFIG_ETHPRIME "FEC0" #define CONFIG_FEC_MXC #define CONFIG_MII #define CONFIG_FEC_XCV_TYPE RMII #define CONFIG_MX28_FEC_MAC_IN_OCOTP +#define CONFIG_PHYLIB +#define CONFIG_PHY_SMSC #endif /* RTC */ -- 1.8.1.2

3 5

[U-Boot] [PATCH 0/6] Upstream environment changes being used in Yocto/OE
by Otavio Salvador 12 Jul '13

12 Jul '13

This changes were being done in every version of U-Boot and it makes sense to try to merge them upstream. Please review them and ack/nack them. Otavio Salvador (6): mx53loco: Change default environment to cope with OE changes mx6qsabrelite: Change default environment to cope with OE changes mx6slevk: Change default environment to cope with OE changes wandboard: Change default environment to cope with OE changes mx51evk: Change default environment to cope with OE changes mx53ard: Change default environment to cope with OE changes include/configs/mx51evk.h | 4 ++-- include/configs/mx53ard.h | 4 ++-- include/configs/mx53loco.h | 4 ++-- include/configs/mx6qsabrelite.h | 4 ++-- include/configs/mx6slevk.h | 4 ++-- include/configs/wandboard.h | 4 ++-- 6 files changed, 12 insertions(+), 12 deletions(-) -- 1.8.3.1

5 16

Re: [U-Boot] SPL size issues on OMAP4
by Michael Trimarchi 12 Jul '13

12 Jul '13

Hi cc: Mailing List On 07/11/2013 07:33 PM, Michael Trimarchi wrote: > Hi Michael > > On 07/11/2013 07:01 PM, Michael Cashwell wrote: >> Greetings, >> >> I've been absent for a while and couldn't find a way to search the list archives so I apologize if this has already been discussed… >> >> I've been fighting the SPL binary growing too large on OMAP4 (using custom configs and features). It's annoying that too large just fails to run with no build or runtime notice. But that's a different issue. >> >> My main issue is that in looking through the map for SPL I've repeatedly found code that I don't need and have a pretty good handle on that. My issue is that code that is compiled but eliminated because it's not called leaves behind all of its anonymous strings ("like this"). In my latest build I have the following sections that are all anonymous strings: >> >> 0x4030b638 0x232 arch/arm/cpu/armv7/omap-common/libomap-common.o >> 0x4030b8b5 0x19 arch/arm/cpu/armv7/omap4/libomap4.o >> 0x4030b9ad 0xbe common/spl/libspl.o >> 0x4030ba6b 0x57 drivers/gpio/libgpio.o >> 0x4030bac2 0x44c drivers/i2c/libi2c.o >> 0x4030bf0e 0x302 drivers/mmc/libmmc.o >> 0x4030c27e 0x15 drivers/serial/libserial.o >> 0x4030c293 0x145 drivers/spi/libspi.o >> 0x4030c4d8 0x53 lib/libgeneric.o >> >> with more than half being unreferenced. This is a big deal when you only have about 25K of SRAM for code and data. >> > > I don't give an answer but some suggestions: > > - using a raw partition to boot and remove the vfat support in first stage boot > - safety you can add 2Kb more to CONFIG_SPL_MAX_SIZE (tested on serial boot too) > - do some tests on different toolchains > > Try to move all in the second stage when it's possible > > Michael > Michael >> In searching the web it seems that dead code and data are removed using --gc-sections, -ffunction-sections and -fdata-sections which u-boot is using correctly. >> >> But it seems that gcc puts all anonymous strings into the same section (.rodata or .rodata.str1.1 if string merging is on) which prevents them from participating in the stripping process. >> >> Interestingly, it puts its own __func__ strings into separate sections and they are eliminated if the function go away. It just doesn't do this for plain "" strings. Grrr. >> >> I was shocked to find gcc posts asking about this more than 13 years ago with barely any traction at all. Given that embarrassing history I'm not hopefully that the gcc folks will ever address this. >> >> Is there a work around I haven't thought of? I'm thinking along the lines of disabling all printfs in SPL in the hope that will take the strings away (since many are some sort of debug / progress message). >> >> Any thoughts or guidance would be appreciated. >> >> -Mike >> >> _______________________________________________ >> U-Boot mailing list >> U-Boot(a)lists.denx.de >> http://lists.denx.de/mailman/listinfo/u-boot >> >

1 0

[U-Boot] pull request for u-boot-tegra/master into ARM/master
by Tom Warren 12 Jul '13

12 Jul '13

Albert, Please pull u-boot-tegra/master into ARM/master. Thanks! ./MAKEALL -s tegra AOK, checkpatch.pl is clean. The following changes since commit 630aacb0859c6e26b2b0311d8e245da5e5b8ac67: Merge branch 'u-boot-samsung/master' into 'u-boot-arm/master' (2013-07-10 20:4 0:47 +0200) are available in the git repository at: git://git.denx.de/u-boot-tegra master for you to fetch changes up to d035fcf9b6a5a0d7ce8d3d5f3ef960618deea47e: ARM: tegra: enable LCD panel on Ventana (2013-07-11 14:15:16 -0700) ---------------------------------------------------------------- Jim Lin (3): ARM: Tegra: FDT: Add USB EHCI function for T30/T114 ARM: Tegra: USB: EHCI: Add support for Tegra30/Tegra114 Tegra: Config: Enable Tegra30/Tegra114 USB function Stephen Warren (2): ARM: tegra: enable LCD panel on Harmony ARM: tegra: enable LCD panel on Ventana arch/arm/dts/tegra114.dtsi | 27 +++ arch/arm/dts/tegra30.dtsi | 27 +++ arch/arm/include/asm/arch-tegra/clk_rst.h | 10 + arch/arm/include/asm/arch-tegra/usb.h | 182 +++++------------- arch/arm/include/asm/arch-tegra114/usb.h | 156 +++++++++++++++ arch/arm/include/asm/arch-tegra20/usb.h | 155 +++++++++++++++ arch/arm/include/asm/arch-tegra30/usb.h | 168 +++++++++++++++++ board/nvidia/common/board.c | 1 + board/nvidia/dts/tegra114-dalmore.dts | 7 + board/nvidia/dts/tegra20-harmony.dts | 32 ++++ board/nvidia/dts/tegra20-ventana.dts | 32 ++++ board/nvidia/dts/tegra30-beaver.dts | 6 + board/nvidia/dts/tegra30-cardhu.dts | 6 + board/nvidia/harmony/harmony.c | 7 + drivers/usb/host/ehci-tegra.c | 304 ++++++++++++++++++++++++++---- include/configs/beaver.h | 14 ++ include/configs/cardhu.h | 14 ++ include/configs/dalmore.h | 14 ++ include/configs/harmony.h | 9 + include/configs/tegra114-common.h | 3 + include/configs/tegra30-common.h | 3 + include/configs/ventana.h | 9 + include/fdtdec.h | 2 + lib/fdtdec.c | 2 + 24 files changed, 1015 insertions(+), 175 deletions(-) create mode 100644 arch/arm/include/asm/arch-tegra114/usb.h create mode 100644 arch/arm/include/asm/arch-tegra20/usb.h create mode 100644 arch/arm/include/asm/arch-tegra30/usb.h

2 1

[U-Boot] [RFC PATCH] arm: arm926ejs: flush cache before disable it
by Bo Shen 12 Jul '13

12 Jul '13

flush cache before disable it Signed-off-by: Bo Shen <voice.shen(a)gmail.com> --- arch/arm/cpu/arm926ejs/cpu.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/arch/arm/cpu/arm926ejs/cpu.c b/arch/arm/cpu/arm926ejs/cpu.c index 626384c..10aa165 100644 --- a/arch/arm/cpu/arm926ejs/cpu.c +++ b/arch/arm/cpu/arm926ejs/cpu.c @@ -46,15 +46,14 @@ int cleanup_before_linux (void) disable_interrupts (); + /* flush I/D-cache */ + cache_flush(); /* turn off I/D-cache */ icache_disable(); dcache_disable(); l2_cache_disable(); - /* flush I/D-cache */ - cache_flush(); - return 0; } -- 1.7.10.4

3 15

[U-Boot] [PATCH] net: fec: Remove bogus flush_dcache_range() call
by Marek Vasut 12 Jul '13

12 Jul '13

Remove incorrectly called and duplicate flush_dcache_range() call from fec_mxc driver. The call is not needed, since the caches are already flushed in fec_tbd_init(), moreover the second argument should be the ending address, not size. Signed-off-by: Marek Vasut <marex(a)denx.de> Reported-by: Albert Aribaud <albert.u.boot(a)aribaud.net> Cc: Stefano Babic <sbabic(a)denx.de> Cc: Tom Rini <trini(a)ti.com> --- drivers/net/fec_mxc.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c index da95e28..97bf8fe 100644 --- a/drivers/net/fec_mxc.c +++ b/drivers/net/fec_mxc.c @@ -560,7 +560,6 @@ static int fec_init(struct eth_device *dev, bd_t* bd) } memset(fec->tbd_base, 0, size); fec_tbd_init(fec); - flush_dcache_range((unsigned)fec->tbd_base, size); } /* -- 1.7.10.4

2 1

[U-Boot] [PATCH] m28evk: add trimffs to nand command
by Marek Vasut 12 Jul '13

12 Jul '13

this is usefull when writing an UBI image which contains and UBIFS volume (check README.nand and UBI FAQ for more details) Signed-off-by: Marek Vasut <marex(a)denx.de> Cc: Stefano Babic <sbabic(a)denx.de> --- include/configs/m28evk.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/m28evk.h b/include/configs/m28evk.h index 5b3fa43..10ccc3b 100644 --- a/include/configs/m28evk.h +++ b/include/configs/m28evk.h @@ -70,6 +70,7 @@ #define CONFIG_CMD_MII #define CONFIG_CMD_MMC #define CONFIG_CMD_NAND +#define CONFIG_CMD_NAND_TRIMFFS #define CONFIG_CMD_NET #define CONFIG_CMD_NFS #define CONFIG_CMD_PING -- 1.7.10.4

2 1

[U-Boot] U-boot timeout with KSZ8021 phy
by Alexandre Pereira da Silva 12 Jul '13

12 Jul '13

Hi, I am trying to make my ethernet work with u-boot on a custom IMX28 board. This board uses the micrel KSZ8021 phy. The network works fine on linux but won't work properly on u-boot. Here is the output: => dhcp BOOTP broadcast 1 DHCP client bound to address 192.168.1.103 Using FEC device TFTP from server 192.168.1.54; our IP address is 192.168.1.103 Filename 'uImage'. Load address: 0x42000000 Loading: T T T T I am using the apx4devkit board configuration as a base for my port, but adapted the phy setting to the KSZ8021 needed value. If that phy configuration value is wrong, it doesn't even get an IP address from DHCP. Marek's patch about cache didn't help much in my case. Thanks.

2 7

[U-Boot] [PATCH] image: Don't relocate ramdisk to highmem
by Thierry Reding 11 Jul '13

11 Jul '13

From: Thierry Reding <treding(a)nvidia.com> The Linux kernel cannot unpack a ramdisk that's stored in high memory. Unless the initrd_high environment variable is explicitly set, abide by that restriction using the getenv_bootm_low() and getenv_bootm_mapsize() helpers. Signed-off-by: Thierry Reding <treding(a)nvidia.com> --- common/image.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/common/image.c b/common/image.c index e91c89e..bc79b43 100644 --- a/common/image.c +++ b/common/image.c @@ -1090,8 +1090,8 @@ int boot_ramdisk_high(struct lmb *lmb, ulong rd_data, ulong rd_len, if (initrd_high == ~0) initrd_copy_to_ram = 0; } else { - /* not set, no restrictions to load high */ - initrd_high = ~0; + /* make sure to put ramdisk in low memory */ + initrd_high = getenv_bootm_low() + getenv_bootm_mapsize(); } -- 1.8.1.5

4 9

[U-Boot] Porting ehci-exynos.c to handle exynos4412 (odroid-u2)
by Suriyan Ramasami 11 Jul '13

11 Jul '13

Hi wonderful folks! I own an odroid-u2 and the u-boot that comes with it does not have usb support. Its configuration is smdk4412 and I do not find that in the u-boot sources. I see it in the arndale and harkernel branches. I do see that usb support was added to the arndale platform - which is exynos5 based. Is it easy to port it for exynos4412? I did try it porting on my own accord and am listing it below... I seem to be hitting issues in drivers/usb/host/ehci-exynos.c -> function setup_usb_phy(struct exynos_usb_phy *usb). Would passing the correct address of usb for the exynos4412 do the trick? If so what should it be? In this same file ehci_hcd_init() uses gpio->x3 and gpio->d1. In exynos4 looks like x3 is from gpio_part2. Also, do the d1 and x3 translate to the same gpiod1 and gpiox3 in the exynos4412? Furthermore, ehci-exynos.c uses functions from arch/arm/cpu/armv7/exynos/system.c which for the most part are exynos5 oriented and do nothing for exynos4. Can someone guide me as to what I could do, or some pointers to helpful docs? I do have the Exynos 4412 user manual. Thanks - Suriyan

3 4