[U-Boot] [PATCH] ppc440: New board: Avnet Virtex5 FXT Evaluation

[Michal Simek]

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 <monstr at 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 at denx.de
>>> =====================================================================
>>>
> 
> 
>