date:20110420

Re: [U-Boot] UEC phy not working on first try

2011-04-20 Thread DUNDA Matthias

  I am using u-boot.2010.09 on a MPC8568-based board.
 
  When trying to boot over one of the UEC network interfaces, it is not
  working instantly. The cable is connected from the beginning, but I
  have to issue a manual 'boot' command, sometimes even multiple times
  before the link is correct. This is the output:

 Do all the UEC interfaces show the same symptoms?

Yes, this happens for all UECs. And I think it worked until we switched from 
u-boot 2009.11.1 to 2010.09 - but there's so much change that I didn't find the 
reason for it, yet.


 The driver thinks the link went away again.  When the cable is
 connected all the time, then this is an indication of something going
 wrong.  You should try to diagnose, why the software gets this link
 change and if it really is an information that the phy provides, if the
 physical path to the phy is stable.

Well, the software runs though uec_init (the_first_run is zero) and gets a 
positive link state in the do-while-loop instantly. Afterwards adjust_link is 
called - and there it fails. Strange thing - I guess I need to dig a little 
deeper...

Code hints are very appreciated! ;-)


 Best wishes
   Detlev Zundel
Thanks!
Matthias


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

Re: [U-Boot] Fix for overlapping sections?

2011-04-20 Thread Wolfgang Denk

Dear Larry,

In message 
f4ba0e7cacfbac4384dc92f2d5aab507ab4...@dsgburgmail001.gburg.drs-ds.master you 
wrote:
 
 A while back there was a fix for the overlapping section link problem
 (see below) involving changing some sort of global.  Does anyone have a
 pointer to the change.  I'm using a fairly old uboot for AMCC
 Canyonlands/460Ex and can't easily upgrade to a newer uboot build.

I don't understand what you mean.  Why exactly can you not upgrade to
a recent version of U-Boot?  All it takes to get a current version of
U-Boot for the Canyonlands board is to type ./MAKEALL canyonlands.



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 fail-safe circuit will destroy others. -- Klipstein
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH-V2 2/2] at91: reworked support for otc570 board

2011-04-20 Thread Daniel Gorsulowski

Hello Reinhard,

Reinhard Meyer wrote:
 Am 18.04.2011 16:15, schrieb Daniel Gorsulowski:
 The otc570 board support was broken. Within this opportunity, I completely
 reworked the board files.

 Signed-off-by: Daniel Gorsulowski daniel.gorsulow...@esd.eu
 ---

 This patch is based on u-boot-atmel/rework101229 branch (minus the last 5
 patches) plus the 'at91: fixed at91sam9263 system file' patch in
 u-boot-atmel/next branch.

 V2: -fixed commit description

  board/esd/otc570/config.mk |1 -
  board/esd/otc570/otc570.c  |  106 ++
  boards.cfg |3 +-
  include/configs/otc570.h   |  265 
 +---
  4 files changed, 211 insertions(+), 164 deletions(-)
  delete mode 100644 board/esd/otc570/config.mk
 
 This patch had several places with spacetab or start of linespace.
 
 I removed them manually. Please, next time run your patches through
 linux/scripts/checkpatch.pl. Thanks.

Sorry, but I checked my patches by checkpatch.pl. Maybe you can explain
me, what I did wrong?

danielg@debby:~/git/u-boot-atmel$
../linux/linux-2.6/scripts/checkpatch.pl
0002-at91-reworked-support-for-otc570-board.patch
WARNING: Use #include linux/io.h instead of asm/io.h
#48: FILE: board/esd/otc570/otc570.c:30:
+#include asm/io.h

ERROR: Macros with complex values should be enclosed in parenthesis
#578: FILE: include/configs/otc570.h:209:
+# define CONFIG_SYS_NAND_ENABLE_PINAT91_PIO_PORTD, 15

ERROR: Macros with complex values should be enclosed in parenthesis
#579: FILE: include/configs/otc570.h:210:
+# define CONFIG_SYS_NAND_READY_PIN AT91_PIO_PORTA, 22

