[coreboot] How the file, c_start.d is made?
peter at stuge.se
Wed Oct 27 18:00:38 CEST 2010
ali hagigat wrote:
> Where is the first lines of Coreboot to study?
I believe the reset vector code is in src/arch/i386/init/entry.S,
and that is followed by code in src/cpu/x86/.
> Where do I have to look at in the beginning to understand the
> algorithm of Coreboot? What will be the code/data flow?
As you may know from reading documentation, source code and
discussions on this mailing list, the structure of coreboot has
evolved a lot, through a couple of generations of code.
A high level overview is that there are three parts to coreboot;
bootblock, romstage and ramstage, executed in that order. When the
ramstage is done it jumps to the payload, which is specifically not
a part of coreboot, although both coreboot and payload are stored in
the same boot flash.
The reset vector and some (all?) of cpu/x86/ is part of the
bootblock. The romstage is mainboard specific. The code running from
RAM is shared between many mainboards.
> Answering to these questions make me return back to the build process
> to know the logical relationship of the source code fragments
Unless you are very skilled with the build tools used for coreboot it
is the completely wrong end to start at. You would even be better off
looking at the src/ directory structure, than the build system.
> and another thing is how and where the source code functions and
> fragments have been written(I mean what physical addresses)?
Irrelevant for much of coreboot. It should be obvious that the
bootblock and to some degree also the romstage are quite special
pieces of code. You have mentioned that you have previous experience
from writing firmware, so you already know that there are a lot of
restrictions placed on these parts of the code. That makes them
highly unsuitable starting points for learning about coreboot. It is
obviously considerably easier to approach the coreboot codebase from
the other end; the code running in RAM.
> You say something but it can not be done in practice dear...
It is what I have done, and both on and off this mailing list I've
seen and met many other developers who have managed to do it too.
> How you are a Coreboot expert while you do not know even what will
> make c_start.d?
I didn't say that I am an expert, did I? My point is that even though
someone has been involved with coreboot for a fairly long time they
do not neccessarily know every single detail of the codebase.
In open source projects this is quite common. Collectively the
community does know all details, but more rarely will a single
developer know every single detail.
The point I have been trying to communicate several times now is that
you should stop studying the ins and outs of coreboot and just start
Build it, try it, break it, experiment, fix it, discover some problem
that affects you, and solve that problem! In that process you will
gain more understanding about how coreboot works than ever possible
through pointless static analysis. The fact that this even needs to
be pointed out has alarms going off all over, and may make people
react negatively to questions.
> When you start studying the files which will be built for Coreboot
> you will face with this dragon very soon.
The point is that you are approaching coreboot from the wrong end.
You would make much more progress by ignoring most of the files
involved, until you actually need to change something.
> Sometimes a person wants to change a specific part of a source code
> and he has a professional manager, while his manager masters the code
> perfectly but he needs new changes and hires an engineer and take him
> over some responsibilities. This is one story, but another scenario is
> when a person is completely stranger to the code and must understand
> the whole project by himself.
> He must deal with any thing related to the project from build to the
> internal code, every thing.
My modest experience tells me that with this approach his performance
will be extremely poor for a long time, for no good reason.
An absolutely fundamental requirement for being able to penetrate a
codebase is the ability to quickly determine what parts are
significant for a given task, and what parts are not. The build
system is usually not significant. Not to belittle what we have in
coreboot, it's a nice foundation for the code and the result of much
hard work, but it is just that; a foundation.
I'll say it one last time: I think you need to start using the code now!
More information about the coreboot