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


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

-- 
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]