total: 2 errors, 1 warnings, 610 lines checked

0002-at91-reworked-support-for-otc570-board.patch has style problems,
please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

 
 Applied to u-boot-atmel/next.

Thank you!

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

-- 
Mit freundlichen Grüßen
Daniel Gorsulowski

-
B.Eng. Daniel Gorsulowski
System-Design

esd electronic system design gmbh
Vahrenwalder Str. 207 - 30165 Hannover - GERMANY
Telefon: 0511-37298-192 - Fax: 0511-37298-68
Bitte besuchen Sie uns im Internet unter http://www.esd.eu
Quality Products - Made in Germany
-
Geschäftsführer: Klaus Detering
Amtsgericht Hannover HRB 51373 - VAT-ID DE 115672832
-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] How does u-boot know where to put its start code?

2011-04-20 Thread Rogan Dawes

On 2011/04/20 7:42 AM, Albert ARIBAUD wrote:
 Le 20/04/2011 04:23, Hebbar, Gururaja a écrit :
 Hi,

 On Wed, Apr 20, 2011 at 02:43:23, Rogan Dawes wrote:
 Hi folks,

 I'm trying to understand a bit more about how u-boot creates the
 image, such that the CPU reset vector is pointing to the right piece
 of code when it is reset.

 i.e. my DNS323 (Orion5x) has a reset vector of 0x. But for
 the life of me, I can't find anywhere that actually references that
 value to place the start code at that point.


 Placing the final boot image is left to user who flashes/burns it
 board. But it should be same as _TEXT_BASE (this is being removed now.
 Orion5x is arm based). Also look
 atu-boot-src\arch\arm\cpu\arm926ejs\start.S 
 u-boot-src\arch\arm\cpu\arm926ejs\u-boot.lds for more info on how
 linker is instructed to place the starting code at predefined address.

 I'm basically trying to make sure that my CONFIG_SYS_TEXT_BASE is
 correct (the address in the flash to which I write the whole
 u-boot.bin file, right?.

 This is passed to linker as the entry point.
 
 There is another point re: orion5x based boards: often, their designers
 preferred generating a linear image for U-Boot, but the fact that the
 vector address is at  makes it impossible to directly the image
 there because it is always greater than 64K. So the designers put some
 pseudo-rom boot code at  that will finally jump to an address
 lower in FLASH; for ED Mini V2 it is FFF9, and that's where the
 U-Boot image is supposed to be flashed.

So, is that the address that you would use for CONFIG_SYS_TEXT_BASE ?

 Rogan, I bet in the DNS323 case, the same applies modulo your Flash
 size. Try tracing through the  code, it should not last more
 than a few tens of instructions before it jumps to some absolute address.

Do you think it would be possible to figure it out from the original
vendor u-boot?

Thanks

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

Re: [U-Boot] Update and Cut down mach types

2011-04-20 Thread Detlev Zundel

Hi Michael,

[...]

 I did that and got the following reply (without quotes due to cut-and-paste)

[...]

 The normal URL which you fetch the file from (as contained within the
 file) will give you the full listing rather than the cut-down version.
 There really is no need for uboot to go picking the copy up from the
 mainline kernel.

So we can just use that version and everything remains sane?  Then
let's do that and move on to other topics ;)

Cheers
  Detlev

-- 
If we knew what it was we were doing, we wouldn't call it research.
-- Einstein
--
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 3/6] TFTP: rename server to remote

2011-04-20 Thread Detlev Zundel

Hi Luca,

 Hi,

 just a few e-mails ago along this thread Albert Aribaud wrote:

  My opinion is that you should make sure that at least the code you touch
  is checkpatch-clean, so yes, you should fix that; but there is no need
  to submit 'checkpatch-compliance' patches. Just fix the line here so
  that checkpatch does not complain.


 So I proceeded along that way.

 Now Detlev Zundel wrote:
 ...
 Hm, I see.  Still, can we have one commit (with cosmetic in the
 changelog) that silences checkpatch but does not have any functional
 changes?  We really try hard to separate cosmetic from functional
 changes.  This makes reviewing (and debugging) so much easier.

 While I appreciate the careful review of my patches, I cannot hide
 that it is discouraging for new contributors to be requested for
 contradictory modifications.

