<div class="gmail_quote">Bottom posted. See below</div>
<div class="gmail_quote"> </div>
<div class="gmail_quote">On 28 October 2010 03:00, Peter Stuge <span dir="ltr"><<a href="mailto:peter@stuge.se">peter@stuge.se</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">
<div class="im">ali hagigat wrote:<br>> Where is the first lines of Coreboot to study?<br><br></div>I believe the reset vector code is in src/arch/i386/init/entry.S,<br>and that is followed by code in src/cpu/x86/.<br>

<div class="im"><br><br>> Where do I have to look at in the beginning to understand the<br>> algorithm of Coreboot? What will be the code/data flow?<br><br></div>As you may know from reading documentation, source code and<br>
discussions on this mailing list, the structure of coreboot has<br>evolved a lot, through a couple of generations of code.<br><br>A high level overview is that there are three parts to coreboot;<br>bootblock, romstage and ramstage, executed in that order. When the<br>
ramstage is done it jumps to the payload, which is specifically not<br>a part of coreboot, although both coreboot and payload are stored in<br>the same boot flash.<br><br>The reset vector and some (all?) of cpu/x86/ is part of the<br>
bootblock. The romstage is mainboard specific. The code running from<br>RAM is shared between many mainboards.<br>
<div class="im"><br><br>> Answering to these questions make me return back to the build process<br>> to know the logical relationship of the source code fragments<br><br></div>Unless you are very skilled with the build tools used for coreboot it<br>
is the completely wrong end to start at. You would even be better off<br>looking at the src/ directory structure, than the build system.<br>
<div class="im"><br><br>> and another thing is how and where the source code functions and<br>> fragments have been written(I mean what physical addresses)?<br><br></div>Irrelevant for much of coreboot. It should be obvious that the<br>
bootblock and to some degree also the romstage are quite special<br>pieces of code. You have mentioned that you have previous experience<br>from writing firmware, so you already know that there are a lot of<br>restrictions placed on these parts of the code. That makes them<br>
highly unsuitable starting points for learning about coreboot. It is<br>obviously considerably easier to approach the coreboot codebase from<br>the other end; the code running in RAM.<br>
<div class="im"><br><br>> You say something but it can not be done in practice dear...<br><br></div>It is what I have done, and both on and off this mailing list I've<br>seen and met many other developers who have managed to do it too.<br>

<div class="im"><br><br>> How you are a Coreboot expert while you do not know even what will<br>> make c_start.d?<br><br></div>I didn't say that I am an expert, did I? My point is that even though<br>someone has been involved with coreboot for a fairly long time they<br>
do not neccessarily know every single detail of the codebase.<br><br>In open source projects this is quite common. Collectively the<br>community does know all details, but more rarely will a single<br>developer know every single detail.<br>
<br>The point I have been trying to communicate several times now is that<br>you should stop studying the ins and outs of coreboot and just start<br>applying it!!<br><br>Build it, try it, break it, experiment, fix it, discover some problem<br>
that affects you, and solve that problem! In that process you will<br>gain more understanding about how coreboot works than ever possible<br>through pointless static analysis. The fact that this even needs to<br>be pointed out has alarms going off all over, and may make people<br>
react negatively to questions.<br>
<div class="im"><br><br>> When you start studying the files which will be built for Coreboot<br>> you will face with this dragon very soon.<br><br></div>The point is that you are approaching coreboot from the wrong end.<br>
You would make much more progress by ignoring most of the files<br>involved, until you actually need to change something.<br>
<div class="im"><br><br>> Sometimes a person wants to change a specific part of a source code<br>> and he has a professional manager, while his manager masters the code<br>> perfectly but he needs new changes and hires an engineer and take him<br>
> over some responsibilities. This is one story, but another scenario is<br>> when a person is completely stranger to the code and must understand<br>> the whole project by himself.<br>><br>> He must deal with any thing related to the project from build to the<br>
> internal code, every thing.<br><br></div>My modest experience tells me that with this approach his performance<br>will be extremely poor for a long time, for no good reason.<br><br>An absolutely fundamental requirement for being able to penetrate a<br>
codebase is the ability to quickly determine what parts are<br>significant for a given task, and what parts are not. The build<br>system is usually not significant. Not to belittle what we have in<br>coreboot, it's a nice foundation for the code and the result of much<br>
hard work, but it is just that; a foundation.<br><br>I'll say it one last time: I think you need to start using the code now!<br>
<div>
<div></div>
<div class="h5"><br><br>//Peter<br><br>--<br>coreboot mailing list: <a href="mailto:coreboot@coreboot.org">coreboot@coreboot.org</a><br><a href="http://www.coreboot.org/mailman/listinfo/coreboot" target="_blank">http://www.coreboot.org/mailman/listinfo/coreboot</a><br>
</div></div></blockquote></div>
<div> </div>
<div>Hi,</div>
<div>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.</div>

<div> </div>
<div>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.</div>
<div> </div>
<div>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.</div>

<div> </div>
<div>Regards,</div>
<div>Michael Cassaniti<br></div>