litesom.c: Board stuff in SOC ?

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

litesom.c: Board stuff in SOC ?

Stefano Babic
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.

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.

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: [hidden email]
=====================================================================
_______________________________________________
U-Boot mailing list
[hidden email]
https://lists.denx.de/listinfo/u-boot
Reply | Threaded
Open this post in threaded view
|

Re: litesom.c: Board stuff in SOC ?

Marcin Niestroj
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 has only RAM and eMMC memory
included with the processor. 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.

The idea about creating a separate file in arch/arm/cpu/armv7/mx6/
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. 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. 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.

[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.

Regards,
Marcin

>
> Regards,
> Stefano
>

--
Marcin Niestroj
_______________________________________________
U-Boot mailing list
[hidden email]
https://lists.denx.de/listinfo/u-boot
Reply | Threaded
Open this post in threaded view
|

Re: litesom.c: Board stuff in SOC ?

Stefano Babic
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
./freescale/common
./compulab/common


.... 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.

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.

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: [hidden email]
=====================================================================
_______________________________________________
U-Boot mailing list
[hidden email]
https://lists.denx.de/listinfo/u-boot
Reply | Threaded
Open this post in threaded view
|

Re: litesom.c: Board stuff in SOC ?

Marcin Niestroj
Hi Stefano,

I've added Tom to the discussion. 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 (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.

--
Regards,
Marcin Niestroj

_______________________________________________
U-Boot mailing list
[hidden email]
https://lists.denx.de/listinfo/u-boot
Reply | Threaded
Open this post in threaded view
|

Re: litesom.c: Board stuff in SOC ?

Stefano Babic
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: [hidden email]
=====================================================================
_______________________________________________
U-Boot mailing list
[hidden email]
https://lists.denx.de/listinfo/u-boot
Reply | Threaded
Open this post in threaded view
|

Re: litesom.c: Board stuff in SOC ?

Tom Rini-4
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

_______________________________________________
U-Boot mailing list
[hidden email]
https://lists.denx.de/listinfo/u-boot

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: litesom.c: Board stuff in SOC ?

Stefano Babic
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: [hidden email]
=====================================================================
_______________________________________________
U-Boot mailing list
[hidden email]
https://lists.denx.de/listinfo/u-boot
Reply | Threaded
Open this post in threaded view
|

Re: litesom.c: Board stuff in SOC ?

Tom Rini-4
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

_______________________________________________
U-Boot mailing list
[hidden email]
https://lists.denx.de/listinfo/u-boot

signature.asc (836 bytes) Download Attachment