My thanks for your saying, Javier. I will be starting from reading the README and begin search through the code. When I get further question, I will come back here. Thahks again.
-woody
On Sat, Jan 26, 2013 at 03:11:29PM +0100, Javier Martinez Canillas wrote:
On Sat, Jan 26, 2013 at 2:07 PM, Woody Wu narkewoody@gmail.com wrote:
??? 2013-1-26 AM5:27???"Robert P. J. Day" rpjday@crashcourse.ca?????????
On Fri, 25 Jan 2013, Wolfgang Denk wrote:
Dear Woody Wu,
In message <CAAsE_ue4VffAioQWzHPpyOZmzoFk9E5S7jj2+2BZuiK=
C5yXtA@mail.gmail.com> you wrote:
I want to firstly get a picture to basically understand how u-boot work, especially on an ARM9 based board. I think not everyone who want to understand u-boot has to read the full code. Thank.
This depends on your definition of "understanding". On a highlevel, you might start with reaing and digesting the manual, eventually trying out how U-Boot works on some (real or emulated) board.
if i can jump in, a good way to start playing is to configure and build for the "sandbox" architecture so you can run it on your x86 system. for the benefit of a couple friends, i whipped together a wiki page for that here:
http://www.crashcourse.ca/wiki/index.php/U-Boot_sandbox
very simple but enough to get you started, and you can match up running the commands with the underlying code.
rday
Sandbox looks amazing! Thanks share me with this info. But i still wondering that if u-boot doesnt have any book or document explaining how it work and how it organized, how pepople can join its development?
Hello Woody,
I recommend you to start with the README file since it gives you a high level overview of U-Boot and some very good specifics too.
Since you are asking about U-Boot source code organization specifically, you can take a look at the "Directory Hierarchy" section of the README file.
But as others stated before, you should first narrow your search to an area that interests you. I found that "scratching your own itch" is the best way to learn.
There is no documentation that can replace the source code itself, remember that a good documentation shouldn't say how thinks are made (for that you have the code) but why things were made in a certain way and the design decisions behind that.
Finally, if you think that the documentation is not enough, feel free to send patches to improve that :-)
As Confusios said "I heard and I forget. I see and I remember. I do and I understand"
Hope it helps, Javier