date:20100817

Dear Scott Wood,
 Then assign struct soc *soc = (struct soc *)0;
 
 One snag you might hit is that dereferencing a NULL pointer is undefined,
 and some versions of GCC assume you won't do this when optimizing.  Not sure
 if this simple usage would be affected (it seems to mainly be an issue when
 comparing a pointer to NULL after dereferencing), and
 -fno-delete-null-pointer-checks may help.
Its just an idea anyway...

Certainly the 1st way I proposed is the easiest to go:
#define BLOCK_BASE_ADDR 0xsomething
block_t *block = (block_t *)BLOCK_BASE_ADDR;

 Whats a IOCCC?
 
 The International Obfuscated C Code Contest, possibly a more appropriate
 venue for code that defines a 4GB struct. :-)
In that case I am quite sure the current AT91 way of defining the hardware
addresses to the drivers already qualifies for that ;)
(Try to follow the definition of SPI0_BASE...)

arch-at91/memory_map.h:
...
#ifndef __ASM_ARM_ARCH_MEMORYMAP_H__
#define __ASM_ARM_ARCH_MEMORYMAP_H__

#include asm/arch/hardware.h

#define USART0_BASE AT91_USART0
#define USART1_BASE AT91_USART1
#define USART2_BASE AT91_USART2
#define USART3_BASE (AT91_BASE_SYS + AT91_DBGU)
#define SPI0_BASE   AT91_BASE_SPI
#define SPI1_BASE   AT91_BASE_SPI1

#endif /* __ASM_ARM_ARCH_MEMORYMAP_H__ */
...

arch-at91/harware.h:
...
#if defined(CONFIG_AT91RM9200)
#include asm/arch-at91/at91rm9200.h
#elif defined(CONFIG_AT91SAM9260) || defined(CONFIG_AT91SAM9G20)
#include asm/arch/at91sam9260.h
#define AT91_BASE_SPI   AT91SAM9260_BASE_SPI0
#define AT91_BASE_SPI1  AT91SAM9260_BASE_SPI1
#define AT91_ID_UHP AT91SAM9260_ID_UHP
#define AT91_PMC_UHPAT91SAM926x_PMC_UHP
#define AT91_BASE_MMCI  AT91SAM9260_BASE_MCI
#elif defined(CONFIG_AT91SAM9261) || defined(CONFIG_AT91SAM9G10)
#include asm/arch/at91sam9261.h
#define AT91_BASE_SPI   AT91SAM9261_BASE_SPI0
#define AT91_ID_UHP AT91SAM9261_ID_UHP
#define AT91_PMC_UHPAT91SAM926x_PMC_UHP
#elif defined(CONFIG_AT91SAM9263)
...

arch-at91/at91sam9260.h:
...
#ifdef CONFIG_AT91_LEGACY

/*
  * User Peripheral physical base addresses.
  */
#define AT91SAM9260_BASE_TCB0   0xfffa
#define AT91SAM9260_BASE_TC00xfffa
#define AT91SAM9260_BASE_TC10xfffa0040
#define AT91SAM9260_BASE_TC20xfffa0080
#define AT91SAM9260_BASE_UDP0xfffa4000
#define AT91SAM9260_BASE_MCI0xfffa8000
#define AT91SAM9260_BASE_TWI0xfffac000
#define AT91SAM9260_BASE_US00xfffb
#define AT91SAM9260_BASE_US10xfffb4000
#define AT91SAM9260_BASE_US20xfffb8000
#define AT91SAM9260_BASE_SSC0xfffbc000
#define AT91SAM9260_BASE_ISI0xfffc
#define AT91SAM9260_BASE_EMAC   0xfffc4000
#define AT91SAM9260_BASE_SPI0   0xfffc8000
#define AT91SAM9260_BASE_SPI1   0xfffcc000
#define AT91SAM9260_BASE_US30xfffd
#define AT91SAM9260_BASE_US40xfffd4000
#define AT91SAM9260_BASE_US50xfffd8000
#define AT91SAM9260_BASE_TCB1   0xfffdc000
#define AT91SAM9260_BASE_TC30xfffdc000
#define AT91SAM9260_BASE_TC40xfffdc040
#define AT91SAM9260_BASE_TC50xfffdc080
#define AT91SAM9260_BASE_ADC0xfffe
#define AT91_BASE_SYS   0xe800
...

arch-at91/at91sam9261.h:
...
#ifdef CONFIG_AT91_LEGACY

/*
  * User Peripheral physical base addresses.
  */
#define AT91SAM9261_BASE_TCB0   0xfffa
#define AT91SAM9261_BASE_TC00xfffa
#define AT91SAM9261_BASE_TC10xfffa0040
#define AT91SAM9261_BASE_TC20xfffa0080
#define AT91SAM9261_BASE_UDP0xfffa4000
#define AT91SAM9261_BASE_MCI0xfffa8000
#define AT91SAM9261_BASE_TWI0xfffac000
#define AT91SAM9261_BASE_US00xfffb
#define AT91SAM9261_BASE_US10xfffb4000
#define AT91SAM9261_BASE_US20xfffb8000
#define AT91SAM9261_BASE_SSC0   0xfffbc000
#define AT91SAM9261_BASE_SSC1   0xfffc
#define AT91SAM9261_BASE_SSC2   0xfffc4000
#define AT91SAM9261_BASE_SPI0   0xfffc8000
#define AT91SAM9261_BASE_SPI1   0xfffcc000
#define AT91_BASE_SYS   0xea00
...

isn't that obfuscated enough?

Reinhard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 6/7] powerpc/qe: supports loading QE firmware from nand flash

2010-08-17 Thread Haiying Wang

On Mon, 2010-16-08 at 12:40 +0200, Wolfgang Denk wrote:
 Dear Haiying Wang,
 
 In message 1281947090.24612.23.ca...@localhost.localdomain you wrote:
  and because some platforms need to load QE firmware from NAND flash(no NOR
  flash), it makes qe_init to be called after nand_init.
  
  Signed-off-by: Haiying Wang haiying.w...@freescale.com
  ---
   arch/powerpc/cpu/mpc83xx/cpu_init.c |8 
   arch/powerpc/cpu/mpc85xx/cpu_init.c |8 
   arch/powerpc/lib/board.c|   31 +++
   3 files changed, 31 insertions(+), 16 deletions(-)
 
 Please do not throw such stuff into common code. Use board /
 architecture specific implementations instead (say, provide some
 misc_init_r() or so).
QE is not a misc feature for the SOCs with QE. It actually makes more
sense to enable it in cpu init code. But P1021 doesn't have ROM in QE,
and P1021mds doesn't have NOR flash on board, so I move this cpu feature
to board.c. How about re-spin this patch as:

---
 arch/powerpc/cpu/mpc85xx/cpu_init.c |2 +-
 arch/powerpc/lib/board.c|   15 +++
 2 files changed, 16 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c 
b/arch/powerpc/cpu/mpc85xx/cpu_init.c
index 1fbc0cc..1021575 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu_init.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c
@@ -369,7 +369,7 @@ int cpu_init_r(void)
 
enable_cpc();
 
-#ifdef CONFIG_QE
+#if defined(CONFIG_QE)  !defined(CONFIG_SYS_QE_FW_IN_NAND)
uint qe_base = CONFIG_SYS_IMMR + 0x0008; /* QE immr base */
qe_init(qe_base);
qe_reset();
diff --git a/arch/powerpc/lib/board.c b/arch/powerpc/lib/board.c
index 0e00d86..aae6e23 100644
--- a/arch/powerpc/lib/board.c
+++ b/arch/powerpc/lib/board.c
@@ -783,6 +783,21 @@ void board_init_r (gd_t *id, ulong dest_addr)
nand_init();/* go init the NAND */
 #endif
 
+   /* QE needs to be initialized after nand_init because some boards have
+* to save QE firmware in NAND flash.
+*/
+#if defined(CONFIG_QE)  defined(CONFIG_SYS_QE_FW_IN_NAND)
+#ifdef CONFIG_SYS_QE_FW_IN_NAND
+   /* load QE firmware from NAND flash to DDR first */
+   ret = nand_read(nand_info[0], (loff_t)CONFIG_SYS_QE_FW_IN_NAND,
+   fw_length, (u_char *)CONFIG_SYS_QE_FW_ADDR);
+
+   if (ret  ret == -EUCLEAN) {
+   printf (NAND read for QE firmware at offset %x failed %d\n,
+   (loff_t)CONFIG_SYS_QE_FW_IN_NAND, ret);
+   }
+#endif /* CONFIG_QE  CONFIG_SYS_QE_FW_IN_NAND */
+
/* relocate environment function pointers etc. */
env_relocate ();



___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] net: Change the NFS_TIMEOUT to 20s for using nfs load image.

2010-08-17 Thread Jin Qing-B24347

Dear Wolfgang,

The work flow is that:
Every timeout is reached,  it will call NfsSend() and whatever the state is 
finally it will call rpc_req()  which will increase the rpc_id value every 
time.  The rpc_id value is increased but the reply.id is not increased by 
timeout.  This makes the judgement statement:
If (ntohl(rpc_pkt.u.reply.id) != rpc_id)  is true and it will return -1.  Then 
we got the error message: *** ERROR: Cannot mount.

So far, I am raising the timeout limit to avoid rpc_id being increased 
unexpectedly.

Do you have any suggestion about this issue?


Best Regards,
Jin Qing

-Original Message-
From: Wolfgang Denk [mailto:w...@denx.de] 
Sent: 2010年8月16日 18:46
To: Li Yang-R58472
Cc: u-boot@lists.denx.de; Jin Qing-B24347
Subject: Re: [U-Boot] [PATCH] net: Change the NFS_TIMEOUT to 20s for using nfs 
load image.

Dear Li Yang,

In message aanlkti=o6z1ebm1af94zp5-s6_3vf6ttp2vedhdzw...@mail.gmail.com you 
wrote:

   #define NFS_RETRY_COUNT 30
  -#define NFS_TIMEOUT 2000UL
  +#define NFS_TIMEOUT 2UL
 
  You mean 30 retries (NFS_RETRY_COUNT) every two seconds were not 
  sufficient in your case?
 
  That's a full minute...
 
 It didn't retry 30 times before it fails completely in our test:
 
 Load address: 0x40
 Loading: T T T T T *** ERROR: Cannot mount T T *** ERROR: Cannot 
 umount
 
 Looks like the state machine is not working as expected?

...or something else is causing errors.

I have never seen such behaviour yet.  Please try and debug it. Simply raising 
the timeout limit seems the wrong approach to 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 When 
the bosses talk about improving  productivity,  they  are  never talking about 
themselves.


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [u-Boot] USB EHCI for mpc512x crashes Uboot

2010-08-17 Thread Damien Dusha

Hi Elinar,


 I have a board with mpc5121e cpu on it and I'm been patching my Uboot
 (U-Boot v2009.11) with the patch given initially by Francesco Rendine:


I've cleaned up this patch and made it work better (there are some issues
with it that needed fixing), but needs (mostly style) work before being
submitted as a patch for mainline.

Please email me off-list if you want to test the patch for yourself. If it
works for you, I should make the effort to clean it up and contribute it
back...

  -- Damien
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] pdm360ng: add EDID property to FDT display node

2010-08-17 Thread Anatolij Gustschin

Hello Wolfgang,

On Mon, 16 Aug 2010 16:02:14 +0200
Wolfgang Denk w...@denx.de wrote:
...
 I have one (probably stupid) question:
 
  +static unsigned char edid_buf[128] = {
  +   0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x00,
  +   0x42, 0xC9, 0x34, 0x12, 0x01, 0x00, 0x00, 0x00,
  +   0x0A, 0x0C, 0x01, 0x03, 0x80, 0x98, 0x5B, 0x78,
  +   0xCA, 0x7E, 0x50, 0xA0, 0x58, 0x4E, 0x96, 0x25,
  +   0x1E, 0x50, 0x54, 0x00, 0x00, 0x00, 0x01, 0x01,
  +   0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01,
  +   0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x80, 0x0C,
  +   0x20, 0x00, 0x31, 0xE0, 0x2D, 0x10, 0x2A, 0x80,
  +   0x12, 0x08, 0x30, 0xE4, 0x10, 0x00, 0x00, 0x18,
  +   0x00, 0x00, 0x00, 0xFD, 0x00, 0x38, 0x3C, 0x1F,
  +   0x3C, 0x04, 0x0A, 0x20, 0x20, 0x20, 0x20, 0x20,
  +   0x20, 0x20, 0x00, 0x00, 0x00, 0xFF, 0x00, 0x50,
  +   0x4D, 0x30, 0x37, 0x30, 0x57, 0x4C, 0x33, 0x0A,
  +   0x0A, 0x0A, 0x0A, 0x0A, 0x00, 0x00, 0x00, 0xFF,
  +   0x00, 0x41, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30,
  +   0x30, 0x30, 0x30, 0x30, 0x30, 0x31, 0x00, 0xD4,
  +};
 
 Is there a way to make these magic numbers readbale for a mere human?

The numbers encode some strings (manufacturer, date,
display name, etc.) and display parameter numbers.
I already thought about the way how to easily generate the
structure. Using some macros doesn't make sense, I think.
Better would be to describe the display in a file and
write a tool that generates the edid data structure from
this description.

 How do you generate these?

I generated the block using Phoenix EDID Designer 1.3
(a tool for Windows). This creates a text file like:

EDID BYTES:
0x   00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00 | 00 FF FF FF FF FF FF 00 42 C9 34 12 01 00 00 00
10 | 0A 0C 01 03 80 98 5B 78 CA 7E 50 A0 58 4E 96 25
20 | 1E 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
30 | 01 01 01 01 01 01 80 0C 20 40 31 E0 26 10 18 80
40 | 36 00 30 E4 10 00 00 18 00 00 00 FD 00 38 3C 1F
50 | 3C 04 0A 20 20 20 20 20 20 20 00 00 00 FF 00 50
60 | 4D 30 37 30 57 4C 33 0A 0A 0A 0A 0A 00 00 00 FF
70 | 00 41 30 30 30 30 30 30 30 30 30 30 30 31 00 91

Then I manualy converted the needed bytes to a char array.

Best regards,
Anatolij

--
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: off...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCHv3 CFI flash] Work around bug in Num onyx P33/P30 256-Mbit 65nm flash chips.

2010-08-17 Thread Stefan Roese

Hi Philippe,

the patch doesn't apply:

[ste...@stefan-desktop u-boot-cfi-flash (master)]$ git am -s -3 
patches_misc/\[U-
Boot\]\ \[PATCHv3\ CFI\ flash\]\ Work\ around\ bug\ in\ Numonyx\ P33_P30\ 
256-Mbit\  
65nm\ flash\ chips..mbox
Applying: Work around bug in Numonyx P33/P30 256-Mbit 65nm flash chips.
fatal: sha1 information is lacking or useless (with-numonyx-workaround.log).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.

Not sure what's causing this. Perhaps some lines that should be removed from 
the 
commit log. Please see below:

