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

[Stefan Roese]

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)
- different PHY's and PHY addresses
- different FLASH configuration that can't be handled with one CFI
  option set
- 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.

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

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

> 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).

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

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

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

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

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