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

[Michal Simek]

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