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!
