Re: [U-Boot] [RFC] Driver model
Dne Po 20. září 2010 12:54:06 Wolfgang Denk napsal(a): Dear Marek Vasut, In message 201009201205.41037.marek.va...@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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Driver model
Dear Marek Vasut, In message 201009241737.27335.marek.va...@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 -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de There were meetings. There were always meetings. And they were dull, which is part of the reason they were meetings. Dull likes company. - Terry Pratchett, _Making_Money_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Driver model
Le 24/09/2010 19:35, Wolfgang Denk a écrit : Dear Marek Vasut, In message201009241737.27335.marek.va...@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, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Driver model
Dear Albert ARIBAUD, In message 4c9ce432.7060...@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 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). 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 -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de It is practically impossible to teach good programming style to stu- dents that have had prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration. - Dijkstra ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Driver model
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, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC] Driver model
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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Driver model
Dear Marek Vasut, In message 201009201205.41037.marek.va...@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 -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de At the source of every error which is blamed on the computer you will find at least two human errors, including the error of blaming it on the computer. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
