On Thu, Jun 30, 2011 at 12:08 PM, Raleigh Boulware <r_boulw...@hotmail.com> wrote: > > >> Date: Thu, 30 Jun 2011 11:58:55 +1000 >> Subject: Re: more U-boot for Pentium >> From: graeme.r...@gmail.com >> To: r_boulw...@hotmail.com >> CC: u-boot@lists.denx.de >> >> On Thu, Jun 30, 2011 at 11:54 AM, Raleigh Boulware >> <r_boulw...@hotmail.com> wrote: >> > >> > >> >> Hi Raleigh, >> >> >> >> On Thu, Jun 30, 2011 at 11:16 AM, Raleigh Boulware >> >> <r_boulw...@hotmail.com> wrote: >> >> > I have been going through the code and I have stumbled accross a file >> >> > called >> >> > sc520_car.S that has something called Cache as ram. I am guessing >> >> > that >> >> > this >> >> > is something special for the sc520 correct? Why was there a need to >> >> > do >> >> > this? >> >> > Why was the Cache used like ram in the boot process? >> >> >> >> Cache-As-RAM allows the CPU cache to be used as regular RAM while >> >> U-Boot >> >> is running from Flash before the onboard SDRAM has been initialised. >> >> This >> >> allows a temporary stack, and therefore C runtime environment to be >> >> created. This this allows you to write the SDRAM initialisation code in >> >> C >> >> which is a lot easier than assembler. >> >> >> > So this is pnly used if we want to setup the SDRAM controller in C code >> >> More that just that - It is used for the duration of board_init_f() which >> may include all manner of peripheral initialisation prior to relocating >> U-Boot into RAM. > Is it possible to just set up the DDR controller early in the process in > assembler to avoid doing a Cache as ram? The reason I ask is because I might > have trouble getting other mother boards to do this.
Yes, you can setup the SDRAM controller in assembler. This would occur in place of the Cache-As-RAM init you see for the sc520. You also need to determine the memory size while you are at it (at a pinch, you can hard- code the memory size initially) > > Als I was looking at 2 rutines. board_init_r() and board_init_f(). It > appears that the code goes from assmbler to this board_init_f() then back to > assembler then to board_init_r(). I am not sure of the reason for this. board_init_f() runs from Flash - It is responsible for getting everything setup ready to run U-Boot from RAM. The last thing board_init_f does is copy U-Boot from Flash into RAM and perform the relocation fixups. board_init_f() then calls back into assembler at which point a new stack is created in RAM before jumping to the in-RAM copy of board_init_r(). Once inside board_init_r(), the Flash is never again accessed unless you save the environment or erase it and write a new U-Boot binary (i.e. you can physically remove the Flash chip and U-Boot will still run fine) Regards, Graeme _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot