> -----Original Message----- > From: u-boot-boun...@lists.denx.de > [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Juergen Schindele > Sent: Friday, February 26, 2010 8:36 PM > To: Wolfgang Wegner > Cc: u-boot@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.schind...@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 . . _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot