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. 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). In the latter case, it doesn't make sense for company X to put their board in boards/SOM-vendor/. 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/. 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. 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/). Thanks! -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
