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 -- ===================================================================== DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de ===================================================================== _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
