SV: [ECOS] Redboot Load Error

[Henrik Mau]

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