On Fri, May 19, 2017 at 04:13:29PM +0200, Stefano Babic wrote: > 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.
I am less concerned with "board" vs "arch" than I am with making it clearly and easily re-usable, but also not adding further complex Makefile logic to handle inclusion. > > 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. So we agree, good, yes, OK :) > 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. Well, I think the answer is that arch/arm/imx-common/ needs to become arch/arm/mach-imx (ala the kernel) and arch/arm/cpu/armv7/mx* needs to move to this new directory, in whatever layout you feel is cleanest (the kernel has this flat, except for include/mach). I don't know if I was clear enough in my first reply, so I'm following up here, now. > > 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. Yeah, there's a little bit of clean-up I want to do to that Makefile at some point and partly relies on adding more Kconfig symbols and merging more of the common-IP-different-src things we still have. But that's another story... > > 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.. :-) Make it so in mach-imx and we'll move from there :) Thanks! -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
