The only rule for building c_start.o from c_start.S is the following in build/arch/i386/lib/c_start.d: build/arch/i386/lib/c_start.o: src/arch/i386/lib/c_start.S \ /root/build/coreboot/coreboot-v4/build/config.h \ src/include/cpu/x86/post_code.h The question is that what rule is making the file, c_start.d itself?
ali hagigat wrote:
what rule is making the file, c_start.d itself?
It's very strange that you are so obsessed with the build system so many months after starting to look at coreboot.
I first looked at coreboot nearly 10 years ago, and while I am not super active in the codebase there are still *so* many other *actual* things to work on and learn about *in the code*.
You've mentioned that you want to study coreboot before you can work with it, but I would recommend that you stop studying the build system for now and look more at what coreboot *code* is actually doing. This is especially true if you are not already very skilled with the GNU toolchain and make, because building coreboot can sometimes require special tricks.
To also answer your question, I suggest that you study the output from
make V=1
and see which command creates the c_start.d file. Then you could probably locate it within the Makefiles.
//Peter
agree with peter. if you want to learn more about the building process of opensource project. i think coreboot is too complex for the beginner. You can choose some small project.
PS: the file %.d is created by gcc with the parameter -MMD, if you want to know about this, check the gcc man page.
2010/10/26 Peter Stuge peter@stuge.se
ali hagigat wrote:
what rule is making the file, c_start.d itself?
It's very strange that you are so obsessed with the build system so many months after starting to look at coreboot.
I first looked at coreboot nearly 10 years ago, and while I am not super active in the codebase there are still *so* many other *actual* things to work on and learn about *in the code*.
You've mentioned that you want to study coreboot before you can work with it, but I would recommend that you stop studying the build system for now and look more at what coreboot *code* is actually doing. This is especially true if you are not already very skilled with the GNU toolchain and make, because building coreboot can sometimes require special tricks.
To also answer your question, I suggest that you study the output from
make V=1
and see which command creates the c_start.d file. Then you could probably locate it within the Makefiles.
//Peter
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Thank you Peter to advice me to study the Coreboot source code and learn new things (my ultimate purpose is the same dear) but simple question is this:
Where is the first lines of Coreboot to study? Where do I have to look at in the beginning to understand the algorithm of Coreboot? What will be the code/data flow?
Answering to these questions make me return back to the build process to know the logical relationship of the source code fragments and another thing is how and where the source code functions and fragments have been written(I mean what physical addresses)?
You say something but it can not be done in practice dear...
How you are a Coreboot expert while you do not know even what will make c_start.d? When you start studying the files which will be built for Coreboot you will face with this dragon very soon.
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.
Best Regards
On Tue, Oct 26, 2010 at 1:51 PM, Peter Stuge peter@stuge.se wrote:
ali hagigat wrote:
what rule is making the file, c_start.d itself?
It's very strange that you are so obsessed with the build system so many months after starting to look at coreboot.
I first looked at coreboot nearly 10 years ago, and while I am not super active in the codebase there are still *so* many other *actual* things to work on and learn about *in the code*.
You've mentioned that you want to study coreboot before you can work with it, but I would recommend that you stop studying the build system for now and look more at what coreboot *code* is actually doing. This is especially true if you are not already very skilled with the GNU toolchain and make, because building coreboot can sometimes require special tricks.
To also answer your question, I suggest that you study the output from
make V=1
and see which command creates the c_start.d file. Then you could probably locate it within the Makefiles.
//Peter
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
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
Bottom posted. See below
On 28 October 2010 03:00, Peter Stuge peter@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@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
-
ali hagigat -
Michael Cassaniti -
Peter Stuge -
Qing Pei Wang