Kernel notes

== So much confusion indeed ==

On the "new project", finally.  I returned the last piece of hardware,
and now I'm fully on the new task, which is very generic, about
providing a boards support package for ...well, the board.  What
board?  The board does not exist quite yet, but we have a bunch of
ways of simulating it.  Nobody seems to know all the details, or
maybe I didn't ask to the right people.

One of these ways is a quite big SOC, that I finally collected
today.  Who to ask about it?  One dude is working from home, another
one is home sick.

The board has a SD card, and I've got instructions on how to flash
it.  I got a clue on *what* to flash on it after lots of research,
and asking around.

I've got the SD card, I've got the software.  But I've got only a
micro-sd hole on my laptop, while this beast needs a regular SD.
Where do I get an adapter, or a writer, or *anything*?  Nobody
knows.

It looks like "nobody knows" is the new mantra.

== Kernel ==

Exploring the kernel, with the goal of figuring out how the devtree
ends up influencing the devices, and eventually results in /dev/uioX
being available (in my case).

- I did not yet find any explicit reference to this, but setup_arch
seems to be the name of the generic entry point for architecture
dependent initialization.  It is implemented by all arch/*/kernel/setup.c

- ARM: the device tree seems to come from a global pointer named
__fdt_pointer. the pointer is marked as __initdata, which means
that it ends up in the '.init.data' section (of the ELF).  According
to the comment, the section is freed after initialization.  Clever.

- Core functionalities found on my way (possibly interesting in
  future):
 - fixmap.h - compile-time virtual memory allocation
 - memblock.h
 - drivers/of - device tree and open-firmware support

- drivers/of/fdt.c
Flat device tree support, from open-firmware A global structure
acts as a container for properties.  The structure seems to be set
read-only after a first initialization/fixup phase (which I think
has to do with alignment).

- on device tree the machine name is first sought as thee 'model'
property, and then with 'compatible'

It might be interesting to have a qemu run, with device tree scanning,
erniched with some printfs!