On Monday 16 August 2010 15:59:05 Philippe De Muyter wrote:
 I have ported U-boot to a in house made board with Numonyx Axcell P33/P30
 256-Mbit 65nm flash chips.
 
 After some time :( searching for bugs in our board or soft, we have
 discovered that those chips have a small but annoying bug, documented in
 Numonyx Axcell P33/P30 256-Mbit Specification Update
 
 It states :
 When customer uses [...] block unlock, the block lock status might be
 altered inadvertently. Lock status might be set to either 01h or 03h
 unexpectedly (00h as expected data), which leads to program/erase failure
 on certain blocks.
 
 A working workaround is given, which I have applied and tested with success
 :
 
 Workaround:  If the interval between 60h and its subsequent command
can be guaranteed within 20μs, Option I is recommended,
otherwise Option II (involves hardware) should be selected.
 Option I: The table below lists the detail command sequences:
 Command
 Data bus   Address bus   Remarks
 Sequence
   1  90hBlock Address
  Read Lock Status
   2 Read Block Address + 02h
  (2)(3)  (1)
 360h   Block Address
  (2)(3)  (1)   Lock/Unlock/RCR
 Configuration 4   D0h/01h/03hBlock Address
 Notes:
 (1) Block Address refers to RCR configuration data only when the 60h
 command sequence is used to set RCR register combined with 03h
 subsequent command.
 (2) For the third and fourth command sequences, the Block Address must
 be the same.
 (3) The interval between 60h command and its subsequent D0h/01h/2Fh/03h
 commands should be less than 20μs.
 
 And here is a log comparison of a simple (destructive) flash test without
 and with the workaround.
 
 diff -U 50 without-numonyx-workaround.log with-numonyx-workaround.log
 --- without-numonyx-workaround.log2010-08-16 15:32:34.0 +0200
 +++ with-numonyx-workaround.log   2010-08-16 15:32:55.0 +0200
 @@ -1,33 +1,33 @@
 -U-Boot 2010.06-00696-g22b002c-dirty (Aug 16 2010 - 15:07:47)
 +U-Boot 2010.06-00696-g22b002c-dirty (Aug 16 2010 - 15:25:19)

These lines might confuse git. I suggest that you remove it and resend the 
resulting 
patch again.

Thanks.

Cheers,
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

Re: [U-Boot] [PATCH 3/7] Add support for SRAM Boot

Dear Haiying Wang,

In message 1282024011.2814.61.ca...@localhost.localdomain you wrote:

Makefile   |   18 ++-
arch/powerpc/cpu/mpc85xx/cpu_init_nand.c   |   31 +++-
arch/powerpc/cpu/mpc85xx/sram_boot/Makefile|  190 
   
arch/powerpc/cpu/mpc85xx/sram_boot/sram_boot.c |   76 
.../cpu/mpc85xx/sram_boot/u-boot-sram-boot.lds |  101 +++
  
  The code for this should not live in some specific 85xx directory, but
  instead be generalized similar to what we have with nand_spl.
 Should we let it structured as $(TOPDIR)/sram_boot/board/freescale?
 At least current, the above code is mostly only used for 85xx. The only
 common part I can tell is the changes in Makefile. 

Not sram_boot, please. The fact that you are using SRAM is specific to
your situation only, but not to the problem.

Assume you want to boot from NAND, and for reliability purposes the
U-Boot image is stored in a UBI partition. The initial NAND bootloader
(1st stage) does not allow to add UBI support, so we will probably
have to make it just load the whole first (guaranteed to be error
free) block into RAM, which then contains full UBI support (but still
not the complete U-Boot image). This 2nd stage loder will then load
the real U-Boot from an UBI partition.

This is a completely different use case, but the basic operation is
the same as in your case.

Please implement your code such that we can re-use it for such other
use cases as well.

   +$(SRAM_BOOT):$(TIMESTAMP_FILE) $(VERSION_FILE) 
   $(obj)include/autoconf.mk
   + $(MAKE) -C $(CPUDIR)/sram_boot all
   +
   +$(U_BOOT_NAND_SRAM): $(NAND_SPL) $(SRAM_BOOT) $(obj)u-boot.bin
   + cat $(obj)nand_spl/u-boot-spl-16k.bin 
   $(obj)$(CPUDIR)/u-boot-sram.bin $(obj)u-boot.bin  $(obj)u-boot-nand.bin
  
  We really need bette rnames here, too.
 Does SRAM_BOOT/sram_boot sound bad? :)

Yes, it does. This has actually nothing to do with SRAM.

  You do not want to duplicate all this stuff here.
  
  This makes no sense.  Also, it is unmaintainable.
 For this case, I need to call some functions like getenv, hwconfig,
 printf, strcmp etc. which are needed in ddr spd code, but I don't want

I think this is a wrong approach. Instead, you should free the DDR
code from such calls.

 to link the libs for those file because if so, the 2nd stage uboot will
 be larger. It might also not be a good idea to copy all those functions
 into some new files which are really duplicate. I agree it is
 unmaintainable here. As Scott pointed, we need to find a better way. Any
 suggestion?

Yes: remove the need for these functions.

   +const char *board_hwconfig = foo:bar=baz;
   +const char *cpu_hwconfig = foo:bar=baz;
  
  This does not exactly look like useful values to me.
 The only use is to make board_hwconfig and cpu_hwconfig from sbss to sdata 
 section.
 
  Please fix!
 The problem here is: 
 The commit 79e4e6480b359cb28129cecfa2cae0ef9cccf803:
  powerpc/8xxx: Enabled hwconfig for memory interleaving
 makes changes as:
 -   if ((p = getenv(memctl_intlv_ctl)) != NULL) {
 +   if (hwconfig_sub(fsl_ddr, ctlr_intlv)) {
 
 Thus the hwconfig is called before ddr initialized, and the system hangs
 at 
  if (board_hwconfig)
 return hwconfig_parse(board_hwconfig, strlen(board_hwconfig),
   opt, ;, ':', arglen);
  in common/hwconfig.c.
 I did not get it yet, but just copied above code from mpc8641hpcn.c to
 make the system boot up. 

It is probably abad concept to depend on such variables that early in
the code, especially when there is SPD information?

In any way, foo:bar=baz does not make any sense.


 Again, if those are not acceptable, do you have any suggestion on how to
 pick the code for the functions I need to use in sram boot?

Change the approach. If you cannot afford the code size for these
funtions, then do not use them.

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 Chairman was as necessary to a Board planet  as  the  zero  was  in
mathematics, but being a zero had big disadvantages...
 - 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 4/7] powerpc/p1021: Add P1021MDS board support

Dear Haiying Wang,

In message 1282025889.2814.80.ca...@localhost.localdomain you wrote:

  Please avoid adding a new header file just for this single prototype.
 This was copied from mpc8568mds/mpc8569mds. If it is not allowed anymore, I 
 can remove it.

Please do.

Ideally provide a cleanup patch for mpc8569mds as well.

  Why do you need a separate one anyway? 
 Because it is p1021mds board specific reset routine.

Yes, what is the problem We have support for board specific code
here, don't we?

  Why cannot you implement this
  in reset_phy() ?
 reset_phy() is a one time reset and called after eth_initialize(). But
 the board designer told me to reset phy for each UEC port before
 initializing it, otherwise the phy can not work properly.

Inded this needs to be reworked. Please wait a few days, there might
be a patch coming.

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
We shall reach greater and greater platitudes of achievement.
- Richard J. Daley
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 6/7] powerpc/qe: supports loading QE firmware from nand flash

Dear Haiying Wang,

In message 1282028890.2814.95.ca...@localhost.localdomain you wrote:

arch/powerpc/cpu/mpc83xx/cpu_init.c |8 
arch/powerpc/cpu/mpc85xx/cpu_init.c |8 
arch/powerpc/lib/board.c|   31 
   +++
3 files changed, 31 insertions(+), 16 deletions(-)
  
  Please do not throw such stuff into common code. Use board /
  architecture specific implementations instead (say, provide some
  misc_init_r() or so).
 QE is not a misc feature for the SOCs with QE. It actually makes more
 sense to enable it in cpu init code. But P1021 doesn't have ROM in QE,
 and P1021mds doesn't have NOR flash on board, so I move this cpu feature
 to board.c. How about re-spin this patch as:

Maybe. But it has no place in arch/powerpc/lib/board.c

  arch/powerpc/cpu/mpc85xx/cpu_init.c |2 +-
  arch/powerpc/lib/board.c|   15 +++
  2 files changed, 16 insertions(+), 1 deletions(-)

NAK for the same reason - I don't want to see this in common code like
arch/powerpc/lib/board.c

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
You know, after a woman's raised a family and so on,  she  wants  to
start living her own life.   Whose life she's _been_ living, then?
  - Terry Pratchett, _Witches Abroad_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] net: Change the NFS_TIMEOUT to 20s for using nfs load image.

Dear Jin Qing-B24347,

In message 
f37f9b48e0e59d42a5f9491a3cad99ad7e8...@zch01exm28.fsl.freescale.net you wrote:
 
 The work flow is that:
 Every timeout is reached,  it will call NfsSend() and whatever the
 state is finally it will call rpc_req()  which will increase the rpc_id
 value every time.  The rpc_id value is increased but the reply.id is not
 increased by timeout.  This makes the judgement statement:
 If (ntohl(rpc_pkt.u.reply.id) != rpc_id)  is true and it will return
 -1.  Then we got the error message: *** ERROR: Cannot mount.
 
 So far, I am raising the timeout limit to avoid rpc_id being increased
 unexpectedly.

What sort of NFS server is this?

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
Have you lived in this village all your life?No, not yet.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [u-Boot] USB EHCI for mpc512x crashes Uboot

Dear Damien Dusha,

In message aanlktim0vhbh_a_v2znhwxx7-tf3e9man56lrecas...@mail.gmail.com you 
wrote:

 Please email me off-list if you want to test the patch for yourself. If it
 works for you, I should make the effort to clean it up and contribute it
 back...

Please do this in any case. I would really like to add this feature.

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 the code and  the  comments  disagree,  then  both  are  probably
wrong.- Norm Schryer
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] net: Change the NFS_TIMEOUT to 20s for using nfs load image.

2010-08-17 Thread Jin Qing-B24347

Dear Wolfgang 

 
 The work flow is that:
 Every timeout is reached,  it will call NfsSend() and whatever the 
 state is finally it will call rpc_req()  which will increase the 
 rpc_id value every time.  The rpc_id value is increased but the 
 reply.id is not increased by timeout.  This makes the judgement
statement:
 If (ntohl(rpc_pkt.u.reply.id) != rpc_id)  is true and it will return 
 -1.  Then we got the error message: *** ERROR: Cannot mount.
 
 So far, I am raising the timeout limit to avoid rpc_id being
increased 
 unexpectedly.

What sort of NFS server is this?

It is a Debian NFS server.

Best regards,
Jin Qing


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [u-Boot] USB EHCI for mpc512x crashes Uboot

2010-08-17 Thread Einar Már Björgvinsson

Hi Damien

I'm very interested in testing this. 
Please send it to me  to the address provided.

Regards
Einar


From: u-boot-boun...@lists.denx.de [u-boot-boun...@lists.denx.de] on behalf of 
Wolfgang Denk [...@denx.de]
Sent: Tuesday, August 17, 2010 9:25 AM
To: Damien Dusha
Cc: u-boot@lists.denx.de; Einar Már Björgvinsson
Subject: Re: [U-Boot] [u-Boot] USB EHCI for mpc512x crashes Uboot

Dear Damien Dusha,

In message aanlktim0vhbh_a_v2znhwxx7-tf3e9man56lrecas...@mail.gmail.com you 
wrote:

 Please email me off-list if you want to test the patch for yourself. If it
 works for you, I should make the effort to clean it up and contribute it
 back...

Please do this in any case. I would really like to add this feature.

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 the code and  the  comments  disagree,  then  both  are  probably
wrong.- Norm Schryer
___
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

[U-Boot] [PATCHv4 CFI flash] Work around bug in Numonyx P33/P30 256-Mbit 65nm flash chips.

I have ported U-boot to a in house made board with Numonyx Axcell P33/P30
256-Mbit 65nm flash chips.

