This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: SV: Redboot Load Error




Daniel Morris wrote:

On Fri, Jun 25, 2004 at 04:11:51PM +0100, Henrik Mau wrote:


Gary Thomas wrote:



On Fri, 2004-06-25 at 06:33, Henrik Mau wrote:




Gary Thomas wrote:





... back on the mailing list so that all may benefit.

On Fri, 2004-06-25 at 04:00, Henrik Mau wrote:






Gary Thomas wrote:







On Thu, 2004-06-24 at 14:06, Henrik Mau wrote:














When loading an application using the load command in Redboot the








first








400 addresses in the srec file do not get copied to the destination
memory. That is, what is listed in the srec file to reside in








0x40400






Ah, but according to the file you sent, the data *does* start at 0x40000. Looking carefully at the first few records:







S012000074776F746872656164732E73726563CD






This record holds the name of the file "twothreads.srec"







S21404000018F09FE518F09FE518F09FE518F09FE5B7






This record loads data into 0x040000..0x04000F







S21404001018F09FE50000000018F09FE518F09FE533






This one loads data into 0x040010..0x04001F

The basic format of these records is:
S21404000018F09FE518F09FE518F09FE518F09FE5B7

S2 - Loadable data with 3 byte address
14 - Record is 20 bytes (0x14) long
040000 - Starting address of data
18F09FE518F09FE518F09FE518F09FE5 - 16 bytes of data in hex
B7 - checksum for the record

Why did you think the data should be at 0x40400?





Sorry, maybe I wasn't being very clear.
The data does get written to 0x40000, however it is not

S21404000018F09FE518F09FE518F09FE518F09FE5B7

that gets written to 0x40000, but instead the data that should be in 0x40400.
I have checked some of the data and it seems as if 0x40000 - 0x403ff gets overwritten with the data from 0x40400 - 0x407ff






The 'load' command will only put data where the S-records tell it (in the absence of the "-b" option, which you don't need). There may be
something else wrong with your platform.


Have you done simple tests, like pre-fill memory, then load and then
dump to the screen?  e.g.
RedBoot> mf -b 0x40000 -l 0x10000 -p 0xDEADDEAD -4
RedBoot> lo -m yM
RedBoot> du -b 0x40000 -l 0x80
RedBoot> du -b 0x40400 -l 0x80

or, checking other memory mappings:
RedBoot> lo -b 0x100000 -m yM
RedBoot> lo -m yM
RedBoot> mcm -s 0x40000 -d 0x100000 -l 0x800

Maybe these can give a hint what's happening.



I get the same values written to the two different memory positions.

I changed the checksum in

S21404000018F09FE518F09FE518F09FE518F09FE5B7


to see if the buffer somehow got overwritten before it had a chance to deal with the first 40 lines, and I received a checksum error. So it seems like the lines are being processed and then later on overwritten.



There aren't other entries from your srec overwriting this area? Have
you tried sorting the srec and manually checking? You could quickly check with something like 'sort -k1.5,1.10 file.srec |less'.


(Obviously modify/be aware of other S3 etc record types).

Daniel


It turns out that the SDRAM status and control register is not set and contain default values that dont match the SDRAM module installed. I have made a workaround that enables me to use the exact module I am using, but a proper detection and initialization would be a nice feature to encorporate in Redboot.

Henrik


-- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]