Hi Michal, Hi Ricardo,
On Sunday 24 August 2008, Michal Simek wrote:
I agree with you that the code of ml507 and other board with that fpga will be almost the same, except external devices like ram, flash type ethernet macs....
Yes, simple ifdef CONFIG_XILINX_LL_TEMAC in config file is sufficient.
But the same happens in other part of the code: many arm boards are very similar between them, etc.
Yes, but FPGA is different case. Arm boards can't be change by user to much as you can change FPGA boards. First u-boot compilation on this board will run.
I'm not so sure if those FPGA based boards are this different from the "standard" boards with SoC's, like PPC's ARM's etc (please correct me if I'm wrong). You will most likely also have board specific implementation differences like:
- different SDRAM configuration (non-SPD vs. SPD) - different PHY's and PHY addresses - different FLASH configuration that can't be handled with one CFI option set - etc..
So it makes perfact sense for me to "allow" multiple board ports in the official U-Boot repository for the Virtex 440 for example. Again, please correct me if I am wrong here.
In the other hand is very convenent (and commercial) that u-boot support as many boards as possible, support explicitily, not as part of a common board, think that the boards are organized by vendor: User are not supported to know all the manufactures "excentrities"
Please Wolfgang for some comments but IMHO this is not the point support a lot of boards as is possible. I think that the point is support important boards in every category and every new board should add any information to U-BOOT.
I think all boards should a right to be included in the official U-Boot repository. Of course code duplication should be avoided if possible.
If the manufacturer has the board with name (arm, ppc) and this board is distributed and known by this name it is good reason to add this board to U-BOOT. For example all freescale boards are good example. A lot of company just copy their hw design - change some minor parameters and do it as proprietary board.
I have been thinking a bit about this and I came with this idea (please give me your comments):
- Create a folder like: /board/xilinx/generic/ppc440
/board/xilinx/generic/ppc405 /board/xilinx/generic/microblace
board/xilinx/ppc440 and ... is sufficient. Just renaming folder should be sufficient.
For microblaze case -> xilinx/m401 -> xilinx/microblaze For ppc405 -> xilinx/ml300 -> xilinx/ppc405 For ppc440 -> xilinx/ml507 -> xilinx/ppc440
ACK.
And remove others folder in xilinx directory.
- Create one config for every previous generic board (nothing new until
know)
ok. And rename config files too.
- Create one config file for every specific board that includes the
generic configuration for it class
Yes. I like this idea. We already have this for AMCC with amcc-common.h.
No. I think that one generic config file is sufficient.
I disagree here (see above).
Because if you are able to compile and run U-BOOT with using generic config on every board with MB, ppc405, ppc440 (of course with specific config files for every platform), you know that your work is functional. You can use it on every board based on your generic board. I do the same for Microblaze - I use some platform and tens design (every design is different) but everything is based on generic design. My U-BOOT bsp can handle a lot of peripherals and generate proper parameters for every board and I see that my generic config file cover all possibilities which can come. If this generic file failed I see that something is wrong there and it is the right time to fix it.
One generic U-Boot config header for all possible board variants? This sounds too good to be true. But how do you handle those cases I stated above? You will need at least different config options. And then you have to use multiple #ifdef's in the generic config header. I prefer the approach from Ricardo here.
My approach is just rename folder to generic style as you suggested. And write one simple readme file where you can write step by step manual how to configure u-boot and then ml507 ,reference design from xilinx page - edk version was tested and works. Avnet virtex5fxt tested, etc... I think this is solution.
- Create folders like /board/xilinx/ml507 with the specific ml507
code (99,9999% this wont be needed)
no.
Again, I'm with Ricardo here.
The generic configuration will take care of the xparameter file: something like:
#if XPAR_TEMAC #define CMD_NET_PING #endif
the same style as is used in Microblaze config file - look at ml401 or xupv2p config files.
Using this philosophy, there is no code replication, boards are explicitly supported and future boards with rare features will be also supported easily
Any ideas/sugestion?
I like this idea.
I see code duplication in main Makefile. This Makefile is long and I haven't seen why we should this file do longer then is.
I don't think this is a real problem.
Again, I think Ricardo's approach with the common board directory is a good idea. And I still think that we should add as many boards as possible to the official repository. There are already too many boards using U-Boot which are *not* available here and that's a shame from my point of view.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================