<div class="gmail_quote"><div>Hi Xiangfu,<br><br>I would like to follow along with the steps Werner suggested. I want to mirror what you are doing. If possible, I would like to do this using QEMU, as I do not yet have a Freerunner.<br>
<br>Werner, et. al. -- please forgive my ignorance. Can you give me a pointer to help me bootstrap (pardon the pun) this effort? I'm not sure how to obtain "start.S and friends", or where to look for register/memory mappings for the Freerunner. Perhaps as Xiangfu makes progress along the lines you recommended, I could follow along in his footsteps. Is there a good way for me to see snapshots of his progress?<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">---------- Forwarded message ----------<br>From: Werner Almesberger <<a href="mailto:werner@openmoko.org">werner@openmoko.org</a>><br>
To: xiangfu <<a href="mailto:xiangfu@openmoko.org">xiangfu@openmoko.org</a>><br>Date: Tue, 3 Jun 2008 20:31:25 -0300<br>Subject: Re: my work about KBOOT<br>xiangfu wrote:<br>
> UBOOT very complicated for me.<br>
<br>
Yes, u-boot is complex and a lot of the code isn't nice.<br>
<br>
I'm not entirely sure where you are with your work at the moment, and<br>
I also don't know how familiar you're already with the tools we use,<br>
but this is what I'd suggest as the general course of action:<br>
<br>
I think it may be easier if you start with as little code as possible<br>
and then add what you need. That way, you don't have to worry about<br>
all the other things u-boot does. Also, you can progress in small<br>
steps and can check your success after each step.<br>
<br>
I would start with a tiny program that just blinks a LED. You boot<br>
this program from NAND (through Steppingstone), instead of u-boot.<br>
This will give you<br>
<br>
- a Makefile that you can understand completely<br>
<br>
- a good understanding of linking and compiler flags<br>
<br>
- knowledge how to access registers<br>
<br>
- experience with using u-boot (from NOR) to place your code into NAND<br>
<br>
Then you can add full CPU initialization (start.S and friends) and<br>
gradually change this into the NAND loader, which loads a file from<br>
NAND to DRAM. I wouldn't try to use it to boot the kernel, but just a<br>
very simple program, such as that LED blinker (now running at a<br>
different address). This will give you<br>
<br>
- a good understanding of the CPU and DRAM bringup process<br>
<br>
- many opportunities to learn to use OpenOCD for debugging<br>
(you'll need this experience later to bring up the kernel)<br>
<br>
Next, you can try to bring up the kernel. This is a big item, but after<br>
having mastered the previous steps, you'll have the skills to debug it<br>
step by step. You should treat the kernel just as one big binary. Don't<br>
worry about user interaction and such yet.<br>
<br>
In order to make the kernel work, you have to:<br>
<br>
- add the initialization that is currently done in u-boot and not<br>
in the kernel. I think you should be able to get the kernel to<br>
issue printks over the serial port even without this, so you may<br>
want to try this first.<br>
<br>
- provide the descriptors that tell it what hardware it runs on, etc.<br>
This is a structure called "Arm TAG" or "ATAG".<br>
<br>
- pass a boot parameter line that tells the kernel where the console<br>
is.<br>
<br>
Once you get the kernel to do anything at all, you can complete the<br>
initialization code, add an initramfs, and then you'll have a fully<br>
functional system. (Which doesn't to much yet, but that's the next<br>
phase then.)<br>
<br>
The importance here is that you make sure you understand what happens<br>
at each step. That's why I'm recommending to build that boot loader<br>
from scratch, and not try to just trim down u-boot.<br>
<br>
If something "just works" but you don't know why, you will have an<br>
incredibly hard time fixing it if it stops working in the future.<br>
<br>
Also, for building the kernel, don't worry about kboot yet. Just make<br>
a regular Openmoko kernel and use that one. kboot's build process<br>
involves the kernel in order to obtain configuration data, but that's<br>
an issue to worry about much later.<br>
<br>
- Werner<br>
</blockquote></div><br>