Re: [U-Boot] [RFC PATCH 1/4 v1] fdt: remove i2c example code.
On Sep 15, 2011, at 8:54 AM, Jason Cooper wrote: > > Signed-off-by: Jason Cooper > --- > common/fdt_decode.c | 14 -- > include/fdt_decode.h | 32 > 2 files changed, 0 insertions(+), 46 deletions(-) Did I miss where these files were added to u-boot? Probably good in general to have some commit message so someone in the future has some idea why this change was made. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] ColdFire: Move boards with simple _config rules to boards.cfg
> -Original Message- > From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On > Behalf Of Stany MARCEL > Sent: Wednesday, September 14, 2011 8:44 PM > To: u-boot@lists.denx.de > Cc: Jin Zhengxiong-R64188; Stany MARCEL; Jin Zhengxiong-R64188 > Subject: [U-Boot] [PATCH 3/6] ColdFire: Move boards with simple _config rules > to boards.cfg > > Signed-off-by: Stany MARCEL > --- > MAKEALL|6 --- > Makefile | 96 > > boards.cfg | 21 +- > include/configs/M5329EVB.h |8 ++-- > 4 files changed, 24 insertions(+), 107 deletions(-) [Jin Zhengxiong-R64188] I suggest to put the M5329EVB update in another separate patch. Thanks. Best Regards, Jason ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] ColdFire: Cleanup lds files for multiple defined symbols
> -Original Message- > From: Stany MARCEL [mailto:stany.mar...@novasys-ingenierie.com] > Sent: Wednesday, September 14, 2011 8:44 PM > To: u-boot@lists.denx.de > Cc: Jin Zhengxiong-R64188; Jin Zhengxiong-R64188; Stany MARCEL > Subject: [PATCH 1/6] ColdFire: Cleanup lds files for multiple defined symbols > > Lds files cleened to remove multiple defined section and modified to be > compliant with --gc-sections added for ColdFire platform in a previous patch. > > Signed-off-by: Stany MARCEL > --- > board/BuS/EB+MCF-EV123/u-boot.lds| 73 ++- > board/cobra5272/u-boot.lds | 69 ++ > board/esd/tasreg/u-boot.lds | 69 +- > board/freescale/m5235evb/u-boot.16 | 71 ++- > board/freescale/m5235evb/u-boot.32 | 79 > ++ > board/freescale/m5249evb/u-boot.lds | 68 + > board/freescale/m5253evbe/u-boot.lds | 67 +--- > board/freescale/m5271evb/u-boot.lds | 66 +--- > board/freescale/m5272c3/u-boot.lds | 67 +--- > board/freescale/m5275evb/u-boot.lds | 68 ++--- > board/freescale/m5282evb/u-boot.lds | 70 ++ > board/idmr/u-boot.lds| 69 +- > 12 files changed, 150 insertions(+), 686 deletions(-) > [snip] > diff --git a/board/cobra5272/u-boot.lds b/board/cobra5272/u-boot.lds index > da14807..6c2dfe8 100644 > --- a/board/cobra5272/u-boot.lds > +++ b/board/cobra5272/u-boot.lds > @@ -1,5 +1,5 @@ > /* > - * (C) Copyright 2000 > + * (C) Copyright 2000-2003 > * Wolfgang Denk, DENX Software Engineering, w...@denx.de. [Jin Zhengxiong-R64188] Please double check the year for the Copyright, Thanks. Best Regards, Jason ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] mx31pdk: Disable watchdog
On 09/16/2011 01:18 AM, Fabio Estevam wrote: Hi Fabio, > When booting a mainline kernel on a mx31pdk the system gets getting resets > from the watchdog. > > As the kernel has watchdog support, disable it from U-boot. But if the kernel has support for watchdog, why does the system reset ? I checked this board and the watchdog in u-boot is set to 64 seconds, that is the maximum value. It is surely enough for kernel to boot and to start triggering the watchdog. If the system still reboots, it seems to me that this is an issue to be fixed in kernel, not in u-boot. I am sure I have tested in the past (not recently) the QONG board with enabled watchdog, using also the imx2_wdt driver in kernel. The watchdog in u-boot helps if u-boot hangs somewhere, for example transfering the image from media. It is a different feature. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/2] usb:gadget:s5p USB Device Controller (UDC) implementation
Dear all, > This patch series adds support for Samsung's USB Device Controller > (UDC) on GONI reference target. > > --- > Depend on: > http://patchwork.ozlabs.org/patch/112847/ > > Lukasz Majewski (2): > usb:gadget:s5p USB Device Controller (UDC) implementation > usb:gadget:s5p Enabling the USB Gadget framework at GONI Are there any comments about those patches? There wasn't any reply about them for some time... -- Best regards, Lukasz Majewski Samsung Poland R&D Center Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL boot modes
Hi Joel, The current release (based on u-boot-ti) is V9: http://patchwork.ozlabs.org/bundle/Simon/OMAP3_SPL_V9/ Or V10 http://mid.gmane.org/1315949258-12064-1-git-send-email-tr...@ti.com (based on u-boot-arm) Actually this may already work (although I haven't tested it yet). If you define CONFIG_SPL_MMC_SUPPORT and CONFIG_SPL_NAND_SUPPORT (plus the necessary defines for them) in your board header it is looking for the bootdevice the ROM code used and tries to load the image from it. If you try MMC with OMAP3 I would appreciate a message if it works or not. Regards Simon On 09/16/2011 08:11 AM, Joel A Fernandes wrote: > Hi Simon, > > Great work on the SPL patches for omap. I am getting a bit familiar > with this and earlier SPL work. > > Just one question about one of your patches I happen to notice [1], > why is there a SPL build for each different boot mode such as for > NAND, MMC etc?. Wouldn't it be nicer to have a single SPL loader that > tried different boot modes one after the other, something like what > x-load already does? Are there are any challenges with this approach? > > Thanks! > Joel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] ORIGEN : use absolute paths and fix tool naming
Dear Angus Ainslie On 13 September 2011 05:11, Angus Ainslie wrote: > On some hosts using relative paths will cause the build to fail. This > patch sets absolute paths for the tools directory > > Get rid of MSDOS style excecutable extension > > Signed-off-by: Angus Ainslie > --- > board/samsung/origen/Makefile | 6 +++--- > spl/Makefile | 2 +- > 2 files changed, 4 insertions(+), 4 deletions(-) > applied to u-boot-samsung. Thanks. Minkyu Kang. -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Samsung] [PATCH] ORIGEN : enable device tree support
Dear Angus Ainslie, On 12 September 2011 16:04, Chander Kashyap wrote: > Dear Angus, > > On 10 September 2011 03:32, wrote: >> From: Angus Ainslie >> >> Enable passing a flattened device tree to the kernel. >> >> Signed-off-by: Angus Ainslie > Acked-by: Chander Kashyap >> --- >> include/configs/origen.h | 3 +++ >> 1 files changed, 3 insertions(+), 0 deletions(-) >> applied to u-boot-samsung. Thanks. Minkyu Kang -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] git-clone doesn't compile
Hello everyone, this is my first attempt to use u-boot on an sbc2410x board with s3c2410a arm processor (v. arm4t) I have surfed the git repository and realised that the specific board has been removed from the u-boot-arm branch. commit message was : "ARM: remove broken "sbc2410x" board" so I picked up that branch and went 'back' in history to the previous commit named: "ARM: remove broken "netstar" board" found here http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=commit;h=6ea24054897b5061efd9888989e6776b60d372af i cloned the u-boot-arm.git and checkout the aforementioned commit. I then tried to compile it as is, and i get this error. make[1]: Entering directory `/home/nass/u-boot-arm/arch/arm/lib' gcc -g -Os -fno-common -ffixed-r8 -msoft-float -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0x33F8 -I/home/nass/u-boot-arm/include -fno-builtin -ffreestanding -nostdinc -isystem /scratchbox/compilers/arm-linux-cs2010q1-202/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.1/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mabi=aapcs-linux -mno-thumb-interwork -march=armv4 -Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral -Wno-format-security -o board.o board.c -c board.c: In function '__dram_init_banksize': board.c:227: error: 'CONFIG_SYS_SDRAM_BASE' undeclared (first use in this function) board.c:227: error: (Each undeclared identifier is reported only once board.c:227: error: for each function it appears in.) board.c: In function 'board_init_f': board.c:270: error: 'CONFIG_SYS_INIT_SP_ADDR' undeclared (first use in this function) board.c:303: error: 'CONFIG_SYS_SDRAM_BASE' undeclared (first use in this function) make[1]: *** [board.o] Error 1 make[1]: Leaving directory `/home/nass/u-boot-arm/arch/arm/lib' make: *** [arch/arm/lib/libarm.o] Error 2 I am not even sure if the commit should just compile or this failure is expected. Should this matter, I am compiling from within scratchbox-hathor, using codesourcery's arm toolchain 'arm-linux-cs2010q1-202'. now it was easy to define what was missing: I found most of these definitions (I still had to guess some values) in include/configs/versatile.h (a header file that no one seems to include anywhere) and incorporated them in include/configs/sbc2410x.h The code compiled fine afterwards, but u-boot.bin didn't start the board when i loaded it, so i 'm wondering if a)I have missed some important steps between compilation and loading stage b)If I have hardcoded some erroneous #define .. Thank you for your help Nass PS: here is the patched part of sbc2410x.h : http://pastebin.com/QEivCaby 1. [sbox-test6: ~/u-boot-arm] > git diff 2. diff --git a/include/configs/sbc2410x.h b/include/configs/sbc2410x.h 3. index f0f19b2..e9d7897 100644 4. --- a/include/configs/sbc2410x.h 5. +++ b/include/configs/sbc2410x.h 6. @@ -164,8 +164,15 @@ 7. 8. #define PHYS_FLASH_1 0x /* Flash Bank #1 */ 9. 10. +//#define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1 /* NASS */ 11. +//#define CONFIG_SYS_INIT_RAM_ADDR0x0080 /* NASS */ 12. +//#define CONFIG_SYS_INIT_RAM_SIZE0x000F /* NASS */ 13. #define CONFIG_SYS_FLASH_BASE PHYS_FLASH_1 14. 15. +//#define CONFIG_SYS_GBL_DATA_OFFSET (CONFIG_SYS_INIT_RAM_SIZE - GENERATED_GBL_DATA_SIZE) / 16. +//#define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_GBL_DATA_OFFSET) /* NAS 17. + 18. + 19. /*--- 20. * FLASH and environment organization 21. */ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/8] MX35: added ESDC structure to imx-regs
The structure and PLL defines are added to
the imx-regs.h file and dropped from board
header files.
Signed-off-by: Stefano Babic
---
arch/arm/include/asm/arch-mx35/imx-regs.h | 30 +
board/freescale/mx35pdk/mx35pdk.h | 18 -
2 files changed, 30 insertions(+), 18 deletions(-)
diff --git a/arch/arm/include/asm/arch-mx35/imx-regs.h
b/arch/arm/include/asm/arch-mx35/imx-regs.h
index e741fb0..08fd2d5 100644
--- a/arch/arm/include/asm/arch-mx35/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx35/imx-regs.h
@@ -147,6 +147,19 @@
#define PLL_MFI(x) (((x) & 0xf) << 10)
#define PLL_MFN(x) (((x) & 0x3ff) << 0)
+#define _PLL_BRM(x)((x) << 31)
+#define _PLL_PD(x) (((x) - 1) << 26)
+#define _PLL_MFD(x)(((x) - 1) << 16)
+#define _PLL_MFI(x)((x) << 10)
+#define _PLL_MFN(x)(x)
+#define _PLL_SETTING(brm, pd, mfd, mfi, mfn) \
+ (_PLL_BRM(brm) | _PLL_PD(pd) | _PLL_MFD(mfd) | _PLL_MFI(mfi) |\
+_PLL_MFN(mfn))
+
+#define CCM_MPLL_532_HZ_PLL_SETTING(1, 1, 12, 11, 1)
+#define CCM_MPLL_399_HZ _PLL_SETTING(0, 1, 16, 8, 5)
+#define CCM_PPLL_300_HZ _PLL_SETTING(0, 1, 4, 6, 1)
+
#define CSCR_U(x) (WEIM_CTRL_CS#x + 0)
#define CSCR_L(x) (WEIM_CTRL_CS#x + 4)
#define CSCR_A(x) (WEIM_CTRL_CS#x + 8)
@@ -286,6 +299,23 @@ struct wdog_regs {
u16 wmcr; /* Misc Control */
};
+struct esdc_regs {
+ u32 esdctl0;
+ u32 esdcfg0;
+ u32 esdctl1;
+ u32 esdcfg1;
+ u32 esdmisc;
+ u32 reserved[4];
+ u32 esdcdly[5];
+ u32 esdcdlyl;
+};
+
+#define ESDC_MISC_RST (1 << 1)
+#define ESDC_MISC_MDDR_EN (1 << 2)
+#define ESDC_MISC_MDDR_DL_RST (1 << 3)
+#define ESDC_MISC_DDR_EN (1 << 8)
+#define ESDC_MISC_DDR2_EN (1 << 9)
+
/*
* NFMS bit in RCSR register for pagesize of nandflash
*/
diff --git a/board/freescale/mx35pdk/mx35pdk.h
b/board/freescale/mx35pdk/mx35pdk.h
index 409aeb2..6aeb218 100644
--- a/board/freescale/mx35pdk/mx35pdk.h
+++ b/board/freescale/mx35pdk/mx35pdk.h
@@ -59,24 +59,6 @@
#define CCM_CCMR_CONFIG0x003F4208
#define CCM_PDR0_CONFIG0x00801000
-#define PLL_BRM_OFFSET 31
-#define PLL_PD_OFFSET 26
-#define PLL_MFD_OFFSET 16
-#define PLL_MFI_OFFSET 10
-
-#define _PLL_BRM(x)((x) << PLL_BRM_OFFSET)
-#define _PLL_PD(x) (((x) - 1) << PLL_PD_OFFSET)
-#define _PLL_MFD(x)(((x) - 1) << PLL_MFD_OFFSET)
-#define _PLL_MFI(x)((x) << PLL_MFI_OFFSET)
-#define _PLL_MFN(x)(x)
-#define _PLL_SETTING(brm, pd, mfd, mfi, mfn) \
- (_PLL_BRM(brm) | _PLL_PD(pd) | _PLL_MFD(mfd) | _PLL_MFI(mfi) |\
-_PLL_MFN(mfn))
-
-#define CCM_MPLL_532_HZ_PLL_SETTING(1, 1, 12, 11, 1)
-#define CCM_MPLL_399_HZ _PLL_SETTING(0, 1, 16, 8, 5)
-#define CCM_PPLL_300_HZ _PLL_SETTING(0, 1, 4, 6, 1)
-
/* MEMORY SETTING */
#define ESDCTL_0x9222 0x9222
#define ESDCTL_0xA222 0xA222
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/8] MX35: add pins definition for UART3
Signed-off-by: Stefano Babic
---
arch/arm/include/asm/arch-mx35/mx35_pins.h |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/arch-mx35/mx35_pins.h
b/arch/arm/include/asm/arch-mx35/mx35_pins.h
index 14669ff..3676e33 100644
--- a/arch/arm/include/asm/arch-mx35/mx35_pins.h
+++ b/arch/arm/include/asm/arch-mx35/mx35_pins.h
@@ -349,6 +349,9 @@ typedef enum iomux_pins {
MX35_PIN_FEC_TDATA2 = _MXC_BUILD_GPIO_PIN(2, 21, 0x31C, 0x780),
MX35_PIN_FEC_RDATA3 = _MXC_BUILD_GPIO_PIN(2, 22, 0x320, 0x784),
MX35_PIN_FEC_TDATA3 = _MXC_BUILD_GPIO_PIN(2, 23, 0x324, 0x788),
+
+ MX35_PIN_RTS2_UART3_RXD_MUX = _MXC_BUILD_NON_GPIO_PIN(0x1a0, 0x5e4),
+ MX35_PIN_CTS2_UART3_TXD_MUX = _MXC_BUILD_NON_GPIO_PIN(0x1a4, 0x5e8),
} iomux_pin_name_t;
#endif
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/8] MX35: add reset cause as provided by other i.MX
Signed-off-by: Stefano Babic
---
arch/arm/cpu/arm1136/mx35/generic.c | 31 +--
1 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/arm1136/mx35/generic.c
b/arch/arm/cpu/arm1136/mx35/generic.c
index fcfaba5..951bccb 100644
--- a/arch/arm/cpu/arm1136/mx35/generic.c
+++ b/arch/arm/cpu/arm1136/mx35/generic.c
@@ -422,12 +422,39 @@ U_BOOT_CMD(
""
);
+static char *get_reset_cause(void)
+{
+ /* read RCSR register from CCM module */
+ struct ccm_regs *ccm =
+ (struct ccm_regs *)IMX_CCM_BASE;
+
+ u32 cause = readl(&ccm->rcsr) & 0x0F;
+
+ switch (cause) {
+ case 0x:
+ return "POR";
+ case 0x0002:
+ return "JTAG";
+ case 0x0004:
+ return "RST";
+ case 0x0008:
+ return "WDOG";
+ default:
+ return "unknown reset";
+ }
+}
+
#if defined(CONFIG_DISPLAY_CPUINFO)
int print_cpuinfo(void)
{
- printf("CPU: Freescale i.MX35 at %d MHz\n",
+ u32 srev = get_cpu_rev();
+
+ printf("CPU: Freescale i.MX35 rev %d.%d at %d MHz.\n",
+ (srev & 0xF0) >> 4, (srev & 0x0F),
get_mcu_main_clk() / 100);
- /* mxc_dump_clocks(); */
+
+ printf("Reset cause: %s\n", get_reset_cause());
+
return 0;
}
#endif
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/8] ARM: moved general function to arm/lib
Functions inside armv7/syslib can be used by other ARM
architectures, too. The file is added as part of
ARM library.
Signed-off-by: Stefano Babic
CC: Albert ARIBAUD
---
arch/arm/cpu/armv7/Makefile |2 -
arch/arm/cpu/armv7/syslib.c | 69 ---
arch/arm/lib/Makefile |2 +
arch/arm/lib/syslib.c | 69 +++
4 files changed, 71 insertions(+), 71 deletions(-)
delete mode 100644 arch/arm/cpu/armv7/syslib.c
create mode 100644 arch/arm/lib/syslib.c
diff --git a/arch/arm/cpu/armv7/Makefile b/arch/arm/cpu/armv7/Makefile
index 92a5a96..5b7f1c7 100644
--- a/arch/arm/cpu/armv7/Makefile
+++ b/arch/arm/cpu/armv7/Makefile
@@ -32,8 +32,6 @@ COBJS += cache_v7.o
COBJS += cpu.o
endif
-COBJS += syslib.o
-
SRCS := $(START:.o=.S) $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS))
START := $(addprefix $(obj),$(START))
diff --git a/arch/arm/cpu/armv7/syslib.c b/arch/arm/cpu/armv7/syslib.c
deleted file mode 100644
index 84d17f0..000
--- a/arch/arm/cpu/armv7/syslib.c
+++ /dev/null
@@ -1,69 +0,0 @@
-/*
- * (C) Copyright 2008
- * Texas Instruments,
- *
- * Richard Woodruff
- * Syed Mohammed Khasim
- *
- * 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
-#include
-
-/
- * sdelay() - simple spin loop. Will be constant time as
- * its generally used in bypass conditions only. This
- * is necessary until timers are accessible.
- *
- * not inline to increase chances its in cache when called
- */
-void sdelay(unsigned long loops)
-{
- __asm__ volatile ("1:\n" "subs %0, %1, #1\n"
- "bne 1b":"=r" (loops):"0"(loops));
-}
-
-/*
- * sr32 - clear & set a value in a bit range for a 32 bit address
- */
-void sr32(void *addr, u32 start_bit, u32 num_bits, u32 value)
-{
- u32 tmp, msk = 0;
- msk = 1 << num_bits;
- --msk;
- tmp = readl((u32)addr) & ~(msk << start_bit);
- tmp |= value << start_bit;
- writel(tmp, (u32)addr);
-}
-
-/*
- * wait_on_value() - common routine to allow waiting for changes in
- * volatile regs.
- */
-u32 wait_on_value(u32 read_bit_mask, u32 match_value, void *read_addr,
- u32 bound)
-{
- u32 i = 0, val;
- do {
- ++i;
- val = readl((u32)read_addr) & read_bit_mask;
- if (val == match_value)
- return 1;
- if (i == bound)
- return 0;
- } while (1);
-}
diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index 300c8fa..c966aa7 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -48,6 +48,8 @@ SOBJS-$(CONFIG_USE_ARCH_MEMSET) += memset.o
SOBJS-$(CONFIG_USE_ARCH_MEMCPY) += memcpy.o
endif
+COBJS-y+= syslib.o
+
SRCS := $(GLSOBJS:.o=.S) $(GLCOBJS:.o=.c) \
$(SOBJS-y:.o=.S) $(COBJS-y:.o=.c)
OBJS := $(addprefix $(obj),$(SOBJS-y) $(COBJS-y))
diff --git a/arch/arm/lib/syslib.c b/arch/arm/lib/syslib.c
new file mode 100644
index 000..84d17f0
--- /dev/null
+++ b/arch/arm/lib/syslib.c
@@ -0,0 +1,69 @@
+/*
+ * (C) Copyright 2008
+ * Texas Instruments,
+ *
+ * Richard Woodruff
+ * Syed Mohammed Khasim
+ *
+ * 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 0211
[U-Boot] [PATCH 6/8] I2C: added I2C-2 and I2C-3 to MX35
Signed-off-by: Stefano Babic CC: Heiko Schocher --- drivers/i2c/mxc_i2c.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/i2c/mxc_i2c.c b/drivers/i2c/mxc_i2c.c index ebde3c5..25c33eb 100644 --- a/drivers/i2c/mxc_i2c.c +++ b/drivers/i2c/mxc_i2c.c @@ -63,6 +63,10 @@ #define I2C_BASEI2C2_BASE_ADDR #elif defined(CONFIG_SYS_I2C_MX35_PORT1) #define I2C_BASE I2C_BASE_ADDR +#elif defined(CONFIG_SYS_I2C_MX35_PORT2) +#define I2C_BASE I2C2_BASE_ADDR +#elif defined(CONFIG_SYS_I2C_MX35_PORT3) +#define I2C_BASE I2C3_BASE_ADDR #else #error "define CONFIG_SYS_I2C_MX_PORTx to use the mx I2C driver" #endif -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/8] MX35: factorize common assembly code
Signed-off-by: Stefano Babic --- arch/arm/include/asm/arch-mx35/lowlevel_macro.S | 140 +++ 1 files changed, 140 insertions(+), 0 deletions(-) create mode 100644 arch/arm/include/asm/arch-mx35/lowlevel_macro.S diff --git a/arch/arm/include/asm/arch-mx35/lowlevel_macro.S b/arch/arm/include/asm/arch-mx35/lowlevel_macro.S new file mode 100644 index 000..05aa951 --- /dev/null +++ b/arch/arm/include/asm/arch-mx35/lowlevel_macro.S @@ -0,0 +1,140 @@ +/* + * Copyright (C) 2007, Guennadi Liakhovetski + * + * (C) Copyright 2008-2010 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 + */ + +/* + * AIPS setup - Only setup MPROTx registers. + * The PACR default values are good. + */ +.macro init_aips + /* +* Set all MPROTx to be non-bufferable, trusted for R/W, +* not forced to user-mode. +*/ + ldr r0, =AIPS1_BASE_ADDR + ldr r1, =AIPS_MPR_CONFIG + str r1, [r0, #0x00] + str r1, [r0, #0x04] + ldr r0, =AIPS2_BASE_ADDR + str r1, [r0, #0x00] + str r1, [r0, #0x04] + + /* +* Clear the on and off peripheral modules Supervisor Protect bit +* for SDMA to access them. Did not change the AIPS control registers +* (offset 0x20) access type +*/ + ldr r0, =AIPS1_BASE_ADDR + ldr r1, =AIPS_OPACR_CONFIG + str r1, [r0, #0x40] + str r1, [r0, #0x44] + str r1, [r0, #0x48] + str r1, [r0, #0x4C] + str r1, [r0, #0x50] + ldr r0, =AIPS2_BASE_ADDR + str r1, [r0, #0x40] + str r1, [r0, #0x44] + str r1, [r0, #0x48] + str r1, [r0, #0x4C] + str r1, [r0, #0x50] +.endm + +/* MAX (Multi-Layer AHB Crossbar Switch) setup */ +.macro init_max + ldr r0, =MAX_BASE_ADDR + /* MPR - priority is M4 > M2 > M3 > M5 > M0 > M1 */ + ldr r1, =MAX_MPR_CONFIG + str r1, [r0, #0x000]/* for S0 */ + str r1, [r0, #0x100]/* for S1 */ + str r1, [r0, #0x200]/* for S2 */ + str r1, [r0, #0x300]/* for S3 */ + str r1, [r0, #0x400]/* for S4 */ + /* SGPCR - always park on last master */ + ldr r1, =MAX_SGPCR_CONFIG + str r1, [r0, #0x010]/* for S0 */ + str r1, [r0, #0x110]/* for S1 */ + str r1, [r0, #0x210]/* for S2 */ + str r1, [r0, #0x310]/* for S3 */ + str r1, [r0, #0x410]/* for S4 */ + /* MGPCR - restore default values */ + ldr r1, =MAX_MGPCR_CONFIG + str r1, [r0, #0x800]/* for M0 */ + str r1, [r0, #0x900]/* for M1 */ + str r1, [r0, #0xA00]/* for M2 */ + str r1, [r0, #0xB00]/* for M3 */ + str r1, [r0, #0xC00]/* for M4 */ + str r1, [r0, #0xD00]/* for M5 */ +.endm + +/* M3IF setup */ +.macro init_m3if + /* Configure M3IF registers */ + ldr r1, =M3IF_BASE_ADDR + /* + * M3IF Control Register (M3IFCTL) + * MRRP[0] = L2CC0 not on priority list (0 << 0) = 0x + * MRRP[1] = L2CC1 not on priority list (0 << 0) = 0x + * MRRP[2] = MBX not on priority list (0 << 0) = 0x + * MRRP[3] = MAX1 not on priority list (0 << 0) = 0x + * MRRP[4] = SDMA not on priority list (0 << 0) = 0x + * MRRP[5] = MPEG4 not on priority list (0 << 0) = 0x + * MRRP[6] = IPU1 on priority list (1 << 6) = 0x0040 + * MRRP[7] = IPU2 not on priority list (0 << 0) = 0x + * + * 0x0040 + */ + ldr r0, =M3IF_CONFIG + str r0, [r1] /* M3IF control reg */ +.endm + +.macro core_init + mrc 15, 0, r1, c1, c0, 0 + + mrc 15, 0, r0, c1, c0, 1 + orr r0, r0, #7 + mcr 15, 0, r0, c1, c0, 1 + orr r1, r1, #(1<<11) + + /* Set unaligned access enable */ + orr r1, r1, #(1<<22) + + /* Set low int latency enable */ + orr r1, r1, #(1<<21) + + mcr 15, 0, r1, c1, c0, 0 + + mov r0, #0 + + /* Set branch prediction enable */ + mcr 15, 0, r0, c15, c2, 4 + + mcr 15, 0, r0, c7, c7, 0/* invalidate I cache and D cache */
[U-Boot] [PATCH 8/8] MX35: add support for flea3 board
The flea3 board is a custom board used in automotive.
Network (FEC), NOR, NAND and SPI are supported.
Signed-off-by: Stefano Babic
---
board/flea3/Makefile| 49
board/flea3/flea3.c | 254 +++
board/flea3/lowlevel_init.S | 79
boards.cfg |1 +
include/configs/flea3.h | 280 +++
5 files changed, 663 insertions(+), 0 deletions(-)
create mode 100644 board/flea3/Makefile
create mode 100644 board/flea3/flea3.c
create mode 100644 board/flea3/lowlevel_init.S
create mode 100644 include/configs/flea3.h
diff --git a/board/flea3/Makefile b/board/flea3/Makefile
new file mode 100644
index 000..f5ad494
--- /dev/null
+++ b/board/flea3/Makefile
@@ -0,0 +1,49 @@
+#
+# Copyright (C) 2007, Guennadi Liakhovetski
+#
+# (C) Copyright 2008-2009 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 $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS := flea3.o
+SOBJS := lowlevel_init.o
+
+SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+SOBJS := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+ $(call cmd_link_o_target, $(OBJS) $(SOBJS))
+
+clean:
+ rm -f $(SOBJS) $(OBJS)
+
+distclean: clean
+ rm -f $(LIB) core *.bak .depend
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/flea3/flea3.c b/board/flea3/flea3.c
new file mode 100644
index 000..90201e3
--- /dev/null
+++ b/board/flea3/flea3.c
@@ -0,0 +1,254 @@
+/*
+ * Copyright (C) 2007, Guennadi Liakhovetski
+ *
+ * (C) Copyright 2008-2010 Freescale Semiconductor, Inc.
+ *
+ * Copyright (C) 2011, Stefano Babic
+ *
+ * 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
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#ifndef CONFIG_BOARD_EARLY_INIT_F
+#error "CONFIG_BOARD_EARLY_INIT_F must be set for this board"
+#endif
+
+#define CCM_CCMR_CONFIG0x003F4208
+
+#define ESDCTL_DDR2_CONFIG 0x007FFC3F
+#define ESDCTL_0x9222 0x9222
+#define ESDCTL_0xA222 0xA222
+#define ESDCTL_0xB222 0xB222
+#define ESDCTL_0x82228080 0x82228080
+#define ESDCTL_DDR2_EMR2 0x0400
+#define ESDCTL_DDR2_EMR3 0x0600
+#define ESDCTL_PRECHARGE 0x0400
+#define ESDCTL_DDR2_EN_DLL 0x02000400
+#define ESDCTL_DDR2_RESET_DLL 0x0333
+#define ESDCTL_DDR2_MR 0x0233
+#define ESDCTL_DDR2_OCD_DEFAULT 0x02000780
+#define ESDCTL_DELAY_LINE5 0x00F49F00
+
+DECLARE_GLOBAL_DATA_PTR;
+
+int dram_init(void)
+{
+ gd->ram_size = get_ram_size((long *)PHYS_SDRAM_1,
+ PHYS_SDRAM_1_SIZE);
+
+ return 0;
+}
+
+void board_setup_sdram(void)
+{
+ u32 val;
+ struct esdc_regs *esdc = (struct esdc_regs *)ESDCTL_BASE_ADDR;
+
+ /* Initialize with default values both CSD0/1 */
+ writel(0x2000, &esdc->esdctl0);
+ writel(0x2000, &esdc->esdctl1);
+
+ /* Initialize MISC register for DDR2 */
+ val = ESDC_MISC_RST | ESDC_MISC_MDDR_EN | ESDC_MISC_MDDR_DL_RST |
+ ESDC_MISC_DDR_EN | ESDC_MISC_DDR2_EN;
+ writel(val, &esdc->esdmisc);
+ val &= ~(ESDC_MISC_RST | ESDC_MISC_MDDR_DL_R
[U-Boot] [PATCH 7/8] MX35: Drop unnecessary prototypes from imx-regs.h
Signed-off-by: Stefano Babic
---
arch/arm/include/asm/arch-mx35/imx-regs.h |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/arch/arm/include/asm/arch-mx35/imx-regs.h
b/arch/arm/include/asm/arch-mx35/imx-regs.h
index 08fd2d5..038f0b6 100644
--- a/arch/arm/include/asm/arch-mx35/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx35/imx-regs.h
@@ -325,9 +325,5 @@ struct esdc_regs {
#define CCM_RCSR_NF_16BIT_SEL (1 << 14)
-extern unsigned int get_board_rev(void);
-extern int is_soc_rev(int rev);
-extern int sdhc_init(void);
-
#endif
#endif /* __ASM_ARCH_MX35_H */
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] mkimage: ublimage must return if the header is not verified
Each image handler must return a not-zero velue if the
header is not recognized to allow the main program to
iterate to the next handler.
Signed-off-by: Stefano Babic
CC: Heiko Schocher
---
tools/ublimage.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/tools/ublimage.c b/tools/ublimage.c
index 9987462..d6b4017 100644
--- a/tools/ublimage.c
+++ b/tools/ublimage.c
@@ -214,6 +214,11 @@ static int ublimage_check_image_types(uint8_t type)
static int ublimage_verify_header(unsigned char *ptr, int image_size,
struct mkimage_params *params)
{
+ struct ubl_header *ubl_hdr = (struct ubl_header *)ptr;
+
+ if ((ubl_hdr->magic & 0xFF00) != UBL_MAGIC_BASE)
+ return -1;
+
return 0;
}
--
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] mkimage: Add variable lenght header support
Some images have not a header of fix lenght. The patch will be
used for the generation of AIS images, because this header has
a variable lenght. The patch adds also the parameter "-s" (skip)
to not copy automatically the passed image file.
Signed-off-by: Stefano Babic
---
tools/mkimage.c | 19 ++-
tools/mkimage.h |8
2 files changed, 22 insertions(+), 5 deletions(-)
diff --git a/tools/mkimage.c b/tools/mkimage.c
index 2f33101..c307a37 100644
--- a/tools/mkimage.c
+++ b/tools/mkimage.c
@@ -248,6 +248,9 @@ main (int argc, char **argv)
usage ();
params.imagename = *++argv;
goto NXTARG;
+ case 's':
+ params.skipcpy = 1;
+ break;
case 'v':
params.vflag++;
break;
@@ -361,11 +364,15 @@ NXTARG: ;
}
/*
-* Must be -w then:
-*
-* write dummy header, to be fixed later
+* In case there an header with a variable
+* length will be added, the corresponding
+* function is called. This is responsible to
+* allocate memory for the header itself.
*/
- memset (tparams->hdr, 0, tparams->header_size);
+ if (tparams->vrec_header)
+ tparams->vrec_header(¶ms, tparams);
+ else
+ memset(tparams->hdr, 0, tparams->header_size);
if (write(ifd, tparams->hdr, tparams->header_size)
!= tparams->header_size) {
@@ -374,7 +381,9 @@ NXTARG: ;
exit (EXIT_FAILURE);
}
- if (params.type == IH_TYPE_MULTI || params.type == IH_TYPE_SCRIPT) {
+ if (!params.skipcpy &&
+ (params.type == IH_TYPE_MULTI ||
+ params.type == IH_TYPE_SCRIPT)) {
char *file = params.datafile;
uint32_t size;
diff --git a/tools/mkimage.h b/tools/mkimage.h
index e59a919..213baf0 100644
--- a/tools/mkimage.h
+++ b/tools/mkimage.h
@@ -60,6 +60,7 @@ struct mkimage_params {
int lflag;
int vflag;
int xflag;
+ int skipcpy;
int os;
int arch;
int type;
@@ -122,6 +123,13 @@ struct image_type_params {
int (*check_image_type) (uint8_t);
/* This callback function will be executed if fflag is defined */
int (*fflag_handle) (struct mkimage_params *);
+ /*
+* This callback function will be executed for variable size record
+* It is expected to build this header in memory and return its length
+* and a pointer to it
+*/
+ int (*vrec_header) (struct mkimage_params *,
+ struct image_type_params *);
/* pointer to the next registered entry in linked list */
struct image_type_params *next;
};
--
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] mkimage: adding support for Davinci AIS image
Some Davinci processors supports the Application
Image Script (AIS) boot process. The patch adds the generation
of the AIS image inside the mkimage tool to make possible
to generate a bootable U-boot without external tools
(TI Davinci AIS Generator).
Signed-off-by: Stefano Babic
---
common/image.c |1 +
include/image.h |1 +
tools/Makefile |4 +-
tools/aisimage.c | 453 ++
tools/aisimage.h | 97
tools/mkimage.c |2 +
tools/mkimage.h |1 +
7 files changed, 558 insertions(+), 1 deletions(-)
create mode 100644 tools/aisimage.c
create mode 100644 tools/aisimage.h
diff --git a/common/image.c b/common/image.c
index d38ce4a..f2804f8 100644
--- a/common/image.c
+++ b/common/image.c
@@ -146,6 +146,7 @@ static const table_entry_t uimage_type[] = {
{ IH_TYPE_KWBIMAGE, "kwbimage", "Kirkwood Boot Image",},
{ IH_TYPE_IMXIMAGE, "imximage", "Freescale i.MX Boot Image",},
{ IH_TYPE_UBLIMAGE, "ublimage", "Davinci UBL image",},
+ { IH_TYPE_AISIMAGE, "aisimage", "Davinci AIS image",},
{ -1, "", "", },
};
diff --git a/include/image.h b/include/image.h
index 352e4a0..2b5a160 100644
--- a/include/image.h
+++ b/include/image.h
@@ -159,6 +159,7 @@
#define IH_TYPE_IMXIMAGE 10 /* Freescale IMXBoot Image */
#define IH_TYPE_UBLIMAGE 11 /* Davinci UBL Image*/
#define IH_TYPE_OMAPIMAGE 12 /* TI OMAP Config Header Image */
+#define IH_TYPE_AISIMAGE 13 /* TI Davinci AIS Image */
/*
* Compression Types
diff --git a/tools/Makefile b/tools/Makefile
index fc741d3..df56a25 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -86,6 +86,7 @@ NOPED_OBJ_FILES-y += fit_image.o
OBJ_FILES-$(CONFIG_CMD_NET) += gen_eth_addr.o
OBJ_FILES-$(CONFIG_CMD_LOADS) += img2srec.o
OBJ_FILES-$(CONFIG_XWAY_SWAP_BYTES) += xway-swap-bytes.o
+NOPED_OBJ_FILES-y += aisimage.o
NOPED_OBJ_FILES-y += kwbimage.o
NOPED_OBJ_FILES-y += imximage.o
NOPED_OBJ_FILES-y += omapimage.o
@@ -184,7 +185,8 @@ $(obj)xway-swap-bytes$(SFX):$(obj)xway-swap-bytes.o
$(HOSTCC) $(HOSTCFLAGS) $(HOSTLDFLAGS) -o $@ $^
$(HOSTSTRIP) $@
-$(obj)mkimage$(SFX): $(obj)crc32.o \
+$(obj)mkimage$(SFX): $(obj)aisimage.o \
+ $(obj)crc32.o \
$(obj)default_image.o \
$(obj)fit_image.o \
$(obj)image.o \
diff --git a/tools/aisimage.c b/tools/aisimage.c
new file mode 100644
index 000..f73309a
--- /dev/null
+++ b/tools/aisimage.c
@@ -0,0 +1,453 @@
+/*
+ * (C) Copyright 2011
+ * Stefano Babic, DENX Software Engineering, sba...@denx.de.
+ *
+ * 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
+ */
+
+/* Required to obtain the getline prototype from stdio.h */
+#define _GNU_SOURCE
+
+#include "mkimage.h"
+#include "aisimage.h"
+#include
+
+#define IS_FNC_EXEC(c) (cmd_table[c].AIS_cmd == AIS_CMD_FNLOAD)
+#define WORD_ALIGN04
+#define WORD_ALIGN(len) (((len)+WORD_ALIGN0-1) & ~(WORD_ALIGN0-1))
+#define MAX_CMD_BUFFER 4096
+#define ARRAY_SIZE(a) (sizeof (a) / sizeof ((a)[0]))
+
+static uint32_t ais_img_size = 0;
+
+/*
+ * Supported commands for configuration file
+ */
+static table_entry_t aisimage_cmds[] = {
+ {CMD_DATA, "DATA", "Reg Write Data"},
+ {CMD_FILL, "FILL", "Fill range with pattern"},
+ {CMD_CRCON, "CRCON","CRC Enable"},
+ {CMD_CRCOFF,"CRCOFF", "CRC Disable"},
+ {CMD_CRCCHECK, "CRCCHECK", "CRC Validate"},
+ {CMD_JMPCLOSE, "JMPCLOSE", "Jump & Close"},
+ {CMD_JMP, "JMP", "Jump"},
+ {CMD_SEQREAD, "SEQREAD", "Sequential read"},
+ {CMD_PLL0, "PLL0", "PLL0"},
+ {CMD_PLL1, "PLL1", "PLL1"},
+ {CMD_CLK, "CLK", "Clock configuration"},
+ {CMD_DDR2, "DDR2", "DDR2 Configuration"},
+ {CMD_EMIFA, "EMIFA","EMIFA"},
+
Re: [U-Boot] [PATCH 1/3] mkimage: ublimage must return if the header is not verified
Hello Stefano, Stefano Babic wrote: > Each image handler must return a not-zero velue if the ^ value > header is not recognized to allow the main program to > iterate to the next handler. > > Signed-off-by: Stefano Babic > CC: Heiko Schocher > --- > tools/ublimage.c |5 + > 1 files changed, 5 insertions(+), 0 deletions(-) Beside of that: Acked-by: Heiko Schocher Thanks for detecting! bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] moje zdje;cie
i wannted wyslac u moje zdjecie dawno temu, ale balem sie, ze u dont like do mnie. sprawdzic na linki u zobaczyc moje zdjecie, mam nadzieje, ze u like it Pobierz i zobaczyc moje zdjecie ... http://dropfile.ru/files/get/w0VuEegoD6/dc595963.zip ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ppc4xx: Flush dcache after DDR2 autocalibration with caches on
Flush the dcache before removing the TLB with caches enabled. Otherwise this might lead to problems later on, e.g. while booting Linux (as seen on ICON-440SPe). Signed-off-by: Stefan Roese --- arch/powerpc/cpu/ppc4xx/44x_spd_ddr2.c |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/cpu/ppc4xx/44x_spd_ddr2.c b/arch/powerpc/cpu/ppc4xx/44x_spd_ddr2.c index 95df1d9..4a2f337 100644 --- a/arch/powerpc/cpu/ppc4xx/44x_spd_ddr2.c +++ b/arch/powerpc/cpu/ppc4xx/44x_spd_ddr2.c @@ -657,6 +657,13 @@ phys_size_t initdram(int board_type) #endif /* +* Flush the dcache before removing the TLB with caches +* enabled. Otherwise this might lead to problems later on, +* e.g. while booting Linux (as seen on ICON-440SPe). +*/ + flush_dcache(); + + /* * Now after initialization (auto-calibration and ECC generation) * remove the TLB entries with caches enabled and program again with * desired cache functionality -- 1.7.6.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] mx31pdk: Disable watchdog
Hello. On 16-09-2011 3:18, Fabio Estevam wrote: > When booting a mainline kernel on a mx31pdk the system gets getting resets > from the watchdog. That's tautological. Maybe "is getting reset"? > As the kernel has watchdog support, disable it from U-boot. > Signed-off-by: Fabio Estevam WBR, Sergei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] mx31pdk: Change the prompt as per other i.MX boards
On 09/16/2011 01:18 AM, Fabio Estevam wrote: > Change the prompt as done in other i.MX boards. > > Signed-off-by: Fabio Estevam > --- > include/configs/mx31pdk.h |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/include/configs/mx31pdk.h b/include/configs/mx31pdk.h > index e77805c..7f91f67 100644 > --- a/include/configs/mx31pdk.h > +++ b/include/configs/mx31pdk.h > @@ -123,7 +123,7 @@ > * Miscellaneous configurable options > */ > #define CONFIG_SYS_LONGHELP /* undef to save memory */ > -#define CONFIG_SYS_PROMPT"uboot> " > +#define CONFIG_SYS_PROMPT"MX31PDK U-Boot > " > #define CONFIG_SYS_CBSIZE256 /* Console I/O Buffer Size */ > /* Print Buffer Size */ > #define CONFIG_SYS_PBSIZE(CONFIG_SYS_CBSIZE + \ Acked-by : Stefano Babic Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/8] MX35: add support for flea3 board
Hi Stefano,
On Fri, Sep 16, 2011 at 6:46 AM, Stefano Babic wrote:
..
> +void board_setup_sdram(void)
> +{
> + u32 val;
> + struct esdc_regs *esdc = (struct esdc_regs *)ESDCTL_BASE_ADDR;
> +
> + /* Initialize with default values both CSD0/1 */
> + writel(0x2000, &esdc->esdctl0);
> + writel(0x2000, &esdc->esdctl1);
On other boards we setup the SDRAM in lowlevel_init.S and here you do
it on the board file.
Shouldn´t this be setup in lowlevel_init.S for consistency?
Regards,
Fabio Estevam
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/8] MX35: add support for flea3 board
Hi Stefano, On Fri, Sep 16, 2011 at 6:46 AM, Stefano Babic wrote: > The flea3 board is a custom board used in automotive. > Network (FEC), NOR, NAND and SPI are supported. > > Signed-off-by: Stefano Babic > --- > board/flea3/Makefile | 49 > board/flea3/flea3.c | 254 +++ > board/flea3/lowlevel_init.S | 79 > boards.cfg | 1 + > include/configs/flea3.h | 280 > +++ > 5 files changed, 663 insertions(+), 0 deletions(-) > create mode 100644 board/flea3/Makefile > create mode 100644 board/flea3/flea3.c > create mode 100644 board/flea3/lowlevel_init.S > create mode 100644 include/configs/flea3.h You missed an entry in MAINTAINERS file. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/8] MX35: add support for flea3 board
On 09/16/2011 01:49 PM, Fabio Estevam wrote: > Hi Stefano, > > On Fri, Sep 16, 2011 at 6:46 AM, Stefano Babic wrote: >> The flea3 board is a custom board used in automotive. >> Network (FEC), NOR, NAND and SPI are supported. >> >> Signed-off-by: Stefano Babic >> --- >> board/flea3/Makefile| 49 >> board/flea3/flea3.c | 254 +++ >> board/flea3/lowlevel_init.S | 79 >> boards.cfg |1 + >> include/configs/flea3.h | 280 >> +++ >> 5 files changed, 663 insertions(+), 0 deletions(-) >> create mode 100644 board/flea3/Makefile >> create mode 100644 board/flea3/flea3.c >> create mode 100644 board/flea3/lowlevel_init.S >> create mode 100644 include/configs/flea3.h > > You missed an entry in MAINTAINERS file. Ok, thanks - fixed in V2. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC] Timer API (again!)
Hi All, Well, here we are again, a Timer API discussion :) All things considered, I don't think the Linux approach is right for U-Boot - It is designed to cater for way more use-cases than U-Boot will ever need to deal with (time queues and call-backs in particular) To summarise, in a nutshell, what _I_ think U-Boot need from a Timer API 1. A reliable udelay() available as early as possible that is OK to delay longer than requested, but not shorter - Accuracy is not implied or assumed 2. A method of obtaining a number of 'time intervals' which have elapsed since some random epoch (more info below) 3. A nice way of making A->B time checks simple within the code OK, some details: 1. I'm starting to thing this should be a function pointer or a flag in gd. Why oh why would you do such a thing I hear you ask... udelay() is needed _EARLY_ - It may well be needed for SDRAM or other hardware initialisation prior to any reliable timer sub-system being available. But early udelay() is often inaccurate and when the timer sub-system gets fully initialised, it can be used for an accurate udelay(). x86 used to have an global data flag that got set when the timer-subsystem got initialised. If the flag was not set, udelay() would use one implementation, but if it was set, udelay() would use a more accurate implementation. In the case of the eNET board, it had an FPGA implementation of a microsecond timer which was even more accurate that the CPU, so it had it's own implementation that should have duplicated the 'if (gd->flags & TIMER_INIT)' but never did (this was OK because udelay() was never needed before then) I think a function pointer in gd would be a much neater way of handling the fact that more accurate (and efficient) implementations of udelay() may present themselves throughout the boot process An other option would be to have the gd flag and make udelay() a lib function which performs the test - If the arch timer has better than 1us resolution it can set the flag and udelay() will use the timer API 2a (random epoch) - The timer sub-system should not rely on a particular epoch (1970, 1901, 0, 1, since boot, since timer init, etc...) - By using the full range of an unsigned variable, the epoch does not matter 2b (time interval) - We need to pick a base resolution for the timer API - Linux uses nano-seconds and I believe this is a good choice. Big Fat Note: The underlying hardware DOES NOT need to have nano-second resolution. The only issue with nano-seconds is that it mandates a 64-bit timer - A few people are against this idea - lets discuss. A 32-bit microsecond timer provides ~4300 seconds (~1.2 hours) which _might_ be long enough, but stand-alone applications doing burn-in tests may need longer. Going milli-seconds means we cannot piggy-back udelay() on the timer API. My preference is a 64-bit nano-second timer with udelay() piggy-backed on the timer API (unless, like NIOS, the timer sub-system cannot provide micro-second resolution, in which case the gd flag or function pointer does not get set to use the timer API for udelay()) I really want to get the Timer API sorted this time around Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/8] MX35: add support for flea3 board
On 09/16/2011 01:48 PM, Fabio Estevam wrote:
> Hi Stefano,
>
Hi Fabio,
> On Fri, Sep 16, 2011 at 6:46 AM, Stefano Babic wrote:
> ..
>> +void board_setup_sdram(void)
>> +{
>> + u32 val;
>> + struct esdc_regs *esdc = (struct esdc_regs *)ESDCTL_BASE_ADDR;
>> +
>> + /* Initialize with default values both CSD0/1 */
>> + writel(0x2000, &esdc->esdctl0);
>> + writel(0x2000, &esdc->esdctl1);
>
> On other boards we setup the SDRAM in lowlevel_init.S and here you do
> it on the board file.
>
> Shouldn´t this be setup in lowlevel_init.S for consistency?
Really the idea is to get rid (as much as possible) of lowlevel_init.S
and make the whole setup in C code.
This board can be then the first one (MX3) doing that, that makes the
code much more readable - and I see in recent patches that this is
pushed for other architectures, too (I mean Heiko's patches for davinci
AM1808). And this is done since a lot of time for some PowerPC boards.
The question arises if the other boards (at least the mx35pdk..) should
be updated in the same way...
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/4 v1] fdt: remove i2c example code.
Kumar,
On Fri, Sep 16, 2011 at 02:31:32AM -0500, Kumar Gala wrote:
> On Sep 15, 2011, at 8:54 AM, Jason Cooper wrote:
> >
> > Signed-off-by: Jason Cooper
> > ---
> > common/fdt_decode.c | 14 --
> > include/fdt_decode.h | 32
> > 2 files changed, 0 insertions(+), 46 deletions(-)
>
> Did I miss where these files were added to u-boot?
No, I sent this series in-reply-to Simon Glass' RFC series adding
fdt_decode.{c,h}. My cover letter details how I got to here.
> Probably good in general to have some commit message so someone in the
> future has some idea why this change was made.
Very true, this code is _way_ too early to consider committing (both
Simon's and mine). Once we remove RFC, I'll make sure to have full
commit logs. This series will most likely get squashed into one patch
with one or two of them being merged into Simon's series.
hth,
Jason.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL boot modes
Dear Joel A Fernandes, In message you wrote: > > Just one question about one of your patches I happen to notice [1], > why is there a SPL build for each different boot mode such as for > NAND, MMC etc?. Wouldn't it be nicer to have a single SPL loader that > tried different boot modes one after the other, something like what > x-load already does? Are there are any challenges with this approach? Yes, this would be nice. Question: how do we make this fit in - say - the 2 KiB code size that some processors load? Including all the drivers for NAND, MMC etc.? 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 Lots of people drink from the wrong bottle sometimes. -- Edith Keeler, "The City on the Edge of Forever", stardate unknown ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] git-clone doesn't compile
Dear Athanasios Silis, In message you wrote: > > I have surfed the git repository and realised that the specific board has > been removed from the u-boot-arm branch. > commit message was : "ARM: remove broken "sbc2410x" board" Please digest that message: remove the BROKEN "sbc2410x" board... > I then tried to compile it as is, and i get this error. This is to be expacted: the board is BROKEN and does not even compile. That (and the fact that nobocy cared to fix the problem) was why it got removed. 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 The project was large enough and management communication poor enough to prompt many members of the team to see themselves as contestants making brownie points, rather than as builders making programming products. Each suboptimized his piece to meet his targets; few stopped to think about the total effect on the customer. - Fred Brooks, "The Mythical Man Month" ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL boot modes
On 09/16/2011 02:31 PM, Wolfgang Denk wrote: > Dear Joel A Fernandes, > > In > message > you wrote: >> >> Just one question about one of your patches I happen to notice [1], >> why is there a SPL build for each different boot mode such as for >> NAND, MMC etc?. Wouldn't it be nicer to have a single SPL loader that >> tried different boot modes one after the other, something like what >> x-load already does? Are there are any challenges with this approach? > > Yes, this would be nice. Question: how do we make this fit in - say - > the 2 KiB code size that some processors load? Including all the > drivers for NAND, MMC etc.? > > Best regards, > > Wolfgang Denk > That's the reason for the librarys in SPL. One can build a SPL that is able to boot from more than one source (although it might not work yet - the tools are there). If size matters: Just include the one needed Regards Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] MX31: Improve readability for reset cause
Currently the reset cause is printed like:
CPU: Freescale i.MX31 rev 2.0 at 531 MHz.Reset cause: POR
Improve readability by adding a new line like it is done on other i.MX boards.
Signed-off-by: Fabio Estevam
---
arch/arm/cpu/arm1136/mx31/generic.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/cpu/arm1136/mx31/generic.c
b/arch/arm/cpu/arm1136/mx31/generic.c
index e3a4d1b..c6def5d 100644
--- a/arch/arm/cpu/arm1136/mx31/generic.c
+++ b/arch/arm/cpu/arm1136/mx31/generic.c
@@ -180,7 +180,7 @@ int print_cpuinfo (void)
{
u32 srev = get_cpu_rev();
- printf("CPU: Freescale i.MX31 rev %d.%d%s at %d MHz.",
+ printf("CPU: Freescale i.MX31 rev %d.%d%s at %d MHz.\n",
(srev & 0xF0) >> 4, (srev & 0x0F),
((srev & 0x8000) ? " unknown" : ""),
mx31_get_mcu_main_clk() / 100);
--
1.6.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch v2 1/7] powerpc/mpc8xxx: Fix DDR code for empty first DIMM slot and enable DQS_en
On Aug 26, 2011, at 1:32 PM, York Sun wrote: > Check second DIMM slot in case the first one is empty. > Honor DQS enable option for SDRAM mode register. > > Signed-off-by: York Sun > --- > arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c | 19 ++- > arch/powerpc/include/asm/fsl_ddr_sdram.h |4 > 2 files changed, 14 insertions(+), 9 deletions(-) applied to 85xx 'next' - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch v2 2/7] powerpc/mpc8xxx: Add SPD EEPROM address for single controller 2 slots
On Aug 26, 2011, at 1:32 PM, York Sun wrote: > The two slots on the same controller have different addresses. > > Signed-off-by: York Sun > --- > arch/powerpc/cpu/mpc8xxx/ddr/main.c | 11 +++ > 1 files changed, 7 insertions(+), 4 deletions(-) applied to 85xx 'next' - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch v2 3/7] powerpc/mpc8xxx: Fix picos_to_mclk() and get_memory_clk_period_ps()
On Aug 26, 2011, at 1:32 PM, York Sun wrote: > Reduce the calculation error to 1ps. > > Signed-off-by: York Sun > --- > arch/powerpc/cpu/mpc8xxx/ddr/util.c | 26 +++--- > 1 files changed, 11 insertions(+), 15 deletions(-) applied to 85xx 'next' - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch v2 4/7] powerpc/mpc8xxx: Add DDR2 to unified DDR driver
On Aug 26, 2011, at 1:32 PM, York Sun wrote: > DDR2 has different ODT table and values. Adding table according to Samsung > application note. > > Fix additive latency calculation to avoid interger underflow. > > Signed-off-by: York Sun > --- > .../cpu/mpc8xxx/ddr/lc_common_dimm_params.c|3 +- > arch/powerpc/cpu/mpc8xxx/ddr/options.c | 214 +++- > arch/powerpc/include/asm/fsl_ddr_sdram.h |7 + > doc/README.fsl-ddr | 52 + > 4 files changed, 274 insertions(+), 2 deletions(-) applied, converted dynamic_odt_t to struct dynamic_odt - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] DaVinci: correct PDSTAT.STATE mask
MDSTAT.STATE occupies bits 0..5 according to all available documentation, so fix the masks which previously was leaving out the itermediate state indicator bit. Signed-off-by: Sergei Shtylyov --- Analogous Linux patch has been queued in the linux-davinci tree: http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2011-July/023075.html arch/arm/cpu/arm926ejs/davinci/lowlevel_init.S |6 +++--- arch/arm/cpu/arm926ejs/davinci/psc.c |4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-) Index: u-boot/arch/arm/cpu/arm926ejs/davinci/lowlevel_init.S === --- u-boot.orig/arch/arm/cpu/arm926ejs/davinci/lowlevel_init.S +++ u-boot/arch/arm/cpu/arm926ejs/davinci/lowlevel_init.S @@ -268,7 +268,7 @@ checkStatClkStop: checkDDRStatClkStop: ldr r6, MDSTAT_DDR2 ldr r7, [r6] - and r7, r7, $0x1f + and r7, r7, $0x3f cmp r7, $0x03 bne checkDDRStatClkStop @@ -343,7 +343,7 @@ checkStatClkStop2: checkDDRStatClkStop2: ldr r6, MDSTAT_DDR2 ldr r7, [r6] - and r7, r7, $0x1f + and r7, r7, $0x3f cmp r7, $0x01 bne checkDDRStatClkStop2 @@ -374,7 +374,7 @@ checkStatClkEn2: checkDDRStatClkEn2: ldr r6, MDSTAT_DDR2 ldr r7, [r6] - and r7, r7, $0x1f + and r7, r7, $0x3f cmp r7, $0x03 bne checkDDRStatClkEn2 Index: u-boot/arch/arm/cpu/arm926ejs/davinci/psc.c === --- u-boot.orig/arch/arm/cpu/arm926ejs/davinci/psc.c +++ u-boot/arch/arm/cpu/arm926ejs/davinci/psc.c @@ -83,7 +83,7 @@ void lpsc_on(unsigned int id) while (readl(ptstat) & 0x01) continue; - if ((readl(mdstat) & 0x1f) == 0x03) + if ((readl(mdstat) & 0x3f) == 0x03) return; /* Already on and enabled */ writel(readl(mdctl) | 0x03, mdctl); @@ -114,7 +114,7 @@ void lpsc_on(unsigned int id) while (readl(ptstat) & 0x01) continue; - while ((readl(mdstat) & 0x1f) != 0x03) + while ((readl(mdstat) & 0x3f) != 0x03) continue; } ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch v2 6/7] powerpc/mpc8349emds: Migrate from spd_sdram to unified DDR driver
On Aug 26, 2011, at 1:32 PM, York Sun wrote: > Update MPC8349EMDS to use unified DDR driver instead of spd_sdram.c. > The unified driver can initialize data using DDR controller. No need to > use DMA if just to initialze for ECC. > > Signed-off-by: York Sun > Signed-off-by: Kim Phillips > --- > board/freescale/mpc8349emds/Makefile |1 + > board/freescale/mpc8349emds/ddr.c | 107 + > board/freescale/mpc8349emds/mpc8349emds.c | 26 --- > include/configs/MPC8349EMDS.h | 16 > 4 files changed, 139 insertions(+), 11 deletions(-) > create mode 100644 board/freescale/mpc8349emds/ddr.c applied to 85xx 'next' - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/85xx: Refactor P2041RDB to use common p_corenet files
On Aug 30, 2011, at 6:04 PM, Kumar Gala wrote: > The P2041RDB has almost identical setup for TLB, LAWS, and PCI with > other P-Series CoreNet platforms. > > The only difference between P2041RDB & P3041DS/P4080DS/P5020DS is the > CPLD vs PIXIS FPGA which we can handle via some simple #ifdefs in the > TLB and LAW setup tables. > > Signed-off-by: Kumar Gala > --- > board/freescale/common/Makefile|1 + > board/freescale/common/p_corenet/law.c |5 ++ > board/freescale/common/p_corenet/tlb.c |7 ++ > board/freescale/p2041rdb/Makefile |3 - > board/freescale/p2041rdb/law.c | 37 -- > board/freescale/p2041rdb/pci.c | 39 -- > board/freescale/p2041rdb/tlb.c | 123 > 7 files changed, 13 insertions(+), 202 deletions(-) > delete mode 100644 board/freescale/p2041rdb/law.c > delete mode 100644 board/freescale/p2041rdb/pci.c > delete mode 100644 board/freescale/p2041rdb/tlb.c applied to 85xx 'next' - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/85xx: p2041rdb - Remove unused 'execute' perm in TLB entries
On Aug 30, 2011, at 6:04 PM, Kumar Gala wrote: > We shouldn't be setting execute permissions on TLB entries that will not > actually have any code run from them. > > Signed-off-by: Kumar Gala > --- > board/freescale/p2041rdb/tlb.c | 34 +++--- > 1 files changed, 19 insertions(+), 15 deletions(-) applied to 85xx 'next' - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch v2 5/7] powerpc/mpc83xx: Migrate from spd_sdram to unified DDR driver
On Aug 26, 2011, at 1:32 PM, York Sun wrote: > Unified DDR driver is maintained for better performance, robustness and bug > fixes. Upgrading to use unified DDR driver for MPC83xx takes advantage of > overall improvement. It requires changes for board files to customize > platform-dependent parameters. > > To utilize the unified DDR driver, a board needs to define CONFIG_FSL_DDRx > in the header file. No more boards will be accepted without such definition. > > Note: the workaround for erratum DDR6 for the very old MPC834x Rev 1.0/1.1 > and MPC8360 Rev 1.1/1.2 parts is not migrated to unified driver. > > Signed-off-by: Kim Phillips > Signed-off-by: York Sun > --- > Makefile |1 + > arch/powerpc/cpu/mpc83xx/Makefile| 20 +- > arch/powerpc/cpu/mpc83xx/ecc.c | 18 -- > arch/powerpc/cpu/mpc83xx/law.c | 61 > arch/powerpc/cpu/mpc83xx/speed.c |9 +++ > arch/powerpc/cpu/mpc85xx/ddr-gen2.c |8 ++- > arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c |4 +- > arch/powerpc/cpu/mpc8xxx/ddr/util.c |9 ++- > arch/powerpc/include/asm/config.h|5 +- > arch/powerpc/include/asm/immap_83xx.h| 117 +- > common/Makefile |8 ++- > include/common.h |4 +- > 12 files changed, 245 insertions(+), 19 deletions(-) > create mode 100644 arch/powerpc/cpu/mpc83xx/law.c applied to 85xx 'next' - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/85xx: refactor common P-Series CoreNet files for FSL boards
On Aug 30, 2011, at 6:04 PM, Kumar Gala wrote:
> We currently support 4 SoC/Boards from the P-Series of QorIQ SoCs that
> are based on the 'CoreNet' Architecture: P2041RDB, P3041DS, P4080DS, and
> P5020DS. There is a significant amount of commonality shared between
> these boards that we can refactor into common code:
>
> * Initial LAW setup
> * Initial TLB setup
> * PCI setup
>
> We start by moving the shared code between P3041DS, P4080DS, and P5020DS
> into a common directory to be shared with other P-Series CoreNet boards.
>
> Signed-off-by: Kumar Gala
> ---
> board/freescale/common/Makefile| 13 +++-
> board/freescale/common/p_corenet/Makefile | 31
> .../{corenet_ds => common/p_corenet}/law.c |0
> .../{corenet_ds => common/p_corenet}/pci.c |0
> .../{corenet_ds => common/p_corenet}/tlb.c |0
> board/freescale/corenet_ds/Makefile|3 --
> 6 files changed, 42 insertions(+), 5 deletions(-)
> create mode 100644 board/freescale/common/p_corenet/Makefile
> rename board/freescale/{corenet_ds => common/p_corenet}/law.c (100%)
> rename board/freescale/{corenet_ds => common/p_corenet}/pci.c (100%)
> rename board/freescale/{corenet_ds => common/p_corenet}/tlb.c (100%)
applied to 85xx 'next'
- k
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] DaVinci: correct MDSTAT.STATE mask
MDSTAT.STATE occupies bits 0..5 according to all available documentation, so fix the masks which previously was leaving out the intermediate state indicator bit. Signed-off-by: Sergei Shtylyov --- Resending with the corrected subject/description... Analogous Linux patch has been queued in the linux-davinci tree: http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2011-July/023075.html arch/arm/cpu/arm926ejs/davinci/lowlevel_init.S |6 +++--- arch/arm/cpu/arm926ejs/davinci/psc.c |4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-) Index: u-boot/arch/arm/cpu/arm926ejs/davinci/lowlevel_init.S === --- u-boot.orig/arch/arm/cpu/arm926ejs/davinci/lowlevel_init.S +++ u-boot/arch/arm/cpu/arm926ejs/davinci/lowlevel_init.S @@ -268,7 +268,7 @@ checkStatClkStop: checkDDRStatClkStop: ldr r6, MDSTAT_DDR2 ldr r7, [r6] - and r7, r7, $0x1f + and r7, r7, $0x3f cmp r7, $0x03 bne checkDDRStatClkStop @@ -343,7 +343,7 @@ checkStatClkStop2: checkDDRStatClkStop2: ldr r6, MDSTAT_DDR2 ldr r7, [r6] - and r7, r7, $0x1f + and r7, r7, $0x3f cmp r7, $0x01 bne checkDDRStatClkStop2 @@ -374,7 +374,7 @@ checkStatClkEn2: checkDDRStatClkEn2: ldr r6, MDSTAT_DDR2 ldr r7, [r6] - and r7, r7, $0x1f + and r7, r7, $0x3f cmp r7, $0x03 bne checkDDRStatClkEn2 Index: u-boot/arch/arm/cpu/arm926ejs/davinci/psc.c === --- u-boot.orig/arch/arm/cpu/arm926ejs/davinci/psc.c +++ u-boot/arch/arm/cpu/arm926ejs/davinci/psc.c @@ -83,7 +83,7 @@ void lpsc_on(unsigned int id) while (readl(ptstat) & 0x01) continue; - if ((readl(mdstat) & 0x1f) == 0x03) + if ((readl(mdstat) & 0x3f) == 0x03) return; /* Already on and enabled */ writel(readl(mdctl) | 0x03, mdctl); @@ -114,7 +114,7 @@ void lpsc_on(unsigned int id) while (readl(ptstat) & 0x01) continue; - while ((readl(mdstat) & 0x1f) != 0x03) + while ((readl(mdstat) & 0x3f) != 0x03) continue; } ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] powerpc/85xx: Add support for setting up RAID engine liodns on P5020
Add support for Job Queue/Ring LIODN for the RAID Engine on P5020. Each
Job Queue/Ring combo needs one id assigned for a total of 4 (2 JQs/2
Rings per JQ). This just handles RAID Engine in non-DPAA mode.
Signed-off-by: Santosh Shukla
Signed-off-by: Kumar Gala
---
* Removed typedef
arch/powerpc/cpu/mpc85xx/liodn.c | 25 -
arch/powerpc/cpu/mpc85xx/p5020_ids.c | 13 +
arch/powerpc/include/asm/fsl_liodn.h | 11 ++-
arch/powerpc/include/asm/fsl_portals.h |3 +++
arch/powerpc/include/asm/immap_85xx.h | 19 +++
include/configs/P5020DS.h |1 +
6 files changed, 70 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/liodn.c b/arch/powerpc/cpu/mpc85xx/liodn.c
index bd19094..e0ea502 100644
--- a/arch/powerpc/cpu/mpc85xx/liodn.c
+++ b/arch/powerpc/cpu/mpc85xx/liodn.c
@@ -1,5 +1,5 @@
/*
- * Copyright 2008-2010 Freescale Semiconductor, Inc.
+ * Copyright 2008-2011 Freescale Semiconductor, Inc.
*
* See file CREDITS for list of people who contributed to this
* project.
@@ -120,6 +120,19 @@ static void setup_pme_liodn_base(void)
#endif
}
+#ifdef CONFIG_SYS_FSL_RAID_ENGINE
+static void setup_raide_liodn_base(void)
+{
+ struct ccsr_raide *raide = (void *)CONFIG_SYS_FSL_RAID_ENGINE_ADDR;
+
+ /* setup raid engine liodn base for data/desc ; both set to 47 */
+ u32 base = (liodn_bases[FSL_HW_PORTAL_RAID_ENGINE].id[0] << 16) |
+ liodn_bases[FSL_HW_PORTAL_RAID_ENGINE].id[0];
+
+ out_be32(&raide->liodnbr, base);
+}
+#endif
+
void set_liodns(void)
{
/* setup general liodn offsets */
@@ -145,6 +158,12 @@ void set_liodns(void)
#endif
/* setup PME liodn base */
setup_pme_liodn_base();
+
+#ifdef CONFIG_SYS_FSL_RAID_ENGINE
+ /* raid engine ccr addr code for liodn */
+ set_liodn(raide_liodn_tbl, raide_liodn_tbl_sz);
+ setup_raide_liodn_base();
+#endif
}
static void fdt_fixup_liodn_tbl(void *blob, struct liodn_id_table *tbl, int sz)
@@ -184,4 +203,8 @@ void fdt_fixup_liodn(void *blob)
#endif
#endif
fdt_fixup_liodn_tbl(blob, sec_liodn_tbl, sec_liodn_tbl_sz);
+
+#ifdef CONFIG_SYS_FSL_RAID_ENGINE
+ fdt_fixup_liodn_tbl(blob, raide_liodn_tbl, raide_liodn_tbl_sz);
+#endif
}
diff --git a/arch/powerpc/cpu/mpc85xx/p5020_ids.c
b/arch/powerpc/cpu/mpc85xx/p5020_ids.c
index 9836588..2911c13 100644
--- a/arch/powerpc/cpu/mpc85xx/p5020_ids.c
+++ b/arch/powerpc/cpu/mpc85xx/p5020_ids.c
@@ -97,6 +97,16 @@ struct liodn_id_table sec_liodn_tbl[] = {
};
int sec_liodn_tbl_sz = ARRAY_SIZE(sec_liodn_tbl);
+#ifdef CONFIG_SYS_FSL_RAID_ENGINE
+struct liodn_id_table raide_liodn_tbl[] = {
+ SET_RAID_ENGINE_JQ_LIODN_ENTRY(0, 0, 60),
+ SET_RAID_ENGINE_JQ_LIODN_ENTRY(0, 1, 61),
+ SET_RAID_ENGINE_JQ_LIODN_ENTRY(1, 0, 62),
+ SET_RAID_ENGINE_JQ_LIODN_ENTRY(1, 1, 63),
+};
+int raide_liodn_tbl_sz = ARRAY_SIZE(raide_liodn_tbl);
+#endif
+
struct liodn_id_table liodn_bases[] = {
[FSL_HW_PORTAL_SEC] = SET_LIODN_BASE_2(64, 100),
#ifdef CONFIG_SYS_DPAA_FMAN
@@ -105,4 +115,7 @@ struct liodn_id_table liodn_bases[] = {
#ifdef CONFIG_SYS_DPAA_PME
[FSL_HW_PORTAL_PME] = SET_LIODN_BASE_2(136, 172),
#endif
+#ifdef CONFIG_SYS_FSL_RAID_ENGINE
+ [FSL_HW_PORTAL_RAID_ENGINE] = SET_LIODN_BASE_1(47),
+#endif
};
diff --git a/arch/powerpc/include/asm/fsl_liodn.h
b/arch/powerpc/include/asm/fsl_liodn.h
index 801571f..9ad104e 100644
--- a/arch/powerpc/include/asm/fsl_liodn.h
+++ b/arch/powerpc/include/asm/fsl_liodn.h
@@ -147,9 +147,18 @@ extern void fdt_fixup_liodn(void *blob);
offsetof(ccsr_sec_t, decoliodnr[num].ls) + \
CONFIG_SYS_FSL_SEC_OFFSET, 0)
+#define SET_RAID_ENGINE_JQ_LIODN_ENTRY(jqNum, rNum, liodnA) \
+ SET_LIODN_ENTRY_1("fsl,raideng-v1.0-job-ring", \
+ liodnA, \
+ offsetof(struct ccsr_raide, jq[jqNum].ring[rNum].cfg1) + \
+ CONFIG_SYS_FSL_RAID_ENGINE_OFFSET, \
+ offsetof(struct ccsr_raide, jq[jqNum].ring[rNum].cfg0) + \
+ CONFIG_SYS_FSL_RAID_ENGINE_OFFSET)
+
extern struct liodn_id_table liodn_tbl[], liodn_bases[], sec_liodn_tbl[];
+extern struct liodn_id_table raide_liodn_tbl[];
extern struct liodn_id_table fman1_liodn_tbl[], fman2_liodn_tbl[];
-extern int liodn_tbl_sz, sec_liodn_tbl_sz;
+extern int liodn_tbl_sz, sec_liodn_tbl_sz, raide_liodn_tbl_sz;
extern int fman1_liodn_tbl_sz, fman2_liodn_tbl_sz;
#endif
diff --git a/arch/powerpc/include/asm/fsl_portals.h
b/arch/powerpc/include/asm/fsl_portals.h
index e1c1212..8c3ea0b 100644
--- a/arch/powerpc/include/asm/fsl_portals.h
+++ b/arch/powerpc/include/asm/fsl_portals.h
@@ -35,6 +35,9 @@ enum fsl_dpaa_dev {
#ifdef CONFIG_SYS_DPAA_PME
FSL_HW_PORTAL_PME,
#endif
+#ifdef CONFIG_SYS_FSL_RAID_ENGINE
+ FSL_HW_PORTAL_RAID_ENGINE,
+#endif
};
struct qportal_info {
diff --git a/arch/powerpc/include/asm/immap_85xx.h
b/arch/powerpc/include/asm/immap_85xx.h
in
Re: [U-Boot] [Patch v2 7/7] powerpc/8xxx: Add support for interactive DDR programming interface
On Aug 26, 2011, at 1:32 PM, York Sun wrote: > Interactive DDR debugging provides a user interface to view and modify SPD, > DIMM parameters, board options and DDR controller registers before DDR is > initialized. With this feature, developers can fine-tune DDR for board > bringup and other debugging without frequently having to reprogram the flash. > > To enable this feature, define CONFIG_FSL_DDR_INTERACTIVE in board header > file and set an environment variable to activate it. Syntax: > > setenv ddr_interactive on > > After reset, U-boot prompts before initializing DDR controllers > FSL DDR> > > The available commands are > print print SPD and intermediate computed data > reset reboot machine > recompute reload SPD and options to default and recompute regs > edit modify spd, parameter, or option > computerecompute registers from current next_step to end > next_step shows current next_step > help this message > go program the memory controller and continue with u-boot > > The first command should be "compute", which reads data from DIMM SPDs and > board options, performs the calculation then stops before setting DDR > controller. A user can use "print" and "edit" commands to view and modify > anything. "Go" picks up from current step with any modification and > compltes the calculation then enables the DDR controller to continue u-boot. > "Recompute" does it over from fresh reading. > > Signed-off-by: York Sun > --- > arch/powerpc/cpu/mpc8xxx/ddr/Makefile |3 +- > arch/powerpc/cpu/mpc8xxx/ddr/ddr.h | 40 +- > arch/powerpc/cpu/mpc8xxx/ddr/interactive.c | 1691 > arch/powerpc/cpu/mpc8xxx/ddr/main.c|9 +- > doc/README.fsl-ddr | 18 + > 5 files changed, 1744 insertions(+), 17 deletions(-) > create mode 100644 arch/powerpc/cpu/mpc8xxx/ddr/interactive.c > > diff --git a/arch/powerpc/cpu/mpc8xxx/ddr/Makefile b/arch/powe Add to README the new CONFIG_FSL_DDR_INTERACTIVE define. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] altbootcmd and failbootcmd
I already have configured and built and have running u-boot and booting Linux on my custom MPC8313 based board, all ok so far. I am now trying to enable the altbootcmd and failbootcmd features so in the event of a image failure or non linux boot I can reboot to a known working image set. I have tried setting CONFIG_POST and get "__POST_WORD_ADDR currently not implemented for this platform". How do I implement/set this ? I have tried setting CONFIG_BOOTCOUNT_LIMIT and get message error QE_MURAM_SIZE undeclared. Any ideas on this one ? Grateful for any help. Regards Tom Johnson ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] armv7: only call save_boot_params for OMAP
save_boot_params in start.S got called for all armv7 based cpus. Since the function relys on the OMAP specific bootloader this broke some boards (or to be specific added more errors to already broken ones). This patch wraps the call in #ifdef CONFIG_OMAP. Signed-off-by: Simon Schwarz --- arch/arm/cpu/armv7/start.S |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S index db8e9d2..7cb380c 100644 --- a/arch/arm/cpu/armv7/start.S +++ b/arch/arm/cpu/armv7/start.S @@ -134,7 +134,9 @@ IRQ_STACK_START_IN: */ reset: +#ifdef CONFIG_OMAP bl save_boot_params +#endif /* * set the cpu to SVC32 mode */ -- 1.7.4.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] armv7: only call save_boot_params for OMAP
Hi Simon, On Friday 16 September 2011 09:02 PM, Simon Schwarz wrote: > save_boot_params in start.S got called for all armv7 based cpus. Since the > function relys on the OMAP specific bootloader this broke some boards > (or to be specific added more errors to already broken ones). This patch > wraps the call in #ifdef CONFIG_OMAP. There is a weakly linked default function implemented in armv7/cpu.c. So, there should not be any build break for u-boot builds. However armv7/cpu.c is not included in an SPL build, so may cause trouble for SPL build of non-OMAP boards. The solution for this problem is the following: --- a/arch/arm/cpu/armv7/Makefile +++ b/arch/arm/cpu/armv7/Makefile @@ -29,9 +29,9 @@ START := start.o ifndef CONFIG_SPL_BUILD COBJS += cache_v7.o -COBJS += cpu.o endif +COBJS += cpu.o COBJS += syslib.o SRCS := $(START:.o=.S) $(COBJS:.o=.c) Let me know if I am missing something. best regards, Aneesh > > Signed-off-by: Simon Schwarz > --- > arch/arm/cpu/armv7/start.S |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S > index db8e9d2..7cb380c 100644 > --- a/arch/arm/cpu/armv7/start.S > +++ b/arch/arm/cpu/armv7/start.S > @@ -134,7 +134,9 @@ IRQ_STACK_START_IN: > */ > > reset: > +#ifdef CONFIG_OMAP > bl save_boot_params > +#endif > /* >* set the cpu to SVC32 mode >*/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] SPL: Make path to start.S configurable
On 09/15/2011 06:02 PM, Marek Vasut wrote: > On Friday, September 16, 2011 12:54:26 AM Scott Wood wrote: >> How about: >> >> ifdef CONFIG_SPL_START_FILE >> START := $(subst ",,$(CONFIG_SPL_START_FILE)) >> else >> START := $(CPUDIR)/start.o >> endif >> >> START_PATH := $(dir $(START)) >> >>> LIBS-y += arch/$(ARCH)/lib/lib$(ARCH).o >>> LIBS-y += $(CPUDIR)/lib$(CPU).o >>> >>> @@ -119,7 +125,7 @@ $(obj)u-boot-spl: depend $(START) $(LIBS) >>> $(obj)u-boot-spl.lds >>> >>> $(GEN_UBOOT) >>> >>> $(START): depend >>> >>> - $(MAKE) -C $(SRCTREE)/$(CPUDIR) $@ >>> + $(MAKE) -C $(SRCTREE)/$(START_PATH) $@ >> >> Yay recursive make. :-P > > Yea ... that's why that START_PATH is needed. Does START_PATH := $(dir $(START)) not work? -scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] SPL: Make path to start.S configurable
On Friday, September 16, 2011 06:16:15 PM Scott Wood wrote: > On 09/15/2011 06:02 PM, Marek Vasut wrote: > > On Friday, September 16, 2011 12:54:26 AM Scott Wood wrote: > >> How about: > >> > >> ifdef CONFIG_SPL_START_FILE > >> START := $(subst ",,$(CONFIG_SPL_START_FILE)) > >> else > >> START := $(CPUDIR)/start.o > >> endif > >> > >> START_PATH := $(dir $(START)) > >> > >>> LIBS-y += arch/$(ARCH)/lib/lib$(ARCH).o > >>> LIBS-y += $(CPUDIR)/lib$(CPU).o > >>> > >>> @@ -119,7 +125,7 @@ $(obj)u-boot-spl: depend $(START) $(LIBS) > >>> $(obj)u-boot-spl.lds > >>> > >>> $(GEN_UBOOT) > >>> > >>> $(START):depend > >>> > >>> - $(MAKE) -C $(SRCTREE)/$(CPUDIR) $@ > >>> + $(MAKE) -C $(SRCTREE)/$(START_PATH) $@ > >> > >> Yay recursive make. :-P > > > > Yea ... that's why that START_PATH is needed. > > Does START_PATH := $(dir $(START)) not work? What if you then wanted to have start.o for SPL in x/y/spl/start_spl.o with START_PATH=x/y and START=spl/start_spl.o ? In currect patch, the spl code can be easily extended to support this. Cheers ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] devkit8000: Fix build break
From: Sandeep Paulraj Found a build erros when i ran MAKEALL. So fix it. Signed-off-by: Sandeep Paulraj --- arch/arm/include/asm/omap_common.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/include/asm/omap_common.h b/arch/arm/include/asm/omap_common.h index 015cede..66d6b71 100644 --- a/arch/arm/include/asm/omap_common.h +++ b/arch/arm/include/asm/omap_common.h @@ -45,7 +45,7 @@ void preloader_console_init(void); #define BOOT_DEVICE_ONE_NAND 4 #define BOOT_DEVICE_MMC1 5 #define BOOT_DEVICE_MMC2 6 -#elif CONFIG_OMAP34XX /* OMAP3 */ +#elif defined(CONFIG_OMAP34XX) /* OMAP3 */ #define BOOT_DEVICE_NONE 0 #define BOOT_DEVICE_XIP1 #define BOOT_DEVICE_NAND 2 -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Fastboot gadget
This series contains a smaller version of the fastboot gadget. I removed the flash/mmc/write to media part and re-add once I'm through with this basic thing :) This "basic" gadget supports the retrieval of variables (like serial number), reboot functionality, download of binary data and booting them in case the binary data is a bootable image. I did not include the fastboot client in this series. Remy asked about this. I could take it and stash it in tools if someone really wants this to have. This would include the fastboot and libzipfile folder from Andorid's system/core repository. An online version can be found at [0]. I haven't seen the library somewhere else than Android. For basic testing, the library could be excluded. [0] http://www.netmite.com/android/mydroid/system/core/ Sebastian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] image: add support for Android's boot image format
This patch adds support for the Android boot-image format. The header
file is from the Android project and got slightly alterted so the struct +
its defines are not generic but have something like a namespace. The
header file is from bootloader/legacy/include/boot/bootimg.h. The header
parsing has been written from scratch and I looked at
bootloader/legacy/usbloader/usbloader.c for some details.
The image contains the physical address (load address) of the kernel and
ramdisk. This address is considered only for the kernel image.
The "second image" is currently ignored. I haven't found anything that
is creating this.
Cc: Wolfgang Denk
Signed-off-by: Sebastian Andrzej Siewior
---
common/cmd_bootm.c | 87 +-
common/image.c | 17 +
include/android_image.h | 89 +++
include/image.h |4 ++
4 files changed, 196 insertions(+), 1 deletions(-)
create mode 100644 include/android_image.h
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 272d879..3e6d120 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
#if defined(CONFIG_CMD_USB)
#include
@@ -211,10 +212,33 @@ static void bootm_start_lmb(void)
#endif
}
+#ifdef CONFIG_ANDROID_BOOT_IMAGE
+static u32 android_img_get_end(struct andr_img_hdr *hdr)
+{
+ u32 size = 0;
+ /*
+* The header takes a full page, the remaining components are aligned
+* on page boundary
+*/
+ size += hdr->page_size;
+ size += ALIGN(hdr->kernel_size, hdr->page_size);
+ size += ALIGN(hdr->ramdisk_size, hdr->page_size);
+ size += ALIGN(hdr->second_size, hdr->page_size);
+
+ return size;
+}
+
+static u32 andoir_img_get_kload(struct andr_img_hdr *hdr)
+{
+ return hdr->kernel_addr;
+}
+#endif
+
static int bootm_start(cmd_tbl_t *cmdtp, int flag, int argc, char * const
argv[])
{
void*os_hdr;
int ret;
+ int img_type;
memset ((void *)&images, 0, sizeof (images));
images.verify = getenv_yesno ("verify");
@@ -230,7 +254,8 @@ static int bootm_start(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv[]
}
/* get image parameters */
- switch (genimg_get_format (os_hdr)) {
+ img_type = genimg_get_format(os_hdr);
+ switch (img_type) {
case IMAGE_FORMAT_LEGACY:
images.os.type = image_get_type (os_hdr);
images.os.comp = image_get_comp (os_hdr);
@@ -272,6 +297,16 @@ static int bootm_start(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv[]
}
break;
#endif
+#ifdef CONFIG_ANDROID_BOOT_IMAGE
+ case IMAGE_FORMAT_ANDROID:
+ images.os.type = IH_TYPE_KERNEL;
+ images.os.comp = IH_COMP_NONE;
+ images.os.os = IH_OS_LINUX;
+
+ images.os.end = android_img_get_end(os_hdr);
+ images.os.load = andoir_img_get_kload(os_hdr);
+ break;
+#endif
default:
puts ("ERROR: unknown image format type!\n");
return 1;
@@ -289,6 +324,10 @@ static int bootm_start(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv[]
return 1;
}
#endif
+#ifdef CONFIG_ANDROID_BOOT_IMAGE
+ } else if (img_type == IMAGE_FORMAT_ANDROID) {
+ images.ep = images.os.load;
+#endif
} else {
puts ("Could not find kernel entry point!\n");
return 1;
@@ -821,6 +860,36 @@ static int fit_check_kernel (const void *fit, int
os_noffset, int verify)
}
#endif /* CONFIG_FIT */
+#ifdef CONFIG_ANDROID_BOOT_IMAGE
+static char andr_tmp_str[ANDR_BOOT_ARGS_SIZE + 1];
+static int android_image_get_kernel(struct andr_img_hdr *hdr, int verify)
+{
+ /*
+* Not all Android tools use the id field for signing the image with
+* sha1 (or anything) so we don't check it. It is not obvious that the
+* string is null terminated so we take care of this.
+*/
+ strncpy(andr_tmp_str, hdr->name, ANDR_BOOT_NAME_SIZE);
+ andr_tmp_str[ANDR_BOOT_NAME_SIZE] = '\0';
+ if (strlen(andr_tmp_str))
+ printf("Android's image name: %s\n", andr_tmp_str);
+
+ printf("Kernel load addr 0x%08x size %u KiB\n",
+ hdr->kernel_addr, DIV_ROUND_UP(hdr->kernel_size, 1024));
+ strncpy(andr_tmp_str, hdr->cmdline, ANDR_BOOT_ARGS_SIZE);
+ andr_tmp_str[ANDR_BOOT_ARGS_SIZE] = '\0';
+ if (strlen(andr_tmp_str)) {
+ printf("Kernel command line: %s\n", andr_tmp_str);
+ setenv("bootargs", andr_tmp_str);
+ }
+ if (hdr->ramdisk_size)
+ printf("RAM disk load addr 0x%08x size %u KiB\n",
+ hdr->ramdisk_addr,
+
[U-Boot] [Example 3/3] fastboot: add board specific implementation
This is just an example how the board specific implementation can look
like. Not for merging.
Signed-off-by: Sebastian Andrzej Siewior
---
board/ti/sdp4430/Makefile |7 ---
board/ti/sdp4430/fastboot.c | 36
2 files changed, 40 insertions(+), 3 deletions(-)
create mode 100644 board/ti/sdp4430/fastboot.c
diff --git a/board/ti/sdp4430/Makefile b/board/ti/sdp4430/Makefile
index 12f2743..89226ab 100644
--- a/board/ti/sdp4430/Makefile
+++ b/board/ti/sdp4430/Makefile
@@ -26,11 +26,12 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(BOARD).o
ifndef CONFIG_SPL_BUILD
-COBJS := sdp.o cmd_bat.o
+COBJS-y:= sdp.o cmd_bat.o
+COBJS-$(CONFIG_CMD_FASTBOOT) += fastboot.o
endif
-SRCS := $(COBJS:.o=.c)
-OBJS := $(addprefix $(obj),$(COBJS))
+SRCS := $(COBJS-y:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS-y))
$(LIB):$(obj).depend $(OBJS)
$(call cmd_link_o_target, $(OBJS))
diff --git a/board/ti/sdp4430/fastboot.c b/board/ti/sdp4430/fastboot.c
new file mode 100644
index 000..9f2c0d4
--- /dev/null
+++ b/board/ti/sdp4430/fastboot.c
@@ -0,0 +1,36 @@
+#include
+#include
+#include
+#include
+
+static struct usb_string def_usb_fb_strings[] = {
+ { FB_STR_SERIAL_IDX,"abcd+efg" },
+ { FB_STR_PROC_REV_IDX, "ES0.0" },
+ { FB_STR_PROC_TYPE_IDX, "VirtIO" },
+ { }
+};
+
+static struct usb_gadget_strings def_fb_strings = {
+ .language = 0x0409, /* en-us */
+ .strings= def_usb_fb_strings,
+};
+
+/*
+ * Hardcoded memory region to stash data which comes over USB before it is
+ * stored on media
+ */
+DECLARE_GLOBAL_DATA_PTR;
+#define SZ_16M 0x0100
+#define SZ_128M 0x0800
+#define CFG_FASTBOOT_TRANSFER_BUFFER (void *)(gd->bd->bi_dram[0].start +
SZ_16M)
+#define CFG_FASTBOOT_TRANSFER_BUFFER_SIZE (SZ_128M - SZ_16M)
+
+int fastboot_board_init(struct fastboot_config *interface,
+ struct usb_gadget_strings **str) {
+
+ interface->transfer_buffer = CFG_FASTBOOT_TRANSFER_BUFFER;
+ interface->transfer_buffer_size = CFG_FASTBOOT_TRANSFER_BUFFER_SIZE;
+
+ *str = &def_fb_strings;
+ return 0;
+}
--
1.7.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] usb/gadget: add the fastboot gadget
This patch contains an implementation of the fastboot protocol on the
device side and a little of documentation.
The gadget expects the new-style gadget framework.
The gadget implements the getvar, reboot, download and reboot commands.
What is missing is the flash handling i.e. writting the image to media.
Signed-off-by: Sebastian Andrzej Siewior
---
common/Makefile |2 +
common/cmd_fastboot.c| 28 ++
doc/README.android-fastboot | 86 ++
doc/README.android-fastboot-protocol | 170 +++
drivers/usb/gadget/Makefile |5 +
drivers/usb/gadget/f_fastboot.c | 549 ++
drivers/usb/gadget/g_fastboot.h | 20 ++
drivers/usb/gadget/u_fastboot.c | 308 +++
include/usb/fastboot.h | 95 ++
9 files changed, 1263 insertions(+), 0 deletions(-)
create mode 100644 common/cmd_fastboot.c
create mode 100644 doc/README.android-fastboot
create mode 100644 doc/README.android-fastboot-protocol
create mode 100644 drivers/usb/gadget/f_fastboot.c
create mode 100644 drivers/usb/gadget/g_fastboot.h
create mode 100644 drivers/usb/gadget/u_fastboot.c
create mode 100644 include/usb/fastboot.h
diff --git a/common/Makefile b/common/Makefile
index d662468..da40d64 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -157,6 +157,8 @@ COBJS-y += cmd_usb.o
COBJS-y += usb.o
COBJS-$(CONFIG_USB_STORAGE) += usb_storage.o
endif
+COBJS-$(CONFIG_CMD_FASTBOOT) += cmd_fastboot.o
+
COBJS-$(CONFIG_CMD_XIMG) += cmd_ximg.o
COBJS-$(CONFIG_YAFFS2) += cmd_yaffs2.o
diff --git a/common/cmd_fastboot.c b/common/cmd_fastboot.c
new file mode 100644
index 000..9a656dd
--- /dev/null
+++ b/common/cmd_fastboot.c
@@ -0,0 +1,28 @@
+#include
+#include
+#include
+
+static int do_fastboot(cmd_tbl_t *cmdtp, int flag, int argc, char *const
argv[])
+{
+ int ret = 1;
+
+ if (!fastboot_init()) {
+ printf("Fastboot entered...\n");
+
+ ret = 0;
+
+ while (1) {
+ if (fastboot_poll())
+ break;
+ }
+ }
+
+ fastboot_shutdown();
+ return ret;
+}
+
+U_BOOT_CMD(
+ fastboot, 1, 1, do_fastboot,
+ "fastboot- use USB Fastboot protocol\n",
+ ""
+);
diff --git a/doc/README.android-fastboot b/doc/README.android-fastboot
new file mode 100644
index 000..4b2a9aa
--- /dev/null
+++ b/doc/README.android-fastboot
@@ -0,0 +1,86 @@
+Android Fastboot
+
+
+Overview
+
+The protocol that is used over USB is described in
+README.android-fastboot-protocol in same folder.
+
+The current implementation does not yet support the flash and erase
+commands.
+
+Client installation
+===
+The counterpart to this gadget is the fastboot client which can
+be found in Android's platform/system/core repository in the fastboot
+folder. It runs on Windows, Linux and even OSx. Linux user are lucky since
+they only need libusb.
+Windows users need to bring some time until they have Android SDK (currently
+http://dl.google.com/android/installer_r12-windows.exe) installed. You
+need to install ADB package which contains the required glue libraries for
+accessing USB. Also you need "Google USB driver package" and "SDK platform
+tools". Once installed the usb driver is placed in your SDK folder under
+extras\google\usb_driver. The android_winusb.inf needs a line like
+
+ %SingleBootLoaderInterface% = USB_Install, USB\VID_0451&PID_D022
+
+either in the [Google.NTx86] section for 32bit Windows or [Google.NTamd64]
+for 64bit Windows. VID and PID should match whatever the fastboot is
+advertising.
+
+Board specific
+==
+The gadget calls at probe time the function fastboot_board_init() which
+should be provided by the board to setup its specific configuration.
+It is possible here to overwrite specific strings like Vendor or Serial
+number. Strings which are not specified here will return a default value.
+This init function must also provide a memory area for the
+"transfer_buffer" and its size. This buffer should be large enough to hold
+whatever the download commands is willing to send or it will fail. This
+can be a kernel image for booting which could be around two MiB or a flash
+partition which could be slightly larger :)
+
+In Action
+=
+Enter into fastboot by executing the fastboot command in u-boot and you
+should see:
+|Fastboot entered...
+
+The gadget terminates once the is unplugged. On the client side you can
+fetch the product name for instance:
+|>fastboot getvar product
+|product: Default Product
+|finished. total time: 0.016s
+
+or initiate a reboot:
+|>fastboot reboot
+
+and once the client comes back, the board should reset.
+
+You can also specify a kernel image to boot. You have to either specify
+the an image in Android format _or_ pass a binary kernel and let the
+fastboot client wrap the And
Re: [U-Boot] [RFC] ARM ISA/cpu/SoC code organization for cache and other functions
Le 16/09/2011 01:18, Jason a écrit : > On Thu, Sep 15, 2011 at 07:10:49PM -0400, Jason wrote: >> Albert, >> >> On Thu, Sep 15, 2011 at 11:42:12PM +0200, Albert ARIBAUD wrote: >>> (re-posting cleaned up and outside any other discussion) >>> >>> This RFC is for discussing how cache operation functions should be >>> managed in the ARM tree. >> ... >>> The source code implementation for ARM cache ops would be: >>> >>> - a header file declaring the ops as weak C functions for at least full >>> cache flush, full cache invalidate, cache line flush and cache line >>> invalidate; >>> >>> - SoC-specific, cpu-specific, and isa-specific definitions for these >>> functions, in the form of C files. >>> >>> - a default implementation in a lib/ file. >>> >>> The object files shall be linked in decreasing precedence order, i.e. >>> SoC file first, then cpu file, then isa file, then lib last, so that for >>> each cache op, the weak symbol mechanism uses the most specific one. >>> >>> One possible organisation for files would be (switch to fixed size font) >>> >>> (isa) (cpu) SoC) >>> arch/arm >>> /armv5t/ >>> cache-ops.c >>> arm926ejs/ >>> cache-ops.c >>> orion5x/ >>> cache-ops.c >>> >>> Plus of course arch/arm/lib/cache-ops.c. >> >> As a new-comer to the u-boot code, is there a difference between this >> implementation and say, a struct of function pointers? eg the struct >> would default to armv5t ops, and arm926ejs init could redefine, say, > > s/redefine/reassign/ > >> cache line invalidate. >> >> The reason I ask is that I think the struct of function pointers would >> be easier for new folks to sort out with cscope, et al. Whereas, the >> weak declarations with multiple implementations would muddy the waters >> when learning the code. >> >> Am I missing something? What are the advantages of weak declarations >> over redefined function pointers? At first sight, implementing weak symbols through pointers might look more understandable because is leverages on C concepts such as pointers, which are better known than weak symbols. However, the simplicity of the base concept must be paid for, in complexity of handling: you need to initialize these pointers, you need to make sure they are initialized the right way, and that no initialization is missed. You also pay in performance, as each access to the weak symbol means a pointer indirection. Last, and not least, the concept of weak symbols is purely a link-time question ; it is only one variant in the ways the linker determines the value of each symbol. Why, then, implement it in run-time? So yes, you could re-implement weak symbols at run time with (arrays of) pointers, but you would not gain clarity overall, and you would distract the reader's attention from what is actually going on by explicitly interposing an implementation. OTOH, weak symbols, as implemented by gcc, simply tell the linker that if a symbol is defined more than once, the linker should do nothing rather than complain, and keep the first definition. End of story. :) I *think* what worries you is that when defining a weak symbol, you don't necessarily tell the reader that this symbol is weak, and he might have a hard time finding out. That's a valid point: although the symbol also has a declaration which explicitly says it is weak, the reader might not look up that declaration. But the solution is easy: just add a C comment before the symbol, reminding the reader that the symbol is weak and why it is, and/or referring him/her to the ./doc/README.xxx file which explains it. >> thx, You're welcome. >> Jason. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] image: add support for Android's boot image format
On Friday, September 16, 2011 12:51:17 Sebastian Andrzej Siewior wrote: > +#ifdef CONFIG_ANDROID_BOOT_IMAGE we already have a standard here: CONFIG_BOOTM_ANDROID > +static u32 andoir_img_get_kload(struct andr_img_hdr *hdr) looks like you missed a "d" in that "andoir" -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] image: add support for Android's boot image format
On 09/16/2011 08:22 PM, Mike Frysinger wrote: > On Friday, September 16, 2011 12:51:17 Sebastian Andrzej Siewior wrote: >> +#ifdef CONFIG_ANDROID_BOOT_IMAGE > > we already have a standard here: CONFIG_BOOTM_ANDROID Ehm. Can't follow. If you want me to s/CONFIG_ANDROID_BOOT_IMAGE /CONFIG_BOOTM_ANDROID/ I sure can do this. The uImage has no CONFIG around it and the other format has CONFIG_FIT around it. A grep for CONFIG_BOOTM_ returns LINUX, NETBSD and others. They differ in the calling ABI, argument passing etc. I do boot here a Linux image but not from an uImage. >> +static u32 andoir_img_get_kload(struct andr_img_hdr *hdr) > > looks like you missed a "d" in that "andoir" yup, fixing, thanks. > -mike Sebastian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [u-boot-release] [Patch v3 7/7] powerpc/8xxx: Add support for interactive DDR programming interface
York Sun wrote: > +Interactive DDR debugging > +=== > + > +For DDR parameter tuning up and debugging, the interactive DDR debugging can > +be activated by saving an environment variable "ddr_interactive". The value > +doesn't matter. Once activated, U-boot prompts "FSL DDR>" before enabling DDR > +controller. The available commands can be seen by typing "help". > + > +The example flow of using interactive debugging is > +type command "compute" to calculate the parameters from the default > +type command "print" with arguments to show SPD, options, registers > +type command "edit" with arguments to change any if desired > +type command "go" to continue calculation and enable DDR controller > + > +Note, check "next_step" to show the flow. For example, after editing > registers, > +DDR controller will be enabled with current setting without further > +calculation. This is pretty skimpy for such a powerful feature. How about some examples and a detailed description of each command? -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 27/31] M28: Save environment in NAND
On 09/08/2011 03:42 PM, Marek Vasut wrote: > Signed-off-by: Marek Vasut > Cc: Stefano Babic > Cc: Wolfgang Denk > Cc: Detlev Zundel > --- > include/configs/m28evk.h | 11 +-- > 1 files changed, 9 insertions(+), 2 deletions(-) > > diff --git a/include/configs/m28evk.h b/include/configs/m28evk.h > index 0d4a0a3..c120c63 100644 > --- a/include/configs/m28evk.h > +++ b/include/configs/m28evk.h > @@ -131,6 +131,15 @@ > #define CONFIG_SYS_NAND_5_ADDR_CYCLE > #define NAND_MAX_CHIPS 8 > > +/* Environment is in NAND */ > +#define CONFIG_ENV_IS_IN_NAND 1 > +#define CONFIG_ENV_SECT_SIZE(128 * 1024) > +#define CONFIG_ENV_SIZE (16 * 1024) > +#define CONFIG_ENV_SIZE_REDUND CONFIG_ENV_SIZE > +#define CONFIG_ENV_OFFSET 0x30 > +#define CONFIG_ENV_OFFSET_REDUND\ > + (CONFIG_ENV_OFFSET + CONFIG_ENV_SECT_SIZE) > + > #define CONFIG_CMD_UBI > #define CONFIG_CMD_UBIFS > #define CONFIG_CMD_MTDPARTS > @@ -230,6 +239,4 @@ > #define CONFIG_LOADADDR 0x4200 > #define CONFIG_SYS_LOAD_ADDRCONFIG_LOADADDR > > -#define CONFIG_ENV_IS_NOWHERE 1 > - > #endif /* __M28_H__ */ Consider using CONFIG_ENV_RANGE to allow for bad blocks. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [u-boot-release] [Patch v3 7/7] powerpc/8xxx: Add support for interactive DDR programming interface
On Fri, 2011-09-16 at 14:15 -0500, Timur Tabi wrote: > York Sun wrote: > > +Interactive DDR debugging > > +=== > > + > > +For DDR parameter tuning up and debugging, the interactive DDR debugging > > can > > +be activated by saving an environment variable "ddr_interactive". The value > > +doesn't matter. Once activated, U-boot prompts "FSL DDR>" before enabling > > DDR > > +controller. The available commands can be seen by typing "help". > > + > > +The example flow of using interactive debugging is > > +type command "compute" to calculate the parameters from the default > > +type command "print" with arguments to show SPD, options, registers > > +type command "edit" with arguments to change any if desired > > +type command "go" to continue calculation and enable DDR controller > > + > > +Note, check "next_step" to show the flow. For example, after editing > > registers, > > +DDR controller will be enabled with current setting without further > > +calculation. > > This is pretty skimpy for such a powerful feature. How about some examples > and > a detailed description of each command? > I think the interactive command is self-explained. I can add some examples if needed. But I am afraid the example will be either too short or too long. For example, I can add the following First step, run "compute" command, it returns with the DIMM part number FSL DDR>compute Detected UDIMM UG51U6400N8SU-ACF Second step, users can run 'print' command with arguments. Without argument, a help message will print out FSL DDR>print print [c] [d] [spd] [dimmparms] [commonparms] [opts] [addresses] [regs] FSL DDR>print dimmparms DIMM parameters: Controller=0 DIMM=0 DIMM organization parameters: module part name = UG51U6400N8SU-ACF rank_density = 2147483648 bytes (2048 megabytes) capacity = 4294967296 bytes (4096 megabytes) burst_lengths_bitmask = 0C base_addresss = 0 ( ) n_ranks = 2 data_width = 64 primary_sdram_width = 64 ec_sdram_width = 0 registered_dimm = 0 n_row_addr = 15 n_col_addr = 10 edc_config = 0 n_banks_per_sdram_device = 8 tCKmin_X_ps = 1500 tCKmin_X_minus_1_ps = 0 tCKmin_X_minus_2_ps = 0 tCKmax_ps = 0 caslat_X = 960 tAA_ps = 13125 caslat_X_minus_1 = 0 caslat_X_minus_2 = 0 caslat_lowest_derated = 0 tRCD_ps = 13125 tRP_ps = 13125 tRAS_ps = 36000 tWR_ps = 15000 tWTR_ps = 7500 tRFC_ps = 16 tRRD_ps = 6000 tRC_ps = 49125 refresh_rate_ps = 780 tIS_ps = 0 tIH_ps = 0 tDS_ps = 0 tDH_ps = 0 tRTP_ps = 7500 tDQSQ_max_ps = 0 tQHS_ps = 0 I can further show the examples of print/edit dimmparams, commonparams, opts, regs. It will be too long. It is not difficult to use the self-guided interface. Agree? York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [u-boot-release] [Patch v3 7/7] powerpc/8xxx: Add support for interactive DDR programming interface
York Sun wrote: > I think the interactive command is self-explained. Why do people say things like that? If I say that it needs to be better documented, then obviously it isn't self-explanatory. > I can add some > examples if needed. But I am afraid the example will be either too short > or too long. > > For example, I can add the following > > First step, run "compute" command, it returns with the DIMM part number > > FSL DDR>compute > Detected UDIMM UG51U6400N8SU-ACF > > Second step, users can run 'print' command with arguments. Without > argument, a help message will print out This is not an example. This is a walk-through. An example shows how individual commands can be used, and what the output could look like. > I can further show the examples of print/edit dimmparams, commonparams, > opts, regs. It will be too long. It is not difficult to use the > self-guided interface. Agree? How could it be too long? Is there not enough room on the git server to store a text file? This file could be 200KB is size, and that would be okay. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library
On 09/15/2011 06:17 PM, Marek Vasut wrote: > On Friday, September 16, 2011 12:57:44 AM Scott Wood wrote: >> On 09/11/2011 11:03 PM, Marek Vasut wrote: >>> Introduce CONFIG_SPL_NO_CPU_SUPPORT_CODE to avoid compiling the CPU >>> support library. This can be useful on some setups. >>> >>> Signed-off-by: Marek Vasut >>> Cc: Stefano Babic >>> Cc: Wolfgang Denk >>> Cc: Detlev Zundel >>> Cc: Chander Kashyap >> >> But you didn't CC these... > > git send-email should handle those ? I'm not too familiar with git send-email, but they're not in the CC list of the actual e-mail. >>> +# In case we want to avoid the CPU support code, we need to define this: >>> +ifndef CONFIG_SPL_NO_CPU_SUPPORT_CODE >>> +SPL_CPU_SUPPORT_CODE := y >>> +endif >> >> SPL should ideally contain nothing by default. Have options that say >> what you do want to pull in, not what you don't want. > > You usually DO want to pull this in (because it contains vectoring code, > really > basic lowlevel init etc), there are only border cases where you do not want > to > do that and use your own. Sorry, I was a bit confused by seeing lib$(CPU), thought at first you were trying to pull in stuff like arch/$(ARCH)/lib. Still, this seems hackish. Shouldn't the control be on specific files that you include, not directories? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] ColdFire: Move boards with simple _config rules to boards.cfg
>> -Original Message- >> From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On >> Behalf Of Stany MARCEL >> Sent: Wednesday, September 14, 2011 8:44 PM >> To: u-boot@lists.denx.de >> Cc: Jin Zhengxiong-R64188; Stany MARCEL; Jin Zhengxiong-R64188 >> Subject: [U-Boot] [PATCH 3/6] ColdFire: Move boards with simple _config rules >> to boards.cfg >> >> Signed-off-by: Stany MARCEL >> --- >> MAKEALL | 6 --- >> Makefile | 96 >> >> boards.cfg | 21 +- >> include/configs/M5329EVB.h | 8 ++-- >> 4 files changed, 24 insertions(+), 107 deletions(-) > [Jin Zhengxiong-R64188] > I suggest to put the M5329EVB update in another separate patch. Thanks. > > Best Regards, > Jason Hi Jason, The modification the M5329EVB configuration header is linked to the build modification, so I don't think it's a good idea to separate them. But if it is really necessary I can split the commit in two parts on Monday. Regards ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] ColdFire: Cleanup lds files for multiple defined symbols
>> -Original Message- >> From: Stany MARCEL [mailto:stany.mar...@novasys-ingenierie.com] >> Sent: Wednesday, September 14, 2011 8:44 PM >> To: u-boot@lists.denx.de >> Cc: Jin Zhengxiong-R64188; Jin Zhengxiong-R64188; Stany MARCEL >> Subject: [PATCH 1/6] ColdFire: Cleanup lds files for multiple defined symbols >> >> Lds files cleened to remove multiple defined section and modified to be >> compliant with --gc-sections added for ColdFire platform in a previous patch. >> >> Signed-off-by: Stany MARCEL >> --- >> board/BuS/EB+MCF-EV123/u-boot.lds | 73 ++- >> board/cobra5272/u-boot.lds | 69 ++ >> board/esd/tasreg/u-boot.lds | 69 +- >> board/freescale/m5235evb/u-boot.16 | 71 ++- >> board/freescale/m5235evb/u-boot.32 | 79 >> ++ >> board/freescale/m5249evb/u-boot.lds | 68 + >> board/freescale/m5253evbe/u-boot.lds | 67 +--- >> board/freescale/m5271evb/u-boot.lds | 66 +--- >> board/freescale/m5272c3/u-boot.lds | 67 +--- >> board/freescale/m5275evb/u-boot.lds | 68 ++--- >> board/freescale/m5282evb/u-boot.lds | 70 ++ >> board/idmr/u-boot.lds | 69 +- >> 12 files changed, 150 insertions(+), 686 deletions(-) >> > > [snip] > >> diff --git a/board/cobra5272/u-boot.lds b/board/cobra5272/u-boot.lds index >> da14807..6c2dfe8 100644 >> --- a/board/cobra5272/u-boot.lds >> +++ b/board/cobra5272/u-boot.lds >> @@ -1,5 +1,5 @@ >> /* >> - * (C) Copyright 2000 >> + * (C) Copyright 2000-2003 >> * Wolfgang Denk, DENX Software Engineering, w...@denx.de. > [Jin Zhengxiong-R64188] Please double check the year for the Copyright, > Thanks. > > Best Regards, > Jason > I merged with another files with this copyright years. Each time a file is edited do I have to actualizes end dates ? Or leave them as they are ? Regards, Stany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] DaVinci: correct MDSTAT.STATE mask
Dear Sergei Shtylyov, In message <201109161858.08706.sshtyl...@ru.mvista.com> you wrote: > MDSTAT.STATE occupies bits 0..5 according to all available documentation, so > fix > the masks which previously was leaving out the intermediate state indicator > bit. > > Signed-off-by: Sergei Shtylyov > > --- > Resending with the corrected subject/description... > Analogous Linux patch has been queued in the linux-davinci tree: > > http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2011-July/023075.html > > arch/arm/cpu/arm926ejs/davinci/lowlevel_init.S |6 +++--- > arch/arm/cpu/arm926ejs/davinci/psc.c |4 ++-- > 2 files changed, 5 insertions(+), 5 deletions(-) > > Index: u-boot/arch/arm/cpu/arm926ejs/davinci/lowlevel_init.S > === > --- u-boot.orig/arch/arm/cpu/arm926ejs/davinci/lowlevel_init.S > +++ u-boot/arch/arm/cpu/arm926ejs/davinci/lowlevel_init.S > @@ -268,7 +268,7 @@ checkStatClkStop: > checkDDRStatClkStop: > ldr r6, MDSTAT_DDR2 > ldr r7, [r6] > - and r7, r7, $0x1f > + and r7, r7, $0x3f Don't you think it's high time to replace these magic constants with at least somewhat meaningful symbolic names (so it would be sufficient to fix this in a single place) ? 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 Let's say the docs present a simplified view of reality...:-) - Larry Wall in <6...@jpl-devvax.jpl.nasa.gov> ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] image: add support for Android's boot image format
Dear Sebastian Andrzej Siewior, In message <1316191879-27214-2-git-send-email-bige...@linutronix.de> you wrote: > This patch adds support for the Android boot-image format. The header > file is from the Android project and got slightly alterted so the struct + > its defines are not generic but have something like a namespace. The > header file is from bootloader/legacy/include/boot/bootimg.h. The header > parsing has been written from scratch and I looked at > bootloader/legacy/usbloader/usbloader.c for some details. > The image contains the physical address (load address) of the kernel and > ramdisk. This address is considered only for the kernel image. > The "second image" is currently ignored. I haven't found anything that > is creating this. ... > + * Copyright (C) 2008 The Android Open Source Project > + * All rights reserved. > + * > + * Redistribution and use in source and binary forms, with or without > + * modification, are permitted provided that the following conditions > + * are met: > + * * Redistributions of source code must retain the above copyright > + *notice, this list of conditions and the following disclaimer. > + * * Redistributions in binary form must reproduce the above copyright > + *notice, this list of conditions and the following disclaimer in > + *the documentation and/or other materials provided with the > + *distribution. > + * > + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS > + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT > + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS > + * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE > + * COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, > + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, > + * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS > + * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED > + * AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, > + * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT > + * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF > + * SUCH DAMAGE. > + */ Are you 100% sure this is a GPLv2+ compatible license??? I don't think so... 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 He'd heard her use that sweet, innocent tone of voice before. It meant that, pretty soon, there was going to be trouble. - Terry Pratchett, _Truckers_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] usb/gadget: add the fastboot gadget
Dear Sebastian Andrzej Siewior, In message <1316191879-27214-3-git-send-email-bige...@linutronix.de> you wrote: > This patch contains an implementation of the fastboot protocol on the > device side and a little of documentation. > The gadget expects the new-style gadget framework. > The gadget implements the getvar, reboot, download and reboot commands. > What is missing is the flash handling i.e. writting the image to media. > > Signed-off-by: Sebastian Andrzej Siewior ... > diff --git a/drivers/usb/gadget/f_fastboot.c b/drivers/usb/gadget/f_fastboot.c > new file mode 100644 > index 000..6c3cae5 > --- /dev/null > +++ b/drivers/usb/gadget/f_fastboot.c > @@ -0,0 +1,549 @@ > +/* > + * The file is based on content which was > + * (C) Copyright 2008 - 2009 > + * Windriver, > + * Tom Rix > + * > + * but after the chainsaw attack by > + * Copyright (c) 2011 Sebastian Andrzej Siewior > + * > + * there isn't much left. The license is in both cases GPLv2 as published > + * by the FSF > + */ For U-Boot, we need GPLv2+. Please see bullet # 3 at http://www.denx.de/wiki/view/U-Boot/Patches#Attributing_Code_Copyrights_Sign and note # 1 at http://www.denx.de/wiki/view/U-Boot/Patches#Notes 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 That was the thing about deserts. They had their own gravity. They sucked you into the centre. - Terry Pratchett, _Small Gods_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL boot modes
On Fri, Sep 16, 2011 at 1:14 AM, Simon Schwarz wrote: > Hi Joel, > > The current release (based on u-boot-ti) is V9: > http://patchwork.ozlabs.org/bundle/Simon/OMAP3_SPL_V9/ > > Or V10 > http://mid.gmane.org/1315949258-12064-1-git-send-email-tr...@ti.com > (based on u-boot-arm) > > Actually this may already work (although I haven't tested it yet). If > you define CONFIG_SPL_MMC_SUPPORT and CONFIG_SPL_NAND_SUPPORT (plus the > necessary defines for them) in your board header it is looking for the > bootdevice the ROM code used and tries to load the image from it. > > If you try MMC with OMAP3 I would appreciate a message if it works or not. I've managed to port over to omap3evm and beagleboard (both xM and rev C) and boot from MMC. I haven't yet gotten NAND happy on omap3evm and will be attempting NAND on beagleboard rev C soon. And I'll post a full patch series once things work a bit more (as I've told Simon privately I had to rework the memory init hook a bit). -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Example 3/3] fastboot: add board specific implementation
Dear Sebastian Andrzej Siewior, In message <1316191879-27214-4-git-send-email-bige...@linutronix.de> you wrote: > This is just an example how the board specific implementation can look > like. Not for merging. > > Signed-off-by: Sebastian Andrzej Siewior ... > --- /dev/null > +++ b/board/ti/sdp4430/fastboot.c > @@ -0,0 +1,36 @@ > +#include > +#include > +#include > +#include Please _always_ add the required license header. 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 Lispers are among the best grads of the Sweep-It-Under-Someone- Else's-Carpet School of Simulated Simplicity. [Was that sufficiently incendiary? :-)] - Larry Wall in <1992jan10.201804.11...@netlabs.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] image: add support for Android's boot image format
On 09/16/2011 11:03 PM, Wolfgang Denk wrote: > Dear Sebastian Andrzej Siewior, Hi Wolfgang, >> + * Copyright (C) 2008 The Android Open Source Project >> + * All rights reserved. >> + * >> + * Redistribution and use in source and binary forms, with or without >> + * modification, are permitted provided that the following conditions >> + * are met: >> + * * Redistributions of source code must retain the above copyright >> + *notice, this list of conditions and the following disclaimer. >> + * * Redistributions in binary form must reproduce the above copyright >> + *notice, this list of conditions and the following disclaimer in >> + *the documentation and/or other materials provided with the >> + *distribution. >> + * >> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS >> + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT >> + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS >> + * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE >> + * COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, >> + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, >> + * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS >> + * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED >> + * AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, >> + * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT >> + * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF >> + * SUCH DAMAGE. >> + */ > > Are you 100% sure this is a GPLv2+ compatible license??? I don't think > so... How so? This is a 3-clause BSD license. According to [0] it is compatible. Is there anything I missed here? [0] http://www.gnu.org/licenses/license-list.html#ModifiedBSD > Best regards, > > Wolfgang Denk > Sebastian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] image: add support for Android's boot image format
On Friday, September 16, 2011 17:28:08 Sebastian Andrzej Siewior wrote: > On 09/16/2011 11:03 PM, Wolfgang Denk wrote: > > Dear Sebastian Andrzej Siewior, > >> + * Copyright (C) 2008 The Android Open Source Project > >> + * All rights reserved. > >> + * > >> + * Redistribution and use in source and binary forms, with or without > >> + * modification, are permitted provided that the following conditions > >> + * are met: > >> + * * Redistributions of source code must retain the above copyright > >> + *notice, this list of conditions and the following disclaimer. > >> + * * Redistributions in binary form must reproduce the above copyright > >> + *notice, this list of conditions and the following disclaimer in > >> + *the documentation and/or other materials provided with the > >> + *distribution. > >> + * > >> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS > >> + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT > >> + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS > >> + * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE > >> + * COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, > >> + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, > >> + * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; > >> LOSS + * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER > >> CAUSED + * AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT > >> LIABILITY, + * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN > >> ANY WAY OUT + * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE > >> POSSIBILITY OF + * SUCH DAMAGE. > >> + */ > > > > Are you 100% sure this is a GPLv2+ compatible license??? I don't think > > so... > > How so? This is a 3-clause BSD license. According to [0] it is > compatible. Is there anything I missed here? i think you mean 2-clause http://en.wikipedia.org/wiki/BSD_License#2- clause_license_.28.22Simplified_BSD_License.22_or_.22FreeBSD_License.22.29 -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library
On Friday, September 16, 2011 09:49:28 PM Scott Wood wrote: > On 09/15/2011 06:17 PM, Marek Vasut wrote: > > On Friday, September 16, 2011 12:57:44 AM Scott Wood wrote: > >> On 09/11/2011 11:03 PM, Marek Vasut wrote: > >>> Introduce CONFIG_SPL_NO_CPU_SUPPORT_CODE to avoid compiling the CPU > >>> support library. This can be useful on some setups. > >>> > >>> Signed-off-by: Marek Vasut > >>> Cc: Stefano Babic > >>> Cc: Wolfgang Denk > >>> Cc: Detlev Zundel > >>> Cc: Chander Kashyap > >> > >> But you didn't CC these... > > > > git send-email should handle those ? > > I'm not too familiar with git send-email, but they're not in the CC list > of the actual e-mail. > > >>> +# In case we want to avoid the CPU support code, we need to define > >>> this: +ifndef CONFIG_SPL_NO_CPU_SUPPORT_CODE > >>> +SPL_CPU_SUPPORT_CODE := y > >>> +endif > >> > >> SPL should ideally contain nothing by default. Have options that say > >> what you do want to pull in, not what you don't want. > > > > You usually DO want to pull this in (because it contains vectoring code, > > really basic lowlevel init etc), there are only border cases where you > > do not want to do that and use your own. > > Sorry, I was a bit confused by seeing lib$(CPU), thought at first you > were trying to pull in stuff like arch/$(ARCH)/lib. > > Still, this seems hackish. Shouldn't the control be on specific files > that you include, not directories? I don't think so ... why ? > > -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library
On 09/16/2011 04:38 PM, Marek Vasut wrote: > On Friday, September 16, 2011 09:49:28 PM Scott Wood wrote: >> Still, this seems hackish. Shouldn't the control be on specific files >> that you include, not directories? > > I don't think so ... why ? That's how the main U-Boot build does it... More specifically, the config.h controls should be on features, and the makefiles should decide which (if any) files are required for that feature. If there are no files from arch/$(ARCH)/cpu/$(CPU) needed, then we get an empty lib$(CPU).o -- nothing special needed to avoid it. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library
On Friday, September 16, 2011 11:42:50 PM Scott Wood wrote: > On 09/16/2011 04:38 PM, Marek Vasut wrote: > > On Friday, September 16, 2011 09:49:28 PM Scott Wood wrote: > >> Still, this seems hackish. Shouldn't the control be on specific files > >> that you include, not directories? > > > > I don't think so ... why ? > > That's how the main U-Boot build does it... More specifically, the > config.h controls should be on features, and the makefiles should decide > which (if any) files are required for that feature. If there are no > files from arch/$(ARCH)/cpu/$(CPU) needed, then we get an empty > lib$(CPU).o -- nothing special needed to avoid it. Yes, but you basically _always_ want that CPU support code in ... and I have no idea why you'd like to avoid particular files. > > -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] image: add support for Android's boot image format
On 09/16/2011 11:35 PM, Mike Frysinger wrote: > On Friday, September 16, 2011 17:28:08 Sebastian Andrzej Siewior wrote: >> On 09/16/2011 11:03 PM, Wolfgang Denk wrote: >>> Dear Sebastian Andrzej Siewior, + * Copyright (C) 2008 The Android Open Source Project + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * * Redistributions of source code must retain the above copyright + *notice, this list of conditions and the following disclaimer. + * * Redistributions in binary form must reproduce the above copyright + *notice, this list of conditions and the following disclaimer in + *the documentation and/or other materials provided with the + *distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS + * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE + * COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, + * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS + * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED + * AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, + * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT + * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ >>> >>> Are you 100% sure this is a GPLv2+ compatible license??? I don't think >>> so... >> >> How so? This is a 3-clause BSD license. According to [0] it is >> compatible. Is there anything I missed here? > > i think you mean 2-clause > http://en.wikipedia.org/wiki/BSD_License#2- > clause_license_.28.22Simplified_BSD_License.22_or_.22FreeBSD_License.22.29 Ups, sorry, Yes, I do. > -mike Sebastian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library
On 09/16/2011 04:47 PM, Marek Vasut wrote: > On Friday, September 16, 2011 11:42:50 PM Scott Wood wrote: >> On 09/16/2011 04:38 PM, Marek Vasut wrote: >>> On Friday, September 16, 2011 09:49:28 PM Scott Wood wrote: Still, this seems hackish. Shouldn't the control be on specific files that you include, not directories? >>> >>> I don't think so ... why ? >> >> That's how the main U-Boot build does it... More specifically, the >> config.h controls should be on features, and the makefiles should decide >> which (if any) files are required for that feature. If there are no >> files from arch/$(ARCH)/cpu/$(CPU) needed, then we get an empty >> lib$(CPU).o -- nothing special needed to avoid it. > > Yes, but you basically _always_ want that CPU support code in ... and I have > no > idea why you'd like to avoid particular files. You have no idea why I'd like to be extremely selective with what I include in a 4K binary? It's not about avoiding particular files. It's about including *nothing* but what is explicitly asked for through some SPL-specific CONFIG symbol. Maybe that includes everything in arch/$(ARCH)/cpu. Maybe it includes nothing in there. More likely, it includes just a fraction of it. If your answer is gc-sections, why do you need to drop the whole directory? And why waste time building entire files that we know we don't want? Why waste time debugging where the sudden bloat came from instead of getting a simple and clear undefined-symbol error? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library
On Saturday, September 17, 2011 12:07:52 AM Scott Wood wrote: > On 09/16/2011 04:47 PM, Marek Vasut wrote: > > On Friday, September 16, 2011 11:42:50 PM Scott Wood wrote: > >> On 09/16/2011 04:38 PM, Marek Vasut wrote: > >>> On Friday, September 16, 2011 09:49:28 PM Scott Wood wrote: > Still, this seems hackish. Shouldn't the control be on specific files > that you include, not directories? > >>> > >>> I don't think so ... why ? > >> > >> That's how the main U-Boot build does it... More specifically, the > >> config.h controls should be on features, and the makefiles should decide > >> which (if any) files are required for that feature. If there are no > >> files from arch/$(ARCH)/cpu/$(CPU) needed, then we get an empty > >> lib$(CPU).o -- nothing special needed to avoid it. > > > > Yes, but you basically _always_ want that CPU support code in ... and I > > have no idea why you'd like to avoid particular files. > > You have no idea why I'd like to be extremely selective with what I > include in a 4K binary? That I do understand -- but that kind of selection is there. > > It's not about avoiding particular files. It's about including > *nothing* but what is explicitly asked for through some SPL-specific > CONFIG symbol. Maybe that includes everything in arch/$(ARCH)/cpu. > Maybe it includes nothing in there. More likely, it includes just a > fraction of it. The stuff in arch/arm/cpu should be exactly what you need, nothing more ! > > If your answer is gc-sections, why do you need to drop the whole > directory? And why waste time building entire files that we know we > don't want? Why waste time debugging where the sudden bloat came from > instead of getting a simple and clear undefined-symbol error? > > -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] devkit8000: Fix build break
On Fri, Sep 16, 2011 at 9:42 AM, wrote: > From: Sandeep Paulraj > > Found a build erros when i ran MAKEALL. > So fix it. > > > Signed-off-by: Sandeep Paulraj > --- > arch/arm/include/asm/omap_common.h | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/arch/arm/include/asm/omap_common.h > b/arch/arm/include/asm/omap_common.h > index 015cede..66d6b71 100644 > --- a/arch/arm/include/asm/omap_common.h > +++ b/arch/arm/include/asm/omap_common.h > @@ -45,7 +45,7 @@ void preloader_console_init(void); > #define BOOT_DEVICE_ONE_NAND 4 > #define BOOT_DEVICE_MMC1 5 > #define BOOT_DEVICE_MMC2 6 > -#elif CONFIG_OMAP34XX /* OMAP3 */ > +#elif defined(CONFIG_OMAP34XX) /* OMAP3 */ > #define BOOT_DEVICE_NONE 0 > #define BOOT_DEVICE_XIP 1 > #define BOOT_DEVICE_NAND 2 I believe this only exists with the SPL patches merged which I thought was only in your next branch atm... -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL boot modes
On Fri, Sep 16, 2011 at 7:31 AM, Wolfgang Denk wrote: > Dear Joel A Fernandes, > > In message > you > wrote: >> >> Just one question about one of your patches I happen to notice [1], >> why is there a SPL build for each different boot mode such as for >> NAND, MMC etc?. Wouldn't it be nicer to have a single SPL loader that >> tried different boot modes one after the other, something like what >> x-load already does? Are there are any challenges with this approach? > > Yes, this would be nice. Question: how do we make this fit in - say - > the 2 KiB code size that some processors load? Including all the > drivers for NAND, MMC etc.? Hi Wolfgang, Thanks for your email. I have to admit that I am new to the SPL way of doing things but.. Based on which drivers have configured, we can cycle through the available boot modes one after the other like: #ifdef CONFIG_NAND nand_boot() #endif else #ifdef CONFIG_MMC mmc_boot() #endif etc.. This should work for boards < 2k mem I'm guessing. Also, we can allow the board to decide in which order to go through based on preferences set in the board and/or config file. For eg. (unless this is already done), it will nice if omap-like boards can read through the sysboot pins to decide which order to try the boot. What do you think? Thanks, Joel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] devkit8000: Fix build break
Le 17/09/2011 00:59, Tom Rini a écrit : > On Fri, Sep 16, 2011 at 9:42 AM, wrote: >> From: Sandeep Paulraj >> >> Found a build erros when i ran MAKEALL. >> So fix it. >> >> >> Signed-off-by: Sandeep Paulraj >> --- >> arch/arm/include/asm/omap_common.h |2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/arch/arm/include/asm/omap_common.h >> b/arch/arm/include/asm/omap_common.h >> index 015cede..66d6b71 100644 >> --- a/arch/arm/include/asm/omap_common.h >> +++ b/arch/arm/include/asm/omap_common.h >> @@ -45,7 +45,7 @@ void preloader_console_init(void); >> #define BOOT_DEVICE_ONE_NAND 4 >> #define BOOT_DEVICE_MMC1 5 >> #define BOOT_DEVICE_MMC2 6 >> -#elif CONFIG_OMAP34XX /* OMAP3 */ >> +#elif defined(CONFIG_OMAP34XX) /* OMAP3 */ >> #define BOOT_DEVICE_NONE 0 >> #define BOOT_DEVICE_XIP1 >> #define BOOT_DEVICE_NAND 2 > > I believe this only exists with the SPL patches merged which I thought > was only in your next branch atm... Confirm, from current u-boot-arm/master: uboot@lilith:~/src/u-boot-arm$ ./MAKEALL devkit8000 Configuring for devkit8000 board... textdata bss dec hex filename 2772007540 216140 500880 7a490 ./u-boot - SUMMARY Boards compiled: 1 -- uboot@lilith:~/src/u-boot-arm$ Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
