[coreboot] Code flow from reset vector
Viswesh S
viswesh_vichu at yahoo.com
Fri Mar 28 13:28:22 CET 2008
Hi,
I havew some doubts on what you mentioned regarding the flow.
...It is added inline.
Regards,
Viswesh
On Wed, Mar 26, 2008 at 11:47:56PM -0700, Viswesh S wrote:
> > But why are you doing this anyway? Wouldn't it be easier to just
> > look at the source code?
>
> [Viswesh] The source code doesnt give you the functional flow.
It does, but the source code flow is not obvious in v2.
> Taking one example, if we look at entry32.inc, we cant see that the
> next function is fpu_start.
No, but mainboard/*/*/Config.lb is also part of the source code.
Think of it as a macro file that is processed to generate code.
Following mainboardinit entry32.inc there is mainboardinit
cpu_reset.inc and then mainboardinit fpu_enable.inc.
Again, this design is in no way optimal and big improvements have
been made in the new version 3 of coreboot. :)
[Viswesh] If we look at the disassembled code, the flow according to me is that,
from the reset_vector --> _start --> _protected_start --> _fpu_start.
And I dont understand the usage of the config.lb in the build.
Can somebody explain it.
//************** Config.lb for qemu-x86***********************
## Build our 16 bit and 32 bit coreboot entry code
##
mainboardinit cpu/x86/16bit/entry16.inc
mainboardinit cpu/x86/32bit/entry32.inc
ldscript /cpu/x86/16bit/entry16.lds
ldscript /cpu/x86/32bit/entry32.lds
##
## Build our reset vector (This is where coreboot is entered)
##
mainboardinit cpu/x86/16bit/reset16.inc
ldscript /cpu/x86/16bit/reset16.lds
### Should this be in the northbridge code?
mainboardinit arch/i386/lib/cpu_reset.inc
##
## Include an id string (For safe flashing)
##
mainboardinit arch/i386/lib/id.inc
ldscript /arch/i386/lib/id.lds
###
### O.k. We aren't just an intermediary anymore!
###
##
## Setup RAM
##
mainboardinit cpu/x86/fpu/enable_fpu.inc
mainboardinit ./auto.inc
***************************** *********************************
Also anybody has Top2005 Sw for linux ?
Regards,
Viswesh
> If we dump the elf file we can actually see the next function which
> is being called, one of the reasons why I looked at the assembly
> code.
>
> I like to understand the assembly code also, but right now the
> utmost priority is to understand the functional flow.
I understand. But look into Config.lb, or even ask on this list, I
think you will get faster results. :)
> Suppose you modify the linux bios, using linux how do u flash it to
> the chip ?
>
> Do you have in system code for it (or) any tool which does it for
> you.
There is a tool called flashrom in util/flashrom/. Remember to erase
before writing to flash when using it.
> Is it better that I write code to write the coreboot to the bios
> chip.
The flashrom tool already supports a number of flash chips and
chipsets, but if your hardware is unsupported or not working properly
and you add code to make it work, please send a signed-off patch to
the list. (See the Coding guidelines in the wiki.)
//Peter
------------------------------
_______________________________________________
coreboot mailing list
coreboot at coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
End of coreboot Digest, Vol 37, Issue 177
*****************************************
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080328/7981431c/attachment.html>
More information about the coreboot
mailing list