my work about KBOOT

[Werner Almesberger]

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