All of lore.kernel.org
 help / color / mirror / Atom feed
* [U-Boot-Users] fishing for ideas
@ 2004-10-01 16:03 Benjamin Collar
  2004-10-01 16:46 ` Frank
                   ` (2 more replies)
  0 siblings, 3 replies; 6+ messages in thread
From: Benjamin Collar @ 2004-10-01 16:03 UTC (permalink / raw)
  To: u-boot

Greetings folks

Yesterday's problems have been overcome. Mostly I was just
misunderstanding what was going on / what was supposed to be going on.
Thanks for the clues overall.

But there is a bit more to it. At the end of the day yesterday, I
performed exactly the same 'loads' command,  with exactly the same srec
file, as I had done at the beginning of the day, and it worked. Talk
about frustration!

Today I was working on it and loaded a linux kernel image. When I
'loads' it, using the u-boot command line, into ram, the 'md' command at
the loaded area shows 

00010000: 27051956 d3232bea 415d1e66 0005ba2c    '..V.#+.A].f...,
00010010: 7d8c5a14 3940ffff 914c0000 3bffffe0    }.Z.9 at ...L..;...
00010020: 4c696e75 782d322e 342e3138 00000000    Linux-2.4.18....
00010030: 00000000 00000000 00000000 00000000    ................

while objdump shows

 00000 27051956 d3232bea 415d1e66 0005ba2c  '..V.#+.A].f...,
 00010 00000000 00000000 82847f95 05070201  ................
 00020 4c696e75 782d322e 342e3138 00000000  Linux-2.4.18....

of course, you'll notice immediately that the 5th word is completely
bogus, among others.

I've spoken with the board developer (who also wrote a bootloader for
the board) and showed him the sdram initialization function, and he said
it was correct. However, I've got the behavior shown above. Is there
another reason why this sort of corruption would happen? (btw, using
'cu' to download the image into RAM).

Thanks for any tips
Ben

-- 
Benjamin Collar
Siemens AG
CT SE 2
Embedded Linux
089-636-53711

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [U-Boot-Users] fishing for ideas
@ 2004-10-01 16:31 VanBaren, Gerald
  0 siblings, 0 replies; 6+ messages in thread
From: VanBaren, Gerald @ 2004-10-01 16:31 UTC (permalink / raw)
  To: u-boot

> -----Original Message-----
> From: u-boot-users-admin at lists.sourceforge.net
> [mailto:u-boot-users-admin at lists.sourceforge.net]On Behalf Of Benjamin
> Collar
> Sent: Friday, October 01, 2004 12:04 PM
> To: u-boot-users at lists.sourceforge.net
> Subject: [U-Boot-Users] fishing for ideas
>
>
> Greetings folks
>
> Yesterday's problems have been overcome. Mostly I was just
> misunderstanding what was going on / what was supposed to be going on.
> Thanks for the clues overall.
>
> But there is a bit more to it. At the end of the day yesterday, I
> performed exactly the same 'loads' command,  with exactly the
> same srec
> file, as I had done at the beginning of the day, and it worked. Talk
> about frustration!
>
> Today I was working on it and loaded a linux kernel image. When I
> 'loads' it, using the u-boot command line, into ram, the 'md'
> command at
> the loaded area shows
>
> 00010000: 27051956 d3232bea 415d1e66 0005ba2c    '..V.#+.A].f...,
> 00010010: 7d8c5a14 3940ffff 914c0000 3bffffe0    }.Z.9 at ...L..;...
> 00010020: 4c696e75 782d322e 342e3138 00000000    Linux-2.4.18....
> 00010030: 00000000 00000000 00000000 00000000    ................
>
> while objdump shows
>
>  00000 27051956 d3232bea 415d1e66 0005ba2c  '..V.#+.A].f...,
>  00010 00000000 00000000 82847f95 05070201  ................
>  00020 4c696e75 782d322e 342e3138 00000000  Linux-2.4.18....
>
> of course, you'll notice immediately that the 5th word is completely
> bogus, among others.
>
> I've spoken with the board developer (who also wrote a bootloader for
> the board) and showed him the sdram initialization function,
> and he said
> it was correct. However, I've got the behavior shown above. Is there
> another reason why this sort of corruption would happen? (btw, using
> 'cu' to download the image into RAM).
>
> Thanks for any tips
> Ben
>
> --
> Benjamin Collar
> Siemens AG
> CT SE 2
> Embedded Linux
> 089-636-53711

Just because he said his bootloader works doesn't necessarily mean it really and truly works (I'm a skeptic: my first statement is invariably "show me").

Do you have caching enabled?  Did he?  Caching enables burst mode which is a well know cause of SDRAM corruption due to what appears to be and is claimed to be working initialization but actually is not correct.

