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. Best regards, Stefano Babic > (at least I mean chilisom code which is in > arch/arm/mach-omap2/am33xx/ > > On 18.05.2017 17:20, Stefano Babic wrote: >> Hi Marcin, >> >> On 18/05/2017 16:57, Marcin Niestroj wrote: >>> Hi Stefano, >>> >>> On 18.05.2017 16:28, Stefano Babic wrote: >>>> Hi Marcin, >>>> >>>> even if it was already merged (and maybe I am guilty of it because I >>>> have not noted before), it is completely crazy that a board is stored >>>> inside the SOC directory. The litesom board is in fact in >>>> ./arch/arm/cpu/armv7/mx6/litesom.c, and there is nothing that justify >>>> this. The code has just board related stuff and nothing common for all >>>> SOC. >>> >>> litesom is not a board, but a SOM. >> >> It does not matter, sorry. The code is not common for all boards (and if >> you like it, all SOMs) sharing the same SOC or SOC family. In this case, >> i.MX6. >> >> There is plenty of such as example in U-Boot, please check it in code. >> SOM support is in the boards directory and it must not be here. It will >> be removed. >> >>> It has only RAM and eMMC memory >>> included with the processor. >> >> Like all SOMs you find in u-boot from a lot of different vendors...just >> check it. >> >>> litesom cannot work on it's own. It needs >>> to be part of some board. An example board is liteboard, which support >>> is included in board/grinn/liteboard/. Please visit [2] to visualize >>> what the litesom device is. >> >> Thanks, nothing new. >> >> Again: the SOM is specific to a vendor and cannot be in the SOC >> directory. There should be then a board/grinn/common (or whatever you >> want) where SOM code is put. And again, not in SOC directory. >> >>> >>> The idea about creating a separate file in arch/arm/cpu/armv7/mx6/ >> >> The idea is correct, just in wrong place. There are plenty of examples >> doing this: >> >> ./engicam/common > > Ok, I see. But it was just merged, so I couldn't look at it earlier. > As I understand, you want me to follow this example with litesom. > > I do not say that is a bad idea in general and we should not follow it. > *BUT* right now these sources cannot be used when other vendor > will create it's own board. They won't compile, because root Makefile > has a "libs-$(HAVE_VENDOR_COMMON_LIB) += board/$(VENDOR)/common/" > entry, which depends on *board* vendor. > >> ./freescale/common > > There is a lot of shared code between freescale boards, but I do not see > SOM example there. Could you point me one? > >> ./compulab/common > > I do not see SOM code there. There is also ./compulab/cl-som-am57x > directory, but it contains *board* support code, which uses > CL-SOM-AM57x, not pure SOM (e.g. they configure UART and SD card, > which are not SOM specific). > >> >> >> .... and many others. >> >>> was to be able to reuse code when new boards, that use litesom >>> as it's core, will be added. And these boards need not to be >>> manufactured or designed by Grinn. >> >> Right, so why are we discussing ? They belong to grinn, that means the >> code should be in board/<vendor>, that is board/grinn. Please move it ! >> >>> So if some other vendor wants >>> to add support for it's board (which will be based on litesom), >>> the code to initialize RAM and eMMC can be reused. >> >> They will be put code into the grimm directory. See all other vendors >> selling SOMs. >> >>> When litesom >>> code would be part of board/grinn/ directory, then other vendors >>> could not easily add support for their boards without copying >>> litesom sources. >> >> I will take care that the code will not be duplicated - not worry. > > Ok. Could you tell me how that would be done? That is my main concern > about moving SOM sources to ./board/<vendor>/common. In fact I've > already asked about that in both RFC for adding lite(som/board) [3] [4] > and described my motivation in PATCH adding lite(som/board) [5] support > in u-boot. > > [3] https://lists.denx.de/pipermail/u-boot/2016-August/265384.html > [4] https://lists.denx.de/pipermail/u-boot/2016-September/266534.html > [5] https://lists.denx.de/pipermail/u-boot/2016-September/266799.html > >> >> Please move it or it will be removed, thanks ! >> >>> >>> [2] http://grinn-global.com/litesom/ >>> >>>> >>>> I just took again the commit and I see: >>>> >>>> Moving arch/arm/mach-litesom/ to arch/arm/cpu/armv7/mx6/ was requested >>>> in [1] during discussion of chiliSOM support patches. >>>> >>>> [1] http://lists.denx.de/pipermail/u-boot/2017-January/279137.html >>>> >>>> >>>> But [1] has nothing to do with the context. I will tend to revert this >>>> patch and wait for an appropriate patch that add support for the board >>>> just like all other boards in U-Boot - as it is currently, it is wrong. >>> >>> Link [1] was a discussion of adding chilisom support into u-boot. >>> The idea was the same - allow to reuse SOM code for vendors creating >>> their own board based on our SOMs. >> >> Idea is already used in U-Boot and the SOM vendor has priority. Else >> code inside arch/arm/cpu/*, that must be common to all boards and *all* >> SOMs using those processor is becoming a mess. Please move it. > > I do not oppose to move SOM sources from arch/arm/cpu/*, but in my > opinion we need some mechanism for reusing SOM code for all board > vendors before doing so. > -- ===================================================================== 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