[U-Boot] boot from ram on rd-6281-a

[Prafulla Wadaskar]

> -----Original Message-----
> From: u-boot-bounces at lists.denx.de 
> [mailto:u-boot-bounces at lists.denx.de] On Behalf Of Juergen Schindele
> Sent: Friday, February 26, 2010 8:36 PM
> To: Wolfgang Wegner
> Cc: u-boot at lists.denx.de
> Subject: Re: [U-Boot] boot from ram on rd-6281-a
> 
> Am Freitag, 26. Februar 2010 schrieben Sie:
> > Dear Juergen,
> > 
> > On Fri, Feb 26, 2010 at 12:16:22PM +0100, Juergen Schindele wrote:
> > > Am Freitag, 26. Februar 2010 schrieb Wolfgang Denk:
> > > > Dear Juergen Schindele,
> > > > 
> > > > In message <201002261056.32502.schindele at nentec.de> you wrote:
> > > > >
> > > > > i need a different bootloader than the one installed.
> > > > > so i tried to develop a private one by loading it to RAM.
> > > > > So i modified the TEXT_BASE = 0x00400000
> > > > > to not collide with the installed one.
> > > > 
> > > > This is not enough. You must also make sure not to try 
> to perform all
> > > > the low level initializations again that have already been done.
> > > I know that, but SKIP_LOW_LEVEL_INIT is defined because 
> > > register init is done with kirkwood boot header for booting from
> > > SPI/NAND-Flash. I dont see other blocking points. :-(
> > > i tried to skip relocate too but it did not help !
> > 
> > I have absolutely no experience concerning kirkwood, but 
> did the same
> > for coldfire for running U-Boot as the flasher application started
> > from the debugger...
> > IIRC there were three places I had to change for coldfire:
> > - low-level init: do not put the vector table at the beginning
> >   of code (probably better: initialize it in the proper place?)
> > - leave the vector base register as it is (should be set up
> >   properly by first loader/debugger, and U-Boot does not use
> >   interrupts)
> > - the cpu speed detection/setting code was basically 
> switched back to
> >   detection for CONFIG_MONITOR_IS_IN_RAM because it involved putting
> >   the RAM to self-refresh, which is obviously not possible 
> when running
> >   from it
> > 
> > (For Coldfire, a special case was that I had to disable monitor
> > protection manually because the standard condition fails due to the
> > memory layout.)
> Thanks for your hint. It lead me to comment out "kirkwood_mpp_conf"
> in function "board_init" and now it works quite great like expected.
> In my understanding the mpp configuration of  rd6281a is buggy !?

Hi Jürgen Schindele

Good to know that u-boot from RAM works well for you

The "Kirkwood_mpp_config" reads mpp registers and writes them back as per configuration provided in kwmpp_cponfig.

If the config you are providing for your board are different, certainly the things may not work, but if they are same, I don't see any reason it should not work.

Even in case of standard u-boot.kwb booting from SPI/NAND the DRAM initialization is done by bootROM header first and then mpp config is done.

So I don't think it's buggy,
if you further have some detailed findings with some explaination, certainly I would like to patch to improve it.

Regards..
Prafulla . .