Re: [U-Boot] can i in u-boot partition a device and format it in fat ?
Hi Altunbas, Hi, i had a look at the u-boot cmd's. I can read/write a file from/to a dos partition but I didn't find a command for partitioning and formatting a device. It is possible with gpt command (please look into the Samsung's Trats board). This allows for GPT restoration/setting (and it is already at mainline). Another option is to use ums command. It floats on the mailing list for some time. With this command you can export eMMC device via usb and format with standard linux tools? Pls ,I need help in this context Mit freundlichen Grüßen / Best regards Sabri Altunbas (DC-IA/EAH2) Tel. +49 (0) 6062/78-526 Fax +49 (0) 6062/78-771 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot -- Best regards, Lukasz Majewski Samsung RD Poland (SRPOL) | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] M29EW flash is detected as 0xFF
FYI. Can u help me anything further. Thanks, Jagan. On Sun, Feb 17, 2013 at 5:21 PM, Jagan Teki jagannadh.t...@gmail.com wrote: Hi, I have a 16MB, M29EW flash on target boards. I got the below info, while probing the flash. Bank # 1: CFI conformant flash (8 x 8) Size: 64 MB in 512 Sectors AMD Standard command set, Manufacturer ID: 0xFF, Device ID: 0xFF Erase timeout: 4096 ms, write timeout: 2 ms Buffer write timeout: 5 ms, buffer size: 1024 bytes Since the Manu.ID of this flash is 0x89, it got detected as 0xFF. Does u-boot code have a support for M29EW flash..? Thanks, Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 2/7] arm: dra7xx: clock: Add the prcm changes
PRCM register addresses are changed from OMAP5 ES2.0 to DRA7XX. So adding the necessary register changes for DRA7XX socs. Signed-off-by: Lokesh Vutla lokeshvu...@ti.com Signed-off-by: R Sricharan r.sricha...@ti.com --- [v2] Removed hard coded constants for PRM_DEVICE_BASE and using the runtime assigned variable instead. Also removed the unnecessary CONTROL_ID_CODE base register change. arch/arm/cpu/armv7/omap4/hw_data.c |2 +- arch/arm/cpu/armv7/omap4/prcm-regs.c |2 +- arch/arm/cpu/armv7/omap5/hw_data.c |6 +- arch/arm/cpu/armv7/omap5/hwinit.c|9 +- arch/arm/cpu/armv7/omap5/prcm-regs.c | 224 +- arch/arm/include/asm/omap_common.h | 17 ++- 6 files changed, 252 insertions(+), 8 deletions(-) diff --git a/arch/arm/cpu/armv7/omap4/hw_data.c b/arch/arm/cpu/armv7/omap4/hw_data.c index 8d31d6d..3b27bc1 100644 --- a/arch/arm/cpu/armv7/omap4/hw_data.c +++ b/arch/arm/cpu/armv7/omap4/hw_data.c @@ -290,7 +290,7 @@ void enable_basic_clocks(void) }; u32 const clk_modules_hw_auto_essential[] = { - (*prcm)-cm_l3_2_gpmc_clkctrl, + (*prcm)-cm_l3_gpmc_clkctrl, (*prcm)-cm_memif_emif_1_clkctrl, (*prcm)-cm_memif_emif_2_clkctrl, (*prcm)-cm_l4cfg_l4_cfg_clkctrl, diff --git a/arch/arm/cpu/armv7/omap4/prcm-regs.c b/arch/arm/cpu/armv7/omap4/prcm-regs.c index c58ce8d..7225a30 100644 --- a/arch/arm/cpu/armv7/omap4/prcm-regs.c +++ b/arch/arm/cpu/armv7/omap4/prcm-regs.c @@ -153,7 +153,7 @@ struct prcm_regs const omap4_prcm = { .cm_l3_2_clkstctrl = 0x4a008800, .cm_l3_2_dynamicdep = 0x4a008808, .cm_l3_2_l3_2_clkctrl = 0x4a008820, - .cm_l3_2_gpmc_clkctrl = 0x4a008828, + .cm_l3_gpmc_clkctrl = 0x4a008828, .cm_l3_2_ocmc_ram_clkctrl = 0x4a008830, .cm_mpu_m3_clkstctrl = 0x4a008900, .cm_mpu_m3_staticdep = 0x4a008904, diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c b/arch/arm/cpu/armv7/omap5/hw_data.c index 1701b09..22590f4 100644 --- a/arch/arm/cpu/armv7/omap5/hw_data.c +++ b/arch/arm/cpu/armv7/omap5/hw_data.c @@ -278,7 +278,7 @@ void enable_basic_clocks(void) }; u32 const clk_modules_hw_auto_essential[] = { - (*prcm)-cm_l3_2_gpmc_clkctrl, + (*prcm)-cm_l3_gpmc_clkctrl, (*prcm)-cm_memif_emif_1_clkctrl, (*prcm)-cm_memif_emif_2_clkctrl, (*prcm)-cm_l4cfg_l4_cfg_clkctrl, @@ -503,6 +503,10 @@ void hw_data_init(void) *omap_vcores = omap5430_volts_es2; break; + case DRA752_ES1_0: + *prcm = dra7xx_prcm; + break; + default: printf(\n INVALID OMAP REVISION ); } diff --git a/arch/arm/cpu/armv7/omap5/hwinit.c b/arch/arm/cpu/armv7/omap5/hwinit.c index d8f711c..6ed 100644 --- a/arch/arm/cpu/armv7/omap5/hwinit.c +++ b/arch/arm/cpu/armv7/omap5/hwinit.c @@ -354,7 +354,12 @@ void reset_cpu(ulong ignored) * So use cold reset in case instead. */ if (omap_rev == OMAP5430_ES1_0) - writel(PRM_RSTCTRL_RESET 0x1, PRM_RSTCTRL); + writel(PRM_RSTCTRL_RESET 0x1, (*prcm)-prm_rstctrl); else - writel(PRM_RSTCTRL_RESET, PRM_RSTCTRL); + writel(PRM_RSTCTRL_RESET, (*prcm)-prm_rstctrl); +} + +u32 warm_reset(void) +{ + return readl((*prcm)-prm_rstst) PRM_RSTST_WARM_RESET_MASK; } diff --git a/arch/arm/cpu/armv7/omap5/prcm-regs.c b/arch/arm/cpu/armv7/omap5/prcm-regs.c index 5e5abcc..ade9875 100644 --- a/arch/arm/cpu/armv7/omap5/prcm-regs.c +++ b/arch/arm/cpu/armv7/omap5/prcm-regs.c @@ -156,7 +156,7 @@ struct prcm_regs const omap5_es1_prcm = { .cm_l3_2_clkstctrl = 0x4a008800, .cm_l3_2_dynamicdep = 0x4a008808, .cm_l3_2_l3_2_clkctrl = 0x4a008820, - .cm_l3_2_gpmc_clkctrl = 0x4a008828, + .cm_l3_gpmc_clkctrl = 0x4a008828, .cm_l3_2_ocmc_ram_clkctrl = 0x4a008830, .cm_mpu_m3_clkstctrl = 0x4a008900, .cm_mpu_m3_staticdep = 0x4a008904, @@ -296,6 +296,8 @@ struct prcm_regs const omap5_es1_prcm = { .cm_wkup_bandgap_clkctrl = 0x4ae07888, .cm_wkupaon_scrm_clkctrl = 0x4ae07890, .cm_wkupaon_io_srcomp_clkctrl = 0x4ae07898, + .prm_rstctrl = 0x4ae07b00, + .prm_rstst = 0x4ae07b04, .prm_vc_val_bypass = 0x4ae07ba0, .prm_vc_cfg_i2c_mode = 0x4ae07bb4, .prm_vc_cfg_i2c_clk = 0x4ae07bb8, @@ -513,7 +515,7 @@ struct prcm_regs const omap5_es2_prcm = { .cm_l3_2_clkstctrl = 0x4a008800, .cm_l3_2_dynamicdep = 0x4a008808, .cm_l3_2_l3_2_clkctrl = 0x4a008820, - .cm_l3_2_gpmc_clkctrl = 0x4a008828, + .cm_l3_gpmc_clkctrl = 0x4a008828, .cm_l3_2_ocmc_ram_clkctrl = 0x4a008830, .cm_mpu_m3_clkstctrl = 0x4a008900, .cm_mpu_m3_staticdep = 0x4a008904, @@ -653,6 +655,8 @@ struct prcm_regs const omap5_es2_prcm = { .cm_wkup_bandgap_clkctrl = 0x4ae07988,
[U-Boot] [PATCH V2 7/7] arm: dra7xx: Add dra7xx_evm build support
Adding the build support for dra7xx_evm. Reusing omap5_evm.h config by moving it to omap5_common.h Signed-off-by: Lokesh Vutla lokeshvu...@ti.com Signed-off-by: R Sricharan r.sricha...@ti.com --- [v2] Addressed Tom Rini's tr...@ti.com comments boards.cfg |1 + include/configs/dra7xx_evm.h| 36 include/configs/{omap5_evm.h = omap5_common.h} | 18 +- include/configs/omap5_evm.h | 241 +-- 4 files changed, 48 insertions(+), 248 deletions(-) create mode 100644 include/configs/dra7xx_evm.h copy include/configs/{omap5_evm.h = omap5_common.h} (94%) diff --git a/boards.cfg b/boards.cfg index 98f7a14..fea1101 100644 --- a/boards.cfg +++ b/boards.cfg @@ -279,6 +279,7 @@ nokia_rx51 arm armv7 rx51 nokia omap4_panda arm armv7 panda ti omap4 omap4_sdp4430arm armv7 sdp4430 ti omap4 omap5_evmarm armv7 omap5_evm ti omap5 +dra7xx_evm arm armv7 dra7xx ti omap5 s5p_goni arm armv7 goni samsungs5pc1xx smdkc100 arm armv7 smdkc100 samsungs5pc1xx origen arm armv7 origen samsungexynos diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h new file mode 100644 index 000..10a4939 --- /dev/null +++ b/include/configs/dra7xx_evm.h @@ -0,0 +1,36 @@ +/* + * (C) Copyright 2013 + * Texas Instruments Incorporated. + * Lokesh Vutla lokeshvu...@ti.com + * + * Configuration settings for the TI DRA7XX board. + * See omap5_common.h for omap5 common settings. + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +#ifndef __CONFIG_DRA7XX_EVM_H +#define __CONFIG_DRA7XX_EVM_H + +#include configs/omap5_common.h + +#define CONFIG_DRA7XX /* in a TI DRA7XX core */ +#define CONFIG_SYS_PROMPT DRA752 EVM # + +#endif /* __CONFIG_DRA7XX_EVM_H */ diff --git a/include/configs/omap5_evm.h b/include/configs/omap5_common.h similarity index 94% copy from include/configs/omap5_evm.h copy to include/configs/omap5_common.h index 1d3ac2b..a162d63 100644 --- a/include/configs/omap5_evm.h +++ b/include/configs/omap5_common.h @@ -1,12 +1,12 @@ /* - * (C) Copyright 2010 + * (C) Copyright 2013 * Texas Instruments Incorporated. * Sricharan R r.sricha...@ti.com * * Derived from OMAP4 done by: * Aneesh V ane...@ti.com * - * Configuration settings for the TI EVM5430 board. + * TI OMAP5 AND DRA7XX common configuration settings * * See file CREDITS for list of people who contributed to this * project. @@ -27,17 +27,14 @@ * MA 02111-1307 USA */ -#ifndef __CONFIG_H -#define __CONFIG_H +#ifndef __CONFIG_OMAP5_COMMON_H +#define __CONFIG_OMAP5_COMMON_H /* * High Level Configuration Options */ -#define CONFIG_ARMV7 /* This is an ARM V7 CPU core */ #define CONFIG_OMAP/* in a TI OMAP core */ #define CONFIG_OMAP54XX/* which is a 54XX */ -#define CONFIG_OMAP5430/* which is in a 5430 */ -#define CONFIG_5430EVM /* working with EVM */ #define CONFIG_OMAP_GPIO /* Get CPU defs */ @@ -96,10 +93,6 @@ #define CONFIG_DRIVER_OMAP34XX_I2C #define CONFIG_I2C_MULTI_BUS -/* TWL6035 */ -#ifndef CONFIG_SPL_BUILD -#define CONFIG_TWL6035_POWER -#endif /* MMC */ #define CONFIG_GENERIC_MMC @@ -185,7 +178,6 @@ #define CONFIG_SYS_LONGHELP/* undef to save memory */ #define CONFIG_SYS_HUSH_PARSER /* use hush command parser */ -#define CONFIG_SYS_PROMPT OMAP5430 EVM # #define CONFIG_SYS_CBSIZE 256 /* Print Buffer Size */ #define CONFIG_SYS_PBSIZE (CONFIG_SYS_CBSIZE + \ @@ -266,4 +258,4 @@ #define CONFIG_SYS_SPL_MALLOC_SIZE 0x10/* 1 MB */ #define CONFIG_SPL_GPIO_SUPPORT -#endif /* __CONFIG_H */ +#endif /* __CONFIG_OMAP5_COMMON_H */ diff --git a/include/configs/omap5_evm.h b/include/configs/omap5_evm.h
[U-Boot] M29EW flash is detected as 0xFF
Hi all, I have a 16MB, M29EW flash on target boards. I got the below info, while probing the flash. Bank # 1: CFI conformant flash (8 x 8) Size: 64 MB in 512 Sectors AMD Standard command set, Manufacturer ID: 0xFF, Device ID: 0xFF Erase timeout: 4096 ms, write timeout: 2 ms Buffer write timeout: 5 ms, buffer size: 1024 bytes Since the Manu.ID of this flash is 0x89, it got detected as 0xFF. Does u-boot code have a support for M29EW flash..? Thanks, Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Notes from the U-Boot BOF Meeting in Geneva 2012/07/12
Dear Simon, In message CAPnjgZ089gS0gLHBVBVARpX=awcyruumslgnir4hfkwzzls...@mail.gmail.com you wrote: I have started on it - I've ported over the Kbuild infrastructure into a dedicated 'kbuild' makefile which is called from the main makefile. This make modifications to the existing makefile very minimal Now it's just a case of building all the Kconfig files which is, to say the least, a massive task. I have a lot of other things going on, so unfortunately progress is slow I wonder how you got on with that? Any work-in-progress that could be used as a base? Want some help? It seems like a useful feature. I also wonder if this has to be a one-step change-it-all-at-once operation? Maybe we can add the infrastructure in a neutral way, and then start moving code to the Kconfig files step by step - similar to what we did with moving Makefile rules out into boards.cfg ? 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: w...@denx.de I have made mistakes, but have never made the mistake of claiming I never made one. - James G. Bennet ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 9/9] dfu: Support larger than memory transfers.
Hi Tom, On Fri, Nov 30, 2012 at 08:01:12PM +0200, Pantelis Antoniou wrote: We didn't support upload/download larger than available memory. This is pretty bad when you have to update your root filesystem for example. This patch removes the limitation (and the crashes when you transfered any file larger than 4MB). On top of that reduces the huge dfu buffer from 4MB to just 64K, which was over the top. The sequence number is a 16 bit counter; make sure we handle rollover correctly. This fixes the wrong transfers for large ( 256MB) images. Also utilize a variable to handle initialization, so that we don't rely on just the counter sent by the host. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com To be clear, patches 1-8 are good and we should take, but this one means we can't use FAT/EXT* partitions without more work. I would suggest that we set this part aside for a moment and perhaps limit transfers that are larget than RAM to RAW only where we can write in chunks today. As fair as I remember, some additional work needs to be done with composite.c file (to remove nasty #ifdefs). There was a problem with newer version of dfu-utils (new handling of descriptors). It is on top of my queue, but I'm currently buried with other work and need to postpone this. However it is still on the back of my head and I push myself to fix this. -- Best regards, Lukasz Majewski Samsung RD Poland (SRPOL) | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] Allow AM33xx boards to setup GPMC chipselects.
Expose the enable_gpmc_cs_config() function so AM33xx based boards can register GPMC chip selects. Changes in V3: - Fix line wrapping Changes in V2: - Indicate this is for AM33xx (not OMAP2) Signed-off-by: Mark Jackson m...@newflow.co.uk --- arch/arm/include/asm/arch-am33xx/sys_proto.h |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/include/asm/arch-am33xx/sys_proto.h b/arch/arm/include/asm/arch-am33xx/sys_proto.h index 588d8de..97ab60d 100644 --- a/arch/arm/include/asm/arch-am33xx/sys_proto.h +++ b/arch/arm/include/asm/arch-am33xx/sys_proto.h @@ -35,5 +35,7 @@ void ddr_pll_config(unsigned int ddrpll_M); void sdelay(unsigned long); void gpmc_init(void); +void enable_gpmc_cs_config(const u32 *gpmc_config, struct gpmc_cs *cs, u32 base, +u32 size); void omap_nand_switch_ecc(int); #endif -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Allow AM33xx boards to setup GPMC chipselects.
On 17/02/13 20:11, Peter Korsgaard wrote: Mark == Mark Jackson mpfj-l...@mimc.co.uk writes: Mark Expose the enable_gpmc_cs_config() function so AM33xx based boards can Mark register GPMC chip selects. Mark Changes in V2: Mark - Indicate this is for AM33xx (not OMAP2) Mark Signed-off-by: Mark Jackson m...@newflow.co.uk Mark --- Mark arch/arm/include/asm/arch-am33xx/sys_proto.h |2 ++ Mark 1 file changed, 2 insertions(+) Mark diff --git a/arch/arm/include/asm/arch-am33xx/sys_proto.h Mark b/arch/arm/include/asm/arch-am33xx/sys_proto.h Mark index 588d8de..97ab60d 100644 Mark --- a/arch/arm/include/asm/arch-am33xx/sys_proto.h Mark +++ b/arch/arm/include/asm/arch-am33xx/sys_proto.h Mark @@ -35,5 +35,7 @@ void ddr_pll_config(unsigned int ddrpll_M); Mark void sdelay(unsigned long); Mark void gpmc_init(void); Mark +void enable_gpmc_cs_config(const u32 *gpmc_config, struct gpmc_cs Mark *cs, u32 base, Mark + u32 size); Seems like your mailer line wrapped the patch. Oops ... resent. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1] Refactor linker-generated arrays
Hi Albert, On 02/16/2013 07:20 PM, Albert ARIBAUD wrote: Hi Andreas, On Mon, 04 Feb 2013 13:41:09 +0100, Andreas Bießmann andreas.de...@googlemail.com wrote: Hi Albert, On 02.02.2013 18:02, Albert ARIBAUD wrote: snip strict aliasing error on gcc-4.4 I have dug into it and found a way to avoid GCC 4.4 or below to warn about aliasing, by replacing 'struct {}' with 'char[0]' as the 0-byte-size type. I still have some warnings through, regarding some regions not being declared: avr32-ld:built in linker script:15: warning: memory region `FLASH' not declared avr32-ld:built in linker script:69: warning: memory region `CPUSRAM' not declared I assume you use Mike Frysingers precompiled avr32 toolchain. I know about that warnings and beware, these toolchain produce defective binaries! The u-boot does not relocate itself properly with these newlib toolchains (also the atmel provided one). It appears 'normal' in that without my patch, the same error occurs; but I'd prefer that you confirm whether you have the same warnings on your side. It's ok so far, the arm-linux toolchain I have do not produce these warnings. Kan you provide the patch so I will do a runtime test. Best regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Notes from the U-Boot BOF Meeting in Geneva 2012/07/12
Hi Wolfgang, On Mon, Feb 18, 2013 at 8:59 PM, Wolfgang Denk w...@denx.de wrote: Dear Simon, In message CAPnjgZ089gS0gLHBVBVARpX=awcyruumslgnir4hfkwzzls...@mail.gmail.com you wrote: I have started on it - I've ported over the Kbuild infrastructure into a dedicated 'kbuild' makefile which is called from the main makefile. This make modifications to the existing makefile very minimal Now it's just a case of building all the Kconfig files which is, to say the least, a massive task. I have a lot of other things going on, so unfortunately progress is slow I wonder how you got on with that? Any work-in-progress that could be used as a base? Want some help? It seems like a useful feature. I also wonder if this has to be a one-step change-it-all-at-once operation? Maybe we can add the infrastructure in a neutral way, and then start moving code to the Kconfig files step by step - similar to what we did with moving Makefile rules out into boards.cfg ? Alas I do not have access to the code I was working on (study is buried in stuff) and I really didn't get that far anyway. But, I got as far as knowing it is possible to run both the current Makefile infrastructure and the KConfig infrastructure in parallel. The trick is to create additional Makefiles (Makefile.kc for example). You just need to add stubs for the KConfig targets (menuconfig, xconfig, etc). Once the core KConfig Make infrastructure is in place, it's simply (?) a case of building all the KConfig files Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1] Refactor linker-generated arrays
On 02/18/2013 11:39 AM, Andreas Bießmann wrote: Hi Albert, On 02/16/2013 07:20 PM, Albert ARIBAUD wrote: snip It's ok so far, the arm-linux toolchain I have do not produce these I mean avr32-linux ... damn weekend ... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] arm:goni: Adjustment of configuration for goni target
From: Arkadiusz Wlodarczyk a.wlodarc...@samsung.com Signed-off-by: Arkadiusz Wlodarczyk a.wlodarc...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Tested-by: Arkadiusz Wlodarczyk a.wlodarc...@samsung.com Cc: Minkyu Kang mk7.k...@samsung.com --- Changes This change encompasses set of adjustments in the configuration of the u-boot in the include/configs/s5p_goni.h, particularly change of rootfs type, change in kernel booting method and added DFU support. All those changes are connected with adjusting of existing goni configuration to latest changes in kernel. --- board/samsung/goni/goni.c |7 +++ include/configs/s5p_goni.h | 37 - 2 files changed, 39 insertions(+), 5 deletions(-) diff --git a/board/samsung/goni/goni.c b/board/samsung/goni/goni.c index ff76963..3c53106 100644 --- a/board/samsung/goni/goni.c +++ b/board/samsung/goni/goni.c @@ -155,4 +155,11 @@ struct s3c_plat_otg_data s5pc110_otg_data = { .regs_otg = S5PC110_OTG_BASE, .usb_phy_ctrl = S5PC110_USB_PHY_CONTROL, }; + +void board_usb_init(void) +{ + debug(USB_udc_probe\n); + s3c_udc_probe(s5pc110_otg_data); +} + #endif diff --git a/include/configs/s5p_goni.h b/include/configs/s5p_goni.h index 56e8347..8a824c7 100644 --- a/include/configs/s5p_goni.h +++ b/include/configs/s5p_goni.h @@ -86,6 +86,17 @@ #define CONFIG_CMD_ONENAND #define CONFIG_CMD_MTDPARTS #define CONFIG_CMD_MMC +#define CONFIG_CMD_DFU + +/* USB Composite download gadget - g_dnl */ +#define CONFIG_USBDOWNLOAD_GADGET +#define CONFIG_DFU_FUNCTION +#define CONFIG_DFU_MMC + +/* USB Samsung's IDs */ +#define CONFIG_G_DNL_VENDOR_NUM 0x04E8 +#define CONFIG_G_DNL_PRODUCT_NUM 0x6601 +#define CONFIG_G_DNL_MANUFACTURER Samsung #define CONFIG_BOOTDELAY 1 #define CONFIG_ZERO_BOOTDELAY_CHECK @@ -105,9 +116,13 @@ ,60m(qboot)\ ,-(UBI)\0 +#define CONFIG_DFU_ALT \ + u-boot mmc 80 400; \ + uImage fat 0 2\0 \ + #define NORMAL_MTDPARTS_DEFAULT MTDPARTS_DEFAULT -#define CONFIG_BOOTCOMMAND run ubifsboot +#define CONFIG_BOOTCOMMAND run mmcboot #define CONFIG_DEFAULT_CONSOLE console=ttySAC2,115200n8\0 @@ -137,7 +152,7 @@ onenand erase 0x0156 0x1eaa; \ onenand write 0x3200 0x126 0x8C\0 \ bootk= \ - onenand read 0x30007FC0 0xc0 0x60; \ + run loaduimage; \ bootm 0x30007FC0\0 \ flashboot= \ set bootargs root=/dev/mtdblock${bootblock} \ @@ -156,21 +171,28 @@ set bootargs CONFIG_RAMDISK_BOOT \ initrd=0x3300,8M ramdisk=8192\0 \ mmcboot= \ - set bootargs root=${mmcblk} rootfstype=${rootfstype} \ + set bootargs root=/dev/mmcblk${mmcdev}p${mmcrootpart} \ + rootfstype=${rootfstype} \ CONFIG_UBI_MTD ${opts} ${lcdinfo} \ CONFIG_COMMON_BOOT ; run bootk\0 \ boottrace=setenv opts initcall_debug; run bootcmd\0 \ bootchart=set opts init=/sbin/bootchartd; run bootcmd\0 \ verify=n\0 \ - rootfstype=cramfs\0 \ + rootfstype=ext4\0 \ console= CONFIG_DEFAULT_CONSOLE \ mtdparts= MTDPARTS_DEFAULT \ meminfo=mem=80M mem=256M@0x4000 mem=128M@0x5000\0 \ + loaduimage=fatload mmc ${mmcdev}:${mmcbootpart} 0x30007FC0 uImage\0 \ + mmcdev=0\0 \ + mmcbootpart=2\0 \ + mmcrootpart=5\0 \ mmcblk=/dev/mmcblk1p1\0 \ bootblock=9\0 \ ubiblock=8\0 \ ubi=enabled\0 \ - opts=always_resume=1 + opts=always_resume=1\0 \ + dfu_alt_info= CONFIG_DFU_ALT + /* Miscellaneous configurable options */ #define CONFIG_SYS_LONGHELP/* undef to save memory */ @@ -211,6 +233,10 @@ #define CONFIG_DOS_PARTITION 1 +/* FAT */ +#define CONFIG_CMD_FAT +#define CONFIG_FAT_WRITE + #define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_LOAD_ADDR - 0x100) #define CONFIG_SYS_CACHELINE_SIZE 64 @@ -233,5 +259,6 @@ #define CONFIG_USB_GADGET #define CONFIG_USB_GADGET_S3C_UDC_OTG #define CONFIG_USB_GADGET_DUALSPEED +#define CONFIG_USB_GADGET_VBUS_DRAW 2 #endif /* __CONFIG_H */ -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] arm:goni:Change in mmc memory partitioning
From: Arkadiusz Wlodarczyk a.wlodarc...@samsung.com Signed-off-by: Arkadiusz Wlodarczyk a.wlodarc...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Tested-by: Arkadiusz Wlodarczyk a.wlodarc...@samsung.com Cc: Minkyu Kang mk7.k...@samsung.com --- Changes This item includes the following changes for goni target: Add GPT command Add definition of partitions for GPT Remove MTD command --- include/configs/s5p_goni.h | 44 ++-- 1 files changed, 26 insertions(+), 18 deletions(-) diff --git a/include/configs/s5p_goni.h b/include/configs/s5p_goni.h index 8a824c7..e8f2639 100644 --- a/include/configs/s5p_goni.h +++ b/include/configs/s5p_goni.h @@ -84,9 +84,9 @@ #define CONFIG_CMD_CACHE #define CONFIG_CMD_REGINFO #define CONFIG_CMD_ONENAND -#define CONFIG_CMD_MTDPARTS #define CONFIG_CMD_MMC #define CONFIG_CMD_DFU +#define CONFIG_CMD_GPT /* USB Composite download gadget - g_dnl */ #define CONFIG_USBDOWNLOAD_GADGET @@ -101,26 +101,30 @@ #define CONFIG_BOOTDELAY 1 #define CONFIG_ZERO_BOOTDELAY_CHECK -#define CONFIG_MTD_DEVICE -#define CONFIG_MTD_PARTITIONS - -/* Actual modem binary size is 16MiB. Add 2MiB for bad block handling */ -#define MTDIDS_DEFAULT onenand0=samsung-onenand -#define MTDPARTS_DEFAULT mtdparts=samsung-onenand:1m(bootloader)\ - ,256k(params)\ - ,2816k(config)\ - ,8m(csa)\ - ,7m(kernel)\ - ,1m(log)\ - ,12m(modem)\ - ,60m(qboot)\ - ,-(UBI)\0 - #define CONFIG_DFU_ALT \ u-boot mmc 80 400; \ uImage fat 0 2\0 \ -#define NORMAL_MTDPARTS_DEFAULT MTDPARTS_DEFAULT +/* partitions definitions */ +#define PARTS_CSA csa-mmc +#define PARTS_BOOTLOADER u-boot +#define PARTS_BOOT boot +#define PARTS_ROOT platform +#define PARTS_DATA data +#define PARTS_CSC csc +#define PARTS_UMS ums + +#define PARTS_DEFAULT \ + uuid_disk=${uuid_gpt_disk}; \ + name=PARTS_CSA,size=8MiB,uuid=${uuid_gpt_PARTS_CSA}; \ + name=PARTS_BOOTLOADER,size=60MiB, \ + uuid=${uuid_gpt_PARTS_BOOTLOADER}; \ + name=PARTS_BOOT,size=100MiB,uuid=${uuid_gpt_PARTS_BOOT}; \ + name=PARTS_ROOT,size=1GiB,uuid=${uuid_gpt_PARTS_ROOT}; \ + name=PARTS_DATA,size=3GiB,uuid=${uuid_gpt_PARTS_DATA}; \ + name=PARTS_CSC,size=150MiB,uuid=${uuid_gpt_PARTS_CSC}; \ + name=PARTS_UMS,size=-,uuid=${uuid_gpt_PARTS_UMS}\0 \ + #define CONFIG_BOOTCOMMAND run mmcboot @@ -180,12 +184,12 @@ verify=n\0 \ rootfstype=ext4\0 \ console= CONFIG_DEFAULT_CONSOLE \ - mtdparts= MTDPARTS_DEFAULT \ meminfo=mem=80M mem=256M@0x4000 mem=128M@0x5000\0 \ loaduimage=fatload mmc ${mmcdev}:${mmcbootpart} 0x30007FC0 uImage\0 \ mmcdev=0\0 \ mmcbootpart=2\0 \ mmcrootpart=5\0 \ + partitions= PARTS_DEFAULT \ mmcblk=/dev/mmcblk1p1\0 \ bootblock=9\0 \ ubiblock=8\0 \ @@ -237,6 +241,10 @@ #define CONFIG_CMD_FAT #define CONFIG_FAT_WRITE +/* GPT */ +#define CONFIG_EFI_PARTITION +#define CONFIG_PARTITION_UUIDS + #define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_LOAD_ADDR - 0x100) #define CONFIG_SYS_CACHELINE_SIZE 64 -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] arm:goni: Add support for USB mass storage
From: Arkadiusz Wlodarczyk a.wlodarc...@samsung.com Signed-off-by: Arkadiusz Wlodarczyk a.wlodarc...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Tested-by: Arkadiusz Wlodarczyk a.wlodarc...@samsung.com Cc: Minkyu Kang mk7.k...@samsung.com --- Changes Switch on USB gadget mass storage and ums command in configuration for goni target; Add code supporting USB gadget mass storage in board/samsung/goni/goni.c --- Depends on implementation of USB mass storage for Samsung. http://patchwork.ozlabs.org/patch/219744/ http://patchwork.ozlabs.org/patch/219746/ http://patchwork.ozlabs.org/patch/219745/ --- board/samsung/goni/goni.c | 68 include/configs/s5p_goni.h |5 +++ 2 files changed, 73 insertions(+), 0 deletions(-) diff --git a/board/samsung/goni/goni.c b/board/samsung/goni/goni.c index 3c53106..a09daca 100644 --- a/board/samsung/goni/goni.c +++ b/board/samsung/goni/goni.c @@ -29,6 +29,7 @@ #include usb/s3c_udc.h #include asm/arch/cpu.h #include power/max8998_pmic.h +#include usb_mass_storage.h DECLARE_GLOBAL_DATA_PTR; static struct s5pc110_gpio *s5pc110_gpio; @@ -163,3 +164,70 @@ void board_usb_init(void) } #endif + +#ifdef CONFIG_USB_GADGET_MASS_STORAGE +static int ums_read_sector(struct ums_device *ums_dev, + ulong start, lbaint_t blkcnt, void *buf) +{ + if (ums_dev-mmc-block_dev.block_read(ums_dev-dev_num, + start + ums_dev-offset, blkcnt, buf) != blkcnt) + return -1; + + return 0; +} + +static int ums_write_sector(struct ums_device *ums_dev, + ulong start, lbaint_t blkcnt, const void *buf) +{ + if (ums_dev-mmc-block_dev.block_write(ums_dev-dev_num, + start + ums_dev-offset, blkcnt, buf) != blkcnt) + return -1; + + return 0; +} + +static void ums_get_capacity(struct ums_device *ums_dev, + long long int *capacity) +{ + long long int tmp_capacity; + + tmp_capacity = (long long int) ((ums_dev-offset + ums_dev-part_size) + * SECTOR_SIZE); + *capacity = ums_dev-mmc-capacity - tmp_capacity; +} + +static struct ums_board_info ums_board = { + .read_sector = ums_read_sector, + .write_sector = ums_write_sector, + .get_capacity = ums_get_capacity, + .name = GONI UMS disk, + .ums_dev = { + .mmc = NULL, + .dev_num = 0, + .offset = 0, + .part_size = 0. + }, +}; + +struct ums_board_info *board_ums_init(unsigned int dev_num, unsigned int offset, + unsigned int part_size) +{ + struct mmc *mmc; + + mmc = find_mmc_device(dev_num); + /* mmc initialization is necessary prior to the ums command usage +* due to fact that on goni target environment is read from oneNand +* memory, so the mmc remains uninitialized whenu-boot prompt appears +* */ + if (!mmc || mmc_init(mmc)) + return NULL; + + ums_board.ums_dev.mmc = mmc; + ums_board.ums_dev.dev_num = dev_num; + ums_board.ums_dev.offset = offset; + ums_board.ums_dev.part_size = part_size; + + return ums_board; +} + +#endif diff --git a/include/configs/s5p_goni.h b/include/configs/s5p_goni.h index e8f2639..1cfbb88 100644 --- a/include/configs/s5p_goni.h +++ b/include/configs/s5p_goni.h @@ -269,4 +269,9 @@ #define CONFIG_USB_GADGET_DUALSPEED #define CONFIG_USB_GADGET_VBUS_DRAW 2 +#define CONFIG_CMD_USB_MASS_STORAGE +#if defined(CONFIG_CMD_USB_MASS_STORAGE) +#define CONFIG_USB_GADGET_MASS_STORAGE +#endif + #endif /* __CONFIG_H */ -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] Allow AM33xx boards to setup GPMC chipselects.
Mark == Mark Jackson mpfj-l...@mimc.co.uk writes: Mark Expose the enable_gpmc_cs_config() function so AM33xx based boards can register GPMC chip selects. Mark Changes in V3: Mark - Fix line wrapping Mark Changes in V2: Mark - Indicate this is for AM33xx (not OMAP2) Mark Signed-off-by: Mark Jackson m...@newflow.co.uk Mark --- Mark arch/arm/include/asm/arch-am33xx/sys_proto.h |2 ++ Mark 1 file changed, 2 insertions(+) Mark diff --git a/arch/arm/include/asm/arch-am33xx/sys_proto.h b/arch/arm/include/asm/arch-am33xx/sys_proto.h Mark index 588d8de..97ab60d 100644 Mark --- a/arch/arm/include/asm/arch-am33xx/sys_proto.h Mark +++ b/arch/arm/include/asm/arch-am33xx/sys_proto.h Mark @@ -35,5 +35,7 @@ void ddr_pll_config(unsigned int ddrpll_M); Mark void sdelay(unsigned long); Mark void gpmc_init(void); Mark +void enable_gpmc_cs_config(const u32 *gpmc_config, struct gpmc_cs *cs, u32 base, Mark +u32 size); Checkpatch still complains. How about wrapping after *cs, and properly aligning the next line? -- Bye, Peter Korsgaard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4] Allow AM33xx boards to setup GPMC chipselects.
Expose the enable_gpmc_cs_config() function so AM33xx based boards can register GPMC chip selects. Changes in V4: - Fix checkpatch errors (TAB - space mangling) Changes in V3: - Fix line wrapping Changes in V2: - Indicate this is for AM33xx (not OMAP2) Signed-off-by: Mark Jackson m...@newflow.co.uk --- arch/arm/include/asm/arch-am33xx/sys_proto.h |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/include/asm/arch-am33xx/sys_proto.h b/arch/arm/include/asm/arch-am33xx/sys_proto.h index 588d8de..97ab60d 100644 --- a/arch/arm/include/asm/arch-am33xx/sys_proto.h +++ b/arch/arm/include/asm/arch-am33xx/sys_proto.h @@ -35,5 +35,7 @@ void ddr_pll_config(unsigned int ddrpll_M); void sdelay(unsigned long); void gpmc_init(void); +void enable_gpmc_cs_config(const u32 *gpmc_config, struct gpmc_cs *cs, u32 base, + u32 size); void omap_nand_switch_ecc(int); #endif -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] Allow AM33xx boards to setup GPMC chipselects.
On 18/02/13 11:01, Peter Korsgaard wrote: Mark == Mark Jackson mpfj-l...@mimc.co.uk writes: Mark Expose the enable_gpmc_cs_config() function so AM33xx based boards can register GPMC chip selects. Mark Changes in V3: Mark - Fix line wrapping Mark Changes in V2: Mark - Indicate this is for AM33xx (not OMAP2) Mark Signed-off-by: Mark Jackson m...@newflow.co.uk Mark --- Mark arch/arm/include/asm/arch-am33xx/sys_proto.h |2 ++ Mark 1 file changed, 2 insertions(+) Mark diff --git a/arch/arm/include/asm/arch-am33xx/sys_proto.h b/arch/arm/include/asm/arch-am33xx/sys_proto.h Mark index 588d8de..97ab60d 100644 Mark --- a/arch/arm/include/asm/arch-am33xx/sys_proto.h Mark +++ b/arch/arm/include/asm/arch-am33xx/sys_proto.h Mark @@ -35,5 +35,7 @@ void ddr_pll_config(unsigned int ddrpll_M); Mark void sdelay(unsigned long); Mark void gpmc_init(void); Mark +void enable_gpmc_cs_config(const u32 *gpmc_config, struct gpmc_cs *cs, u32 base, Mark +u32 size); Checkpatch still complains. How about wrapping after *cs, and properly aligning the next line? G ... stupid mailer programs !! Hopefully v4 is now correct ... Mark J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 16/20] Roll crc32 into hash infrastructure
Dear Tom, In message 51216721.1010...@ti.com you wrote: There's another thread I don't have yet (and I don't have this one in gmail yet even). But, I am OK with custodians using their repos, but not the master branch, for unrelated but otherwise good patches. I'm also fine with patchwork bundles. I suppose we could use the staging repository for these changes instead. What I mostly object about there is that these patches would go into mainline basicly unreviewed, as patch submission and pull request is all done from a single person, with no other feedback on the patches at all. And this affects a lot of common code... Actually, I see this change when pulling u-boot-x86.git/master: - bloat-o-meter u-boot-before u-boot add/remove: 9/0 grow/shrink: 3/14 up/down: 1006/-560 (446) function old new delta hash_command - 424+424 strncasecmp- 156+156 simple_itoa- 104+104 crc32_wd_buf - 76 +76 setenv_hex - 68 +68 setenv_ulong - 52 +52 strcasecmp - 36 +36 do_mem_loopw 304 328 +24 static.local - 22 +22 do_mem_loop 268 288 +20 hash_algo - 16 +16 do_mem_cmp 332 340 +8 do_mem_mw224 220 -4 set_working_fdt_addr 72 52 -20 load_serial_ymodem 300 280 -20 load_serial 512 492 -20 index_partitions 200 180 -20 do_load_serial_bin 18441824 -20 do_load 468 448 -20 do_jffs2_fsload 320 300 -20 do_imgextract636 592 -44 NetLoop 832 788 -44 do_mem_cp312 252 -60 do_bootm12441180 -64 do_mem_crc 188 88-100 do_mem_mtest14361332-104 So there are changes all over the place, including a growth of the memory footprint. I think this needs at least minimal review. 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: w...@denx.de Time is an illusion perpetrated by the manufacturers of space. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] Allow AM33xx boards to setup GPMC chipselects.
Mark == Mark Jackson mpfj-l...@mimc.co.uk writes: Mark Expose the enable_gpmc_cs_config() function so AM33xx based boards can register GPMC chip selects. Acked-by: Peter Korsgaard jac...@sunsite.dk -- Bye, Peter Korsgaard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4 V3] EXYNOS5: Add gpio pin numbering feature
Hi Simon, Thank you for comments. On Sun, Feb 17, 2013 at 11:51 AM, Simon Glass s...@chromium.org wrote: Hi Rajeshwari, On Thu, Feb 7, 2013 at 4:00 AM, Rajeshwari Shinde rajeshwar...@samsung.com wrote: This patch adds support for gpio pin numbering support on EXYNOS5 pinmux. Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com If we are going to have GPIO numbering it needs to be continuous. The scheme in the Chrome OS tree does this. -Okay It's great to have gpio_cfg_pin() but I can't see the actual definition. The definition for same is in S5P: GPIO: Add generic pin numbering API's patch of same patch set. Also please carefully check that the GPIO numbers are all correct - it doesn't look right to me. I had verified for each value. Will recheck the same. Also for the benefit of people using FDT who still don't have symbols and who don't yet have proper GPIO support in U-Boot (phandle to bank + number within bank, as in the kernel), can you please annotate the first enum value of each GPIO group (A, B, C) with its hex value? That will also provide a check that things are correct. So you want me to assign each bank GPIO group with its Base adress in hex? One more doubt as per Minkyu comment to support the same for EXYNOS4 and avoid error do we have to append EXYNOS5_ at the start of enum values? Or anyother solution you would suggest? Regards, Simon --- Changes in V2: - none. Changes in V3: - none. arch/arm/cpu/armv7/exynos/pinmux.c | 148 + arch/arm/include/asm/arch-exynos/gpio.h | 360 ++- 2 files changed, 413 insertions(+), 95 deletions(-) diff --git a/arch/arm/cpu/armv7/exynos/pinmux.c b/arch/arm/cpu/armv7/exynos/pinmux.c index bd499b4..c79d58e 100644 --- a/arch/arm/cpu/armv7/exynos/pinmux.c +++ b/arch/arm/cpu/armv7/exynos/pinmux.c @@ -29,89 +29,77 @@ static void exynos5_uart_config(int peripheral) { - struct exynos5_gpio_part1 *gpio1 = - (struct exynos5_gpio_part1 *) samsung_get_base_gpio_part1(); - struct s5p_gpio_bank *bank; int i, start, count; switch (peripheral) { case PERIPH_ID_UART0: - bank = gpio1-a0; - start = 0; + start = GPIO_A00; count = 4; break; case PERIPH_ID_UART1: - bank = gpio1-d0; - start = 0; + start = GPIO_D00; count = 4; break; case PERIPH_ID_UART2: - bank = gpio1-a1; - start = 0; + start = GPIO_A10; count = 4; break; case PERIPH_ID_UART3: - bank = gpio1-a1; - start = 4; + start = GPIO_A14; count = 2; break; } for (i = start; i start + count; i++) { - s5p_gpio_set_pull(bank, i, GPIO_PULL_NONE); - s5p_gpio_cfg_pin(bank, i, GPIO_FUNC(0x2)); + gpio_set_pull(i, GPIO_PULL_NONE); + gpio_cfg_pin(i, GPIO_FUNC(0x2)); } } static int exynos5_mmc_config(int peripheral, int flags) { - struct exynos5_gpio_part1 *gpio1 = - (struct exynos5_gpio_part1 *) samsung_get_base_gpio_part1(); - struct s5p_gpio_bank *bank, *bank_ext; - int i, start = 0, gpio_func = 0; + int i, start, start_ext, gpio_func = 0; switch (peripheral) { case PERIPH_ID_SDMMC0: - bank = gpio1-c0; - bank_ext = gpio1-c1; - start = 0; + start = GPIO_C00; + start_ext = GPIO_C10; gpio_func = GPIO_FUNC(0x2); break; case PERIPH_ID_SDMMC1: - bank = gpio1-c2; - bank_ext = NULL; + start = GPIO_C20; + start_ext = 0; break; case PERIPH_ID_SDMMC2: - bank = gpio1-c3; - bank_ext = gpio1-c4; - start = 3; + start = GPIO_C30; + start_ext = GPIO_C43; gpio_func = GPIO_FUNC(0x3); break; case PERIPH_ID_SDMMC3: - bank = gpio1-c4; - bank_ext = NULL; + start = GPIO_C40; + start_ext = 0; break; } - if ((flags PINMUX_FLAG_8BIT_MODE) !bank_ext) { + if ((flags PINMUX_FLAG_8BIT_MODE) !start_ext) { debug(SDMMC device %d does not support 8bit mode, peripheral); return -1; } if (flags PINMUX_FLAG_8BIT_MODE) { - for (i = start; i = (start + 3); i++) { - s5p_gpio_cfg_pin(bank_ext, i, gpio_func); -
Re: [U-Boot] [PATCH v7 16/19] arm926ejs: Remove deprecated and now unused NAND SPL
On Sunday, February 17, 2013 5:25:33 PM, Benoît Thébaudeau wrote: On Sunday, February 17, 2013 5:08:00 PM, Albert ARIBAUD wrote: Hi Albert, On Sun, 17 Feb 2013 17:04:54 +0100, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi Benoît, On Sun, 17 Feb 2013 16:51:37 +0100 (CET), Benoît Thébaudeau benoit.thebaud...@advansee.com wrote: Hi Albert, Tom, Zhong, On Friday, February 15, 2013 9:54:22 PM, Benoît Thébaudeau wrote: Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com --- Changes in v7: None Changes in v6: - New patch. Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: None arch/arm/cpu/arm926ejs/start.S | 10 -- 1 file changed, 10 deletions(-) I would like to get your feedback regarding the status of the Samsung SMDK6400 board: - It is not in boards.cfg, so, according to commit 1285a28, support for it should already have been removed a long time ago. It also seems to be the only board remaining in the main Makefile. - It uses the deprecated NAND SPL. - MAKEALL does not test its build, which has been broken for a while. - If it were removed or fixed, ARM1176's start.S' relocate_code() could be made identical to all the other implementations of this function, so all this duplicated code could be moved to a common location like crt0.S. Besides that, it would be possible to completely get rid of the legacy NAND SPL on ARM. I have no intention of fixing this board, but dropping it and cleaning up ARM after that would be easy. Cc:ing the board maintainers, as they should be the first ones to be asked whether they intend to bring the board into boards.cfg and fix it, or whether it should be dropped. Scratch this: correct maintainer CC:ed now Yes, I had already Cc'ed Zhong. Adding Mike to Cc as he had been assigned the board migration job to boards.cfg, due for v2012.03. Perhaps he got some information from the SMDK6400 maintainer. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 13/19] Makefile: u-boot-with-spl.bin: Fix SPL padding
On Sunday, February 17, 2013 5:16:49 PM, Benoît Thébaudeau wrote: Hi Poonam, Andy, On Friday, February 15, 2013 9:54:19 PM, Benoît Thébaudeau wrote: PAD_TO is not a generic SPL configuration option, so use CONFIG_SPL_MAX_SIZE instead. We want to use --pad-to with a size, but this option expects an address, so use u-boot-spl.bin instead of u-boot-spl as the input file in order to get addresses starting at 0. Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com --- Changes in v7: - Use u-boot-spl.bin instead of u-boot-spl in order to avoid having to use --change-addresses. Changes in v6: - Fix size passed to --pad-to thanks to --change-addresses. Changes in v5: None Changes in v4: - New patch. Changes in v3: None Changes in v2: None Makefile |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index a8c7b7b..317dffc 100644 --- a/Makefile +++ b/Makefile @@ -486,7 +486,8 @@ $(obj)u-boot.dis: $(obj)u-boot $(OBJDUMP) -d $ $@ $(obj)u-boot-with-spl.bin: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin - $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(PAD_TO) -O binary $(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin + $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(CONFIG_SPL_MAX_SIZE) \ + -I binary -O binary $ $(obj)spl/u-boot-spl-pad.bin cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin $@ rm $(obj)spl/u-boot-spl-pad.bin I would like to let you know what is going on, and to get your feedback for this patch. include/configs/p1_p2_rdb_pc.h seems to be the only current user of u-boot-with-spl.bin, triggered for example by the P2020RDB-PC_NAND config. Before this patch, PAD_TO was used, but there is no such definition for this board for generic SPL, so this board seems broken, all the more none of the various values defined for CONFIG_SYS_TEXT_BASE relatively to CONFIG_SPL_TEXT_BASE would be compatible with an image built by appending U-Boot to the generic SPL. Can you confirm? This patch won't fix this board, but I want to make sure that it won't be an issue for you now or later. I'm also wondering why there is both generic SPL for NAND and legacy NAND SPL for p1_p2_rdb, all the more the NAND SPL version does not seem to be used in boards.cfg. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] How to generate an interrupt from u-boot
Hi, Iam working on the samsung smdkv310 based soc. I want to generate an interrupt from the timer. Is it possible to service an interrupts at u-boot level. Smdkv310 board is having the GIC controller. Is there any patches to initialise the GIC(Generic interrupt controller). Please do needful. Thanks balaji ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 9/9] dfu: Support larger than memory transfers.
Dear Lukasz Majewski, Hi Tom, On Fri, Nov 30, 2012 at 08:01:12PM +0200, Pantelis Antoniou wrote: We didn't support upload/download larger than available memory. This is pretty bad when you have to update your root filesystem for example. This patch removes the limitation (and the crashes when you transfered any file larger than 4MB). On top of that reduces the huge dfu buffer from 4MB to just 64K, which was over the top. The sequence number is a 16 bit counter; make sure we handle rollover correctly. This fixes the wrong transfers for large ( 256MB) images. Also utilize a variable to handle initialization, so that we don't rely on just the counter sent by the host. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com To be clear, patches 1-8 are good and we should take, but this one means we can't use FAT/EXT* partitions without more work. I would suggest that we set this part aside for a moment and perhaps limit transfers that are larget than RAM to RAW only where we can write in chunks today. As fair as I remember, some additional work needs to be done with composite.c file (to remove nasty #ifdefs). There was a problem with newer version of dfu-utils (new handling of descriptors). It is on top of my queue, but I'm currently buried with other work and need to postpone this. However it is still on the back of my head and I push myself to fix this. Guys, can you just tell me what I should drop from u-boot-usb to submit a pullRQ with the rest ? Otherwise I'll drop the whole DFU stuff and be done with it. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Notes from the U-Boot BOF Meeting in Geneva 2012/07/12
Dear Graeme Russ, Hi Wolfgang, On Mon, Feb 18, 2013 at 8:59 PM, Wolfgang Denk w...@denx.de wrote: Dear Simon, In message CAPnjgZ089gS0gLHBVBVARpX=awcyRUUmSLGNiR4HFkwZZLsL- g...@mail.gmail.com you wrote: I have started on it - I've ported over the Kbuild infrastructure into a dedicated 'kbuild' makefile which is called from the main makefile. This make modifications to the existing makefile very minimal Now it's just a case of building all the Kconfig files which is, to say the least, a massive task. I have a lot of other things going on, so unfortunately progress is slow I wonder how you got on with that? Any work-in-progress that could be used as a base? Want some help? It seems like a useful feature. I also wonder if this has to be a one-step change-it-all-at-once operation? Maybe we can add the infrastructure in a neutral way, and then start moving code to the Kconfig files step by step - similar to what we did with moving Makefile rules out into boards.cfg ? Alas I do not have access to the code I was working on (study is buried in stuff) and I really didn't get that far anyway. But, I got as far as knowing it is possible to run both the current Makefile infrastructure and the KConfig infrastructure in parallel. The trick is to create additional Makefiles (Makefile.kc for example). You just need to add stubs for the KConfig targets (menuconfig, xconfig, etc). Once the core KConfig Make infrastructure is in place, it's simply (?) a case of building all the KConfig files True, we can add Kconfig first and Kbuild afterwards. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] SMDK5250: FDT: Retrieve board model via DT
Print out the board model by parsing the device tree file. Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com --- board/samsung/smdk5250/smdk5250.c | 11 ++- 1 files changed, 10 insertions(+), 1 deletions(-) diff --git a/board/samsung/smdk5250/smdk5250.c b/board/samsung/smdk5250/smdk5250.c index 6f6f2c2..0097b3f 100644 --- a/board/samsung/smdk5250/smdk5250.c +++ b/board/samsung/smdk5250/smdk5250.c @@ -336,8 +336,17 @@ int board_eth_init(bd_t *bis) #ifdef CONFIG_DISPLAY_BOARDINFO int checkboard(void) { - printf(\nBoard: SMDK5250\n); +#ifdef CONFIG_OF_CONTROL + const char *board_name; + board_name = fdt_getprop(gd-fdt_blob, 0, model, NULL); + if (board_name == NULL) + printf(\nUnknown Board\n); + else + printf(\nBoard: %s\n, board_name); +#else + printf(\nBoard: SMDK5250\n); +#endif return 0; } #endif -- 1.7.4.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 9/9] dfu: Support larger than memory transfers.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/18/2013 05:01 AM, Lukasz Majewski wrote: Hi Tom, On Fri, Nov 30, 2012 at 08:01:12PM +0200, Pantelis Antoniou wrote: We didn't support upload/download larger than available memory. This is pretty bad when you have to update your root filesystem for example. This patch removes the limitation (and the crashes when you transfered any file larger than 4MB). On top of that reduces the huge dfu buffer from 4MB to just 64K, which was over the top. The sequence number is a 16 bit counter; make sure we handle rollover correctly. This fixes the wrong transfers for large ( 256MB) images. Also utilize a variable to handle initialization, so that we don't rely on just the counter sent by the host. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com To be clear, patches 1-8 are good and we should take, but this one means we can't use FAT/EXT* partitions without more work. I would suggest that we set this part aside for a moment and perhaps limit transfers that are larget than RAM to RAW only where we can write in chunks today. As fair as I remember, some additional work needs to be done with composite.c file (to remove nasty #ifdefs). There was a problem with newer version of dfu-utils (new handling of descriptors). I thought it ended up being resolved. I'll have to re-read the thread again I guess. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRIjHWAAoJENk4IS6UOR1WEs0P/07uTOJRh+8hBgnpcXwBZ8zD keEtN8vHs3JYOjW1k6styAFNGXy+PBhOJNOIx6ClsdTvCRU8FtGh09SZUAYBrZEj 5WbfqGaeFWY9bpgAhwsNRMXD3mcHq3EGvRm0Ga+ep/EDFd+lgswvfx9EtgxkOjy5 MM0G4BnjwJxWM4DW2Wkk/rXI7Xy8jpVn3abUPLva4iY8X5L6ez9GXp/VNv6nCoNI i+LuGXEnv7BsO9g+x5pvYlnQeMC5BPC7vKNMq9dj8o6MZ/Q7jCQkqz85GIqyDTta UByzr24G4xK5m7V0iFSlV7fnRHjcg7q+uAB6u2YSibssyibIuLoJA2VdiGZqp8oH OUBQ3L2v84QHhcKTQm/yqcQ4FWHaHQ369v4QwnON29yFqtb7Z/M3GEKCqPbPIlge eg+Bb8fymdjELQT4Bo0+EkydlvaQOhkSjxBlVa9GTkRyoPxpE7RNY5lgciseVZO4 hKG/Xfnce7fpQNoE8fJCWRslQp3sOiDE65gFRzNJN/15i+my+xYmN5HiNPWhcgmI 2EVJGx9/LXqZ6yGZh8bQCC3yvNnshG+cm4qAj58ytkLjVSVnsd7yxFYbexUTEJ0q YwOmE/72cgL/3IzpRUmh4o5G+uFJqhFx7zndMQyItdTN09mhZu7dCUtgud66A1Qg wUiQkeF4sWubUMIpYUvz =L9X2 -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] i.MX6: Add DDR controller registers
Thanks for the review Jason, On 02/17/2013 10:16 PM, Liu Hui-R64343 wrote: -Original Message- From: Eric Nelson [mailto:eric.nel...@boundarydevices.com] Sent: Monday, February 18, 2013 3:24 AM To: u-boot@lists.denx.de Cc: sba...@denx.de; Liu Hui-R64343; Estevam Fabio-R49496; troy.ki...@boundarydevices.com; Eric Nelson Subject: [PATCH 6/6] i.MX6: Add DDR controller registers Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com --- arch/arm/include/asm/arch-mx6/mx6-ddr.h | 85 + arch/arm/include/asm/arch-mx6/mx6dl-ddr.h | 71 arch/arm/include/asm/arch-mx6/mx6q-ddr.h | 69 +++ 3 files changed, 225 insertions(+) create mode 100644 arch/arm/include/asm/arch-mx6/mx6-ddr.h create mode 100644 arch/arm/include/asm/arch-mx6/mx6dl-ddr.h create mode 100644 arch/arm/include/asm/arch-mx6/mx6q-ddr.h I did not see any user of these files, what the purpose of this? These will be used in the memory configuration for nitrogen6x, that will build for dual/quad or dual-lite/solo as discussed here: http://lists.denx.de/pipermail/u-boot/2013-January/145562.html I'm holding that off waiting for commentary on these to avoid thrashing. diff --git a/arch/arm/include/asm/arch-mx6/mx6-ddr.h b/arch/arm/include/asm/arch-mx6/mx6-ddr.h new file mode 100644 index 000..4d18ede --- /dev/null +++ b/arch/arm/include/asm/arch-mx6/mx6-ddr.h @@ -0,0 +1,85 @@ +/* + * Copyright (C) 2012 Boundary Devices Inc. Either 2013 or 2012 - 2013? Can you tell this patch has been lingering? + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + + * You should have received a copy of the GNU General Public License +along + * with this program; if not, write to the Free Software Foundation, +Inc., + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. + */ +#ifndef __ASM_ARCH_MX6_DDR_H__ +#define __ASM_ARCH_MX6_DDR_H__ + +#ifdef CONFIG_MX6Q +#include mx6q-ddr.h +#else +#if defined(CONFIG_MX6DL) || defined(CONFIG_MX6S) #include +mx6dl-ddr.h +#else +#error Please select cpu +#endif /* CONFIG_MX6DL or CONFIG_MX6S */ +#endif /* CONFIG_MX6Q */ + +#define MMDC_P0_MDCTL 0x021b I also prefer to add MX6_ prefix, Will fix in V2 along with your Ditto comments. ... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/6] i.MX6: consolidate pad names for multi-CPU boards
Thanks again Jason, On 02/17/2013 10:31 PM, Liu Hui-R64343 wrote: -Original Message- From: Eric Nelson [mailto:eric.nel...@boundarydevices.com] Sent: Monday, February 18, 2013 3:24 AM To: u-boot@lists.denx.de Cc: sba...@denx.de; Liu Hui-R64343; Estevam Fabio-R49496; troy.ki...@boundarydevices.com; Eric Nelson Subject: [PATCH 2/6] i.MX6: consolidate pad names for multi-CPU boards Rename all i.MX6 pad declarations to MX6_PAD_x, so a board may support either i.MX6Quad/Dual (MX6Q) or i.MX6Dual-Lite/Solo (MX6DL) by including the proper header. Boards mx6qarm2, mx6qsabreauto, mx6qsabrelite, and mx6qsabresd only support MX6Q, so they include mx6q_pins.h. Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com --- arch/arm/include/asm/arch-mx6/mx6-pins.h | 31 + arch/arm/include/asm/arch-mx6/mx6dl_pins.h| 190 +-- arch/arm/include/asm/arch-mx6/mx6q_pins.h | 1671 + arch/arm/include/asm/arch-mx6/mx6x_pins.h | 1671 - board/freescale/mx6qarm2/mx6qarm2.c | 78 +- board/freescale/mx6qsabreauto/mx6qsabreauto.c | 60 +- board/freescale/mx6qsabrelite/mx6qsabrelite.c | 190 +-- board/freescale/mx6qsabresd/mx6qsabresd.c | 102 +- 8 files changed, 2012 insertions(+), 1981 deletions(-) create mode 100644 arch/arm/include/asm/arch-mx6/mx6-pins.h create mode 100644 arch/arm/include/asm/arch-mx6/mx6q_pins.h delete mode 100644 arch/arm/include/asm/arch-mx6/mx6x_pins.h diff --git a/arch/arm/include/asm/arch-mx6/mx6-pins.h b/arch/arm/include/asm/arch-mx6/mx6-pins.h new file mode 100644 index 000..4011268 --- /dev/null +++ b/arch/arm/include/asm/arch-mx6/mx6-pins.h @@ -0,0 +1,31 @@ +/* + * Copyright (C) 2012 Boundary Devices Inc. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + + * You should have received a copy of the GNU General Public License along + * with this program; if not, write to the Free Software Foundation, Inc., + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. + */ +#ifndef __ASM_ARCH_MX6_PINS_H__ +#define __ASM_ARCH_MX6_PINS_H__ + +#ifdef CONFIG_MX6Q +#include mx6q_pins.h +#else +#if defined(CONFIG_MX6DL) || defined(CONFIG_MX6S) +#include mx6dl_pins.h +#else +#error Please select cpu +#endif /* CONFIG_MX6DL or CONFIG_MX6S */ +#endif /* CONFIG_MX6Q */ + +#endif /*__ASM_ARCH_MX6_PINS_H__ */ diff --git a/arch/arm/include/asm/arch-mx6/mx6dl_pins.h b/arch/arm/include/asm/arch-mx6/mx6dl_pins.h index 79e2c4f..0395357 100644 --- a/arch/arm/include/asm/arch-mx6/mx6dl_pins.h +++ b/arch/arm/include/asm/arch-mx6/mx6dl_pins.h @@ -50,100 +50,100 @@ #define NO_MUX_I0 #define NO_PAD_I0 enum { - MX6DL_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK = IOMUX_PAD(0x03B0, 0x009C, 0, 0x, 0, PAD_CTL_DSE_120ohm), - MX6DL_PAD_DI0_PIN15__IPU1_DI0_PIN15 = IOMUX_PAD(0x03B4, 0x00A0, 0, 0x, 0, PAD_CTL_DSE_120ohm), - MX6DL_PAD_DI0_PIN2__IPU1_DI0_PIN2 = IOMUX_PAD(0x03B8, 0x00A4, 0, 0x, 0, PAD_CTL_DSE_120ohm), - MX6DL_PAD_DI0_PIN3__IPU1_DI0_PIN3 = IOMUX_PAD(0x03BC, 0x00A8, 0, 0x, 0, PAD_CTL_DSE_120ohm), - MX6DL_PAD_DI0_PIN4__GPIO_4_20 = IOMUX_PAD(0x03C0, 0x00AC, 5, 0x, 0, PAD_CTL_DSE_120ohm), [...] diff --git a/board/freescale/mx6qarm2/mx6qarm2.c b/board/freescale/mx6qarm2/mx6qarm2.c index ee20d4f..ff7f5e8 100644 --- a/board/freescale/mx6qarm2/mx6qarm2.c +++ b/board/freescale/mx6qarm2/mx6qarm2.c @@ -23,7 +23,7 @@ #include common.h #include asm/io.h #include asm/arch/imx-regs.h -#include asm/arch/mx6x_pins.h +#include asm/arch/mx6q_pins.h Since you have defined mx6-pins.h, why not just include the mx6-pins.h? If not using mx6-pins.h, then what's the purpose of it? I kept mx6q_pins.h for existing boards that included dual-quad support, since the only builds are for that platform. If these boards support Dual-Lite/Solo, they'll need an additional board file with the proper declarations. I have no idea whether that's planned. Regards, Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] AM335x : failure to boot SPL from NAND
On 15/02/13 21:13, Tom Rini wrote: On Thu, Feb 14, 2013 at 03:54:23PM +, Mark Jackson wrote: I'm trying to diagnose why our AM335x based CPU board (based on the AM335x Starter Kit) can boot SPL and U-Boot from an MMC card, but is unable to boot from NAND (connected to CS0). Following the TI wiki (http://processors.wiki.ti.com/index.php/AM335x_U-Boot_User%27s_Guide#Flashing_images_to_NAND_in_SD_boot) I:- (1) boot from MMC (2) erase the nand (3) copy MLO from MMC into NAND (4) verified it copied correctly (using crc32) When I reboot the board in NAND mode, I get nothing on UART0. If I reboot in MMC mode, SPL and U-Boot load correctly. Can anyone give me some pointers on the boot sequence, and where I might look to help debug the problem ? Assuming you're using mainline U-Boot and can rule out vendor problems, if you can access the SYSBOOT pins, set it up for a mode that does NAND and UART. If you never see the 'CCC' on console (or only see it the first time if you do UART then NAND), then you are starting SPL and dying in there. If you just see a stream of C then your file is not written to NAND correctly. Interesting ... I don't get any 'CCC' on the console. However, I then tested this by booting via MMC, erasing the NAND chip and then trying to reboot via NAND again. I still get no 'CCC' on the console !?! This is using boot mode 10011 (NAND, NANDI2C, MMC0, UART0), so I would expect to either boot via MMC (if I left it in) or get some 'CCC' output on the console. I can see that the NAND signals always have a burst of activity every 10ms. That must be a timeout of some sort ... do you know if that's a hardware or software timeout ? Mark J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] AM335x : failure to boot SPL from NAND
On Mon, Feb 18, 2013 at 02:43:47PM +, Mark Jackson wrote: On 15/02/13 21:13, Tom Rini wrote: On Thu, Feb 14, 2013 at 03:54:23PM +, Mark Jackson wrote: I'm trying to diagnose why our AM335x based CPU board (based on the AM335x Starter Kit) can boot SPL and U-Boot from an MMC card, but is unable to boot from NAND (connected to CS0). Following the TI wiki (http://processors.wiki.ti.com/index.php/AM335x_U-Boot_User%27s_Guide#Flashing_images_to_NAND_in_SD_boot) I:- (1) boot from MMC (2) erase the nand (3) copy MLO from MMC into NAND (4) verified it copied correctly (using crc32) When I reboot the board in NAND mode, I get nothing on UART0. If I reboot in MMC mode, SPL and U-Boot load correctly. Can anyone give me some pointers on the boot sequence, and where I might look to help debug the problem ? Assuming you're using mainline U-Boot and can rule out vendor problems, if you can access the SYSBOOT pins, set it up for a mode that does NAND and UART. If you never see the 'CCC' on console (or only see it the first time if you do UART then NAND), then you are starting SPL and dying in there. If you just see a stream of C then your file is not written to NAND correctly. Interesting ... I don't get any 'CCC' on the console. However, I then tested this by booting via MMC, erasing the NAND chip and then trying to reboot via NAND again. I still get no 'CCC' on the console !?! How did you wire the SYSBOOT pins, and which UART is connected to console? If you have UART0 as the one hooked up to console and have SYSBOOT[4:0] as 00100, the order is UART0,XIP (NOR),MMC0,NAND. So you should see '' (UART0 trying to initiate X-Modem), then it will try MMC0 and then NAND.. This is using boot mode 10011 (NAND, NANDI2C, MMC0, UART0), so I would expect to either boot via MMC (if I left it in) or get some 'CCC' output on the console. Correct. If you have an empty NAND and nothing inserted in MMC, it should be an endless cycle of 'C'. I can see that the NAND signals always have a burst of activity every 10ms. That must be a timeout of some sort ... do you know if that's a hardware or software timeout ? Moving beyond what I can easily help with, sorry. Hit up the TI forums at http://e2e.ti.com/ as this is getting a bit off-topic for the U-Boot list as well :) Thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT PULL] Please pull u-boot-nds32/master into your branch
On Mon, Feb 18, 2013 at 03:43:14PM +0800, Macpaul Lin wrote: Hi Tom, Please pull a bug fix for the missing of including header which cause broken on NDS32 (board adp-ag102). Thanks, Macpaul Lin The following changes since commit ea6bd08b7717bf0d3f69ad9f016bf3b03b3eaf16: nds32: Add a basic errno.h (2013-02-18 15:29:07 +0800) are available in the git repository at: git://git.denx.de/u-boot-nds32.git master for you to fetch changes up to ea6bd08b7717bf0d3f69ad9f016bf3b03b3eaf16: nds32: Add a basic errno.h (2013-02-18 15:29:07 +0800) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/10] am33xx: add ti814x specific register definitions
On Sun, Feb 17, 2013 at 09:28:33PM +0100, Peter Korsgaard wrote: Matt == Matt Porter mpor...@ti.com writes: Matt Support the ti814x specific register definitions within Matt arch-am33xx. Matt Signed-off-by: Matt Porter mpor...@ti.com Matt --- Matt arch/arm/cpu/armv7/am33xx/sys_info.c|3 +++ Matt arch/arm/include/asm/arch-am33xx/cpu.h | 11 + Matt arch/arm/include/asm/arch-am33xx/hardware.h | 32 +++ Matt arch/arm/include/asm/arch-am33xx/omap.h |7 ++ Matt arch/arm/include/asm/arch-am33xx/spl.h |5 + Matt 5 files changed, 54 insertions(+), 4 deletions(-) Matt diff --git a/arch/arm/include/asm/arch-am33xx/hardware.h b/arch/arm/include/asm/arch-am33xx/hardware.h Matt index 41ab2c0..786c159 100644 Matt --- a/arch/arm/include/asm/arch-am33xx/hardware.h Matt +++ b/arch/arm/include/asm/arch-am33xx/hardware.h Matt @@ -20,9 +20,14 @@ Matt #define __AM33XX_HARDWARE_H Matt #include asm/arch/omap.h Matt +#include config.h Quite some of the base addresses are similar, but I wonder if it wouldn't be cleaner to simply have a hardware-am33xx.h / hardware-ti814x.h instead of all these ifdef / elif? Since I suspect the things common from ti814x and am33xx are also common to ti816x (which has been left as an exercise to whomever needs that next), I think we can re-structure this into something like that, but keeping the common parts within hardware.h still. Matt /* Control Module Base Address */ Matt +#ifdef CONFIG_AM33XX Matt #define CTRL_BASE 0x44E1 Matt #define CTRL_DEVICE_BASE 0x44E10600 Matt +#elif defined(CONFIG_TI814X) Matt +#define CTRL_BASE 0x4814 Matt +#endif No CTRL_DEVICE_BASE on ti814x? I think this is a side-effect of Matt not supporting the things attached to it (USB in the case of am335x). Matt --- a/arch/arm/include/asm/arch-am33xx/spl.h Matt +++ b/arch/arm/include/asm/arch-am33xx/spl.h Matt @@ -25,8 +25,13 @@ Matt #define BOOT_DEVICE_XIP 2 Matt #define BOOT_DEVICE_NAND 5 Matt +#ifdef CONFIG_AM33XX Matt #define BOOT_DEVICE_MMC1 8 Matt #define BOOT_DEVICE_MMC2 9 /* eMMC or daughter card */ Matt +#elif defined(CONFIG_TI814X) Matt +#define BOOT_DEVICE_MMC1 9 Matt +#define BOOT_DEVICE_MMC2 8 /* ROM only supports 2nd instance */ Argh! Couldn't we just swap the meaning of mmc1/mmc2 or would that be too confusing? IMHO, that will lead to further confusion down the line. I talked with Matt about this before and well, it's funky. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/10] am33xx: add ti814x specific register definitions
Tom == Tom Rini tr...@ti.com writes: Hi, Quite some of the base addresses are similar, but I wonder if it wouldn't be cleaner to simply have a hardware-am33xx.h / hardware-ti814x.h instead of all these ifdef / elif? Tom Since I suspect the things common from ti814x and am33xx are also common Tom to ti816x (which has been left as an exercise to whomever needs that Tom next), I think we can re-structure this into something like that, but Tom keeping the common parts within hardware.h still. FYI, I might very well be that guy as I've recently started work on a ti816x based project. Argh! Couldn't we just swap the meaning of mmc1/mmc2 or would that be too confusing? Tom IMHO, that will lead to further confusion down the line. I talked with Tom Matt about this before and well, it's funky. Ok. -- Bye, Peter Korsgaard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 16/20] Roll crc32 into hash infrastructure
Hi Wolfgang, On Mon, Feb 18, 2013 at 3:35 AM, Wolfgang Denk w...@denx.de wrote: Dear Tom, In message 51216721.1010...@ti.com you wrote: There's another thread I don't have yet (and I don't have this one in gmail yet even). But, I am OK with custodians using their repos, but not the master branch, for unrelated but otherwise good patches. I'm also fine with patchwork bundles. I suppose we could use the staging repository for these changes instead. What I mostly object about there is that these patches would go into mainline basicly unreviewed, as patch submission and pull request is all done from a single person, with no other feedback on the patches at all. And this affects a lot of common code... Fair enough. I suspect a number of people scan the code, but few feel invested enough to formally Ack it. Also, providing a full review of such a series can take quite a bit of time. Against that, I think it is better to get code in and tested than have it sit around until just before the next release. Actually, I see this change when pulling u-boot-x86.git/master: Thanks for looking at it. Some of it is just the code moving around, but I will take a look at why hash_command grows so much, and why the overall size has grown. Clearly I didn't do enough here when I checked the series. One change was trying to unify the verify feature, so perhaps something has gone wrong there. - bloat-o-meter u-boot-before u-boot add/remove: 9/0 grow/shrink: 3/14 up/down: 1006/-560 (446) function old new delta hash_command - 424+424 strncasecmp- 156+156 simple_itoa- 104+104 crc32_wd_buf - 76 +76 setenv_hex - 68 +68 setenv_ulong - 52 +52 strcasecmp - 36 +36 do_mem_loopw 304 328 +24 static.local - 22 +22 do_mem_loop 268 288 +20 hash_algo - 16 +16 do_mem_cmp 332 340 +8 do_mem_mw224 220 -4 set_working_fdt_addr 72 52 -20 load_serial_ymodem 300 280 -20 load_serial 512 492 -20 index_partitions 200 180 -20 do_load_serial_bin 18441824 -20 do_load 468 448 -20 do_jffs2_fsload 320 300 -20 do_imgextract636 592 -44 NetLoop 832 788 -44 do_mem_cp312 252 -60 do_bootm12441180 -64 do_mem_crc 188 88-100 do_mem_mtest14361332-104 So there are changes all over the place, including a growth of the memory footprint. I think this needs at least minimal review. We need more reviewers I think. Regards, Simon 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: w...@denx.de Time is an illusion perpetrated by the manufacturers of space. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 16/19] arm926ejs: Remove deprecated and now unused NAND SPL
On Sun, Feb 17, 2013 at 04:51:37PM +0100, Beno??t Th??baudeau wrote: Hi Albert, Tom, Zhong, On Friday, February 15, 2013 9:54:22 PM, Beno??t Th??baudeau wrote: Signed-off-by: Beno??t Th??baudeau benoit.thebaud...@advansee.com --- Changes in v7: None Changes in v6: - New patch. Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: None arch/arm/cpu/arm926ejs/start.S | 10 -- 1 file changed, 10 deletions(-) I would like to get your feedback regarding the status of the Samsung SMDK6400 board: - It is not in boards.cfg, so, according to commit 1285a28, support for it should already have been removed a long time ago. It also seems to be the only board remaining in the main Makefile. - It uses the deprecated NAND SPL. - MAKEALL does not test its build, which has been broken for a while. - If it were removed or fixed, ARM1176's start.S' relocate_code() could be made identical to all the other implementations of this function, so all this duplicated code could be moved to a common location like crt0.S. Besides that, it would be possible to completely get rid of the legacy NAND SPL on ARM. I have no intention of fixing this board, but dropping it and cleaning up ARM after that would be easy. I'm in favor of removing and updating README.scrapyard, baring quick attention from the maintainer to update it to not being using the Makefile and fix the rest of the breakage. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1] Refactor linker-generated arrays
Hi Andreas, On Mon, 18 Feb 2013 11:42:07 +0100, Andreas Bießmann andreas.de...@googlemail.com wrote: On 02/18/2013 11:39 AM, Andreas Bießmann wrote: Hi Albert, On 02/16/2013 07:20 PM, Albert ARIBAUD wrote: snip It's ok so far, the arm-linux toolchain I have do not produce these I mean avr32-linux ... damn weekend ... Thanks Andreas for the feedback. I am currently testing V2 locally and will send it out in a few hours hopefully. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 13/19] Makefile: u-boot-with-spl.bin: Fix SPL padding
On Sun, Feb 17, 2013 at 05:16:49PM +0100, Beno??t Th??baudeau wrote: Hi Poonam, Andy, On Friday, February 15, 2013 9:54:19 PM, Beno??t Th??baudeau wrote: PAD_TO is not a generic SPL configuration option, so use CONFIG_SPL_MAX_SIZE instead. We want to use --pad-to with a size, but this option expects an address, so use u-boot-spl.bin instead of u-boot-spl as the input file in order to get addresses starting at 0. Signed-off-by: Beno??t Th??baudeau benoit.thebaud...@advansee.com --- Changes in v7: - Use u-boot-spl.bin instead of u-boot-spl in order to avoid having to use --change-addresses. Changes in v6: - Fix size passed to --pad-to thanks to --change-addresses. Changes in v5: None Changes in v4: - New patch. Changes in v3: None Changes in v2: None Makefile |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index a8c7b7b..317dffc 100644 --- a/Makefile +++ b/Makefile @@ -486,7 +486,8 @@ $(obj)u-boot.dis: $(obj)u-boot $(OBJDUMP) -d $ $@ $(obj)u-boot-with-spl.bin: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin - $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(PAD_TO) -O binary $(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin + $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(CONFIG_SPL_MAX_SIZE) \ + -I binary -O binary $ $(obj)spl/u-boot-spl-pad.bin cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin $@ rm $(obj)spl/u-boot-spl-pad.bin I would like to let you know what is going on, and to get your feedback for this patch. include/configs/p1_p2_rdb_pc.h seems to be the only current user of u-boot-with-spl.bin, triggered for example by the P2020RDB-PC_NAND config. cam_enc_4xx also uses this target. Heiko? It looks like this change should be safe there as well. Before this patch, PAD_TO was used, but there is no such definition for this board for generic SPL, so this board seems broken, all the more none of the various values defined for CONFIG_SYS_TEXT_BASE relatively to CONFIG_SPL_TEXT_BASE would be compatible with an image built by appending U-Boot to the generic SPL. Can you confirm? This patch won't fix this board, but I want to make sure that it won't be an issue for you now or later. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 16/20] Roll crc32 into hash infrastructure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/18/2013 11:36 AM, Simon Glass wrote: Hi Wolfgang, On Mon, Feb 18, 2013 at 3:35 AM, Wolfgang Denk w...@denx.de wrote: Dear Tom, In message 51216721.1010...@ti.com you wrote: There's another thread I don't have yet (and I don't have this one in gmail yet even). But, I am OK with custodians using their repos, but not the master branch, for unrelated but otherwise good patches. I'm also fine with patchwork bundles. I suppose we could use the staging repository for these changes instead. What I mostly object about there is that these patches would go into mainline basicly unreviewed, as patch submission and pull request is all done from a single person, with no other feedback on the patches at all. And this affects a lot of common code... Fair enough. I suspect a number of people scan the code, but few feel invested enough to formally Ack it. Also, providing a full review of such a series can take quite a bit of time. Against that, I think it is better to get code in and tested than have it sit around until just before the next release. [snip] So there are changes all over the place, including a growth of the memory footprint. I think this needs at least minimal review. We need more reviewers I think. This is where I'm trying to find a good balance right now. If we just wait for reviewed-by lines to fly by, things will sit forever. Partly because enough folks don't feel like they own things enough to risk saying they reviewed something that turns out later to have a bug. And partly there's just not enough folks reading patches. I do try and give things some sort of read-over when it's the person posting who is doing the merging, especially for common rather than their area code. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRIl9FAAoJENk4IS6UOR1WJqMP/ie04KKI6NpMPDei9QSJ9+qg peFMXyVXoNWVZ0OuVSgVYOyBNtTmZeUmNsyamtE/1QifAWX6F2lwXHl2teYcebMk 7Fn/N3uzoVisfcFhY3Ec0dgBigYbRm5hiSHF7qzBkS78FfI5XSFaR/XjkshCgLlC i5Vf8Gh6ilb67fLumzxnXU2LLpbfcoOoT7iMLX0C5SFkx9sjo4k/5/WC64jsx8IS NQiaoFX3Ow7uU63G7jEJ4hiqXsp2ulWZTBA4ynN7ydGYiPo+sRXoLRaBYB9yAkRQ 3Uj1a101VX+9LWdNoMRpqv6W3gq75+8nSggovK0DmxtF4X5PaF17Xmpc8dBTT9rE cCIkePKDNgg6QjTAtCxk7+nw997JSjrj1nV0R2+Jm225tby4hIjmnIfnCNgeYbbI II7+ecaUl4w+GxB1SgjFLmEyW0unDsYZauT4sXxSdBp/UOrs4I3XYW4gFofifMcB peJELQYVUHnXblZ+xR+8zY3URsn2vNRxNq5fUDWMUADgvwecfvWFeKaVGDA+aWHs vNFKWayZbt5MpqG4aQJ4mzIhf9avNytf8BSSQ+LFp53xOl5f08OsioN9+4H3rOND LRuiMZ5wtrlJea3Eoi3PFXeO/l4N4eKvDNbwNSwDbS4EZj+4mZbGrNxGglcQK3C+ 1EM1fpRioWEXpGaMpmKV =W6Pn -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 16/20] Roll crc32 into hash infrastructure
Hi Wolfgang, On Mon, Feb 18, 2013 at 3:35 AM, Wolfgang Denk w...@denx.de wrote: Dear Tom, In message 51216721.1010...@ti.com you wrote: There's another thread I don't have yet (and I don't have this one in gmail yet even). But, I am OK with custodians using their repos, but not the master branch, for unrelated but otherwise good patches. I'm also fine with patchwork bundles. I suppose we could use the staging repository for these changes instead. What I mostly object about there is that these patches would go into mainline basicly unreviewed, as patch submission and pull request is all done from a single person, with no other feedback on the patches at all. And this affects a lot of common code... Actually, I see this change when pulling u-boot-x86.git/master: - bloat-o-meter u-boot-before u-boot What board is this please? Some specific notes here - I think it boils down to moving crc32 into the hash framework. This adds some overhead, but has a few benefits. add/remove: 9/0 grow/shrink: 3/14 up/down: 1006/-560 (446) function old new delta hash_command - 424+424 This is the generic hashing command. What is happening here is that the crc32 command is getting a few more features, more like sha1sum. However, this might not be desriable - and in fact this patch changes the behaviour of the CRC storage and verify to support using an environment variable, and requiring * before the argument when an address is required! That needs to be fixed, at least. The intent is to try to unify the hashing/crc features into a single framework. If you enable only crc32 and nothing else then this has quite a cost (0.5KB at present). I think I can reduce this code by making the full features of hash.c only available when something more than just crc32 is enabled. However, it might involve some #ifdefs... strncasecmp- 156+156 simple_itoa- 104+104 crc32_wd_buf - 76 +76 setenv_hex - 68 +68 setenv_ulong - 52 +52 strcasecmp - 36 +36 do_mem_loopw 304 328 +24 static.local - 22 +22 do_mem_loop 268 288 +20 hash_algo - 16 +16 do_mem_cmp 332 340 +8 do_mem_mw224 220 -4 set_working_fdt_addr 72 52 -20 load_serial_ymodem 300 280 -20 load_serial 512 492 -20 index_partitions 200 180 -20 do_load_serial_bin 18441824 -20 do_load 468 448 -20 do_jffs2_fsload 320 300 -20 do_imgextract636 592 -44 NetLoop 832 788 -44 do_mem_cp312 252 -60 do_bootm12441180 -64 do_mem_crc 188 88-100 do_mem_mtest14361332-104 So there are changes all over the place, including a growth of the memory footprint. I think this needs at least minimal review. 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: w...@denx.de Time is an illusion perpetrated by the manufacturers of space. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 13/19] Makefile: u-boot-with-spl.bin: Fix SPL padding
On Monday, February 18, 2013 5:50:59 PM, Tom Rini wrote: On Sun, Feb 17, 2013 at 05:16:49PM +0100, Beno??t Th??baudeau wrote: Hi Poonam, Andy, On Friday, February 15, 2013 9:54:19 PM, Beno??t Th??baudeau wrote: PAD_TO is not a generic SPL configuration option, so use CONFIG_SPL_MAX_SIZE instead. We want to use --pad-to with a size, but this option expects an address, so use u-boot-spl.bin instead of u-boot-spl as the input file in order to get addresses starting at 0. Signed-off-by: Beno??t Th??baudeau benoit.thebaud...@advansee.com --- Changes in v7: - Use u-boot-spl.bin instead of u-boot-spl in order to avoid having to use --change-addresses. Changes in v6: - Fix size passed to --pad-to thanks to --change-addresses. Changes in v5: None Changes in v4: - New patch. Changes in v3: None Changes in v2: None Makefile |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index a8c7b7b..317dffc 100644 --- a/Makefile +++ b/Makefile @@ -486,7 +486,8 @@ $(obj)u-boot.dis: $(obj)u-boot $(OBJDUMP) -d $ $@ $(obj)u-boot-with-spl.bin: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin - $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(PAD_TO) -O binary $(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin + $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(CONFIG_SPL_MAX_SIZE) \ + -I binary -O binary $ $(obj)spl/u-boot-spl-pad.bin cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin $@ rm $(obj)spl/u-boot-spl-pad.bin I would like to let you know what is going on, and to get your feedback for this patch. include/configs/p1_p2_rdb_pc.h seems to be the only current user of u-boot-with-spl.bin, triggered for example by the P2020RDB-PC_NAND config. cam_enc_4xx also uses this target. Heiko? It looks like this change should be safe there as well. And MPC8313ERDB too. But I've just seen that commit 74752ba did something for that in u-boot/master, and this commit is not in u-boot-imx/master on which I based this series. Why is u-boot-imx/master not sync'ed with u-boot/master? How am I supposed to handle patch sets depending on several custodian repositories? Commit 74752ba performs a '--pad-to=$(or $(CONFIG_SPL_PAD_TO),0)' on u-boot-spl. I could use this CONFIG_SPL_PAD_TO for this series too, but is it really necessary to have both CONFIG_SPL_PAD_TO and CONFIG_SPL_MAX_SIZE? In other words, is there any case for which CONFIG_SPL_PAD_TO could be different from CONFIG_SPL_TEXT_BASE + CONFIG_SPL_MAX_SIZE for a valid reason? Before this patch, PAD_TO was used, but there is no such definition for this board for generic SPL, so this board seems broken, all the more none of the various values defined for CONFIG_SYS_TEXT_BASE relatively to CONFIG_SPL_TEXT_BASE would be compatible with an image built by appending U-Boot to the generic SPL. Can you confirm? This patch won't fix this board, but I want to make sure that it won't be an issue for you now or later. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH] Provide a mechanism to avoid using #ifdef everywhere
Many parts of the U-Boot code base are sprinkled with #ifdefs. This makes different boards compile different versions of the source code, meaning that we must build all boards to check for failures. It is easy to misspell an #ifdef and there is not as much checking of this by the compiler. Multiple dependent #ifdefs are harder to do than with if..then..else. Variable declarations must be #idefed as well as the code that uses them, often much later in the file/function. #ifdef indents don't match code indents and have their own separate indent feature. Overall, excessive use of #idef hurts readability and makes the code harder to modify and refactor. For people coming newly into the code base, #ifdefs can be a big barrier. The use of #ifdef in U-Boot has possibly got a little out of hand. In an attempt to turn the tide, this patch provides a way to make CONFIG macros available to C code without using the preprocessor. This makes it possible to use standard C conditional features such as if/then instead of #ifdef. A README update exhorts compliance. As an example of how to use this, this patch replaces all but two #ifdefs from the main code body of common/main.c, which has the dubious distinction of having the most #ifdefs by at least one measure: $ for f in $(find . -name *.c); do echo $(grep -c ifdef $f) $f; done \ |sort -nr |head 57 ./common/main.c 57 ./arch/powerpc/cpu/mpc83xx/cpu_init.c 48 ./arch/powerpc/lib/board.c 46 ./drivers/video/cfb_console.c 40 ./drivers/mtd/cfi_flash.c 38 ./net/tftp.c 38 ./common/cmd_bootm.c 37 ./drivers/usb/host/ohci-hcd.c 36 ./drivers/fpga/ivm_core.c 35 ./drivers/usb/gadget/ether.c Code size for this patch seems to be roughly neutral (below numbers are average change in byte size for each region: x86: (3 boards) text -1.3 data +1.3 sandbox: (1 boards) bss +16.0 m68k: (50 boards) text -4.8 powerpc: (634 boards) text +7.4 data +0.0 bss +2.1 sh: (21 boards) text -9.1 bss +2.5 nios2: (3 boards) text +24.0 arm: (287 boards) spl/u-boot-spl:text -0.3 text -2.3 bss +7.2 nds32: (3 boards) text -16.0 Signed-off-by: Simon Glass s...@chromium.org --- Makefile | 41 ++- README| 87 - common/cmd_fitupd.c | 1 + common/main.c | 794 ++ include/command.h | 2 - include/common.h | 9 +- include/config_drop.h | 17 + include/configs/pm9263.h | 2 +- include/fdt_support.h | 4 +- include/hush.h| 2 - include/menu.h| 2 - include/net.h | 2 + tools/scripts/define2conf.sed | 36 ++ tools/scripts/define2list.sed | 31 ++ 14 files changed, 563 insertions(+), 467 deletions(-) create mode 100644 include/config_drop.h create mode 100644 tools/scripts/define2conf.sed create mode 100644 tools/scripts/define2list.sed diff --git a/Makefile b/Makefile index fc18dd4..5ca3a57 100644 --- a/Makefile +++ b/Makefile @@ -614,6 +614,7 @@ updater: # parallel sub-makes creating .depend files simultaneously. depend dep:$(TIMESTAMP_FILE) $(VERSION_FILE) \ $(obj)include/autoconf.mk \ + $(obj)include/generated/autoconf.h \ $(obj)include/generated/generic-asm-offsets.h \ $(obj)include/generated/asm-offsets.h for dir in $(SUBDIRS) $(CPUDIR) $(LDSCRIPT_MAKEFILE_DIR) ; do \ @@ -688,6 +689,43 @@ $(obj)include/autoconf.mk: $(obj)include/config.h sed -n -f tools/scripts/define2mk.sed $@.tmp \ mv $@.tmp $@ +# Create a C header file where every '#define CONFIG_XXX value' becomes +# '#define config_xxx() value', or '#define config_xxx() 0' where the CONFIG +# is not used by this board configuration. This allows C code to do things +# like 'if (config_xxx())' and have the compiler remove the dead code, +# instead of using '#ifdef CONFIG_XXX...#endif'. Note that in most cases +# if the config_...() returns 0 then the option is not enabled. In some rare +# cases such as CONFIG_BOOTDELAY, the config can be enabled but still have a +# a value of 0. So in addition we a #define config_xxx_enabled(), setting the +# value to 0 if the option is disabled, 1 if enabled. This last feature will +# hopefully be deprecated soon. +# The file is regenerated when any U-Boot header file changes. +$(obj)include/generated/autoconf.h: $(obj)include/config.h + @$(XECHO) Generating $@ ; \ + set -e ; \ + : Extract the config macros to a C header file ; \ + $(CPP) $(CFLAGS) -DDO_DEPS_ONLY -dM include/common.h | \ + sed -n -f tools/scripts/define2conf.sed $@.tmp; \ + : Regenerate our list of all config macros if neeed ; \ + if [ ! -f $@-all.tmp ] || \ + find $(src) -name '*.h' -type f -newer $@-all.tmp | \ + egrep -qv
Re: [U-Boot] [PATCH] CONFIG_BOOTDELAY default should not affect runtime
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/09/2013 11:21 AM, Otavio Salvador wrote: Hello Wolfgang, On Sat, Feb 9, 2013 at 4:54 AM, Wolfgang Denk w...@denx.de wrote: Dear Joe Hershberger, In message 1360355280-1197-1-git-send-email-joe.hershber...@ni.com you wrote: Because the code that handles bootdelay is compiled in conditionally based on the default value, you are restricted in the default, regardless of what you want the runtime options to be. Change the source to always check if any default is given so that other values can be selected and used at runtime. Signed-off-by: Joe Hershberger joe.hershber...@ni.com --- common/main.c | 14 ++ 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/common/main.c b/common/main.c index e2d2e09..0973c59 100644 --- a/common/main.c +++ b/common/main.c @@ -95,7 +95,7 @@ extern void mdm_init(void); /* defined in board.c */ * Watch for 'delay' seconds for autoboot stop or autoboot delay string. * returns: 0 - no key string, allow autoboot 1 - got key string, abort */ -#if defined(CONFIG_BOOTDELAY) (CONFIG_BOOTDELAY = 0) +#if defined(CONFIG_BOOTDELAY) Careful!! This is probably changing behaviour of a number of boards significantly. we have to check if we really want this, and if yes, we have to announce it and provide a grace period (eventually using doc/feature-removal-schedule.txt ?) It seems the CONFIG_BOOTDELAY as 0 is not very common: ~/hacking/u-boot% git grep CONFIG_BOOTDELAY | egrep 'BOOTDELAY\s* \-[0-9]' include/configs/RPXsuper.h:#define CONFIG_BOOTDELAY -1 include/configs/ep8260.h:#define CONFIG_BOOTDELAY-1 include/configs/espt.h:#define CONFIG_BOOTDELAY-1 include/configs/scb9328.h:#define CONFIG_BOOTDELAY -1 include/configs/sh7763rdp.h:#define CONFIG_BOOTDELAY-1 I count 49 boards with git grep -E 'CONFIG_BOOTDELAY[[:blank:]]+-[0-9]' so it's not _that_ uncommon. So maybe those could have CONFIG_BOOTDELAY undefined keeping them working as before? The problem is that as I read the README, we document CONFIG_BOOTDELAY as having a valid value range of from -2 to sane positive value. So yes, if we want to change this we need to (a) change the README too and (b) give some sort of heads-up. Off the top of my head, we could change to: CONFIG_AUTOBOOT_DISABLED and CONFIG_FORCE_AUTOBOOT_NO_DELAY and update doc/README.autoboot as well and add some sanity #warning checks for a release or two in some common generated config related file or something like that. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRImLoAAoJENk4IS6UOR1W78kP/1xHVrQ4pZbAV8WnBsxje+gn qphEJU5Ud+gA5ThyEm/I1d1VSSvLgOWGqnarleOSXUmcWkBcbfetO69VVLnvlUI+ oVXEopn7plCO7iM2YAiOW8vx5fy97JqGxWn1/BJ64ySjup5GlEXd97Op9LQ+wjy7 xNgFQ1KN9wdoabQU2PUy7jeGXY8LTdFx4GsYSK/KRJWIvo3O57c2uOsE2BiA2Uxq Ue780cVqqsoRmZxo2gooAUTupz3kPYmFthPn2qxs1y3nLn4GVrJM5YurOhH2weeA sHOffHqlUn1kUxrhRnM6mpeu+JUeKFP8IoyOuhCYA7D28Bk1XtqkZai+yobOrf3U cr4WUdhZEA9hFZAXnlrVe/FjVLe6pvQ9hPjUshPoCerahrcpUOwiegrw6IWg+vzB DdK5hbPh09rTdpfnjWWRf0fSrqQqaXmNQALmRQOc4G1Vn8xKruC4vacetdNRfgCn gFOSTpbDBG7oKFXHpCzliXEg8lFy+af+oMKTztR/UtPrBX5cfr6XF2SekNm9jus4 Njjq1ouYKXfOyeNIrg0prOi14ZMF3uQYb/eUsffzeujdmbhcgENopUrGLl9FvlxV bsktw7oWhgirVZ5CsODk/3siDfJc1pi9yz3oMO61Qqtrrv3HLLjGIFEx4DjxNmkk COfH7og2vh8xQavT8IXY =oTlx -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 13/19] Makefile: u-boot-with-spl.bin: Fix SPL padding
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/18/2013 12:26 PM, Benoît Thébaudeau wrote: [snip] But I've just seen that commit 74752ba did something for that in u-boot/master, and this commit is not in u-boot-imx/master on which I based this series. Why is u-boot-imx/master not sync'ed with u-boot/master? How am I supposed to handle patch sets depending on several custodian repositories? I'm not sure why u-boot-imx is out of sync at the moment. My rule of thumb is to start working on u-boot/master and cherry-pick out things I need from other places into a -test branch. I know the kernel folks have to deal with a lot of this as well, but I think it ends up being a developer choice on what best fits their needs when they need N different series to be applied for their starting point. Commit 74752ba performs a '--pad-to=$(or $(CONFIG_SPL_PAD_TO),0)' on u-boot-spl. I could use this CONFIG_SPL_PAD_TO for this series too, but is it really necessary to have both CONFIG_SPL_PAD_TO and CONFIG_SPL_MAX_SIZE? In other words, is there any case for which CONFIG_SPL_PAD_TO could be different from CONFIG_SPL_TEXT_BASE + CONFIG_SPL_MAX_SIZE for a valid reason? I was wondering along those lines. I don't _think_ we need both CONFIG_SPL_PAD_TO and CONFIG_SPL_MAX_SIZE, but we can't combine CONFIG_SPL_MAX_SIZE and CONFIG_SPL_TEXT_BASE as on TI platforms we start quite well above zero (0x402F0400 on am33xx, etc). That said, I guess we do need CONFIG_SPL_PAD_TO so that some platforms can do: #define CONFIG_SPL_PAD_TO (CONFIG_SPL_TEXT_BASE + CONFIG_SPL_MAX_SIZE) and others just #define CONFIG_SPL_PAD_TO CONFIG_SPL_MAX_SIZE - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRImSWAAoJENk4IS6UOR1W0DkP/3VBLW0gdRoIfvNHpO3cI0Db FfjKGQoCgAmrlCE4PyGo2SkkBPl/doxLWYCOr8DJ/BDnjF04r/8NMT/wn/a9xrvv d5fCpIxQPme356SfMS23LVnTmJR4mOKLdHjJ2QXxyrFXXTnI7W80iPgfslgCTJje kxbH5chVQq7LYN9ZeynOP9XEZYT9rTcAXG9LVPqStWi73izpMa/D0adc/FqdWfi3 qcstiSxSQyPWmF7O7dRYzs9J4BMcT749NuQmkvbrh64/XL81emynfrYCgBU70QMr uQV9qxq+zALmUuMTdWRD0ATLQiybuN5Mbam7X4ACAmi8THfSEuUWtS3g0PR9+FH+ /HYICi8l2WDONRCWDcj5PLpQNYaNeunSPj+8q4g4i/OiEO+1rWZqtrgXxcH/WTlT dz6C6w/YFhfCakKwB8r2+5H3GyIpoDgbqsCfxI8LTNDA69/zXohbH6uDNMqWDPAV IS0+7Z3iC+MPmfkAXL2vz02CoiUiX2YwgYrhVrmPAbbsHSLndh2oAmGkdl8Hc2BK zhCKW75bv1flXwBIE3skocKZTDTjiMsMKoqosiFtSIaXQsn6Zz7YYh4ZpCNE0U3C P3GRpeotnXk0jRp6DOGKceWfVQLbY3rAZKWoMAjTujGIh3YfXRVU+KWLqi8APjNK a2aPpMFx6Oy72BQvV11W =zJru -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 13/19] Makefile: u-boot-with-spl.bin: Fix SPL padding
On Monday, February 18, 2013 6:27:50 PM, Tom Rini wrote: Commit 74752ba performs a '--pad-to=$(or $(CONFIG_SPL_PAD_TO),0)' on u-boot-spl. I could use this CONFIG_SPL_PAD_TO for this series too, but is it really necessary to have both CONFIG_SPL_PAD_TO and CONFIG_SPL_MAX_SIZE? In other words, is there any case for which CONFIG_SPL_PAD_TO could be different from CONFIG_SPL_TEXT_BASE + CONFIG_SPL_MAX_SIZE for a valid reason? I was wondering along those lines. I don't _think_ we need both CONFIG_SPL_PAD_TO and CONFIG_SPL_MAX_SIZE, but we can't combine CONFIG_SPL_MAX_SIZE and CONFIG_SPL_TEXT_BASE as on TI platforms we start quite well above zero (0x402F0400 on am33xx, etc). That said, I guess we do need CONFIG_SPL_PAD_TO so that some platforms can do: #define CONFIG_SPL_PAD_TO (CONFIG_SPL_TEXT_BASE + CONFIG_SPL_MAX_SIZE) and others just #define CONFIG_SPL_PAD_TO CONFIG_SPL_MAX_SIZE If we did like my patch here, i.e. use objcopy with u-boot-spl.bin instead of u-boot-spl, objcopy would always get a fake 0x0 address at the beginning of the .bin, so CONFIG_SPL_MAX_SIZE could be used with --pad-to, and CONFIG_SPL_PAD_TO would be useless. The only question is if we may need to have an empty gap between the SPL and U-Boot within the resulting image. I don't think so since that would mean that the target memory device has an area that is not really available at the location of this gap. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 13/19] Makefile: u-boot-with-spl.bin: Fix SPL padding
On 02/18/2013 06:28:15 AM, Benoît Thébaudeau wrote: I'm also wondering why there is both generic SPL for NAND and legacy NAND SPL for p1_p2_rdb, all the more the NAND SPL version does not seem to be used in boards.cfg. p1_p2_rdb_pc and P1_P2_RDB are different targets (unfortunately). The former is for newer boards and has been converted to the new SPL. The latter is for older boards, which I do not have access to and have had a hard time getting information about (which would be required to merge the two targets). Perhaps P1_P2_RDB should just be removed. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 13/19] Makefile: u-boot-with-spl.bin: Fix SPL padding
On 02/18/2013 12:00:52 PM, Benoît Thébaudeau wrote: On Monday, February 18, 2013 6:27:50 PM, Tom Rini wrote: Commit 74752ba performs a '--pad-to=$(or $(CONFIG_SPL_PAD_TO),0)' on u-boot-spl. I could use this CONFIG_SPL_PAD_TO for this series too, but is it really necessary to have both CONFIG_SPL_PAD_TO and CONFIG_SPL_MAX_SIZE? In other words, is there any case for which CONFIG_SPL_PAD_TO could be different from CONFIG_SPL_TEXT_BASE + CONFIG_SPL_MAX_SIZE for a valid reason? They're logically different things. I was wondering along those lines. I don't _think_ we need both CONFIG_SPL_PAD_TO and CONFIG_SPL_MAX_SIZE, but we can't combine CONFIG_SPL_MAX_SIZE and CONFIG_SPL_TEXT_BASE as on TI platforms we start quite well above zero (0x402F0400 on am33xx, etc). That said, I guess we do need CONFIG_SPL_PAD_TO so that some platforms can do: #define CONFIG_SPL_PAD_TO (CONFIG_SPL_TEXT_BASE + CONFIG_SPL_MAX_SIZE) and others just #define CONFIG_SPL_PAD_TO CONFIG_SPL_MAX_SIZE If we did like my patch here, i.e. use objcopy with u-boot-spl.bin instead of u-boot-spl, objcopy would always get a fake 0x0 address at the beginning of the .bin, so CONFIG_SPL_MAX_SIZE could be used with --pad-to, and CONFIG_SPL_PAD_TO would be useless. The only question is if we may need to have an empty gap between the SPL and U-Boot within the resulting image. I don't think so since that would mean that the target memory device has an area that is not really available at the location of this gap. Why not allow that possibility? Maybe it's easier for the SPL to load from a particular offset (e.g. NAND starting at the beginning of a block)? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 13/19] Makefile: u-boot-with-spl.bin: Fix SPL padding
On Monday, February 18, 2013 7:02:49 PM, Scott Wood wrote: On 02/18/2013 12:00:52 PM, Benoît Thébaudeau wrote: On Monday, February 18, 2013 6:27:50 PM, Tom Rini wrote: Commit 74752ba performs a '--pad-to=$(or $(CONFIG_SPL_PAD_TO),0)' on u-boot-spl. I could use this CONFIG_SPL_PAD_TO for this series too, but is it really necessary to have both CONFIG_SPL_PAD_TO and CONFIG_SPL_MAX_SIZE? In other words, is there any case for which CONFIG_SPL_PAD_TO could be different from CONFIG_SPL_TEXT_BASE + CONFIG_SPL_MAX_SIZE for a valid reason? They're logically different things. I was wondering along those lines. I don't _think_ we need both CONFIG_SPL_PAD_TO and CONFIG_SPL_MAX_SIZE, but we can't combine CONFIG_SPL_MAX_SIZE and CONFIG_SPL_TEXT_BASE as on TI platforms we start quite well above zero (0x402F0400 on am33xx, etc). That said, I guess we do need CONFIG_SPL_PAD_TO so that some platforms can do: #define CONFIG_SPL_PAD_TO (CONFIG_SPL_TEXT_BASE + CONFIG_SPL_MAX_SIZE) and others just #define CONFIG_SPL_PAD_TO CONFIG_SPL_MAX_SIZE If we did like my patch here, i.e. use objcopy with u-boot-spl.bin instead of u-boot-spl, objcopy would always get a fake 0x0 address at the beginning of the .bin, so CONFIG_SPL_MAX_SIZE could be used with --pad-to, and CONFIG_SPL_PAD_TO would be useless. The only question is if we may need to have an empty gap between the SPL and U-Boot within the resulting image. I don't think so since that would mean that the target memory device has an area that is not really available at the location of this gap. Why not allow that possibility? To save a config setting (there are already many for SPL) if this is not strictly required, but also for the reason below. Maybe it's easier for the SPL to load from a particular offset (e.g. NAND starting at the beginning of a block)? CONFIG_SPL_MAX_SIZE would be closer to a NAND mapping in that case (e.g. size of 1 NAND Flash block) than CONFIG_SPL_PAD_TO (address within RAM that should be considered relatively to CONFIG_SPL_TEXT_BASE to get the NAND offset). Also, CONFIG_SPL_PAD_TO and CONFIG_SPL_MAX_SIZE depend on each other: If both can be defined, you may change one forgetting the other one, which could e.g. result in an overlapping of SPL and U-Boot that won't show up at build time (with CONFIG_SPL_MAX_SIZE = 0x1000 and CONFIG_SPL_PAD_TO = CONFIG_SPL_TEXT_BASE + 0x800, the SPL would build fine, and objcopy wouldn't complain). Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] trying to understand u-boot-nand.ais file for AM1808 exp kit
i hope someone here can clear up what should be a simple question -- i'm trying to figure out what exactly is going on when building and flashing a u-boot image for my new AM1808 experimenter kit or, more accurately, someone else's modified version where the 8M of NOR flash has been replaced with 2G of NAND flash. i've downloaded the DaVinci PSP SDK (v03.22.00.02) and i'm trying to figure out what the prebuilt u-boot images mean, and what it means to flash them. the earlier PSP SDK used separate ubl and u-boot images, so i've seen examples of using the supplied windows-based sfh_OMAP-L138.exe utility to flash the board, in that it had to reference both binary files since, with that earlier PSP SDK, they were separate objects. with this current SDK, the build now creates a combination image, as explained in the User's Guide: U-Boot included in this release will replace the UBL which was being used to copy U-Boot to external RAM. the contents of the ready-to-flash images directory in this PSP SDK is: u-boot-mmcsd.ais u-boot-mmcsd.bin u-boot-nand.ais u-boot-nor.bin u-boot-spi.ais so my questions are: 1) when one flashes these images to the board, where exactly are they being placed? in some SPI flash of some kind totally separate from the main NOR (or, in this case, NAND) flash? 2) given that the standard NOR flash has been replaced with NAND, which (now single) u-boot image file should i be flashing? i *think*, from the user guide, it would be u-boot-nand.ais, as the command for flashing to NAND flash is given as: ..\sfh_OMAP-L138.exe -flash_noubl -flashType NAND u-boot AIS file it's just not clear what command i'd use for this situation, and where that single u-boot image would end up. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 13/19] Makefile: u-boot-with-spl.bin: Fix SPL padding
On 02/18/2013 12:22:58 PM, Benoît Thébaudeau wrote: On Monday, February 18, 2013 7:02:49 PM, Scott Wood wrote: On 02/18/2013 12:00:52 PM, Benoît Thébaudeau wrote: The only question is if we may need to have an empty gap between the SPL and U-Boot within the resulting image. I don't think so since that would mean that the target memory device has an area that is not really available at the location of this gap. Why not allow that possibility? To save a config setting (there are already many for SPL) if this is not strictly required, but also for the reason below. Maybe it's easier for the SPL to load from a particular offset (e.g. NAND starting at the beginning of a block)? CONFIG_SPL_MAX_SIZE would be closer to a NAND mapping in that case (e.g. size of 1 NAND Flash block) than CONFIG_SPL_PAD_TO (address within RAM that should be considered relatively to CONFIG_SPL_TEXT_BASE to get the NAND offset). CONFIG_SPL_PAD_TO is for the placement of the payload -- and it's not a RAM address. Currently it is a link address (or zero if the linker script handles padding, or padding is not required for other reasons). With your patch it it is a file offset, IIUC. CONFIG_SPL_MAX_SIZE is what it says -- the maximum size that the SPL may be, ideally to be enforced by the linker script. They are different. An SPL wanting the payload to begin as a block boundary does not mean the hardware is suddenly capable of loading an entire block of SPL. Also, CONFIG_SPL_PAD_TO and CONFIG_SPL_MAX_SIZE depend on each other: If both can be defined, you may change one forgetting the other one, which could e.g. result in an overlapping of SPL and U-Boot that won't show up at build time (with CONFIG_SPL_MAX_SIZE = 0x1000 and CONFIG_SPL_PAD_TO = CONFIG_SPL_TEXT_BASE + 0x800, the SPL would build fine, and objcopy wouldn't complain). So add a check that CONFIG_SPL_PAD_TO = CONFIG_SPL_MAX_SIZE (assuming the new interpretation of CONFIG_SPL_PAD_TO as a file offset), and let CONFIG_SPL_PAD_TO default to CONFIG_SPL_MAX_SIZE if not set. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/5] Add support for using an UBI volume for environment
On Fri, Feb 08, 2013 at 02:07:21PM -0600, Joe Hershberger wrote: NAND is not good at handling absolute addresses to sectors for storing particular data. The current implementation of the NAND env support works around this in several ways such as storing a pointer to the sector in the OOB of the first sector (interferes with some CRC) or supporting a range of sectors (which unless it is huge is not guaranteed to be safe). None of these options address wear-leveling concerns or bad block handling. Accessing the u-boot env from UBI eliminates these concerns. However, it does require some of the basic settings for finding the UBI env to be in the default u-boot env. Joe Hershberger (5): ubi: Expose a few simple functions from the cmd_ubi ubi: ubifs: Turn off verbose prints mtd: Make mtdparts work with pre-reloc env env: Add support for UBI environment env: Add redundant env support to UBI env README| 21 + common/Makefile | 1 + common/cmd_mtdparts.c | 23 +- common/cmd_nvedit.c | 7 +- common/cmd_ubi.c | 149 +++--- common/env_ubi.c | 218 ++ drivers/mtd/mtdpart.c | 14 ++-- drivers/mtd/ubi/ubi.h | 3 +- fs/ubifs/ubifs.h | 2 +- include/environment.h | 18 + include/ubi_uboot.h | 3 + tools/env/fw_env.c| 6 +- 12 files changed, 387 insertions(+), 78 deletions(-) create mode 100644 common/env_ubi.c Please add a patch 6 which enables all of these options for some board, preferably the one you've been testing this with. Thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] Davinci: Make MAC address offset in EEPROM configurable CONFIG_SYS_I2C_EEPROM_MAC_OFFSET
On Fri, Feb 01, 2013 at 07:18:58AM +, Kim B??ndergaard wrote: --- arch/arm/cpu/arm926ejs/davinci/misc.c | 2 +- include/configs/da830evm.h| 1 + include/configs/davinci_dm365evm.h| 1 + include/configs/davinci_dm6467evm.h | 1 + include/configs/davinci_dvevm.h | 1 + include/configs/davinci_sffsdr.h | 1 + include/configs/davinci_sonata.h | 1 + 7 files changed, 7 insertions(+), 1 deletion(-) With the following addition to fix da850_am18xxevm: diff --git a/boards.cfg b/boards.cfg index b1319aa..e89762b 100644 --- a/boards.cfg +++ b/boards.cfg @@ -137,7 +137,7 @@ portuxg20arm arm926ejs stamp9g20 taskit stamp9g20arm arm926ejs stamp9g20 taskit at91stamp9g20:AT91SAM9G20 cam_enc_4xx arm arm926ejs cam_enc_4xx ait davinci cam_enc_4xx da830evm arm arm926ejs da8xxevm davincidavinci -da850_am18xxevm arm arm926ejs da8xxevm davincidavinci da850evm:DA850_AM18X_EVM,MAC_ADDR_IN_EEPROM,SYS_I2C_EEPROM_ADDR_LEN=2,SYS_I2C_EEPROM_ADDR=0x50 +da850_am18xxevm arm arm926ejs da8xxevm davincidavinci da850evm:DA850_AM18X_EVM,MAC_ADDR_IN_EEPROM,SYS_I2C_EEPROM_ADDR_LEN=2,SYS_I2C_EEPROM_ADDR=0x50,SYS_I2C_EEPROM_MAC_OFFSET=0x7F00 da850evm arm arm926ejs da8xxevm davincidavinci da850evm:MAC_ADDR_IN_SPIFLASH da850evm_direct_nor arm arm926ejs da8xxevm davincidavinci da850evm:MAC_ADDR_IN_SPIFLASH,USE_NOR,DIRECT_NOR_BOOT davinci_dm355evm arm arm926ejs dm355evm davincidavinci Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 13/19] Makefile: u-boot-with-spl.bin: Fix SPL padding
On Monday, February 18, 2013 7:24:51 PM, Scott Wood wrote: On 02/18/2013 12:22:58 PM, Benoît Thébaudeau wrote: On Monday, February 18, 2013 7:02:49 PM, Scott Wood wrote: On 02/18/2013 12:00:52 PM, Benoît Thébaudeau wrote: The only question is if we may need to have an empty gap between the SPL and U-Boot within the resulting image. I don't think so since that would mean that the target memory device has an area that is not really available at the location of this gap. Why not allow that possibility? To save a config setting (there are already many for SPL) if this is not strictly required, but also for the reason below. Maybe it's easier for the SPL to load from a particular offset (e.g. NAND starting at the beginning of a block)? CONFIG_SPL_MAX_SIZE would be closer to a NAND mapping in that case (e.g. size of 1 NAND Flash block) than CONFIG_SPL_PAD_TO (address within RAM that should be considered relatively to CONFIG_SPL_TEXT_BASE to get the NAND offset). CONFIG_SPL_PAD_TO is for the placement of the payload Correct. -- and it's not a RAM address. It doesn't have to be, but it may be for some configs. Currently it is a link address (or zero if the linker script handles padding, or padding is not required for other reasons). Correct. With your patch it it is a file offset, IIUC. With my patch, it is nothing at all since only CONFIG_SPL_MAX_SIZE is used. CONFIG_SPL_MAX_SIZE is what it says -- the maximum size that the SPL may be, ideally to be enforced by the linker script. Correct. They are different. An SPL wanting the payload to begin as a block boundary does not mean the hardware is suddenly capable of loading an entire block of SPL. Sure, but my question is: Why would you want to have a 2-kiB SPL followed by a 126-kiB gap before the payload? Why couldn't you place the payload on the 1st page boundary after the SPL? If there are hardware constraints or something that make CONFIG_SPL_PAD_TO useful in some cases, then let's use it, but otherwise, why keep it? And if we keep it, do we change it to an image offset, or do we keep it as a link address? Also, CONFIG_SPL_PAD_TO and CONFIG_SPL_MAX_SIZE depend on each other: If both can be defined, you may change one forgetting the other one, which could e.g. result in an overlapping of SPL and U-Boot that won't show up at build time (with CONFIG_SPL_MAX_SIZE = 0x1000 and CONFIG_SPL_PAD_TO = CONFIG_SPL_TEXT_BASE + 0x800, the SPL would build fine, and objcopy wouldn't complain). So add a check that CONFIG_SPL_PAD_TO = CONFIG_SPL_MAX_SIZE (assuming the new interpretation of CONFIG_SPL_PAD_TO as a file offset), and let CONFIG_SPL_PAD_TO default to CONFIG_SPL_MAX_SIZE if not set. That would make sense. The current default value of 0 for CONFIG_SPL_PAD_TO does not make sense since it means that the SPL can't know where the payload is located within the image. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] imx6, spl and falcon boot
Ok is there documentation anywhere that can show the requirements for supporting SPL if I'd like to be able to implement it, same with falcon mode? I've already got support for nitrogen6x through another vendor but they won't support the spl. I'm taking a look at board/woodburn/woodburn.c to see what was done for another board that supports SPL. It just looks like void board_init_f(ulong dummy) needs to be implemented for the SPL. Someone recommend I look at another set of patch notes that have better docs, but I see it mostly has the falcon mode in it. http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/146987/focus=147040 -Original Message- From: Dirk Behme [mailto:dirk.be...@gmail.com] Sent: Saturday, February 16, 2013 2:32 AM To: Chaves, Kevin Cc: u-boot@lists.denx.de; Eric Nelson Subject: Re: [U-Boot] imx6, spl and falcon boot Am 15.02.2013 21:45, schrieb Chaves, Kevin: Hi, First off, sorry I'm not used to using mailing lists. I'm not sure if this is the best way to dig for information. We've recently switched to uboot/linux from wince and I'm trying to understand how configuring uboot works. I'm also trying to find out how to use the SPL framework and possibly falcon mode with a i.mx6 nitrogen6x board. I'd be delighted if any one could help! I haven't used spl and falcon mode, so I can't help with these. Regarding the general support for the i.mx6 nitrogen6x this isn't in U-Boot mainline, yet. Try to git pull the most recent U-Boot mainline from git://git.denx.de/u-boot.git [1] and apply the patch http://patchwork.ozlabs.org/patch/216991/ You should then be able to build one of the supported boards nitrogen6q nitrogen6dl nitrogen6s nitrogen6q2g nitrogen6dl2g nitrogen6s1g by make nitrogen6xxx_config make (replace the 'xxx' with the ending matching your board, e.g. 'q' if you have a Quad board). Best regards Dirk [1] http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=summary ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] Davinci: Make MAC address offset in EEPROM configurable CONFIG_SYS_I2C_EEPROM_MAC_OFFSET
On Mon, Feb 18, 2013 at 01:39:45PM -0500, Tom Rini wrote: On Fri, Feb 01, 2013 at 07:18:58AM +, Kim B??ndergaard wrote: --- arch/arm/cpu/arm926ejs/davinci/misc.c | 2 +- include/configs/da830evm.h| 1 + include/configs/davinci_dm365evm.h| 1 + include/configs/davinci_dm6467evm.h | 1 + include/configs/davinci_dvevm.h | 1 + include/configs/davinci_sffsdr.h | 1 + include/configs/davinci_sonata.h | 1 + 7 files changed, 7 insertions(+), 1 deletion(-) With the following addition to fix da850_am18xxevm: diff --git a/boards.cfg b/boards.cfg index b1319aa..e89762b 100644 --- a/boards.cfg +++ b/boards.cfg @@ -137,7 +137,7 @@ portuxg20arm arm926ejs stamp9g20 taskit stamp9g20arm arm926ejs stamp9g20 taskit at91stamp9g20:AT91SAM9G20 cam_enc_4xx arm arm926ejs cam_enc_4xx ait davinci cam_enc_4xx da830evm arm arm926ejs da8xxevm davincidavinci -da850_am18xxevm arm arm926ejs da8xxevm davincidavinci da850evm:DA850_AM18X_EVM,MAC_ADDR_IN_EEPROM,SYS_I2C_EEPROM_ADDR_LEN=2,SYS_I2C_EEPROM_ADDR=0x50 +da850_am18xxevm arm arm926ejs da8xxevm davincidavinci da850evm:DA850_AM18X_EVM,MAC_ADDR_IN_EEPROM,SYS_I2C_EEPROM_ADDR_LEN=2,SYS_I2C_EEPROM_ADDR=0x50,SYS_I2C_EEPROM_MAC_OFFSET=0x7F00 da850evm arm arm926ejs da8xxevm davincidavinci da850evm:MAC_ADDR_IN_SPIFLASH da850evm_direct_nor arm arm926ejs da8xxevm davincidavinci da850evm:MAC_ADDR_IN_SPIFLASH,USE_NOR,DIRECT_NOR_BOOT davinci_dm355evm arm arm926ejs dm355evm davincidavinci Applied to u-boot-ti/master, thanks! Blarg, I take it back. It's not applied as I see you didn't include a Signed-off-by line. Please incorporate the above change which is: Signed-off-by: Tom Rini tr...@ti.com and submit a v3, assuming the rules for a Signed-off-by-line are true. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm: pxa: Add support for ICP DAS LP-8x4x
LP-8x4x is a programmable automation controller by ICP DAS. It is shipped with outdated U-Boot v1.3.0 This patch adds enough supports to boot the board: - 128M of 128M SDRAM - 32M of 48M NOR Flash memory - 1 of 4 Serial console (PXA FFUART) - 1 of 2 Ethernet controller (DM9000) Signed-off-by: Sergey Yanovich ynv...@gmail.com --- arch/arm/include/asm/mach-types.h | 13 ++ board/icpdas/lp8x4x/Makefile | 41 ++ board/icpdas/lp8x4x/lp8x4x.c | 133 ++ boards.cfg|1 + include/configs/lp8x4x.h | 272 + 5 files changed, 460 insertions(+) create mode 100644 board/icpdas/lp8x4x/Makefile create mode 100644 board/icpdas/lp8x4x/lp8x4x.c create mode 100644 include/configs/lp8x4x.h diff --git a/arch/arm/include/asm/mach-types.h b/arch/arm/include/asm/mach-types.h index a676b6d..644b937 100644 --- a/arch/arm/include/asm/mach-types.h +++ b/arch/arm/include/asm/mach-types.h @@ -1107,6 +1107,7 @@ extern unsigned int __machine_arch_type; #define MACH_TYPE_OMAP5_SEVM 3777 #define MACH_TYPE_ARMADILLO_800EVA 3863 #define MACH_TYPE_KZM9G4140 +#define MACH_TYPE_LP8X4X 4539 #ifdef CONFIG_ARCH_EBSA110 # ifdef machine_arch_type @@ -14248,6 +14249,18 @@ extern unsigned int __machine_arch_type; # define machine_is_kzm9g()(0) #endif +#ifdef CONFIG_MACH_LP8X4X +# ifdef machine_arch_type +# undef machine_arch_type +# define machine_arch_type __machine_arch_type +# else +# define machine_arch_type MACH_TYPE_LP8X4X +# endif +# define machine_is_lp8x4x() (machine_arch_type == MACH_TYPE_LP8X4X) +#else +# define machine_is_lp8x4x() (0) +#endif + /* * These have not yet been registered */ diff --git a/board/icpdas/lp8x4x/Makefile b/board/icpdas/lp8x4x/Makefile new file mode 100644 index 000..cbe6aa9 --- /dev/null +++ b/board/icpdas/lp8x4x/Makefile @@ -0,0 +1,41 @@ +# +# ICPDAS LP-8x4x Support +# +# Copyright (C) 2013 Sergey Yanovich ynv...@gmail.com +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).o + +COBJS := lp8x4x.o + +SRCS := $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) + +$(LIB):$(obj).depend $(OBJS) + $(call cmd_link_o_target, $(OBJS)) + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/icpdas/lp8x4x/lp8x4x.c b/board/icpdas/lp8x4x/lp8x4x.c new file mode 100644 index 000..abdb84a --- /dev/null +++ b/board/icpdas/lp8x4x/lp8x4x.c @@ -0,0 +1,133 @@ +/* + * ICP DAS LP-8x4x Support + * + * Copyright (C) 2010 Marek Vasut marek.va...@gmail.com + * adapted from Voipac PXA270 Support by + * Copyright (C) 2013 Sergey Yanovich ynv...@gmail.com + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +#include common.h +#include asm/arch/hardware.h +#include asm/arch/regs-mmc.h +#include asm/arch/pxa.h +#include netdev.h +#include serial.h +#include asm/io.h + +DECLARE_GLOBAL_DATA_PTR; + +/* + * Miscelaneous platform dependent initialisations + */ +int board_init(void) +{ + /* We have RAM, disable cache */ + dcache_disable(); + icache_disable(); + + /* memory and cpu-speed are setup before relocation */ + /* so we do _nothing_ here */ + + /* Arch number of lp8x4x */ + gd-bd-bi_arch_number = MACH_TYPE_LP8X4X; + + /* adress of boot parameters */ + gd-bd-bi_boot_params = 0xa100; +
Re: [U-Boot] [PATCH] usb: Add new command to set USB 2.0 port test modes
On Fri, Feb 15, 2013 at 05:52:45PM -0800, Julius Werner wrote: This patch adds a new 'usb test' command, that will set a port to a USB 2.0 test mode (see USB 2.0 spec 7.1.20). It supports all five test modes on both downstream hub ports and ordinary device's upstream ports. In addition, it supports EHCI root hub ports. The command is guarded by the CONFIG_CMD_USB_TEST ifdef (disabled by default). Signed-off-by: Julius Werner jwer...@chromium.org We need to enable this on some target as well or we're adding dead code. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/p1022ds: Add support for NAND and NAND boot using SPL
On Fri, Feb 15, 2013 at 6:34 PM, Scott Wood scottw...@freescale.com wrote: On 02/14/2013 03:35:13 PM, Matthew McClintock wrote: +#if defined(CONFIG_SYS_BR2_PRELIM) defined(CONFIG_SYS_OR2_PRELIM) + /* for FPGA */ + set_lbc_br(2, CONFIG_SYS_BR2_PRELIM); + set_lbc_or(2, CONFIG_SYS_OR2_PRELIM); +#else +#error CONFIG_SYS_BR2_PRELIM, CONFIG_SYS_OR2_PRELIM must be defined +#endif As discussed internally, this if/else is pointless. In internal discussion, you said it was moot, and then you post it again here? Because one of us was confused. At some point I switched over the thinking we were talking about the ifdefs in dui.c. But, this clears things up quite a bit - these ifdefs are not required and not sure why there were ever put there. diff --git a/drivers/video/Makefile b/drivers/video/Makefile index 170a358..a1c7895 100644 --- a/drivers/video/Makefile +++ b/drivers/video/Makefile @@ -34,7 +34,9 @@ COBJS-$(CONFIG_EXYNOS_FB) += exynos_fb.o exynos_fimd.o COBJS-$(CONFIG_EXYNOS_MIPI_DSIM) += exynos_mipi_dsi.o exynos_mipi_dsi_common.o \ exynos_mipi_dsi_lowlevel.o COBJS-$(CONFIG_EXYNOS_PWM_BL) += exynos_pwm_bl.o +ifndef CONFIG_SPL_BUILD COBJS-$(CONFIG_FSL_DIU_FB) += fsl_diu_fb.o videomodes.o +endif COBJS-$(CONFIG_S6E8AX0) += s6e8ax0.o COBJS-$(CONFIG_S6E63D6) += s6e63d6.o COBJS-$(CONFIG_LD9040) += ld9040.o I thought we discussed internally that you don't need this? Right, I tested without this but somehow lost the changes. Will fix in v2. +/* Nand Flash */ +#if defined(CONFIG_NAND_FSL_ELBC) !defined(CONFIG_FSL_DIU_FB) +#define CONFIG_SYS_NAND_BASE 0xff80 +#ifdef CONFIG_PHYS_64BIT +#define CONFIG_SYS_NAND_BASE_PHYS 0xfff80ull +#else +#define CONFIG_SYS_NAND_BASE_PHYS CONFIG_SYS_NAND_BASE +#endif CONFIG_FSL_DIU_FB is always defined, so when would we ever set CONFIG_SYS_NAND_BASE? +#define CONFIG_SYS_NAND_BASE_LIST { CONFIG_SYS_NAND_BASE, } ...and here you use it outside the ifdef. I think the only reason that this builds is that CONFIG_FSL_DIU_FB is defined *after* the above check. Why are you introducing a new ifdefs on CONFIG_FSL_DIU_FB here in the first place? Seems you are right about these bits. Not sure why this is or was ever written like this (for reference this is several internal patches squashed together). I'll remove the CONFIG_FSL_DIU_FB bits +#ifdef CONFIG_FSL_DIU_FB +#define CONFIG_SYS_BR1_PRELIM \ + (BR_PHYS_ADDR(0xe000) | BR_PS_16 | BR_V) +#define CONFIG_SYS_OR1_PRELIM (OR_AM_128MB | 0xff7) +#endif Here's another -- this one is dead code. What does this have to do with NAND at all? This should have been removed. It's since been fixed by Timur's other patch to keep the BR/OR set when using the DIU. @@ -177,6 +284,8 @@ #define PIXIS_LBMAP_SWITCH 7 #define PIXIS_LBMAP_MASK 0xF0 #define PIXIS_LBMAP_ALTBANK0x20 +#define PIXIS_SPD 0x07 +#define PIXIS_SPD_SYSCLK_MASK 0x07 #define PIXIS_ELBC_SPI_MASK0xc0 #define PIXIS_SPI 0x80 Relevance? The two new lines are used in spl_minimal.c when communicating with the PIXIS to determine what the bus_clk is for serial baud rate. -M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 13/19] Makefile: u-boot-with-spl.bin: Fix SPL padding
On 02/18/2013 12:52:51 PM, Benoît Thébaudeau wrote: On Monday, February 18, 2013 7:24:51 PM, Scott Wood wrote: On 02/18/2013 12:22:58 PM, Benoît Thébaudeau wrote: On Monday, February 18, 2013 7:02:49 PM, Scott Wood wrote: On 02/18/2013 12:00:52 PM, Benoît Thébaudeau wrote: The only question is if we may need to have an empty gap between the SPL and U-Boot within the resulting image. I don't think so since that would mean that the target memory device has an area that is not really available at the location of this gap. Why not allow that possibility? To save a config setting (there are already many for SPL) if this is not strictly required, but also for the reason below. Maybe it's easier for the SPL to load from a particular offset (e.g. NAND starting at the beginning of a block)? CONFIG_SPL_MAX_SIZE would be closer to a NAND mapping in that case (e.g. size of 1 NAND Flash block) than CONFIG_SPL_PAD_TO (address within RAM that should be considered relatively to CONFIG_SPL_TEXT_BASE to get the NAND offset). CONFIG_SPL_PAD_TO is for the placement of the payload Correct. -- and it's not a RAM address. It doesn't have to be, but it may be for some configs. Right. My point is it shouldn't be defined as a RAM address. Currently it is a link address (or zero if the linker script handles padding, or padding is not required for other reasons). Correct. With your patch it it is a file offset, IIUC. With my patch, it is nothing at all since only CONFIG_SPL_MAX_SIZE is used. Sorry, I just meant with your change to how objcopy is invoked. What you pass into objcopy is a file offset. CONFIG_SPL_MAX_SIZE is what it says -- the maximum size that the SPL may be, ideally to be enforced by the linker script. Correct. They are different. An SPL wanting the payload to begin as a block boundary does not mean the hardware is suddenly capable of loading an entire block of SPL. Sure, but my question is: Why would you want to have a 2-kiB SPL followed by a 126-kiB gap before the payload? Why couldn't you place the payload on the 1st page boundary after the SPL? You can, and we usually do. But size-limited SPLs may want to simplify (e.g. bad block detection needs some special logic to handle beginning inside a block), and it may not always be 126 KiB. E.g. MPC8313ERDB uses small-page NAND, so it's only 12KiB that gets wasted. It currently has MAX_SIZE of 4KiB but PAD_TO of base plus 16KiB. If there are hardware constraints or something that make CONFIG_SPL_PAD_TO useful in some cases, then let's use it, but otherwise, why keep it? It's easier to mainain orthogonality (and use defaults for simplicity) than to restore it after the fact if we need it later. And if we keep it, do we change it to an image offset, or do we keep it as a link address? Changing to an image offset sounds good. Also, CONFIG_SPL_PAD_TO and CONFIG_SPL_MAX_SIZE depend on each other: If both can be defined, you may change one forgetting the other one, which could e.g. result in an overlapping of SPL and U-Boot that won't show up at build time (with CONFIG_SPL_MAX_SIZE = 0x1000 and CONFIG_SPL_PAD_TO = CONFIG_SPL_TEXT_BASE + 0x800, the SPL would build fine, and objcopy wouldn't complain). So add a check that CONFIG_SPL_PAD_TO = CONFIG_SPL_MAX_SIZE (assuming the new interpretation of CONFIG_SPL_PAD_TO as a file offset), and let CONFIG_SPL_PAD_TO default to CONFIG_SPL_MAX_SIZE if not set. That would make sense. The current default value of 0 for CONFIG_SPL_PAD_TO does not make sense since it means that the SPL can't know where the payload is located within the image. CONFIG_SPL_PAD_TO is not the mechanism that is used for finding the payload. On mpc85xx it is unnecessary because the SPL will always be fixed size, because the reset vector goes at the end. It's also possible that some SPLs could use linker symbols to find the end of the SPL, if they want to pack more tightly. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] trying to understand u-boot-nand.ais file for AM1808 exp kit
On Mon, Feb 18, 2013 at 01:15:13PM -0500, Robert P. J. Day wrote: i hope someone here can clear up what should be a simple question -- i'm trying to figure out what exactly is going on when building and flashing a u-boot image for my new AM1808 experimenter kit or, more accurately, someone else's modified version where the 8M of NOR flash has been replaced with 2G of NAND flash. i've downloaded the DaVinci PSP SDK (v03.22.00.02) and i'm trying to figure out what the prebuilt u-boot images mean, and what it means to flash them. OK, for PSP related questions, please head to http://e2e.ti.com and poke the TI folks involved. That said, the da850_am18xxevm target in mainline works on the AM1808. The file board/davinci/da8xxevm/README.da850 documents the how and why and ought to be fine for NAND and was fine for SPI last time I had mine hooked up. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/p1022ds: Add support for NAND and NAND boot using SPL
On 02/18/2013 01:07:53 PM, Matthew McClintock wrote: @@ -118,6 +172,7 @@ * Localbus non-cacheable * 0xe000_ 0xe80f_ Promjet/free 128M non-cacheable * 0xe800_ 0xefff_ FLASH 128M non-cacheable + * 0xff80_ 0xff80_1fff NAND 8K non-cacheable * 0xffdf_ 0xffdf_7fff PIXIS 32K non-cacheable TLB0 * 0xffd0_ 0xffd0_3fff L1 for stack 16K Cacheable TLB0 * 0xffe0_ 0xffef_ CCSR 1M non-cacheable This says 8K... +/* NAND flash config */ +#define CONFIG_SYS_NAND_BR_PRELIM (BR_PHYS_ADDR(CONFIG_SYS_NAND_BASE_PHYS) \ + | (2BR_DECC_SHIFT)/* Use HW ECC */ \ + | BR_PS_8 /* Port Size = 8 bit */ \ + | BR_MS_FCM /* MSEL = FCM */ \ + | BR_V) /* valid */ +#define CONFIG_SYS_NAND_OR_PRELIM (OR_AM_256KB /* length 256K */ \ + | OR_FCM_PGS/* Large Page*/ \ + | OR_FCM_CSCT \ + | OR_FCM_CST \ + | OR_FCM_CHT \ + | OR_FCM_SCY_1 \ + | OR_FCM_TRLX \ + | OR_FCM_EHTR) ...this says 256K. IIRC the minimum for localbus is 32K. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 13/19] Makefile: u-boot-with-spl.bin: Fix SPL padding
Hi Scott, On Monday, February 18, 2013 8:11:22 PM, Scott Wood wrote: On 02/18/2013 12:52:51 PM, Benoît Thébaudeau wrote: On Monday, February 18, 2013 7:24:51 PM, Scott Wood wrote: On 02/18/2013 12:22:58 PM, Benoît Thébaudeau wrote: On Monday, February 18, 2013 7:02:49 PM, Scott Wood wrote: On 02/18/2013 12:00:52 PM, Benoît Thébaudeau wrote: The only question is if we may need to have an empty gap between the SPL and U-Boot within the resulting image. I don't think so since that would mean that the target memory device has an area that is not really available at the location of this gap. Why not allow that possibility? To save a config setting (there are already many for SPL) if this is not strictly required, but also for the reason below. Maybe it's easier for the SPL to load from a particular offset (e.g. NAND starting at the beginning of a block)? CONFIG_SPL_MAX_SIZE would be closer to a NAND mapping in that case (e.g. size of 1 NAND Flash block) than CONFIG_SPL_PAD_TO (address within RAM that should be considered relatively to CONFIG_SPL_TEXT_BASE to get the NAND offset). CONFIG_SPL_PAD_TO is for the placement of the payload Correct. -- and it's not a RAM address. It doesn't have to be, but it may be for some configs. Right. My point is it shouldn't be defined as a RAM address. Currently it is a link address (or zero if the linker script handles padding, or padding is not required for other reasons). Correct. With your patch it it is a file offset, IIUC. With my patch, it is nothing at all since only CONFIG_SPL_MAX_SIZE is used. Sorry, I just meant with your change to how objcopy is invoked. What you pass into objcopy is a file offset. CONFIG_SPL_MAX_SIZE is what it says -- the maximum size that the SPL may be, ideally to be enforced by the linker script. Correct. They are different. An SPL wanting the payload to begin as a block boundary does not mean the hardware is suddenly capable of loading an entire block of SPL. Sure, but my question is: Why would you want to have a 2-kiB SPL followed by a 126-kiB gap before the payload? Why couldn't you place the payload on the 1st page boundary after the SPL? You can, and we usually do. But size-limited SPLs may want to simplify (e.g. bad block detection needs some special logic to handle beginning inside a block), and it may not always be 126 KiB. E.g. MPC8313ERDB uses small-page NAND, so it's only 12KiB that gets wasted. It currently has MAX_SIZE of 4KiB but PAD_TO of base plus 16KiB. If there are hardware constraints or something that make CONFIG_SPL_PAD_TO useful in some cases, then let's use it, but otherwise, why keep it? It's easier to mainain orthogonality (and use defaults for simplicity) than to restore it after the fact if we need it later. And if we keep it, do we change it to an image offset, or do we keep it as a link address? Changing to an image offset sounds good. Also, CONFIG_SPL_PAD_TO and CONFIG_SPL_MAX_SIZE depend on each other: If both can be defined, you may change one forgetting the other one, which could e.g. result in an overlapping of SPL and U-Boot that won't show up at build time (with CONFIG_SPL_MAX_SIZE = 0x1000 and CONFIG_SPL_PAD_TO = CONFIG_SPL_TEXT_BASE + 0x800, the SPL would build fine, and objcopy wouldn't complain). So add a check that CONFIG_SPL_PAD_TO = CONFIG_SPL_MAX_SIZE (assuming the new interpretation of CONFIG_SPL_PAD_TO as a file offset), and let CONFIG_SPL_PAD_TO default to CONFIG_SPL_MAX_SIZE if not set. That would make sense. The current default value of 0 for CONFIG_SPL_PAD_TO does not make sense since it means that the SPL can't know where the payload is located within the image. CONFIG_SPL_PAD_TO is not the mechanism that is used for finding the payload. On mpc85xx it is unnecessary because the SPL will always be fixed size, because the reset vector goes at the end. It's also possible that some SPLs could use linker symbols to find the end of the SPL, if they want to pack more tightly. Thanks for all the clarifications. So I will make a v8 with CONFIG_SPL_PAD_TO as an image offset, and use it to generate u-boot-with-spl.bin. But first, I will wait for more feedback on v7 (Fabio should give his test results this week), and for Stefano to re-sync u-boot-imx/master with u-boot/master. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/p1022ds: Add support for NAND and NAND boot using SPL
Add defines needed to access NAND, remove second flash bank that is actually connected to NAND. Add nand booting support for P1022DS with hardcoded DDR config using SPL framework from 2011 Signed-off-by: Matthew McClintock m...@freescale.com Signed-off-by: Jerry Huang chang-ming.hu...@freescale.com Signed-off-by: Jiang Yutang b14...@freescale.com Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- v2: - remove unneeded changes to drivers/video/Makefile - remove unneeded preprocessor usage around setting OR2/BR2 - remove stale code that is now addressed by another DIU fix board/freescale/common/Makefile |6 ++ board/freescale/p1022ds/Makefile | 14 board/freescale/p1022ds/law.c |1 + board/freescale/p1022ds/spl_minimal.c | 129 board/freescale/p1022ds/tlb.c | 20 +++-- boards.cfg|2 + include/configs/P1022DS.h | 132 + 7 files changed, 284 insertions(+), 20 deletions(-) create mode 100644 board/freescale/p1022ds/spl_minimal.c diff --git a/board/freescale/common/Makefile b/board/freescale/common/Makefile index 75725b4..72bb56c 100644 --- a/board/freescale/common/Makefile +++ b/board/freescale/common/Makefile @@ -33,10 +33,14 @@ COBJS-$(CONFIG_FSL_CADMUS) += cadmus.o COBJS-$(CONFIG_FSL_VIA)+= cds_via.o COBJS-$(CONFIG_FMAN_ENET) += fman.o COBJS-$(CONFIG_FSL_PIXIS) += pixis.o +ifndef CONFIG_SPL_BUILD COBJS-$(CONFIG_FSL_NGPIXIS)+= ngpixis.o +endif COBJS-$(CONFIG_FSL_QIXIS) += qixis.o COBJS-$(CONFIG_PQ_MDS_PIB) += pq-mds-pib.o +ifndef CONFIG_SPL_BUILD COBJS-$(CONFIG_ID_EEPROM) += sys_eeprom.o +endif COBJS-$(CONFIG_FSL_SGMII_RISER)+= sgmii_riser.o ifndef CONFIG_RAMBOOT_PBL COBJS-$(CONFIG_FSL_FIXED_MMC_LOCATION) += sdhc_boot.o @@ -48,7 +52,9 @@ COBJS-$(CONFIG_MPC8555CDS)+= cds_pci_ft.o COBJS-$(CONFIG_MPC8536DS) += ics307_clk.o COBJS-$(CONFIG_MPC8572DS) += ics307_clk.o +ifndef CONFIG_SPL_BUILD COBJS-$(CONFIG_P1022DS)+= ics307_clk.o +endif COBJS-$(CONFIG_P2020DS)+= ics307_clk.o COBJS-$(CONFIG_P3041DS)+= ics307_clk.o COBJS-$(CONFIG_P4080DS)+= ics307_clk.o diff --git a/board/freescale/p1022ds/Makefile b/board/freescale/p1022ds/Makefile index c6d3418..0eeef05 100644 --- a/board/freescale/p1022ds/Makefile +++ b/board/freescale/p1022ds/Makefile @@ -11,12 +11,26 @@ include $(TOPDIR)/config.mk LIB= $(obj)lib$(BOARD).o +MINIMAL= + +ifdef CONFIG_SPL_BUILD +ifdef CONFIG_SPL_INIT_MINIMAL +MINIMAL=y +endif +endif + +ifdef MINIMAL + +COBJS-y+= spl_minimal.o tlb.o law.o + +else COBJS-y+= $(BOARD).o COBJS-y+= ddr.o COBJS-y+= law.o COBJS-y+= tlb.o COBJS-$(CONFIG_FSL_DIU_FB) += diu.o +endif SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c) OBJS := $(addprefix $(obj),$(COBJS-y)) diff --git a/board/freescale/p1022ds/law.c b/board/freescale/p1022ds/law.c index b23b8f9..feee799 100644 --- a/board/freescale/p1022ds/law.c +++ b/board/freescale/p1022ds/law.c @@ -16,6 +16,7 @@ struct law_entry law_table[] = { SET_LAW(CONFIG_SYS_FLASH_BASE_PHYS, LAW_SIZE_256M, LAW_TRGT_IF_LBC), SET_LAW(PIXIS_BASE_PHYS, LAW_SIZE_4K, LAW_TRGT_IF_LBC), + SET_LAW(CONFIG_SYS_NAND_BASE_PHYS, LAW_SIZE_8K, LAW_TRGT_IF_LBC), }; int num_law_entries = ARRAY_SIZE(law_table); diff --git a/board/freescale/p1022ds/spl_minimal.c b/board/freescale/p1022ds/spl_minimal.c new file mode 100644 index 000..8d12fa6 --- /dev/null +++ b/board/freescale/p1022ds/spl_minimal.c @@ -0,0 +1,129 @@ +/* + * Copyright 2011 Freescale Semiconductor, Inc. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + * + */ + +#include common.h +#include ns16550.h +#include asm/io.h +#include nand.h +#include asm/fsl_law.h +#include asm/fsl_ddr_sdram.h + + +/* + * Fixed sdram init -- doesn't use serial presence detect. + */ +void sdram_init(void) +{ + volatile ccsr_ddr_t *ddr = (ccsr_ddr_t *)CONFIG_SYS_MPC8xxx_DDR_ADDR; + + __raw_writel(CONFIG_SYS_DDR_CS0_BNDS, ddr-cs0_bnds); + __raw_writel(CONFIG_SYS_DDR_CS0_CONFIG, ddr-cs0_config); +#if CONFIG_CHIP_SELECTS_PER_CTRL 1 + __raw_writel(CONFIG_SYS_DDR_CS1_BNDS,
Re: [U-Boot] [RFC PATCH] Provide a mechanism to avoid using #ifdef everywhere
Dear Simon, In message 1361207920-24983-1-git-send-email-...@chromium.org you wrote: Many parts of the U-Boot code base are sprinkled with #ifdefs. This makes different boards compile different versions of the source code, meaning that we must build all boards to check for failures. It is easy to misspell ... +# Create a C header file where every '#define CONFIG_XXX value' becomes +# '#define config_xxx() value', or '#define config_xxx() 0' where the CONFIG +# is not used by this board configuration. This allows C code to do things +# like 'if (config_xxx())' and have the compiler remove the dead code, +# instead of using '#ifdef CONFIG_XXX...#endif'. Note that in most cases +# if the config_...() returns 0 then the option is not enabled. In some rare +# cases such as CONFIG_BOOTDELAY, the config can be enabled but still have a +# a value of 0. So in addition we a #define config_xxx_enabled(), setting the +# value to 0 if the option is disabled, 1 if enabled. This last feature will +# hopefully be deprecated soon. I think config_* is not a good name to use here - it has never been a reserved prefix so far, so it is IMO a bad idea to turn it into one now . We already have quite a number such variable names in the code all over the place (not sure I caught them all): config_2config_io_ctrl config_8260_ioports config_kbc_gpio config_8560_ioports config_list config_address config_list_t config_backside_crossbar_muxconfig_mpc8xx_ioports config_base config_nfc_clk config_bit config_node config_buf config_on_ebc_cs4_is_small_flash config_byte config_pci_bridge config_change config_periph_clk config_clockconfig_pin config_cmd_ctrl config_pll_clk config_core_clk config_qe_ioports config_data config_reg config_data_eye_leveling_samplesconfig_reg_helper config_ddr config_s config_ddr_clk config_sdram config_ddr_data config_select_P config_ddr_phy config_selection config_desc config_selection_t config_device config_status config_fifo config_table config_file_sizeconfig_val config_frontside_crossbar_vsc3316 config_val_P config_genmii_advertconfig_validity config_hub_port config_validity_t config_id config_vtp config_instance +The compiler will see that config_xxx() evalutes to a constant and will +eliminate the dead code. The resulting code (and code size) is the same. Did you measure the impact on compile time? +This takes care of almost all CONFIG macros. Unfortunately there are a few +cases where a value of 0 does not mean the option is disabled. For example +CONFIG_BOOTDELAY can be defined to 0, which means that the bootdelay +code should be used, but with a value of 0. To get around this and other +sticky cases, an addition macro with an '_enabled' suffix is provided, where +the value is always either 0 or 1: + + // Will work even if boaard config has '#define CONFIG_BOOTDELAY 0' + if (config_bootdelay_enabled()) + do_something; + +(Probably such config options should be deprecated and then we can remove +this feature) These are perfectly valid cases, I think - there are quite a number of these, including defines for console index, PHY address, etc. etc. --- a/common/cmd_fitupd.c +++ b/common/cmd_fitupd.c @@ -8,6 +8,7 @@ #include common.h #include command.h +#include net.h #if !defined(CONFIG_UPDATE_TFTP) #error CONFIG_UPDATE_TFTP required This seems to be an unrelated change? diff --git a/common/main.c b/common/main.c index e2d2e09..cd42b67 100644 --- a/common/main.c +++ b/common/main.c ... -#include malloc.h /* for free() prototype */ ... +#include malloc.h Why dropping the comment? -#undef DEBUG_PARSER +#define DEBUG_PARSER 0 /* set to 1 to debug */ + + +#define debug_parser(fmt, args...) \ + debug_cond(DEBUG_PARSER, fmt, ##args) + +#ifndef DEBUG_BOOTKEYS +#define DEBUG_BOOTKEYS 0 +#endif +#define debug_bootkeys(fmt, args...) \ + debug_cond(DEBUG_BOOTKEYS, fmt, ##args) This is also a different type of changes. Please keep such separate. -#ifndef CONFIG_ZERO_BOOTDELAY_CHECK - if (bootdelay == 0) + if (config_zero_bootdelay_check() bootdelay == 0) This appears to be plain wrong. That was a #ifndef before... + if (config_autoboot_delay_str() delaykey[0].str == NULL) + delaykey[0].str = config_autoboot_delay_str(); Hm constructs like these make me think about side effects. As is, your implementation
Re: [U-Boot] [PATCH] powerpc/p1022ds: Add support for NAND and NAND boot using SPL
On Mon, Feb 18, 2013 at 1:18 PM, Scott Wood scottw...@freescale.com wrote: On 02/18/2013 01:07:53 PM, Matthew McClintock wrote: @@ -118,6 +172,7 @@ * Localbus non-cacheable * 0xe000_ 0xe80f_ Promjet/free128M non-cacheable * 0xe800_ 0xefff_ FLASH 128M non-cacheable + * 0xff80_ 0xff80_1fff NAND8K non-cacheable * 0xffdf_ 0xffdf_7fff PIXIS 32K non-cacheable TLB0 * 0xffd0_ 0xffd0_3fff L1 for stack16K Cacheable TLB0 * 0xffe0_ 0xffef_ CCSR1M non-cacheable This says 8K... +/* NAND flash config */ +#define CONFIG_SYS_NAND_BR_PRELIM (BR_PHYS_ADDR(CONFIG_SYS_NAND_BASE_PHYS) \ + | (2BR_DECC_SHIFT)/* Use HW ECC */ \ + | BR_PS_8 /* Port Size = 8 bit */ \ + | BR_MS_FCM /* MSEL = FCM */ \ + | BR_V) /* valid */ +#define CONFIG_SYS_NAND_OR_PRELIM (OR_AM_256KB /* length 256K */ \ + | OR_FCM_PGS/* Large Page*/ \ + | OR_FCM_CSCT \ + | OR_FCM_CST \ + | OR_FCM_CHT \ + | OR_FCM_SCY_1 \ + | OR_FCM_TRLX \ + | OR_FCM_EHTR) ...this says 256K. IIRC the minimum for localbus is 32K. And the law is 8K and TLB is 16K - should I go with 32K for everything? However, I don't think 32K TLB works on this part. -M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/p1022ds: Add support for NAND and NAND boot using SPL
On 02/18/2013 01:24:44 PM, McClintock Matthew-B29882 wrote: On Mon, Feb 18, 2013 at 1:18 PM, Scott Wood scottw...@freescale.com wrote: On 02/18/2013 01:07:53 PM, Matthew McClintock wrote: @@ -118,6 +172,7 @@ * Localbus non-cacheable * 0xe000_ 0xe80f_ Promjet/free128M non-cacheable * 0xe800_ 0xefff_ FLASH 128M non-cacheable + * 0xff80_ 0xff80_1fff NAND8K non-cacheable * 0xffdf_ 0xffdf_7fff PIXIS 32K non-cacheable TLB0 * 0xffd0_ 0xffd0_3fff L1 for stack16K Cacheable TLB0 * 0xffe0_ 0xffef_ CCSR1M non-cacheable This says 8K... +/* NAND flash config */ +#define CONFIG_SYS_NAND_BR_PRELIM (BR_PHYS_ADDR(CONFIG_SYS_NAND_BASE_PHYS) \ + | (2BR_DECC_SHIFT)/* Use HW ECC */ \ + | BR_PS_8 /* Port Size = 8 bit */ \ + | BR_MS_FCM /* MSEL = FCM */ \ + | BR_V) /* valid */ +#define CONFIG_SYS_NAND_OR_PRELIM (OR_AM_256KB /* length 256K */ \ + | OR_FCM_PGS/* Large Page*/ \ + | OR_FCM_CSCT \ + | OR_FCM_CST \ + | OR_FCM_CHT \ + | OR_FCM_SCY_1 \ + | OR_FCM_TRLX \ + | OR_FCM_EHTR) ...this says 256K. IIRC the minimum for localbus is 32K. And the law is 8K and TLB is 16K - should I go with 32K for everything? However, I don't think 32K TLB works on this part. You don't need to create a 32K TLB, but the documented address map should agree with what you put in the actual hardware (and LAWs should agree with ORn/BRn). -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 13/19] Makefile: u-boot-with-spl.bin: Fix SPL padding
On 02/17/2013 10:16:49 AM, Benoît Thébaudeau wrote: Hi Poonam, Andy, On Friday, February 15, 2013 9:54:19 PM, Benoît Thébaudeau wrote: PAD_TO is not a generic SPL configuration option, so use CONFIG_SPL_MAX_SIZE instead. We want to use --pad-to with a size, but this option expects an address, so use u-boot-spl.bin instead of u-boot-spl as the input file in order to get addresses starting at 0. Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com --- Changes in v7: - Use u-boot-spl.bin instead of u-boot-spl in order to avoid having to use --change-addresses. Changes in v6: - Fix size passed to --pad-to thanks to --change-addresses. Changes in v5: None Changes in v4: - New patch. Changes in v3: None Changes in v2: None Makefile |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index a8c7b7b..317dffc 100644 --- a/Makefile +++ b/Makefile @@ -486,7 +486,8 @@ $(obj)u-boot.dis: $(obj)u-boot $(OBJDUMP) -d $ $@ $(obj)u-boot-with-spl.bin: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin - $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(PAD_TO) -O binary $(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin + $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(CONFIG_SPL_MAX_SIZE) \ + -I binary -O binary $ $(obj)spl/u-boot-spl-pad.bin cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin $@ rm $(obj)spl/u-boot-spl-pad.bin I would like to let you know what is going on, and to get your feedback for this patch. include/configs/p1_p2_rdb_pc.h seems to be the only current user of u-boot-with-spl.bin, triggered for example by the P2020RDB-PC_NAND config. Before this patch, PAD_TO was used, but there is no such definition for this board for generic SPL, so this board seems broken, --pad-to= with no argument behaves the same as --pad-to=0, though since it's undocumented we now avoid relying on that behavior as you observed in a followup post. all the more none of the various values defined for CONFIG_SYS_TEXT_BASE relatively to CONFIG_SPL_TEXT_BASE would be compatible with an image built by appending U-Boot to the generic SPL. Can you confirm? I don't follow. CONFIG_SYS_TEXT_BASE is for where the payload gets loaded to, and has nothing to do with its position in the SPL-concat image, nor with the address that the SPL starts running at. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 13/19] Makefile: u-boot-with-spl.bin: Fix SPL padding
On Monday, February 18, 2013 8:37:29 PM, Scott Wood wrote: On 02/17/2013 10:16:49 AM, Benoît Thébaudeau wrote: Hi Poonam, Andy, On Friday, February 15, 2013 9:54:19 PM, Benoît Thébaudeau wrote: PAD_TO is not a generic SPL configuration option, so use CONFIG_SPL_MAX_SIZE instead. We want to use --pad-to with a size, but this option expects an address, so use u-boot-spl.bin instead of u-boot-spl as the input file in order to get addresses starting at 0. Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com --- Changes in v7: - Use u-boot-spl.bin instead of u-boot-spl in order to avoid having to use --change-addresses. Changes in v6: - Fix size passed to --pad-to thanks to --change-addresses. Changes in v5: None Changes in v4: - New patch. Changes in v3: None Changes in v2: None Makefile |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index a8c7b7b..317dffc 100644 --- a/Makefile +++ b/Makefile @@ -486,7 +486,8 @@ $(obj)u-boot.dis: $(obj)u-boot $(OBJDUMP) -d $ $@ $(obj)u-boot-with-spl.bin: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin - $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(PAD_TO) -O binary $(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin + $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(CONFIG_SPL_MAX_SIZE) \ + -I binary -O binary $ $(obj)spl/u-boot-spl-pad.bin cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin $@ rm $(obj)spl/u-boot-spl-pad.bin I would like to let you know what is going on, and to get your feedback for this patch. include/configs/p1_p2_rdb_pc.h seems to be the only current user of u-boot-with-spl.bin, triggered for example by the P2020RDB-PC_NAND config. Before this patch, PAD_TO was used, but there is no such definition for this board for generic SPL, so this board seems broken, --pad-to= with no argument behaves the same as --pad-to=0, though since it's undocumented we now avoid relying on that behavior as you observed in a followup post. OK. all the more none of the various values defined for CONFIG_SYS_TEXT_BASE relatively to CONFIG_SPL_TEXT_BASE would be compatible with an image built by appending U-Boot to the generic SPL. Can you confirm? I don't follow. CONFIG_SYS_TEXT_BASE is for where the payload gets loaded to, and has nothing to do with its position in the SPL-concat image, nor with the address that the SPL starts running at. Right, sorry, I meant CONFIG_SYS_NAND_U_BOOT_OFFS. It is 0, which is not compatible with the payload being appended to the SPL in the programmed image. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 13/19] Makefile: u-boot-with-spl.bin: Fix SPL padding
On 02/18/2013 01:52:10 PM, Benoît Thébaudeau wrote: On Monday, February 18, 2013 8:37:29 PM, Scott Wood wrote: On 02/17/2013 10:16:49 AM, Benoît Thébaudeau wrote: Before this patch, PAD_TO was used, but there is no such definition for this board for generic SPL, so this board seems broken, --pad-to= with no argument behaves the same as --pad-to=0, though since it's undocumented we now avoid relying on that behavior as you observed in a followup post. OK. all the more none of the various values defined for CONFIG_SYS_TEXT_BASE relatively to CONFIG_SPL_TEXT_BASE would be compatible with an image built by appending U-Boot to the generic SPL. Can you confirm? I don't follow. CONFIG_SYS_TEXT_BASE is for where the payload gets loaded to, and has nothing to do with its position in the SPL-concat image, nor with the address that the SPL starts running at. Right, sorry, I meant CONFIG_SYS_NAND_U_BOOT_OFFS. It is 0, which is not compatible with the payload being appended to the SPL in the programmed image. That just means we load the whole thing, including SPL, so that we're always loading from the start of the block. Note the difference between CONFIG_SYS_NAND_U_BOOT_DST and CONFIG_SYS_NAND_U_BOOT_START. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 13/19] Makefile: u-boot-with-spl.bin: Fix SPL padding
On Monday, February 18, 2013 8:47:28 PM, Scott Wood wrote: On 02/18/2013 01:52:10 PM, Benoît Thébaudeau wrote: On Monday, February 18, 2013 8:37:29 PM, Scott Wood wrote: On 02/17/2013 10:16:49 AM, Benoît Thébaudeau wrote: Before this patch, PAD_TO was used, but there is no such definition for this board for generic SPL, so this board seems broken, --pad-to= with no argument behaves the same as --pad-to=0, though since it's undocumented we now avoid relying on that behavior as you observed in a followup post. OK. all the more none of the various values defined for CONFIG_SYS_TEXT_BASE relatively to CONFIG_SPL_TEXT_BASE would be compatible with an image built by appending U-Boot to the generic SPL. Can you confirm? I don't follow. CONFIG_SYS_TEXT_BASE is for where the payload gets loaded to, and has nothing to do with its position in the SPL-concat image, nor with the address that the SPL starts running at. Right, sorry, I meant CONFIG_SYS_NAND_U_BOOT_OFFS. It is 0, which is not compatible with the payload being appended to the SPL in the programmed image. That just means we load the whole thing, including SPL, so that we're always loading from the start of the block. Note the difference between CONFIG_SYS_NAND_U_BOOT_DST and CONFIG_SYS_NAND_U_BOOT_START. OK. Hmm, this difference is CONFIG_SPL_MAX_SIZE, but CONFIG_SPL_PAD_TO is not defined, so the payload is right after the SPL in the image and the SPL jumps to somewhere in the middle of the payload? Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 13/19] Makefile: u-boot-with-spl.bin: Fix SPL padding
On 02/18/2013 02:01:59 PM, Benoît Thébaudeau wrote: On Monday, February 18, 2013 8:47:28 PM, Scott Wood wrote: On 02/18/2013 01:52:10 PM, Benoît Thébaudeau wrote: On Monday, February 18, 2013 8:37:29 PM, Scott Wood wrote: On 02/17/2013 10:16:49 AM, Benoît Thébaudeau wrote: all the more none of the various values defined for CONFIG_SYS_TEXT_BASE relatively to CONFIG_SPL_TEXT_BASE would be compatible with an image built by appending U-Boot to the generic SPL. Can you confirm? I don't follow. CONFIG_SYS_TEXT_BASE is for where the payload gets loaded to, and has nothing to do with its position in the SPL-concat image, nor with the address that the SPL starts running at. Right, sorry, I meant CONFIG_SYS_NAND_U_BOOT_OFFS. It is 0, which is not compatible with the payload being appended to the SPL in the programmed image. That just means we load the whole thing, including SPL, so that we're always loading from the start of the block. Note the difference between CONFIG_SYS_NAND_U_BOOT_DST and CONFIG_SYS_NAND_U_BOOT_START. OK. Hmm, this difference is CONFIG_SPL_MAX_SIZE, but CONFIG_SPL_PAD_TO is not defined, so the payload is right after the SPL in the image and the SPL jumps to somewhere in the middle of the payload? It jumps to the beginning of the payload. As mentioned elsewhere in the thread, mpc85xx NAND SPL is always fixed size (done in the linker script) because the reset vector comes at the end. Thus, max size equals actual size without needing --pad-to. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 13/19] Makefile: u-boot-with-spl.bin: Fix SPL padding
On Monday, February 18, 2013 9:06:30 PM, Scott Wood wrote: On 02/18/2013 02:01:59 PM, Benoît Thébaudeau wrote: On Monday, February 18, 2013 8:47:28 PM, Scott Wood wrote: On 02/18/2013 01:52:10 PM, Benoît Thébaudeau wrote: On Monday, February 18, 2013 8:37:29 PM, Scott Wood wrote: On 02/17/2013 10:16:49 AM, Benoît Thébaudeau wrote: all the more none of the various values defined for CONFIG_SYS_TEXT_BASE relatively to CONFIG_SPL_TEXT_BASE would be compatible with an image built by appending U-Boot to the generic SPL. Can you confirm? I don't follow. CONFIG_SYS_TEXT_BASE is for where the payload gets loaded to, and has nothing to do with its position in the SPL-concat image, nor with the address that the SPL starts running at. Right, sorry, I meant CONFIG_SYS_NAND_U_BOOT_OFFS. It is 0, which is not compatible with the payload being appended to the SPL in the programmed image. That just means we load the whole thing, including SPL, so that we're always loading from the start of the block. Note the difference between CONFIG_SYS_NAND_U_BOOT_DST and CONFIG_SYS_NAND_U_BOOT_START. OK. Hmm, this difference is CONFIG_SPL_MAX_SIZE, but CONFIG_SPL_PAD_TO is not defined, so the payload is right after the SPL in the image and the SPL jumps to somewhere in the middle of the payload? It jumps to the beginning of the payload. As mentioned elsewhere in the thread, mpc85xx NAND SPL is always fixed size (done in the linker script) because the reset vector comes at the end. Thus, max size equals actual size without needing --pad-to. OK, clear. Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 04/23] Introduce generic link section.h symbol files
On Fri, Feb 08, 2013 at 07:12:00AM -0800, Simon Glass wrote: We create a separate header file for link symbols defined by the link scripts. It is helpful to have these all in one place and try to make them common across architectures. Since Linux already has a similar file, we bring this in even though many of the symbols there are not relevant to us. Each architecture has its own asm/sections.h where symbols specifc to that architecture can be added. For now everything except AVR32 just includes the generic header. One change is needed in arch/avr32/lib/board.c to make this conversion work. Signed-off-by: Simon Glass s...@chromium.org Need to specify a tag/hash for where this came from in the kernel. Also, didn't you and Wolfgang agree to drop the CREDITS file bit from the boilerplate on new files? Reviewed-by: Tom Rini tr...@ti.com -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 03/23] Replace __bss_end__ with __bss_end
On Fri, Feb 08, 2013 at 07:11:59AM -0800, Simon Glass wrote: Note this is a tree-wide change affecting multiple architectures. At present we use __bss_start, but mostly __bss_end__. This seems inconsistent and in a number of places __bss_end is used instead. Change to use __bss_end for the BSS end symbol throughout U-Boot. This makes it possible to use the asm-generic/sections.h file on all archs. Signed-off-by: Simon Glass s...@chromium.org Reviewed-by: Tom Rini tr...@ti.com -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/p1022ds: Add support for NAND and NAND boot using SPL
Add defines needed to access NAND, remove second flash bank that is actually connected to NAND. Add nand booting support for P1022DS with hardcoded DDR config using SPL framework from 2011 Signed-off-by: Matthew McClintock m...@freescale.com Signed-off-by: Jerry Huang chang-ming.hu...@freescale.com Signed-off-by: Jiang Yutang b14...@freescale.com Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- v2: - remove unneeded changes to drivers/video/Makefile - remove unneeded preprocessor usage around setting OR2/BR2 - remove stale code that is now addressed by another DIU fix v3: - make law and localbus sizes consistent board/freescale/common/Makefile |6 ++ board/freescale/p1022ds/Makefile | 14 board/freescale/p1022ds/law.c |1 + board/freescale/p1022ds/spl_minimal.c | 129 board/freescale/p1022ds/tlb.c | 20 +++-- boards.cfg|2 + include/configs/P1022DS.h | 132 + 7 files changed, 284 insertions(+), 20 deletions(-) create mode 100644 board/freescale/p1022ds/spl_minimal.c diff --git a/board/freescale/common/Makefile b/board/freescale/common/Makefile index 75725b4..72bb56c 100644 --- a/board/freescale/common/Makefile +++ b/board/freescale/common/Makefile @@ -33,10 +33,14 @@ COBJS-$(CONFIG_FSL_CADMUS) += cadmus.o COBJS-$(CONFIG_FSL_VIA)+= cds_via.o COBJS-$(CONFIG_FMAN_ENET) += fman.o COBJS-$(CONFIG_FSL_PIXIS) += pixis.o +ifndef CONFIG_SPL_BUILD COBJS-$(CONFIG_FSL_NGPIXIS)+= ngpixis.o +endif COBJS-$(CONFIG_FSL_QIXIS) += qixis.o COBJS-$(CONFIG_PQ_MDS_PIB) += pq-mds-pib.o +ifndef CONFIG_SPL_BUILD COBJS-$(CONFIG_ID_EEPROM) += sys_eeprom.o +endif COBJS-$(CONFIG_FSL_SGMII_RISER)+= sgmii_riser.o ifndef CONFIG_RAMBOOT_PBL COBJS-$(CONFIG_FSL_FIXED_MMC_LOCATION) += sdhc_boot.o @@ -48,7 +52,9 @@ COBJS-$(CONFIG_MPC8555CDS)+= cds_pci_ft.o COBJS-$(CONFIG_MPC8536DS) += ics307_clk.o COBJS-$(CONFIG_MPC8572DS) += ics307_clk.o +ifndef CONFIG_SPL_BUILD COBJS-$(CONFIG_P1022DS)+= ics307_clk.o +endif COBJS-$(CONFIG_P2020DS)+= ics307_clk.o COBJS-$(CONFIG_P3041DS)+= ics307_clk.o COBJS-$(CONFIG_P4080DS)+= ics307_clk.o diff --git a/board/freescale/p1022ds/Makefile b/board/freescale/p1022ds/Makefile index c6d3418..0eeef05 100644 --- a/board/freescale/p1022ds/Makefile +++ b/board/freescale/p1022ds/Makefile @@ -11,12 +11,26 @@ include $(TOPDIR)/config.mk LIB= $(obj)lib$(BOARD).o +MINIMAL= + +ifdef CONFIG_SPL_BUILD +ifdef CONFIG_SPL_INIT_MINIMAL +MINIMAL=y +endif +endif + +ifdef MINIMAL + +COBJS-y+= spl_minimal.o tlb.o law.o + +else COBJS-y+= $(BOARD).o COBJS-y+= ddr.o COBJS-y+= law.o COBJS-y+= tlb.o COBJS-$(CONFIG_FSL_DIU_FB) += diu.o +endif SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c) OBJS := $(addprefix $(obj),$(COBJS-y)) diff --git a/board/freescale/p1022ds/law.c b/board/freescale/p1022ds/law.c index b23b8f9..c4398dd 100644 --- a/board/freescale/p1022ds/law.c +++ b/board/freescale/p1022ds/law.c @@ -16,6 +16,7 @@ struct law_entry law_table[] = { SET_LAW(CONFIG_SYS_FLASH_BASE_PHYS, LAW_SIZE_256M, LAW_TRGT_IF_LBC), SET_LAW(PIXIS_BASE_PHYS, LAW_SIZE_4K, LAW_TRGT_IF_LBC), + SET_LAW(CONFIG_SYS_NAND_BASE_PHYS, LAW_SIZE_32K, LAW_TRGT_IF_LBC), }; int num_law_entries = ARRAY_SIZE(law_table); diff --git a/board/freescale/p1022ds/spl_minimal.c b/board/freescale/p1022ds/spl_minimal.c new file mode 100644 index 000..8d12fa6 --- /dev/null +++ b/board/freescale/p1022ds/spl_minimal.c @@ -0,0 +1,129 @@ +/* + * Copyright 2011 Freescale Semiconductor, Inc. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + * + */ + +#include common.h +#include ns16550.h +#include asm/io.h +#include nand.h +#include asm/fsl_law.h +#include asm/fsl_ddr_sdram.h + + +/* + * Fixed sdram init -- doesn't use serial presence detect. + */ +void sdram_init(void) +{ + volatile ccsr_ddr_t *ddr = (ccsr_ddr_t *)CONFIG_SYS_MPC8xxx_DDR_ADDR; + + __raw_writel(CONFIG_SYS_DDR_CS0_BNDS, ddr-cs0_bnds); + __raw_writel(CONFIG_SYS_DDR_CS0_CONFIG, ddr-cs0_config); +#if CONFIG_CHIP_SELECTS_PER_CTRL 1 +
Re: [U-Boot] [PATCH v7 16/19] arm926ejs: Remove deprecated and now unused NAND SPL
Hi Tom, On Monday, February 18, 2013 5:40:21 PM, Tom Rini wrote: On Sun, Feb 17, 2013 at 04:51:37PM +0100, Beno??t Th??baudeau wrote: Hi Albert, Tom, Zhong, On Friday, February 15, 2013 9:54:22 PM, Beno??t Th??baudeau wrote: Signed-off-by: Beno??t Th??baudeau benoit.thebaud...@advansee.com --- Changes in v7: None Changes in v6: - New patch. Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: None arch/arm/cpu/arm926ejs/start.S | 10 -- 1 file changed, 10 deletions(-) I would like to get your feedback regarding the status of the Samsung SMDK6400 board: - It is not in boards.cfg, so, according to commit 1285a28, support for it should already have been removed a long time ago. It also seems to be the only board remaining in the main Makefile. - It uses the deprecated NAND SPL. - MAKEALL does not test its build, which has been broken for a while. - If it were removed or fixed, ARM1176's start.S' relocate_code() could be made identical to all the other implementations of this function, so all this duplicated code could be moved to a common location like crt0.S. Besides that, it would be possible to completely get rid of the legacy NAND SPL on ARM. I have no intention of fixing this board, but dropping it and cleaning up ARM after that would be easy. I'm in favor of removing and updating README.scrapyard, baring quick attention from the maintainer to update it to not being using the Makefile and fix the rest of the breakage. OK. The s3c64xx SoC and all the drivers coming with it then become unused. Should this be removed too? There may be out-of-tree users of this SoC. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 16/19] arm926ejs: Remove deprecated and now unused NAND SPL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/18/2013 03:39 PM, Benoît Thébaudeau wrote: Hi Tom, On Monday, February 18, 2013 5:40:21 PM, Tom Rini wrote: On Sun, Feb 17, 2013 at 04:51:37PM +0100, Beno??t Th??baudeau wrote: Hi Albert, Tom, Zhong, On Friday, February 15, 2013 9:54:22 PM, Beno??t Th??baudeau wrote: Signed-off-by: Beno??t Th??baudeau benoit.thebaud...@advansee.com --- Changes in v7: None Changes in v6: - New patch. Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: None arch/arm/cpu/arm926ejs/start.S | 10 -- 1 file changed, 10 deletions(-) I would like to get your feedback regarding the status of the Samsung SMDK6400 board: - It is not in boards.cfg, so, according to commit 1285a28, support for it should already have been removed a long time ago. It also seems to be the only board remaining in the main Makefile. - It uses the deprecated NAND SPL. - MAKEALL does not test its build, which has been broken for a while. - If it were removed or fixed, ARM1176's start.S' relocate_code() could be made identical to all the other implementations of this function, so all this duplicated code could be moved to a common location like crt0.S. Besides that, it would be possible to completely get rid of the legacy NAND SPL on ARM. I have no intention of fixing this board, but dropping it and cleaning up ARM after that would be easy. I'm in favor of removing and updating README.scrapyard, baring quick attention from the maintainer to update it to not being using the Makefile and fix the rest of the breakage. OK. The s3c64xx SoC and all the drivers coming with it then become unused. Should this be removed too? There may be out-of-tree users of this SoC. Yes, it's what the scrapyard is for. If an out-of-tree user exists they can either support the reference board (and bring it back from the dead) or their own board. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRIpWVAAoJENk4IS6UOR1W8LoP/AjswbJBzJX2HkrQ2My5LSsk SIqktkdZw68IvwqYHWNzCYow/O693dV5l3Dz+KFKQXQ/Loz6wqTolrQSKrwl8CRq OLKLD6vcNI3Z+buNsV3Bq9+3XXM2d8T5o3U8TV3eLKzgVo6SnfsgaDEzTqs1LgvD A0tran0YMTPhTzcHDoB4SXutRFE+Hrv8rJaRjKzQL9118kGA21NRAz46HcB+FzRo idew5fkjo88PMoAdaKm9V0cMavH5AOAxuffUJTGSHCOZwq9MPJ4B+iWSitDKN8/I tu2cv7tCqv/MhCsJU9JVarco0I4t4sXcjPAWMqpg1vllBBgxazLGLfLlQ3B/cx0Q KEaAkn8iU7fxPt+FbIau/beMyi6E/PBLJ4PcTa2gLPEayRpiMBYG7VrwnIXahwuI RcFKCJLr2XN9aYgQSmXnL9/k8Tc9Hf6bYzamjA6/Zf27GcU0TipfSNRY4fgRuQno 5r8iWv6JCJEqWc0VQG/1Lqs/oRGQ9vl1py/zHQoCV5ChM+1G4XSU7eCeJZKRREE6 abKoVhj1BJ6THdtM+0B+cqVM+gr4uGN7+wqHCsNJibKgQl1HHXDps9v72q7vYjI+ bEAcqGMOpD1+RtHm6Xsjznmaj5REGgHUQ0eO1S898TdUQlML3AbkcgS0x83GHZHE ziLexJiV0qKbTG3O/d80 =tKpl -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 9/9] dfu: Support larger than memory transfers.
On Mon, Feb 18, 2013 at 11:01:42AM +0100, Lukasz Majewski wrote: Hi Tom, On Fri, Nov 30, 2012 at 08:01:12PM +0200, Pantelis Antoniou wrote: We didn't support upload/download larger than available memory. This is pretty bad when you have to update your root filesystem for example. This patch removes the limitation (and the crashes when you transfered any file larger than 4MB). On top of that reduces the huge dfu buffer from 4MB to just 64K, which was over the top. The sequence number is a 16 bit counter; make sure we handle rollover correctly. This fixes the wrong transfers for large ( 256MB) images. Also utilize a variable to handle initialization, so that we don't rely on just the counter sent by the host. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com To be clear, patches 1-8 are good and we should take, but this one means we can't use FAT/EXT* partitions without more work. I would suggest that we set this part aside for a moment and perhaps limit transfers that are larget than RAM to RAW only where we can write in chunks today. As fair as I remember, some additional work needs to be done with composite.c file (to remove nasty #ifdefs). There was a problem with newer version of dfu-utils (new handling of descriptors). I see you and Pantelis talking about if some changes were really needed in composite.c or not, but nothing about dfu-utils. Were you objecting to the composite.c changes because you didn't need them, or because they in turn broke trats (can I get one of these somewhere?) The only other unresolved thing was about board_usb_init() which I think was settled on trats needing to change behavior. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] Exynos5: Pinmux: Add fdt for pinmux
This patch adds fdt nodes for peripherals which require pin muxing and configuration. Device tree bindings for pinctrl are kept same as required for Linux. Existing pinmux code modified to retrieve gpio range and function related info from fdt. Depends-on: [PATCH 0/3 V2] EXYNOS5: Add GPIO numbering feature URL: http://lists.denx.de/pipermail/u-boot/2013-January/144681.html Signed-off-by: Akshay Saraswat aksha...@samsung.com --- Changes since v1: - Device tree bindings changed to linux style. - Added documentation for samsung pinctrl. arch/arm/cpu/armv7/exynos/pinmux.c | 445 + arch/arm/dts/exynos5250-pinctrl.dtsi | 675 ++ arch/arm/dts/exynos5250.dtsi |1 + doc/device-tree-bindings/samsung-pinctrl.txt | 253 ++ include/fdtdec.h |1 + lib/fdtdec.c |1 + 6 files changed, 1280 insertions(+), 96 deletions(-) create mode 100644 arch/arm/dts/exynos5250-pinctrl.dtsi create mode 100644 doc/device-tree-bindings/samsung-pinctrl.txt diff --git a/arch/arm/cpu/armv7/exynos/pinmux.c b/arch/arm/cpu/armv7/exynos/pinmux.c index c79d58e..da59483 100644 --- a/arch/arm/cpu/armv7/exynos/pinmux.c +++ b/arch/arm/cpu/armv7/exynos/pinmux.c @@ -23,91 +23,302 @@ #include common.h #include fdtdec.h +#include linux/ctype.h #include asm/arch/gpio.h #include asm/arch/pinmux.h #include asm/arch/sromc.h -static void exynos5_uart_config(int peripheral) +DECLARE_GLOBAL_DATA_PTR; + +/* Struct for storing pin function and gpio related info */ +struct pin_group { + void *dev_name; + int npins; + int function; + enum exynos5_gpio_pin gpio[]; +}; + +static void get_pins(const struct fdt_property *fprop, struct pin_group *pgrp) +{ + int i; + + pgrp-npins = 0; + + for (i = 0; !(fprop-data[i] == (int)NULL + fprop-data[i-1] == (int)NULL); i += 7) { + int pin_bank = -1; + + if (strncmp(fprop-data + i, gpa0, 4) == 0) + pin_bank = GPIO_A00; + else if (strncmp(fprop-data + i, gpa1, 4) == 0) + pin_bank = GPIO_A10; + else if (strncmp(fprop-data + i, gpa2, 4) == 0) + pin_bank = GPIO_A20; + else if (strncmp(fprop-data + i, gpb0, 4) == 0) + pin_bank = GPIO_B00; + else if (strncmp(fprop-data + i, gpb1, 4) == 0) + pin_bank = GPIO_B10; + else if (strncmp(fprop-data + i, gpb2, 4) == 0) + pin_bank = GPIO_B20; + else if (strncmp(fprop-data + i, gpb3, 4) == 0) + pin_bank = GPIO_B30; + else if (strncmp(fprop-data + i, gpc0, 4) == 0) + pin_bank = GPIO_C00; + else if (strncmp(fprop-data + i, gpc1, 4) == 0) + pin_bank = GPIO_C10; + else if (strncmp(fprop-data + i, gpc2, 4) == 0) + pin_bank = GPIO_C20; + else if (strncmp(fprop-data + i, gpc3, 4) == 0) + pin_bank = GPIO_C30; + else if (strncmp(fprop-data + i, gpd0, 4) == 0) + pin_bank = GPIO_D00; + else if (strncmp(fprop-data + i, gpd1, 4) == 0) + pin_bank = GPIO_D10; + else if (strncmp(fprop-data + i, gpy0, 4) == 0) + pin_bank = GPIO_Y00; + else if (strncmp(fprop-data + i, gpy1, 4) == 0) + pin_bank = GPIO_Y10; + else if (strncmp(fprop-data + i, gpy2, 4) == 0) + pin_bank = GPIO_Y20; + else if (strncmp(fprop-data + i, gpy3, 4) == 0) + pin_bank = GPIO_Y30; + else if (strncmp(fprop-data + i, gpy4, 4) == 0) + pin_bank = GPIO_Y40; + else if (strncmp(fprop-data + i, gpy5, 4) == 0) + pin_bank = GPIO_Y50; + else if (strncmp(fprop-data + i, gpy6, 4) == 0) + pin_bank = GPIO_Y60; + else if (strncmp(fprop-data + i, gpc4, 4) == 0) + pin_bank = GPIO_C40; + else if (strncmp(fprop-data + i, gpx0, 4) == 0) + pin_bank = GPIO_X00; + else if (strncmp(fprop-data + i, gpx1, 4) == 0) + pin_bank = GPIO_X10; + else if (strncmp(fprop-data + i, gpx2, 4) == 0) + pin_bank = GPIO_X20; + else if (strncmp(fprop-data + i, gpx3, 4) == 0) + pin_bank = GPIO_X30; + else if (strncmp(fprop-data + i, gpe0, 4) == 0) + pin_bank = GPIO_E00; + else if (strncmp(fprop-data + i, gpe1, 4) == 0) + pin_bank = GPIO_E10; + else if
Re: [U-Boot] [RFC PATCH] Provide a mechanism to avoid using #ifdef everywhere
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/18/2013 02:23 PM, Wolfgang Denk wrote: Dear Simon, In message 1361207920-24983-1-git-send-email-...@chromium.org you wrote: Many parts of the U-Boot code base are sprinkled with #ifdefs. This makes different boards compile different versions of the source code, meaning that we must build all boards to check for failures. It is easy to misspell ... +# Create a C header file where every '#define CONFIG_XXX value' becomes +# '#define config_xxx() value', or '#define config_xxx() 0' where the CONFIG +# is not used by this board configuration. This allows C code to do things +# like 'if (config_xxx())' and have the compiler remove the dead code, +# instead of using '#ifdef CONFIG_XXX...#endif'. Note that in most cases +# if the config_...() returns 0 then the option is not enabled. In some rare +# cases such as CONFIG_BOOTDELAY, the config can be enabled but still have a +# a value of 0. So in addition we a #define config_xxx_enabled(), setting the +# value to 0 if the option is disabled, 1 if enabled. This last feature will +# hopefully be deprecated soon. I think config_* is not a good name to use here - it has never been a reserved prefix so far, so it is IMO a bad idea to turn it into one now . We already have quite a number such variable names in the code all over the place (not sure I caught them all): Indeed. It's not a good choice to suddenly reserve now either. build_has_xxx() ? I'm not sure. [snip] +The compiler will see that config_xxx() evalutes to a constant and will +eliminate the dead code. The resulting code (and code size) is the same. Did you measure the impact on compile time? Probably won't have a good handle on this without converting a whole build target's needs (just about). [snip] -#if defined CONFIG_ZERO_BOOTDELAY_CHECK /* * Check if key already pressed * Don't check if bootdelay 0 */ - if (bootdelay = 0) { +if (config_zero_bootdelay_check() bootdelay = 0) { if (tstc()) {/* we got a key press */ (void) getc(); /* consume input*/ puts (\b\b\b 0); abort = 1;/* don't auto boot */ } } -#endif I think code like this needs more careful editing. With the #ifdef, it was clear that the comment only applies if CONFIG_ZERO_BOOTDELAY_CHECK is defined, but now it suddenly becomes valid _always_, which is pretty much misleading to someone trying to understand this code. I think it would be necessary to rephrase the commend, and move it partially into the if() block. Exactly. This type of change will require a lot of re-commenting to make it clear what's going on now, and after the change even more-so. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRIp7WAAoJENk4IS6UOR1W1S0QAKzMt8KkcVdRTFElSjlze35P PxFkO/W8YchPkzwMdhpU4UxHNYoFziLk5pLfj8hhh9uyQ7Lp0I411PZtJ+mkt3I5 RQf8xPHF9PDN2w0ZsxYKd0JE9LgFB/b9EmOOpzxy7Bge3aEGrfnhqgjNgnPGgVgO eCcLGZLrGYlbcL9SOJNxBdFjgCxJvRfrNtsaLOJc5SveeqMNGISp6xc5WDWnmf1f JAHNg7d9ik5d782AC76jbNUVOIp+85N0dMjhCdLR4YZBdNTC5grAW6x7gEGj+vYZ xUE2/Y20FG1Ie3vQjbbW1gUhYtxCxjFLl+UkUOn5bf6F0eDgyUvaSt17nrO3GSbQ hgunWaw9fZoVKMhb1WNnRHmLU5gS9rVlYGGsGibiMs1VPuiYpTLM/kuxfVitxJO0 Ysgkyotgfj2RbnKuBCkMVmvxBzIC3S2bAtxY97TwVrpEh2ZB7r2YwEKak8WhVxyQ nMyMulgpZoMJLM3fJEcF/kQPIzsKtz1Fl/YQXGZlI2lQpohE03kAPVQDyVeTQpGA FzGOUwVZY4WbcKrpcCV4tJOEnHRVyDR8ntQx0udMjtChaLE40fAmmUlWmWrnE4yV SVBM+PS2d7NCXt85QpS0eMc/UdFI0v1i6R24KEHEfqQe1WEdQb1wC7XXYblutZ8z ySlnbeEMfeDg5i5FHX46 =CF0y -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 03/23] Replace __bss_end__ with __bss_end
On Mon, Feb 18, 2013 at 5:13 PM, Tom Rini tr...@ti.com wrote: On Fri, Feb 08, 2013 at 07:11:59AM -0800, Simon Glass wrote: Note this is a tree-wide change affecting multiple architectures. At present we use __bss_start, but mostly __bss_end__. This seems inconsistent and in a number of places __bss_end is used instead. Change to use __bss_end for the BSS end symbol throughout U-Boot. This makes it possible to use the asm-generic/sections.h file on all archs. Signed-off-by: Simon Glass s...@chromium.org Reviewed-by: Tom Rini tr...@ti.com The short commit log is wrong; it say's twice __bss_end. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] imx6, spl and falcon boot
Hi, On Mon, Feb 18, 2013 at 11:44:36AM -0700, Chaves, Kevin wrote : Ok is there documentation anywhere that can show the requirements for supporting SPL if I'd like to be able to implement it, same with falcon mode? I've already got support for nitrogen6x through another vendor but they won't support the spl. I'm taking a look at board/woodburn/woodburn.c to see what was done for another board that supports SPL. It just looks like void board_init_f(ulong dummy) needs to be implemented for the SPL. Someone recommend I look at another set of patch notes that have better docs, but I see it mostly has the falcon mode in it. http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/146987/focus=147040 i.Mx6 doen't really require an SPL as the romcode is already able to do quite a lot. If what your are looking for is booting directly your kernel, you can have a look at that bootloader (it is actually much less than that): https://github.com/alexandrebelloni/whoosh It supports sabrelite and sabresd, it should be quite fast to port to nitrogen6x. I can do it but I don't have access to the hardware...yet. Regards, -- Alexandre Belloni ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] imx6, spl and falcon boot
On Mon, Feb 18, 2013 at 6:36 PM, Alexandre Belloni alexandre.bell...@piout.net wrote: Hi, On Mon, Feb 18, 2013 at 11:44:36AM -0700, Chaves, Kevin wrote : Ok is there documentation anywhere that can show the requirements for supporting SPL if I'd like to be able to implement it, same with falcon mode? I've already got support for nitrogen6x through another vendor but they won't support the spl. I'm taking a look at board/woodburn/woodburn.c to see what was done for another board that supports SPL. It just looks like void board_init_f(ulong dummy) needs to be implemented for the SPL. Someone recommend I look at another set of patch notes that have better docs, but I see it mostly has the falcon mode in it. http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/146987/focus=147040 i.Mx6 doen't really require an SPL as the romcode is already able to do quite a lot. If what your are looking for is booting directly your kernel, you can have a look at that bootloader (it is actually much less than that): https://github.com/alexandrebelloni/whoosh It supports sabrelite and sabresd, it should be quite fast to port to nitrogen6x. I can do it but I don't have access to the hardware...yet. The point of using the Falcon mode here would be to allow boot onto interactive mode, when need, and boot fast by default. The whoosh goal is *very* nice but it is different. :-) -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] imx6, spl and falcon boot
This is almost exactly what we want to do, we just want to be able to hold a key down during the boot and switch it to a recovery settings with a different kernel/rfs, would this be supported as well? -Original Message- From: Alexandre Belloni [mailto:alexandre.bell...@piout.net] Sent: Monday, February 18, 2013 4:37 PM To: Chaves, Kevin Cc: Dirk Behme; u-boot@lists.denx.de Subject: Re: [U-Boot] imx6, spl and falcon boot Hi, On Mon, Feb 18, 2013 at 11:44:36AM -0700, Chaves, Kevin wrote : Ok is there documentation anywhere that can show the requirements for supporting SPL if I'd like to be able to implement it, same with falcon mode? I've already got support for nitrogen6x through another vendor but they won't support the spl. I'm taking a look at board/woodburn/woodburn.c to see what was done for another board that supports SPL. It just looks like void board_init_f(ulong dummy) needs to be implemented for the SPL. Someone recommend I look at another set of patch notes that have better docs, but I see it mostly has the falcon mode in it. http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/146987/focus=14 7040 i.Mx6 doen't really require an SPL as the romcode is already able to do quite a lot. If what your are looking for is booting directly your kernel, you can have a look at that bootloader (it is actually much less than that): https://github.com/alexandrebelloni/whoosh It supports sabrelite and sabresd, it should be quite fast to port to nitrogen6x. I can do it but I don't have access to the hardware...yet. Regards, -- Alexandre Belloni ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/20] common: Use new numeric setenv functions
On Wed, Dec 26, 2012 at 10:57:05AM -0800, Simon Glass wrote: Use setenv_ulong(), setenv_hex() and setenv_addr() in common/ Signed-off-by: Simon Glass s...@chromium.org [snip] diff --git a/common/cmd_fdos.c b/common/cmd_fdos.c index fbee861..5a35cc1 100644 --- a/common/cmd_fdos.c +++ b/common/cmd_fdos.c [snip] @@ -91,8 +90,7 @@ int do_fdosboot(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) } flush_cache (load_addr, size); -sprintf(buf, %x, size); -setenv(filesize, buf); + setenv_hex(filesize, size); Tab and space mixing in the function. I'll fix if git am --whitespace=fix doesn't spot and fix. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 13/20] drivers: Use new numeric setenv functions
On Wed, Dec 26, 2012 at 10:57:06AM -0800, Simon Glass wrote: Use setenv_ulong(), setenv_hex() and setenv_addr() in drivers/ Signed-off-by: Simon Glass s...@chromium.org --- fs/fs.c |4 +--- fs/ubifs/ubifs.c |4 +--- fs/ not drivers/ -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 16/20] Roll crc32 into hash infrastructure
On Mon, Feb 18, 2013 at 09:06:01AM -0800, Simon Glass wrote: Hi Wolfgang, On Mon, Feb 18, 2013 at 3:35 AM, Wolfgang Denk w...@denx.de wrote: Dear Tom, In message 51216721.1010...@ti.com you wrote: There's another thread I don't have yet (and I don't have this one in gmail yet even). But, I am OK with custodians using their repos, but not the master branch, for unrelated but otherwise good patches. I'm also fine with patchwork bundles. I suppose we could use the staging repository for these changes instead. What I mostly object about there is that these patches would go into mainline basicly unreviewed, as patch submission and pull request is all done from a single person, with no other feedback on the patches at all. And this affects a lot of common code... Actually, I see this change when pulling u-boot-x86.git/master: - bloat-o-meter u-boot-before u-boot What board is this please? Some specific notes here - I think it boils down to moving crc32 into the hash framework. This adds some overhead, but has a few benefits. So you're going to v2 this part? -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/20] Improvements to memory, hashing functions for sandbox
On Wed, Dec 26, 2012 at 10:56:53AM -0800, Simon Glass wrote: This series aims to get all the memory functions running correctly on sandbox. There was some discussion about this a while ago, and a commit was added to show a possible approach: 355a8357 sandbox: Change md command to use map_physmem This commit was subsequently reverted because it used map_physmem() instead of the NOP that most architectures need for the memory functions. This series introduces map_sysmem(), a NOP on all architectures except sandbox. It allows us to use a ram buffer to which all U-Boot addresses are relative. The memory commands (including hashing) are updated to use this so that sandbox can now use those commands. Half of the mtest code is behind #ifdefs and there is duplication of some functions in both versions of the memory test. Several patches here clean this up a bit and get it working on sandbox. The numeric setenv_ulong() function is a useful way of avoiding a 'char buf[17]; sprintf(buf, %ld, ...); setenv(..., buf)' sequence. There is also setenv_addr(). What is missing is setenv_hex() which sets a ulong in hex format. Add this function and then make use of it in the main places: common/ drivers/ and net/. The recently added and very basic hash instructure can help reduce code duplication in some cases. Redo the crc32 command to use this, and make it available through the 'hash' command. Also a few bugs were found in hashing with verify disabled - the arg count was not checked and a variable declaration was missing. To permit the memory tester to run on sandbox, we need ctrl-C to work. To achieve this, add a proper implementation of sandbox's tstc(), with a simple FIFO for character input. An os_usleep() is added to ensure that U-Boot does not consume infinite CPU when setting at the command prompt. With all of this it is possible to use the memory commands in sandbox, as well as crc32 and the other hashing commands. So, aside from a few posted comments: Reviewed-by: Tom Rini tr...@ti.com And pending the answer to if you plan to v2 the hash command part (and since everyone sets CONFIG_CMD_CRC32, we do want to be careful), I'm OK with applying this bundle. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-x86.git
On Sun, Feb 17, 2013 at 01:32:58PM -0800, Simon Glass wrote: Hi Wolfgang, On Sun, Feb 17, 2013 at 12:58 PM, Wolfgang Denk w...@denx.de wrote: Dear Simon Glass, In message capnjgz2p6sbdxiwxw2tecdjadmhkn5inbgrpzbtvwmqutyv...@mail.gmail.com you wrote: Hi Tom, This series includes the sandbox map_sysmem() feature, and gets the memory and hashing functions running on sandbox to allow testing/code coverage. I have run it through buildman and it seems clean, with the proviso that I don't have fully-working toolchains for all architectures. NAK. It is not correct to push changes that affect global code through a arch-specific custodian tree, especially if the submitter of the patche(es) is identical to the custodian of the very tree, and even more so if there have been not ANY independent Acked-by: or at least Tested-by: messages. This is NOT how the peer review process is supposed to work!! Especially as a custodian you must not do such things. OK, I was not quite sure what to do, so may have misunderstood Tom's instructions - there is a short thread here http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/153342 I have created a patchwork bundle instead. http://patchwork.ozlabs.org/bundle/sjg/sandbox-mem/ OK, I thought I said, but maybe I didn't, I'm OK with re-using the tree, but _not_ the master branch, u-boot-x86/sandbox would have been fine. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 07/10] usb: mxs: Adapt code for i.MX23 support
Dear Otavio Salvador, The i.MX23 just one USB port so we shouldn't mess up with PLL1CTRL and USB1 port when building for i.MX23. Signed-off-by: Otavio Salvador ota...@ossystems.com.br --- Changes in v4: - Rework soc_ehci_hcd_{enable,disable}_clock to mxs_ehci_hcd_clock (Fabio / Marek) Changes in v3: - Improve commit log - Move code to enable/disable clock to soc_ehci_hcd_{enable,disable}_clock - Proper use mx23 clock registers Changes in v2: - Avoid wrong clock setting in MX23 drivers/usb/host/ehci-mxs.c | 58 +++-- 1 file changed, 35 insertions(+), 23 deletions(-) diff --git a/drivers/usb/host/ehci-mxs.c b/drivers/usb/host/ehci-mxs.c index 5062af5..45333ce 100644 --- a/drivers/usb/host/ehci-mxs.c +++ b/drivers/usb/host/ehci-mxs.c @@ -23,7 +23,11 @@ #include asm/io.h #include asm/arch/regs-common.h #include asm/arch/regs-base.h +#if defined(CONFIG_MX23) +#include asm/arch/regs-clkctrl-mx23.h +#elif defined(CONFIG_MX28) #include asm/arch/regs-clkctrl-mx28.h +#endif This should be handled automatically in imx-regs.h no ? I believe all this regs- xxx.h crap should just be part of imx-regs.h and none of that should be here at all. #include asm/arch/regs-usb.h #include asm/arch/regs-usbphy.h @@ -50,10 +54,12 @@ int mxs_ehci_get_port(struct ehci_mxs *mxs_usb, int port) usb_base = MXS_USBCTRL0_BASE; phy_base = MXS_USBPHY0_BASE; break; +#ifdef CONFIG_MX28 case 1: usb_base = MXS_USBCTRL1_BASE; phy_base = MXS_USBPHY1_BASE; break; +#endif default: printf(CONFIG_EHCI_MXS_PORT (port = %d)\n, port); return -1; @@ -67,17 +73,40 @@ int mxs_ehci_get_port(struct ehci_mxs *mxs_usb, int port) /* This DIGCTL register ungates clock to USB */ #define HW_DIGCTL_CTRL 0x8001c000 #define HW_DIGCTL_CTRL_USB0_CLKGATE (1 2) +#ifdef CONFIG_MX28 #define HW_DIGCTL_CTRL_USB1_CLKGATE (1 16) +#endif -int ehci_hcd_init(int index, struct ehci_hccr **hccr, struct ehci_hcor **hcor) +static void mxs_ehci_hcd_clock(bool enable) I wonder if this shall not go to arch/arm.../mxs/clock.c ? I'd say, pass also int index argument and call it twice for mx28 and once for mx23. That'd align well with the multi-controller stuff. { - - int ret; - uint32_t usb_base, cap_base; struct mxs_register_32 *digctl_ctrl = (struct mxs_register_32 *)HW_DIGCTL_CTRL; struct mxs_clkctrl_regs *clkctrl_regs = (struct mxs_clkctrl_regs *)MXS_CLKCTRL_BASE; + uint32_t reg = HW_DIGCTL_CTRL_USB0_CLKGATE; + + writel(CLKCTRL_PLL0CTRL0_EN_USB_CLKS | CLKCTRL_PLL0CTRL0_POWER, +(enable ? clkctrl_regs-hw_clkctrl_pll0ctrl0_set : \ + clkctrl_regs-hw_clkctrl_pll0ctrl0_clr)); + +#ifdef CONFIG_MX28 + /* i.MX28 has two USB controllers */ + reg |= HW_DIGCTL_CTRL_USB1_CLKGATE; + + writel(CLKCTRL_PLL1CTRL0_EN_USB_CLKS | CLKCTRL_PLL1CTRL0_POWER, +(enable ? clkctrl_regs-hw_clkctrl_pll1ctrl0_set : \ + clkctrl_regs-hw_clkctrl_pll1ctrl0_clr)); +#endif + + /* Gate/gateoff the USB clock */ + writel(reg, (enable ? digctl_ctrl-reg_clr : \ + digctl_ctrl-reg_set)); Uh ... uh ... uh ... No, kill the ternary operators. Good old if (enable) else please. Something like (imprecise code warning): if (enable) reg_offset = offsetof(mxs_register32, set); else reg_offset = offsetof(mxs_register32, clk); do_all_the_stuff here, all writel(val, mxs_register32 + offset); like this example. +} + +int ehci_hcd_init(int index, struct ehci_hccr **hccr, struct ehci_hcor **hcor) +{ + int ret; + uint32_t usb_base, cap_base; ret = mxs_ehci_get_port(ehci_mxs, CONFIG_EHCI_MXS_PORT); if (ret) @@ -90,13 +119,7 @@ int ehci_hcd_init(int index, struct ehci_hccr **hccr, struct ehci_hcor **hcor) ehci_mxs.phy_regs-hw_usbphy_ctrl_clr); /* Enable USB clock */ - writel(CLKCTRL_PLL0CTRL0_EN_USB_CLKS | CLKCTRL_PLL0CTRL0_POWER, - clkctrl_regs-hw_clkctrl_pll0ctrl0_set); - writel(CLKCTRL_PLL1CTRL0_EN_USB_CLKS | CLKCTRL_PLL1CTRL0_POWER, - clkctrl_regs-hw_clkctrl_pll1ctrl0_set); - - writel(HW_DIGCTL_CTRL_USB0_CLKGATE | HW_DIGCTL_CTRL_USB1_CLKGATE, - digctl_ctrl-reg_clr); + mxs_ehci_hcd_clock(true); /* Start USB PHY */ writel(0, ehci_mxs.phy_regs-hw_usbphy_pwd); @@ -118,10 +141,6 @@ int ehci_hcd_stop(int index) { int ret; uint32_t usb_base, cap_base, tmp; - struct mxs_register_32 *digctl_ctrl = - (struct mxs_register_32 *)HW_DIGCTL_CTRL; - struct mxs_clkctrl_regs *clkctrl_regs = - (struct mxs_clkctrl_regs *)MXS_CLKCTRL_BASE; struct ehci_hccr *hccr; struct
Re: [U-Boot] [PATCH v4 4/4] Tegra: MMC: Add DT support to MMC driver for all T20 boards
On Thu, Feb 14, 2013 at 3:04 PM, Tom Warren twarren.nvi...@gmail.comwrote: tegra_mmc_init() now parses the DT info for bus width, WP/CD GPIOs, etc. Tested on Seaboard, fully functional. Tamonten boards (medcom-wide, plutux, and tec) use a different/new dtsi file w/common settings. Signed-off-by: Tom Warren twar...@nvidia.com Signed-off-by: Thierry Reding thierry.red...@avionic-design.de --- v2: - all boards now call tegra_mmc_init once, w/no params - count MMC controllers, not aliases - AD boards (medcom/plutux/tec) use common tegra20-tamonten.dtsi v3: - move any power init inside board's pin_mux_mmc function, and/or create pin_mux_mmc function if necessary. - move board_mmc_init out of each board file and into ../common/board.c v4: - remove #ifdef CONFIG_TEGRA_MMC from trimslice.c - fix minor whitespace issue in board/nvidia/common/board.c - remove marking of used node_list entries in MMC driver, not needed diff --git a/drivers/mmc/tegra_mmc.c b/drivers/mmc/tegra_mmc.c index d749ab0..918a98d 100644 --- a/drivers/mmc/tegra_mmc.c +++ b/drivers/mmc/tegra_mmc.c @@ -21,6 +21,7 @@ #include bouncebuf.h #include common.h +#include fdtdec.h #include asm/gpio.h #include asm/io.h #include asm/arch/clock.h @@ -28,54 +29,23 @@ #include asm/arch-tegra/tegra_mmc.h #include mmc.h -/* support 4 mmc hosts */ -struct mmc mmc_dev[4]; -struct mmc_host mmc_host[4]; +DECLARE_GLOBAL_DATA_PTR; +struct mmc mmc_dev[MAX_HOSTS]; +struct mmc_host mmc_host[MAX_HOSTS]; -/** - * Get the host address and peripheral ID for a device. Devices are numbered - * from 0 to 3. - * - * @param host Structure to fill in (base, reg, mmc_id) - * @param dev_indexDevice index (0-3) - */ -static void tegra_get_setup(struct mmc_host *host, int dev_index) -{ - debug(tegra_get_setup: dev_index = %d\n, dev_index); - - switch (dev_index) { - case 1: - host-base = TEGRA_SDMMC3_BASE; - host-mmc_id = PERIPH_ID_SDMMC3; - break; - case 2: - host-base = TEGRA_SDMMC2_BASE; - host-mmc_id = PERIPH_ID_SDMMC2; - break; - case 3: - host-base = TEGRA_SDMMC1_BASE; - host-mmc_id = PERIPH_ID_SDMMC1; - break; - case 0: - default: - host-base = TEGRA_SDMMC4_BASE; - host-mmc_id = PERIPH_ID_SDMMC4; - break; - } - - host-reg = (struct tegra_mmc *)host-base; -} +#ifndef CONFIG_OF_CONTROL +#error Please enable device tree support to use this driver +#endif static void mmc_prepare_data(struct mmc_host *host, struct mmc_data *data, struct bounce_buffer *bbstate) { unsigned char ctrl; - - debug(buf: %p (%p), data-blocks: %u, data-blocksize: %u\n, - bbstate-bounce_buffer, bbstate-user_buffer, data-blocks, - data-blocksize); + debug(%s: buf: %p (%p), data-blocks: %u, data-blocksize: %u\n, + __func__, bbstate-bounce_buffer, bbstate-user_buffer, + data-blocks, data-blocksize); This patch is FULL of these changes. It makes it almost impossible to identify the substantive changes to this code. In the future, please put changes to debug output in a separate patch, unless it directly applies to the relevant change. Also, I note that you didn't mention the fact that you reworked all the debug() calls to prefix with the function name in your patch description. +/* + * Process a list of nodes, adding them to our list of SDMMC ports. + * + * @param blob fdt blob + * @param node_list list of nodes to process (any =0 are ignored) + * @param count number of nodes to process + * @return 0 if ok, -1 on error + */ +static int process_nodes(const void *blob, int node_list[], int count) +{ + struct mmc_host *host; + int i, node; + + debug(%s: count = %d\n, __func__, count); + + /* build mmc_host[] for each controller */ + for (i = 0; i count; i++) { + node = node_list[i]; + if (node = 0) + continue; + + host = mmc_host[i]; + host-id = i; + + if (mmc_get_config(blob, node, host)) { + printf(%s: failed to decode dev %d\n, __func__, i); + return -1; + } + do_mmc_init(i); + } + return 0; +} + +void tegra_mmc_init(void) +{ + int node_list[MAX_HOSTS], count; + const void *blob = gd-fdt_blob; + debug(%s entry\n, __func__); + + count = fdtdec_find_aliases_for_id(blob, sdhci, + COMPAT_NVIDIA_TEGRA20_SDMMC, node_list, MAX_HOSTS); + debug(%s: count of sdhci nodes is %d\n, __func__, count); + + if (process_nodes(blob, node_list, count)) { +
Re: [U-Boot] [PATCH 16/20] Roll crc32 into hash infrastructure
Dear Simon, In message capnjgz09okkf0qtnifkorvg37nensnlfzylblp+4jt6u_l3...@mail.gmail.com you wrote: - bloat-o-meter u-boot-before u-boot What board is this please? That was TQM5200S This is the generic hashing command. What is happening here is that the crc32 command is getting a few more features, more like sha1sum. However, this might not be desriable - and in fact this patch changes the behaviour of the CRC storage and verify to support using an environment variable, and requiring * before the argument when an address is required! That needs to be fixed, at least. Indeed - such a change of user interface must not be done here (though it does make a lot of sense to use common code for this stuff). The intent is to try to unify the hashing/crc features into a single Understood and appreciayed. framework. If you enable only crc32 and nothing else then this has quite a cost (0.5KB at present). I think I can reduce this code by making the full features of hash.c only available when something more than just crc32 is enabled. However, it might involve some #ifdefs... Actually 0.5 k is quite heavy impact, so I guess the #ifdef's win... 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: w...@denx.de But the only way of discovering the limits of the possible is to venture a little way past them into the impossible. - _Profiles of the Future_ (1962; rev. 1973) ``Hazards of Prophecy: The Failure of Imagination'' ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 09/10] mx23_olinuxino: Enable USB support
On Sun, Feb 17, 2013 at 4:45 PM, Otavio Salvador ota...@ossystems.com.br wrote: +#ifdef CONFIG_CMD_USB + /* Enable LAN9512 */ + gpio_direction_output(MX23_PAD_GPMI_ALE__GPIO_0_17, 1); +#endif What about doing like we do with other imx devices and write something like: gpio_direction_output(MXS_GPIO_NR(0, 17), 1); ,where #define MXS_GPIO_NR(bank, nr) ((bank) * 32 + (nr)) This also aligns with the kernel style. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 03/23] Replace __bss_end__ with __bss_end
On Fri, Feb 8, 2013 at 9:11 AM, Simon Glass s...@chromium.org wrote: Note this is a tree-wide change affecting multiple architectures. At present we use __bss_start, but mostly __bss_end__. This seems inconsistent and in a number of places __bss_end is used instead. Change to use __bss_end for the BSS end symbol throughout U-Boot. This makes it possible to use the asm-generic/sections.h file on all archs. Signed-off-by: Simon Glass s...@chromium.org Builds for all 85xx, so: Acked-by: Andy Fleming aflem...@freescale.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-x86.git
On Mon, Feb 18, 2013 at 7:52 PM, Tom Rini tr...@ti.com wrote: OK, I thought I said, but maybe I didn't, I'm OK with re-using the tree, but _not_ the master branch, u-boot-x86/sandbox would have been fine. Personally I'd prefer another tree as done for other custodians. It makes life of new developers easier. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-x86.git
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/18/2013 06:30 PM, Otavio Salvador wrote: On Mon, Feb 18, 2013 at 7:52 PM, Tom Rini tr...@ti.com wrote: OK, I thought I said, but maybe I didn't, I'm OK with re-using the tree, but _not_ the master branch, u-boot-x86/sandbox would have been fine. Personally I'd prefer another tree as done for other custodians. It makes life of new developers easier. It doesn't scale, however. If I had my wish and we were starting this afresh, I'd go with user repositories rather than subject repositories. Using Simon as the example, I don't think he needs one for sandbox, one for patman (and other tools) and one for x86. I'd rather pull .../sjc/for-trini/x86-whatever-vs-something. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRIr00AAoJENk4IS6UOR1W5BsP/0XxGgvNqvp/Od5k1JnrR9EW mqf6xRV7IZ6MXwPBAK7/WBaAerEZ79vx2KSezQxejkxzJlTYVgiltJHf9GNCM3xh aenk/RGsyjjPmvZXTY/kR79x3/tMMdEu3xHaLb9F2a62qWfOAjQAcjqWtfwN1mSP TOgnEenxYovihC8hqQA+Qo6PjRwTQJStGapUCwxWinXAD1CWxcp3QdlHr8I2T6Ib TYIBSzT5iM/9LSdexh0Z8HOqQ0Mdu91znbJZCROkSWN5E9PM/oRaiXoWfSF6zWZy mjhmI9V+Egl9SOhJU3XL6Q2Zjs98jsnQMIELczHrHFxidWjbdopYD5GOEfx59A+z R8zZc59TSe1ocWdoJOkToy33iiXhWSUJR3ig6fmofVV7IXF/i9yO07GrlpW+CUip GVxAUaZdSgPfNtIKXQ10zwzO3VGRgxk2eLs5zb+cMR/wc/gy8cqQY9J9GJwF/k7t cysCzTW+iaSBaXwYSgVIscO7e7B9x+rt7Py+1MkkYegVE5N5Z2Igh8J5Z/tHe1Fi A+GuvkcX9aytvSiBtKjqBbe0pSc10h1EfsmAfhH1F/Go94RA+58cPMNPmzN9KkBj 6+TahbMkzk5vsHcLosio6Oj0ZNS0Xo6w/XAZGyhep0gl61YSZNwUGx5pBbcQ6OPi 2I6hs4o9GUZV2id6IZU9 =dJRp -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-x86.git
On Mon, Feb 18, 2013 at 8:45 PM, Tom Rini tr...@ti.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/18/2013 06:30 PM, Otavio Salvador wrote: On Mon, Feb 18, 2013 at 7:52 PM, Tom Rini tr...@ti.com wrote: OK, I thought I said, but maybe I didn't, I'm OK with re-using the tree, but _not_ the master branch, u-boot-x86/sandbox would have been fine. Personally I'd prefer another tree as done for other custodians. It makes life of new developers easier. It doesn't scale, however. If I had my wish and we were starting this afresh, I'd go with user repositories rather than subject repositories. Using Simon as the example, I don't think he needs one for sandbox, one for patman (and other tools) and one for x86. I'd rather pull .../sjc/for-trini/x86-whatever-vs-something. The hassle to send to separated branches is the same for different remotes; what concerns me is a new developer to try to find patman or sandbox pending patches and do not realize it is at x86 tree. This is confusing. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-x86.git
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/18/2013 06:48 PM, Otavio Salvador wrote: On Mon, Feb 18, 2013 at 8:45 PM, Tom Rini tr...@ti.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/18/2013 06:30 PM, Otavio Salvador wrote: On Mon, Feb 18, 2013 at 7:52 PM, Tom Rini tr...@ti.com wrote: OK, I thought I said, but maybe I didn't, I'm OK with re-using the tree, but _not_ the master branch, u-boot-x86/sandbox would have been fine. Personally I'd prefer another tree as done for other custodians. It makes life of new developers easier. It doesn't scale, however. If I had my wish and we were starting this afresh, I'd go with user repositories rather than subject repositories. Using Simon as the example, I don't think he needs one for sandbox, one for patman (and other tools) and one for x86. I'd rather pull .../sjc/for-trini/x86-whatever-vs-something. The hassle to send to separated branches is the same for different remotes; what concerns me is a new developer to try to find patman or sandbox pending patches and do not realize it is at x86 tree. This is confusing. It's not that great in kernel-land, I agree. But at least for U-Boot I hope we would be able to keep the number, and possibly as/more importantly, the time trees are not in master (or next) but have good things in them. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRIr6WAAoJENk4IS6UOR1WOOsP/2mxdE/HHOF0GMhDAo9xDPqm 24NHn5286PCGbQIizbbwBIOnb0/suFLbqNIhIXaE587z4veDFwiTR74Ns85NrDvi 2IUavB0QwpSO8dwpjykOHvo5aA8DUaM6jYxXhrgnm3fsvlZJIgrOcEHtBd3xKerq LdGrHybmjPZFhC9kK04JoICVAJb8svnWH9C+ql56QLn1/ZjwHVP3OlYv3bmx+iKG QuBtx30CmLwciJBAq6x3LlVasm76naA9S444RFPwxH0s3Eqlsl111Z9FdtAnc2HW VCgzU+GPgowayLSnMCf0RdXL5ho23vpOYsABOd+jKVCoK3VgEkSpyQXWk52vKD5h pRTqBNOl7KrVaCYcB5NC+xB/5dTUpem3qfvQ6UAbElehLDfHvI82Dd7ttPl0GMsH +aUTNdqubHtU6DmApGQDrfOyzi4u4vLSy3CX6Am/7pGpfd3h1M+gLChhLNH010H0 b9BMOWRRc8TolydImTFHuibCtEfx7HcleIujlThodTocU4aTkaUMoi3nSeJ58KcA vPJl1Y/vR8MmuS5mQr//Lzvf+nsSxQYg18crkasPqbqiiAeCAKHBkHd7ZD+ALCxY k9Plxpa/sx8DUqQUdgFxyDz5kAPCOli/BLdC6h/+7Yflp6HAwa/Ly6QoFYT6yGA3 79hxzWjtJ5/uravy4eKl =5qPb -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT PULL] u-boot-mpc83xx: keymile board updates
On Fri, Feb 15, 2013 at 05:59:44PM -0600, Kim Phillips wrote: Hi Tom, Please pull the latest set of keymile 83xx board updates: The following changes since commit 9a82b10c6657c5744802971036bb564ebc660291: Merge branch 'master' of git://git.denx.de/u-boot (2013-02-15 17:46:50 -0600) are available in the git repository at: git://git.denx.de/u-boot-mpc83xx.git master for you to fetch changes up to 411190cb16b63e39345a608b68b3d1be5168117a: powerpc/83xx/km: drop uneeded dtt_bus environment var (2013-02-15 17:47:21 -0600) Andreas Huber (2): km/common: introduce $uimage variable km/scripts: replace hardcoded uImage Holger Brunck (12): km/common: remove unneeded ifdefs for I2C km/common/ivm: remove obsolete code km/common/ivm: remove CONFIG_SYS_I2C_IVM_BUS related code km/common/ivm: rework piggy mac adress offset generation powerpc/83xx: use ppc_6xx as arch variable for kmvect1 kmeter1_nand: allow uasge of NAND_ECC_SOFT_BCH powerpc/83xx: use NAND_ECC_BCH for kmcoge5ne km/common: add eccmode to kernel commandline powerpc/83xx/km: cleanup tuxx1 support powerpc/83xx/km: add support for kmopti2 board powerpc/83xx/km: remove uneeded CONFIG_MISC_INIT_R powerpc/83xx/km: drop uneeded dtt_bus environment var Karlheinz Jerg (2): km82xx, km83xx: move ethernet_present() from common to cpu specific powerpc/83xx/km: add MV88E6122 switch support for kmvect1 board/keymile/common/common.c| 13 board/keymile/common/ivm.c | 48 +++--- board/keymile/km82xx/km82xx.c| 8 +++ board/keymile/km83xx/km83xx.c| 103 --- board/keymile/scripts/develop-common.txt | 5 +- board/keymile/scripts/ramfs-common.txt | 5 +- boards.cfg | 7 ++- drivers/mtd/nand/kmeter1_nand.c | 4 ++ include/configs/km/keymile-common.h | 12 +++- include/configs/km/km8309-common.h | 4 +- include/configs/km/km8321-common.h | 2 - include/configs/km/km83xx-common.h | 9 +-- include/configs/km8360.h | 2 + include/configs/suvd3.h | 37 +++ include/configs/tuxx1.h | 46 ++ 15 files changed, 226 insertions(+), 79 deletions(-) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot