[U-Boot-Users] Support for the ML507
Hello again:
This is my third submission of the same thing, please be indulgent....:
This month I have been working on the ml507 board, trying to give it support. This boards has a lot of components and I have developed drivers for some of them. On my first submission, the board and the drivers were on a single diff file. The mail list didn't like a message so big so I cutted it in 4 parts, bziped it and resend it. Later on I have realized that, it do not support the guidelines on the web.... And it will be huge work for the mantainers to check all that code
So, I have spent the evening dividing the big patch in 8 independent patches. I have used the git tools to prepare the patches and resend them... Unfortunatelly some of this files are bigged than the 40kb limit.... If the mail list administrator don't accept this parts you can download the full set of patches from my website: http://www.ii.uam.es/~rribalda/ml507.tgz
Why my patches are so big... They give support to IPs by Xilinx, which have some kind of generic drivers to adapt them to multiple OS... When the driver was very complex I have used this generic drivers and added an adaptor. Because it does not follows the coding guidelines, all this drivers have been located under the board directory to respect all your "clean" work.
Sorry for the mess I have created in just a matter of minutes.
Best Regards and I hope to see my code on the main line someday.
In message aa76a2be0807101114g67d0f099y95de772f47051107@mail.gmail.com you wrote:
So, I have spent the evening dividing the big patch in 8 independent patches. I have used the git tools to prepare the patches and resend them... Unfortunatelly some of this files are bigged than the 40kb limit.... If the mail list administrator don't accept this parts you can download the full set of patches from my website: http://www.ii.uam.es/~rribalda/ml507.tgz
40 kB is the soft limit; the hard limit is 100 kB.
Why my patches are so big... They give support to IPs by Xilinx, which have some kind of generic drivers to adapt them to multiple
You are aware that some similar code laready exists in U-Boot? and that your patches contain lots of code that will most definitely never be used in U-Boot?
OS... When the driver was very complex I have used this generic drivers and added an adaptor. Because it does not follows the coding
I have extremely little emthusiasm to add big and complex drivers that are intended to support many operating systems plus an adaption layer to a small boot loader like U-Boot.
I think such drivers should be reimplemented from scratch, with efficiency and style in mind.
guidelines, all this drivers have been located under the board directory to respect all your "clean" work.
The Coding Style reqyierements apply to code in the board/ directories as well.
And adding thsi stuff there makes it only worse, as the next similar board that gets added will copy the whole crap.
This is bound to be unmaintainable.
I *strongly* recommend to redesign and reimplement.
Best regards,
Wolfgang Denk
Hello again:
I have adapted the Xilinx drivers just because there were other examples of that behaviour on the u-boot code (board/xilinx/xilinx_enet, board/xilinx/xilinx_iic and board/xilinx/common) for the xilinx drivers.
About redesigning the drivers from scratch.... Maybe is not a good idea on FPGA soft cores. This devices made of hardware/software change very frequently (even twice per year) and if we develop a driver from scratch, it will be very hard to mantain. On the other hand, if we use the "generic drivers" we just need to change them when the devices are upgraded.
Maybe an option will be just not give support to FPGAs boards..., but they are used by a lot of people (students and companies). We can have the risk that if we do not give support to that boards, the FPGAs manufacturers will create a fork and take full control of the u-boot roadmap (more money and resources).
I have tried to follow the coding guidelines for all the files I have created from scratch, but not for the drivers by xilinx.
Best Regards
On Thu, Jul 10, 2008 at 8:48 PM, Wolfgang Denk wd@denx.de wrote:
In message aa76a2be0807101114g67d0f099y95de772f47051107@mail.gmail.com you wrote:
So, I have spent the evening dividing the big patch in 8 independent patches. I have used the git tools to prepare the patches and resend them... Unfortunatelly some of this files are bigged than the 40kb limit.... If the mail list administrator don't accept this parts you can download the full set of patches from my website: http://www.ii.uam.es/~rribalda/ml507.tgz
40 kB is the soft limit; the hard limit is 100 kB.
Why my patches are so big... They give support to IPs by Xilinx, which have some kind of generic drivers to adapt them to multiple
You are aware that some similar code laready exists in U-Boot? and that your patches contain lots of code that will most definitely never be used in U-Boot?
OS... When the driver was very complex I have used this generic drivers and added an adaptor. Because it does not follows the coding
I have extremely little emthusiasm to add big and complex drivers that are intended to support many operating systems plus an adaption layer to a small boot loader like U-Boot.
I think such drivers should be reimplemented from scratch, with efficiency and style in mind.
guidelines, all this drivers have been located under the board directory to respect all your "clean" work.
The Coding Style reqyierements apply to code in the board/ directories as well.
And adding thsi stuff there makes it only worse, as the next similar board that gets added will copy the whole crap.
This is bound to be unmaintainable.
I *strongly* recommend to redesign and reimplement.
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: wd@denx.de How much net work could a network work, if a network could net work?
Hi,
Hello again:
I have adapted the Xilinx drivers just because there were other examples of that behaviour on the u-boot code (board/xilinx/xilinx_enet, board/xilinx/xilinx_iic and board/xilinx/common) for the xilinx drivers.
This style is deprecated. xilinx_enet is emaclite(drivers/net/xilinx_emac.c) driver which I rewrite some month ago. IIC driver is easy to rewrite. You used bad example.
About redesigning the drivers from scratch.... Maybe is not a good idea on FPGA soft cores. This devices made of hardware/software change very frequently (even twice per year) and if we develop a driver from scratch, it will be very hard to mantain. On the other hand, if we use the "generic drivers" we just need to change them when the devices are upgraded.
Almost all IP cores are backward compatible. I developed for Microblaze cpu MLD(TCL) which helps you with changes in your design. You can do the same thing. Bsp is available at git.monstr.eu. Patches are welcomed.
Maybe an option will be just not give support to FPGAs boards..., but they are used by a lot of people (students and companies). We can have the risk that if we do not give support to that boards, the FPGAs manufacturers will create a fork and take full control of the u-boot roadmap (more money and resources).
Of course you can add support for generic board or for small amount of board in generic style. Look at ml401 and xupv2p for microblaze. It is not to hard to add support for xilinx fpga board but you have to do it correctly. I see a space for adding one generic board with ppc440 which will be sufficient for others.
I have tried to follow the coding guidelines for all the files I have created from scratch, but not for the drivers by xilinx.
If you want to help with handling of xilinx board, you can contact me.
Michal Simek
Best Regards
On Thu, Jul 10, 2008 at 8:48 PM, Wolfgang Denk wd@denx.de wrote:
In message aa76a2be0807101114g67d0f099y95de772f47051107@mail.gmail.com you
wrote:
So, I have spent the evening dividing the big patch in 8 independent patches. I have used the git tools to prepare the patches and resend them... Unfortunatelly some of this files are bigged than the 40kb limit.... If the mail list administrator don't accept this parts you can download the full set of patches from my website: http://www.ii.uam.es/~rribalda/ml507.tgz
40 kB is the soft limit; the hard limit is 100 kB.
Why my patches are so big... They give support to IPs by Xilinx, which have some kind of generic drivers to adapt them to multiple
You are aware that some similar code laready exists in U-Boot? and that your patches contain lots of code that will most definitely never be used in U-Boot?
OS... When the driver was very complex I have used this generic drivers and added an adaptor. Because it does not follows the coding
I have extremely little emthusiasm to add big and complex drivers that are intended to support many operating systems plus an adaption layer to a small boot loader like U-Boot.
I think such drivers should be reimplemented from scratch, with efficiency and style in mind.
guidelines, all this drivers have been located under the board directory to respect all your "clean" work.
The Coding Style reqyierements apply to code in the board/ directories as well.
And adding thsi stuff there makes it only worse, as the next similar board that gets added will copy the whole crap.
This is bound to be unmaintainable.
I *strongly* recommend to redesign and reimplement.
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: wd@denx.de How much net work could a network work, if a network could net work?
Hi Ricardo,
Hello again:
This is my third submission of the same thing, please be indulgent....:
Please don't send next submission of the same thing if you know that minimally half of these patches are wrong.
Michal
This month I have been working on the ml507 board, trying to give it support. This boards has a lot of components and I have developed drivers for some of them. On my first submission, the board and the drivers were on a single diff file. The mail list didn't like a message so big so I cutted it in 4 parts, bziped it and resend it. Later on I have realized that, it do not support the guidelines on the web.... And it will be huge work for the mantainers to check all that code
So, I have spent the evening dividing the big patch in 8 independent patches. I have used the git tools to prepare the patches and resend them... Unfortunatelly some of this files are bigged than the 40kb limit.... If the mail list administrator don't accept this parts you can download the full set of patches from my website: http://www.ii.uam.es/~rribalda/ml507.tgz
Why my patches are so big... They give support to IPs by Xilinx, which have some kind of generic drivers to adapt them to multiple OS... When the driver was very complex I have used this generic drivers and added an adaptor. Because it does not follows the coding guidelines, all this drivers have been located under the board directory to respect all your "clean" work.
Sorry for the mess I have created in just a matter of minutes.
Best Regards and I hope to see my code on the main line someday.
participants (4)
-
Michal Simek -
Michal Simek
-
Ricardo Ribalda Delgado -
Wolfgang Denk