From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michal Simek Date: Mon, 25 Aug 2008 15:37:11 +0200 Subject: [U-Boot] [PATCH] ppc440: New board: Avnet Virtex5 FXT Evaluation In-Reply-To: References: <1219422944-17293-1-git-send-email-ricardo.ribalda@uam.es> <48B12EAE.40509@seznam.cz> <200808251009.08488.sr@denx.de> <48B27C78.1000501@seznam.cz> Message-ID: <48B2B587.2000800@seznam.cz> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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. > > Regards > > On Mon, Aug 25, 2008 at 05:33, Michal Simek 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 at denx.de >>> ===================================================================== >>> > > >