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