Hi,
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.
As for U-Boot, there currently is no driver model. Therefore I'd like to start a discussing on this topic so we can converge towards a reasonable result.
My few points:
* 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.
* 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.
* We need some "device tree" To know, what driver is where and where are it's driver data etc.
* Get rid of static data in drivers, switch to dynamic allocation So these wont interfere with multiple instances of the same driver.
Cheers
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
Dne Po 20. září 2010 12:54:06 Wolfgang Denk napsal(a):
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.]
I wanted to avoid saying it right away.
- 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...
This looks very cool. I thought about this and I came to a further idea: * Make "minimal" u-boot that'd be independent of DTree * Upon setting variable "fdt" to an address of the DTree, enable remaining components of uboot
The second point would allow booting a platform in case the DTree was faulty. Or we can have a known-good DTree and a variable that'd allow to override it, that might be even better.
- 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
Dear Marek Vasut,
In message 201009241737.27335.marek.vasut@gmail.com you wrote:
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...
This looks very cool. I thought about this and I came to a further idea:
- Make "minimal" u-boot that'd be independent of DTree
- Upon setting variable "fdt" to an address of the DTree, enable remaining
components of uboot
The second point would allow booting a platform in case the DTree was faulty. Or we can have a known-good DTree and a variable that'd allow to override it, that might be even better.
We will probably need something like that anyway - the "minimal configuration" being largely what is running before relocation, the "full configuration" when we have full access to normal resources.
Best regards,
Wolfgang Denk
Le 24/09/2010 19:35, Wolfgang Denk a écrit :
Dear Marek Vasut,
In message201009241737.27335.marek.vasut@gmail.com you wrote:
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...
This looks very cool. I thought about this and I came to a further idea:
- Make "minimal" u-boot that'd be independent of DTree
- Upon setting variable "fdt" to an address of the DTree, enable remaining
components of uboot
The second point would allow booting a platform in case the DTree was faulty. Or we can have a known-good DTree and a variable that'd allow to override it, that might be even better.
We will probably need something like that anyway - the "minimal configuration" being largely what is running before relocation, the "full configuration" when we have full access to normal resources.
Best regards,
Wolfgang Denk
Stop me if I'm wrong, but basically this would imply that u-boot be built with support for the largest possible device combination, thus be rather big, right? I hope the ability to trim it down u-boot to a minimum is retained, though, i.e. be able to choose between a one-size-fits-all binary that will run on anything *or* a tight fit that will run only on a given platform with minimal footprint (or anything in-between, actually).
Amicalement,
Dear Albert ARIBAUD,
In message 4C9CE432.7060100@free.fr you wrote:
Stop me if I'm wrong, but basically this would imply that u-boot be built with support for the largest possible device combination, thus be rather big, right? ...
Probably yes - similar to how Linux kernels are configured today by default, i. e. one kernel image being able to run on all (or at least a wide range of) boards of the same architecture, or even of a number of similar / compatible architectures.
... I hope the ability to trim it down u-boot to aminimum is retained, though, i.e. be able to choose between a one-size-fits-all binary that will run on anything *or* a tight fit that will run only on a given platform with minimal footprint (or anything in-between, actually).
Of course. We will always allow customized, board specific configurations that can be kept as small as possible if they don't need this feature.
But if you look at current trends with SoC and board manufacturers, it would be really great if we could have some image that covers more than just one or two boards.
Best regards,
Wolfgang Denk
Le 24/09/2010 20:59, Wolfgang Denk a écrit :
Of course. We will always allow customized, board specific configurations that can be kept as small as possible if they don't need this feature.
Good.
But if you look at current trends with SoC and board manufacturers, it would be really great if we could have some image that covers more than just one or two boards.
This is understandable too; I just wanted to make sure there was a choice.
Thanks for the clarification!
Amicalement,
participants (3)
-
Albert ARIBAUD -
Marek Vasut -
Wolfgang Denk