Sorry for that, but it is only that we start using checkpatch more
aggressively, that such problems turn up which we did not yet agree on
how to solve.

 There should be one precise policy, and that should be clearly documented.

I fully agree.

 http://www.denx.de/wiki/U-Boot/CodingStyle is the place where I would
 expect to find it.

I'll start a new thread to discuss this.  Hopefully we then come up with
a policy to stick into that wiki page.

Thanks for bearing with me
  Detlev

-- 
In God we trust.  All others we monitor
   -- NSA motto
--
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] UEC phy not working on first try

2011-04-20 Thread Detlev Zundel

Hi Matthias,

  I am using u-boot.2010.09 on a MPC8568-based board.
 
  When trying to boot over one of the UEC network interfaces, it is not
  working instantly. The cable is connected from the beginning, but I
  have to issue a manual 'boot' command, sometimes even multiple times
  before the link is correct. This is the output:

 Do all the UEC interfaces show the same symptoms?

 Yes, this happens for all UECs. And I think it worked until we
 switched from u-boot 2009.11.1 to 2010.09 - but there's so much change
 that I didn't find the reason for it, yet.

Ah!  I didn't realize that you are in the excellent position to have one
good and one bad commit.  Simply use git bisect to find the problematic
commit and show that to us.

Best wishes
  Detlev

-- 
... and I will continue to use a  low-level language to indicate how
machines actually compute.  Readers  who only want to see algorithms
that are already packaged in a plug-in way, using a trendy language,
should buy other people's books.
 -- Donald Knuth, Fascicle 1
--
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] How does u-boot know where to put its start code?

2011-04-20 Thread Albert ARIBAUD

Hi Rogan,