After some time :( searching for bugs in our board or soft, we have
discovered that those chips have a small but annoying bug, documented in
Numonyx Axcell P33/P30 256-Mbit Specification Update

It states :
When customer uses [...] block unlock, the block lock status might be
altered inadvertently. Lock status might be set to either 01h or 03h
unexpectedly (00h as expected data), which leads to program/erase failure
on certain blocks.

A working workaround is given, which I have applied and tested with success :

Workaround:  If the interval between 60h and its subsequent command
 can be guaranteed within 20μs, Option I is recommended,
 otherwise Option II (involves hardware) should be selected.
Option I: The table below lists the detail command sequences:
Command
  Data bus   Address bus   Remarks
Sequence
  1  90hBlock Address
   Read Lock Status
  2 Read Block Address + 02h
 (2)(3)  (1)
360h   Block Address
 (2)(3)  (1)   Lock/Unlock/RCR Configuration
4   D0h/01h/03hBlock Address
Notes:
(1) Block Address refers to RCR configuration data only when the 60h
command sequence is used to set RCR register combined with 03h
subsequent command.
(2) For the third and fourth command sequences, the Block Address must
be the same.
(3) The interval between 60h command and its subsequent D0h/01h/2Fh/03h
commands should be less than 20μs.

And here is a log comparison of a simple (destructive) flash test without
and with the workaround.

diff -U 50 without-numonyx-workaround.log with-numonyx-workaround.log
-U-Boot 2010.06-00696-g22b002c-dirty (Aug 16 2010 - 15:07:47)
+U-Boot 2010.06-00696-g22b002c-dirty (Aug 16 2010 - 15:25:19)
 
 CPU:   Freescale MCF5484
CPU CLK 200 MHz BUS CLK 100 MHz
 Board: Macq Electronique ME2060
 I2C:   ready
 DRAM:  64 MiB
 FLASH: 32 MiB
 In:serial
 Out:   serial
 Err:   serial
 Net:   FEC0, FEC1
 - flinfo
 
 Bank # 1: CFI conformant FLASH (16 x 16)  Size: 32 MB in 259 Sectors
   Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x8922
   Erase timeout: 4096 ms, write timeout: 1 ms
   Buffer write timeout: 5 ms, buffer size: 1024 bytes
 
   Sector Start Addresses:
   FE00   RO   FE008000   RO   FE01   RO   FE018000   RO   FE02   RO
   FE04   RO   FE06   RO   FE08   RO   FE0A   RO   FE0C   RO
   ...
   FFF8   RO   FFFA   RO   FFFC   RO   FFFE   RO
 - protect off all
 Un-Protect Flash Bank # 1
 
...
 done
 - erase all
 Erase Flash Bank # 1
 
...
 done
 - cp.b 100 fe00 200
-Copy to Flash... Flash not Erased
+Copy to Flash... done
 -

Signed-off-by: Philippe De Muyter p...@macqel.be

---
diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index 2d09caf..809ff0e 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -1348,15 +1350,32 @@ int flash_real_protect (flash_info_t * info, long 
sector, int prot)
case CFI_CMDSET_INTEL_PROG_REGIONS:
case CFI_CMDSET_INTEL_STANDARD:
case CFI_CMDSET_INTEL_EXTENDED:
-   flash_write_cmd (info, sector, 0,
-FLASH_CMD_CLEAR_STATUS);
-   flash_write_cmd (info, sector, 0, FLASH_CMD_PROTECT);
-   if (prot)
-   flash_write_cmd (info, sector, 0,
-   FLASH_CMD_PROTECT_SET);
-   else
+   /*
+* see errata called
+* Numonyx Axcell P33/P30 Specification Update :)
+*/
+   flash_write_cmd (info, sector, 0, FLASH_CMD_READ_ID);
+   if (!flash_isequal (info, sector, FLASH_OFFSET_PROTECT,
+   prot)) {
+   /*
+* cmd must come before FLASH_CMD_PROTECT + 20us
+* Disable interrupts which might cause a 
timeout here.
+*/
+   int flag = disable_interrupts ();
+

Re: [U-Boot] Debugging why my kernel won't start

2010-08-17 Thread Albert ARIBAUD

Le 16/08/2010 22:15, Rogan Dawes a écrit :
 On 2010/08/16 9:24 AM, Rogan Dawes wrote:
 Hi folks,

 I'm trying to get mainline u-boot working on my DNS323 (Orion5x based).
 Until I am confident in the config, I'm using a chainloaded approach,
 wrapping my featureful u-boot in an image file:

 $ mkimage -A arm -O u-boot -T kernel -C none -a 0x300 -e 0x300
 -n UBoot dns323 -d u-boot.bin uImage.bin

 I am trying to boot the default kernel that is already flashed into the
 device first. The first problem is that the DNS323 uses an incorrect
 mach-type value of 526, while the registered value is 1542. See
 http://wiki.dns323.info/software:kernel). I have modified
 arch/arm/include/asm/mach-types.h to set MACH_TYPE_DNS323 to the
 correct Dlink value, which should match what the default kernel is
 expecting.

 Unfortunately, all I get is:

 DNS323B1   bootm FF82
 ## Booting kernel from Legacy Image at ff82 ...
   Image Name:   Linux-2.6.12.6-arm1
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:1490204 Bytes = 1.4 MiB
   Load Address: 8000
   Entry Point:  8000
   Verifying Checksum ... OK
   Loading Kernel Image ...

 and it hangs there.

 That appears to be this code from cmd_bootm:

case IH_COMP_NONE:
if (load == blob_start) {
printf (   XIP %s ... , type_name);
} else {
printf (   Loading %s ... , type_name);
memmove_wd ((void *)load, (void *)image_start,
image_len, CHUNKSZ);
}
*load_end = load + image_len;
puts(OK\n);
break;

 So, the memmove_wd never completes, it seems.

 I added a debug statement at the top of memmove_wd, and got:

 Moving memory from ff820040 to 8000

 Is that because the uImage header is 64 bytes?

 Also, the following suggests that there may be something wrong with the
 addresses that I am using:

 DNS323B1   bootm FF82 FF9A
 ## Booting kernel from Legacy Image at ff82 ...
   Image Name:   Linux-2.6.12.6-arm1
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:1490204 Bytes = 1.4 MiB
   Load Address: 8000
   Entry Point:  8000
   Verifying Checksum ... OK
 ## Loading init Ramdisk from Legacy Image at ff9a ...
   Image Name:   Ramdisk
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:5240600 Bytes = 5 MiB
   Load Address: 0080
   Entry Point:  0080
   Verifying Checksum ... Bad Data CRC
 Ramdisk image is corrupt or invalid
 DNS323B1

 My chainloaded u-boot is configured in an image to load at 0x300,
 and stay there (no relocation), if I have understood these parameters
 correctly:

 -a 0x300 -e 0x300

 Can anyone see what I am doing wrong?

 Many thanks!

 Rogan

 So I changed memmove_wd to use the watchdog style of memmove'ing, in
 small chunks to try to track down where the problem arises. I used 1kB
 chunks, and got:

 Moving 1024 of 611612 bytes from ff8f6840 to 000de800
 Moving 1024 of 610588 bytes from ff8f6c40 to 000dec00
 Moving 1024 of 609564 bytes from ff8f7040 to 000df000

 before it finally hung.

 So, I checked what was at that address:

 DNS323B1  md.b 000df000 400
 000df000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 
 000df010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 
 000df020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 
 000df030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 
 000df040: ff ff ff ff ff ff ff ff ff df ff ff ff ff ff ff
 
 000df050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 
 000df060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 
 000df070: ff ff ff ff bf ff ff ff ff ff ff ff ff f7 ff ff
 
 000df080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 
 000df090: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 
 000df0a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 
 000df0b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 
 000df0c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 
 000df0d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 
 000df0e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 
 000df0f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 
 000df100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 
 000df110: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 
 000df120: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 
 000df130: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 
 000df140: ff ff ff ff ff ff

Re: [U-Boot] [PATCH v2a] AT91: add SD/MMC support

2010-08-17 Thread Schleifer, Alexander

Hello Reinhard,

thanks for your reply.
I checked the register settings and sorted out, that the SDCBUS was initialized 
in 4-bit mode by the bootstrap.

So I added the explicit initialization when port A is used:

#if defined(CONFIG_ATMEL_MCI_PORTB)
mmci_writel(SDCR, (MMCI_BF(SCDSEL, 1)
 | MMCI_BF(SCDBUS, 0)));
#else
mmci_writel(SDCR, (MMCI_BF(SCDSEL, 0)
 | MMCI_BF(SCDBUS, 0)));
#endif

Best regards,
Alex

-Original Message-
From: Reinhard Meyer [mailto:u-b...@emk-elektronik.de] 
Sent: Montag, 16. August 2010 12:16
To: Schleifer, Alexander
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH v2a] AT91: add SD/MMC support

Dear Schleifer, Alexander,
 But I found out, that the AT91Bootstrap initialization impacts

the U-Boot code. If I use the AT91Bootstrap (without mci initialization)

from NAND flash, the mmc init command successfully reads the card.

It fails if I use the AT91Bootstrap with mci initialization.

That's unlikely (it has the same init sequences)...

Do you have at91_mci_hw_init(void) in your at91sam_devices.c and do you 
call that function from your board init?

Can you list me what that bootstrap does initialize differently if mci is 
enabled?

Best Regards,
Reinhard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Debugging why my kernel won't start

On 2010/08/17 12:10 PM, Albert ARIBAUD wrote:
 (quick note to Wolfgang: yes, there is RAM at 0x8000 on these 
 machines. All orion5x based machines have RAM start at 0, and u-boot 
 makes sure SDRAM is set up this way)
 
 Rogan,
 
 You cannot tell from your log output that memmove never completes. It 
 could as well be the kernel not outputting to the console, or failing to 
 start at all even though the move was ok.

Actually, I can tell that the memmove never completes (or if it does, it
alters the code flow in the process):

 So I changed memmove_wd to use the watchdog style of memmove'ing, in
 small chunks to try to track down where the problem arises. I used 1kB
 chunks, and got:

 Moving 1024 of 611612 bytes from ff8f6840 to 000de800
 Moving 1024 of 610588 bytes from ff8f6c40 to 000dec00
 Moving 1024 of 609564 bytes from ff8f7040 to 000df000

 before it finally hung.

I had a debug statement in the loop, printing out the above at each
iteration. Since it never completed the loop, copying/moving the entire
kernel (609564 bytes remaining), I think it is safe to assume that it
never got to the point of trying to boot the kernel.

Additionally, just doing a cp with the above parameters also hangs.

 The first thing you should do is make sure that you pass the right 
 machine-id, but also that you pass ATAGs correctly to the kernel -- it 
 seems that at least some LaCie custom u-boot  implementations use an env 
 variable ('mainlineKernel', IIRC) to differenciate between mainline and 
 LaCie custom kernels. Maybe your HW was designed the same way. Best is 
 you look up the u-boot source code provided by the manufacturer of your 
 machine.
 
 The second thing is to make sure your kernel uses the right console. Are 
 you using netconsole? Maybe the manufacturer's kernel does not have 
 netconsole. Do you use a serial (RS-232) console? Make sure the kernel 
 has command line arguments to use it too.
 
 Amicalement,

I'll check those once I have got the copy working correctly :-)

FWIW, I'm using a serial console, not netconsole. And the bootargs
include the console definition.

Based on what Wolfgang has said, perhaps the address space registers are
set up differently in the vendor u-boot to what the current mainline is
doing. I'll check that next, I think.

I'm just struggling to understand how the last command that I executed
ended up in the memory where I was trying to copy the kernel to. That
suggests that U-boot is actively using that memory for some reason, and
copying the kernel image over the top of it seems like a very good way
to cause u-boot to stop behaving consistently, and hang.

Thanks anyway.

Rogan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Debugging why my kernel won't start

2010-08-17 Thread Albert ARIBAUD

Le 17/08/2010 12:21, Rogan Dawes a écrit :
 On 2010/08/17 12:10 PM, Albert ARIBAUD wrote:
 (quick note to Wolfgang: yes, there is RAM at 0x8000 on these
 machines. All orion5x based machines have RAM start at 0, and u-boot
 makes sure SDRAM is set up this way)

 Rogan,

 You cannot tell from your log output that memmove never completes. It
 could as well be the kernel not outputting to the console, or failing to
 start at all even though the move was ok.

 Actually, I can tell that the memmove never completes (or if it does, it
 alters the code flow in the process):

 So I changed memmove_wd to use the watchdog style of memmove'ing, in
 small chunks to try to track down where the problem arises. I used 1kB
 chunks, and got:

 Moving 1024 of 611612 bytes from ff8f6840 to 000de800
 Moving 1024 of 610588 bytes from ff8f6c40 to 000dec00
 Moving 1024 of 609564 bytes from ff8f7040 to 000df000

 before it finally hung.

 I had a debug statement in the loop, printing out the above at each
 iteration. Since it never completed the loop, copying/moving the entire
 kernel (609564 bytes remaining), I think it is safe to assume that it
 never got to the point of trying to boot the kernel.

Sorry, I'd missed that one.

 Additionally, just doing a cp with the above parameters also hangs.

 Based on what Wolfgang has said, perhaps the address space registers are
 set up differently in the vendor u-boot to what the current mainline is
 doing. I'll check that next, I think.

 I'm just struggling to understand how the last command that I executed
 ended up in the memory where I was trying to copy the kernel to. That
 suggests that U-boot is actively using that memory for some reason, and
 copying the kernel image over the top of it seems like a very good way
 to cause u-boot to stop behaving consistently, and hang.

I do think you're overwriting u-boot with the kernel. What location does 
your u-boot load at? What location is the manufacturer's u-boot supposed 
to be loading at? See their TEXT_BASE in the board config file (or link 
file maybe).

FYI, in my u-boot edminiv2 support code, I had issues with big kernels, 
so I decided to move u-boot's final location as high in RAM as by board 
allows, so that it never will be overwritten by Linux (unless I load a 
63+ MB kernel, that is :) )

 Thanks anyway.

 Rogan

You're welcome.

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2a] AT91: add SD/MMC support

Dear Schleifer, Alexander,
 Hello Reinhard,
 
 thanks for your reply.
 I checked the register settings and sorted out, that the SDCBUS was 
 initialized in 4-bit mode by the bootstrap.
 
 So I added the explicit initialization when port A is used:
 
 #if defined(CONFIG_ATMEL_MCI_PORTB)
 mmci_writel(SDCR, (MMCI_BF(SCDSEL, 1)
  | MMCI_BF(SCDBUS, 0)));
 #else
 mmci_writel(SDCR, (MMCI_BF(SCDSEL, 0)
  | MMCI_BF(SCDBUS, 0)));
 #endif
Arghh, thats why getting the geometry worked, but not a block read.

And you were right, the new driver would have handled that correctly :)

Since currently the new driver is among the newest in my series of
changes here, I'll have to try to rebase to get it to the oldest
position.

Reinhard

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Debugging why my kernel won't start

On 2010/08/17 12:41 PM, Albert ARIBAUD wrote:
 I had a debug statement in the loop, printing out the above at each
 iteration. Since it never completed the loop, copying/moving the entire
 kernel (609564 bytes remaining), I think it is safe to assume that it
 never got to the point of trying to boot the kernel.
 
 Sorry, I'd missed that one.

No problem, there was a lot of data there.

 I do think you're overwriting u-boot with the kernel. What location does 
 your u-boot load at? What location is the manufacturer's u-boot supposed 
 to be loading at? See their TEXT_BASE in the board config file (or link 
 file maybe).

My U-Boot is configured to load at 0x300 (48MB), as far out of the
way as possible. That is, using the mkimage tool, which is how I get my
rebuilt u-boot onto the machine. This is my command line:

$ make clean mrproper dns323_b1_config  make  \
mkimage -A arm -O u-boot -T kernel -C none \
-a 0x300 -e 0x300 -n UBoot dns323 \
-d u-boot.bin uImage.bin

My TEXT_BASE is identical to yours: 0x10

Does that make a difference, if the u-boot image is chain loaded from
another one?

This is what I found in the vendor code:

./board/mv88fxx81/db88f5181/config_tiny.mk:TEXT_BASE = 0x00f1
./board/mv88fxx81/db88f5181/config.mk:TEXT_BASE = 0x00f1
./board/mv88fxx81/db88f5181/config_prpmc.mk:TEXT_BASE = 0x02f1
./board/mv88fxx81/db88f5181/config_def.mk:TEXT_BASE = 0x00f1
./board/mv88fxx81/db88f5181/config_tiny_voip.mk:TEXT_BASE = 0x00f4
./board/mv88fxx81/db88f1181/config.mk:TEXT_BASE = 0x00f0

I'm not sure which config has been used for the version of u-boot on my
board, though.

At any rate, those are all substantially higher than I am currently using.

I'll try with a higher value, and see what happens.

 FYI, in my u-boot edminiv2 support code, I had issues with big kernels, 
 so I decided to move u-boot's final location as high in RAM as by board 
 allows, so that it never will be overwritten by Linux (unless I load a 
 63+ MB kernel, that is :) )

That was my reasoning with the 48MB, too :-)

Rogan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Debugging why my kernel won't start

On 2010/08/17 1:19 PM, Rogan Dawes wrote:
 I'll try with a higher value, and see what happens.
 

So, I tried with TEXT_BASE=f1, and I got a bit further:

DNS323B1 bootm FF82
## Booting kernel from Legacy Image at ff82 ...
   Image Name:   Linux-2.6.12.6-arm1
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:1490204 Bytes = 1.4 MiB
   Load Address: 8000
   Entry Point:  8000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK
Using machid 0x526 from environment

Starting kernel ...

Uncompressing
Linux...
done, booting the kernel.

So, that does appear to have been (at least part of) the problem.

Now to figure out why I'm not getting any further than this. (And why
the vendor ramdisk is giving me CRC errors).

Rogan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] TI: DaVinci DA850 EVM: support passing device speed grade information to kernel

2010-08-17 Thread Detlev Zundel

Hi Nori,

Hi Detlev,

On Fri, Aug 13, 2010 at 16:09:41, Detlev Zundel wrote:
Hi Nori,

A revision for me is attached to certain bugs/problems which we may need
to work around in software. Think about something like we can enable
caching only on rev2 CPUs. For all I know, the ATAG_REVISION tag seems
to capture this aspect.

We will most likely end up using this aspect of ATAG_REVISION as further
revisions of the EVM appear.

The maximum speed of a CPU is orthogonal for
me, i.e. there can still be a fast and a slow rev 1 CPU

Note that we are not taking about CPU being fast or slow at a given point
of time. We are talking about whether the cpu on the board can support a
given rate. It means that the silicon has been characterized (and probably
priced) differently. So you can actually treat it as a different CPU
revision.

Well yes, you _can_ treat that as a revision, but certainly I would
not understand what you mean. A CPU revision for me is connected to the
physical chip mask on the CPU (i.e. what goes into the manufacturing
process) and the maximum allowed operating frequency is a property of an
individual chip possibly only detected by actual measurements (what
comes out of manufacturing). I never heard people talk about
_functionally equivalent_ CPUs with different graded operating
frequencies as different revisions, but YMMV.

It would have been nice if hardware provided a way to detect
this difference between chips, but unfortunately it does not.

Very likely because of what I wrote above - if this is a qualification
_after_ the manufacturing.

In fact, all of these speed graded parts are sold separately with different
datasheets. Please see the 375 and 456 AM1x parts:

http://focus.ti.com/paramsearch/docs/parametricsearch.tsp?family=dspsectionId=2tabId=2641familyId=1877paramCriteria=no

They surely have differnet part numbers and this is perfectly fine.

But let's take a look at your first link. I see two parts here with
different allowed frequencies: AM1806-375 and AM1806-456. _Both_ links
lead to the same page with these datasheets:

This is just a documentation trick to make sure common aspects don't have
to be maintained separately.

So you call labeling the parts with the same revision a documentation
trick? Is that easier than to accept the fact that the maximum speed
rating of a CPU is not a revision?

Yes, but I am still unconvinced ATAG_REVISION is not suitable for this
purpose.

When writing code which should also be maintainable by other people it
is a good idea to consider common expectations also of other people.

Agreed. And I am open to concrete suggestions on how this could be
better done.

Let's take a step back. What information do you want to pass to the
Linux kernel? What does the Linux kernel do with it?

As far as I understand you, it is a maximum frequency, correct? The
absolute limit is given by the labeling of individual parts - but for
whatever reason - maybe the user also wants to influence that. So why
not call it maximum operating frequency?

If you really do have to pass the informatino to the kernel (why does no
other SoC in ARM use such a aconcept yet? How do they handle multiple
frequencies?) and because I'm not too familiar with the ATAGs (flat
device trees are far superior), let's see what the current Linux kernel
declares. [Studying the code] Ah, in arch/avr32/include/asm/setup.h
someone came up with the idea to create a generic ATAG_CLOCK tag. That
does look promising - it scales, i.e. one can specify multiple clocks
(i.e. core, bus, whatever) and it uses long long so it will not overflow
in the near future.

Why not reuse such an existing concept which matches your usage much
better (arch/arm/include/asm/setup.h comments ATAG_REVISION as board
revision)?