Can you create a situation where the same operation works on his bootloader but doesn't work on yours?  Can you make his bootloader fail like yours when doing the same or similar operation (not necessarily downloading with cu)?

Yours with no answers, just questions...
gvb

******************************************
The following messages are brought to you by the Lawyers' League of IdioSpeak:


******************************************
The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege.  If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager.  Please do not copy it for any purpose, or disclose its contents to any other person.  The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company.  The recipient should check this e-mail and any attachments for the presence of viruses.  The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email.
******************************************

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [U-Boot-Users] fishing for ideas
  2004-10-01 16:03 [U-Boot-Users] fishing for ideas Benjamin Collar
@ 2004-10-01 16:46 ` Frank
  2004-10-01 17:45 ` Tadas
  2004-10-01 17:45 ` Wolfgang Denk
  2 siblings, 0 replies; 6+ messages in thread
From: Frank @ 2004-10-01 16:46 UTC (permalink / raw)
  To: u-boot

It does look like your sdram isn't configured correctly or you
have a hardware problem. Try turning off cache and are you sure
you can trust the hardware guy's opinion that he saw nothing
wrong with the sdram init values. Since he wrote the original
bootloader, he may not want you to replace it with u-boot.:-)

--- Benjamin Collar <benjamin.collar@siemens.com> wrote:

> Greetings folks
> 
> Yesterday's problems have been overcome. Mostly I was just
> misunderstanding what was going on / what was supposed to be
> going on.
> Thanks for the clues overall.
> 
> But there is a bit more to it. At the end of the day
> yesterday, I
> performed exactly the same 'loads' command,  with exactly the
> same srec
> file, as I had done at the beginning of the day, and it
> worked. Talk
> about frustration!
> 
> Today I was working on it and loaded a linux kernel image.
> When I
> 'loads' it, using the u-boot command line, into ram, the 'md'
> command at
> the loaded area shows 
> 
> 00010000: 27051956 d3232bea 415d1e66 0005ba2c   
> '..V.#+.A].f...,
> 00010010: 7d8c5a14 3940ffff 914c0000 3bffffe0   
> }.Z.9 at ...L..;...
> 00010020: 4c696e75 782d322e 342e3138 00000000   
> Linux-2.4.18....
> 00010030: 00000000 00000000 00000000 00000000   
> ................
> 
> while objdump shows
> 
>  00000 27051956 d3232bea 415d1e66 0005ba2c  '..V.#+.A].f...,
>  00010 00000000 00000000 82847f95 05070201  ................
>  00020 4c696e75 782d322e 342e3138 00000000  Linux-2.4.18....
> 
> of course, you'll notice immediately that the 5th word is
> completely
> bogus, among others.
> 
> I've spoken with the board developer (who also wrote a
> bootloader for
> the board) and showed him the sdram initialization function,
> and he said
> it was correct. However, I've got the behavior shown above. Is
> there
> another reason why this sort of corruption would happen? (btw,
> using
> 'cu' to download the image into RAM).
> 
> Thanks for any tips
> Ben
> 
> -- 
> Benjamin Collar
> Siemens AG
> CT SE 2
> Embedded Linux
> 089-636-53711
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on
> ITManagersJournal
> Use IT products in your business? Tell us what you think of
> them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to
> find out more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
> 



		
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [U-Boot-Users] fishing for ideas
  2004-10-01 16:03 [U-Boot-Users] fishing for ideas Benjamin Collar
  2004-10-01 16:46 ` Frank