Le 20/04/2011 09:46, Rogan Dawes a écrit :
 On 2011/04/20 7:42 AM, Albert ARIBAUD wrote:
 Le 20/04/2011 04:23, Hebbar, Gururaja a écrit :
 Hi,

 On Wed, Apr 20, 2011 at 02:43:23, Rogan Dawes wrote:
 Hi folks,

 I'm trying to understand a bit more about how u-boot creates the
 image, such that the CPU reset vector is pointing to the right piece
 of code when it is reset.

 i.e. my DNS323 (Orion5x) has a reset vector of 0x. But for
 the life of me, I can't find anywhere that actually references that
 value to place the start code at that point.


 Placing the final boot image is left to user who flashes/burns it
 board. But it should be same as _TEXT_BASE (this is being removed now.
 Orion5x is arm based). Also look
 atu-boot-src\arch\arm\cpu\arm926ejs\start.S
 u-boot-src\arch\arm\cpu\arm926ejs\u-boot.lds for more info on how
 linker is instructed to place the starting code at predefined address.

 I'm basically trying to make sure that my CONFIG_SYS_TEXT_BASE is
 correct (the address in the flash to which I write the whole
 u-boot.bin file, right?.

 This is passed to linker as the entry point.

 There is another point re: orion5x based boards: often, their designers
 preferred generating a linear image for U-Boot, but the fact that the
 vector address is at  makes it impossible to directly the image
 there because it is always greater than 64K. So the designers put some
 pseudo-rom boot code at  that will finally jump to an address
 lower in FLASH; for ED Mini V2 it is FFF9, and that's where the
 U-Boot image is supposed to be flashed.

 So, is that the address that you would use for CONFIG_SYS_TEXT_BASE ?

Yes, exactly.

 Rogan, I bet in the DNS323 case, the same applies modulo your Flash
 size. Try tracing through the  code, it should not last more
 than a few tens of instructions before it jumps to some absolute address.

 Do you think it would be possible to figure it out from the original
 vendor u-boot?

Sort of: if you look up the vendor U-Boot source code and find nothing 
about 0x, that's a sign that it expects something else than 
U-Boot to kick in at that address.

You can also disassemble what lies at 0x on your board, either 
live through JTAG or offline by running a binary extract of  
through objdump.

 Thanks

 Rogan

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

Re: [U-Boot] [PATCH v2 3/6] TFTP: rename server to remote

2011-04-20 Thread Detlev Zundel

Hi Luca,

 Il 19/04/2011 16:18, Detlev Zundel ha scritto:
 Hi Luca,

 With the upcoming TFTP server implementation, the remote node can be
 either a client or a server, so avoid ambiguities.

 Signed-off-by: Luca Ceresoliluca.ceres...@comelit.it
 Cc: Wolfgang Denkw...@denx.de
 ---
 Changes in v2:
   - fixed checkpatch issues.

   net/tftp.c |   42 +-
   1 files changed, 21 insertions(+), 21 deletions(-)

 diff --git a/net/tftp.c b/net/tftp.c
 index 00abec3..da545c6 100644
 --- a/net/tftp.c
 +++ b/net/tftp.c
 @@ -55,18 +55,18 @@ enum {
 TFTP_ERR_FILE_ALREADY_EXISTS = 6,
   };

 -static IPaddr_t TftpServerIP;
 -static int TftpServerPort; /* The UDP port at their end
 */
 -static int TftpOurPort;/* The UDP port at our end  
 */
 +static IPaddr_t TftpRemoteIP;
 +static int TftpRemotePort; /* The UDP port at their end*/
 +static int TftpOurPort;/* The UDP port at our end  */
   static intTftpTimeoutCount;
 -static ulong   TftpBlock;  /* packet sequence number   
 */
 -static ulong   TftpLastBlock;  /* last packet sequence number 
 received */
 -static ulong   TftpBlockWrap;  /* count of sequence number 
 wraparounds */
 -static ulong   TftpBlockWrapOffset;/* memory offset due to 
 wrapping*/
 +static ulong   TftpBlock;  /* packet sequence number   
 */
 +static ulong   TftpLastBlock;  /* last packet sequence number received 
 */
 +static ulong   TftpBlockWrap;  /* count of sequence number wraparounds 
 */
 +static ulong   TftpBlockWrapOffset; /* memory offset due to wrapping   
 */
 These changes are indentation only changes, so they should be in a
 separate patch.

 It's needed for checkpatch compliance.

I'm trying to understand the problems involved, but looking at this
again, it is not clear to me what you say here.  When I run your version
1 of the patches (where you only do the rename) through checkpatch, I
get:

  WARNING: line over 80 characters
  #116: FILE: net/tftp.c:59:
  +static int   TftpRemotePort; /* The UDP port at their end
*/
  
  WARNING: consider using kstrto* in preference to simple_strtol
  #215: FILE: net/tftp.c:619:
  + TftpRemotePort = simple_strtol(ep, NULL, 10);
  
  total: 0 errors, 2 warnings, 99 lines checked
  
  /home/dzu/transfer/p2 has style problems, please review.  If any of these 
errors
  are false positives report them to the maintainer, see
  CHECKPATCH in MAINTAINERS.

So I'm not sure why you say that the other changes are needed for
checkpatch.  What exactly do you mean by this?

Thanks
  Detlev

-- 
C hasn't changed much since the 1970s. And let's face it it's ugly.
Can't we do better? C++? (Sorry, never mind.)
-- Rob Pike
--
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] Update and Cut down mach types

2011-04-20 Thread Albert ARIBAUD

