[U-Boot] Want to study U-Boot code
Javier Martinez Canillas
javier at dowhile0.org
Sat Jan 26 15:11:29 CET 2013
On Sat, Jan 26, 2013 at 2:07 PM, Woody Wu <narkewoody at gmail.com> wrote:
> 在 2013-1-26 AM5:27,"Robert P. J. Day" <rpjday at crashcourse.ca>写道:
>>
>> On Fri, 25 Jan 2013, Wolfgang Denk wrote:
>>
>> > Dear Woody Wu,
>> >
>> > In message <CAAsE_ue4VffAioQWzHPpyOZmzoFk9E5S7jj2+2BZuiK=
> C5yXtA at 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
More information about the U-Boot
mailing list