[U-Boot] [PATCH]
Dear Jean,
I made new patch about L2 cane enable/disable function.
The related thread is here.
http://www.mail-archive.com/u-boot@lists.denx.de/msg14744.html
I fixed title issue apart header.
Thanks to read :)
Best Regards,
riverful
=
omap3 L2 cache enable/disable function moved from cpu/arm_cortexa8/cpu.c
to cpu/arm_cortexa8/omap3/. for generic SoC supports.
Signed-off-by: HeungJun, Kim riverful@samsung.com
---
cpu/arm_cortexa8/cpu.c | 68 +-
cpu/arm_cortexa8/omap3/Makefile|2 +-
cpu/arm_cortexa8/omap3/board.c |5 +-
cpu/arm_cortexa8/omap3/cache.c | 99
include/asm-arm/arch-omap3/sys_proto.h |1 -
include/asm-arm/cache.h| 37
6 files changed, 143 insertions(+), 69 deletions(-)
create mode 100644 cpu/arm_cortexa8/omap3/cache.c
create mode 100644 include/asm-arm/cache.h
diff --git a/cpu/arm_cortexa8/cpu.c b/cpu/arm_cortexa8/cpu.c
index 3e1780b..96f42a9 100644
--- a/cpu/arm_cortexa8/cpu.c
+++ b/cpu/arm_cortexa8/cpu.c
@@ -35,15 +35,12 @@
#include command.h
#include asm/arch/sys_proto.h
#include asm/system.h
+#include asm/cache.h
#ifdef CONFIG_USE_IRQ
DECLARE_GLOBAL_DATA_PTR;
#endif
-#ifndef CONFIG_L2_OFF
-void l2cache_disable(void);
-#endif
-
static void cache_flush(void);
int cpu_init(void)
@@ -80,7 +77,7 @@ int cleanup_before_linux(void)
#ifndef CONFIG_L2_OFF
/* turn off L2 cache */
- l2cache_disable();
+ l2_cache_disable();
/* invalidate L2 cache also */
v7_flush_dcache_all(get_device_type());
#endif
@@ -89,71 +86,12 @@ int cleanup_before_linux(void)
asm(mcr p15, 0, %0, c7, c10, 4: :r(i));
#ifndef CONFIG_L2_OFF
- l2cache_enable();
+ l2_cache_enable();
#endif
return 0;
}
-void l2cache_enable()
-{
- unsigned long i;
- volatile unsigned int j;
-
- /* ES2 onwards we can disable/enable L2 ourselves */
- if (get_cpu_rev() = CPU_3XX_ES20) {
- __asm__ __volatile__(mrc p15, 0, %0, c1, c0, 1:=r(i));
- __asm__ __volatile__(orr %0, %0, #0x2:=r(i));
- __asm__ __volatile__(mcr p15, 0, %0, c1, c0, 1:=r(i));
- } else {
- /* Save r0, r12 and restore them after usage */
- __asm__ __volatile__(mov %0, r12:=r(j));
- __asm__ __volatile__(mov %0, r0:=r(i));
-
- /*
-* GP Device ROM code API usage here
-* r12 = AUXCR Write function and r0 value
-*/
- __asm__ __volatile__(mov r12, #0x3);
- __asm__ __volatile__(mrc p15, 0, r0, c1, c0, 1);
- __asm__ __volatile__(orr r0, r0, #0x2);
- /* SMI instruction to call ROM Code API */
- __asm__ __volatile__(.word 0xE1600070);
- __asm__ __volatile__(mov r0, %0:=r(i));
- __asm__ __volatile__(mov r12, %0:=r(j));
- }
-
-}
-
-void l2cache_disable()
-{
- unsigned long i;
- volatile unsigned int j;
-
- /* ES2 onwards we can disable/enable L2 ourselves */
- if (get_cpu_rev() = CPU_3XX_ES20) {
- __asm__ __volatile__(mrc p15, 0, %0, c1, c0, 1:=r(i));
- __asm__ __volatile__(bic %0, %0, #0x2:=r(i));
- __asm__ __volatile__(mcr p15, 0, %0, c1, c0, 1:=r(i));
- } else {
- /* Save r0, r12 and restore them after usage */
- __asm__ __volatile__(mov %0, r12:=r(j));
- __asm__ __volatile__(mov %0, r0:=r(i));
-
- /*
-* GP Device ROM code API usage here
-* r12 = AUXCR Write function and r0 value
-*/
- __asm__ __volatile__(mov r12, #0x3);
- __asm__ __volatile__(mrc p15, 0, r0, c1, c0, 1);
- __asm__ __volatile__(bic r0, r0, #0x2);
- /* SMI instruction to call ROM Code API */
- __asm__ __volatile__(.word 0xE1600070);
- __asm__ __volatile__(mov r0, %0:=r(i));
- __asm__ __volatile__(mov r12, %0:=r(j));
- }
-}
-
static void cache_flush(void)
{
asm (mcr p15, 0, %0, c7, c5, 0: :r (0));
diff --git a/cpu/arm_cortexa8/omap3/Makefile b/cpu/arm_cortexa8/omap3/Makefile
index b96b3dd..f83036b 100644
--- a/cpu/arm_cortexa8/omap3/Makefile
+++ b/cpu/arm_cortexa8/omap3/Makefile
@@ -26,7 +26,7 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(SOC).a
SOBJS := lowlevel_init.o
-COBJS := sys_info.o board.o clock.o interrupts.o mem.o syslib.o
+COBJS := sys_info.o board.o clock.o interrupts.o mem.o syslib.o cache.o
SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS))
diff --git a/cpu/arm_cortexa8/omap3/board.c b/cpu/arm_cortexa8/omap3/board.c
index 51d5cf6..439ea6a 100644
--- a/cpu/arm_cortexa8/omap3/board.c
+++ b/cpu/arm_cortexa8/omap3/board.c
@@ -36,6 +36,7 @@
#include asm/io.h
#include
[U-Boot] [PATCH] omap3 L2-cache enable/disable function to omap3 dependent code
Dear Jean,
I miss mail title sorry. :)
=
Dear Jean,
I made new patch about L2 cane enable/disable function.
The related thread is here.
http://www.mail-archive.com/u-boot@lists.denx.de/msg14744.html
I fixed title issue apart header.
Thanks to read :)
Best Regards,
riverful
=
omap3 L2 cache enable/disable function moved from cpu/arm_cortexa8/cpu.c
to cpu/arm_cortexa8/omap3/. for generic SoC supports.
Signed-off-by: HeungJun, Kim riverful@samsung.com
---
cpu/arm_cortexa8/cpu.c | 68 +-
cpu/arm_cortexa8/omap3/Makefile|2 +-
cpu/arm_cortexa8/omap3/board.c |5 +-
cpu/arm_cortexa8/omap3/cache.c | 99
include/asm-arm/arch-omap3/sys_proto.h |1 -
include/asm-arm/cache.h| 37
6 files changed, 143 insertions(+), 69 deletions(-)
create mode 100644 cpu/arm_cortexa8/omap3/cache.c
create mode 100644 include/asm-arm/cache.h
diff --git a/cpu/arm_cortexa8/cpu.c b/cpu/arm_cortexa8/cpu.c
index 3e1780b..96f42a9 100644
--- a/cpu/arm_cortexa8/cpu.c
+++ b/cpu/arm_cortexa8/cpu.c
@@ -35,15 +35,12 @@
#include command.h
#include asm/arch/sys_proto.h
#include asm/system.h
+#include asm/cache.h
#ifdef CONFIG_USE_IRQ
DECLARE_GLOBAL_DATA_PTR;
#endif
-#ifndef CONFIG_L2_OFF
-void l2cache_disable(void);
-#endif
-
static void cache_flush(void);
int cpu_init(void)
@@ -80,7 +77,7 @@ int cleanup_before_linux(void)
#ifndef CONFIG_L2_OFF
/* turn off L2 cache */
- l2cache_disable();
+ l2_cache_disable();
/* invalidate L2 cache also */
v7_flush_dcache_all(get_device_type());
#endif
@@ -89,71 +86,12 @@ int cleanup_before_linux(void)
asm(mcr p15, 0, %0, c7, c10, 4: :r(i));
#ifndef CONFIG_L2_OFF
- l2cache_enable();
+ l2_cache_enable();
#endif
return 0;
}
-void l2cache_enable()
-{
- unsigned long i;
- volatile unsigned int j;
-
- /* ES2 onwards we can disable/enable L2 ourselves */
- if (get_cpu_rev() = CPU_3XX_ES20) {
- __asm__ __volatile__(mrc p15, 0, %0, c1, c0, 1:=r(i));
- __asm__ __volatile__(orr %0, %0, #0x2:=r(i));
- __asm__ __volatile__(mcr p15, 0, %0, c1, c0, 1:=r(i));
- } else {
- /* Save r0, r12 and restore them after usage */
- __asm__ __volatile__(mov %0, r12:=r(j));
- __asm__ __volatile__(mov %0, r0:=r(i));
-
- /*
-* GP Device ROM code API usage here
-* r12 = AUXCR Write function and r0 value
-*/
- __asm__ __volatile__(mov r12, #0x3);
- __asm__ __volatile__(mrc p15, 0, r0, c1, c0, 1);
- __asm__ __volatile__(orr r0, r0, #0x2);
- /* SMI instruction to call ROM Code API */
- __asm__ __volatile__(.word 0xE1600070);
- __asm__ __volatile__(mov r0, %0:=r(i));
- __asm__ __volatile__(mov r12, %0:=r(j));
- }
-
-}
-
-void l2cache_disable()
-{
- unsigned long i;
- volatile unsigned int j;
-
- /* ES2 onwards we can disable/enable L2 ourselves */
- if (get_cpu_rev() = CPU_3XX_ES20) {
- __asm__ __volatile__(mrc p15, 0, %0, c1, c0, 1:=r(i));
- __asm__ __volatile__(bic %0, %0, #0x2:=r(i));
- __asm__ __volatile__(mcr p15, 0, %0, c1, c0, 1:=r(i));
- } else {
- /* Save r0, r12 and restore them after usage */
- __asm__ __volatile__(mov %0, r12:=r(j));
- __asm__ __volatile__(mov %0, r0:=r(i));
-
- /*
-* GP Device ROM code API usage here
-* r12 = AUXCR Write function and r0 value
-*/
- __asm__ __volatile__(mov r12, #0x3);
- __asm__ __volatile__(mrc p15, 0, r0, c1, c0, 1);
- __asm__ __volatile__(bic r0, r0, #0x2);
- /* SMI instruction to call ROM Code API */
- __asm__ __volatile__(.word 0xE1600070);
- __asm__ __volatile__(mov r0, %0:=r(i));
- __asm__ __volatile__(mov r12, %0:=r(j));
- }
-}
-
static void cache_flush(void)
{
asm (mcr p15, 0, %0, c7, c5, 0: :r (0));
diff --git a/cpu/arm_cortexa8/omap3/Makefile b/cpu/arm_cortexa8/omap3/Makefile
index b96b3dd..f83036b 100644
--- a/cpu/arm_cortexa8/omap3/Makefile
+++ b/cpu/arm_cortexa8/omap3/Makefile
@@ -26,7 +26,7 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(SOC).a
SOBJS := lowlevel_init.o
-COBJS := sys_info.o board.o clock.o interrupts.o mem.o syslib.o
+COBJS := sys_info.o board.o clock.o interrupts.o mem.o syslib.o cache.o
SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS))
diff --git a/cpu/arm_cortexa8/omap3/board.c b/cpu/arm_cortexa8/omap3/board.c
index 51d5cf6..439ea6a 100644
--- a/cpu/arm_cortexa8/omap3/board.c
+++ b/cpu/arm_cortexa8/omap3/board.c
@@
Re: [U-Boot] [PATCH V2] board support patch for phyCORE-MPC5200B-tiny
Dear Jon Smirl, In message 9e4733910905311659u5e7c77a2ld80b526149c0d...@mail.gmail.com you wrote: Are you sure? This is pessimal choice. EEPROM is slow and unreliable. After you decided for a solution, then please remove the (then) dead code. Phytec ships default with the boards using the EEPROM. Once in mainline, you might want to point Phytec to that new, current and well tested code, so they can consoider switching to the mainline version. But, I'm with you and I flip the #if to use the FLASH. I also recommend to configure resndant environment. Both FLASH and EEPROM work. The flash has 128KB page size which wastes a lot of space holding a 2KB environment so I see why some people want to stick with EEPROM. Yes, wasting 128 or even 256 k of flash for just a few variables seems to be an expensive thing. But keep in mind that most 52xx systems boot from 0xFFF0, so the the last megabyte of flash is an excellent place for this (and probably the device tree). So I'd like to keep them both in place. Would it be better if the FLASH section was a comment? Indeed, a comment would be better. 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 If you believe that feeling bad or worrying long enough will change a past or future event, then you are residing on another planet with a different reality system. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] board support patch for phyCORE-MPC5200B-tiny
Dear Jon Smirl, In message 9e4733910905311805r2682b953tb87a4b97847b8...@mail.gmail.com you wrote: On Sun, May 31, 2009 at 6:11 PM, Wolfgang Denk w...@denx.de wrote: +#define CONFIG_SYS_LOAD_ADDR 0x10 /* default load address */ This used to be a reasonable choice with Linux 2.4.4; it ain't so any more. What should it be? At least 4 MB, or higher, depending on your typical kernel configurations. 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 Success in marriage is not so much finding the right person as it is being the right person. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM Cortex A8: Move OMAP3 specific reset handler to OMAP3 code
Dear Jean Dirk, Jean's opinion seems that file naming func naming must match for soruce maintaining, definitely I agree with that. Moreover it's a very first time to implement the new arm_cortexa8 code for u-boot source. So, the matching works is needed. On the other hand, Dirk's opinion seems that it dosen't make sense in this case, if there is many files when the developer make the code. I think that too, especially when the code is a little simple like the boot code. The u-boot's architecture SoC directory tree is already brilliant, so it's alright we just look at this directories what arch SoC ever we develop. So, my opinions is re-using the files seems to be right in this case. the Dirk's patch code is not difficult to understand use. After the code polluted cause of not-matching the file func naming, I believe that the developers seem be able to fix this issue easily, like my case. BTW, when am I able to re-update my new patch?? I wanna do that :) Best Regards, riverful 2009/6/1 Dirk Behme dirk.be...@googlemail.com: Dear Jean-Christophe, Jean-Christophe PLAGNIOL-VILLARD wrote: On 09:30 Sat 30 May , Dirk Behme wrote: Reset is SoC specific and not ARM Cortex A8 generic. Move it from generic code to OMAP3 SoC specific file. CC: Kim, Heung Jun river...@gmail.com Signed-off-by: Dirk Behme dirk.be...@googlemail.com --- This patches fixes the second issue found by riverful in http://lists.denx.de/pipermail/u-boot/2009-May/053433.html The first issue is fixed by http://lists.denx.de/pipermail/u-boot/2009-May/053444.html cpu/arm_cortexa8/omap3/lowlevel_init.S | 12 cpu/arm_cortexa8/start.S | 14 -- 2 files changed, 12 insertions(+), 14 deletions(-) Index: u-boot-arm/cpu/arm_cortexa8/omap3/lowlevel_init.S === --- u-boot-arm.orig/cpu/arm_cortexa8/omap3/lowlevel_init.S +++ u-boot-arm/cpu/arm_cortexa8/omap3/lowlevel_init.S @@ -181,6 +181,18 @@ lowlevel_init: /* back to arch calling code */ mov pc, lr +.global reset_cpu +reset_cpu: + ldr r1, rstctl @ get addr for global reset + @ reg + mov r3, #0x2 @ full reset pll + mpu + str r3, [r1] @ force reset + mov r0, r0 +_loop_forever: + b _loop_forever +rstctl: + .word PRM_RSTCTRL + please move this to reset.S other wise fine Most probably your idea is that each file should only contain functionality which fits 100% (120%?) what the file name implies (?). While from general point of view this is correct, it makes no sense to create new files again and again just to follow this rule. We already created a cache.c on your request, now you request a new file reset.S for ~5 assembly lines. This new file would contain more comments (e.g. GPL header) than useful code. So while in general case having file names reflecting more or less the functionality in these files, in this case it doesn't make sense. It doesn't make sense to pollute the source tree with a new file containing ~5 assembly lines just to make your rules apply. For such small code, re-using existing file is the better way to go. So NACK in this case. Best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM Cortex A8: Move OMAP3 specific reset handler to OMAP3 code
Dear Riverful, In message b64afca20906010014r321bd3fas3539d97f6667e...@mail.gmail.com you wrote: Jean's opinion seems that file naming func naming must match for soruce maintaining, definitely I agree with that. I do not agree. Yes, they _should_ match. That means we should try to acchieve this whenever it makes sense. But there is no strict must that we need to create a new source file for each and every function. Maintaining tons of tiny files does not make much sense either. In this case, I agree with Dirk that splitting of a new source file for a small (10 lines or so including comments) function is overkill. Jean-Christiphe sent a note about this code, and Dirk probvided a reasonable explanation why the code was written as is. I think that should be enough in this case. From my point of view, the code can go in as is. 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 algorithm to do that is extremely nasty. You might want to mug someone with it. - M. Devine, Computer Science 340 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH]
Dear Kim, Heung Jun, In message b64afca20905312308r1dbe50d8pc3d04e8450483...@mail.gmail.com you wrote: I made new patch about L2 cane enable/disable function. The related thread is here. http://www.mail-archive.com/u-boot@lists.denx.de/msg14744.html I fixed title issue apart header. Thanks to read :) Your patch format has many deficiencies. I strongly recommend to use git-format-patch to create patches for submission. Problems: - there is no subject, i. e. no tile line for the commit message, - Your comments (the text above)( are part of what will become the commit message; such comments must be placed *below* the --- line. - You seem to use a = line as separator, but this is not used by the git tools and does not work. Best Regards, riverful = omap3 L2 cache enable/disable function moved from cpu/arm_cortexa8/cpu.c to cpu/arm_cortexa8/omap3/. for generic SoC supports. Signed-off-by: HeungJun, Kim riverful@samsung.com --- ^^^ Please mode all your comments BELOW this line. Above is only the commit message. Thanks. 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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap3 L2-cache enable/disable function to omap3 dependent code
Dear Kim, Heung Jun, In message b64afca20905312312w578a4699q1939b50d573b0...@mail.gmail.com you wrote: Dear Jean, I miss mail title sorry. :) = Dear Jean, I made new patch about L2 cane enable/disable function. The related thread is here. http://www.mail-archive.com/u-boot@lists.denx.de/msg14744.html I fixed title issue apart header. Thanks to read :) Best Regards, riverful = All these comments belong *below* the --- line. 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 If I don't document something, it's usually either for a good reason, or a bad reason. In this case it's a good reason. :-) - Larry Wall in 1992jan17.005405.16...@netlabs.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] uboot under cygwin
Hi All, My first post here. Sorry if it was asked before and I couldn't find it. I need to build uboot for my own board based on 5121ads design from Freescale. My board is different from the reference as it has no CPLD, so I have to change a few things in the uboot code. I use Windows based CodeWarrior and USB tap to burn images on the board. The easiest thing for me is using cygwin so I won't have to copy binary images between OSes. Tried to compile uboot on cygwin with numerous errors mostly conflicting types in uboot tools. So I guess my question is - does anyone have any success building uboot under cygwin? Here is a sample of my compiler output make[1]: Entering directory `/cygdrive/d/temp/Freescale/u-boot-2008.10/tools' gcc -Wall -pedantic -ansi -idirafter /cygdrive/d/temp/Freescale/u-boot-2008.10/include -idirafter /cygdrive/d/temp/Freescale/u-boot-2008.10/include2 -idirafter /cygdr 0/include -DTEXT_BASE=0xFFF0 -DUSE_HOSTCC -O -c -o img2srec.o img2srec.c gcc -Wall -pedantic -ansi -idirafter /cygdrive/d/temp/Freescale/u-boot-2008.10/include -idirafter /cygdrive/d/temp/Freescale/u-boot-2008.10/include2 -idirafter /cygdr 0/include -DTEXT_BASE=0xFFF0 -DUSE_HOSTCC -O -o img2srec.exe img2srec.o strip img2srec.exe gcc -g -Wall -idirafter /cygdrive/d/temp/Freescale/u-boot-2008.10/include -idirafter /cygdrive/d/temp/Freescale/u-boot-2008.10/include2 -idirafter /cygdrive/d/temp/Fr EXT_BASE=0xFFF0 -DUSE_HOSTCC -O -c -o mkimage.o mkimage.c In file included from ../include/libfdt.h:54, from fdt_host.h:25, from mkimage.h:36, from mkimage.c:25: /cygdrive/d/temp/Freescale/u-boot-2008.10/include/libfdt_env.h:50: error: conflicting types for 'uintptr_t' /usr/include/stdint.h:62: error: previous declaration of 'uintptr_t' was here In file included from fdt_host.h:25, from mkimage.h:36, from mkimage.c:25: ../include/libfdt.h: In function `fdt_set_magic': ../include/libfdt.h:162: warning: implicit declaration of function `__cpu_to_be32' In file included from mkimage.c:26: /cygdrive/d/temp/Freescale/u-boot-2008.10/include/image.h: At top level: /cygdrive/d/temp/Freescale/u-boot-2008.10/include/image.h:193: error: parse error before ulong /cygdrive/d/temp/Freescale/u-boot-2008.10/include/image.h:195: error: parse error before load /cygdrive/d/temp/Freescale/u-boot-2008.10/include/image.h:197: error: parse error before '}' token /cygdrive/d/temp/Freescale/u-boot-2008.10/include/image.h:211: error: parse error before ulong ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-BOot] new cpu(Ingenic), new board(PI)
Wolfgang Denk wrote: Dear xiangfu, In message 4a21e74f.6080...@gmail.com you wrote: there is two branch in my git[2]. [xiangfu] this one , I try to merge with the upstream. [u-boot] is the upstream. I use git diff u-boot..xiangfu ~/pi_project.patch to generate the patch[1]. No. Please use git-format-patch to create patches. Make sure to split your changes lgically into commits - the commits should be small and orthogonal to each other. Please see http://www.denx.de/wiki/U-Boot/Patches for details. Best regards, Wolfgang Denk Thanks for the reply. I will need sometime to work, maybe 2~3 weeks. because I have some other important work must to do. I will keep send email if I have progress on U-boot. -- Best Regards Xiangfu Liu jabber : xiangf...@gmail.com skype : xiangfu.z ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC/PATCH] jffs2/mtdparts: Fix problem with usage from JFFS2 and MTDPARTS together
Wolfgang Denk wrote: Dear Stefan Roese, In message 1242468262-25814-1-git-send-email...@denx.de you wrote: Currently using JFFS2 with MTDPARTS enabled doesn't work. This is because mtdparts_init() is available in both files, cmd_mtdparts.c and cmd_jffs2.c. Please note that in the original cmd_jffs2.c file (before the jffs2/mtdparts command/file split those 2 different versions already existed. So this is nothing new. The main problem is that the variables current_dev and current_partnum are declared in both files now. This doesn't work. This patch now changes the names of those variable to more specific names: current_mtd_dev and current_mtd_partnum. This is because this patch also changes the declaration from static to global, so that they can be used from both files. Please note that my first tests were not successful. The MTD devices selected via mtdparts are now accessed but I'm failing to see the directory listed via the ls command. Nothing is displayed. Perhaps I didn't generate the JFFS2 image correctly (I never used JFFS2 in U-Boot before). Not sure. Perhaps somebody else could take a look at this as well. I'll continue looking into this on Monday. Signed-off-by: Stefan Roese s...@denx.de Cc: Wolfgang Denk w...@denx.de Cc: Detlev Zundel d...@denx.de Cc: Ilya Yanok ya...@emcraft.com Cc: Renaud barbier renaud.barb...@ge.com --- Renaud, you reported this problem on 05-04-2009 [mtdparts and JFFS2]. Could you please take a look at my patch. Does this work for you? Or what else is missing? This works for me. I had the ls problem before when current_mtd_dev was not declare global. This was because as a static current_mtd_dev. was NULL. Thank, Stefan. common/cmd_jffs2.c| 44 ++--- common/cmd_mtdparts.c | 74 2 files changed, 64 insertions(+), 54 deletions(-) Applied to master, thanks. Best regards, Wolfgang Denk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] The omap3 L2 cache enable/disable function to omap3 dependent code
CC: Dirk Behme dirk.be...@googlemail.com
Signed-off-by: HeungJun, Kim riverful@samsung.com
---
The L2 cache enable/disable function in the cpu/arm_cortexa8/cpu.c moved
to cpu/arm_cortexa8/omap3/cache.c.
This patches fixes the First issue in the following
http://lists.denx.de/pipermail/u-boot/2009-May/053433.html
The Second issue is fixed by
http://lists.denx.de/pipermail/u-boot/2009-May/053490.html
cpu/arm_cortexa8/cpu.c | 68 +-
cpu/arm_cortexa8/omap3/Makefile|2 +-
cpu/arm_cortexa8/omap3/board.c |5 +-
cpu/arm_cortexa8/omap3/cache.c | 99
include/asm-arm/arch-omap3/sys_proto.h |1 -
include/asm-arm/cache.h| 37
6 files changed, 143 insertions(+), 69 deletions(-)
create mode 100644 cpu/arm_cortexa8/omap3/cache.c
create mode 100644 include/asm-arm/cache.h
diff --git a/cpu/arm_cortexa8/cpu.c b/cpu/arm_cortexa8/cpu.c
index 3e1780b..96f42a9 100644
--- a/cpu/arm_cortexa8/cpu.c
+++ b/cpu/arm_cortexa8/cpu.c
@@ -35,15 +35,12 @@
#include command.h
#include asm/arch/sys_proto.h
#include asm/system.h
+#include asm/cache.h
#ifdef CONFIG_USE_IRQ
DECLARE_GLOBAL_DATA_PTR;
#endif
-#ifndef CONFIG_L2_OFF
-void l2cache_disable(void);
-#endif
-
static void cache_flush(void);
int cpu_init(void)
@@ -80,7 +77,7 @@ int cleanup_before_linux(void)
#ifndef CONFIG_L2_OFF
/* turn off L2 cache */
- l2cache_disable();
+ l2_cache_disable();
/* invalidate L2 cache also */
v7_flush_dcache_all(get_device_type());
#endif
@@ -89,71 +86,12 @@ int cleanup_before_linux(void)
asm(mcr p15, 0, %0, c7, c10, 4: :r(i));
#ifndef CONFIG_L2_OFF
- l2cache_enable();
+ l2_cache_enable();
#endif
return 0;
}
-void l2cache_enable()
-{
- unsigned long i;
- volatile unsigned int j;
-
- /* ES2 onwards we can disable/enable L2 ourselves */
- if (get_cpu_rev() = CPU_3XX_ES20) {
- __asm__ __volatile__(mrc p15, 0, %0, c1, c0, 1:=r(i));
- __asm__ __volatile__(orr %0, %0, #0x2:=r(i));
- __asm__ __volatile__(mcr p15, 0, %0, c1, c0, 1:=r(i));
- } else {
- /* Save r0, r12 and restore them after usage */
- __asm__ __volatile__(mov %0, r12:=r(j));
- __asm__ __volatile__(mov %0, r0:=r(i));
-
- /*
-* GP Device ROM code API usage here
-* r12 = AUXCR Write function and r0 value
-*/
- __asm__ __volatile__(mov r12, #0x3);
- __asm__ __volatile__(mrc p15, 0, r0, c1, c0, 1);
- __asm__ __volatile__(orr r0, r0, #0x2);
- /* SMI instruction to call ROM Code API */
- __asm__ __volatile__(.word 0xE1600070);
- __asm__ __volatile__(mov r0, %0:=r(i));
- __asm__ __volatile__(mov r12, %0:=r(j));
- }
-
-}
-
-void l2cache_disable()
-{
- unsigned long i;
- volatile unsigned int j;
-
- /* ES2 onwards we can disable/enable L2 ourselves */
- if (get_cpu_rev() = CPU_3XX_ES20) {
- __asm__ __volatile__(mrc p15, 0, %0, c1, c0, 1:=r(i));
- __asm__ __volatile__(bic %0, %0, #0x2:=r(i));
- __asm__ __volatile__(mcr p15, 0, %0, c1, c0, 1:=r(i));
- } else {
- /* Save r0, r12 and restore them after usage */
- __asm__ __volatile__(mov %0, r12:=r(j));
- __asm__ __volatile__(mov %0, r0:=r(i));
-
- /*
-* GP Device ROM code API usage here
-* r12 = AUXCR Write function and r0 value
-*/
- __asm__ __volatile__(mov r12, #0x3);
- __asm__ __volatile__(mrc p15, 0, r0, c1, c0, 1);
- __asm__ __volatile__(bic r0, r0, #0x2);
- /* SMI instruction to call ROM Code API */
- __asm__ __volatile__(.word 0xE1600070);
- __asm__ __volatile__(mov r0, %0:=r(i));
- __asm__ __volatile__(mov r12, %0:=r(j));
- }
-}
-
static void cache_flush(void)
{
asm (mcr p15, 0, %0, c7, c5, 0: :r (0));
diff --git a/cpu/arm_cortexa8/omap3/Makefile b/cpu/arm_cortexa8/omap3/Makefile
index b96b3dd..f83036b 100644
--- a/cpu/arm_cortexa8/omap3/Makefile
+++ b/cpu/arm_cortexa8/omap3/Makefile
@@ -26,7 +26,7 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(SOC).a
SOBJS := lowlevel_init.o
-COBJS := sys_info.o board.o clock.o interrupts.o mem.o syslib.o
+COBJS := sys_info.o board.o clock.o interrupts.o mem.o syslib.o cache.o
SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS))
diff --git a/cpu/arm_cortexa8/omap3/board.c b/cpu/arm_cortexa8/omap3/board.c
index 51d5cf6..439ea6a 100644
--- a/cpu/arm_cortexa8/omap3/board.c
+++ b/cpu/arm_cortexa8/omap3/board.c
@@ -36,6 +36,7 @@
#include asm/io.h
#include asm/arch/sys_proto.h
#include
[U-Boot] potential Uboot Ping problem
Hi, It appears the ping in UBOOT is broken. The ping works fine if you have a network connection. But if the network connection is disconnected the ping hangs the system. There is no response to Control-C either. I have to power cycle the proto to get back to a UBOOT prompt. Is this a known issue or did I possibly break something? I have a board based on the Atmel AT91SAM9RL-EK. My theory is that it may be a generic problem with the uboot ping. I can't confirm that since the only hardware I have is our protos. Does anyone else have a board with another MAC/PHY that you can try this on? As for UBOOT code, our environment is based on 2008.10 code. Our MAC/PHY is the Microchip ENC28J60. Thanks, Steve -- View this message in context: http://www.nabble.com/potential-Uboot-Ping-problem-tp23815872p23815872.html Sent from the Uboot - Users mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] potential Uboot Ping problem
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Steven Zedeck Sent: Monday, June 01, 2009 8:05 PM To: u-boot@lists.denx.de Subject: [U-Boot] potential Uboot Ping problem Hi, It appears the ping in UBOOT is broken. The ping works fine if you have a network connection. But if the network connection is disconnected the ping hangs the system. There is no response to Control-C either. I have to power cycle the proto to get back to a UBOOT prompt. Is this a known issue or did I possibly break something? I have a board based on the Atmel AT91SAM9RL-EK. My theory is that it may be a generic problem with the uboot ping. I can't confirm that since the only hardware I have is our protos. It was noticed on the OMAP3EVM last FRI and we were suspecting it to be problem with the omap3 board configuration itself. (Though did not spend much time in debug). Now, I too get a feeling that it could be a generic problem. Best regards, Sanjeev Does anyone else have a board with another MAC/PHY that you can try this on? As for UBOOT code, our environment is based on 2008.10 code. Our MAC/PHY is the Microchip ENC28J60. Thanks, Steve -- View this message in context: http://www.nabble.com/potential-Uboot-Ping-problem-tp23815872p 23815872.html Sent from the Uboot - Users mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] potential Uboot Ping problem
I guess thats good news. I looked inside the cmd_ping code a bit. I bet there's a while loop somewhere that is waiting for something and may not have a timeout loop. Any ideas? Thanks, Steve Premi, Sanjeev wrote: -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Steven Zedeck Sent: Monday, June 01, 2009 8:05 PM To: u-boot@lists.denx.de Subject: [U-Boot] potential Uboot Ping problem Hi, It appears the ping in UBOOT is broken. The ping works fine if you have a network connection. But if the network connection is disconnected the ping hangs the system. There is no response to Control-C either. I have to power cycle the proto to get back to a UBOOT prompt. Is this a known issue or did I possibly break something? I have a board based on the Atmel AT91SAM9RL-EK. My theory is that it may be a generic problem with the uboot ping. I can't confirm that since the only hardware I have is our protos. It was noticed on the OMAP3EVM last FRI and we were suspecting it to be problem with the omap3 board configuration itself. (Though did not spend much time in debug). Now, I too get a feeling that it could be a generic problem. Best regards, Sanjeev Does anyone else have a board with another MAC/PHY that you can try this on? As for UBOOT code, our environment is based on 2008.10 code. Our MAC/PHY is the Microchip ENC28J60. Thanks, Steve -- View this message in context: http://www.nabble.com/potential-Uboot-Ping-problem-tp23815872p 23815872.html Sent from the Uboot - Users mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot -- View this message in context: http://www.nabble.com/potential-Uboot-Ping-problem-tp23815872p23816429.html Sent from the Uboot - Users mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM Cortex A8: Move OMAP3 specific reset handler to OMAP3 code
On 17:56 Sun 31 May , Dirk Behme wrote: Dear Jean-Christophe, Jean-Christophe PLAGNIOL-VILLARD wrote: On 09:30 Sat 30 May , Dirk Behme wrote: Reset is SoC specific and not ARM Cortex A8 generic. Move it from generic code to OMAP3 SoC specific file. CC: Kim, Heung Jun river...@gmail.com Signed-off-by: Dirk Behme dirk.be...@googlemail.com --- This patches fixes the second issue found by riverful in http://lists.denx.de/pipermail/u-boot/2009-May/053433.html The first issue is fixed by http://lists.denx.de/pipermail/u-boot/2009-May/053444.html cpu/arm_cortexa8/omap3/lowlevel_init.S | 12 cpu/arm_cortexa8/start.S | 14 -- 2 files changed, 12 insertions(+), 14 deletions(-) Index: u-boot-arm/cpu/arm_cortexa8/omap3/lowlevel_init.S === --- u-boot-arm.orig/cpu/arm_cortexa8/omap3/lowlevel_init.S +++ u-boot-arm/cpu/arm_cortexa8/omap3/lowlevel_init.S @@ -181,6 +181,18 @@ lowlevel_init: /* back to arch calling code */ mov pc, lr +.global reset_cpu +reset_cpu: + ldr r1, rstctl @ get addr for global reset + @ reg + mov r3, #0x2@ full reset pll + mpu + str r3, [r1]@ force reset + mov r0, r0 +_loop_forever: + b _loop_forever +rstctl: + .word PRM_RSTCTRL + please move this to reset.S other wise fine Most probably your idea is that each file should only contain functionality which fits 100% (120%?) what the file name implies (?). While from general point of view this is correct, it makes no sense to create new files again and again just to follow this rule. We already created a cache.c on your request, now you request a new file reset.S for ~5 assembly lines. This new file would contain more comments (e.g. GPL header) than useful code. the idea is different here I want to have only code in lowlevel_init.S that can be disable by CONFIG_SKIP_LOWLEVEL_INIT and do it via Makefile Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3] board support patch for phyCORE-MPC5200B-tiny
Add support for the Phytec phyCORE-MPC5200B-tiny. Code originally from
Pengutronix.de.
Added MAKEALL and MAINTAINER entry per last posting.
Signed-off-by: Jon Smirl jonsm...@gmail.com
---
MAINTAINERS |4
MAKEALL |1
Makefile| 10 +
board/phytec/pcm030/Makefile| 50
board/phytec/pcm030/config.mk | 42 +++
board/phytec/pcm030/mt46v32m16-75.h | 54
board/phytec/pcm030/pcm030.c| 219
cpu/mpc5xxx/ide.c |3
include/configs/pcm030.h| 472 +++
9 files changed, 855 insertions(+), 0 deletions(-)
create mode 100644 board/phytec/pcm030/Makefile
create mode 100644 board/phytec/pcm030/config.mk
create mode 100644 board/phytec/pcm030/mt46v32m16-75.h
create mode 100644 board/phytec/pcm030/pcm030.c
create mode 100644 include/configs/pcm030.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 3d50668..1385ac1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -407,6 +407,10 @@ Andre Schwarz andre.schw...@matrix-vision.de
mvbc_p MPC5200
mvblm7 MPC8343
+Jon Smirl jonsm...@gmail.com
+
+ pcm030 MPC5200
+
Timur Tabi ti...@freescale.com
MPC8349E-mITX MPC8349
diff --git a/MAKEALL b/MAKEALL
index 57dd425..659730f 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -60,6 +60,7 @@ LIST_5xxx= \
munices \
MVBC_P \
o2dnt \
+ pcm030 \
pf5200 \
PM520 \
TB5200 \
diff --git a/Makefile b/Makefile
index 4f30560..c26cfeb 100644
--- a/Makefile
+++ b/Makefile
@@ -687,6 +687,16 @@ MVBC_P_config: unconfig
o2dnt_config: unconfig
@$(MKCONFIG) o2dnt ppc mpc5xxx o2dnt
+pcm030_config \
+pcm030_LOWBOOT_config: unconfig
+ @ include/config.h
+ @[ -z $(findstring LOWBOOT_,$@) ] || \
+ { echo TEXT_BASE = 0xFF00 board/phytec/pcm030/config.tmp
; \
+ echo ... with LOWBOOT configuration ; \
+ }
+ @$(MKCONFIG) -a pcm030 ppc mpc5xxx pcm030 phytec
+ @ echo remember to set pcm030_REV to 0 for rev 1245.0 rev or to 1 for
rev 1245.1
+
pf5200_config: unconfig
@$(MKCONFIG) pf5200 ppc mpc5xxx pf5200 esd
diff --git a/board/phytec/pcm030/Makefile b/board/phytec/pcm030/Makefile
new file mode 100644
index 000..22ce8e6
--- /dev/null
+++ b/board/phytec/pcm030/Makefile
@@ -0,0 +1,50 @@
+#
+# (C) Copyright 2003-2007
+# Wolfgang Denk, DENX Software Engineering, w...@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
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).a
+
+COBJS := $(BOARD).o
+
+SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+SOBJS := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS)
+ $(AR) $(ARFLAGS) $@ $(OBJS)
+
+clean:
+ rm -f $(SOBJS) $(OBJS)
+
+distclean: clean
+ rm -f $(LIB) core *.bak $(obj).depend
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/phytec/pcm030/config.mk b/board/phytec/pcm030/config.mk
new file mode 100644
index 000..5d3469c
--- /dev/null
+++ b/board/phytec/pcm030/config.mk
@@ -0,0 +1,42 @@
+#
+# (C) Copyright 2003
+# Wolfgang Denk, DENX Software Engineering, w...@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
+#
Re: [U-Boot] USB gadget interface from cdc branch into mainline
Hello Ragha, 2009/5/30 Ragha raghavendra...@gmail.com: Hello, The gadget interface at cdc branch [1] sounds good. Any plans for merging it into mainline? Yeah, I planned it for the next release. Kind Regards, Remy Regards, -Ragha [1] http://git.denx.de/?p=u-boot/u-boot-usb.git;a=shortlog;h=refs/heads/cdc ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] uboot under cygwin
On Mon, 1 Jun 2009 10:37:11 +0300 Stas Desyatnlkov s...@tech-mer.com wrote: gcc -g -Wall -idirafter /cygdrive/d/temp/Freescale/u-boot-2008.10/include -idirafter /cygdrive/d/temp/Freescale/u-boot-2008.10/include2 -idirafter /cygdrive/d/temp/Fr EXT_BASE=0xFFF0 -DUSE_HOSTCC -O -c -o mkimage.o mkimage.c In file included from ../include/libfdt.h:54, from fdt_host.h:25, from mkimage.h:36, from mkimage.c:25: /cygdrive/d/temp/Freescale/u-boot-2008.10/include/libfdt_env.h:50: error: conflicting types for 'uintptr_t' /usr/include/stdint.h:62: error: previous declaration of 'uintptr_t' was here In file included from fdt_host.h:25, from mkimage.h:36, from mkimage.c:25: ../include/libfdt.h: In function `fdt_set_magic': ../include/libfdt.h:162: warning: implicit declaration of function `__cpu_to_be32' In file included from mkimage.c:26: /cygdrive/d/temp/Freescale/u-boot-2008.10/include/image.h: At top level: /cygdrive/d/temp/Freescale/u-boot-2008.10/include/image.h:193: error: parse error before ulong /cygdrive/d/temp/Freescale/u-boot-2008.10/include/image.h:195: error: parse error before load /cygdrive/d/temp/Freescale/u-boot-2008.10/include/image.h:197: error: parse error before '}' token /cygdrive/d/temp/Freescale/u-boot-2008.10/include/image.h:211: error: parse error before ulong can you retest with the latest greatest on git.denx.de? If it still fails, can you retry after applying this patch?: http://lists.denx.de/pipermail/u-boot/2009-May/053479.html thanks, Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Large Block USB Flash Drive Problem
Hello, 2009/5/28 Barnes, Clifton A. cabar...@indesign-llc.com: I have been trying out loading the Linux kernel using a USB flash drive in the u-boot-2009.06-rc2 release and ran into a problem with one of my flash drives. This particular drive has a block size of 2048 while the other drives have block sizes of 512. The drives with a block size of 512 work perfectly. However, the flash drive with a block size of 2048 fails during the 'usb start' command. I traced this issue to the Part_dos.c file and the function test_part_dos. The buffer allocated there is only 512 bytes. When I changed it to 2048, the 'usb start' command worked correctly and found the one storage device connected. This had no adverse affect with the flash drives that were 512 bytes. Should the macro DEFAULT_SECTOR_SIZE be changed to accommodate larger block size usb flash drives? The second problem came when I tried to use the FAT utilities. When I ran 'fatls usb 0', it failed the same way as when the 'usb start' failed before. Naturally, I guessed that it was a buffer size problem again. I was able to trace the issue to the macro SECTOR_SIZE in fat.h. I tried changing it to 2048, however, there is a check right below it that fails if SECTOR_SIZE != FS_BLOCK_SIZE. So, I assume that the support isn't written to handle sector sizes that are different than the FAT block size. However, I went ahead and changed them both to 2048. This fixed the issues with the FAT utilities partly. I was able to run 'fatls usb 0' and it listed the files but also some junk. I'm guessing it was grabbing junk after the files since the block size is too big. I was also able to run 'fatload usb 0 0x2200 uImage' successfully and boot the kernel successfully. So, I think the fix has to be in the SECTOR_SIZE macro in the fat.h file. Can anyone with expertise in the FAT implementation take a look at supporting different sector sizes for larger block size flash drives? Well, there was a patch posted for this some time ago: http://www.mail-archive.com/u-boot@lists.denx.de/msg05444.html But, this patch broke several 512 byte blocksize devices, so I did not push it to mainline. You might take a look at it, maybe it solves your problem. If you can make it work properly with 512 byte devices as well, I am in for a patch... Kind Regards, Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] The omap3 L2 cache enable/disable function to omap3 dependent code
On Tue, 2 Jun 2009 01:08:53 +0900
Kim, Heung Jun river...@gmail.com wrote:
Dear Kim Philips,
Thanks to review help.
3. while making backreferences by pointing to messages in the list
archive is cool, they don't stand the test of time - the URL may one
day cease to exist. So it is better to either reference a commitish in
the repository itself, or simply restate/copy the original data.
But, I don't understand idea 3 well.
Let me know more detailed? :-)
I don't understand the word commitish the meaning of original data.
And, I think that you tell me to simplify the comments.
Is it right or something like?
basically, I'm saying that backreferences should only be git commit
ID's ('commitish' in git terminology). See e.g., Commit 574b319512
introduced and A later fix in commit 8ec6e332ea below:
commit af75a45d23b72a59ac5cc0427696c7f634fdc94b
Author: Wolfgang Denk w...@denx.de
Date: Fri May 15 09:27:58 2009 +0200
IDE: bail out of dev_print() for unknown device types
Commit 574b319512 introduced a subtle bug by mixing a list of tests
for dev_desc-type and dev_desc-if_type into one switch(), which
then mostly did not work because dev_desc-type cannot take any
IF_* type values. A later fix in commit 8ec6e332ea changed the
switch() into testing dev_desc-if_type, but at this point the
initial test for unknown device types was completely lost, which
resulted in output like that for IDE ports without device attached:
Device 1: Model: Firm: Ser#:
Type: # 1F #
Capacity: not available
This patch re-introduces the missing test for unknown device types.
Signed-off-by: Wolfgang Denk w...@denx.de
Cc: Stefan Roese s...@denx.de
Cc: Detlev Zundel d...@denx.de
Tested-by: Stefan Roese s...@denx.de
...and if your commit message wants to reference something that is
_not_ already in the repository, e.g., in your case I think you have
this compiler error:
cpu.c:99: warning: function declaration isn't a prototype
cpu.c: In function 'l2cache_enable':
cpu.c:104: warning: implicit declaration of function 'get_cpu_rev'
cpu.c:104: error: 'CPU_3XX_ES20' undeclared (first use in this function)
cpu.c:104: error: (Each undeclared identifier is reported only once
cpu.c:104: error: for each function it appears in.)
cpu.c: At top level:
cpu.c:129: warning: function declaration isn't a prototype
cpu.c: In function 'l2cache_disable':
cpu.c:134: error: 'CPU_3XX_ES20' undeclared (first use in this function)
make[1]: *** [cpu.o] Error 1
...so please copy it into the commit message, so that it lives as long
as the life of the project (as opposed to the life of the maillist
archive server URL).
Kim
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/6] mpc83xx: USB: Reorganized its support
Hello Vivek, 2009/5/25 Vivek Mahajan vivek.maha...@freescale.com: The following patch reorganizes/reworks the USB support for mpc83xx as under:- * Moves the 83xx USB clock init from drivers/usb/host/ehci-fsl.c to cpu/mpx83xx/cpu_init.c * Board specific usb_phy_type is read from the environment * Adds USB EHCI specific structure in include/usb/ehci-fsl.h * Copyrights revamped in most of the following files Signed-off-by: Vivek Mahajan vivek.maha...@freescale.com Sorry, but this patch does not apply to U-boot-usb next branch, can you please rebase? Kind Regards, Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] mpc85xx: USB: Add support
Hello Vivek, 2009/5/21 Vivek Mahajan vivek.maha...@freescale.com: The following patch adds 85xx-specific USB support and also revamps Copyright in immap_85xx.h Signed-off-by: Vivek Mahajan vivek.maha...@freescale.com Sorry, but this patch does not apply to U-boot-usb next branch, can you please rebase? Kind Regards, Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 6/6] mpc85xx: 8536ds: Add USB related CONFIGs
Hello Vivek, 2009/5/25 Vivek Mahajan vivek.maha...@freescale.com: This patch adds CONFIGs for enabling USB in mpc8536ds and also adds usb_phy_type in CONFIG_EXTRA_ENV_SETTINGS. Also revamps its Copyright. Signed-off-by: Vivek Mahajan vivek.maha...@freescale.com --- v2 change: usb_phy_type is set in CONFIG_EXTRA_ENV_SETTINGS Sorry, but this patch does not apply to U-boot-usb next branch, can you please rebase? Kind Regards, Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] ZOOM2 detect the version of the zoom2 board at runtime.
On 09:58 Fri 29 May , Tom Rix wrote:
There are currently 3 versions of the zoom2 board.
The production board, that is currently being released.
The beta board, similar in form to the production board but not released.
The alpha board, a set of PCBs with a very limited circulation.
GPIO 94 is used to determine the version of the board. If GPIO 94 is clear,
the board is a production board, otherwise it is a beta board.
The alpha board will likely be mistaken for a beta board. An alpha board
was unavailible for testing.
This has been tested on the beta and production boards.
Signed-off-by: Tom Rix tom@windriver.com
---
board/omap3/zoom2/zoom2.c | 48 ++--
board/omap3/zoom2/zoom2.h |6 +
2 files changed, 51 insertions(+), 3 deletions(-)
diff --git a/board/omap3/zoom2/zoom2.c b/board/omap3/zoom2/zoom2.c
index e5c248d..06e644f 100644
--- a/board/omap3/zoom2/zoom2.c
+++ b/board/omap3/zoom2/zoom2.c
@@ -33,6 +33,7 @@
#include status_led.h
#endif
#include asm/io.h
+#include asm/arch/gpio.h
#include asm/arch/mem.h
#include asm/arch/mux.h
#include asm/arch/sys_proto.h
@@ -60,6 +61,46 @@ static u32 gpmc_serial_TL16CP754C[GPMC_MAX_REG] = {
0x1D0904C4, 0
};
+/* Used to track the revision of the board */
+int zoom2_revision = ZOOM2_REVISION_UNKNOWN;
add static and as the beagle provide a function to get the current version
+
+/*
+ * Routine: zoom2_identify
+ * Description: Detect which version of Zoom2 we are running on.
+ */
+void zoom2_identify(void)
+{
+ /*
+ * To check for production board vs beta board,
+ * check if gpio 94 is clear.
+ *
+ * No way yet to check for alpha board identity.
+ * Alpha boards were produced in very limited quantities
+ * and they are not commonly used. They are mentioned here
+ * only for completeness.
+ */
+ if (!omap_request_gpio(94)) {
+ unsigned int val;
+
+ omap_set_gpio_direction(94, 1);
+ val = omap_get_gpio_datain(94);
+ omap_free_gpio(94);
+
+ if (val)
+ zoom2_revision = ZOOM2_REVISION_BETA;
+ else
+ zoom2_revision = ZOOM2_REVISION_PRODUCTION;
+ }
+
+ printf(Board revision );
+ if (ZOOM2_REVISION_PRODUCTION == zoom2_revision)
+ printf(Production\n);
+ else if (ZOOM2_REVISION_BETA == zoom2_revision)
+ printf(Beta\n);
+ else
+ printf(Unknown\n);
please use switch
+}
+
/*
* Routine: board_init
* Description: Early hardware init.
@@ -96,10 +137,11 @@ int board_init (void)
* Routine: misc_init_r
* Description: Configure zoom board specific configurations
*/
-int misc_init_r (void)
+int misc_init_r(void)
{
- power_init_r ();
- dieid_num_r ();
+ zoom2_identify();
+ power_init_r();
+ dieid_num_r();
return 0;
}
diff --git a/board/omap3/zoom2/zoom2.h b/board/omap3/zoom2/zoom2.h
index cae8a7a..7f15260 100644
--- a/board/omap3/zoom2/zoom2.h
+++ b/board/omap3/zoom2/zoom2.h
@@ -32,6 +32,12 @@ const omap3_sysinfo sysinfo = {
NAND,
};
+#define ZOOM2_REVISION_UNKNOWN 0
+#define ZOOM2_REVISION_ALPHA 1
+#define ZOOM2_REVISION_BETA 2
+#define ZOOM2_REVISION_PRODUCTION3
please use an emum
Best Regards,
J.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] The omap3 L2 cache enable/disable function to omap3 dependent code
Kim Phillips wrote: On Mon, 1 Jun 2009 19:14:49 +0900 Kim, Heung Jun river...@gmail.com wrote: CC: Dirk Behme dirk.be...@googlemail.com Signed-off-by: HeungJun, Kim riverful@samsung.com --- The L2 cache enable/disable function in the cpu/arm_cortexa8/cpu.c moved to cpu/arm_cortexa8/omap3/cache.c. This patches fixes the First issue in the following http://lists.denx.de/pipermail/u-boot/2009-May/053433.html The Second issue is fixed by http://lists.denx.de/pipermail/u-boot/2009-May/053490.html Hi Riverful, 1. the patch title is missing the verb 'move' 2. your signoff is in the correct location, however the commit message is not. It belongs above the line with the '---'. 3. while making backreferences by pointing to messages in the list archive is cool, they don't stand the test of time - the URL may one day cease to exist. So it is better to either reference a commitish in the repository itself, or simply restate/copy the original data. As long as references to the mailing list archive are in patch comment (below --- as they are here) and don't go into git I think it's fine to use them. Best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-BOOT] nand merge problem
On Sun, May 31, 2009 at 04:09:35PM +0800, xiangfu wrote:
static void jz_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int ctrl)
{
struct nand_chip *this = (struct nand_chip *)(mtd-priv);
unsigned int nandaddr = (unsigned int)this-IO_ADDR_W;
if (ctrl NAND_CTRL_CHANGE) {
if (ctrl NAND_CLE)
nandaddr = nandaddr | 0x8000;
else
nandaddr = nandaddr ~0x8000;
if (ctrl NAND_ALE)
this-IO_ADDR_W = (void __iomem *)((unsigned
long)(this-IO_ADDR_W) |
0x0001);
else
this-IO_ADDR_W = (void __iomem *)((unsigned
long)(this-IO_ADDR_W)
~0x0001);
if (ctrl NAND_NCE) {
this-IO_ADDR_W = this-IO_ADDR_R = (void __iomem
*)NAND_DATA_PORT1;
REG_EMC_NFCSR |= EMC_NFCSR_NFCE1;
} else {
REG_EMC_NFCSR = ~EMC_NFCSR_NFCE1;
REG_EMC_NFCSR = ~EMC_NFCSR_NFCE2;
REG_EMC_NFCSR = ~EMC_NFCSR_NFCE3;
REG_EMC_NFCSR = ~EMC_NFCSR_NFCE4;
}
}
this-IO_ADDR_W = (void __iomem *)nandaddr;
if (cmd != NAND_CMD_NONE)
writeb(cmd, this-IO_ADDR_W);
}
Try something like this instead:
static void jz_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int ctrl)
{
struct nand_chip *this = mtd-priv;
unsigned long nandaddr = (unsigned long)this-IO_ADDR_W;
if (ctrl NAND_CTRL_CHANGE) {
/* Change this to use I/O accessors. */
if (ctrl NAND_NCE) {
REG_EMC_NFCSR |= EMC_NFCSR_NFCE1;
} else {
/*
* Why set only one bit when NCE is high, but clear
* four when low? Why clear separate bits in the same
* register one at a time?
*/
REG_EMC_NFCSR = ~EMC_NFCSR_NFCE1;
REG_EMC_NFCSR = ~EMC_NFCSR_NFCE2;
REG_EMC_NFCSR = ~EMC_NFCSR_NFCE3;
REG_EMC_NFCSR = ~EMC_NFCSR_NFCE4;
}
}
if (cmd == NAND_CMD_NONE)
return;
if (ctrl NAND_CLE)
nandaddr |= 0x8000;
else /* must be ALE */
nandaddr |= 0x0001;
writeb(cmd, (uint8_t *)nandaddr);
}
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Adds WATCHDOG_RESET() function call to lib_m68k dtimer_interrupt.
From: Richard Retanubun richardretanu...@ruggedcom.com
Ported from lib_ppc/interrupts.c, this adds the ability for
the coldfire system timer to auto-reset the watchdog when
dtimer_interrupts is called.
Signed-off-by: Richard Retanubun richardretanu...@ruggedcom.com
---
lib_m68k/time.c | 13 -
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/lib_m68k/time.c b/lib_m68k/time.c
index 697d67e..29269f6 100644
--- a/lib_m68k/time.c
+++ b/lib_m68k/time.c
@@ -27,10 +27,15 @@
#include asm/timer.h
#include asm/immap.h
+#include watchdog.h
DECLARE_GLOBAL_DATA_PTR;
-static ulong timestamp;
+static volatile ulong timestamp = 0;
+
+#ifndef CONFIG_SYS_WATCHDOG_FREQ
+#define CONFIG_SYS_WATCHDOG_FREQ (CONFIG_SYS_HZ / 2)
+#endif
#if defined(CONFIG_MCFTMR)
#ifndef CONFIG_SYS_UDELAY_BASE
@@ -76,6 +81,12 @@ void dtimer_interrupt(void *not_used)
if ((CONFIG_SYS_TMRPND_REG CONFIG_SYS_TMRINTR_MASK) ==
CONFIG_SYS_TMRINTR_PEND) {
timerp-ter = (DTIM_DTER_CAP | DTIM_DTER_REF);
timestamp++;
+
+ #if defined(CONFIG_WATCHDOG) || defined (CONFIG_HW_WATCHDOG)
+ if ((timestamp % (CONFIG_SYS_WATCHDOG_FREQ)) == 0) {
+ WATCHDOG_RESET ();
+ }
+ #endif/* CONFIG_WATCHDOG || CONFIG_HW_WATCHDOG */
return;
}
}
--
1.5.6.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] MX31: Add NAND SPL for i.MX31.
On Sat, May 30, 2009 at 09:54:56AM +0200, Magnus Lilja wrote: 2009/5/29 Scott Wood scottw...@freescale.com: The bad block location is typically different (offset 0 rather than 5) with large page flash. I think that's because of the non-standard imlementation of large page support in the i.MX31 NFC. We should have comments in the code explaining what's going on in such cases. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Compier warning cleanup
From: Richard Retanubun richardretanu...@ruggedcom.com
Follow up to git commit: 19b5b533ccd522abeb501d510750693c35e20456
Cleanup on compiler warnings on unused variables now that
bd-bi_enetaddr is no longer used.
Signed-off-by: Richard Retanubun richardretanu...@ruggedcom.com
---
lib_m68k/board.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/lib_m68k/board.c b/lib_m68k/board.c
index 584d1ff..7d4ffc7 100644
--- a/lib_m68k/board.c
+++ b/lib_m68k/board.c
@@ -438,9 +438,8 @@ board_init_f (ulong bootflag)
void board_init_r (gd_t *id, ulong dest_addr)
{
cmd_tbl_t *cmdtp;
- char *s, *e;
+ char *s;
bd_t *bd;
- int i;
extern void malloc_bin_reloc (void);
#ifndef CONFIG_ENV_IS_NOWHERE
--
1.5.6.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Coldfire M5271: Activate u-boot system timer interrupt.
From: Richard Retanubun richardretanu...@ruggedcom.com This patch assigns the u-boot system timer interrupt to interrupt level 3, priority 6. Without this patch the interrupt will be a level 0, priority 0, which disables it and cause u-boot functions that relies on the timer (e.g. sleep command) to never return. Signed-off-by: Richard Retanubun richardretanu...@ruggedcom.com --- include/asm-m68k/immap.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/asm-m68k/immap.h b/include/asm-m68k/immap.h index 93f730f..6a3ef03 100644 --- a/include/asm-m68k/immap.h +++ b/include/asm-m68k/immap.h @@ -149,7 +149,7 @@ #define CONFIG_SYS_TMRINTR_NO (INT0_LO_DTMR3) #define CONFIG_SYS_TMRINTR_MASK(INTC_IPRL_INT22) #define CONFIG_SYS_TMRINTR_PEND(CONFIG_SYS_TMRINTR_MASK) -#define CONFIG_SYS_TMRINTR_PRI (0) /* Level must include inorder to work */ +#define CONFIG_SYS_TMRINTR_PRI (0x1E) /* Interrupt level 3, priority 6 */ #define CONFIG_SYS_TIMER_PRESCALER (((gd-bus_clk / 100) - 1) 8) #endif -- 1.5.6.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Standardize the use of MCFFEC_TOUT_LOOP as a udelay(1) loop counter.
From: Richard Retanubun richardretanu...@ruggedcom.com
Signed-off-by: Richard Retanubun richardretanu...@ruggedcom.com
---
drivers/net/mcfmii.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/mcfmii.c b/drivers/net/mcfmii.c
index 4f1c0a0..4acc29e 100644
--- a/drivers/net/mcfmii.c
+++ b/drivers/net/mcfmii.c
@@ -270,7 +270,7 @@ void __mii_init(void)
if ((status linkgood) == linkgood)
break;
- udelay(500);
+ udelay(1);
}
if (i = MCFFEC_TOUT_LOOP) {
printf(Link UP timeout\n);
--
1.5.6.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] The omap3 L2 cache enable/disable function to omap3 dependent code
On Mon, 01 Jun 2009 18:46:21 +0200 Dirk Behme dirk.be...@googlemail.com wrote: 2. your signoff is in the correct location, however the commit message is not. It belongs above the line with the '---'. 3. while making backreferences by pointing to messages in the list archive is cool, they don't stand the test of time - the URL may one day cease to exist. So it is better to either reference a commitish in the repository itself, or simply restate/copy the original data. As long as references to the mailing list archive are in patch comment (below --- as they are here) and don't go into git I think it's fine to use them. agreed (and I just did that myself in another thread) - it's just that, in this case, the referenced subject matter needs to go in the git commit message (see 2 above). Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] The omap3 L2 cache enable/disable function to omap3 dependent code
CC: Dirk Behme dirk.be...@googlemail.com
Signed-off-by: HeungJun, Kim riverful@samsung.com
---
The L2 cache enable/disable function in the cpu/arm_cortexa8/cpu.c moved
to cpu/arm_cortexa8/omap3/cache.c.
This patches fixes the First issue in the following
http://lists.denx.de/pipermail/u-boot/2009-May/053433.html
The Second issue is fixed by
http://lists.denx.de/pipermail/u-boot/2009-May/053490.html
cpu/arm_cortexa8/cpu.c | 68 +-
cpu/arm_cortexa8/omap3/Makefile|2 +-
cpu/arm_cortexa8/omap3/board.c |5 +-
cpu/arm_cortexa8/omap3/cache.c | 99
include/asm-arm/arch-omap3/sys_proto.h |1 -
include/asm-arm/cache.h| 37
6 files changed, 143 insertions(+), 69 deletions(-)
create mode 100644 cpu/arm_cortexa8/omap3/cache.c
create mode 100644 include/asm-arm/cache.h
diff --git a/cpu/arm_cortexa8/cpu.c b/cpu/arm_cortexa8/cpu.c
index 3e1780b..96f42a9 100644
--- a/cpu/arm_cortexa8/cpu.c
+++ b/cpu/arm_cortexa8/cpu.c
@@ -35,15 +35,12 @@
#include command.h
#include asm/arch/sys_proto.h
#include asm/system.h
+#include asm/cache.h
#ifdef CONFIG_USE_IRQ
DECLARE_GLOBAL_DATA_PTR;
#endif
-#ifndef CONFIG_L2_OFF
-void l2cache_disable(void);
-#endif
-
static void cache_flush(void);
int cpu_init(void)
@@ -80,7 +77,7 @@ int cleanup_before_linux(void)
#ifndef CONFIG_L2_OFF
/* turn off L2 cache */
- l2cache_disable();
+ l2_cache_disable();
/* invalidate L2 cache also */
v7_flush_dcache_all(get_device_type());
#endif
@@ -89,71 +86,12 @@ int cleanup_before_linux(void)
asm(mcr p15, 0, %0, c7, c10, 4: :r(i));
#ifndef CONFIG_L2_OFF
- l2cache_enable();
+ l2_cache_enable();
#endif
return 0;
}
-void l2cache_enable()
-{
- unsigned long i;
- volatile unsigned int j;
-
- /* ES2 onwards we can disable/enable L2 ourselves */
- if (get_cpu_rev() = CPU_3XX_ES20) {
- __asm__ __volatile__(mrc p15, 0, %0, c1, c0, 1:=r(i));
- __asm__ __volatile__(orr %0, %0, #0x2:=r(i));
- __asm__ __volatile__(mcr p15, 0, %0, c1, c0, 1:=r(i));
- } else {
- /* Save r0, r12 and restore them after usage */
- __asm__ __volatile__(mov %0, r12:=r(j));
- __asm__ __volatile__(mov %0, r0:=r(i));
-
- /*
-* GP Device ROM code API usage here
-* r12 = AUXCR Write function and r0 value
-*/
- __asm__ __volatile__(mov r12, #0x3);
- __asm__ __volatile__(mrc p15, 0, r0, c1, c0, 1);
- __asm__ __volatile__(orr r0, r0, #0x2);
- /* SMI instruction to call ROM Code API */
- __asm__ __volatile__(.word 0xE1600070);
- __asm__ __volatile__(mov r0, %0:=r(i));
- __asm__ __volatile__(mov r12, %0:=r(j));
- }
-
-}
-
-void l2cache_disable()
-{
- unsigned long i;
- volatile unsigned int j;
-
- /* ES2 onwards we can disable/enable L2 ourselves */
- if (get_cpu_rev() = CPU_3XX_ES20) {
- __asm__ __volatile__(mrc p15, 0, %0, c1, c0, 1:=r(i));
- __asm__ __volatile__(bic %0, %0, #0x2:=r(i));
- __asm__ __volatile__(mcr p15, 0, %0, c1, c0, 1:=r(i));
- } else {
- /* Save r0, r12 and restore them after usage */
- __asm__ __volatile__(mov %0, r12:=r(j));
- __asm__ __volatile__(mov %0, r0:=r(i));
-
- /*
-* GP Device ROM code API usage here
-* r12 = AUXCR Write function and r0 value
-*/
- __asm__ __volatile__(mov r12, #0x3);
- __asm__ __volatile__(mrc p15, 0, r0, c1, c0, 1);
- __asm__ __volatile__(bic r0, r0, #0x2);
- /* SMI instruction to call ROM Code API */
- __asm__ __volatile__(.word 0xE1600070);
- __asm__ __volatile__(mov r0, %0:=r(i));
- __asm__ __volatile__(mov r12, %0:=r(j));
- }
-}
-
static void cache_flush(void)
{
asm (mcr p15, 0, %0, c7, c5, 0: :r (0));
diff --git a/cpu/arm_cortexa8/omap3/Makefile b/cpu/arm_cortexa8/omap3/Makefile
index b96b3dd..f83036b 100644
--- a/cpu/arm_cortexa8/omap3/Makefile
+++ b/cpu/arm_cortexa8/omap3/Makefile
@@ -26,7 +26,7 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(SOC).a
SOBJS := lowlevel_init.o
-COBJS := sys_info.o board.o clock.o interrupts.o mem.o syslib.o
+COBJS := sys_info.o board.o clock.o interrupts.o mem.o syslib.o cache.o
SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS))
diff --git a/cpu/arm_cortexa8/omap3/board.c b/cpu/arm_cortexa8/omap3/board.c
index 51d5cf6..439ea6a 100644
--- a/cpu/arm_cortexa8/omap3/board.c
+++ b/cpu/arm_cortexa8/omap3/board.c
@@ -36,6 +36,7 @@
#include asm/io.h
#include asm/arch/sys_proto.h
Re: [U-Boot] [PATCH] The omap3 L2 cache enable/disable function to omap3 dependent code
Dear Wolfgang,
I fixed the deficiencies like the following :
http://lists.denx.de/pipermail/u-boot/2009-June/053534.html
And, I use git-format-patch.
One more thing,
I wanted to tell that this is the exact time in the unmatch-naming case,
by the following thread. :
http://lists.denx.de/pipermail/u-boot/2009-June/053533.html
It's my fault that u don't understand my words :)
BTW, Very thanks to review.
Best Regards,
riverful
2009/6/1 Kim, Heung Jun river...@gmail.com:
CC: Dirk Behme dirk.be...@googlemail.com
Signed-off-by: HeungJun, Kim riverful@samsung.com
---
The L2 cache enable/disable function in the cpu/arm_cortexa8/cpu.c moved
to cpu/arm_cortexa8/omap3/cache.c.
This patches fixes the First issue in the following
http://lists.denx.de/pipermail/u-boot/2009-May/053433.html
The Second issue is fixed by
http://lists.denx.de/pipermail/u-boot/2009-May/053490.html
cpu/arm_cortexa8/cpu.c | 68 +-
cpu/arm_cortexa8/omap3/Makefile | 2 +-
cpu/arm_cortexa8/omap3/board.c | 5 +-
cpu/arm_cortexa8/omap3/cache.c | 99
include/asm-arm/arch-omap3/sys_proto.h | 1 -
include/asm-arm/cache.h | 37
6 files changed, 143 insertions(+), 69 deletions(-)
create mode 100644 cpu/arm_cortexa8/omap3/cache.c
create mode 100644 include/asm-arm/cache.h
diff --git a/cpu/arm_cortexa8/cpu.c b/cpu/arm_cortexa8/cpu.c
index 3e1780b..96f42a9 100644
--- a/cpu/arm_cortexa8/cpu.c
+++ b/cpu/arm_cortexa8/cpu.c
@@ -35,15 +35,12 @@
#include command.h
#include asm/arch/sys_proto.h
#include asm/system.h
+#include asm/cache.h
#ifdef CONFIG_USE_IRQ
DECLARE_GLOBAL_DATA_PTR;
#endif
-#ifndef CONFIG_L2_OFF
-void l2cache_disable(void);
-#endif
-
static void cache_flush(void);
int cpu_init(void)
@@ -80,7 +77,7 @@ int cleanup_before_linux(void)
#ifndef CONFIG_L2_OFF
/* turn off L2 cache */
- l2cache_disable();
+ l2_cache_disable();
/* invalidate L2 cache also */
v7_flush_dcache_all(get_device_type());
#endif
@@ -89,71 +86,12 @@ int cleanup_before_linux(void)
asm(mcr p15, 0, %0, c7, c10, 4: :r(i));
#ifndef CONFIG_L2_OFF
- l2cache_enable();
+ l2_cache_enable();
#endif
return 0;
}
-void l2cache_enable()
-{
- unsigned long i;
- volatile unsigned int j;
-
- /* ES2 onwards we can disable/enable L2 ourselves */
- if (get_cpu_rev() = CPU_3XX_ES20) {
- __asm__ __volatile__(mrc p15, 0, %0, c1, c0, 1:=r(i));
- __asm__ __volatile__(orr %0, %0, #0x2:=r(i));
- __asm__ __volatile__(mcr p15, 0, %0, c1, c0, 1:=r(i));
- } else {
- /* Save r0, r12 and restore them after usage */
- __asm__ __volatile__(mov %0, r12:=r(j));
- __asm__ __volatile__(mov %0, r0:=r(i));
-
- /*
- * GP Device ROM code API usage here
- * r12 = AUXCR Write function and r0 value
- */
- __asm__ __volatile__(mov r12, #0x3);
- __asm__ __volatile__(mrc p15, 0, r0, c1, c0, 1);
- __asm__ __volatile__(orr r0, r0, #0x2);
- /* SMI instruction to call ROM Code API */
- __asm__ __volatile__(.word 0xE1600070);
- __asm__ __volatile__(mov r0, %0:=r(i));
- __asm__ __volatile__(mov r12, %0:=r(j));
- }
-
-}
-
-void l2cache_disable()
-{
- unsigned long i;
- volatile unsigned int j;
-
- /* ES2 onwards we can disable/enable L2 ourselves */
- if (get_cpu_rev() = CPU_3XX_ES20) {
- __asm__ __volatile__(mrc p15, 0, %0, c1, c0, 1:=r(i));
- __asm__ __volatile__(bic %0, %0, #0x2:=r(i));
- __asm__ __volatile__(mcr p15, 0, %0, c1, c0, 1:=r(i));
- } else {
- /* Save r0, r12 and restore them after usage */
- __asm__ __volatile__(mov %0, r12:=r(j));
- __asm__ __volatile__(mov %0, r0:=r(i));
-
- /*
- * GP Device ROM code API usage here
- * r12 = AUXCR Write function and r0 value
- */
- __asm__ __volatile__(mov r12, #0x3);
- __asm__ __volatile__(mrc p15, 0, r0, c1, c0, 1);
- __asm__ __volatile__(bic r0, r0, #0x2);
- /* SMI instruction to call ROM Code API */
- __asm__ __volatile__(.word 0xE1600070);
- __asm__ __volatile__(mov r0, %0:=r(i));
- __asm__ __volatile__(mov r12, %0:=r(j));
- }
-}
-
static void cache_flush(void)
{
asm (mcr p15, 0, %0, c7, c5, 0: :r (0));
diff --git a/cpu/arm_cortexa8/omap3/Makefile b/cpu/arm_cortexa8/omap3/Makefile
index b96b3dd..f83036b 100644
--- a/cpu/arm_cortexa8/omap3/Makefile
+++
[U-Boot] REJECT: Too many recipients to the message
Hi, there is an increasing number of postings with loong lists of recipients (10 addresses and more); usually several of these are regular and active users of this mailing list so this is actually redundant; for the remaining addresses question is if these people really need to be informed, and if so, if they should rather subscribe to the list (or if a company-internal mailing list address should be used instead). So far, I have manually ACKed all postings that were helt by the mailing list software because of too many recipients. From now on, I will not do this any more, but rather reject those messages. Please restrict yourself - 10 or more explicit reciepients are not really needed. 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 Success covers a multitude of blunders. - George Bernard Shaw ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3] board support patch for phyCORE-MPC5200B-tiny
Dear Jon Smirl,
In message 20090601150640.12311.66146.st...@terra you wrote:
Add support for the Phytec phyCORE-MPC5200B-tiny. Code originally from
Pengutronix.de.
Added MAKEALL and MAINTAINER entry per last posting.
Signed-off-by: Jon Smirl jonsm...@gmail.com
...
+pcm030_config \
+pcm030_LOWBOOT_config: unconfig
+ @ include/config.h
+ @[ -z $(findstring LOWBOOT_,$@) ] || \
+ { echo TEXT_BASE = 0xFF00 board/phytec/pcm030/config.tmp
; \
+ echo ... with LOWBOOT configuration ; \
+ }
+ @$(MKCONFIG) -a pcm030 ppc mpc5xxx pcm030 phytec
+ @ echo remember to set pcm030_REV to 0 for rev 1245.0 rev or to 1 for
rev 1245.1
Please get rid of this echo here.
Otherwise fine with me.
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
Absolute: Independent, irresponsible. An absolute monarchy is one in
which the sovereign does as he pleases so long as he pleases the
assassins. Not many absolute monarchies are left, most of them having
been replaced by limited monarchies, where the soverign's power for
evil (and for good) is greatly curtailed, and by republics, which are
governed by chance. - Ambrose Bierce
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Enable display CPU-Info for at91sam9261
Signed-off-by: Remy Bohmer li...@bohmer.net --- include/configs/at91sam9261ek.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/include/configs/at91sam9261ek.h b/include/configs/at91sam9261ek.h index fdaa71c..9a50347 100644 --- a/include/configs/at91sam9261ek.h +++ b/include/configs/at91sam9261ek.h @@ -45,6 +45,8 @@ #define CONFIG_SKIP_LOWLEVEL_INIT #define CONFIG_SKIP_RELOCATE_UBOOT +#define CONFIG_DISPLAY_CPUINFO 1 + /* * Hardware drivers */ -- 1.6.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] REJECT: Too many recipients to the message
Jerry Van Baren wrote: That is actually a MailMan feature. If you go to your personal configuration page, you will find the last option to be... Avoid duplicate copies of messages? When you are listed explicitly in the To: or Cc: headers of a list message, you can opt to not receive another copy from the mailing list. Select Yes to avoid receiving copies from the mailing list; select No to receive copies. I already have that set to no. It's not the list e-mail that isn't making it, but the direct CC e-mail. It only happens some of the time. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4] board support patch for phyCORE-MPC5200B-tiny
Add support for the Phytec phyCORE-MPC5200B-tiny. Code originally from
Pengutronix.de.
Added MAKEALL and MAINTAINER entry per last posting.
Signed-off-by: Jon Smirl jonsm...@gmail.com
---
MAINTAINERS |4
MAKEALL |1
Makefile|9 +
board/phytec/pcm030/Makefile| 50
board/phytec/pcm030/config.mk | 42 +++
board/phytec/pcm030/mt46v32m16-75.h | 54
board/phytec/pcm030/pcm030.c| 219
cpu/mpc5xxx/ide.c |3
include/configs/pcm030.h| 472 +++
9 files changed, 854 insertions(+), 0 deletions(-)
create mode 100644 board/phytec/pcm030/Makefile
create mode 100644 board/phytec/pcm030/config.mk
create mode 100644 board/phytec/pcm030/mt46v32m16-75.h
create mode 100644 board/phytec/pcm030/pcm030.c
create mode 100644 include/configs/pcm030.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 3d50668..1385ac1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -407,6 +407,10 @@ Andre Schwarz andre.schw...@matrix-vision.de
mvbc_p MPC5200
mvblm7 MPC8343
+Jon Smirl jonsm...@gmail.com
+
+ pcm030 MPC5200
+
Timur Tabi ti...@freescale.com
MPC8349E-mITX MPC8349
diff --git a/MAKEALL b/MAKEALL
index 57dd425..659730f 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -60,6 +60,7 @@ LIST_5xxx= \
munices \
MVBC_P \
o2dnt \
+ pcm030 \
pf5200 \
PM520 \
TB5200 \
diff --git a/Makefile b/Makefile
index 4f30560..752f8be 100644
--- a/Makefile
+++ b/Makefile
@@ -687,6 +687,15 @@ MVBC_P_config: unconfig
o2dnt_config: unconfig
@$(MKCONFIG) o2dnt ppc mpc5xxx o2dnt
+pcm030_config \
+pcm030_LOWBOOT_config: unconfig
+ @ include/config.h
+ @[ -z $(findstring LOWBOOT_,$@) ] || \
+ { echo TEXT_BASE = 0xFF00 board/phytec/pcm030/config.tmp
; \
+ echo ... with LOWBOOT configuration ; \
+ }
+ @$(MKCONFIG) -a pcm030 ppc mpc5xxx pcm030 phytec
+
pf5200_config: unconfig
@$(MKCONFIG) pf5200 ppc mpc5xxx pf5200 esd
diff --git a/board/phytec/pcm030/Makefile b/board/phytec/pcm030/Makefile
new file mode 100644
index 000..22ce8e6
--- /dev/null
+++ b/board/phytec/pcm030/Makefile
@@ -0,0 +1,50 @@
+#
+# (C) Copyright 2003-2007
+# Wolfgang Denk, DENX Software Engineering, w...@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
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).a
+
+COBJS := $(BOARD).o
+
+SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+SOBJS := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS)
+ $(AR) $(ARFLAGS) $@ $(OBJS)
+
+clean:
+ rm -f $(SOBJS) $(OBJS)
+
+distclean: clean
+ rm -f $(LIB) core *.bak $(obj).depend
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/phytec/pcm030/config.mk b/board/phytec/pcm030/config.mk
new file mode 100644
index 000..5d3469c
--- /dev/null
+++ b/board/phytec/pcm030/config.mk
@@ -0,0 +1,42 @@
+#
+# (C) Copyright 2003
+# Wolfgang Denk, DENX Software Engineering, w...@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
[U-Boot] UBIFS will not build for Davinci (2006.06-rc2)
Hi, I am trying to add UBIFS support to the davinci_dvevm board (ARCH=arm, CPU=arm926ejs, BOARD=dvevm, VENDOR=davinci, SOC=davinci) configuration. However, I encountered a number of issues that lead me to belive that UBIFS support is limited to PowerPC architectures. Has UBIFS support been built and tested on any platform other than PowerPC? The patch I used to enable UBIFS support on the DVEVM board is: --- /home/tester/uboot/u-boot-2009.06-rc2.orig/include/configs/davinci_dvevm.h 2009-05-15 14:29:23.0 -0700 +++ /home/tester/uboot/u-boot-2009.06-rc2/include/configs/davinci_dvevm.h 2009-06-01 11:15:59.0 -0700 @@ -51,7 +51,7 @@ /*===*/ #define DV_EVM #define CONFIG_SYS_NAND_SMALLPAGE -#define CONFIG_SYS_USE_NOR +#define CONFIG_SYS_USE_NAND /*===*/ /* SoC Configuration */ /*===*/ @@ -129,6 +129,14 @@ #define CONFIG_SYS_MAX_NAND_DEVICE1/* Max number of NAND devices */ #define CONFIG_ENV_OFFSET0x0/* Block 0--not used by bootcode */ #define DEF_BOOTM +#define CONFIG_MTD_PARTITIONS +#define CONFIG_CMD_MTDPARTS +#define CONFIG_CMD_UBI +#define CONFIG_CMD_UBIFS +#define CONFIG_SYS_64BIT_VSPRINTF +#define CONFIG_RBTREE +#define CONFIG_LZO #elif defined(CONFIG_SYS_USE_NOR) #ifdef CONFIG_NOR_UART_BOOT #define CONFIG_SKIP_LOWLEVEL_INIT/* U-Boot is loaded by a bootloader */ The first problem I encountered was a compiler error: In file included from ubifs.c:27: ubifs.h:468: error: conflicting types for '__set_bit' /home/tester/uboot/u-boot-2009.06-rc2/include/asm/bitops.h:29: error: previous definition of '__set_bit' was here ubifs.h:476: error: conflicting types for '__clear_bit' /home/tester/uboot/u-boot-2009.06-rc2/include/asm/bitops.h:36: error: previous definition of '__clear_bit' was here make[2]: *** [ubifs.o] Error 1 The error seems to occur becase fs/ubifs/ubifs.h defines two inline functions, __set_bit() and __clear_bit(). For some architectures, including ARM, these functions are already defined in bitops.h AND the prototypes are different from the ones in ubifs.h: __set_bit() __clear_bit(): include/asm-arm/bitops.h include/asm-microblaze/bitops.h __set_bit() only: include/asm-blackfin/bitops.h include/asm-i386/bitops.h include/asm-mips/bitops.h For a quick fix (and probably not the recommended one), I renamed all the __set_bit() and __clear_bit() symbols in fs/ubifs to be __ubi_set_bit() and __ubi_clear_bit(). The second problem was a compiler error in lzo1x_decompress.c: lzo1x_decompress.c:17:27: error: asm/unaligned.h: No such file or directory lzo1x_decompress.c: In function 'lzo1x_decompress_safe': lzo1x_decompress.c:72: warning: implicit declaration of function 'put_unaligned' lzo1x_decompress.c:72: warning: implicit declaration of function 'get_unaligned' lzo1x_decompress.c:140: warning: implicit declaration of function 'get_unaligned_le16' make[2]: *** [lzo1x_decompress.o] Error 1 File unaligned.h is ONLY present in include/asm-ppc. So I undefined CONFIG_LZO and now I get linker errors: fs/ubifs/libubifs.a(super.o): In function `init_constants_early': /home/tester/uboot/u-boot-2009.06-rc2/fs/ubifs/super.c:317: undefined reference to `fls' fs/ubifs/libubifs.a(lpt.o): In function `dirty_cow_nnode': /home/tester/uboot/u-boot-2009.06-rc2/fs/ubifs/lpt.c:893: undefined reference to `test_and_set_bit' fs/ubifs/libubifs.a(lpt.o): In function `dirty_cow_pnode': /home/tester/uboot/u-boot-2009.06-rc2/fs/ubifs/lpt.c:944: undefined reference to `test_and_set_bit' fs/ubifs/libubifs.a(lpt.o): In function `do_calc_lpt_geom': /home/tester/uboot/u-boot-2009.06-rc2/fs/ubifs/lpt.c:81: undefined reference to `fls' /home/tester/uboot/u-boot-2009.06-rc2/fs/ubifs/lpt.c:82: undefined reference to `fls' /home/tester/uboot/u-boot-2009.06-rc2/fs/ubifs/lpt.c:83: undefined reference to `fls' /home/tester/uboot/u-boot-2009.06-rc2/fs/ubifs/lpt.c:84: undefined reference to `fls' /home/tester/uboot/u-boot-2009.06-rc2/fs/ubifs/lpt.c:87: undefined reference to `fls' fs/ubifs/libubifs.a(lpt.o):/home/tester/uboot/u-boot-2009.06-rc2/fs/ubifs/lpt.c:89: more undefined references to `fls' follow fs/ubifs/libubifs.a(tnc.o): In function `dirty_cow_znode': /home/tester/uboot/u-boot-2009.06-rc2/fs/ubifs/tnc.c:274: undefined reference to `test_and_set_bit' fs/ubifs/libubifs.a(ubifs.o):(.data+0xc): undefined reference to `lzo1x_decompress_safe' * Function test_and_set_bit() is declared in include/asm-arm/bitops.h but it is never defined, like it is for other architectures. * Function fls() is ONLY defined for PowerPC architectures. * Function lzo1x_decompress_safe is missing, of course, because I undefined CONFIG_LZO. Also, there are some C library related linker errors: /usr/local/WindRiver_3_0/wrlinux-3.0/layers/wrll-toolchain-4.3-85/arm/toolchain/x86-linux2/bin/../lib/gcc/arm-wrs-linux-gnueabi/4.3.2/libgcc.a(_udivsi3.o): In function `__aeabi_uidiv': (.text+0x0): multiple definition of
Re: [U-Boot] [PATCH V2] Add display cpuinfo for Atmel at91 arm926ejs based cores
Hi Rémy,
I do have a few comments, see below:
On Mon, Jun 01, 2009 at 08:21:42PM +0200, Remy Bohmer wrote:
V2 reworked comments from Jean-Christophe PLAGNIOL-VILLARD
[...]
+COBJS-$(CONFIG_DISPLAY_CPUINFO) +=cpuinfo.o
missing space ?
+ switch ((cidr AT91_CIDR_EPROC) 5) {
+ /* 0x1 = ARM946ES, 0x2 = ARM7TDMI, 0x4 = ARM920T */
+ case 0x5: txt = ARM926EJS;break;
+ default: txt = undefined;break;
since there are only four choices (until now at least...), why not
put the 'txt' for all of them ?
and the 'undefined' string is not a good choice: it represents a
configuration not known to U-Boot, but its numeric value is well
defined. So I suggest you change this to 'unknown', or even better,
'unknown: 0xfoo'.
+ }
+ printf(Embedded Processor: %s\n, txt);
+
+ switch ((cidr AT91_CIDR_ARCH) 20) {
+ case 0x19: txt = AT91SAM9xx; break;
+ case 0x29: txt = AT91SAM9XExx;break;
+ case 0x39: txt = CAP9;break;
+ default: txt = undefined; break;
same comments as above for 'undefined'.
+ switch ((cidr AT91_CIDR_NVPTYP) 28) {
+ case 0x0: txt = ROM; break;
+ case 0x1: txt = ROMless or onchip flash; break;
+ case 0x2: txt = Embedded flash memory; break;
+ case 0x3: txt = ROM and Embedded flash memory; break;
+ case 0x4: txt = SRAM emulating ROM;break;
+ default: txt = undefined; break;
ditto.
+ switch (cidr AT91_CIDR_SRAMSIZ) {
+ case AT91_CIDR_SRAMSIZ_1K: txt = 1K; break;
+ case AT91_CIDR_SRAMSIZ_2K: txt = 2K; break;
+ case AT91_CIDR_SRAMSIZ_112K: txt = 112K; break;
+ case AT91_CIDR_SRAMSIZ_4K: txt = 4K; break;
+ case AT91_CIDR_SRAMSIZ_80K: txt = 80K;break;
+ case AT91_CIDR_SRAMSIZ_160K: txt = 160K; break;
+ case AT91_CIDR_SRAMSIZ_8K: txt = 8K; break;
+ case AT91_CIDR_SRAMSIZ_16K: txt = 16K;break;
+ case AT91_CIDR_SRAMSIZ_32K: txt = 32K;break;
+ case AT91_CIDR_SRAMSIZ_64K: txt = 64K;break;
+ case AT91_CIDR_SRAMSIZ_128K: txt = 128K; break;
+ case AT91_CIDR_SRAMSIZ_256K: txt = 256K; break;
+ case AT91_CIDR_SRAMSIZ_96K: txt = 96K;break;
+ case AT91_CIDR_SRAMSIZ_512K: txt = 512K; break;
+ default: txt = undefined;break;
bad alignment here (you did align the 'txt =' properly in all other
switch/case statements, but not here).
ditto for 'undefined'.
Stelian.
--
Stelian Pop stel...@popies.net
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] REJECT: Too many recipients to the message
Dear Scott Wood, In message 4a242071.1010...@freescale.com you wrote: there is an increasing number of postings with loong lists of recipients (10 addresses and more); usually several of these are regular and active users of this mailing list so this is actually redundant; It is not redundant -- including a person in the CC list brings the mail to their attention faster (and with less chances of missing it) than if they have to pick it out of the list. An email message is a message is a message, isn't it? The message on the list and the Cc: are identical, aren't they? What is the difference whether you receive one or two identical copies of a message? How about reconfiguring the list software instead? I see no reason for that yet. 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 If a train station is a place where a train stops, then what's a workstation? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] REJECT: Too many recipients to the message
Dear Scott Wood, In message 4a242313.3060...@freescale.com you wrote: I already have that set to no. It's not the list e-mail that isn't making it, but the direct CC e-mail. It only happens some of the time. To the best of my knowledge both messages get sent, but it seems some servers drop them on the receiving side, if the message ID is already known. 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 A student of probability soon realizes that by its nature the billion-to-one chance crops up nine times out of ten, and that the greatest odds boil down to a double-sided statement: it will happen, or it will not. - Terry Pratchett, _The Dark Side of the Sun_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Enable display CPU-Info for at91sam9261
On Mon, Jun 01, 2009 at 08:21:43PM +0200, Remy Bohmer wrote: Signed-off-by: Remy Bohmer li...@bohmer.net --- include/configs/at91sam9261ek.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/include/configs/at91sam9261ek.h b/include/configs/at91sam9261ek.h index fdaa71c..9a50347 100644 --- a/include/configs/at91sam9261ek.h +++ b/include/configs/at91sam9261ek.h @@ -45,6 +45,8 @@ #define CONFIG_SKIP_LOWLEVEL_INIT #define CONFIG_SKIP_RELOCATE_UBOOT +#define CONFIG_DISPLAY_CPUINFO 1 For homogeneity reasons, since this is a generic AT91 config option, I think it makes sense to define this by default for all the AT91 boards - or not define it at all. Your pick. Stelian. -- Stelian Pop stel...@popies.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] MX31: Add NAND SPL for i.MX31.
Hi 2009/6/1 Scott Wood scottw...@freescale.com: On Sat, May 30, 2009 at 09:54:56AM +0200, Magnus Lilja wrote: 2009/5/29 Scott Wood scottw...@freescale.com: The bad block location is typically different (offset 0 rather than 5) with large page flash. I think that's because of the non-standard imlementation of large page support in the i.MX31 NFC. We should have comments in the code explaining what's going on in such cases. Yes, I'll add that. /Magnus ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] MX31: Add NAND SPL for i.MX31.
Hi
2009/5/30 Magnus Lilja lilja.mag...@gmail.com:
2009/5/29 Scott Wood scottw...@freescale.com:
On Sun, May 03, 2009 at 09:56:57PM +0200, Magnus Lilja wrote:
+static void mx31_nand_page_address(unsigned int page_address)
+{
+ unsigned int page_count;
+
+ writew(0x00, NFC_FLASH_ADDR);
+ writew(NFC_ADDR, NFC_CONFIG2);
+ mx31_wait_ready();
+
+ /* code only for 2kb flash */
+ if (CFG_NAND_PAGE_SIZE == 0x800) {
+ writew(0x00, NFC_FLASH_ADDR);
+ writew(NFC_ADDR, NFC_CONFIG2);
+ mx31_wait_ready();
+ }
+
+ page_count = CFG_NAND_CHIP_SIZE / CFG_NAND_PAGE_SIZE;
+
+ if (page_address = page_count) {
+ page_count--; /* transform 0x0100 to 0x00ff */
+ do {
+ writew(page_address 0xff, NFC_FLASH_ADDR);
+ writew(NFC_ADDR, NFC_CONFIG2);
+ mx31_wait_ready();
+ page_address = page_address 8;
+ page_count = page_count 8;
+ } while (page_count);
+ }
Does the number of address bytes really need to depend on the size of the
flash chip, or can you base it on the number of non-zero bytes in
page_address (the chip will know when the address phase is over because
ALE drops)?
Ok, will try to look into it.
I did try to output only the non-zero bytes in the page_address but
that didn't work at all, u-boot didn't boot Don't know why though.
/Magnus
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] REJECT: Too many recipients to the message
On Mon, Jun 01, 2009 at 10:00:12PM +0200, Wolfgang Denk wrote: Dear Scott Wood, In message 4a242071.1010...@freescale.com you wrote: there is an increasing number of postings with loong lists of recipients (10 addresses and more); usually several of these are regular and active users of this mailing list so this is actually redundant; It is not redundant -- including a person in the CC list brings the mail to their attention faster (and with less chances of missing it) than if they have to pick it out of the list. An email message is a message is a message, isn't it? The message on the list and the Cc: are identical, aren't they? Yes, but how one's MUA / mail client handles them may *not* be identi- cal. Quite a few people configure their MUA to prioritize messages based on whether they are on the To: list, CC:, BCC:, or none of the above (i.e. by list membership). What is the difference whether you receive one or two identical copies of a message? It's a hassle and distraction to deal with duplicates. How about reconfiguring the list software instead? I see no reason for that yet. +1 for not restricting the # of addressees absent a reason other than some of them are often redundant. Tom -- A: Because it breaks the logical| flow of the message.| Email to user 'CTZ001' | at 'email.mot.com' Q: Why is top posting frowned upon? | ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] Add display cpuinfo for Atmel at91 arm926ejs based cores
On 21:59 Mon 01 Jun , Stelian Pop wrote:
Hi Rémy,
I do have a few comments, see below:
On Mon, Jun 01, 2009 at 08:21:42PM +0200, Remy Bohmer wrote:
V2 reworked comments from Jean-Christophe PLAGNIOL-VILLARD
[...]
+COBJS-$(CONFIG_DISPLAY_CPUINFO) +=cpuinfo.o
missing space ?
+ switch ((cidr AT91_CIDR_EPROC) 5) {
+/* 0x1 = ARM946ES, 0x2 = ARM7TDMI, 0x4 = ARM920T */
+ case 0x5: txt = ARM926EJS;break;
+ default: txt = undefined;break;
since there are only four choices (until now at least...), why not
put the 'txt' for all of them ?
We need to use the ifdef to reduce the size impact and not implement
non-supported code is important
and the 'undefined' string is not a good choice: it represents a
configuration not known to U-Boot, but its numeric value is well
defined. So I suggest you change this to 'unknown', or even better,
'unknown: 0xfoo'.
I agree
Best Regards,
J.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Enable display CPU-Info for at91sam9261
On 22:03 Mon 01 Jun , Stelian Pop wrote: On Mon, Jun 01, 2009 at 08:21:43PM +0200, Remy Bohmer wrote: Signed-off-by: Remy Bohmer li...@bohmer.net --- include/configs/at91sam9261ek.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/include/configs/at91sam9261ek.h b/include/configs/at91sam9261ek.h index fdaa71c..9a50347 100644 --- a/include/configs/at91sam9261ek.h +++ b/include/configs/at91sam9261ek.h @@ -45,6 +45,8 @@ #define CONFIG_SKIP_LOWLEVEL_INIT #define CONFIG_SKIP_RELOCATE_UBOOT +#define CONFIG_DISPLAY_CPUINFO 1 For homogeneity reasons, since this is a generic AT91 config option, I think it makes sense to define this by default for all the AT91 boards - or not define it at all. Your pick. for the Atmel's ref boards maybe but for other boards we need to let this choice to each board Maintainer Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] REJECT: Too many recipients to the message
Dear T Ziomek, In message 20090601203258.gg8...@email.mot.com you wrote: Yes, but how one's MUA / mail client handles them may *not* be identi- cal. Quite a few people configure their MUA to prioritize messages based on whether they are on the To: list, CC:, BCC:, or none of the above (i.e. by list membership). I read this as a pro for long cc: lists. What is the difference whether you receive one or two identical copies of a message? It's a hassle and distraction to deal with duplicates. This however is a clear con, isn't it? How about reconfiguring the list software instead? I see no reason for that yet. +1 for not restricting the # of addressees absent a reason other than some of them are often redundant. We neever before had any such problems. Currently these are caused because some messages have 5 (or more) samsung.com addresses listed on Cc:; for example, [PATCH] The omap3 L2 cache enable/disable function to omap3 dependent code has 6 such addresses on Cc: I doubt that this is really necessary. In this specific case, a company-internal distribution list would probably be more appropriate. 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 A Vulcan can no sooner be disloyal than he can exist without breathing. -- Kirk, The Menagerie, stardate 3012.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] REJECT: Too many recipients to the message
Dear T Ziomek, In message 20090601210846.gj8...@email.mot.com you wrote: How about reconfiguring the list software instead? I see no reason for that yet. I see no reason, at least none articulated as of yet, for the current configuration. The current configurations is (1) the default one, and (2) pretty useful to detect list abuse that has not been cought yet by other means. We neever before had any such problems. Currently these are caused because some messages have 5 (or more) samsung.com addresses listed on Cc:; for example, [PATCH] The omap3 L2 cache enable/disable function to omap3 dependent code has 6 such addresses on Cc: And what problem does that cause? Such messages need manual moderation which (1) delays the messages and (2) causes additional work to the list moderator (me). I doubt that this is really necessary. Necessary is in the eye of the beholder here. And IMHO the presump- tion should be that the sender of an email is addressing it properly. Absent either (a) clear, significant abuse of emails' recipients or (b) a measurable and significant impact on the list provider [1], let people CC who they consider appropriate and let the list server send emails to whomever it is asked to send emails to. [1] E.g. exceeding bandwidth quotas, mail delivery being delayed for hours, etc. Messages get delayed, and they exceed my patience quota ;-) In this specific case, a company-internal distribution list would probably be more appropriate. I don't understand what you envision here, or what it would accomplish. They could Cc: u-boot-addi...@foo.com (i. e. just one address) and distribute this internally to anybody who might be interested. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I used to be indecisive, now I'm not sure. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] potential Uboot Ping problem
Hi Steven, On Mon, 2009-06-01 at 08:03 -0700, Steven Zedeck wrote: I guess thats good news. I looked inside the cmd_ping code a bit. I bet there's a while loop somewhere that is waiting for something and may not have a timeout loop. Any ideas? Thanks, Steve Please don't top post, it makes the conversation hard to follow. http://www.caliburn.nl/topposting.html Premi, Sanjeev wrote: -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Steven Zedeck Sent: Monday, June 01, 2009 8:05 PM To: u-boot@lists.denx.de Subject: [U-Boot] potential Uboot Ping problem Hi, It appears the ping in UBOOT is broken. The ping works fine if you have a network connection. But if the network connection is disconnected the ping hangs the system. There is no response to Control-C either. I have to power cycle the proto to get back to a UBOOT prompt. Is this a known issue or did I possibly break something? I have a board based on the Atmel AT91SAM9RL-EK. My theory is that it may be a generic problem with the uboot ping. I can't confirm that since the only hardware I have is our protos. It was noticed on the OMAP3EVM last FRI and we were suspecting it to be problem with the omap3 board configuration itself. (Though did not spend much time in debug). Now, I too get a feeling that it could be a generic problem. Best regards, Sanjeev Does anyone else have a board with another MAC/PHY that you can try this on? Ideally, if there is no link, the ping command should just exit gracefully without attempting network operations. Eg on my 8561-based board with no cables plugged in: = ping 192.168.1.1 Auto-neg error, defaulting to 10BT/HD eTSEC1: No link. Auto-neg error, defaulting to 10BT/HD eTSEC2: No link. ping failed; host 192.168.1.1 is not alive there is no delay in the printing of the above info. The tsec driver's init function returns -1 when link isn't detected. Perhaps your ethernet driver should do the same? What happens if you ping a non-existent IP address? Does that also hang the board? Do other network operations hang the board if no ethernet cable is plugged in? Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] REJECT: Too many recipients to the message
Wolfgang Denk wrote: Dear T Ziomek, In message 20090601210846.gj8...@email.mot.com you wrote: How about reconfiguring the list software instead? I see no reason for that yet. I see no reason, at least none articulated as of yet, for the current configuration. The current configurations is (1) the default one, and (2) pretty useful to detect list abuse that has not been cought yet by other means. I don't understand what CC lists have to do with abuse of the mailing list -- any mail generated by a CC is done at the sender's mail server. CC lists do not cause additional mail to be sent by lists.denx.de. At worst, long-running threads can accumulate CCs that are no longer relevant to where the thread has gone (and I'm fine with encouraging those to be trimmed), but that's got nothing to do with the mailing list itself. The only thing that having the list reject such mails will accomplish is that people *not* on the CC list won't see the mail, which is sort of the opposite of the intended effect. We neever before had any such problems. Currently these are caused because some messages have 5 (or more) samsung.com addresses listed on Cc:; for example, [PATCH] The omap3 L2 cache enable/disable function to omap3 dependent code has 6 such addresses on Cc: And what problem does that cause? Such messages need manual moderation which (1) delays the messages and (2) causes additional work to the list moderator (me). That problem is not caused by the CC lists, but rather the configuration of the list server. What problem do the CC lists cause *by themselves*? In this specific case, a company-internal distribution list would probably be more appropriate. I don't understand what you envision here, or what it would accomplish. They could Cc: u-boot-addi...@foo.com (i. e. just one address) and distribute this internally to anybody who might be interested. What would that accomplish (keeping in mind that the CCs are often not for expanding the distribution list but calling specific people's attention to the mail)? If those addicts were uniformly interested in all u-boot mail, why wouldn't they just subscribe to the list? If they're only interested in some threads, what makes you think it will be the same set of 5 (or more) people each time? How should I know that someone wants to be CCed by some address other than what they post with? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Blackfin: add jtagconsole helper script
This script is similar to the netconsole script, but instead works with
the JTAG console device driver that exists on Blackfin parts.
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
tools/jtagconsole | 39 +++
1 files changed, 39 insertions(+), 0 deletions(-)
create mode 100755 tools/jtagconsole
diff --git a/tools/jtagconsole b/tools/jtagconsole
new file mode 100755
index 000..24198c8
--- /dev/null
+++ b/tools/jtagconsole
@@ -0,0 +1,39 @@
+#!/bin/sh
+
+usage() {
+ (
+ echo Usage: $0 [board IP] [board port]
+ echo
+ echo If IP is not specified, 'localhost' will be used
+ echo If port is not specified, '2001' will be used
+ [ -z $* ] exit 0
+ echo
+ echo ERROR: $*
+ exit 1
+ ) 12
+ exit $?
+}
+
+while [ -n $1 ] ; do
+ case $1 in
+ -h|--help) usage;;
+ --)break;;
+ -*)usage Invalid option $1;;
+ *) break;;
+ esac
+ shift
+done
+
+ip=${1:-localhost}
+port=${2:-2001}
+
+if [ -z ${ip} ] || [ -n $3 ] ; then
+ usage Invalid number of arguments
+fi
+
+trap stty icanon echo intr ^C 0 2 3 5 10 13 15
+echo NOTE: the interrupt signal (normally ^C) has been remapped to ^T
+
+stty -icanon -echo intr ^T
+nc ${ip} ${port}
+exit 0
--
1.6.3.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] REJECT: Too many recipients to the message
On Tue, Jun 02, 2009 at 12:00:21AM +0200, Wolfgang Denk wrote: Dear T Ziomek, In message 20090601210846.gj8...@email.mot.com you wrote: How about reconfiguring the list software instead? I see no reason for that yet. I see no reason, at least none articulated as of yet, for the current configuration. The current configurations is (1) the default one, Unless there's a good reason it's the default, I wouldn't defer to that in the presence of good arguments otherwise. and (2) pretty useful to detect list abuse that has not been cought yet by other means. What sort(s) of abuse has configuration this helped catch? We neever before had any such problems. Currently these are caused because some messages have 5 (or more) samsung.com addresses listed on Cc:; for example, [PATCH] The omap3 L2 cache enable/disable function to omap3 dependent code has 6 such addresses on Cc: And what problem does that cause? Such messages need manual moderation which (1) delays the messages and (2) causes additional work to the list moderator (me). But that's a problem caused by the list server's config, not inherently by the # of CCs. I doubt that this is really necessary. Necessary is in the eye of the beholder here. And IMHO the presump- tion should be that the sender of an email is addressing it properly. Absent either (a) clear, significant abuse of emails' recipients or (b) a measurable and significant impact on the list provider [1], let people CC who they consider appropriate and let the list server send emails to whomever it is asked to send emails to. [1] E.g. exceeding bandwidth quotas, mail delivery being delayed for hours, etc. I take this example back; as Scott reminds us the CCs don't affect the list server (except for a few more bytes in the headers of a message it relays). In which case I have even more trouble seeing the harm in re- moving the list server's [apparently arbitrary and unsubstantiated] CC limit. Or at least changing it to a much higher number. Messages get delayed, and they exceed my patience quota ;-) Again, not inherently because of having too many CCs. Raise/remove the limit, and your immediate issue is resolved. What's not to like? Tom -- A: Because it breaks the logical| flow of the message.| Email to user 'CTZ001' | at 'email.mot.com' Q: Why is top posting frowned upon? | ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Canyonlands SATA harddisk driver
Hello Kuribayashi-san,
Please make sure I'm not talking about register definition structures.
They're harmless, and no need to be cleaned up.
The definition of the register of DMA is the following.
However, the structure is used a little for the usage in which DMA is disabled.
struct dmareg {
u32 low;
u32 high;
};
struct dma_chan_regs {
struct dmareg sar;
struct dmareg dar;
struct dmareg llp;
struct dmareg ctl;
struct dmareg sstat;
struct dmareg dstat;
struct dmareg sstatar;
struct dmareg dstatar;
struct dmareg cfg;
struct dmareg sgr;
struct dmareg dsr;
};
struct dma_interrupt_regs {
struct dmareg tfr;
struct dmareg block;
struct dmareg srctran;
struct dmareg dsttran;
struct dmareg error;
};
struct ahb_dma_regs {
struct dma_chan_regschan_regs[DMA_NUM_CHAN_REGS];
struct dma_interrupt_regs interrupt_raw;
struct dma_interrupt_regs interrupt_status;
struct dma_interrupt_regs interrupt_mask;
struct dma_interrupt_regs interrupt_clear;
struct dmareg statusInt;
struct dmareg rq_srcreg;
struct dmareg rq_dstreg;
struct dmareg rq_sgl_srcreg;
struct dmareg rq_sgl_dstreg;
struct dmareg rq_lst_srcreg;
struct dmareg rq_lst_dstreg;
struct dmareg dma_cfg;
struct dmareg dma_chan_en;
struct dmareg dma_id;
struct dmareg dma_test;
struct dmareg res1;
struct dmareg res2;
/* DMA Comp Params
* Param 6 = dma_param[0], Param 5 = dma_param[1],
* Param 4 = dma_param[2] ...
*/
struct dmareg dma_params[6];
};
But, other local, private, resource management structures are encouraged
to be shrinked/optimized, as it's just waste of ROM space.
Originally U-boot of PowerPC is not importance for the size because the size is
large.
I will point out and object about you.
It is important to maintain interchangeability with the Linux kernel driver.
It is important that maintenance is good.
Regards,
Kazuaki Ichinohe
Shinya Kuribayashi wrote:
Kazuaki Ichinohe wrote:
DMA function was scheduled to be developed as my schedule.
However, the development of the DMA function is discontinued once now.
The structure of the register that controls DMA has not been used any
longer.
I will e-mail the source code ( removed the struct of DMA register )
later.
Please make sure I'm not talking about register definition structures.
They're harmless, and no need to be cleaned up.
But, other local, private, resource management structures are encouraged
to be shrinked/optimized, as it's just waste of ROM space.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Canyonlands SATA harddisk driver
Kazuaki Ichinohe wrote: But, other local, private, resource management structures are encouraged to be shrinked/optimized, as it's just waste of ROM space. Originally U-boot of PowerPC is not importance for the size because the size is large. I will point out and object about you. As said before, I'm fine with this driver as is. I've just pointed out it has bunch of unused struct members in it. It is important to maintain interchangeability with the Linux kernel driver. It is important that maintenance is good. Hm, I don't see any good aspects with doing so, but that's also fine with me. -- Shinya Kuribayashi NEC Electronics ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] potential Uboot Ping problem
Peter Tyser wrote: Hi Steven, On Mon, 2009-06-01 at 08:03 -0700, Steven Zedeck wrote: I guess thats good news. I looked inside the cmd_ping code a bit. I bet there's a while loop somewhere that is waiting for something and may not have a timeout loop. Any ideas? Thanks, Steve Please don't top post, it makes the conversation hard to follow. http://www.caliburn.nl/topposting.html Premi, Sanjeev wrote: -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Steven Zedeck Sent: Monday, June 01, 2009 8:05 PM To: u-boot@lists.denx.de Subject: [U-Boot] potential Uboot Ping problem Hi, It appears the ping in UBOOT is broken. The ping works fine if you have a network connection. But if the network connection is disconnected the ping hangs the system. There is no response to Control-C either. I have to power cycle the proto to get back to a UBOOT prompt. Is this a known issue or did I possibly break something? I have a board based on the Atmel AT91SAM9RL-EK. My theory is that it may be a generic problem with the uboot ping. I can't confirm that since the only hardware I have is our protos. It was noticed on the OMAP3EVM last FRI and we were suspecting it to be problem with the omap3 board configuration itself. (Though did not spend much time in debug). Now, I too get a feeling that it could be a generic problem. Best regards, Sanjeev Does anyone else have a board with another MAC/PHY that you can try this on? Ideally, if there is no link, the ping command should just exit gracefully without attempting network operations. Eg on my 8561-based board with no cables plugged in: = ping 192.168.1.1 Auto-neg error, defaulting to 10BT/HD eTSEC1: No link. Auto-neg error, defaulting to 10BT/HD eTSEC2: No link. ping failed; host 192.168.1.1 is not alive there is no delay in the printing of the above info. The tsec driver's init function returns -1 when link isn't detected. Perhaps your ethernet driver should do the same? What happens if you ping a non-existent IP address? Does that also hang the board? Do other network operations hang the board if no ethernet cable is plugged in? Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot The ethernet driver is also from the uboot distribution. Its enc28j60.c. I'll need to go through it to see where its hanging assuming its in that driver or the ping code that calls it. thanks, Steve -- View this message in context: http://www.nabble.com/potential-Uboot-Ping-problem-tp23815872p23824737.html Sent from the Uboot - Users mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Canyonlands SATA harddisk driver
On 18:07 Fri 29 May , Shinya Kuribayashi wrote: Kazuaki Ichinohe wrote: DMA function was scheduled to be developed as my schedule. However, the development of the DMA function is discontinued once now. The structure of the register that controls DMA has not been used any longer. I will e-mail the source code ( removed the struct of DMA register ) later. Please make sure I'm not talking about register definition structures. They're harmless, and no need to be cleaned up. But, other local, private, resource management structures are encouraged to be shrinked/optimized, as it's just waste of ROM space. if we remove it from the source, it will be harder to integrate upgrade on both side. As done for the nand and ubi add ifndef __U_BOOT__ will allow to reduce the size impact without the integration difficult Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] USB gadget interface from cdc branch into mainline
On Mon, Jun 1, 2009 at 10:38 AM, Remy Bohmer li...@bohmer.net wrote: Yeah, I planned it for the next release. Is it going to be u-boot-2009.06? I am interested in supporting OMAP3 musb drivers with this new interface. Thanks, -Raghu ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-BOOT] nand merge problem
Thanks Scott,
it's work. :-)
Scott Wood wrote:
Try something like this instead:
static void jz_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int ctrl)
{
struct nand_chip *this = mtd-priv;
unsigned long nandaddr = (unsigned long)this-IO_ADDR_W;
if (ctrl NAND_CTRL_CHANGE) {
/* Change this to use I/O accessors. */
if (ctrl NAND_NCE) {
REG_EMC_NFCSR |= EMC_NFCSR_NFCE1;
} else {
/*
* Why set only one bit when NCE is high, but clear
* four when low? Why clear separate bits in the same
* register one at a time?
*/
my mistake. I copy those code form the device's kernel source code.
REG_EMC_NFCSR = ~EMC_NFCSR_NFCE1;
REG_EMC_NFCSR = ~EMC_NFCSR_NFCE2;
REG_EMC_NFCSR = ~EMC_NFCSR_NFCE3;
REG_EMC_NFCSR = ~EMC_NFCSR_NFCE4;
}
}
if (cmd == NAND_CMD_NONE)
return;
if (ctrl NAND_CLE)
nandaddr |= 0x8000;
else /* must be ALE */
nandaddr |= 0x0001;
writeb(cmd, (uint8_t *)nandaddr);
}
-Scott
--
Best Regards
Xiangfu Liu
jabber : xiangf...@gmail.com
skype : xiangfu.z
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] REJECT: Too many recipients to the message
Dear Wolfgang everyone, It happened ”Too many recipients to the message”, and I'm very sorry that my messages's many CC cause this event. Before that, I didn't find the recipients # limits on the u-boot mailinglist guidelines. So, I just send the messages like other my situation. If It's hard to configure mailing list server, I think the warnning about“The limit of CC” is showed on the u-boot mailinglist guidlines or anywhere. Thanks Sorry. Best Regards, Riverful - 원본 메시지 - 보낸 사람: T Ziomek ctz...@email.mot.com 보낸 날짜: 2009년 6월 2일 화요일 오전 9:09 받는 사람: Wolfgang Denk w...@denx.de 참조: Scott Wood scottw...@freescale.com; u-boot@lists.denx.de 제목: Re: [U-Boot] REJECT: Too many recipients to the message On Tue, Jun 02, 2009 at 12:00:21AM +0200, Wolfgang Denk wrote: Dear T Ziomek, In message 20090601210846.gj8...@email.mot.com you wrote: How about reconfiguring the list software instead? I see no reason for that yet. I see no reason, at least none articulated as of yet, for the current configuration. The current configurations is (1) the default one, Unless there's a good reason it's the default, I wouldn't defer to that in the presence of good arguments otherwise. and (2) pretty useful to detect list abuse that has not been cought yet by other means. What sort(s) of abuse has configuration this helped catch? We neever before had any such problems. Currently these are caused because some messages have 5 (or more) samsung.com addresses listed on Cc:; for example, [PATCH] The omap3 L2 cache enable/disable function to omap3 dependent code has 6 such addresses on Cc: And what problem does that cause? Such messages need manual moderation which (1) delays the messages and (2) causes additional work to the list moderator (me). But that's a problem caused by the list server's config, not inherently by the # of CCs. I doubt that this is really necessary. Necessary is in the eye of the beholder here. And IMHO the presump- tion should be that the sender of an email is addressing it properly. Absent either (a) clear, significant abuse of emails' recipients or (b) a measurable and significant impact on the list provider [1], let people CC who they consider appropriate and let the list server send emails to whomever it is asked to send emails to. [1] E.g. exceeding bandwidth quotas, mail delivery being delayed for hours, etc. I take this example back; as Scott reminds us the CCs don't affect the list server (except for a few more bytes in the headers of a message it relays). In which case I have even more trouble seeing the harm in re- moving the list server's [apparently arbitrary and unsubstantiated] CC limit. Or at least changing it to a much higher number. Messages get delayed, and they exceed my patience quota ;-) Again, not inherently because of having too many CCs. Raise/remove the limit, and your immediate issue is resolved. What's not to like? Tom -- A: Because it breaks the logical| flow of the message.| Email to user 'CTZ001' | at 'email.mot.com' Q: Why is top posting frowned upon? | ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC/PATCH] jffs2/mtdparts: Fix problem with usage from JFFS2 and MTDPARTS together
On Monday 01 June 2009 10:59:16 Renaud barbier wrote: Renaud, you reported this problem on 05-04-2009 [mtdparts and JFFS2]. Could you please take a look at my patch. Does this work for you? Or what else is missing? This works for me. Great, thanks for checking. Best regards, Stefan = 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] [PATCH v1] arm: Kirkwood: Basic SOCs support
Kirkwood family controllers are highly integrated SOCs
based on Feroceon-88FR131/Sheeva-88SV131/arm926ejs cpu core.
SOC versions supported:-
1) 88F6281-A0 define CONFIG_KW88F6281_A0
2) 88F6192-A0 define CONFIG_KW88F6192_A0
Other supported features:-
1) get_random_hex() fucntion
2) PCI Express port initialization
3) NS16550 driver support
Contributors:
Yotam Admon yo...@marvell.com
Michael Blostein michae...@marvell.com
Reviewed-by: Ronen Shitrit rshit...@marvell.com
Acked-by: Stefan Rose s...@denx.de
Signed-off-by: Prafulla Wadaskar prafu...@marvell.com
---
Change log:
v2: explained cpu winregs programming, defined macros too.
cpu/arm926ejs/kirkwood/Makefile | 49 +
cpu/arm926ejs/kirkwood/cpu.c | 315 +
cpu/arm926ejs/kirkwood/dram.c | 58 ++
cpu/arm926ejs/kirkwood/mpp.c | 80
cpu/arm926ejs/kirkwood/timer.c| 168 +++
drivers/serial/serial.c |3 +
include/asm-arm/arch-kirkwood/cpu.h | 159 +++
include/asm-arm/arch-kirkwood/kirkwood.h | 69 +++
include/asm-arm/arch-kirkwood/kw88f6192.h | 37
include/asm-arm/arch-kirkwood/kw88f6281.h | 37
include/asm-arm/arch-kirkwood/mpp.h | 303 +++
11 files changed, 1278 insertions(+), 0 deletions(-)
create mode 100644 cpu/arm926ejs/kirkwood/Makefile
create mode 100644 cpu/arm926ejs/kirkwood/cpu.c
create mode 100644 cpu/arm926ejs/kirkwood/dram.c
create mode 100644 cpu/arm926ejs/kirkwood/mpp.c
create mode 100644 cpu/arm926ejs/kirkwood/timer.c
create mode 100644 include/asm-arm/arch-kirkwood/cpu.h
create mode 100644 include/asm-arm/arch-kirkwood/kirkwood.h
create mode 100644 include/asm-arm/arch-kirkwood/kw88f6192.h
create mode 100644 include/asm-arm/arch-kirkwood/kw88f6281.h
create mode 100644 include/asm-arm/arch-kirkwood/mpp.h
diff --git a/cpu/arm926ejs/kirkwood/Makefile b/cpu/arm926ejs/kirkwood/Makefile
new file mode 100644
index 000..d73e210
--- /dev/null
+++ b/cpu/arm926ejs/kirkwood/Makefile
@@ -0,0 +1,49 @@
+#
+# (C) Copyright 2009
+# Marvell Semiconductor www.marvell.com
+# Written-by: Prafulla Wadaskar prafu...@marvell.com
+#
+# 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., 51 Franklin Street, Fifth Floor, Boston,
+# MA 02110-1301 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(SOC).a
+
+COBJS-y= dram.o
+COBJS-y+= cpu.o
+COBJS-y+= mpp.o
+COBJS-y+= timer.o
+
+SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
+OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS-y))
+
+all: $(obj).depend $(LIB)
+
+$(LIB):$(OBJS)
+ $(AR) $(ARFLAGS) $@ $(OBJS)
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/cpu/arm926ejs/kirkwood/cpu.c b/cpu/arm926ejs/kirkwood/cpu.c
new file mode 100644
index 000..32e95d2
--- /dev/null
+++ b/cpu/arm926ejs/kirkwood/cpu.c
@@ -0,0 +1,315 @@
+/*
+ * (C) Copyright 2009
+ * Marvell Semiconductor www.marvell.com
+ * Written-by: Prafulla Wadaskar prafu...@marvell.com
+ *
+ * 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., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ */
+
+#include common.h
+#include netdev.h
+#include asm/cache.h
+#include u-boot/md5.h
+#include asm/arch/kirkwood.h
+
+#define BUFLEN 16
+
+void reset_cpu(unsigned long ignored)
+{
+ struct kwcpu_registers *cpureg =
Re: [U-Boot] [PATCH v1] arm: Kirkwood: Basic SOCs support
Hi Jean I have added macros and put some comments in kw_config_adr_windows() for better readability Also I have given references from datasheet too. This was the only feedback from the last patch. I Hope this patch is clean to apply So please kindly review and apply the same Regards.. Prafulla . . -Original Message- From: Prafulla Wadaskar [mailto:prafu...@marvell.com] Sent: Tuesday, June 02, 2009 3:17 PM To: u-boot@lists.denx.de Cc: Nicolas Pitre; Manas Saksena; Lennert Buijtenhek; Prabhanjan Sarnaik; Ronen Shitrit; Ashish Karkare; Prafulla Wadaskar Subject: [PATCH v1] arm: Kirkwood: Basic SOCs support Kirkwood family controllers are highly integrated SOCs based on Feroceon-88FR131/Sheeva-88SV131/arm926ejs cpu core. SOC versions supported:- 1) 88F6281-A0 define CONFIG_KW88F6281_A0 2) 88F6192-A0 define CONFIG_KW88F6192_A0 Other supported features:- 1) get_random_hex() fucntion 2) PCI Express port initialization 3) NS16550 driver support Contributors: Yotam Admon yo...@marvell.com Michael Blostein michae...@marvell.com Reviewed-by: Ronen Shitrit rshit...@marvell.com Acked-by: Stefan Rose s...@denx.de Signed-off-by: Prafulla Wadaskar prafu...@marvell.com --- Change log: v2: explained cpu winregs programming, defined macros too. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] UBIFS will not build for Davinci (2006.06-rc2)
On Monday 01 June 2009 20:58:39 kevin_sprin...@telus.net wrote: I am trying to add UBIFS support to the davinci_dvevm board (ARCH=arm, CPU=arm926ejs, BOARD=dvevm, VENDOR=davinci, SOC=davinci) configuration. However, I encountered a number of issues that lead me to belive that UBIFS support is limited to PowerPC architectures. Has UBIFS support been built and tested on any platform other than PowerPC? Yes. I don't know of any other tests. Porting to other platforms should be not that hard though. I stated this in my original commit text of the lzo compressor support: git-id: b1b4e89a0f3b75854c39a62cae41bad56d210adf Add LZO decompressor support This patch adds LZO decompression support to U-Boot. It is needed for the upcoming UBIFS support, since UBIFS uses LZO as default compressor/ decompressor. Since we only support read-only in UBIFS, only the decompressor is needed. All this is copied with minor changes from the current Linux kernel version (2.6.28-rc8). This patch only implements this LZO decompressor support for PPC. Other platforms using UBIFS will have to add the required include/asm/unaligned.h as well. It should be fairly easy to copy this from the Linux source tree as I have done it for PPC in this patch. Signed-off-by: Stefan Roese s...@denx.de So I suggest that take a look at the commit ID mentioned above and try to move the ARM related files for supporting lzo from Linux to U-Boot as well. The patch I used to enable UBIFS support on the DVEVM board is: --- /home/tester/uboot/u-boot-2009.06-rc2.orig/include/configs/davinci_dvevm.h 2009-05-15 14:29:23.0 -0700 +++ /home/tester/uboot/u-boot-2009.06-rc2/include/configs/davinci_dvevm.h 2009-06-01 11:15:59.0 -0700 @@ -51,7 +51,7 @@ /*===*/ #define DV_EVM #define CONFIG_SYS_NAND_SMALLPAGE -#define CONFIG_SYS_USE_NOR +#define CONFIG_SYS_USE_NAND /*===*/ /* SoC Configuration */ /*===*/ @@ -129,6 +129,14 @@ #define CONFIG_SYS_MAX_NAND_DEVICE1/* Max number of NAND devices */ #define CONFIG_ENV_OFFSET0x0/* Block 0--not used by bootcode */ #define DEF_BOOTM +#define CONFIG_MTD_PARTITIONS +#define CONFIG_CMD_MTDPARTS +#define CONFIG_CMD_UBI +#define CONFIG_CMD_UBIFS +#define CONFIG_SYS_64BIT_VSPRINTF +#define CONFIG_RBTREE +#define CONFIG_LZO #elif defined(CONFIG_SYS_USE_NOR) #ifdef CONFIG_NOR_UART_BOOT #define CONFIG_SKIP_LOWLEVEL_INIT/* U-Boot is loaded by a bootloader */ The first problem I encountered was a compiler error: In file included from ubifs.c:27: ubifs.h:468: error: conflicting types for '__set_bit' /home/tester/uboot/u-boot-2009.06-rc2/include/asm/bitops.h:29: error: previous definition of '__set_bit' was here ubifs.h:476: error: conflicting types for '__clear_bit' /home/tester/uboot/u-boot-2009.06-rc2/include/asm/bitops.h:36: error: previous definition of '__clear_bit' was here make[2]: *** [ubifs.o] Error 1 The error seems to occur becase fs/ubifs/ubifs.h defines two inline functions, __set_bit() and __clear_bit(). For some architectures, including ARM, these functions are already defined in bitops.h AND the prototypes are different from the ones in ubifs.h: __set_bit() __clear_bit(): include/asm-arm/bitops.h include/asm-microblaze/bitops.h __set_bit() only: include/asm-blackfin/bitops.h include/asm-i386/bitops.h include/asm-mips/bitops.h For a quick fix (and probably not the recommended one), I renamed all the __set_bit() and __clear_bit() symbols in fs/ubifs to be __ubi_set_bit() and __ubi_clear_bit(). I don't like this approach as it changes the UBIFS C files instead of one of the headers used as porting layer from Linux to U-Boot. We shouldn't change the C files to make it easier to sync UBIFS with later Linux versions. Perhaps this __set_bit()(__clear_bit() U-Boot implementation needs to be consolidated throughout all platforms. The second problem was a compiler error in lzo1x_decompress.c: lzo1x_decompress.c:17:27: error: asm/unaligned.h: No such file or directory lzo1x_decompress.c: In function 'lzo1x_decompress_safe': lzo1x_decompress.c:72: warning: implicit declaration of function 'put_unaligned' lzo1x_decompress.c:72: warning: implicit declaration of function 'get_unaligned' lzo1x_decompress.c:140: warning: implicit declaration of function 'get_unaligned_le16' make[2]: *** [lzo1x_decompress.o] Error 1 File unaligned.h is ONLY present in include/asm-ppc. See statement above. So I undefined CONFIG_LZO and now I get linker errors: fs/ubifs/libubifs.a(super.o): In function `init_constants_early': /home/tester/uboot/u-boot-2009.06-rc2/fs/ubifs/super.c:317: undefined reference to `fls' fs/ubifs/libubifs.a(lpt.o): In function `dirty_cow_nnode': /home/tester/uboot/u-boot-2009.06-rc2/fs/ubifs/lpt.c:893: undefined reference to `test_and_set_bit'
[U-Boot] [PATCH v2 2/5] spi: Add Marvell Kirkwood SPI driver
This patch adds a SPI driver for the Marvell Kirkwood SoC's.
Signed-off-by: Prafulla Wadaskar prafu...@marvell.com
---
Change log:
v2: White space in debug print removed
drivers/spi/Makefile|1 +
drivers/spi/kirkwood_spi.c | 185 +++
include/asm-arm/arch-kirkwood/spi.h | 56 +++
3 files changed, 242 insertions(+), 0 deletions(-)
create mode 100644 drivers/spi/kirkwood_spi.c
create mode 100644 include/asm-arm/arch-kirkwood/spi.h
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 1350f3e..7ffa47d 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -28,6 +28,7 @@ LIB := $(obj)libspi.a
COBJS-$(CONFIG_ATMEL_DATAFLASH_SPI) += atmel_dataflash_spi.o
COBJS-$(CONFIG_ATMEL_SPI) += atmel_spi.o
COBJS-$(CONFIG_BFIN_SPI) += bfin_spi.o
+COBJS-$(CONFIG_KIRKWOOD_SPI) += kirkwood_spi.o
COBJS-$(CONFIG_MPC8XXX_SPI) += mpc8xxx_spi.o
COBJS-$(CONFIG_MXC_SPI) += mxc_spi.o
COBJS-$(CONFIG_SOFT_SPI) += soft_spi.o
diff --git a/drivers/spi/kirkwood_spi.c b/drivers/spi/kirkwood_spi.c
new file mode 100644
index 000..a1c3070
--- /dev/null
+++ b/drivers/spi/kirkwood_spi.c
@@ -0,0 +1,185 @@
+/*
+ * (C) Copyright 2009
+ * Marvell Semiconductor www.marvell.com
+ * Written-by: Prafulla Wadaskar prafu...@marvell.com
+ *
+ * Derived from drivers/spi/mpc8xxx_spi.c
+ *
+ * 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., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ */
+
+#include common.h
+#include malloc.h
+#include spi.h
+#include asm/arch/kirkwood.h
+#include asm/arch/spi.h
+#include asm/arch/mpp.h
+
+static struct kwspi_registers *spireg = (struct kwspi_registers *)KW_SPI_BASE;
+
+struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs,
+ unsigned int max_hz, unsigned int mode)
+{
+ struct spi_slave *slave;
+ u32 data;
+ u32 kwspi_mpp_config[] = {
+ MPP0_GPIO,
+ MPP7_SPI_SCn,
+ 0
+ };
+
+ if (!spi_cs_is_valid(bus, cs))
+ return NULL;
+
+ slave = malloc(sizeof(struct spi_slave));
+ if (!slave)
+ return NULL;
+
+ slave-bus = bus;
+ slave-cs = cs;
+
+ writel(~KWSPI_CSN_ACT | KWSPI_SMEMRDY, spireg-ctrl);
+
+ /* calculate spi clock prescaller using max_hz */
+ data = ((CONFIG_SYS_TCLK / 2) / max_hz) KWSPI_CLKPRESCL_MASK;
+ data |= 0x10;
+
+ /* program spi clock prescaller using max_hz */
+ writel(KWSPI_ADRLEN_3BYTE | data, spireg-cfg);
+ debug(data = 0x%08x\n, data);
+
+ writel(KWSPI_SMEMRDIRQ, spireg-irq_cause);
+ writel(KWSPI_IRQMASK, spireg-irq_mask);
+
+ /* program mpp registers to select SPI_CSn */
+ if (cs) {
+ kwspi_mpp_config[0] = MPP0_GPIO;
+ kwspi_mpp_config[1] = MPP7_SPI_SCn;
+ } else {
+ kwspi_mpp_config[0] = MPP0_SPI_SCn;
+ kwspi_mpp_config[1] = MPP7_GPO;
+ }
+ kirkwood_mpp_conf(kwspi_mpp_config);
+
+ return slave;
+}
+
+void spi_free_slave(struct spi_slave *slave)
+{
+ free(slave);
+}
+
+int spi_claim_bus(struct spi_slave *slave)
+{
+ return 0;
+}
+
+void spi_release_bus(struct spi_slave *slave)
+{
+}
+
+#ifndef CONFIG_SPI_CS_IS_VALID
+/*
+ * you can define this function board specific
+ * define above CONFIG in board specific config file and
+ * provide the function in board specific src file
+ */
+int spi_cs_is_valid(unsigned int bus, unsigned int cs)
+{
+ return (bus == 0 (cs == 0 || cs == 1));
+}
+#endif
+
+void spi_cs_activate(struct spi_slave *slave)
+{
+ writel(readl(spireg-ctrl) | KWSPI_IRQUNMASK, spireg-ctrl);
+}
+
+void spi_cs_deactivate(struct spi_slave *slave)
+{
+ writel(readl(spireg-ctrl) KWSPI_IRQMASK, spireg-ctrl);
+}
+
+int spi_xfer(struct spi_slave *slave, unsigned int bitlen, const void *dout,
+void *din, unsigned long flags)
+{
+ unsigned int tmpdout, tmpdin;
+ int tm, isread = 0;
+
+ debug(spi_xfer: slave %u:%u dout %08X din %08X bitlen %u\n,
+ slave-bus, slave-cs, dout, din, bitlen);
+
+ if (flags SPI_XFER_BEGIN)
+ spi_cs_activate(slave);
+
+ /*
+* handle data in 8-bit chunks
+
[U-Boot] pci bus scan in u-boot-1.0.2
Hello, I'm tring using pci function of u-boot-1.0.2. But while the programm run into function pci_hose_scan_bus() in /drivers/pci.c, it looks like go to dead and will never run. So, I assert some debug infomation, and then get the problem,maybe it is pci_hose_##rw##_config_##size() function. Because this function will never return this time! Can anybody help me! Thanks a lot, Josh Wei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
