using kboot for booting

[Werner Almesberger]

Xiangfu Liu wrote:
> when i google KBOOT
> the first web is kboot.sf.net : )

Good. So Google still gets it right ;-)

> and i read you plan carefully and i  started to make my own plan base on
> this

By the way, Wolfgang asked me a few days ago for a plan how to structure
this work. I've attached it below (slightly edited for context).

> if we  focus on the freerunner or both of freerunner and  neo1973?

I'd suggest to start with booting the GTA02 (FreeRunner) from NAND,
and then extend this to booting from SD. In the end, we'll need it for
booting the GTA04 from SD, but it will take a while until useful
prototype hardware will be available.

- Werner

---------------------------------- cut here -----------------------------------

Wolfgang Spraul wrote:
> Another question: Do you think 2 people can co-work on the u-boot  
> replacement task? Or is this better suited for just 1 person?

There are many tasks that can be parallelized:

- must-have and specific to Openmoko:

  - NAND loader (similar for all GTA)
  - SD loader for GTA04 (note: the MMC interface of 6400 is quite different
    from 2410 or 2442)
  - move low-level init into kernel ("stand-alone kernel")
  - system integration (i.e., smooth the edges)
  - design fastpath concept, implement in first-stage loaders
  - verify 100mA path

- nice to have and specific to Openmoko:

  - SD loader for GTA01
  - SD loader for GTA02

- not specific to Openmoko, connected to other projects:

  - make better use of OE in kboot
  - GUI or menu
  - shrink kboot kernel and initramfs to fit into GTA02 NOR (2MB)

- not specific to Openmoko, work inside kboot:

  - rewrite kboot shell in C
  - assorted kboot improvements, such as switching of rootfs context

The ones not specific to Openmoko are more fuzzily defined and involve
long-term design decisions of kboot. So I'd like to take care of these
myself. The ones inside kboot I'd implement myself, for those connected
to other projects, I'd at least oversee how this work is combined.

None of these "general" changes are time-critical for having a prototype.

The other stuff has more narrowly defined goals. Implementing it properly
is critical for system stability, so Andy and I will be very picky about
the quality, but that will only make this better as a "getting started"
experience. Implementing the first-stage boot loaders will also be a
good way to gain familiarity with the lowest-level parts of the
hardware.

Since the basic CPU bringup can be shared, I'd suggest to do one
low-level loader first and then do the other(s).

Since all of the first-stage loaders will share the basic CPU bringup
(which is similar among the CPUs) and the fastpath logic, it would be
good to have them all in a single tree, in which the respective modules
are linked to build the actual loaders.

Organizing that code properly will require some experience as a
software architect, so the NAND loader should be done by someone who
will keep the longer-term evolution of that code in mind right from
the start. (Or else we'll get an army of silly little branches.)

There's a lot to learn about CPU initialization, so I think they'll
have to spend at least a week in data sheets and schematics before any
serious development can happen. When I get back from my vacation, we can
see how far they've come, and plan the next steps.

The first two tasks are the NAND loader and moving low-level init into
the kernel. The latter will be subject to the usual kernel code quality
standards. Also Matt has raised a few very good points about how cryptic
some of our current code there is (see the GPGCON example).

In principle, both tasks could be worked on in parallel, but the kernel
changes can only be usefully tested once the first-stage loader is
written. (A little bit of testing of the modified kernel could be done
from u-boot, though.)

The system integration work can be done quite in parallel, by just
running kboot user space from our existing kernel booted by u-boot.
There's also a "dry run" mode in kboot that skips most of the system
setup, so one can run it basically like any other application on a
normal system.

So I'd make this the first two tasks:

1) develop the NAND first-stage loader on GTA02, then adapt the
   low-level kernel init code 

2) bring up kboot user space on a GTA02 and start integration there
   (i.e., make sure the network comes up, that kboot finds the
   configuration files in the rootfs, and all that)

Point 2) is less time-critical. When 1) is done, one can already boot
into Linux, just the handling of the system is a bit quirky. After this
initial obstacle is mastered, work can be very smooth and incremental.

If you think both can work together very closely, basically in "two
developers, one screen" mode, then that might help to get the low-level
init right. As I said, there are lots of nasty little details there,
scattered over the 2442, the PMU, and the circuit around them, and four
eyes see more than two. They'll also have to get very intimate with
JTAG and all this.

- Werner