[coreboot] How the file, c_start.d is made?

[Michael Cassaniti]

Bottom posted. See below

On 28 October 2010 03:00, Peter Stuge <peter at stuge.se> wrote:

> 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
> applying it!!
>
> 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!
>
>
> //Peter
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>

Hi,
This information would be quite good to put on the wiki. The modular process
coreboot follows from reset vector to payload boot would be nice. Even
though it is strictly not necessary to know this information to work with
coreboot, I believe it may make new users more comfortable, especially when
faced with the question of what part of the process I need to change.

I think having the overview diagram coupled with a statement saying that
most development takes place in these modules (insert module names here)
would help a new developer to realise where they are starting.

Please don't take this as a discredit of your argument. I do understand
where you are coming from. It is reasonable that you only need to
concentrate on mainboard specific code until something form elsewhere in the
source code tree affects your code.

Regards,
Michael Cassaniti
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20101028/6c3e6341/attachment.html>