[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@...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
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@...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@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
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@...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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
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
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@...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
participants (4)
-
Benjamin Collar -
Frank -
Tadas -
Wolfgang Denk