+/*
+ * get_board_rev() - setup to pass kernel board revision information
+ * Returns:
+ * bit[0-3]Maximum speed supported by the
DA850/OMAP-L138/AM18x part
+ * 0 - 300 MHz
+ * 1 - 372 MHz
+ * 2 - 408 MHz
+ * 3 - 456 MHz

The description says it returns bit[0-3] which may seem that those
canstants are encoded by a single bit each, whereas the code uses
integer values. Change either the comment or the code.

[0-3] usually indicates the range the range 0 to 3. Do you have
suggestions on how else this might be documented?

As I said, bit[0-3] denotes the 4 bits 0-3, i.e. a range from 0-15.
(In this context the numbers below would actually translate into
individual bits.) Just drop this bit[0-3] and it is clear.

Why would dropping bit[0-3] make anything clear? As I mentioned
above other bits can be used in future to determine other aspects
of board revision. May be I can add that information. Is the following
more clear?

/*
* get_board_rev() - setup to pass kernel board revision information
* Returns:
* bit[0-3]

Re: [U-Boot] [PATCH 2/2] pdm360ng: add EDID property to FDT display node

2010-08-17 Thread Detlev Zundel

Hi Anatolij,

 Hello Wolfgang,

 On Mon, 16 Aug 2010 16:02:14 +0200
 Wolfgang Denk w...@denx.de wrote:
 ...
 I have one (probably stupid) question:
 
  +static unsigned char edid_buf[128] = {
  +  0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x00,
  +  0x42, 0xC9, 0x34, 0x12, 0x01, 0x00, 0x00, 0x00,
  +  0x0A, 0x0C, 0x01, 0x03, 0x80, 0x98, 0x5B, 0x78,
  +  0xCA, 0x7E, 0x50, 0xA0, 0x58, 0x4E, 0x96, 0x25,
  +  0x1E, 0x50, 0x54, 0x00, 0x00, 0x00, 0x01, 0x01,
  +  0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01,
  +  0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x80, 0x0C,
  +  0x20, 0x00, 0x31, 0xE0, 0x2D, 0x10, 0x2A, 0x80,
  +  0x12, 0x08, 0x30, 0xE4, 0x10, 0x00, 0x00, 0x18,
  +  0x00, 0x00, 0x00, 0xFD, 0x00, 0x38, 0x3C, 0x1F,
  +  0x3C, 0x04, 0x0A, 0x20, 0x20, 0x20, 0x20, 0x20,
  +  0x20, 0x20, 0x00, 0x00, 0x00, 0xFF, 0x00, 0x50,
  +  0x4D, 0x30, 0x37, 0x30, 0x57, 0x4C, 0x33, 0x0A,
  +  0x0A, 0x0A, 0x0A, 0x0A, 0x00, 0x00, 0x00, 0xFF,
  +  0x00, 0x41, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30,
  +  0x30, 0x30, 0x30, 0x30, 0x30, 0x31, 0x00, 0xD4,
  +};
 
 Is there a way to make these magic numbers readbale for a mere human?

 The numbers encode some strings (manufacturer, date,
 display name, etc.) and display parameter numbers.
 I already thought about the way how to easily generate the
 structure. Using some macros doesn't make sense, I think.
 Better would be to describe the display in a file and
 write a tool that generates the edid data structure from
 this description.

I don't believe that currently we have a need for such a tool.  When we
can document verbally how to generate the data and if it is used often
enough, then maybe someone comes up with a cleverer solution.

 How do you generate these?

 I generated the block using Phoenix EDID Designer 1.3
 (a tool for Windows). This creates a text file like:

 EDID BYTES:
 0x   00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
 
 00 | 00 FF FF FF FF FF FF 00 42 C9 34 12 01 00 00 00
 10 | 0A 0C 01 03 80 98 5B 78 CA 7E 50 A0 58 4E 96 25
 20 | 1E 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
 30 | 01 01 01 01 01 01 80 0C 20 40 31 E0 26 10 18 80
 40 | 36 00 30 E4 10 00 00 18 00 00 00 FD 00 38 3C 1F
 50 | 3C 04 0A 20 20 20 20 20 20 20 00 00 00 FF 00 50
 60 | 4D 30 37 30 57 4C 33 0A 0A 0A 0A 0A 00 00 00 FF
 70 | 00 41 30 30 30 30 30 30 30 30 30 30 30 31 00 91

 Then I manualy converted the needed bytes to a char array.

Then put this text as a how-to comment next to the data.  This _is_
valuable informatino which we do not want to loose.  Rather then putting
it in a commit message, this will keep the comment intact once people
begin copying the construct around.

Cheers
  Detlev

-- 
... what [Microsoft] Exchange provides is *like* email, but it is *not* email.
Once you start trying to use it for real email, you find it's broken by design
in a large number of ways.  It makes no  sense for [a company] to require that
you use Exchange for Internet email, because that's not what Exchange does.
  -- David Woodhouse 1281348164.12908.47.ca...@localhost
--
DENX Software Engineering GmbH,  MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] TI: DaVinci DA850 EVM: support passing device speed grade information to kernel

2010-08-17 Thread Nori, Sekhar

Hi Detlev,

On Tue, Aug 17, 2010 at 17:42:32, Detlev Zundel wrote:
   Yes, but I am still unconvinced ATAG_REVISION is not suitable for this
   purpose.
 
  When writing code which should also be maintainable by other people it
  is a good idea to consider common expectations also of other people.
 
  Agreed. And I am open to concrete suggestions on how this could be
  better done.

 Let's take a step back.  What information do you want to pass to the
 Linux kernel?  What does the Linux kernel do with it?

From the patch description: The kernel uses this information to determine
the maximum speed reachable using cpufreq

 As far as I understand you, it is a maximum frequency, correct?  The
 absolute limit is given by the labeling of individual parts - but for
 whatever reason - maybe the user also wants to influence that.

The user does not influence this rating. Do you call it influenced by
user because there is an environment variable to set this? The way
the patch is written it can also be specified in the board configuration
header file. The environment variable is just a convenience option. The
expectation is that the user will rebuild U-Boot based on which silicon
he is using so he doesn't have to set the environment variable at all.

So, the user is just configuring the software according to the
hardware. There no user influence on the silicon speed grade.

  So why
 not call it maximum operating frequency?

Yes, that's a correct description. Where do you want to call it such?

 If you really do have to pass the informatino to the kernel (why does no
 other SoC in ARM use such a aconcept yet?  How do they handle multiple
 frequencies?) and because I'm not too familiar with the ATAGs (flat
 device trees are far superior), let's see what the current Linux kernel
 declares.  [Studying the code] Ah, in arch/avr32/include/asm/setup.h
 someone came up with the idea to create a generic ATAG_CLOCK tag.  That
 does look promising - it scales, i.e. one can specify multiple clocks
 (i.e. core, bus, whatever) and it uses long long so it will not overflow
 in the near future.

 Why not reuse such an existing concept which matches your usage much
 better (arch/arm/include/asm/setup.h comments ATAG_REVISION as board
 revision)?

Note again that we are not trying to pass information regarding the
current clock speed here. We are passing information regarding a silicon
characteristic. The DA850 kernel reads the system registers directly to
find out the clock speed. Even in the avr32 platform this ATAG is unused.

From kernel file: arch/avr32/kernel/setup.c:

static int __init parse_tag_clock(struct tag *tag)
{
/*
 * We'll figure out the clocks by peeking at the system
 * manager regs directly.
 */
return 0;
}
__tagtable(ATAG_CLOCK, parse_tag_clock);

Anyway, I can see the talk of speed and board revision has created
some confusion.

What if instead of maxspeed, I named the variable as soctype and had
values like am18x-300, am18x-375, am18x-450 passed to it?

It means the same thing, but will probably create a different perception?

I wanted to avoid taking this route since the same code supports
different SoC part numbers and passing part number specific values
can cause some confusion for users of other parts. That is all.

The question is why should a new ARM ATAG be introduced if an existing
one is good enough for the purpose?

  Using HZ would probably settle the which unit is used question, but
  the code would overflow at ~4.2 GHz and the numbers will be large and
  entry errors have to be expected.  As Hz is too fine for CPU frequencies
  this would lead me to use either kilo or megaherz but I would express it
  in the variable name.
 
  I don't have a very strong inclination on this so I will go with
  your suggestion.

 Did you check if we can learn from other code already present in U-Boot?

 Let's see - in arch/mips/cpu/incaip_clock.c there is an environment
 variable cpuclk which is in MHz. Aha, the 8xx parts also use a
 cpuclk environment variable which is even documented in
 doc/README.MPC866.

Yes, U-Boot online documentation also has a reference to it:
http://www.denx.de/wiki/view/DULG/UBootEnvVariables.


 Ah, now I'm in a tight spot - contrary to my previous writings when I
 belived we did not have a comparably construct - I would now vote to use
 exactly the same name and thus unfortunately not use a _mhz suffix but
 still specify the clock in mhz.

You mean replace maxspeed by cpuclk? As I have noted a number of times
before, we are not passing the cpu clock speed here. That information kernel
directly reads from system registers. No need to pass it from U-Boot. The
example you are giving is not the right comparison.

The cpuclk variable in MPC866 is used to set the current cpu speed and pass that
information to kernel. I had a feeling this confusion is going to arise and
that is why I noted in my patch description:


Note that U-Boot itself does not set

[U-Boot] [PATCH v3] AT91: MCI: add SD/MMC driver using mmc framework

This patch adds SD/MMC support to AT91SAM9260/9XE/9G20
using the generic MMC framework.

Signed-off-by: Reinhard Meyer u-b...@emk-elektronik.de
---
The driver itself is not dependent on any particular AT91 or AVR32
device, but further work in device specific files is
required to enable its use for other AT91 (and AVR32) devices:
at91*_devices.c, hardware.h, at91*.h.
Patches welcome!

 arch/arm/cpu/arm926ejs/at91/at91sam9260_devices.c |   21 ++
 arch/arm/include/asm/arch-at91/at91_common.h  |1 +
 arch/arm/include/asm/arch-at91/clk.h  |5 +
 arch/arm/include/asm/arch-at91/hardware.h |1 +
 doc/README.atmel_mci  |   86 +
 drivers/mmc/Makefile  |5 +-
 drivers/mmc/atmel_mci.h   |   48 +++-
 drivers/mmc/gen_atmel_mci.c   |  353 +
 include/mmc.h |   15 +-
 9 files changed, 530 insertions(+), 5 deletions(-)
 create mode 100644 doc/README.atmel_mci
 create mode 100644 drivers/mmc/gen_atmel_mci.c

diff --git a/arch/arm/cpu/arm926ejs/at91/at91sam9260_devices.c 
b/arch/arm/cpu/arm926ejs/at91/at91sam9260_devices.c
index 77d49ab..2d88481 100644
--- a/arch/arm/cpu/arm926ejs/at91/at91sam9260_devices.c
+++ b/arch/arm/cpu/arm926ejs/at91/at91sam9260_devices.c
@@ -194,3 +194,24 @@ void at91_macb_hw_init(void)
 #endif
 }
 #endif
+
+#if defined(CONFIG_ATMEL_MCI) || defined(CONFIG_GENERIC_ATMEL_MCI)
+void at91_mci_hw_init(void)
+{
+   at91_set_a_periph(AT91_PIO_PORTA, 8, 1);/* MCCK */
+#if defined(CONFIG_ATMEL_MCI_PORTB)
+   at91_set_b_periph(AT91_PIO_PORTA, 1, 1);/* MCCDB */
+   at91_set_b_periph(AT91_PIO_PORTA, 0, 1);/* MCDB0 */
+   at91_set_b_periph(AT91_PIO_PORTA, 5, 1);/* MCDB1 */
+   at91_set_b_periph(AT91_PIO_PORTA, 4, 1);/* MCDB2 */
+   at91_set_b_periph(AT91_PIO_PORTA, 3, 1);/* MCDB3 */
+#else
+   at91_set_a_periph(AT91_PIO_PORTA, 7, 1);/* MCCDA */
+   at91_set_a_periph(AT91_PIO_PORTA, 6, 1);/* MCDA0 */
+   at91_set_a_periph(AT91_PIO_PORTA, 9, 1);/* MCDA1 */
+   at91_set_a_periph(AT91_PIO_PORTA, 10, 1);   /* MCDA2 */
+   at91_set_a_periph(AT91_PIO_PORTA, 11, 1);   /* MCDA3 */
+#endif
+}
+#endif
+
diff --git a/arch/arm/include/asm/arch-at91/at91_common.h 
b/arch/arm/include/asm/arch-at91/at91_common.h
index 01840ee..0067190 100644
--- a/arch/arm/include/asm/arch-at91/at91_common.h
+++ b/arch/arm/include/asm/arch-at91/at91_common.h
@@ -27,6 +27,7 @@
 
 void at91_can_hw_init(void);
 void at91_macb_hw_init(void);
+void at91_mci_hw_init(void);
 void at91_serial_hw_init(void);
 void at91_serial0_hw_init(void);
 void at91_serial1_hw_init(void);
diff --git a/arch/arm/include/asm/arch-at91/clk.h 
b/arch/arm/include/asm/arch-at91/clk.h
index f642dd9..457e6c9 100644
--- a/arch/arm/include/asm/arch-at91/clk.h
+++ b/arch/arm/include/asm/arch-at91/clk.h
@@ -59,5 +59,10 @@ static inline unsigned long get_twi_clk_rate(unsigned int 
dev_id)
return get_mck_clk_rate();
 }
 
+static inline unsigned long get_mci_clk_rate(void)
+{
+   return get_mck_clk_rate();
+}
+
 int at91_clock_init(unsigned long main_clock);
 #endif /* __ASM_ARM_ARCH_CLK_H__ */
diff --git a/arch/arm/include/asm/arch-at91/hardware.h 
b/arch/arm/include/asm/arch-at91/hardware.h
index 4ddb315..9f732a7 100644
--- a/arch/arm/include/asm/arch-at91/hardware.h
+++ b/arch/arm/include/asm/arch-at91/hardware.h
@@ -20,6 +20,7 @@
 #include asm/arch-at91/at91rm9200.h
 #elif defined(CONFIG_AT91SAM9260) || defined(CONFIG_AT91SAM9G20)
 #include asm/arch/at91sam9260.h
+#define AT91_BASE_MCI  AT91SAM9260_BASE_MCI
 #define AT91_BASE_SPI  AT91SAM9260_BASE_SPI0
 #define AT91_ID_UHPAT91SAM9260_ID_UHP
 #define AT91_PMC_UHP   AT91SAM926x_PMC_UHP
diff --git a/doc/README.atmel_mci b/doc/README.atmel_mci
new file mode 100644
index 000..18b1bdf
--- /dev/null
+++ b/doc/README.atmel_mci
@@ -0,0 +1,86 @@
+How to use SD/MMC cards with Atmel SoCs having MCI hardware
+---
+2010-08-16 Reinhard Meyer reinhard.me...@emk-elektronik.de
+
+This is a new approach to use Atmel MCI hardware with the
+general MMC framework. Therefore it benefits from that
+framework's abilities to handle SDHC Cards and the ability
+to write blocks.
+
+- AT91SAM9XE512 (tested, will definitely work with XE128 and XE256)
+- AT91SAM9260 (not tested, but MCI is to AT91SAM9XE)
+- AT91SAM9G20 (not tested, should work)
+
+It should work with all other ATMEL devices that have MCI,
+including AVR32.
+
+The generic driver does NOT assign port pins to the MCI block
+nor does it start the MCI clock. This has to be handled in a
+board/SoC specific manner before the driver is initialized:
+
+example: this is added to at91sam9260_devices.c:
+
+#if defined(CONFIG_ATMEL_MCI) || defined(CONFIG_GENERIC_ATMEL_MCI)
+void at91_mci_hw_init(void)
+{
+

Re: [U-Boot] [PATCH v2] TI: DaVinci DA850 EVM: support passing device speed grade information to kernel

2010-08-17 Thread Detlev Zundel

Hi Sekhar,

 Hi Detlev,

 On Tue, Aug 17, 2010 at 17:42:32, Detlev Zundel wrote:
   Yes, but I am still unconvinced ATAG_REVISION is not suitable for this
   purpose.
 
  When writing code which should also be maintainable by other people it
  is a good idea to consider common expectations also of other people.
 
  Agreed. And I am open to concrete suggestions on how this could be
  better done.

 Let's take a step back.  What information do you want to pass to the
 Linux kernel?  What does the Linux kernel do with it?

From the patch description: The kernel uses this information to determine
 the maximum speed reachable using cpufreq

 As far as I understand you, it is a maximum frequency, correct?  The
 absolute limit is given by the labeling of individual parts - but for
 whatever reason - maybe the user also wants to influence that.

 The user does not influence this rating. 

He does not influence the rating, but maybe he wants to limit the top
frequency the CPU runs with?  I've seen customers do this in order to
save power.

 Do you call it influenced by user because there is an environment
 variable to set this? The way the patch is written it can also be
 specified in the board configuration header file. The environment
 variable is just a convenience option. 

I'm getting lost in your arguments.  First you tell me that only the
user can find out what speed a single individual CPU can run at and now
you tell me that the user is not involved at all.

If the original statement is correct then it is of course a good thing
to have an environment variable as this the preferred way of user
interaction.

 The expectation is that the user will rebuild U-Boot based on which
 silicon he is using so he doesn't have to set the environment variable
 at all.

I consider having different binaries for different maximum operating
frequencies a completely broken conecpt sorry.  In Linux we are striving
to run a single binary on different CPU types and you want to rebuild
U-Boot for a single parameter _not even used by U-Boot_?

 So, the user is just configuring the software according to the
 hardware. There no user influence on the silicon speed grade.

Exactly, the user is configuring this parameter _of his system_.  He may
use the label on the CPU as this parameter or he may even choose to
ignore the labeling - ever heard of overclocking?

 So why not call it maximum operating frequency?

 Yes, that's a correct description. Where do you want to call it such?

In the name of the ATAG.

 If you really do have to pass the informatino to the kernel (why does no
 other SoC in ARM use such a aconcept yet?  How do they handle multiple
 frequencies?) and because I'm not too familiar with the ATAGs (flat
 device trees are far superior), let's see what the current Linux kernel
 declares.  [Studying the code] Ah, in arch/avr32/include/asm/setup.h
 someone came up with the idea to create a generic ATAG_CLOCK tag.  That
 does look promising - it scales, i.e. one can specify multiple clocks
 (i.e. core, bus, whatever) and it uses long long so it will not overflow
 in the near future.

 Why not reuse such an existing concept which matches your usage much
 better (arch/arm/include/asm/setup.h comments ATAG_REVISION as board
 revision)?

 Note again that we are not trying to pass information regarding the
 current clock speed here. We are passing information regarding a silicon
 characteristic.

