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

[Detlev Zundel <dzu@denx.de>]

Hi Pavel,

> On Wed 2014-05-28 16:29:50, Wolfgang Denk wrote:
>> In message <20140528124910.GA24478@amd.pavel.ucw.cz> you wrote:
>> > 
>> > There are no differences between EBV socrates and socfpga boards,
>> > currently.
>> 
>> Well, for one thing, the board vendor and the board name differ...
>
> I meant from current code in u-boot point of view...

But as we all agree, this may change quickly and for multiple boards.

>> > > > 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.  
>> > 
>> > That's what mx6 did, AFAICT.
>> 
>> I think Detlev is right here.  We do have specific board vendors
>> directories, and there are a number of reasons to keep this used
>> (just to give one example: say a vendor wants to use a similar look
>> and feel for the default environment settings etc. for all boards).
>
>> If there is code which is identical for several (or all?) boards we
>> should ask ourself if it really belongs into the board/ directory at
>> all?
>
> That might be the case. It seems that current code in board/altera is
> SoC-specific, as it works on both Altera and EBV boards. 

Then we are in agreement that it does not belong below board/ ;)

>> > Actually.. there's nothing Altera specific in board/altera (it works
>> > on ebv just fine), so board/socfpga sounds like a better name. But I
>> > don't think such rename should be done lightly, so I still believe the
>> > patch as submitted is the best way to go.
>> 
>> I think board/altera as such makes sense, with Altera being the vendor
>> of that specific board.  However, if there is common code there, this
>> code should be moved out of board/ .
>
> It seems there's currently 99.99% of SoC-specific code there.
>
> What would be the right place for that code?

Depends on what exactly it implements.  Apart from that we can also take
a look at where the code is in a Linux tree and take that as an
example.  After all, we want people developing the Linux kernel to also
feel at home in the U-Boot sources.

> arch/arm/cpu/armv7/socfpga/ ? But it is not really armv7-specific.
> drivers/misc ? Do we need to make a soc/ directory?

We have arch/arm/imx-common for example, but I'm not so sure if this is
a good approach.  Maybe there is not a _single_ correct place, but we
have to distribute the files to multiple directories?

> And then... who does the move? It is not going to make merging between
> rocketboards.org and mainline even trickier than it already is :-(.

This is a good question and we should certainly not answer it lightly.
Usually we care only to a certain degree for non-mainline code, though.
Blocking ourselves because of non-mainline code would allow "external"
control which I think is not really helpful for the project.

Cheers
  Detlev
  
-- 
I think that level of generalization is too abstract for useful thinking.
             -- Richard Stallman in <E19N344-0006Q9-Bt@fencepost.gnu.org>
--
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