Subject: U-Boot-Users Digest, Vol 23, Issue 11
From: [email-masked]
To: [email-masked]
Date: Wed, 02 Apr 2008 11:58:00 -0700
List-Id: Universal Boot Loader general discussion <u-boot-users.lists.sourceforge.net>

Send U-Boot-Users mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.sourceforge.net/lists/listinfo/u-boot-users
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of U-Boot-Users digest..."

Today's Topics:

   1. Re: [PATCH] Fix fdt set command to conform to dts spec
      (Jerry Van Baren)
   2. Re: [PATCH] Fix host tool build breakage, take two
      (Bartlomiej Sieka)
   3. LED&RFID Ankara Fuar?na Davetlisiniz!!! ( LED&RFID e-davetiye )
   4. Re: [PATCH] Fix host tool build breakage, take two (Kumar Gala)
   5. Re: [PATCH] mpc837xerdb: Fix warning: implicit declaration of
      function 'fdt_fixup_dr_usb' (Kim Phillips)
   6. [PATCH] ads5121e DRAM init (Kenneth Johansson)
   7. Re: [PATCH] Fix host tool build breakage, take two (Wolfgang Denk)

----------------------------------------------------------------------

Message: 1
Date: Wed, 02 Apr 2008 11:29:36 -0400
From: Jerry Van Baren <[email-masked]>
Subject: Re: [U-Boot-Users] [PATCH] Fix fdt set command to conform to
	dts spec
