Dear Stephen Warren,
On 08/08/2012 05:42 AM, Marek Vasut wrote:
From: Marek Vasut marek.vasut@gmail.com
This patch contains UDM-design.txt, which is document containing general description of the driver model. The remaining files contains descriptions of conversion process of particular subsystems.
diff --git a/doc/driver-model/UDM-design.txt b/doc/driver-model/UDM-design.txt
+II) Driver core initialization stages +-------------------------------------
+The drivers have to be initialized in two stages, since the U-Boot bootloader +runs in two stages itself. The first stage is the one which is executed before +the bootloader itself is relocated. The second stage then happens after +relocation.
- First stage
- The first stage runs after the bootloader did very basic hardware
init. This + means the stack pointer was configured, caches disabled and that's about it. + The problem with this part is the memory management isn't running at all. To + make things even worse, at this point, the RAM is still likely uninitialized + and therefore unavailable.
- Second stage
- At this stage, the bootloader has initialized RAM and is running from
it's + final location. Dynamic memory allocations are working at this point. Most of + the driver initialization is executed here.
Given the above descriptions of the two stages, ...
+III) The drivers +----------------
- The structure of a driver
- The driver will contain a structure located in a separate section,
which + will allow linker to create a list of compiled-in drivers at compile time. + Let's call this list "driver_list".
- struct driver __attribute__((section(driver_list))) {
- /* The name of the driver */
- char name[STATIC_CONFIG_DRIVER_NAME_LENGTH];
- /*
* This function should connect this driver with cores it depends onand + * with other drivers, likely bus drivers
*/- int (*bind)(struct instance *i);
... the comments here should probably say which stage each function will be run at.
The drivers must be agnostic to where they're executed
- /* This function actually initializes the hardware. */
- int (*probe)(struct instance *i);
- /*
* The function of the driver called when U-Boot finishedrelocation. + * This is particularly important to eg. move pointers to DMA buffers + * and such from the location before relocation to their final location. + */
- int (*reloc)(struct instance *i);
The need for this function implies that some other functions (both bind and probe?) are to be called before relocation.
They can be called after reloc too.
Isn't the pre-relocation environment rather strict
Yes
and hence this will require a bunch of changes to driver code to initialize differently?
No
Why not just initialize everything after relocation; IIRC, that's how most things are initialized now, isn't it?
You want eg. i2c bus running before relocation to init your DRAM controller. Or serial console for debug output.
Related, if you're intending to allow drivers to be loaded from e.g. the filesystem later
Not now, but we keep that in mind. Btw. (!) we're writing a bootloader here, not an operating system.
that will happen after relocation. There will then be a discrepancy between the environment where bind/probe get run for a built-in driver vs. a dynamically loaded driver.
Will there?
Best regards, Marek Vasut