[U-Boot] [PATCH v2] Separate EBV Socrates board from Altera Cyclone 5 board and from Virtual Target

[Detlev Zundel <dzu@denx.de>]

Hi Pavel,

> Hi!
>
>> > /home/pavel/wagabuibui/u-boot/board/ebv/socfpga/Makefile: No such file
>> > or directory
>> > make[2]: *** No rule to make target
>> > `/home/pavel/wagabuibui/u-boot/board/ebv/socfpga/Makefile'.  Stop.
>> 
>> I feared as much, so thats why I asked ;)
>> 
>> > ...and I don't think we want to do board/{altera,ebv} symlink. Are
>> > there any other options? Or is "altera" in the boards file simply
>> > acceptable?
>> 
>> This is a problem that will turn up in the future even more, so I
>> propose to solve it correctly now.  It will not be long before we
>  > want
>
> Well, OTOH it is orthogonal problem to the "board name is shared
> between socrates and altera" and "config is shared between altera and
> virtual target". And this patch is going to go stale rather quickly.

I admit, I do not understand that fully.

>> to have our own configuration for our MCV module and this will certainly
>> be sold by DENX.  I think we need an infrastructure to allow for boards
>> sold by arbitrary manufacturers all using the Altera chip.
>> 
>> The situation as such is not uncommon, so maybe you can follow examples
>> from different CPUs?  I.e. how is the imx6 handled on the different base
>> boards?
>
> The examples I seen were different: there different board vendors
> actually needed different code.
>
> AFAICT, one solution would be to put "-" in that column, and do "git
> mv board/altera/ board/socfpga/".

Putting "-" in the vendor column just doesn't feel right.  How about
using a minimal board C file for socrates under ebv/socrates that only
implements checkboard and shares the rest?

> But if we decide to go that way, it should really be separate patch.

I still like to see a solution that scales to things we already know
will happen ;)  Looking at the original patch, with this in mind even
the #define ALTERA_BOARD_NAME doesn't look right any longer.

Thanks
  Detlev

-- 
We have a live-manual.  It's called emacs-devel at gnu.org.
You can stick to just reading it, but you can skip to a specific chapter
by simply sending an email asking for it ;-)
                                    -- Stefan Monnier
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de