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

[Ricardo Ribalda Delgado]

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
>> =====================================================================
>>
>



-- 
Ricardo Ribalda
http://www.eps.uam.es/~rribalda/