CSST's load to ram feature

CSST's load to ram feature

[Juha Kuikka]

Hi,

TI's CSST too can, in addition to burning to flash memory, load binary
directly to RAM and execute it from there.

This feature works fine with the included example binaries but I am unable
to use it to run x-loader or u-boot.

I'm suspecting x-loader/u-boot do not work because they expect the system to
be in a certain state but it is not.

Has anybody else had this problem and more importantly found a solution to
it?

Thanks,
 Juha

-- 
Madness takes it's toll. Please have exact change.

RE: CSST's load to ram feature

[Woodruff, Richard]

 > TI's CSST too can, in addition to burning to flash memory, 
> load binary directly to RAM and execute it from there.
> 
> This feature works fine with the included example binaries 
> but I am unable to use it to run x-loader or u-boot.
> 
> I'm suspecting x-loader/u-boot do not work because they 
> expect the system to be in a certain state but it is not.
> 
> Has anybody else had this problem and more importantly found 
> a solution to it?


I've downloaded x-loader into RAM via lauterbach (or u-boot) and have
gotten it to work.

I did this on the 2420-H4 and 3430-SDP.  I seem to recall fixing some
relocation bugs which were introduced into 2430 which may have stopped
it from working.  If you look at the 3430 xloader I think you can make
it work.  The issue was in the initial assembly in cpu/arm1136.  Now if
it works with CSST is something else.

Regards,
Richard W.

Re: CSST's load to ram feature

[Nishanth Menon]

Woodruff, Richard stated on 8/23/2007 8:31 PM:
>>
>> This feature works fine with the included example binaries 
>> but I am unable to use it to run x-loader or u-boot.
>>
>> I'm suspecting x-loader/u-boot do not work because they 
>> expect the system to be in a certain state but it is not.
>>
One possible condition is clock configurations. x-loader and u-boot
might expect a 19.2 Mhz sys clock, and configures accordginly while
possibly the uboot expects something like 26Meg or something.. am just
guessing here.. in theory, if every single configuration is being done
by the u-boot + x-loader combination and if the image is raw, all the
execute option does is to hand over control to the image, and this
should allow it to work.  As Richard mentioned, Lauterbach etc might
give you a better controlled environment for uboot and x-loader to work in.

Regards,
Nishanth Menon

RE: CSST's load to ram feature

[Woodruff, Richard]

> One possible condition is clock configurations. x-loader and 
> u-boot might expect a 19.2 Mhz sys clock, and configures 
> accordingly while possibly the uboot expects something like 
> 26Meg or something.. am just guessing here.. in theory, if 
> every single configuration is being done by the u-boot + 
> x-loader combination and if the image is raw, all the execute 
> option does is to hand over control to the image, and this 
> should allow it to work.  As Richard mentioned, Lauterbach 
> etc might give you a better controlled environment for uboot 
> and x-loader to work in.

100% correct ;)

For our x-loader buids we even have soft-links from xloader into u-boot
to try and get around some of this.  They as currently implemented must
be matched.

Regards,
Richard W.