@ 2004-10-01 17:45 ` Tadas
  2004-10-05 14:56   ` Benjamin Collar
  2004-10-01 17:45 ` Wolfgang Denk
  2 siblings, 1 reply; 6+ messages in thread
From: Tadas @ 2004-10-01 17:45 UTC (permalink / raw)
  To: u-boot

I had similar problem, and it was because of sdram
try to test memory somehow, fill with NOT THE SAME BYTES
and test it. probably memory test command should work.
I expect incorrect bank size

You can easy check if it is ubot fault.
just upload the same file with jtag debugger and you will see if there is
difference.


----- Original Message ----- 
From: "Benjamin Collar" <benjamin.collar@siemens.com>
To: <u-boot-users@lists.sourceforge.net>
Sent: Friday, October 01, 2004 7:03 PM
Subject: [U-Boot-Users] fishing for ideas


> Greetings folks
>
> Yesterday's problems have been overcome. Mostly I was just
> misunderstanding what was going on / what was supposed to be going on.
> Thanks for the clues overall.
>
> But there is a bit more to it. At the end of the day yesterday, I
> performed exactly the same 'loads' command,  with exactly the same srec
> file, as I had done at the beginning of the day, and it worked. Talk
> about frustration!
>
> Today I was working on it and loaded a linux kernel image. When I
> 'loads' it, using the u-boot command line, into ram, the 'md' command at
> the loaded area shows
>
> 00010000: 27051956 d3232bea 415d1e66 0005ba2c    '..V.#+.A].f...,
> 00010010: 7d8c5a14 3940ffff 914c0000 3bffffe0    }.Z.9 at ...L..;...
> 00010020: 4c696e75 782d322e 342e3138 00000000    Linux-2.4.18....
> 00010030: 00000000 00000000 00000000 00000000    ................
>
> while objdump shows
>
>  00000 27051956 d3232bea 415d1e66 0005ba2c  '..V.#+.A].f...,
>  00010 00000000 00000000 82847f95 05070201  ................
>  00020 4c696e75 782d322e 342e3138 00000000  Linux-2.4.18....
>
> of course, you'll notice immediately that the 5th word is completely
> bogus, among others.
>
> I've spoken with the board developer (who also wrote a bootloader for
> the board) and showed him the sdram initialization function, and he said
> it was correct. However, I've got the behavior shown above. Is there
> another reason why this sort of corruption would happen? (btw, using
> 'cu' to download the image into RAM).
>
> Thanks for any tips
> Ben
>
> -- 
> Benjamin Collar
> Siemens AG
> CT SE 2
> Embedded Linux
> 089-636-53711
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out
more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [U-Boot-Users] fishing for ideas
  2004-10-01 16:03 [U-Boot-Users] fishing for ideas Benjamin Collar
  2004-10-01 16:46 ` Frank
  2004-10-01 17:45 ` Tadas
@ 2004-10-01 17:45 ` Wolfgang Denk
  2 siblings, 0 replies; 6+ messages in thread
From: Wolfgang Denk @ 2004-10-01 17:45 UTC (permalink / raw)
  To: u-boot

In message <1096646639.10111.115.camel@mhpajh5c> you wrote:
> 
> Today I was working on it and loaded a linux kernel image. When I
> 'loads' it, using the u-boot command line, into ram, the 'md' command at
> the loaded area shows 
> 
> 00010000: 27051956 d3232bea 415d1e66 0005ba2c    '..V.#+.A].f...,
> 00010010: 7d8c5a14 3940ffff 914c0000 3bffffe0    }.Z.9 at ...L..;...
> 00010020: 4c696e75 782d322e 342e3138 00000000    Linux-2.4.18....
> 00010030: 00000000 00000000 00000000 00000000    ................
> 
> while objdump shows
> 
>  00000 27051956 d3232bea 415d1e66 0005ba2c  '..V.#+.A].f...,
>  00010 00000000 00000000 82847f95 05070201  ................
>  00020 4c696e75 782d322e 342e3138 00000000  Linux-2.4.18....

What's the result of "imi 00010000" on the  target  and  "mkimage  -l
<your_image_file>"  on the ost? I guess that "imi" reports a checksum
error?

> I've spoken with the board developer (who also wrote a bootloader for
> the board) and showed him the sdram initialization function, and he said
> it was correct. However, I've got the behavior shown above. Is there
> another reason why this sort of corruption would happen? (btw, using
> 'cu' to download the image into RAM).

There can be many reasons, ranging from a broken serial port on  your
host to RAM errors.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
"The hottest places in Hell are reserved for those who, in  times  of
moral crisis, preserved their neutrality."                    - Dante

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [U-Boot-Users] fishing for ideas
  2004-10-01 17:45 ` Tadas
@ 2004-10-05 14:56   ` Benjamin Collar
  0 siblings, 0 replies; 6+ messages in thread
From: Benjamin Collar @ 2004-10-05 14:56 UTC (permalink / raw)
  To: u-boot

Hi everyone

Thank you for your ideas and suggestions. Turns out, the culprit
was...Baud Rate--set too high.

Argh. Why won't the baud rate leave me alone?

Anyway, we've got a kernel half-booting-then-oopsing now, so we'll just
keep going.

Again, thanks for everyone's help.

Ben

-- 
Benjamin Collar
Siemens AG
CT SE 2
Embedded Linux
089-636-53711

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2004-10-05 14:56 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-10-01 16:03 [U-Boot-Users] fishing for ideas Benjamin Collar
2004-10-01 16:46 ` Frank
2004-10-01 17:45 ` Tadas
2004-10-05 14:56   ` Benjamin Collar
2004-10-01 17:45 ` Wolfgang Denk
  -- strict thread matches above, loose matches on Subject: below --
2004-10-01 16:31 VanBaren, Gerald

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.