On Thu, Jun 30, 2011 at 12:08 PM, Raleigh Boulware r_boulware@hotmail.com wrote:
Date: Thu, 30 Jun 2011 11:58:55 +1000 Subject: Re: more U-boot for Pentium From: graeme.russ@gmail.com To: r_boulware@hotmail.com CC: u-boot@lists.denx.de
On Thu, Jun 30, 2011 at 11:54 AM, Raleigh Boulware r_boulware@hotmail.com wrote:
Hi Raleigh,
On Thu, Jun 30, 2011 at 11:16 AM, Raleigh Boulware r_boulware@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