About a characteristic of the maximum usable clock, yes.  Nobody except
you is talking about a current clock speed.

 The DA850 kernel reads the system registers directly to find out the
 clock speed. Even in the avr32 platform this ATAG is unused.

I'm getting lost.  Now you are talking about a current clock speed, not
a maximum clock speed, right?  Actually I was only pointing out the
ATAG_CLOCK to show that there _are_ ATAGS which are more in line with
what I perceive to be the problem that you try to solve.

From kernel file: arch/avr32/kernel/setup.c:

 static int __init parse_tag_clock(struct tag *tag)
 {
 /*
  * We'll figure out the clocks by peeking at the system
  * manager regs directly.
  */
 return 0;
 }
 __tagtable(ATAG_CLOCK, parse_tag_clock);

 Anyway, I can see the talk of speed and board revision has created
 some confusion.

What board revision are you now talking of?

 What if instead of maxspeed, I named the variable as soctype and had
 values like am18x-300, am18x-375, am18x-450 passed to it?

Well yes, you could do that but do you believe that everybody would
infer that the setting of this variable influences a maximum clock
frequency used by the Linux kernel?  I fail to see why you say yourself
that you are configuring a maximum clock frequency and then go on to
define a variable soctype.

 It means the same thing, but will probably create a different perception?

 I wanted to avoid taking this route since the same code supports
 different SoC part numbers and passing part

Re: [U-Boot] [PATCH 0/2 v5][U-BOOT] Zoom3: Add support for OMAP3630 Zoom3 board.

2010-08-17 Thread Martinez, Aldo

Dear Wolfgang,
 -Original Message-
 From: Martinez, Aldo
 Sent: Friday, July 16, 2010 1:30 AM
 To: u-boot@lists.denx.de
 Cc: Paulraj, Sandeep; w...@denx.de; Martinez, Aldo
 Subject: [PATCH 0/2 v5][U-BOOT] Zoom3: Add support for OMAP3630 Zoom3
 board.

 From: Aldo Brett Cedillo Martinez aldo.cedi...@ti.com

 This patch set gives basic functionality to Omap3630 Zoom3 board. And
 unifies serial_devices for zoom2 and zoom3 since both use the same
 struct.

 Thanks Wolfgang for your comments, the modifications done were:
 - Added entry to MAINTAINERS in proper order.
 - Macro for UART1_RX pin.
 - Left include for status led unconditional.
 - Unindented preprocessor statements.
 - Made CONFIG_SYS_HZ a constant with value 1000.
 - Zoom2 and Zoom3 devices now use the same serial device.

 Aldo Brett Cedillo Martinez (2):
   [U-BOOT] Zoom3: Add support for OMAP3630 Zoom3 board.
   [U-BOOT] Unify serial_device for zoom2 and zoom3.

I wonder what is the status of this patch? 
Sandeep commented me it was dependent on another patch, maybe a serial driver 
patch. The second patch of this series affects include/serial.h, should I make 
any modifications to patch so it can apply?

Thanks and best regards,
Aldo
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Debugging why my kernel won't start

2010-08-17 Thread Albert ARIBAUD

Le 17/08/2010 13:42, Rogan Dawes a écrit :
 On 2010/08/17 1:19 PM, Rogan Dawes wrote:
 I'll try with a higher value, and see what happens.


 So, I tried with TEXT_BASE=f1, and I got a bit further:

 DNS323B1  bootm FF82
 ## Booting kernel from Legacy Image at ff82 ...
 Image Name:   Linux-2.6.12.6-arm1
 Image Type:   ARM Linux Kernel Image (uncompressed)
 Data Size:1490204 Bytes = 1.4 MiB
 Load Address: 8000
 Entry Point:  8000
 Verifying Checksum ... OK
 Loading Kernel Image ... OK
 OK
 Using machid 0x526 from environment

 Starting kernel ...

 Uncompressing
 Linux...
 done, booting the kernel.

 So, that does appear to have been (at least part of) the problem.

Ok, so u-boot is now out of the way of the linux image load area.

 Now to figure out why I'm not getting any further than this. (And why
 the vendor ramdisk is giving me CRC errors).

What is the actual command you use for booting your kernel? IIUC (and if 
I trust the few experiments I did on edminiv2 with ramdisks) you need to 
pass the ramdisk address to the bootm command, e.g. bootm ff82 
ff8x (where x is your ramdisk's location in flash (I'm assuming 
your ramdisk image is in flash as your kernel image is). You did an 
'iminfo' on both images to verify their integrity, didn't you?

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 2/2] pdm360ng: add EDID property to FDT display node

2010-08-17 Thread Anatolij Gustschin

PDM360NG board uses this functionality to pass display
timing info to the Linux Framebuffer driver.

Signed-off-by: Anatolij Gustschin ag...@denx.de
---
v2:
 - added howto comment explaining the generation of
   EDID data block.

 board/pdm360ng/pdm360ng.c |   43 +++
 1 files changed, 43 insertions(+), 0 deletions(-)

diff --git a/board/pdm360ng/pdm360ng.c b/board/pdm360ng/pdm360ng.c
index e3abeb8..d154517 100644
--- a/board/pdm360ng/pdm360ng.c
+++ b/board/pdm360ng/pdm360ng.c
@@ -518,6 +518,46 @@ struct node_info nodes[] = {
 };
 #endif
 
+#if defined(CONFIG_VIDEO)
+/*
+ * EDID block has been generated using Phoenix EDID Designer 1.3.
+ * This tool creates a text file containing:
+ *
+ * EDID BYTES:
+ * 0x   00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
+ * 
+ * 00 | 00 FF FF FF FF FF FF 00 42 C9 34 12 01 00 00 00
+ * 10 | 0A 0C 01 03 80 98 5B 78 CA 7E 50 A0 58 4E 96 25
+ * 20 | 1E 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
+ * 30 | 01 01 01 01 01 01 80 0C 20 00 31 E0 2D 10 2A 80
+ * 40 | 12 08 30 E4 10 00 00 18 00 00 00 FD 00 38 3C 1F
+ * 50 | 3C 04 0A 20 20 20 20 20 20 20 00 00 00 FF 00 50
+ * 60 | 4D 30 37 30 57 4C 33 0A 0A 0A 0A 0A 00 00 00 FF
+ * 70 | 00 41 30 30 30 30 30 30 30 30 30 30 30 31 00 D4
+ *
+ * Then this data has been manually converted to the char
+ * array below.
+ */
+static unsigned char edid_buf[128] = {
+   0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x00,
+   0x42, 0xC9, 0x34, 0x12, 0x01, 0x00, 0x00, 0x00,
+   0x0A, 0x0C, 0x01, 0x03, 0x80, 0x98, 0x5B, 0x78,
+   0xCA, 0x7E, 0x50, 0xA0, 0x58, 0x4E, 0x96, 0x25,
+   0x1E, 0x50, 0x54, 0x00, 0x00, 0x00, 0x01, 0x01,
+   0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01,
+   0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x80, 0x0C,
+   0x20, 0x00, 0x31, 0xE0, 0x2D, 0x10, 0x2A, 0x80,
+   0x12, 0x08, 0x30, 0xE4, 0x10, 0x00, 0x00, 0x18,
+   0x00, 0x00, 0x00, 0xFD, 0x00, 0x38, 0x3C, 0x1F,
+   0x3C, 0x04, 0x0A, 0x20, 0x20, 0x20, 0x20, 0x20,
+   0x20, 0x20, 0x00, 0x00, 0x00, 0xFF, 0x00, 0x50,
+   0x4D, 0x30, 0x37, 0x30, 0x57, 0x4C, 0x33, 0x0A,
+   0x0A, 0x0A, 0x0A, 0x0A, 0x00, 0x00, 0x00, 0xFF,
+   0x00, 0x41, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30,
+   0x30, 0x30, 0x30, 0x30, 0x30, 0x31, 0x00, 0xD4,
+};
+#endif
+
 void ft_board_setup(void *blob, bd_t *bd)
 {
u32 val[8];
@@ -528,6 +568,9 @@ void ft_board_setup(void *blob, bd_t *bd)
 #ifdef CONFIG_FDT_FIXUP_PARTITIONS
fdt_fixup_mtdparts(blob, nodes, ARRAY_SIZE(nodes));
 #endif
+#if defined(CONFIG_VIDEO)
+   fdt_add_edid(blob, fsl,mpc5121-diu, edid_buf);
+#endif
 
/* Fixup NOR FLASH mapping */
val[i++] = 0;   /* chip select number */
-- 
1.7.0.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCHv4 CFI flash] Work around bug in Num onyx P33/P30 256-Mbit 65nm flash chips.

2010-08-17 Thread Stefan Roese

Hi Philippe,

