Hi Tom,
On 19/05/2017 15:39, Tom Rini wrote:
On Fri, May 19, 2017 at 12:51:18PM +0200, Stefano Babic wrote:
Hi Marcin,
On 19/05/2017 12:41, Marcin Niestroj wrote:
Hi Stefano,
I've added Tom to the discussion.
Of course !
So if we make some changes to SOM code position in u-boot tree, let's make sure we do it for all architectures the same
We have already not done in this way. We have all boards / SOM code inside bords/, the only exceptions are yours. If there is a decision to add an abstraction for SOM, we have to put coherently all SOMs that are now stored in the boards directory.
What you mention are just exception - that I would like to clean up.
So, we do have a problem with the layout today.
Indeed, true. There is not an abstraction for SOM today.
The point of SOMs is that yes, you can drop them into a carrier from the same vendor (and this is true for both "3rd party" ones like litesom/chilisom/solidrun/etc and vendor ones like more recent NXP eval boards) or company X buys the SOMs and puts them in their own custom carrier (which hell, we have customers that do).
Right, this is the common case.
In the latter case, it doesn't make sense for company X to put their board in boards/SOM-vendor/.
The question is how they reference to the common / SOM code. I am quite sure that the object should be part of the board library, that is at the end part of board/<vendor>/<board name>/lib.a.
In my mind, arch/arm/mach-omap2/am33xx/chilisom.c is the right solution and the big problem with i.MX right now is that arch/arm/imx-common and arch/arm/cpu/armv7/mx* need to get some re-organization under arch/arm/mach-imx/.
Sure the SOM code should be not under cpu/....mx6. This is wrong.
imx-common was created (as far as I can still remember) as solution to put code shared between all i.MX processors, from imx.2x up to i.MX6 or i.MX7. Code that does not belong to a single SOC.
As far as I see, there is not a single solution for SOM in u-boot. In some cases (what you mention) are in mach-*, in some other cases they are under board/<vendor>. Just check the number of "common" directories under boards. In most cases they are SOM, and I am sure I am still missing a lot of them.
And I'm not going to claim that arch/arm/mach-omap2 is best organized here, I largely moved the old omap-common to mach-omap2 and everything else into subdirs of that.
Nevertheless, this is a much more sustainable solution. If imx-common is changed into mach-imx, and it contains subdirectories for the specific type, we could simplify imx-common/Makefile, that is become messy with two many filters in a way as in mach-omap2. And then, moving litesom.c in a place as arch/arm/mach-imx/som/mx6 seems much more appropriate.
I can certainly see an argument for arch/arm/mach-$X/som/ (or mach-$X/$soc/som/) instead of just putting them in arch/arm/mach-$X/ (or again, mach-$X/$soc/).
mach-$X/$soc/som/ is my preferred choice if we vote.. :-)
Best regards, Stefano