Dear Marek Vasut,
In message 201009201205.41037.marek.vasut@gmail.com you wrote:
most of the readers here probably noticed, there are various forks of U-Boot bootloader floating around the net. The development model there is quite closed and certainly not community driven, on the other hand, they have neat driver model.
You are speaking about barebox, right? [I am not aware of another fork with a driver model.]
- Start with ethernet subsystem
It seems to be quite ready for conversion of this scale. Besides it'd be easy to prove multiple instances of ethernet device work with the driver model.
Indeed ethernet seems to make sense; eventually followed by serial, as this will quickly show some of the challenges (i. e. driver support in the restricted environment before relocation). Block devices (IDE, SDCard/MMC, USB, eventually also NAND etc.) could need some unification as well.
- Create an universal driver model:
The driver will have usual .probe function, which will have some argument of type "void *" to it's driver data. This way we can pass it's base address for example instead of #defining it. Very similar to linux kernel.
Instead of picking out a single function, we should rather discuss the whole interface. I guess the stating point would be the current BB implementation?
- We need some "device tree"
To know, what driver is where and where are it's driver data etc.
Using the DT for run-time configuration of U-Boot would be especially interesting. Assume: a single U-Boot image for all - say - OMAP3 boards...
- Get rid of static data in drivers, switch to dynamic allocation
So these wont interfere with multiple instances of the same driver.
This might be a challange. Keep in mind that some drivers (console, eventually I2C / SPI, MMC/SDcard, NAND, ...) might be needed before relocation to RAM.
Best regards,
Wolfgang Denk