Hi Pavel,
> On Wed 2014-05-28 16:29:50, Wolfgang Denk wrote:
>> In message <20140528124910.ga24...@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...@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: d...@denx.de
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
