Yes, I agree.
M
Hello Stefan and Michal
If you want I can prepare a patch with the idea that I proposed on my previous mail, just to have something to start discussing about. Please consider the patch as it is: something real to discuss about: not a "real" patch I hope I have something today after.
RegardsOn Mon, Aug 25, 2008 at 05:33, Michal Simek monstr@seznam.cz wrote:
Hi Stefan,
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)
I am not MPMC (memory controller) expert but I think for 98% of board you choose type of memory which is used by board. Size of memory it's up to you. Just compile and will work. SPD is not use to much as is in others board. Not any other setting is used. Baseaddress and size is enough.
- different PHY's and PHY addresses
Yes. This should be a small problem in case you use ip core with phy handling. For example i think ml507 has not different routing with ml505 and there are some phy and You can change some modes too. More comment below.
- different FLASH configuration that can't be handled with one CFI option set
Flash options are set when you do bitstream - timing and others. Software site is transparent just use CFI. You need only baseaddress.
- 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.
I think that in this state which we have - only two ethernet cores are in U-BOOT and one of them is ancient and use by older boards and emaclite doesn't care about phy, it is not right time to care about phy. Phy lib is not in U-BOOT but for example in Yoshio ll_temac driver is use phy detection. In case when we will have phy lib (Ben has it in his to do list) we can use phy detection and I think it will work. In more compicated board is possible to directly specify phy number. In generator not in u-boot config.
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.
yes.
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.
ok.
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).
[snip]
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.
Look above. All differences should be handled by BSP and in Microblaze case they are. Just run BSP in edk which you have to use for you hardware building and then copy one file to U-BOOT.
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.
[snip]
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.
ok
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.
I agree with you that U-BOOT runs on many boards and in many case is shame that they are not in U-BOOT repo but the question is if the information value from this board add any information to U-BOOT code. Many of these boards are proprietary boards. Others then use generic platform and hw developers just change phy or use switch on board. I agree that if someone use for example new Vitesse switch and there is difficult initialization is a big shame that this board is not in U-BOOT repo. But I think that others "boring" board with just change size of memory, flash and others minor things should be out of u-boot.
FPGA cpu are different. You have to use EDK for creating your design. You have one board and you can do in Microblaze case almost everything (ppc board has more limitation) and you can have tens (thousands) designs which are interesting. That what I want to see that what is reference design. Of course you can't add more memory which is on development board and others thing but in every case you do your design yourself you have to use any generator for extract parameters from your design. That is what Ricardo, I and other use because we have to. Xparameters is that file. (You can see it in xilinx folder). You have to generate this file and values in this file describe design in detail (not every possible choices are covered).
I use for Microblaze generator which I had and I haven't found any problem which should not be covered by bsp directly from EDK. Microblaze community use a lot Petalinux. There is ancient U-BOOT version and there is used only one file for every board which are in full distribution. This is really what people use and they just compile one generic board.
IMHO if this approach works on microblaze that this approach should work on ppc440 too.
You can look at ml401 and xupv2p config file. There is big overlap just because one board hasn't flash memory but in ml401 is handled both. I have improved configs in my repo which I used with some others feature and they are not in U-BOOT mainline because of time.
Thanks for your comments, Michal
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 =====================================================================