my work about KBOOT

Dale Schumacher dale.schumacher at
Wed Jun 4 11:32:41 CEST 2008

Hi Xiangfu,

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.

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?

---------- Forwarded message ----------
> From: Werner Almesberger <werner at>
> To: xiangfu <xiangfu at>
> Date: Tue, 3 Jun 2008 20:31:25 -0300
> Subject: Re: my work about KBOOT
> xiangfu wrote:
> > UBOOT very complicated for me.
> Yes, u-boot is complex and a lot of the code isn't nice.
> I'm not entirely sure where you are with your work at the moment, and
> I also don't know how familiar you're already with the tools we use,
> but this is what I'd suggest as the general course of action:
> I think it may be easier if you start with as little code as possible
> and then add what you need. That way, you don't have to worry about
> all the other things u-boot does. Also, you can progress in small
> steps and can check your success after each step.
> I would start with a tiny program that just blinks a LED. You boot
> this program from NAND (through Steppingstone), instead of u-boot.
> This will give you
> - a Makefile that you can understand completely
> - a good understanding of linking and compiler flags
> - knowledge how to access registers
> - experience with using u-boot (from NOR) to place your code into NAND
> Then you can add full CPU initialization (start.S and friends) and
> gradually change this into the NAND loader, which loads a file from
> NAND to DRAM. I wouldn't try to use it to boot the kernel, but just a
> very simple program, such as that LED blinker (now running at a
> different address). This will give you
> - a good understanding of the CPU and DRAM bringup process
> - many opportunities to learn to use OpenOCD for debugging
>  (you'll need this experience later to bring up the kernel)
> Next, you can try to bring up the kernel. This is a big item, but after
> having mastered the previous steps, you'll have the skills to debug it
> step by step. You should treat the kernel just as one big binary. Don't
> worry about user interaction and such yet.
> In order to make the kernel work, you have to:
> - add the initialization that is currently done in u-boot and not
>  in the kernel. I think you should be able to get the kernel to
>  issue printks over the serial port even without this, so you may
>  want to try this first.
> - provide the descriptors that tell it what hardware it runs on, etc.
>  This is a structure called "Arm TAG" or "ATAG".
> - pass a boot parameter line that tells the kernel where the console
>  is.
> Once you get the kernel to do anything at all, you can complete the
> initialization code, add an initramfs, and then you'll have a fully
> functional system. (Which doesn't to much yet, but that's the next
> phase then.)
> The importance here is that you make sure you understand what happens
> at each step. That's why I'm recommending to build that boot loader
> from scratch, and not try to just trim down u-boot.
> If something "just works" but you don't know why, you will have an
> incredibly hard time fixing it if it stops working in the future.
> Also, for building the kernel, don't worry about kboot yet. Just make
> a regular Openmoko kernel and use that one. kboot's build process
> involves the kernel in order to obtain configuration data, but that's
> an issue to worry about much later.
> - Werner
-------------- next part --------------
An HTML attachment was scrubbed...

More information about the openmoko-kernel mailing list