Le 19/04/2011 15:45, Paulraj, Sandeep a écrit :



 Hello Sandeep, Wolfgang

 Am 19.04.2011 14:42, schrieb Paulraj, Sandeep:
 Wolfgang, Albert,

 Russell King sent some updates to the linux kernel for mach-types.

 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-
 2.6.git;a=commitdiff;h=6f82f4db80189281a8ac42f2e72396accb719b57

   He also removed a lot of entries which never made it to mainline.

 I have a patch and it is the branch below

 http://git.denx.de/?p=u-boot/u-boot-
 ti.git;a=shortlog;h=refs/heads/update-mach-types

 Please review and if it is acceptable to everyone then we should
 apply this patch to remain in sync with the mainline kernel.

 This will break a least jadecpu.
 We don't use Linux on this board. When
 porting I was requested to reserve an MACH_ID just in case the board
 will ever be used with Linux. This has not been the case for this board.
 But I would like to have this board in the u-boot tree.

 We are not removing this board from u-boot

 What will be the
 solution for ARM but non-Linux u-boot ports then? What should be passed
 to gd-bd-bi_arch_number?

 I'll defer to Wolfgang and Albert on this issue.

 There are new boards and hence mach types being added.
 Russell sent a patch that both added new mach IDs and removed many others.


 --Sandeep

If the jadecpu board does not require a machine ID because it does not 
run Linux, then it should be able to build without a machine ID. So:

- if the need for a machine ID lies in the jadecpu U-Boot code, then the 
jadecpu code should be fixed.

- if the need for a machine ID is general to the U-Boot ARM arch, than 
the ARM arch must be fixed.

Now somebody must find out which is which, and submit a patch copying 
either the jadecpu maintainer, the ARM custodian, or better yet, both. :)

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

[U-Boot] TFTP - check for len == 0 before storing

2011-04-20 Thread David Andrey

Hello,

I had a problem with an old TFTP Server which is sending a second last
data block with len == 0 at end. It's clearly not RFC conform, but I
still made a additional check in u-boot/tftp to avoid a wrong filesize
value. This wrong filesize value caused some trouble by NAND operations.


Regards
David



Date: Wed, 20 Apr 2011 10:12:10 +0200
Subject: [PATCH] Check for for data block len == 0

---
 net/tftp.c |   10 --
 1 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/net/tftp.c b/net/tftp.c
index ed559b7..40d81b5 100644
--- a/net/tftp.c
+++ b/net/tftp.c
@@ -135,8 +135,14 @@ mcast_cleanup(void)
 static __inline__ void
 store_block (unsigned block, uchar * src, unsigned len)
 {
-   ulong offset = block * TftpBlkSize + TftpBlockWrapOffset;
-   ulong newsize = offset + len;
+   ulong offset = 0;
+   ulong newsize = 0;
+
+   if (len == 0)
+   return;
+
+   offset = block * TftpBlkSize + TftpBlockWrapOffset;
+   newsize = offset + len;
 #ifdef CONFIG_SYS_DIRECT_FLASH_TFTP
int i, rc = 0;

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

Re: [U-Boot] Update and Cut down mach types

2011-04-20 Thread Igor Grinberg

Hi Sandeep, Albert, Wolfgang,

On 04/19/11 15:42, Paulraj, Sandeep wrote:
Wolfgang, Albert,

Russell King sent some updates to the linux kernel for mach-types.

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=6f82f4db80189281a8ac42f2e72396accb719b57

He also removed a lot of entries which never made it to mainline.

Well, as I understood from Russell, the main purpose of this cut down
is to make du -s linux/arch/arm smaller, because there is no real need in
all those boards listed in mach-types.h unless there is a support for them
in mainline Linux kernel.
Nevertheless the real ARM registry remains untouched - meaning that all
board ids remain the same and no board is removed from the registry.

This is the place where U-Boot board support diverges from Linux...

Are we obliged to follow the Linux mach-types.h?
Can't we just adopt Russell's cut down script to boards supported by U-Boot?
Or will it harden the mach-types.h future updates?

Have you thought of getting rid of mach-types.h completely?
Making every board define its ARM registry id can work and will
eliminate the need for mach-types.h update every couple of months.

I have a patch and it is the branch below

http://git.denx.de/?p=u-boot/u-boot-ti.git;a=shortlog;h=refs/heads/update-mach-types

Have you checked that none of the removed boards are in U-Boot tree?
Because if there are some, then their build will be broken...
And have to be fixed by... say a #define MACH_TYPE_* id
in a board_config file.

1 2 >

1 - 100 of 109 matches

Mail list logo