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

[Detlev Zundel <dzu@denx.de>]

Hi Chian,

> Hi guys,
>
>
> On Fri, 2014-05-30 at 11:41 +0200, Detlev Zundel wrote:
>> 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.
>
>
> Yup, some other board vendors are using different HW configuration. Some
> of the difference are Altera dev kit have EEPROM and using Micrel PHY
> for EMAC. I presume Socrates board should have their own board path such
> as board/socrates/socfpga.

We are using a "board/<vendor>" scheme, so it should be
"board/ebv/socrates", but otherwise we agree.

>> >> > > > 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/ ;)
>
>
> Within board/altera, there are 2 types of files as below:
>
> 1. HW configuration handoff files (such as pinmux_config, pll_config).
>    Pinmux might be different as certain board might have different
> routing (normally to optimize the board layout and shorter PCB trace
> length).
>
> 2. Board specific code (socfpga_cyclone5.c)
>    These functions include board_init, board_early_init, checkboard.
>    I believe that the function print_cpuinfo and overwrite _console
> should goto arch/arm/cpu/armv7/socfpga/misc.c.
>    I will create the patch to change this later (as I already did this
> at rocketboard.org).

Thanks in advance!

>> >> > 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.
>>
>
>
> As above, I can move some common function to
> arch/arm/cpu/armv7/socfpga/misc.c.

Sounds good.

Thanks
  Detlev
  
-- 
A statistician can have his head in an oven and his feet in ice, and
he will say that on the average he feels fine.
--
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