my work about KBOOT

xiangfu xiangfu at
Wed Jun 4 02:54:33 CEST 2008

Thanks Werner !  
i will report progress.

Werner Almesberger wrote:
> 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

More information about the openmoko-kernel mailing list