[U-Boot] more U-boot for Pentium

[Graeme Russ]

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