unfortunately your patch base64 encoded. :-(

Even though git seems to be able to handle this, your commit text still has 
some problems. Please see below:

On Tuesday 17 August 2010 11:49:24 Philippe De Muyter wrote:
 I have ported U-boot to a in house made board with Numonyx Axcell P33/P30
 256-Mbit 65nm flash chips.
 
 After some time :( searching for bugs in our board or soft, we have
 discovered that those chips have a small but annoying bug, documented in
 Numonyx Axcell P33/P30 256-Mbit Specification Update
 
 It states :
 When customer uses [...] block unlock, the block lock status might be
 altered inadvertently. Lock status might be set to either 01h or 03h
 unexpectedly (00h as expected data), which leads to program/erase failure
 on certain blocks.
 
 A working workaround is given, which I have applied and tested with success
 :
 
 Workaround:  If the interval between 60h and its subsequent command
can be guaranteed within 20μs, Option I is recommended,
otherwise Option II (involves hardware) should be selected.
 Option I: The table below lists the detail command sequences:
 Command
 Data bus   Address bus   Remarks
 Sequence
   1  90hBlock Address
  Read Lock Status
   2 Read Block Address + 02h
  (2)(3)  (1)
 360h   Block Address
  (2)(3)  (1)   Lock/Unlock/RCR
 Configuration 4   D0h/01h/03hBlock Address
 Notes:
 (1) Block Address refers to RCR configuration data only when the 60h
 command sequence is used to set RCR register combined with 03h
 subsequent command.
 (2) For the third and fourth command sequences, the Block Address must
 be the same.
 (3) The interval between 60h command and its subsequent D0h/01h/2Fh/03h
 commands should be less than 20μs.
 
 And here is a log comparison of a simple (destructive) flash test without
 and with the workaround.
 
 diff -U 50 without-numonyx-workaround.log with-numonyx-workaround.log
 -U-Boot 2010.06-00696-g22b002c-dirty (Aug 16 2010 - 15:07:47)
 +U-Boot 2010.06-00696-g22b002c-dirty (Aug 16 2010 - 15:25:19)

You still have this diff stuff in the commit text. This results in the 
remaining stuff being dropped by git after applying. Please remove those diff 
lines. And please don't send base64 encoded mails. I strongly suggest using 
git send-email.
 
Thanks.

Cheers,
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

Re: [U-Boot] [PATCHv4 CFI flash] Work around bug in Numonyx P33/P30 256-Mbit?65nm flash chips.

On Tue, Aug 17, 2010 at 05:57:00PM +0200, Stefan Roese wrote:
 Hi Philippe,
 
 unfortunately your patch base64 encoded. :-(

Are you sure ?  It isn't so in my `sent' folder.

 
 Even though git seems to be able to handle this, your commit text still has 
 some problems. Please see below:
 
 On Tuesday 17 August 2010 11:49:24 Philippe De Muyter wrote:
  I have ported U-boot to a in house made board with Numonyx Axcell P33/P30
  256-Mbit 65nm flash chips.
  
  After some time :( searching for bugs in our board or soft, we have
  discovered that those chips have a small but annoying bug, documented in
  Numonyx Axcell P33/P30 256-Mbit Specification Update
  
  It states :
  When customer uses [...] block unlock, the block lock status might be
  altered inadvertently. Lock status might be set to either 01h or 03h
  unexpectedly (00h as expected data), which leads to program/erase failure
  on certain blocks.
  
  A working workaround is given, which I have applied and tested with success
  :
  
  Workaround:  If the interval between 60h and its subsequent command
   can be guaranteed within 20μs, Option I is recommended,
   otherwise Option II (involves hardware) should be selected.
  Option I: The table below lists the detail command sequences:
  Command
Data bus   Address bus   Remarks
  Sequence
1  90hBlock Address
 Read Lock Status
2 Read Block Address + 02h
   (2)(3)  (1)
  360h   Block Address
   (2)(3)  (1)   Lock/Unlock/RCR
  Configuration 4   D0h/01h/03hBlock Address
  Notes:
  (1) Block Address refers to RCR configuration data only when the 60h
  command sequence is used to set RCR register combined with 03h
  subsequent command.
  (2) For the third and fourth command sequences, the Block Address must
  be the same.
  (3) The interval between 60h command and its subsequent D0h/01h/2Fh/03h
  commands should be less than 20μs.
  
  And here is a log comparison of a simple (destructive) flash test without
  and with the workaround.
  
  diff -U 50 without-numonyx-workaround.log with-numonyx-workaround.log
  -U-Boot 2010.06-00696-g22b002c-dirty (Aug 16 2010 - 15:07:47)
  +U-Boot 2010.06-00696-g22b002c-dirty (Aug 16 2010 - 15:25:19)
 
 You still have this diff stuff in the commit text. This results in the 
 remaining stuff being dropped by git after applying. Please remove those diff 
 lines.

Sorry about that; I had tested with `patch', but of course it does not
need the commit text part :(

 And please don't send base64 encoded mails. I strongly suggest using 
 git send-email.

My experience with `git send-email' is not that good (none of the mails I sent
this way were answered), but I'll try again.

Thanks

Philippe

-- 
Philippe De Muyter  phdm at macqel dot be  Tel +32 27029044
Macq Electronique SA  rue de l'Aeronef 2  B-1140 Bruxelles  Fax +32 27029077
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2] Adds driver for Xilinx' xps_spi SPI controller.

2010-08-17 Thread Graeme Smecher

Hi all,

On 04/08/10 02:04 PM, Graeme Smecher wrote:
 This code differs in only trivial ways from the altera_spi driver. It plays
 nice with Thomas Chou's mmc_spi driver, as well as with SPI flash.

 Documentation for the SPI core is available here:

 http://www.xilinx.com/support/documentation/ip_documentation/xps_spi.pdf

 Signed-off-by: Graeme Smechergraeme.smec...@mail.mcgill.ca
 ---
   drivers/spi/Makefile |1 +
   drivers/spi/xilinx_spi.c |  173 
 ++
   2 files changed, 174 insertions(+), 0 deletions(-)
   create mode 100644 drivers/spi/xilinx_spi.c


Just a friendly reminder -- I'd be really happy to see this, and my 
other patch (July 29, Add support for Winbond W25Q64 SPI flash), 
integrated into the tree. Please let me know if there's anything I can 
do to grease the skids.

cheers,
Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCHv5 CFI flash] Work around bug in Numonyx P33/P30 256-Mbit 65nm flash chips.

I have ported U-boot to a in house made board with Numonyx Axcell P33/P30
256-Mbit 65nm flash chips.

After some time :( searching for bugs in our board or soft, we have
discovered that those chips have a small but annoying bug, documented in
Numonyx Axcell P33/P30 256-Mbit Specification Update

It states :
When customer uses [...] block unlock, the block lock status might be
altered inadvertently. Lock status might be set to either 01h or 03h
unexpectedly (00h as expected data), which leads to program/erase failure
on certain blocks.

A working workaround is given, which I have applied and tested with success :

Workaround:  If the interval between 60h and its subsequent command
 can be guaranteed within 20us, Option I is recommended,
 otherwise Option II (involves hardware) should be selected.
Option I: The table below lists the detail command sequences:
Command
  Data bus   Address bus   Remarks
Sequence
  1  90hBlock Address
   Read Lock Status
  2 Read Block Address + 02h
 (2)(3)  (1)
360h   Block Address
 (2)(3)  (1)   Lock/Unlock/RCR Configuration
4   D0h/01h/03hBlock Address
Notes:
(1) Block Address refers to RCR configuration data only when the 60h
command sequence is used to set RCR register combined with 03h
subsequent command.
(2) For the third and fourth command sequences, the Block Address must
be the same.
(3) The interval between 60h command and its subsequent D0h/01h/2Fh/03h
commands should be less than 20us.

And here is a log comparison of a simple (destructive) flash test without
and with the workaround.

 diff without-numonyx-workaround.log with-numonyx-workaround.log
 -U-Boot 2010.06-00696-g22b002c-dirty (Aug 16 2010 - 15:07:47)
 +U-Boot 2010.06-00696-g22b002c-dirty (Aug 16 2010 - 15:25:19)
  
  CPU:   Freescale MCF5484
 CPU CLK 200 MHz BUS CLK 100 MHz
  Board: Macq Electronique ME2060
  I2C:   ready
  DRAM:  64 MiB
  FLASH: 32 MiB
  In:serial
  Out:   serial
  Err:   serial
  Net:   FEC0, FEC1
  - flinfo
  
  Bank # 1: CFI conformant FLASH (16 x 16)  Size: 32 MB in 259 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x8922
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 5 ms, buffer size: 1024 bytes
  
Sector Start Addresses:
FE00 RO   FE008000 RO   FE01 RO   FE018000 RO   FE02 RO
FE04 RO   FE06 RO   FE08 RO   FE0A RO   FE0C RO
...
FFF8 RO   FFFA RO   FFFC RO   FFFE RO
  - protect off all
  Un-Protect Flash Bank # 1
  ... done
  - erase all
  Erase Flash Bank # 1
  ... done
  - cp.b 100 fe00 200
 -Copy to Flash... Flash not Erased
 +Copy to Flash... done
  -

Signed-off-by: Philippe De Muyter p...@macqel.be

---
diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index 2d09caf..809ff0e 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -1348,15 +1350,32 @@ int flash_real_protect (flash_info_t * info, long 
sector, int prot)
case CFI_CMDSET_INTEL_PROG_REGIONS:
case CFI_CMDSET_INTEL_STANDARD:
case CFI_CMDSET_INTEL_EXTENDED:
-   flash_write_cmd (info, sector, 0,
-FLASH_CMD_CLEAR_STATUS);
-   flash_write_cmd (info, sector, 0, FLASH_CMD_PROTECT);
-   if (prot)
-   flash_write_cmd (info, sector, 0,
-   FLASH_CMD_PROTECT_SET);
-   else
+   /*
+* see errata called
+* Numonyx Axcell P33/P30 Specification Update :)
+*/
+   flash_write_cmd (info, sector, 0, FLASH_CMD_READ_ID);
+   if (!flash_isequal (info, sector, FLASH_OFFSET_PROTECT,
+   prot)) {
+   /*
+* cmd must come before FLASH_CMD_PROTECT + 20us
+* Disable interrupts which might cause a 
timeout here.
+*/
+   int flag = disable_interrupts ();
+   unsigned short cmd;
+
+   if (prot)
+   cmd = FLASH_CMD_PROTECT_SET;
+   else
+   cmd = FLASH_CMD_PROTECT_CLEAR;
+
flash_write_cmd (info, sector, 0,
-   FLASH_CMD_PROTECT_CLEAR);
+ FLASH_CMD_PROTECT);
+

Re: [U-Boot] [PATCHv4 CFI flash] Work around bug in Numonyx P33/P30 256-Mbit?65nm flash chips.

2010-08-17 Thread Stefan Roese

On Tuesday 17 August 2010 18:18:07 Philippe De Muyter wrote:
  unfortunately your patch base64 encoded. :-(
 
 Are you sure ?  It isn't so in my `sent' folder.

Here from the header in my inbox:

Content-Type: text/plain;
   charset=utf-8
Content-Transfer-Encoding: base64

snip
 
   diff -U 50 without-numonyx-workaround.log with-numonyx-workaround.log
   -U-Boot 2010.06-00696-g22b002c-dirty (Aug 16 2010 - 15:07:47)
   +U-Boot 2010.06-00696-g22b002c-dirty (Aug 16 2010 - 15:25:19)
  
  You still have this diff stuff in the commit text. This results in the
  remaining stuff being dropped by git after applying. Please remove those
  diff lines.
 
 Sorry about that; I had tested with `patch', but of course it does not
 need the commit text part :(
 
  And please don't send base64 encoded mails. I strongly suggest using
  git send-email.
 
 My experience with `git send-email' is not that good (none of the mails I
 sent this way were answered), but I'll try again.

Did you find them on the list via a mailing archive?

Thanks.

Cheers,
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

Re: [U-Boot] [PATCHv4 CFI flash] Work around bug in Numonyx P33/P30 256-Mbit?65nm flash chips.

On Tue, Aug 17, 2010 at 06:18:07PM +0200, Philippe De Muyter wrote:
 On Tue, Aug 17, 2010 at 05:57:00PM +0200, Stefan Roese wrote:
  Hi Philippe,
  
  unfortunately your patch base64 encoded. :-(
 
 Are you sure ?  It isn't so in my `sent' folder.
 

Thinking again about it, it must happen somewhere between my computer and
yours, because of the `micro' character (here replaced by 'u') in the
`20us' clause in the commit text.

Philippe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2] Adds driver for Xilinx' xps_spi SPI controller.

2010-08-17 Thread Anatolij Gustschin

Hi,

On Tue, 17 Aug 2010 09:27:10 -0700
Graeme Smecher graeme.smec...@mail.mcgill.ca wrote:

 On 04/08/10 02:04 PM, Graeme Smecher wrote:
  This code differs in only trivial ways from the altera_spi driver. It plays
  nice with Thomas Chou's mmc_spi driver, as well as with SPI flash.
 
  Documentation for the SPI core is available here:
 
  http://www.xilinx.com/support/documentation/ip_documentation/xps_spi.pdf
 
  Signed-off-by: Graeme Smechergraeme.smec...@mail.mcgill.ca
  ---
drivers/spi/Makefile |1 +
drivers/spi/xilinx_spi.c |  173 
  ++
2 files changed, 174 insertions(+), 0 deletions(-)
create mode 100644 drivers/spi/xilinx_spi.c
 
 
 Just a friendly reminder -- I'd be really happy to see this, and my 
 other patch (July 29, Add support for Winbond W25Q64 SPI flash), 
 integrated into the tree. Please let me know if there's anything I can 
 do to grease the skids.

Thanks! But both, this and your other patch have been submitted when
the merge window for next v2010.09 release was closed. So the patches
probably won't be integrated before the next merge window opens,
since these are not bug fixes. Normally you do not have to resubmit
the patches when the next merge window opens again, maybe send a
reminder again. Some info about release cycle can be found here [1].

Best regards,
Anatolij

[1] http://www.denx.de/wiki/U-Boot/ReleaseCycle
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2] Adds driver for Xilinx' xps_spi SPI controller.

2010-08-17 Thread Graeme Smecher

Hi Anatolij,

On 17/08/10 10:25 AM, Anatolij Gustschin wrote:
 Hi,

 On Tue, 17 Aug 2010 09:27:10 -0700
 Graeme Smechergraeme.smec...@mail.mcgill.ca  wrote:


 On 04/08/10 02:04 PM, Graeme Smecher wrote:
  
 This code differs in only trivial ways from the altera_spi driver. It plays
 nice with Thomas Chou's mmc_spi driver, as well as with SPI flash.

 Documentation for the SPI core is available here:

  
 http://www.xilinx.com/support/documentation/ip_documentation/xps_spi.pdf

 Signed-off-by: Graeme Smechergraeme.smec...@mail.mcgill.ca
 ---
drivers/spi/Makefile |1 +
drivers/spi/xilinx_spi.c |  173 
 ++
2 files changed, 174 insertions(+), 0 deletions(-)
create mode 100644 drivers/spi/xilinx_spi.c


 Just a friendly reminder -- I'd be really happy to see this, and my
 other patch (July 29, Add support for Winbond W25Q64 SPI flash),
 integrated into the tree. Please let me know if there's anything I can
 do to grease the skids.
  
 Thanks! But both, this and your other patch have been submitted when
 the merge window for next v2010.09 release was closed. So the patches
 probably won't be integrated before the next merge window opens,
 since these are not bug fixes. Normally you do not have to resubmit
 the patches when the next merge window opens again, maybe send a
 reminder again. Some info about release cycle can be found here [1].

 Best regards,
 Anatolij

 [1] http://www.denx.de/wiki/U-Boot/ReleaseCycle


Ah, of course -- I should have guessed. I'll send along another prod 
next month if it's necessary.

thanks,
Graeme

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/7] Add support for SRAM Boot

2010-08-17 Thread Scott Wood

On Tue, 17 Aug 2010 11:20:00 +0200
Wolfgang Denk w...@denx.de wrote:

 In message 1282024011.2814.61.ca...@localhost.localdomain you wrote:
  For this case, I need to call some functions like getenv, hwconfig,
  printf, strcmp etc. which are needed in ddr spd code, but I don't want
 
 I think this is a wrong approach. Instead, you should free the DDR
 code from such calls.

They're there for a reason, and space isn't so tight that we need to
drop console output and other features at this level.

In this specific case, we probably have room to suck in the full
implementations of printf and the string functions (I believe Haiying
is currently creating a 48K middle stage, while SRAM on this chip is
256K), so I think we could scale back on the intrusiveness of those
changes by letting the middle stage grow a bit...

  Again, if those are not acceptable, do you have any suggestion on how to
  pick the code for the functions I need to use in sram boot?
 
 Change the approach. If you cannot afford the code size for these
 funtions, then do not use them.

...but take this entire subsystem as is or go without anything
vaguely resembling this code, lest it be called 'duplication' is a
rather limiting pair of choices.  It seems reasonable to refactor
things to be more modular (possibly in a nicer way than sprinkling
ifdefs), or provide an alternate trimmed-down implementation.

One thing that should probably be tried first, though, is
-ffunction-sections and --gc-sections, to have the linker discard any
functions that aren't referenced.  It seems some arches/boards already
use this.

-Scott

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] TI: DaVinci DA850 EVM: support passing device speed grade information to kernel

Dear Detlev Zundel,

In message m2hbitgthb@ohwell.denx.de you wrote:
 
  You mean replace maxspeed by cpuclk? As I have noted a number of times
  before, we are not passing the cpu clock speed here. That information kernel
  directly reads from system registers. No need to pass it from U-Boot. The
  example you are giving is not the right comparison.
 
 Ok, then currently I would vote for cpumaxspeed_mhz.

Even though its pretty descriptive - for the sake of consistency I
recommend to omit the _mhz part. Also, I feel that clock would be
more appropriate than speed. And we should consider that we already
use cpuclk for very similar purposes in U-Boot.

Can we agree on cpumaxclk ?


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
Far back in the mists of ancient time, in the great and glorious days
of the former Galactic Empire, life was wild, rich  and  largely  tax
free. - Douglas Adams, _The Hitchhiker's Guide to the Galaxy_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/7] Add support for SRAM Boot

Dear Scott Wood,

In message 20100817131904.5703f...@schlenkerla.am.freescale.net you wrote:
 
 ...but take this entire subsystem as is or go without anything
 vaguely resembling this code, lest it be called 'duplication' is a
 rather limiting pair of choices.  It seems reasonable to refactor
 things to be more modular (possibly in a nicer way than sprinkling
 ifdefs), or provide an alternate trimmed-down implementation.

Agreed. Factoring out functions that can then be selected on Makefile
level is probably OK.

 One thing that should probably be tried first, though, is
 -ffunction-sections and --gc-sections, to have the linker discard any
 functions that aren't referenced.  It seems some arches/boards already
 use this.

I guess that should help here a lot, too.

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 day without sunshine is like night.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Debugging why my kernel won't start

On 2010/08/17 5:38 PM, Albert ARIBAUD wrote:

 Ok, so u-boot is now out of the way of the linux image load area.
 
 Now to figure out why I'm not getting any further than this. (And why
 the vendor ramdisk is giving me CRC errors).
 
 What is the actual command you use for booting your kernel? IIUC (and if 
 I trust the few experiments I did on edminiv2 with ramdisks) you need to 
 pass the ramdisk address to the bootm command, e.g. bootm ff82 
 ff8x (where x is your ramdisk's location in flash (I'm assuming 
 your ramdisk image is in flash as your kernel image is). You did an 
 'iminfo' on both images to verify their integrity, didn't you?
 
 Amicalement,

Well, there are two approaches. The vendor u-boot uses two parameters to
pass the address of the ramdisk to the kernel.

Without that parameter, the kernel should still boot, and show the
initial messages, until it tries to mount its root filesystem, at which
point it should panic.

I'm not passing the second parameter at this stage, because the ramdisk
is failing the CRC32 check for some reason. It may be that the CRC32
calculation has changed between 1.1.1 which was the base for the vendor
u-boot, and mainline. e.g. rather than being calculated over the precise
length of the data, it is calculated over the entire block. Just a
guess, of course.

But until I can get the standard firmware to boot from my replacement
U-boot, I'll keep trying.

The hints I'm getting from googling for u-boot done, booting the
kernel are suggesting that the problem is likely a machid mismatch.

And indeed, that WAS the problem.

I had been led to believe that it was possible to override the compiled
in mach type by setting a machid environment variable. This would give
me the best of both worlds - a u-boot compiled according to mainline
registered numbers, with the ability to boot vendor firmware by simply
setting an environment variable.

Unfortunately, this did not work for me :-(

-#define MACH_TYPE_DNS323   1542
+#define MACH_TYPE_DNS323   526

Making the above change results in a booting kernel, until the root fs
can not be found.

Am I mistaken in expecting the machid environment variable trick to work?

Thanks

Rogan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Debugging why my kernel won't start

On 2010/08/17 9:56 PM, Rogan Dawes wrote:
 
 Am I mistaken in expecting the machid environment variable trick to work?
 
 Thanks
 
 Rogan

No, but mistaken in thinking that the machid was in decimal, when it is
really in hex.

Now to figure out why the CRC calculations are different, and I'll have
a fully functioning u-boot!

Thanks so much to everyone who has helped me get this far!

Rogan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Debugging why my kernel won't start

Dear Rogan Dawes,

In message 4c6ae955.1060...@dawes.za.net you wrote:

 I'm not passing the second parameter at this stage, because the ramdisk
 is failing the CRC32 check for some reason. It may be that the CRC32
 calculation has changed between 1.1.1 which was the base for the vendor
 u-boot, and mainline. e.g. rather than being calculated over the precise
 length of the data, it is calculated over the entire block. Just a
 guess, of course.

That's a wild guess actually, and I bet a beer or two that its a
wrong one.

 I had been led to believe that it was possible to override the compiled
 in mach type by setting a machid environment variable. This would give
 me the best of both worlds - a u-boot compiled according to mainline
 registered numbers, with the ability to boot vendor firmware by simply
 setting an environment variable.
 
 Unfortunately, this did not work for me :-(

This feature was introduced by commit 3c234efa, dated 2008-01-30.
Eventually your U-Bootimage predates this...

 Am I mistaken in expecting the machid environment variable trick to work?

It should work in reasonably recent versions of U-Boot.

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] Debugging why my kernel won't start

Dear Rogan Dawes,

In message 4c6aec70.40...@dawes.za.net you wrote:

 No, but mistaken in thinking that the machid was in decimal, when it is
 really in hex.
 
 Now to figure out why the CRC calculations are different, and I'll have
 a fully functioning u-boot!

For a test you could as ell disable CRC checking:

= setenv verify no
= save

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
It is much easier to suggest solutions when you know nothing
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/2 v5][U-BOOT] Zoom3: Add support for OMAP3630 Zoom3 board.

2010-08-17 Thread Jeff Carr

On Tue, Aug 17, 2010 at 08:34, Martinez, Aldo aldo.cedi...@ti.com wrote:

 I wonder what is the status of this patch?