To: Andy Fleming <[email-masked]>
Cc: [email-masked], [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=us-ascii; format=flowed

Andy Fleming wrote:
> The fdt set command was treating properties specified as <00> and <0011>
> as byte streams, rather than as an array of cells.  As we already have
> syntax for expressing the desire for a stream of bytes ([ xx xx ...]),
> we should use the <> syntax to describe arrays of cells, which are always
> 32-bits per element.  If we imagine this likely (IMHO) scenario:
> 
>> fdt set /ethernet-phy@1 reg <1>
> 
> With the old code, this would create a bad fdt, since the reg cell would be
> made to be one byte in length.  But the cell must be 4 bytes, so this would
> break mysteriously.

Confirmed, my bad.  Applied to the u-boot-fdt repo.

Thanks,
gvb

------------------------------

Message: 2
Date: Wed, 02 Apr 2008 17:59:48 +0200
From: Bartlomiej Sieka <[email-masked]>
Subject: Re: [U-Boot-Users] [PATCH] Fix host tool build breakage, take
	two
To: Kumar Gala <[email-masked]>
Cc: [email-masked],	Haavard Skinnemoen
	<[email-masked]>,	Wolfgang Denk <[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Kumar Gala wrote:
> On Tue, 1 Apr 2008, Wolfgang Denk wrote:
[...]
>>> Any ideas on how to work around this?  Do we really intend to pick up
>>> the system md5.h or should we be getting the one from u-boot/include/
>>> md5.h?
>> We need the system md5.h, I think. We'll investigate.
> 
> If I force things to use the md5.h in u-boot/include things seem to build.
> Here's the patch for the forcing:

I think that generally it is a better idea to use U-Boot's includes when
building for the host system, as this gives us better control over what
exactly gets included. But then on the other hand, tools/Makefils has this:

CPPFLAGS   = -idirafter $(SRCTREE)/include \
		-idirafter $(OBJTREE)/include2 \
		-idirafter $(OBJTREE)/include \

Could anyone comment on the reasons why we try U-Boot's includes after
system includes? Perhaps it would be a good idea to reverse the order --
see below for a quick RFC patch (compile-tested on two arm and two ppc
boards, each arch with and without CONFIG_FIT enabled).

Kumar - could you try the patch out and see if it helps your build issue?

Regards,
Bartlomiej

diff --git a/tools/Makefile b/tools/Makefile
index 8784a6d..93f74aa 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -117,7 +117,7 @@ BINS        := $(addprefix $(obj),$(BIN_FILES))
  #
  # Use native tools and options
  #
-CPPFLAGS   = -idirafter $(SRCTREE)/include \
+CPPFLAGS   = -I $(SRCTREE)/include \
		-idirafter $(OBJTREE)/include2 \
		-idirafter $(OBJTREE)/include \
		-DTEXT_BASE=$(TEXT_BASE) -DUSE_HOSTCC

------------------------------

Message: 3
Date: Wed, 2 Apr 2008 20:24:00 +0300
From: " LED&RFID e-davetiye " <[email-masked]>
Subject: [U-Boot-Users] LED&RFID Ankara Fuar?na Davetlisiniz!!!
To: <[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="iso-8859-9"

Untitled Document

  

  

        BU DAVET?YEN?N ?IKI?INI ALARAK YA DA L?NKTEK? FORMU DOLDURARAK 

      FUARIMIZI ?CRETS?Z Z?YARET EDEB?L?RS?N?Z. 

          

     

  
    Marmara Tan&#305;t&#305;m Fuarc&#305;l&#305;k

        ?stanbul (Merkez) Tel: +90 212 481 04 04 Fax: +90 212 481 04 74

        Ankara (Sube) Tel: +90 312 426 64 22 Fax: +90 312 426 64 41

        ?zmir (Sube)  Tel: +90 232 422 00 93 Fax: +90 232 422 16 33

     

  
    Listemizden ?&#305;kmak istiyorsan&#305;z l?tfen buraya t?klay?n. 

-------------- next part --------------
An HTML attachment was scrubbed...

------------------------------

Message: 4
Date: Wed, 2 Apr 2008 12:24:49 -0500
From: Kumar Gala <[email-masked]>
Subject: Re: [U-Boot-Users] [PATCH] Fix host tool build breakage, take
	two
To: Bartlomiej Sieka <[email-masked]>
Cc: [email-masked],	Haavard Skinnemoen
	<[email-masked]>,	Wolfgang Denk <[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes

On Apr 2, 2008, at 10:59 AM, Bartlomiej Sieka wrote:
> Kumar Gala wrote:
>> On Tue, 1 Apr 2008, Wolfgang Denk wrote:
> [...]
>>>> Any ideas on how to work around this?  Do we really intend to  
>>>> pick up
>>>> the system md5.h or should we be getting the one from u-boot/ 
>>>> include/
>>>> md5.h?
>>> We need the system md5.h, I think. We'll investigate.
>> If I force things to use the md5.h in u-boot/include things seem to  
>> build.
>> Here's the patch for the forcing:
>
> I think that generally it is a better idea to use U-Boot's includes  
> when
> building for the host system, as this gives us better control over  
> what
> exactly gets included. But then on the other hand, tools/Makefils  
> has this:
>
> CPPFLAGS   = -idirafter $(SRCTREE)/include \
> 		-idirafter $(OBJTREE)/include2 \
> 		-idirafter $(OBJTREE)/include \
>
> Could anyone comment on the reasons why we try U-Boot's includes after
> system includes? Perhaps it would be a good idea to reverse the  
> order --
> see below for a quick RFC patch (compile-tested on two arm and two ppc
> boards, each arch with and without CONFIG_FIT enabled).
>
> Kumar - could you try the patch out and see if it helps your build  
> issue?
>
> Regards,
> Bartlomiej
>
> diff --git a/tools/Makefile b/tools/Makefile
> index 8784a6d..93f74aa 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -117,7 +117,7 @@ BINS        := $(addprefix $(obj),$(BIN_FILES))
> #
> # Use native tools and options
> #
> -CPPFLAGS   = -idirafter $(SRCTREE)/include \
> +CPPFLAGS   = -I $(SRCTREE)/include \
> 		-idirafter $(OBJTREE)/include2 \
> 		-idirafter $(OBJTREE)/include \
> 		-DTEXT_BASE=$(TEXT_BASE) -DUSE_HOSTCC

I get:

gcc -g -Wall -I /tmp/u-boot-85xx/include -idirafter /tmp/u-boot-85xx/ 
include2 -idirafter /tmp/u-boot-85xx/include -DTEXT_BASE=0xfff80000 - 
DUSE_HOSTCC -O -c -o image.o image.c
In file included from image.c:73:
/usr/include/md5.h:27: error: parse error before "UINT4"
/usr/include/md5.h:30: error: parse error before '}' token
/usr/include/md5.h:38: error: parse error before "PROTO_LIST"
/usr/include/md5.h:39: error: parse error before "PROTO_LIST"
/usr/include/md5.h:41: error: parse error before "PROTO_LIST"
/usr/include/md5.h:43: error: parse error before "PROTO_LIST"
image.c: In function `calculate_hash':
image.c:1944: warning: implicit declaration of function `md5'
make[1]: *** [image.o] Error 1
make[1]: Leaving directory `/tmp/u-boot-85xx/tools'
make: *** [tools] Error 2

- k

------------------------------

Message: 5
Date: Wed, 2 Apr 2008 12:50:26 -0500
From: Kim Phillips <[email-masked]>
Subject: Re: [U-Boot-Users] [PATCH] mpc837xerdb: Fix warning: implicit
	declaration of function 'fdt_fixup_dr_usb'
To: Jean-Christophe PLAGNIOL-VILLARD <[email-masked]>
Cc: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=US-ASCII

On Wed,  2 Apr 2008 13:41:21 +0200
Jean-Christophe PLAGNIOL-VILLARD <[email-masked]> wrote:

> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <[email-masked]>
> 
Acked-by: Kim Phillips <[email-masked]>

Kim

------------------------------

Message: 6
Date: Wed, 02 Apr 2008 20:34:14 +0200
From: Kenneth Johansson <[email-masked]>
Subject: [U-Boot-Users] [PATCH] ads5121e DRAM init
To: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain

    Do the DRAM init according to micron MT47H64M8B6-37E
    documentation.
    
    Signed-off-by: Kenneth Johansson <[email-masked]>

diff --git a/board/ads5121/ads5121.c b/board/ads5121/ads5121.c
index 8629b03..606cc6b 100644
--- a/board/ads5121/ads5121.c
+++ b/board/ads5121/ads5121.c
@@ -158,26 +158,18 @@ long int fixed_sdram (void)
 		im->mddrc.ddr_command = CFG_MICRON_NOP;
 
 	im->mddrc.ddr_command = CFG_MICRON_PCHG_ALL;
-	im->mddrc.ddr_command = CFG_MICRON_NOP;
-	im->mddrc.ddr_command = CFG_MICRON_RFSH;
-	im->mddrc.ddr_command = CFG_MICRON_NOP;
-	im->mddrc.ddr_command = CFG_MICRON_RFSH;
-	im->mddrc.ddr_command = CFG_MICRON_NOP;
-	im->mddrc.ddr_command = CFG_MICRON_INIT_DEV_OP;
-	im->mddrc.ddr_command = CFG_MICRON_NOP;
-	im->mddrc.ddr_command = CFG_MICRON_EM2;
-	im->mddrc.ddr_command = CFG_MICRON_NOP;
-	im->mddrc.ddr_command = CFG_MICRON_PCHG_ALL;
-	im->mddrc.ddr_command = CFG_MICRON_EM2;
-	im->mddrc.ddr_command = CFG_MICRON_EM3;
-	im->mddrc.ddr_command = CFG_MICRON_EN_DLL;
-	im->mddrc.ddr_command = CFG_MICRON_INIT_DEV_OP;
+	im->mddrc.ddr_command = CFG_MICRON_DDR2_LM_EM2;
+	im->mddrc.ddr_command = CFG_MICRON_DDR2_LM_EM3;
+	im->mddrc.ddr_command = CFG_MICRON_DDR2_LM_EM;
+	im->mddrc.ddr_command = CFG_MICRON_DDR2_LM_MR_DLL_RESET;
+                                
 	im->mddrc.ddr_command = CFG_MICRON_PCHG_ALL;
 	im->mddrc.ddr_command = CFG_MICRON_RFSH;
-	im->mddrc.ddr_command = CFG_MICRON_INIT_DEV_OP;
-	im->mddrc.ddr_command = CFG_MICRON_OCD_DEFAULT;
-	im->mddrc.ddr_command = CFG_MICRON_PCHG_ALL;
-	im->mddrc.ddr_command = CFG_MICRON_NOP;
+	im->mddrc.ddr_command = CFG_MICRON_RFSH;
+
+	im->mddrc.ddr_command = CFG_MICRON_DDR2_LM_MR;
+	im->mddrc.ddr_command = CFG_MICRON_DDR2_LM_EM_OCD;
+	im->mddrc.ddr_command = CFG_MICRON_DDR2_LM_EM_EXIT;
 
 	/* Start MDDRC */
 	im->mddrc.ddr_time_config0 = CFG_MDDRC_TIME_CFG0_RUN;
diff --git a/include/configs/ads5121.h b/include/configs/ads5121.h
index c147424..83781c6 100644
--- a/include/configs/ads5121.h
+++ b/include/configs/ads5121.h
@@ -117,14 +117,22 @@
 #define CFG_MDDRC_TIME_CFG1	0x54EC1168
 #define CFG_MDDRC_TIME_CFG2	0x35210864
 
-#define CFG_MICRON_NOP		0x01380000
-#define CFG_MICRON_PCHG_ALL	0x01100400
-#define CFG_MICRON_EM2		0x01020000
-#define CFG_MICRON_EM3		0x01030000
-#define CFG_MICRON_EN_DLL	0x01010000
-#define CFG_MICRON_RFSH		0x01080000
-#define CFG_MICRON_INIT_DEV_OP	0x01000432
-#define CFG_MICRON_OCD_DEFAULT	0x01010780
+/* DRAM commands */
+#define CFG_MICRON_NOP			0x01380000
+#define CFG_MICRON_PCHG_ALL		0x01100400
+#define CFG_MICRON_RFSH			0x01080000
+
+/* DDR2 specific commands */
+#define CFG_MICRON_DDR2_LM_MR_DLL_RESET	0x01000100	/* reset DLL        */
+#define CFG_MICRON_DDR2_LM_MR		0x01000432	/* burst lenght 4   */
+							/* CAS 3            */
+							/* Write recovery 3 */
+#define CFG_MICRON_DDR2_LM_EM_OCD	0x01010780	/* OCD default      */
+							/* DQS# enable      */
+#define CFG_MICRON_DDR2_LM_EM_EXIT	0x01010400	/* DQS# enable      */
+#define CFG_MICRON_DDR2_LM_EM		0x01010000
+#define CFG_MICRON_DDR2_LM_EM2		0x01020000
+#define CFG_MICRON_DDR2_LM_EM3		0x01030000
 
 /* DDR Priority Manager Configuration */
 #define CFG_MDDRCGRP_PM_CFG1	0x000777AA

------------------------------

Message: 7
Date: Wed, 02 Apr 2008 20:57:50 +0200
From: Wolfgang Denk <[email-masked]>
Subject: Re: [U-Boot-Users] [PATCH] Fix host tool build breakage, take
	two
To: Bartlomiej Sieka <[email-masked]>
Cc: [email-masked],	Haavard Skinnemoen
	<[email-masked]>,	Kumar Gala <[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1

In message <[email-masked]> you wrote:
>
> I think that generally it is a better idea to use U-Boot's includes when
> building for the host system, as this gives us better control over what
> exactly gets included. But then on the other hand, tools/Makefils has this:

But U-boot doesn't have the knowledge about the target system that the
target distribution has.

> CPPFLAGS   = -idirafter $(SRCTREE)/include \
> 		-idirafter $(OBJTREE)/include2 \
> 		-idirafter $(OBJTREE)/include \
> 
> Could anyone comment on the reasons why we try U-Boot's includes after
> system includes? Perhaps it would be a good idea to reverse the order --
> see below for a quick RFC patch (compile-tested on two arm and two ppc
> boards, each arch with and without CONFIG_FIT enabled).

Don't! I guess you tried just one configuration, and probably not even
building on a 32 versus a 64 bit host system.

When building tools with the host compiler that are supposed  to  run
on  the host system we should always use the host's header files. And
we should really make sure that U-Boot header files get used only iff
there is no corresponding host header  file,  and  in  this  case  we
should make sure that this is intentional.

The current problem comes from the fact  that  old  versions  of  the
cyrus-sasl-devel  package  install  a  /usr/include/md5.h  file which
probably NOT intended for direct use, but only within the context  of
the  SASL  package; recent versions of the same package install it in
/usr/include/sasl/md5.h instead.

To solve this problem I see three solutions:

1) Fix the broken host systems for example by installing more recent
   versions of the cyrus-sasl-devel package; this would be best, but
   is unfortunately not possible everywhere.
2) Use relative file names (as suggested by Kumar) or similar methods
   to make sure we pick up the md5.h header file from a local
   directory instead from /usr/include.
3) Rename md5.h to make sure we use a pick up our own file instead of
   some unrelated file which happens to have the same name.

My vote goes for 3).

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: [email-masked]
It is a good thing for an uneducated man to read books of quotations.
                        - Sir Winston Churchill _My Early Life_ ch. 9

------------------------------

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

------------------------------

_______________________________________________
U-Boot-Users mailing list
[email-masked]
https://lists.sourceforge.net/lists/listinfo/u-boot-users

End of U-Boot-Users Digest, Vol 23, Issue 11
********************************************