As someone trying to do development on a 3630, this would be helpful
to have in the upstream tree.

 Sandeep commented me it was dependent on another patch, maybe a serial driver 
 patch. The second patch of this series affects include/serial.h, should I 
 make any

Until this is upstream, is there a way to pull these patches from some
tree or should I just copy all of them out of your email and manually
apply them?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Pull request: nand flash

Dear Scott Wood,

In message 20100816220141.ga2...@schlenkerla.am.freescale.net you wrote:
 The following changes since commit 668a6b45915d10d75357f5b93f569bbf49ea2b06:
   Wolfgang Denk (1):
 Merge branch 'master' of git://git.denx.de/u-boot-usb
 
 are available in the git repository at:
 
   git://git.denx.de/u-boot-nand-flash.git master
 
 Mike Frysinger (1):
   env_nand: return error when no device is found
 
  common/env_nand.c |2 ++
  1 files changed, 2 insertions(+), 0 deletions(-)

Applied, 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
Life. Don't talk to me about life.  - Marvin the Paranoid Android
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Debugging why my kernel won't start

On 2010/08/17 11:20 PM, Wolfgang Denk wrote:
 Dear Rogan Dawes,
 
 In message 4c6aec70.40...@dawes.za.net you wrote:

 No, but mistaken in thinking that the machid was in decimal, when it is
 really in hex.

 Now to figure out why the CRC calculations are different, and I'll have
 a fully functioning u-boot!
 
 For a test you could as ell disable CRC checking:
 
   = setenv verify no
   = save
 
 Best regards,
 
 Wolfgang Denk
 

Hi Wolfgang,

Yes, I found that while I was trying to see if the CRC calculation had
changed, but it did not work.

For some reason, the kernel didn't seem to think it had been given the
ramdisk parameter. At least, I get the following error message:

Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(1,0)

Hmmm! Diff of the boot logs shows (mainline vs vendor):

 initrd (0xff9a0040 - 0xffe9f758) extends beyond physical memory -
disabling initrd
---
 Using UBoot passing parameters structure

Also potentially interesting is:

 Memory: 64MB = 64MB total
 Memory: 61696KB available (2599K code, 462K data, 112K init)
---
 Memory: 64MB 0MB 0MB 0MB = 64MB total
 Memory: 56576KB available (2599K code, 462K data, 112K init)

It seems that the amount of memory is being passed differently to the
kernel (1 bank vs 4)?

Keeping in mind that this is the same kernel executing, just with a
different setup code or parameters.

I'll keep investigating.

Rogan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Debugging why my kernel won't start

Dear Rogan Dawes,

In message 4c6b051a.5050...@dawes.za.net you wrote:

 For some reason, the kernel didn't seem to think it had been given the
 ramdisk parameter. At least, I get the following error message:

Where is the ramdisk located? Make sure it is loaded into RAM (not
flash!).


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
Anyone who knows history, particularly the history of Europe, will, I
think, recognize that the domination of education or of government by
any one particular religious faith is never a happy  arrangement  for
the people.   - Eleanor Roosevelt
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Debugging why my kernel won't start

2010-08-17 Thread Mps Rusya Türki Cumhuriyetler Hızlı Paket Taşıma cılığı A . Ş

On 2010/08/18 12:04 AM, Wolfgang Denk wrote:
 Dear Rogan Dawes,
 
 In message 4c6b051a.5050...@dawes.za.net you wrote:

 For some reason, the kernel didn't seem to think it had been given the
 ramdisk parameter. At least, I get the following error message:
 
 Where is the ramdisk located? Make sure it is loaded into RAM (not
 flash!).
 
 Best regards,
 
 Wolfgang Denk

Hi Wolfgang,

The ramdisk is located at ff9a (in flash). Its image header
relocates it to 0080:

From the vendor u-boot:

## Loading Ramdisk Image at ff9a ...
   Image Name:   Ramdisk
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:5240600 Bytes =  5 MB
   Load Address: 0080
   Entry Point:  0080
   Verifying Checksum ... OK

And from mine:

DNS323B1 setenv verify no
DNS323B1 run bootcmd
## Booting kernel from Legacy Image at ff82 ...
   Image Name:   Linux-2.6.12.6-arm1
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:1490204 Bytes = 1.4 MiB
   Load Address: 8000
   Entry Point:  8000
## Loading init Ramdisk from Legacy Image at ff9a ...
   Image Name:   Ramdisk
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:5240600 Bytes = 5 MiB
   Load Address: 0080
   Entry Point:  0080
   Loading Kernel Image ... OK
OK

0x80 is well within the 64MB that the device has.

Regards,

Rogan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [RFC] CONFIG_RESET_PHY_R feature is broken

2010-08-17 Thread Ilya Yanok

Hello Ben, Everybody,

some boards used to have their PHY quirks in board-specific reset_phy() 
function. This used to work because of reset_phy() being called later 
than Ethernet drivers initialization during startup.
But nowadays some drivers (in particular I faced this problem using 
mpc5xxx_fec driver) use 'on demand' PHY initialization, and 
board-specific quirks don't have effect any more... Actually, 
CONFIG_RESET_PHY_R is broken even without 'on demand' PHY 
initialization: at least mpc5xxx_fec driver can decide to reinit PHY 
during normal operation and board-specific reset_phy() function won't be 
called in this case too... Another design flaw of the CONFIG_RESET_PHY_R 
feature is that boards with more than one Ethernet controller are pretty 
common today and usually we want to initialize only the PHY connected to 
the controller we are trying to use at the moment and there is no way to 
tell the reset_phy() function which PHY we want to reset...

Ben, do you have any ideas how we could fix this?

I believe on of possible solutions here would be to introduce generic 
PHY layer in U-Boot but unfortunately this would be too much efforts for 
us in this project... Maybe somebody is aware of such work being done so 
we can join?

Regards, Ilya.

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/2 v5][U-BOOT] Zoom3: Add support for OMAP3630 Zoom3 board.

2010-08-17 Thread Paulraj, Sandeep


 
 On Tue, Aug 17, 2010 at 08:34, Martinez, Aldo aldo.cedi...@ti.com wrote:
 
  I wonder what is the status of this patch?
 
 As someone trying to do development on a 3630, this would be helpful
 to have in the upstream tree.
 
  Sandeep commented me it was dependent on another patch, maybe a serial
 driver patch. The second patch of this series affects include/serial.h,
 should I make any
 
 Until this is upstream, is there a way to pull these patches from some
 tree or should I just copy all of them out of your email and manually
 apply them?


I am not supposed to be adding this patch below
http://www.mail-archive.com/u-boot@lists.denx.de/msg34906.html

I will need an ACK from the responsible custodian.


Regards,
Sandeep
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/2 v5][U-BOOT] Zoom3: Add support for OMAP3630 Zoom3 board.

2010-08-17 Thread Jeff Carr

On Tue, Aug 17, 2010 at 14:43, Jeff Carr basilarc...@gmail.com wrote:
 On Tue, Aug 17, 2010 at 08:34, Martinez, Aldo aldo.cedi...@ti.com wrote:

 I wonder what is the status of this patch?

I tried this patch today and DRAM seems to not work after u-boot
loads. Strange. I did:

git clone git://git.denx.de/u-boot.git
git pull git://git.denx.de/u-boot-ti.git master
patch  your_patch_from_this_thread.diff
export CROSS_COMPILE=arm-none-linux-gnueabi-
make omap3_zoom3_config
make

Then the output looks like:

U-Boot 2010.06-00691-g30b170e-dirty (Aug 17 2010 - 15:58:42)

OMAP3530-GP ES2.0, CPU-OPP2 L3-165MHz
OMAP3 Zoom3 + LPDDR/NAND
DRAM:  640 MiB
NAND:  512 MiB
In:serial
Out:   serial
Err:   serial
Board revision Production
Die ID #782400011ff0015a5e591101d014
Hit any key to stop autoboot:  0
OMAP3 Zoom3 #bdinfo
arch_number = 0x09A0
env_t   = 0x
boot_params = 0x8100
DRAM bank   = 0x
- start= 0x8000
- size = 0x2000
DRAM bank   = 0x0001
- start= 0xA000
- size = 0x0800
baudrate= 115200 bps
OMAP3 Zoom3 #md 0x80001000
80001000:
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] loading S-record files

2010-08-17 Thread Mangelschots, Jef

We can load binary files by loading them in RAM (offset 0x300) first and 
then copying them to Flash with the cp.b command.

Now we are trying to load our executable (in S-record format) in Flash with the 
loads command (load S-record) using U-boot.

It is my understanding that S-record files specify the exact location of all 
data, so I assume that loads will write the content directly to Flash (without 
the need to load it in RAM first). Is this correct ?

I tried loading an S-record file of which the data is mapped to RAM and that 
seems to work,
But when the S-record file contains records that map a chunk to Flash, it gives 
the following error:

Unknown command 'S325F8045B0042414E434F4E464947555245445F5354CD' - try 'help'
= S325F8045B20415445524154494F4E414C5F5354417E


FYI: 0xf800 is the start of our Flash.
Our U-boot is based on 2008.10 version.


Any files attached to this e-mail will have been checked with virus detection 
software prior to transmission but you should carry out your own virus check 
before opening any attachment. Safetran Systems Corp does not accept liability 
for any damage or loss which may be caused by software viruses. The contents of 
this e-mail and any attachments are the property of Safetran Systems Corp and 
are intended for the confidential use by the named recipient only. They may be 
legally privileged and should not be communicated to, or relied upon, by any 
other person without written consent. If you are not the addressee, please 
notify us immediately at the following address:  Safetran Systems Corporation, 
2400 Nelson Miller Parkway, Louisville, Kentucky 40223. Safetran Systems Corp 
is a subsidiary of  Invensys Plc.  Registered office: Portland House, 
Bressenden Place, London, SW1E 5BF. UK Registered in England and Wales No. 
1641421.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/2 v5][U-BOOT] Zoom3: Add support for OMAP3630 Zoom3 board.

2010-08-17 Thread Martinez, Aldo

Hi Jeff,
 On Tue, Aug 17, 2010 at 08:34, Martinez, Aldo aldo.cedi...@ti.com wrote:
 
  I wonder what is the status of this patch?
 
 As someone trying to do development on a 3630, this would be helpful
 to have in the upstream tree.
I know :)
  Sandeep commented me it was dependent on another patch, maybe a serial
 driver patch. The second patch of this series affects include/serial.h,
 should I make any
 
 Until this is upstream, is there a way to pull these patches from some
 tree or should I just copy all of them out of your email and manually
 apply them?
I think the only option now is taking them from the email :)

Aldo
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/2 v5][U-BOOT] Zoom3: Add support for OMAP3630 Zoom3 board.

2010-08-17 Thread Martinez, Aldo

Hi Jeff,

 -Original Message-
 From: Jeff Carr [mailto:basilarc...@gmail.com]
 Sent: Tuesday, August 17, 2010 6:53 PM
 To: Martinez, Aldo
 Cc: u-boot@lists.denx.de
 Subject: Re: [U-Boot] [PATCH 0/2 v5][U-BOOT] Zoom3: Add support for
 OMAP3630 Zoom3 board.
 
 On Tue, Aug 17, 2010 at 14:43, Jeff Carr basilarc...@gmail.com wrote:
  On Tue, Aug 17, 2010 at 08:34, Martinez, Aldo aldo.cedi...@ti.com
 wrote:
 
  I wonder what is the status of this patch?
 
 I tried this patch today and DRAM seems to not work after u-boot
 loads. Strange. I did:
 
 git clone git://git.denx.de/u-boot.git
 git pull git://git.denx.de/u-boot-ti.git master
 patch  your_patch_from_this_thread.diff
 export CROSS_COMPILE=arm-none-linux-gnueabi-
 make omap3_zoom3_config
 make
 
 Then the output looks like:
 
 U-Boot 2010.06-00691-g30b170e-dirty (Aug 17 2010 - 15:58:42)
 
 OMAP3530-GP ES2.0, CPU-OPP2 L3-165MHz
 OMAP3 Zoom3 + LPDDR/NAND
 DRAM:  640 MiB
 NAND:  512 MiB
 In:serial
 Out:   serial
 Err:   serial
 Board revision Production
 Die ID #782400011ff0015a5e591101d014
 Hit any key to stop autoboot:  0
 OMAP3 Zoom3 #bdinfo
 arch_number = 0x09A0
 env_t   = 0x
 boot_params = 0x8100
 DRAM bank   = 0x
 - start= 0x8000
 - size = 0x2000
 DRAM bank   = 0x0001
 - start= 0xA000
 - size = 0x0800
 baudrate= 115200 bps
 OMAP3 Zoom3 #md 0x80001000
 80001000:
I'll take a look at this, thanks for noting it. 

Best regards,
Aldo Brett
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Dünyanın Heryerine Hızlı ve Ekonomik Hava Kargo Kurye Taşımacılığ ı

MPS Express Dev Kampanya
MPS Gift Hediye Kampanyasından Sizde Yararlanın... 
Dünyanın 220 Ülkesinde Faliyet gösteren MPS Express Türkiyeden Dünyanın 
Heryerine Döküman Paket Koli ve İhracat Kargolarınızı en hızlı en ekonomik ve 
en güvenli şekilde taşıma hizmetini bir yenisini daha ekledi.Türkiyeden Rusya 
ve Ukrayna Ülkelerine göndereceğiniz her türlü kargolarınızı kg gözetmeksizin 
KAPIDAN - KAPIYA İmza karşılığı teslim ederek rakipsiz bir hizmet başlatmıştır.
Rusya  Ukrayna Paket Taşımacılığı 
Varış ülkesinde gümrüğe tabi olsun olmasın numunelerinizi Rusya ve Ukrayna 
Ülkelerinde Rakipleri Gümrüğe bırakırken,MPS Express  Müşterinizin kapısına 
teslim etmeyi taahüt ediyor.
Rusya ve Ukrayna Fuar Taşıma Hizmeti 
MPS Express Fuar Taşıma hizmeti ile katılacağınız fuarlarda 
organizasyonlarınızın başarı ile sonuçlandırmanıza yardımcı olmak için sizi 
sadece satış odaklı kılabilmek ve katılacağınız etkinlik nerede olursa olsun 
MPS Express KALİTE VE DENEYİMİ VE HIZLI. Sizlere tam zamanlı 
organizasyonlarınızın her aşamasında üstlenerek müşterileriniz ile 10.yılında 
buluşturma devam ediyor...
Dünyanın Heryerine Hızlı ve Ekonomik Hava Kargo  Kurye Taşımacılığı 
MPS Express  Yurtdışına göndereceğiniz Tüm Kargolarınızda Dünyanın 220 Ülkesine 
Hızlı  Ekonomik güvenilir bir şekilde taşıma hizmeti sağlamaktadır.Dünya 
Çapında bir çok güçlü kuruluş ile işbirliği yapan MPS Express  Türkiye 
genelinde Müşterilerine sunduğu kaliteli hizmet sayesinde 220 ülke ve özerk 
bölgede konumunu sürdürmektedir.MPS Express çeşitli ülkeler de en yaygın 
kuruluşlar işbirliği yapmayı tercih ederek müşterilerine lokal dağıtımda en 
dağıtım firmaları ile çalışma avantajları sağlamaktadır.
Hava Kargo 
Türkiyeden Dünyanın her yerine ,Dünyanın her yerinden Havalimanı yada kapıdan 
kapıya havayolu taşımacılığı hizmetleri veren MPS Express  Seçkin havayolu 
şirketleri ile Yapılan anlaşmalar sayesinde taşımalarda yer ve fiyat 
avantajları sağlamaktadır.MPS Express  Sektöründe deneyimi ve çalışma anlayışı 
ile havayolu taşımacılığında Türkiyede öncü bir marka haline 
gelmiştir.İhracatta artan dış rekabetin ve uluslararası arenadaki alıcıların 
daha hızlı termin isteklerinin sonucu olarak oluşan kalite hizmet ve ekonomik 
çözümler ile talebini karşılayarak yatırımlarını tamamlamıştır.
Dünyanın Heryerine Hava Kargo Ürün ve HizmetlerimizMüşteri Hizmetleri   
.:+ 90 212 444 0 108 
Havalimanından Havalimanı Taşıma Çözümleri  
 sa...@mpsglobalexpress.com  www.mpsglobalexpress.com   
   
Havalimanından Kapıya Taşıma Çözümleri  
   i...@mpsglobalexpress.com
Tehlikeli Madde Taşıma Çözümleri 
Kapıdan Havalimanına Taşıma Çözümleri 
Kapıdan Kapıya Taşıma Çözümleri 
Gümrüklü  Gümrüksüz Kapı Teslimi 
Yolcu beraberinde Kargo Teslim Çözümleri 
Rusya ve Ukrayna Acil Kargo Çözümleri 


 
 

-
 
 

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/2 v5][U-BOOT] Zoom3: Add support for OMAP3630 Zoom3 board.

2010-08-17 Thread Jeff Carr

On Tue, Aug 17, 2010 at 18:13, Martinez, Aldo aldo.cedi...@ti.com wrote:

 On Tue, Aug 17, 2010 at 14:43, Jeff Carr basilarc...@gmail.com wrote:
 I tried this patch today and DRAM seems to not work after u-boot

 I'll take a look at this, thanks for noting it.

 Best regards,
 Aldo Brett

It dawns on me that I didn't ask what toolchain you are using. I've been using
gcc version 4.3.2 (Sourcery G++ Lite 2008q3-72)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Hallo

2010-08-17 Thread Bella Benju

Hello


Greetings,


I saw your e-mail in the net while  browsing, and i pick interest in you
 as such i


came here to look for my second half, my soul mate,my friend It is to 
tell


about myself to you, as I haven't seen you ever before. But I feel


something inside. I feel like a little sign of hope that I am not doing


this in vain.I feel that you have the friendly soul to mine.What I want 
to


find is Love. please get back to me with the above e-mail. i will detail
 more about myself


to you.and all so send my picture to you if you reply this mail.


regard.


 From  Bella.





Hallo


Hilsener,


Jeg så din e-post i nettet mens du surfer, og jeg plukker interesse for 
deg som sådan i


kom hit for å se etter min andre halvdel, min sjelefrende, min venn Det 
er å fortelle


om meg selv til deg, som jeg ikke har sett deg noen gang tidligere. Men 
jeg føler


noe inni. Jeg føler meg som et lite tegn på håp om at jeg ikke gjør


dette i vain.I føler at du har den vennlige sjelen til mine.What Jeg 
ønsker å


Funnet er Kjærlighet. vennligst komme tilbake til meg med det over 
e-post. jeg vil detaljer mer om meg selv


å you.and alle så sender mitt bilde for deg hvis du svarer denne posten.


hensyn.


 Fra Bella.___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/2 v5][U-BOOT] Zoom3: Add support for OMAP3630 Zoom3 board.

2010-08-17 Thread Steve Sakoman

On Tue, Aug 17, 2010 at 2:43 PM, Jeff Carr basilarc...@gmail.com wrote:
 On Tue, Aug 17, 2010 at 08:34, Martinez, Aldo aldo.cedi...@ti.com wrote:

 I wonder what is the status of this patch?

 As someone trying to do development on a 3630, this would be helpful
 to have in the upstream tree.

I'm preparing a patch series to support 37XX versions of Beagle and
Overo.  It includes enhancements to the existing code in
arch/arm/cpu/armv7/omap3 to detect and configure the 36/37XX series
processors, as well as changes to the board files for Beagle and Overo
to support both old and new versions.  Perhaps those patches might
help you with your 3630 work.

I hope to have them submitted to the list by end of week.

Regards,

Steve
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] powerpc/8xxx: query feature reporting register for num cores on unknown cpus

2010-08-17 Thread Kumar Gala


On Aug 9, 2010, at 6:39 PM, Kim Phillips wrote:

 
 From 093851331069abefe38e93bb04f715e9c63c9dd3 Mon Sep 17 00:00:00 2001
 From: Kim Phillips kim.phill...@freescale.com
 Date: Mon, 9 Aug 2010 18:28:40 -0500
 Subject: [PATCH] powerpc/8xxx: share PIC defines among 85xx and 86xx
 
 fixes breakeage introduced by commit
 a37c36f4e70bada297f281b0e542539ad43e50f6 powerpc/8xxx: query
 feature reporting register for num cores on unknown cpus
 
 Reported-by: Wolfgang Denk w...@denx.de
 Signed-off-by: Kim Phillips kim.phill...@freescale.com
 ---
 arch/powerpc/cpu/mpc85xx/cpu.c|2 +-
 arch/powerpc/cpu/mpc85xx/cpu_init.c   |2 +-
 arch/powerpc/cpu/mpc85xx/interrupts.c |2 +-
 arch/powerpc/cpu/mpc85xx/mp.c |6 +++---
 arch/powerpc/cpu/mpc85xx/traps.c  |2 +-
 arch/powerpc/cpu/mpc8xxx/cpu.c|8 +---
 arch/powerpc/include/asm/immap_85xx.h |4 +---
 arch/powerpc/include/asm/immap_86xx.h |9 ++---
 8 files changed, 19 insertions(+), 16 deletions(-)

applied

- k

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] powerpc/85xx: Rename Security Engine Job Queue to Job Ring to match docs

2010-08-17 Thread Kumar Gala

Official docs call it the Job Ring not Job Queue for the p4080 security
block.  Match the docs to reduce confusion.

Signed-off-by: Kim Phillips kim.phill...@freescale.com
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
 arch/powerpc/cpu/mpc85xx/p4080_ids.c  |8 
 arch/powerpc/include/asm/fsl_liodn.h  |8 
 arch/powerpc/include/asm/immap_85xx.h |6 +++---
 3 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/arch/powerpc/cpu/mpc85xx/p4080_ids.c 
b/arch/powerpc/cpu/mpc85xx/p4080_ids.c
index 3861146..a6cfaa5 100644
--- a/arch/powerpc/cpu/mpc85xx/p4080_ids.c
+++ b/arch/powerpc/cpu/mpc85xx/p4080_ids.c
@@ -81,10 +81,10 @@ struct liodn_id_table fman2_liodn_tbl[] = {
 #endif
 
 struct liodn_id_table sec_liodn_tbl[] = {
-   SET_SEC_JQ_LIODN_ENTRY(0, 146, 154),
-   SET_SEC_JQ_LIODN_ENTRY(1, 147, 155),
-   SET_SEC_JQ_LIODN_ENTRY(2, 178, 186),
-   SET_SEC_JQ_LIODN_ENTRY(3, 179, 187),
+   SET_SEC_JR_LIODN_ENTRY(0, 146, 154),
+   SET_SEC_JR_LIODN_ENTRY(1, 147, 155),
+   SET_SEC_JR_LIODN_ENTRY(2, 178, 186),
+   SET_SEC_JR_LIODN_ENTRY(3, 179, 187),
SET_SEC_RTIC_LIODN_ENTRY(a, 144),
SET_SEC_RTIC_LIODN_ENTRY(b, 145),
SET_SEC_RTIC_LIODN_ENTRY(c, 176),
diff --git a/arch/powerpc/include/asm/fsl_liodn.h 
b/arch/powerpc/include/asm/fsl_liodn.h
index acdc99a..4c17fe2 100644
--- a/arch/powerpc/include/asm/fsl_liodn.h
+++ b/arch/powerpc/include/asm/fsl_liodn.h
@@ -115,11 +115,11 @@ extern void fdt_fixup_liodn(void *blob);
FM_PPID_RX_PORT_OFFSET(fmNum, enetNum + 16), \
CONFIG_SYS_FSL_FM##fmNum##_RX##enetNum##_10G_OFFSET) \
 
-#define SET_SEC_JQ_LIODN_ENTRY(jqNum, liodnA, liodnB) \
-   SET_LIODN_ENTRY_2(fsl,sec4.0-job-queue, liodnA, liodnB,\
-   offsetof(ccsr_sec_t, jqliodnr[jqNum].ls) + \
+#define SET_SEC_JR_LIODN_ENTRY(jrNum, liodnA, liodnB) \
+   SET_LIODN_ENTRY_2(fsl,sec4.0-job-ring, liodnA, liodnB,\
+   offsetof(ccsr_sec_t, jrliodnr[jrNum].ls) + \
CONFIG_SYS_FSL_SEC_OFFSET, \
-   CONFIG_SYS_FSL_SEC_OFFSET + 0x1000 + 0x1000 * jqNum)
+   CONFIG_SYS_FSL_SEC_OFFSET + 0x1000 + 0x1000 * jrNum)
 
 /* This is a bit evil since we treat rtic param as both a string  hex value */
 #define SET_SEC_RTIC_LIODN_ENTRY(rtic, liodnA) \
diff --git a/arch/powerpc/include/asm/immap_85xx.h 
b/arch/powerpc/include/asm/immap_85xx.h
index e5a02c3..3dd2b7f 100644
--- a/arch/powerpc/include/asm/immap_85xx.h
+++ b/arch/powerpc/include/asm/immap_85xx.h
@@ -2063,7 +2063,7 @@ typedef struct ccsr_sec {
struct {
u32 ms; /* Job Ring LIODN Register, MS */
u32 ls; /* Job Ring LIODN Register, LS */
-   } jqliodnr[4];
+   } jrliodnr[4];
u8  res2[0x30];
struct {
u32 ms; /* RTIC LIODN Register, MS */
@@ -2108,8 +2108,8 @@ typedef struct ccsr_sec {
 #define SEC_CTPR_MS_AXI_LIODN  0x0800
 #define SEC_CTPR_MS_QI 0x0200
 #define SEC_RVID_MA0x0f00
-#define SEC_CHANUM_MS_JQNUM_MASK   0xf000
-#define SEC_CHANUM_MS_JQNUM_SHIFT  28
+#define SEC_CHANUM_MS_JRNUM_MASK   0xf000
+#define SEC_CHANUM_MS_JRNUM_SHIFT  28
 #define SEC_CHANUM_MS_DECONUM_MASK 0x0f00
 #define SEC_CHANUM_MS_DECONUM_SHIFT24
 #endif
-- 
1.6.0.6

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] powerpc/8xxx: Fix quad-rank DIMMs support on corenet_ds board.

2010-08-17 Thread Kumar Gala

From: york york...@freescale.com

The board specific parameters associated with quad rank dimms where
missing.  This fixes it so the board will function if quad rank dimms
are placed in it.

Signed-off-by: York Sun york...@freescale.com
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
 board/freescale/corenet_ds/ddr.c |   18 +-
 include/configs/corenet_ds.h |2 +-
 2 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/board/freescale/corenet_ds/ddr.c b/board/freescale/corenet_ds/ddr.c
index 82b2b4f..18adf2f 100644
--- a/board/freescale/corenet_ds/ddr.c
+++ b/board/freescale/corenet_ds/ddr.c
@@ -66,11 +66,19 @@ typedef struct {
  *  seem reliable, but errors will appear when memory intensive
  *  program is run. */
 /* XXX: Single rank at 800 MHz is OK.  */
-const board_specific_parameters_t board_specific_parameters[][20] = {
+const board_specific_parameters_t board_specific_parameters[][30] = {
{
/*  memory controller 0 */
/*lo|  hi|  num|  clk| cpo|wrdata|2T*/
/*   mhz| mhz|ranks|adjst|| delay|  */
+   {  0, 333,4,6,   7,3,  0},
+   {334, 400,4,6,   9,3,  0},
+   {401, 549,4,6,  11,3,  0},
+   {550, 680,4,1,  10,5,  0},
+   {681, 850,4,1,  12,5,  0},
+   {851, 1050,   4,1,  12,5,  0},
+   {1051, 1250,  4,1,  15,4,  0},
+   {1251, 1350,  4,1,  15,4,  0},
{  0, 333,2,6,   7,3,  0},
{334, 400,2,6,   9,3,  0},
{401, 549,2,6,  11,3,  0},
@@ -90,6 +98,14 @@ const board_specific_parameters_t 
board_specific_parameters[][20] = {
/*  memory controller 1 */
/*lo|  hi|  num|  clk| cpo|wrdata|2T*/
/*   mhz| mhz|ranks|adjst|| delay|  */
+   {  0, 333,4,6,   7,3,  0},
+   {334, 400,4,6,   9,3,  0},
+   {401, 549,4,6,  11,3,  0},
+   {550, 680,4,1,  10,5,  0},
+   {681, 850,4,1,  12,5,  0},
+   {851, 1050,   4,1,  12,5,  0},
+   {1051, 1250,  4,1,  15,4,  0},
+   {1251, 1350,  4,1,  15,4,  0},
{  0, 333,2, 6,  7,3,  0},
{334, 400,2, 6,  9,3,  0},
{401, 549,2, 6, 11,3,  0},
diff --git a/include/configs/corenet_ds.h b/include/configs/corenet_ds.h
index dd609da..3dcee85 100644
--- a/include/configs/corenet_ds.h
+++ b/include/configs/corenet_ds.h
@@ -124,7 +124,7 @@
 #define CONFIG_SYS_SDRAM_BASE  CONFIG_SYS_DDR_SDRAM_BASE
 
 #define CONFIG_DIMM_SLOTS_PER_CTLR 1
-#define CONFIG_CHIP_SELECTS_PER_CTRL   (2 * CONFIG_DIMM_SLOTS_PER_CTLR)
+#define CONFIG_CHIP_SELECTS_PER_CTRL   (4 * CONFIG_DIMM_SLOTS_PER_CTLR)
 
 #define CONFIG_DDR_SPD
 #define CONFIG_FSL_DDR3
-- 
1.6.0.6

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] please update ARM mach-types

Dear Tom Rix,

Could you please update ARM machine types?

Its about 40 entries behind, including my recently added entry ;)

Best Regards,
Reinhard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] musb: Add usb support configs for DA850

2010-08-17 Thread Ajay Kumar Gupta

DA8xx musb support is already available and DA830 is using it as
it has required configs in include/configs/da830evm.h

Updated the DA850 evm configs so that DA850 evm can also use
musb functionalities.

CC: Remy Bohmer li...@bohmer.net
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
 include/configs/da850evm.h |   37 +
 1 files changed, 37 insertions(+), 0 deletions(-)

diff --git a/include/configs/da850evm.h b/include/configs/da850evm.h
index 357715d..948c195 100644
--- a/include/configs/da850evm.h
+++ b/include/configs/da850evm.h
@@ -137,4 +137,41 @@
 #undef CONFIG_CMD_ENV
 #endif
 
+/*
+ * USB configuration
+ */
+#define CONFIG_USB_DA8XX   /* Platform hookup to MUSB controller */
+#define CONFIG_MUSB_HCD
+
+#ifdef CONFIG_USB_DA8XX
+
+#ifdef CONFIG_MUSB_HCD /* include support for usb host */
+#define CONFIG_CMD_USB /* include support for usb cmd */
+
+#define CONFIG_USB_STORAGE /* MSC class support */
+#define CONFIG_CMD_STORAGE /* inclue support for usb-storage cmd */
+#define CONFIG_CMD_FAT /* inclue support for FAT/storage */
+#define CONFIG_DOS_PARTITION   /* inclue support for FAT/storage */
+
+#ifdef CONFIG_USB_KEYBOARD /* HID class support */
+#define CONFIG_SYS_USB_EVENT_POLL
+#define CONFIG_PREBOOT usb start
+#endif /* CONFIG_USB_KEYBOARD */
+
+#endif /* CONFIG_MUSB_HCD */
+
+#ifdef CONFIG_MUSB_UDC
+/* USB device configuration */
+#define CONFIG_USB_DEVICE  1
+#define CONFIG_USB_TTY 1
+#define CONFIG_SYS_CONSOLE_IS_IN_ENV   1
+/* Change these to suit your needs */
+#define CONFIG_USBD_VENDORID   0x0451
+#define CONFIG_USBD_PRODUCTID  0x5678
+#define CONFIG_USBD_MANUFACTURER   Texas Instruments
+#define CONFIG_USBD_PRODUCT_NAME   DA850EVM
+#endif /* CONFIG_MUSB_UDC */
+
+#endif /* CONFIG_USB_DA8XX */
+
 #endif /* __CONFIG_H */
-- 
1.6.2.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Debugging why my kernel won't start

Dear Rogan Dawes,

In message 4c6b08f1.9000...@dawes.za.net you wrote:

 The ramdisk is located at ff9a (in flash). Its image header
 relocates it to 0080:

Try to copy the ramdisk to RAM, and pass the Linux kernl an address in
RAM.

Try it.

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 realize that command does have its fascination, even under  circum-
stances such as these, but I neither enjoy the idea of command nor am
I  frightened  of  it. It simply exists, and I will do whatever logi-
cally needs to be done.
-- Spock, The Galileo Seven, stardate 2812.7
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/2 v5][U-BOOT] Zoom3: Add support for OMAP3630 Zoom3 board.