[U-Boot] How do ARM platform initialize DDR?

[U-Boot] How do ARM platform initialize DDR?

[York Sun]

Albert,

Pardon me if this is a dumb question. I have been working on powerpc
platforms in the past. Now we (the developers I work with) are exploring
ARM cores. I am searching how memory is initialized and found different
solutions. Some platforms have memory ready before u-boot even starts,
some simply write to a set of registers. I understand many platforms
don't share the IP of DDR controller. I am wondering if there is generic
DDR driver used by many ARM platforms, like the one we have for
powerpc/mpc85xx SoCs.

Regards,

York

[U-Boot] How do ARM platform initialize DDR?

[MJ embd]

Hi York,

There is no generic driver. AFAIK. Having worked on both mpc85xx and ARM

I can tell you about samsung 5250. There are 2 uboots (one spl and other main).
In case of sd/mmc boot the internal rom copies the spl uboot to iRAM
and the spl boot loader initialises the DDR3.

you can check for board/samsung/smdk5250/dmc_init_ddr3.c

-Regards
mj

On 9/17/13, York Sun <yorksun@freescale.com> wrote:
> Albert,
>
> Pardon me if this is a dumb question. I have been working on powerpc
> platforms in the past. Now we (the developers I work with) are exploring
> ARM cores. I am searching how memory is initialized and found different
> solutions. Some platforms have memory ready before u-boot even starts,
> some simply write to a set of registers. I understand many platforms
> don't share the IP of DDR controller. I am wondering if there is generic
> DDR driver used by many ARM platforms, like the one we have for
> powerpc/mpc85xx SoCs.
>
> Regards,
>
> York
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>


-- 
-mj

[U-Boot] How do ARM platform initialize DDR?

[York Sun]

Dear MJ,

Thanks for your reply.

I don't see the file in my copy. Probably it is not merged yet?
Anyway, you just confirmed what I found so far. Do you use static
setting in dmc_init_ddr3.c? I mean does it adapt to different DDR speeds
and modules (if applicable)?

In my mind, I am thinking to restructure arch/powerpc/cpu/mpc8xxx/ddr/
to driver/ddr/fsl/ so the same driver can be shared as far as the DDR IP
is the same (or similar).

York


On 09/17/2013 09:34 AM, MJ embd wrote:
> Hi York,
> 
> There is no generic driver. AFAIK. Having worked on both mpc85xx and ARM
> 
> I can tell you about samsung 5250. There are 2 uboots (one spl and other main).
> In case of sd/mmc boot the internal rom copies the spl uboot to iRAM
> and the spl boot loader initialises the DDR3.
> 
> you can check for board/samsung/smdk5250/dmc_init_ddr3.c
> 
> -Regards
> mj
> 
> On 9/17/13, York Sun <yorksun@freescale.com> wrote:
>> Albert,
>>
>> Pardon me if this is a dumb question. I have been working on powerpc
>> platforms in the past. Now we (the developers I work with) are exploring
>> ARM cores. I am searching how memory is initialized and found different
>> solutions. Some platforms have memory ready before u-boot even starts,
>> some simply write to a set of registers. I understand many platforms
>> don't share the IP of DDR controller. I am wondering if there is generic
>> DDR driver used by many ARM platforms, like the one we have for
>> powerpc/mpc85xx SoCs.
>>
>> Regards,
>>
>> York
>>
>> _______________________________________________
>> U-Boot mailing list
>> U-Boot at lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
>>
> 
> 

[U-Boot] How do ARM platform initialize DDR?

[MJ embd]

yes, I am using uboot for arndale board.
The code is written by samsung only and it is not static.

The best option would be to have an eth / serial driver kind of arch
which all soc vendors can share. But ddr is scattered, in absence of
that, your point seems valid for fsl specific.

-mj

On 9/17/13, York Sun <yorksun@freescale.com> wrote:
> Dear MJ,
>
> Thanks for your reply.
>
> I don't see the file in my copy. Probably it is not merged yet?
> Anyway, you just confirmed what I found so far. Do you use static
> setting in dmc_init_ddr3.c? I mean does it adapt to different DDR speeds
> and modules (if applicable)?
>
> In my mind, I am thinking to restructure arch/powerpc/cpu/mpc8xxx/ddr/
> to driver/ddr/fsl/ so the same driver can be shared as far as the DDR IP
> is the same (or similar).
>
> York
>
>
> On 09/17/2013 09:34 AM, MJ embd wrote:
>> Hi York,
>>
>> There is no generic driver. AFAIK. Having worked on both mpc85xx and ARM
>>
>> I can tell you about samsung 5250. There are 2 uboots (one spl and other
>> main).
>> In case of sd/mmc boot the internal rom copies the spl uboot to iRAM
>> and the spl boot loader initialises the DDR3.
>>
>> you can check for board/samsung/smdk5250/dmc_init_ddr3.c
>>
>> -Regards
>> mj
>>
>> On 9/17/13, York Sun <yorksun@freescale.com> wrote:
>>> Albert,
>>>
>>> Pardon me if this is a dumb question. I have been working on powerpc
>>> platforms in the past. Now we (the developers I work with) are exploring
>>> ARM cores. I am searching how memory is initialized and found different
>>> solutions. Some platforms have memory ready before u-boot even starts,
>>> some simply write to a set of registers. I understand many platforms
>>> don't share the IP of DDR controller. I am wondering if there is generic
>>> DDR driver used by many ARM platforms, like the one we have for
>>> powerpc/mpc85xx SoCs.
>>>
>>> Regards,
>>>
>>> York
>>>
>>> _______________________________________________
>>> U-Boot mailing list
>>> U-Boot at lists.denx.de
>>> http://lists.denx.de/mailman/listinfo/u-boot
>>>
>>
>>
>
>
>


-- 
-mj

[U-Boot] How do ARM platform initialize DDR?

[Sharma Bhupesh-B45370]

Adding Vipin to the thread as he has better knowledge on this than me.
Vipin can you please add your comments here as well..

As far as I can remember for the ARM based SPEAr SoCs on which we worked in the past:

- At the moment the DDR initialization code for various ARM SoCs in u-boot is scattered
  across ARCH directories:

	See examples of SPEAr (based on ARM926ejs) [1] and OMAP4 (ARmv7) [2] DDR drivers.

- There is no unified driver model in place for DDR driver similar to what is available for eth/serial
  drivers and we need to formulate a DDR model (something using the suggested framework in [3]) so
  that the same DDR driver can be shared across PPC and ARM SoCs.

References:

[1] SPEAr DDR drivers for Denali MPMC - 

http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/cpu/arm926ejs/spear/start.S;h=7dbd5dbf99e8c6e216cc50e789ec7f103e0ecaea;hb=HEAD#l105

http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/cpu/arm926ejs/spear/spl.c;h=b550404352b8c04f2e5d5d71df41c750c07ab1a8;hb=HEAD#l69

http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/cpu/arm926ejs/spear/spr600_mt47h128m8_3_266_cl5_async.c;h=cc45ab7016b1658eceb545c959bb1b59f33c06c7;hb=HEAD#l12

[2] OMAP4 Elpida DDR drivers - 

http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/cpu/armv7/omap4/sdram_elpida.c;h=67a79261f778c6afab3d0e3870eac1e18cff8411;hb=HEAD

http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/cpu/armv7/omap4/emif.c;h=e89032be75dc916891ccfd70c66e19c4b7b38839;hb=HEAD

[3] UDM-cores.txt - 

http://git.denx.de/?p=u-boot.git;a=blob;f=doc/driver-model/UDM-cores.txt;h=4e1318871a8d9f7f6f329800d6394158e42f85dd;hb=HEAD


Regards,
Bhupesh


> -----Original Message-----
> From: u-boot-bounces at lists.denx.de [mailto:u-boot-bounces at lists.denx.de]
> On Behalf Of MJ embd
> Sent: Tuesday, September 17, 2013 10:37 PM
> To: sun york-R58495
> Cc: u-boot at lists.denx.de
> Subject: Re: [U-Boot] How do ARM platform initialize DDR?
> 
> yes, I am using uboot for arndale board.
> The code is written by samsung only and it is not static.
> 
> The best option would be to have an eth / serial driver kind of arch
> which all soc vendors can share. But ddr is scattered, in absence of
> that, your point seems valid for fsl specific.
> 
> -mj
> 
> On 9/17/13, York Sun <yorksun@freescale.com> wrote:
> > Dear MJ,
> >
> > Thanks for your reply.
> >
> > I don't see the file in my copy. Probably it is not merged yet?
> > Anyway, you just confirmed what I found so far. Do you use static
> > setting in dmc_init_ddr3.c? I mean does it adapt to different DDR
> > speeds and modules (if applicable)?
> >
> > In my mind, I am thinking to restructure arch/powerpc/cpu/mpc8xxx/ddr/
> > to driver/ddr/fsl/ so the same driver can be shared as far as the DDR
> > IP is the same (or similar).
> >
> > York
> >
> >
> > On 09/17/2013 09:34 AM, MJ embd wrote:
> >> Hi York,
> >>
> >> There is no generic driver. AFAIK. Having worked on both mpc85xx and
> >> ARM
> >>
> >> I can tell you about samsung 5250. There are 2 uboots (one spl and
> >> other main).
> >> In case of sd/mmc boot the internal rom copies the spl uboot to iRAM
> >> and the spl boot loader initialises the DDR3.
> >>
> >> you can check for board/samsung/smdk5250/dmc_init_ddr3.c
> >>
> >> -Regards
> >> mj
> >>
> >> On 9/17/13, York Sun <yorksun@freescale.com> wrote:
> >>> Albert,
> >>>
> >>> Pardon me if this is a dumb question. I have been working on powerpc
> >>> platforms in the past. Now we (the developers I work with) are
> >>> exploring ARM cores. I am searching how memory is initialized and
> >>> found different solutions. Some platforms have memory ready before
> >>> u-boot even starts, some simply write to a set of registers. I
> >>> understand many platforms don't share the IP of DDR controller. I am
> >>> wondering if there is generic DDR driver used by many ARM platforms,
> >>> like the one we have for powerpc/mpc85xx SoCs.
> >>>
> >>> Regards,
> >>>
> >>> York
> >>>
> >>> _______________________________________________
> >>> U-Boot mailing list
> >>> U-Boot at lists.denx.de
> >>> http://lists.denx.de/mailman/listinfo/u-boot
> >>>
> >>
> >>
> >
> >
> >
> 
> 
> --
> -mj
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] How do ARM platform initialize DDR?

[Tom Rini]

On Tue, Sep 17, 2013 at 08:59:24AM -0700, York Sun wrote:

> Albert,
> 
> Pardon me if this is a dumb question. I have been working on powerpc
> platforms in the past. Now we (the developers I work with) are exploring
> ARM cores. I am searching how memory is initialized and found different
> solutions. Some platforms have memory ready before u-boot even starts,
> some simply write to a set of registers. I understand many platforms
> don't share the IP of DDR controller. I am wondering if there is generic
> DDR driver used by many ARM platforms, like the one we have for
> powerpc/mpc85xx SoCs.

Thinking back, as a rule of thumb, PowerPC has SPD I2C data
available, usually.  That's not the rule for ARM.  One of a few choices
happen:
1) ROM sets up DDR.
2) U-Boot/SPL sets up the DDR controller.

The problem is that the DDR controller is usually vendor-specific.
Perhaps the flip-side here is that there's not so much a generic DDR
driver for mpc85xx but simply one vendor for mpc85xx.  Taking
arch/powerpc/cpu/mpc85xx/ddr-gen3.c as what you're talking about,
arch/arm/cpu/armv7/omap-common/emif-common.c would be an ARM-world
example (the 'EMIF' is found on a large variety of TI parts, not just
"omap" ones).

> 
> Regards,
> 
> York
> 
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130919/137f83e6/attachment.pgp>

[U-Boot] How do ARM platform initialize DDR?

[York Sun]

On 09/19/2013 01:57 PM, Tom Rini wrote:
> On Tue, Sep 17, 2013 at 08:59:24AM -0700, York Sun wrote:
> 
>> Albert,
>>
>> Pardon me if this is a dumb question. I have been working on powerpc
>> platforms in the past. Now we (the developers I work with) are exploring
>> ARM cores. I am searching how memory is initialized and found different
>> solutions. Some platforms have memory ready before u-boot even starts,
>> some simply write to a set of registers. I understand many platforms
>> don't share the IP of DDR controller. I am wondering if there is generic
>> DDR driver used by many ARM platforms, like the one we have for
>> powerpc/mpc85xx SoCs.
> 
> Thinking back, as a rule of thumb, PowerPC has SPD I2C data
> available, usually.  That's not the rule for ARM.  One of a few choices
> happen:
> 1) ROM sets up DDR.
> 2) U-Boot/SPL sets up the DDR controller.
> 

So for ARM platforms, the majority don't have the flexibility of using
different DIMMs and/or clocks?

> The problem is that the DDR controller is usually vendor-specific.
> Perhaps the flip-side here is that there's not so much a generic DDR
> driver for mpc85xx but simply one vendor for mpc85xx.  Taking
> arch/powerpc/cpu/mpc85xx/ddr-gen3.c as what you're talking about,
> arch/arm/cpu/armv7/omap-common/emif-common.c would be an ARM-world
> example (the 'EMIF' is found on a large variety of TI parts, not just
> "omap" ones).

Does it make sense to share the Freescale DDR driver across ARM and
Powerpc? Or does it make more sense to selectively copy the mpc8xxx DDR
driver to Freescale ARM subfolder to start with. If the similarity
sustains then we merge them into common driver. If not, we maintain two
separated drivers.

For those who is not familiar with, Freescale is extending products to
ARM cores. I am expecting peripherals stay relatively close, so many
driver can be reused.

York

[U-Boot] How do ARM platform initialize DDR?

[Tom Rini]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/19/2013 05:08 PM, York Sun wrote:
> On 09/19/2013 01:57 PM, Tom Rini wrote:
>> On Tue, Sep 17, 2013 at 08:59:24AM -0700, York Sun wrote:
>> 
>>> Albert,
>>> 
>>> Pardon me if this is a dumb question. I have been working on
>>> powerpc platforms in the past. Now we (the developers I work
>>> with) are exploring ARM cores. I am searching how memory is
>>> initialized and found different solutions. Some platforms have
>>> memory ready before u-boot even starts, some simply write to a
>>> set of registers. I understand many platforms don't share the
>>> IP of DDR controller. I am wondering if there is generic DDR
>>> driver used by many ARM platforms, like the one we have for 
>>> powerpc/mpc85xx SoCs.
>> 
>> Thinking back, as a rule of thumb, PowerPC has SPD I2C data 
>> available, usually.  That's not the rule for ARM.  One of a few
>> choices happen: 1) ROM sets up DDR. 2) U-Boot/SPL sets up the DDR
>> controller.
>> 
> 
> So for ARM platforms, the majority don't have the flexibility of
> using different DIMMs and/or clocks?

It's a different world.  Again, thinking back to the PowerPC boards
I've seen, they had "regular" DDR sockets.  Most ARM boards don't.
You can design your board with whatever, and I know in prototyping
folks make do swapping chips in and out (and if you look at the omap
code, you can see where we have code to calculate the timing values
and print them, or use provided hard-coded values).

>> The problem is that the DDR controller is usually
>> vendor-specific. Perhaps the flip-side here is that there's not
>> so much a generic DDR driver for mpc85xx but simply one vendor
>> for mpc85xx.  Taking arch/powerpc/cpu/mpc85xx/ddr-gen3.c as what
>> you're talking about, 
>> arch/arm/cpu/armv7/omap-common/emif-common.c would be an
>> ARM-world example (the 'EMIF' is found on a large variety of TI
>> parts, not just "omap" ones).
> 
> Does it make sense to share the Freescale DDR driver across ARM
> and Powerpc? Or does it make more sense to selectively copy the
> mpc8xxx DDR driver to Freescale ARM subfolder to start with. If the
> similarity sustains then we merge them into common driver. If not,
> we maintain two separated drivers.
> 
> For those who is not familiar with, Freescale is extending products
> to ARM cores. I am expecting peripherals stay relatively close, so
> many driver can be reused.

I've been wondering when this would start to be visible.  If we are
able to share the DDR controller code between mpc85xx and the ARM
stuff you're talking about, we'll have to sort out someplace within
drivers/ to place it, to avoid #include nightmares I suspect.  Other
drivers should be easier to share at least :)

- -- 
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSO22RAAoJENk4IS6UOR1WhJYQALM/XAMzPMMH4WJD8PkO7DqJ
HB3WI2oopdm096Bfe8ZT2MPpuEm6OuIb/5HjacED0XxfCHT59NVxIo5tI51IEbqH
74k3LtvTMgADqVw092H3LsFFIJWPd0MsWCDian+NuAp8g03PK9eDOgczQujYflm/
cs6En1hYp+QolbxdHxpQ0HKwNxzA+bkT6JGzF2ziutp8P+wTHh5ypjtFCwF8h4cG
IrGAhePYPHXZzCZYGRPWD0CXthcizXCuRCpykflEGpUsTOR0Cd/2UT0jBFh3aUCU
jalrVG/LjhUWqO+IEzAhOtML4Z84oFLQQ5EBmwAOnt+ql6sxk2+L8kxEMWUzaE23
EppRrT7HDHI/Uc7ogeJP5JNjiYGmmp0dLhqIK3vIJ8pAyenj8TcOW2q0Y7eCrItN
UPJNrYGLKXHC1f5OpfMSJG33lNRJY2oSI+D2ELENMtXBiC9y3nb8Lqar7GjJ6VQq
BJcEbCNUT1IVqvCP/OsYKhtssqHdKYmjfSd9oOHonhwmZTqEyVh08/U1LIfIiYfa
7lody/RNVvnbUKjlojiBR6upJbfGC6YJSDQUzy02zf4gPNF01Q1rXO5fT6vfIa1z
YVM5yV4MJ8F0Phma2uOk25NLgRmDcXeL4LCvpOOQUi3+ymMqMarmZwRdThARsBKh
1tFCkl3LA01CtGdZCzBI
=INiu
-----END PGP SIGNATURE-----

[U-Boot] How do ARM platform initialize DDR?

[Wolfgang Denk]

Dear York Sun,

In message <523B67D2.2050107@freescale.com> you wrote:
>
> So for ARM platforms, the majority don't have the flexibility of using
> different DIMMs and/or clocks?

The majority of ARM systems are embedded designs which never use any
kind of DIMM, but raw soldered-on RAM chips.

> Does it make sense to share the Freescale DDR driver across ARM and
> Powerpc? Or does it make more sense to selectively copy the mpc8xxx DDR
> driver to Freescale ARM subfolder to start with. If the similarity

You are probably in a beter position to answer that than us - how many
ARM systems are there around that use the same memory controller as
the MPC8xxx?

> For those who is not familiar with, Freescale is extending products to
> ARM cores. I am expecting peripherals stay relatively close, so many
> driver can be reused.

Well, I'm not sure which exact products you might have in mind here,
but from what we've seen so far with the i.MX2x (and mxs), i.MX3x,
iMX5x and i.MX6 systems, there are commnon IP blocks like the FEC, but
so far I haven't seen this with the memory controller.

And I haven't seen any single FSL ARM board in our lab yet that was
using any kind ot DIMM or such.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"In Christianity neither morality nor religion come into contact with
reality at any point."                          - Friedrich Nietzsche

[U-Boot] How do ARM platform initialize DDR?

[York Sun]

On 09/19/2013 02:39 PM, Wolfgang Denk wrote:
> Dear York Sun,
> 
> In message <523B67D2.2050107@freescale.com> you wrote:
>>
>> So for ARM platforms, the majority don't have the flexibility of using
>> different DIMMs and/or clocks?
> 
> The majority of ARM systems are embedded designs which never use any
> kind of DIMM, but raw soldered-on RAM chips.

That explains a lot.

> 
>> Does it make sense to share the Freescale DDR driver across ARM and
>> Powerpc? Or does it make more sense to selectively copy the mpc8xxx DDR
>> driver to Freescale ARM subfolder to start with. If the similarity
> 
> You are probably in a beter position to answer that than us - how many
> ARM systems are there around that use the same memory controller as
> the MPC8xxx?

Zero as far as I know. But this is changing and this is why I brought it
up. I don't want to maintain two set of drivers if not necessary.

> 
>> For those who is not familiar with, Freescale is extending products to
>> ARM cores. I am expecting peripherals stay relatively close, so many
>> driver can be reused.
> 
> Well, I'm not sure which exact products you might have in mind here,
> but from what we've seen so far with the i.MX2x (and mxs), i.MX3x,
> iMX5x and i.MX6 systems, there are commnon IP blocks like the FEC, but
> so far I haven't seen this with the memory controller.

I hope I am not revealing a secret. :)
It has been announced that new SoCs are coming. It is still too early.
But I am preparing software for it.

> 
> And I haven't seen any single FSL ARM board in our lab yet that was
> using any kind ot DIMM or such.
> 
Thanks for confirmation. I will let you know once I learn what the board
will look like (not very soon).

York

[U-Boot] How do ARM platform initialize DDR?

[York Sun]

On 09/19/2013 02:33 PM, Tom Rini wrote:
> On 09/19/2013 05:08 PM, York Sun wrote:
>> On 09/19/2013 01:57 PM, Tom Rini wrote:
>>> On Tue, Sep 17, 2013 at 08:59:24AM -0700, York Sun wrote:
>>>
>>>> Albert,
>>>>
>>>> Pardon me if this is a dumb question. I have been working on
>>>> powerpc platforms in the past. Now we (the developers I work
>>>> with) are exploring ARM cores. I am searching how memory is
>>>> initialized and found different solutions. Some platforms have
>>>> memory ready before u-boot even starts, some simply write to a
>>>> set of registers. I understand many platforms don't share the
>>>> IP of DDR controller. I am wondering if there is generic DDR
>>>> driver used by many ARM platforms, like the one we have for 
>>>> powerpc/mpc85xx SoCs.
>>>
>>> Thinking back, as a rule of thumb, PowerPC has SPD I2C data 
>>> available, usually.  That's not the rule for ARM.  One of a few
>>> choices happen: 1) ROM sets up DDR. 2) U-Boot/SPL sets up the DDR
>>> controller.
>>>
> 
>> So for ARM platforms, the majority don't have the flexibility of
>> using different DIMMs and/or clocks?
> 
> It's a different world.  Again, thinking back to the PowerPC boards
> I've seen, they had "regular" DDR sockets.  Most ARM boards don't.
> You can design your board with whatever, and I know in prototyping
> folks make do swapping chips in and out (and if you look at the omap
> code, you can see where we have code to calculate the timing values
> and print them, or use provided hard-coded values).

Understood. We may have boards with DIMM slots. I do see value of a
fully functional DDR driver here.

> 
>>> The problem is that the DDR controller is usually
>>> vendor-specific. Perhaps the flip-side here is that there's not
>>> so much a generic DDR driver for mpc85xx but simply one vendor
>>> for mpc85xx.  Taking arch/powerpc/cpu/mpc85xx/ddr-gen3.c as what
>>> you're talking about, 
>>> arch/arm/cpu/armv7/omap-common/emif-common.c would be an
>>> ARM-world example (the 'EMIF' is found on a large variety of TI
>>> parts, not just "omap" ones).
> 
>> Does it make sense to share the Freescale DDR driver across ARM
>> and Powerpc? Or does it make more sense to selectively copy the
>> mpc8xxx DDR driver to Freescale ARM subfolder to start with. If the
>> similarity sustains then we merge them into common driver. If not,
>> we maintain two separated drivers.
> 
>> For those who is not familiar with, Freescale is extending products
>> to ARM cores. I am expecting peripherals stay relatively close, so
>> many driver can be reused.
> 
> I've been wondering when this would start to be visible.  If we are
> able to share the DDR controller code between mpc85xx and the ARM
> stuff you're talking about, we'll have to sort out someplace within
> drivers/ to place it, to avoid #include nightmares I suspect.  Other
> drivers should be easier to share at least :)
> 

I did a quick and dirty hack yesterday to move DDR driver to
drivers/ddr/fsl. I had to change many #include <asm/????>.

York

[U-Boot] How do ARM platform initialize DDR?

[Mj Embd]

Hi York,

I was thinking about your problem and this could be a solution
mpc85xx uses a family of ddr controllers.
I believe they would be migrated to LayerScape,

Freescale has also i.mx4/5/6 series and coming i.mx8, that series
uses/might use another ddr controller

Option1
As you suggested which looks a worthy option.
 ddr/fsl/contoller1/ --- for 85xx
 ddr/fsl/contoller2/ --- for I.mx

in your board config file, you might want to use
 CONFIG_DDR_CONTROLLER_MPC85xx
or CONFIG_DDR_CONTROLLER_IMX

PS: I see no direct relation between ddr controller and core, also
freescale is going core agnostic so I think the ddr controller be moved
from cpu folder to driver/ddr folder.

-Regards
mj


On Fri, Sep 20, 2013 at 3:19 AM, York Sun <yorksun@freescale.com> wrote:

> On 09/19/2013 02:33 PM, Tom Rini wrote:
> > On 09/19/2013 05:08 PM, York Sun wrote:
> >> On 09/19/2013 01:57 PM, Tom Rini wrote:
> >>> On Tue, Sep 17, 2013 at 08:59:24AM -0700, York Sun wrote:
> >>>
> >>>> Albert,
> >>>>
> >>>> Pardon me if this is a dumb question. I have been working on
> >>>> powerpc platforms in the past. Now we (the developers I work
> >>>> with) are exploring ARM cores. I am searching how memory is
> >>>> initialized and found different solutions. Some platforms have
> >>>> memory ready before u-boot even starts, some simply write to a
> >>>> set of registers. I understand many platforms don't share the
> >>>> IP of DDR controller. I am wondering if there is generic DDR
> >>>> driver used by many ARM platforms, like the one we have for
> >>>> powerpc/mpc85xx SoCs.
> >>>
> >>> Thinking back, as a rule of thumb, PowerPC has SPD I2C data
> >>> available, usually.  That's not the rule for ARM.  One of a few
> >>> choices happen: 1) ROM sets up DDR. 2) U-Boot/SPL sets up the DDR
> >>> controller.
> >>>
> >
> >> So for ARM platforms, the majority don't have the flexibility of
> >> using different DIMMs and/or clocks?
> >
> > It's a different world.  Again, thinking back to the PowerPC boards
> > I've seen, they had "regular" DDR sockets.  Most ARM boards don't.
> > You can design your board with whatever, and I know in prototyping
> > folks make do swapping chips in and out (and if you look at the omap
> > code, you can see where we have code to calculate the timing values
> > and print them, or use provided hard-coded values).
>
> Understood. We may have boards with DIMM slots. I do see value of a
> fully functional DDR driver here.
>
> >
> >>> The problem is that the DDR controller is usually
> >>> vendor-specific. Perhaps the flip-side here is that there's not
> >>> so much a generic DDR driver for mpc85xx but simply one vendor
> >>> for mpc85xx.  Taking arch/powerpc/cpu/mpc85xx/ddr-gen3.c as what
> >>> you're talking about,
> >>> arch/arm/cpu/armv7/omap-common/emif-common.c would be an
> >>> ARM-world example (the 'EMIF' is found on a large variety of TI
> >>> parts, not just "omap" ones).
> >
> >> Does it make sense to share the Freescale DDR driver across ARM
> >> and Powerpc? Or does it make more sense to selectively copy the
> >> mpc8xxx DDR driver to Freescale ARM subfolder to start with. If the
> >> similarity sustains then we merge them into common driver. If not,
> >> we maintain two separated drivers.
> >
> >> For those who is not familiar with, Freescale is extending products
> >> to ARM cores. I am expecting peripherals stay relatively close, so
> >> many driver can be reused.
> >
> > I've been wondering when this would start to be visible.  If we are
> > able to share the DDR controller code between mpc85xx and the ARM
> > stuff you're talking about, we'll have to sort out someplace within
> > drivers/ to place it, to avoid #include nightmares I suspect.  Other
> > drivers should be easier to share at least :)
> >
>
> I did a quick and dirty hack yesterday to move DDR driver to
> drivers/ddr/fsl. I had to change many #include <asm/????>.
>
> York
>
>
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>



-- 
-mj

[U-Boot] How do ARM platform initialize DDR?

[Timur Tabi]

On Tue, Sep 17, 2013 at 10:59 AM, York Sun <yorksun@freescale.com> wrote:
> I am wondering if there is generic
> DDR driver used by many ARM platforms, like the one we have for
> powerpc/mpc85xx SoCs.

Sadly, no such thing exists.  There is no generic DDR controller for
ARM.  I'm working on DDR controller support for our ARM chips, and
it's nowhere near as elegant as Freescale's PowerPC parts.  In our
case, we have firmware running in the chip that does DDR
initialization and then loads u-boot.bin from a SPI flash into DDR,
and then it boots the main processor.

[U-Boot] How do ARM platform initialize DDR?

[Timur Tabi]

On Thu, Sep 19, 2013 at 3:57 PM, Tom Rini <trini@ti.com> wrote:
>
> Thinking back, as a rule of thumb, PowerPC has SPD I2C data
> available, usually.  That's not the rule for ARM.  One of a few choices
> happen:

Even if you do have SPD on your ARM chip, that's still no guarantee
that you can program the DDR controller properly.  On our chips, we
have to have a table of 300+ for each frequency that we support, and
the SPD only lets us tweak a few registers to account for different
size DIMMs.

[U-Boot] How do ARM platform initialize DDR?

[Wolfgang Denk]

Dear Timur,

In message <CAOZdJXVDf7Z7Ya8p4nkybp1wJ1cnMTs736cEtRNp_9yQYgQ68A@mail.gmail.com> you wrote:
> On Tue, Sep 17, 2013 at 10:59 AM, York Sun <yorksun@freescale.com> wrote:
> > I am wondering if there is generic
> > DDR driver used by many ARM platforms, like the one we have for
> > powerpc/mpc85xx SoCs.
> 
> Sadly, no such thing exists.  There is no generic DDR controller for
> ARM.  I'm working on DDR controller support for our ARM chips, and
> it's nowhere near as elegant as Freescale's PowerPC parts.  In our

MPC85xx is just one family of processors.  And I don't think you
really want to claim that all Freescale's PowerPC processors use the
same memory controller?  Try and compare the memory controllers (and
the required initialization sequences) for just a selection of
MPC8xx, MPC82xx, MPC83xx, MPC85xx.

And even if some parts use the same IP block, usually the register
interfaces to it are sufficiently different to make common code a
challenge at least (compare MPC5121 and MPC5125).

Yes, some of the later modes share more common IP blocks, but PowerPC
is in no way better than ARM in this respect - the difference is only,
that there are way more different ARM SoCs than there ver have been
PPC ones, so the problems become more visible.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A man is not complete until he is married -- then he is finished.

[U-Boot] When to create a SoC directory for ARM

[York Sun]

Dear Wolfgang,

I failed to find the guideline, here is my question. Pardon me if this
is a dump question as I am still new to ARM.

As David Feng post his patch set to add ARMv8 support, I am trying to
enable it for Freescale implementation. Let's name it as LS2 for this
discussion. I am thinking to reuse as much as possible for existing
codes, which include copying some header files from powerpc partially. I
noticed the SoC field in boards.cfg file and I am wondering how to use
it effectively. I want to put LS2 specific headers to
arch/arm/include/asm/arch-ls2. Do I need to copy all files from
arch/arm/include/asm/arch-armv8/? There aren't many but I see mmu.h is
included in start.S. I have been searching case like this in ARMv7 but
didn't see shared header file (maybe I missed it). Please advise.

Regards,

York

[U-Boot] When to create a SoC directory for ARM

[Scott Wood]

On Wed, 2013-09-25 at 16:30 -0700, York Sun wrote:
> Dear Wolfgang,
> 
> I failed to find the guideline, here is my question. Pardon me if this
> is a dump question as I am still new to ARM.
> 
> As David Feng post his patch set to add ARMv8 support, I am trying to
> enable it for Freescale implementation. Let's name it as LS2 for this
> discussion. I am thinking to reuse as much as possible for existing
> codes, which include copying some header files from powerpc partially. I
> noticed the SoC field in boards.cfg file and I am wondering how to use
> it effectively. I want to put LS2 specific headers to
> arch/arm/include/asm/arch-ls2. Do I need to copy all files from
> arch/arm/include/asm/arch-armv8/? There aren't many but I see mmu.h is
> included in start.S. I have been searching case like this in ARMv7 but
> didn't see shared header file (maybe I missed it). Please advise.

LS2 is (or perhaps more accurately, contains) an implementation of
ARMv8, so you should be using arch-armv8 rather than copying it.

-Scott

[U-Boot] When to create a SoC directory for ARM

[sun york-R58495]

On Sep 25, 2013, at 4:52 PM, Scott Wood wrote:

> On Wed, 2013-09-25 at 16:30 -0700, York Sun wrote:
>> Dear Wolfgang,
>> 
>> I failed to find the guideline, here is my question. Pardon me if this
>> is a dump question as I am still new to ARM.
>> 
>> As David Feng post his patch set to add ARMv8 support, I am trying to
>> enable it for Freescale implementation. Let's name it as LS2 for this
>> discussion. I am thinking to reuse as much as possible for existing
>> codes, which include copying some header files from powerpc partially. I
>> noticed the SoC field in boards.cfg file and I am wondering how to use
>> it effectively. I want to put LS2 specific headers to
>> arch/arm/include/asm/arch-ls2. Do I need to copy all files from
>> arch/arm/include/asm/arch-armv8/? There aren't many but I see mmu.h is
>> included in start.S. I have been searching case like this in ARMv7 but
>> didn't see shared header file (maybe I missed it). Please advise.
> 
> LS2 is (or perhaps more accurately, contains) an implementation of
> ARMv8, so you should be using arch-armv8 rather than copying it.

True. But I guess LS2 won't be the only "LS" Freescale is going to make. Where is the best place to put the header file for chassis related registers, like CCSR we have for mpc8xxx. I am thinking the best place is arch/arm/include/asm/ls2 (or a better name). Like other ARMv7 variants, I am thinking to put ls2 under arch/arm/cpu/armv8/ as well, to host LS-specific code.

York

[U-Boot] When to create a SoC directory for ARM

[Scott Wood]

On Wed, 2013-09-25 at 20:04 -0500, sun york-R58495 wrote:
> On Sep 25, 2013, at 4:52 PM, Scott Wood wrote:
> 
> > On Wed, 2013-09-25 at 16:30 -0700, York Sun wrote:
> >> Dear Wolfgang,
> >> 
> >> I failed to find the guideline, here is my question. Pardon me if this
> >> is a dump question as I am still new to ARM.
> >> 
> >> As David Feng post his patch set to add ARMv8 support, I am trying to
> >> enable it for Freescale implementation. Let's name it as LS2 for this
> >> discussion. I am thinking to reuse as much as possible for existing
> >> codes, which include copying some header files from powerpc partially. I
> >> noticed the SoC field in boards.cfg file and I am wondering how to use
> >> it effectively. I want to put LS2 specific headers to
> >> arch/arm/include/asm/arch-ls2. Do I need to copy all files from
> >> arch/arm/include/asm/arch-armv8/? There aren't many but I see mmu.h is
> >> included in start.S. I have been searching case like this in ARMv7 but
> >> didn't see shared header file (maybe I missed it). Please advise.
> > 
> > LS2 is (or perhaps more accurately, contains) an implementation of
> > ARMv8, so you should be using arch-armv8 rather than copying it.
> 
> True. But I guess LS2 won't be the only "LS" Freescale is going to
> make. Where is the best place to put the header file for chassis
> related registers, like CCSR we have for mpc8xxx.

Anything that isn't deeply tied to the ARM architecture should probably
just go in include/.

>  I am thinking the
> best place is arch/arm/include/asm/ls2 (or a better name). Like other
> ARMv7 variants, I am thinking to put ls2 under arch/arm/cpu/armv8/ as
> well, to host LS-specific code.

Likewise, if it's specifically tied to armv8 it should go in
arch/arm/include/asm/arch-armv8, but I'm not sure what would be tied to
both armv8 and ls2.  Most likely anything LS-specific that needs to go
under arch/arm/ should go somewhere like arch/arm/include/asm/ls/
(similar to arch/arm/include/asm/imx-common).

-Scott

[U-Boot] When to create a SoC directory for ARM

[FengHua]

> Date: Wed, 25 Sep 2013 20:10:13 -0500
> From: Scott Wood <scottwood@freescale.com>
> Subject: Re: [U-Boot] When to create a SoC directory for ARM
> To: sun york-R58495 <R58495@freescale.com>
> Cc: Rini <trini@ti.com>, Wood Scott-B07421 <B07421@freescale.com>,
> 	"u-boot at lists.denx.de" <u-boot@lists.denx.de>, Tom
> Message-ID: <1380157813.24959.237.camel@snotra.buserror.net>
> Content-Type: text/plain; charset="UTF-8"
> On Wed, 2013-09-25 at 20:04 -0500, sun york-R58495 wrote:
> > On Sep 25, 2013, at 4:52 PM, Scott Wood wrote:
> > 
> > > On Wed, 2013-09-25 at 16:30 -0700, York Sun wrote:
> > >> Dear Wolfgang,
> > >> 
> > >> I failed to find the guideline, here is my question. Pardon me if this
> > >> is a dump question as I am still new to ARM.
> > >> 
> > >> As David Feng post his patch set to add ARMv8 support, I am trying to
> > >> enable it for Freescale implementation. Let's name it as LS2 for this
> > >> discussion. I am thinking to reuse as much as possible for existing
> > >> codes, which include copying some header files from powerpc partially. I
> > >> noticed the SoC field in boards.cfg file and I am wondering how to use
> > >> it effectively. I want to put LS2 specific headers to
> > >> arch/arm/include/asm/arch-ls2. Do I need to copy all files from
> > >> arch/arm/include/asm/arch-armv8/? There aren't many but I see mmu.h is
> > >> included in start.S. I have been searching case like this in ARMv7 but
> > >> didn't see shared header file (maybe I missed it). Please advise.
> > > 
> > > LS2 is (or perhaps more accurately, contains) an implementation of
> > > ARMv8, so you should be using arch-armv8 rather than copying it.
> > 
> > True. But I guess LS2 won't be the only "LS" Freescale is going to
> > make. Where is the best place to put the header file for chassis
> > related registers, like CCSR we have for mpc8xxx.
> Anything that isn't deeply tied to the ARM architecture should probably
> just go in include/.
> >  I am thinking the
> > best place is arch/arm/include/asm/ls2 (or a better name). Like other
> > ARMv7 variants, I am thinking to put ls2 under arch/arm/cpu/armv8/ as
> > well, to host LS-specific code.

> Likewise, if it's specifically tied to armv8 it should go in
> arch/arm/include/asm/arch-armv8, but I'm not sure what would be tied to
> both armv8 and ls2.  Most likely anything LS-specific that needs to go
> under arch/arm/ should go somewhere like arch/arm/include/asm/ls/
> (similar to arch/arm/include/asm/imx-common).

> -Scott
all SOC specific include file should be in arch/arm/include/asm/arch-SOC/ or
some common directory(like include/asm/imx-common). Currently, u-boot only link SOC specific(arch-SOC) include directory.
You could touch a mmu.h file in arch/arm/include/asm/arch-ls2/ and include
arch/arm/include/asm/arch-armv8/mmu.h.
or move arch-armv8/mmu.h to arch/arm/include/asm/ to make it as a generic file.
Maybe we should distinguish architecture specific include directory and SOC
 specific include directory.


-David

[U-Boot] When to create a SoC directory for ARM

[sun york-R58495]

On Sep 25, 2013, at 10:23 PM, FengHua wrote:

> > Date: Wed, 25 Sep 2013 20:10:13 -0500
> > From: Scott Wood <scottwood@freescale.com>
> > Subject: Re: [U-Boot] When to create a SoC directory for ARM
> > To: sun york-R58495 <R58495@freescale.com>
> > Cc: Rini <trini@ti.com>, Wood Scott-B07421 <B07421@freescale.com>,
> > 	"u-boot at lists.denx.de" <u-boot@lists.denx.de>, Tom
> > Message-ID: <1380157813.24959.237.camel@snotra.buserror.net>
> > Content-Type: text/plain; charset="UTF-8"
> 
> > On Wed, 2013-09-25 at 20:04 -0500, sun york-R58495 wrote:
> > > On Sep 25, 2013, at 4:52 PM, Scott Wood wrote:
> > > 
> > > > On Wed, 2013-09-25 at 16:30 -0700, York Sun wrote:
> > > >> Dear Wolfgang,
> > > >> 
> > > >> I failed to find the guideline, here is my question. Pardon me if this
> > > >> is a dump question as I am still new to ARM.
> > > >> 
> > > >> As David Feng post his patch set to add ARMv8 support, I am trying to
> > > >> enable it for Freescale implementation. Let's name it as LS2 for this
> > > >> discussion. I am thinking to reuse as much as possible for existing
> > > >> codes, which include copying some header files from powerpc partially. I
> > > >> noticed the SoC field in boards.cfg file and I am wondering how to use
> > > >> it effectively. I want to put LS2 specific headers to
> > > >> arch/arm/include/asm/arch-ls2. Do I need to copy all files from
> > > >> arch/arm/include/asm/arch-armv8/? There aren't many but I see mmu.h is
> > > >> included in start.S. I have been searching case like this in ARMv7 but
> > > >> didn't see shared header file (maybe I missed it). Please advise.
> > > > 
> > > > LS2 is (or perhaps more accurately, contains) an implementation of
> > > > ARMv8, so you should be using arch-armv8 rather than copying it.
> > > 
> > > True. But I guess LS2 won't be the only "LS" Freescale is going to
> > > make. Where is the best place to put the header file for chassis
> > > related registers, like CCSR we have for mpc8xxx.
> 
> > Anything that isn't deeply tied to the ARM architecture should probably
> > just go in include/.
> > >  I am thinking the
> > > best place is arch/arm/include/asm/ls2 (or a better name). Like other
> > > ARMv7 variants, I am thinking to put ls2 under arch/arm/cpu/armv8/ as
> > > well, to host LS-specific code.
> 
> > Likewise, if it's specifically tied to armv8 it should go in
> > arch/arm/include/asm/arch-armv8, but I'm not sure what would be tied to
> > both armv8 and ls2.  Most likely anything LS-specific that needs to go
> > under arch/arm/ should go somewhere like arch/arm/include/asm/ls/
> > (similar to arch/arm/include/asm/imx-common).
> 
> > -Scott
> 
> all SOC specific include file should be in arch/arm/include/asm/arch-SOC/ or
> some common directory(like include/asm/imx-common). Currently, u-boot only link SOC specific(arch-SOC) include directory.
> You could touch a mmu.h file in arch/arm/include/asm/arch-ls2/ and include
> arch/arm/include/asm/arch-armv8/mmu.h.
> or move arch-armv8/mmu.h to arch/arm/include/asm/ to make it as a generic file.
> Maybe we should distinguish architecture specific include directory and SOC
>  specific include directory.


I was thinking to change the include in start.S to

#include <asm/arch-armv8/mmu.h>

York

[U-Boot] When to create a SoC directory for ARM

[Wolfgang Denk]

Dear York,

In message <52437209.9020008@freescale.com> you wrote:
> 
> As David Feng post his patch set to add ARMv8 support, I am trying to
> enable it for Freescale implementation. Let's name it as LS2 for this
> discussion. I am thinking to reuse as much as possible for existing
> codes, which include copying some header files from powerpc partially. I

Please do NOT copy files. If these are shared, then move them to a
common location and make all code reference this.

> noticed the SoC field in boards.cfg file and I am wondering how to use
> it effectively. I want to put LS2 specific headers to
> arch/arm/include/asm/arch-ls2. Do I need to copy all files from
> arch/arm/include/asm/arch-armv8/? There aren't many but I see mmu.h is

Same here: never ever create copies of existing files.  Movce them to
a common location and make all code reference this single copy.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
8 Catfish                                               = 1 Octo-puss

[U-Boot] When to create a SoC directory for ARM

[FengHua]

> -----????-----
> ???: "sun york-R58495" <R58495@freescale.com>
> ????: 2013?9?26? ???
> ???: FengHua <fenghua@phytium.com.cn>
> ??: "albert.u.boot" <albert.u.boot@aribaud.net>, trini <trini@ti.com>, "Wood
>  Scott-B07421" <B07421@freescale.com>, u-boot <u-boot@lists.denx.de>
> ??: Re: [U-Boot] When to create a SoC directory for ARM
> 
> 
> On Sep 25, 2013, at 10:23 PM, FengHua wrote:
> 
> > > Date: Wed, 25 Sep 2013 20:10:13 -0500
> > > From: Scott Wood <scottwood@freescale.com>
> > > Subject: Re: [U-Boot] When to create a SoC directory for ARM
> > > To: sun york-R58495 <R58495@freescale.com>
> > > Cc: Rini <trini@ti.com>, Wood Scott-B07421 <B07421@freescale.com>,
> > > 	"u-boot at lists.denx.de" <u-boot@lists.denx.de>, Tom
> > > Message-ID: <1380157813.24959.237.camel@snotra.buserror.net>
> > > Content-Type: text/plain; charset="UTF-8"
> > 
> > > On Wed, 2013-09-25 at 20:04 -0500, sun york-R58495 wrote:
> > > > On Sep 25, 2013, at 4:52 PM, Scott Wood wrote:
> > > > 
> > > > > On Wed, 2013-09-25 at 16:30 -0700, York Sun wrote:
> > > > >> Dear Wolfgang,
> > > > >> 
> > > > >> I failed to find the guideline, here is my question. Pardon me if this
> > > > >> is a dump question as I am still new to ARM.
> > > > >> 
> > > > >> As David Feng post his patch set to add ARMv8 support, I am trying to
> > > > >> enable it for Freescale implementation. Let's name it as LS2 for this
> > > > >> discussion. I am thinking to reuse as much as possible for existing
> > > > >> codes, which include copying some header files from powerpc partially. I
> > > > >> noticed the SoC field in boards.cfg file and I am wondering how to use
> > > > >> it effectively. I want to put LS2 specific headers to
> > > > >> arch/arm/include/asm/arch-ls2. Do I need to copy all files from
> > > > >> arch/arm/include/asm/arch-armv8/? There aren't many but I see mmu.h is
> > > > >> included in start.S. I have been searching case like this in ARMv7 but
> > > > >> didn't see shared header file (maybe I missed it). Please advise.
> > > > > 
> > > > > LS2 is (or perhaps more accurately, contains) an implementation of
> > > > > ARMv8, so you should be using arch-armv8 rather than copying it.
> > > > 
> > > > True. But I guess LS2 won't be the only "LS" Freescale is going to
> > > > make. Where is the best place to put the header file for chassis
> > > > related registers, like CCSR we have for mpc8xxx.
> > 
> > > Anything that isn't deeply tied to the ARM architecture should probably
> > > just go in include/.
> > > >  I am thinking the
> > > > best place is arch/arm/include/asm/ls2 (or a better name). Like other
> > > > ARMv7 variants, I am thinking to put ls2 under arch/arm/cpu/armv8/ as
> > > > well, to host LS-specific code.
> > 
> > > Likewise, if it's specifically tied to armv8 it should go in
> > > arch/arm/include/asm/arch-armv8, but I'm not sure what would be tied to
> > > both armv8 and ls2.  Most likely anything LS-specific that needs to go
> > > under arch/arm/ should go somewhere like arch/arm/include/asm/ls/
> > > (similar to arch/arm/include/asm/imx-common).
> > 
> > > -Scott
> > 
> > all SOC specific include file should be in arch/arm/include/asm/arch-SOC/ or
> > some common directory(like include/asm/imx-common). Currently, u-boot only link SOC specific(arch-SOC) include directory.
> > You could touch a mmu.h file in arch/arm/include/asm/arch-ls2/ and include
> > arch/arm/include/asm/arch-armv8/mmu.h.
> > or move arch-armv8/mmu.h to arch/arm/include/asm/ to make it as a generic file.
> > Maybe we should distinguish architecture specific include directory and SOC
> >  specific include directory.
> 
> 
> I was thinking to change the include in start.S to
> 
> #include <asm/arch-armv8/mmu.h>
> 

The current arch-armv8/mum.h is based on armv8 architecture.
Maybe just maybe some armv8 processor will not implement some features of it
for example 64K page size, then it do not works.
So, maybe it's better to touch a mmu.h file in include/asm/arch_SOC and 
include arch-armv8/mmu.h or make different implementation.

Regards,
David

[U-Boot] When to create a SoC directory for ARM

[York Sun]

On 09/26/2013 03:49 AM, FengHua wrote:
> 
> 
> 
>> -----????-----
>> ???: "sun york-R58495" <R58495@freescale.com>
>> ????: 2013?9?26? ???
>> ???: FengHua <fenghua@phytium.com.cn>
>> ??: "albert.u.boot" <albert.u.boot@aribaud.net>, trini <trini@ti.com>, "Wood
>>  Scott-B07421" <B07421@freescale.com>, u-boot <u-boot@lists.denx.de>
>> ??: Re: [U-Boot] When to create a SoC directory for ARM
>>
>>
>> On Sep 25, 2013, at 10:23 PM, FengHua wrote:
>>
>>>> Date: Wed, 25 Sep 2013 20:10:13 -0500
>>>> From: Scott Wood <scottwood@freescale.com>
>>>> Subject: Re: [U-Boot] When to create a SoC directory for ARM
>>>> To: sun york-R58495 <R58495@freescale.com>
>>>> Cc: Rini <trini@ti.com>, Wood Scott-B07421 <B07421@freescale.com>,
>>>> 	"u-boot at lists.denx.de" <u-boot@lists.denx.de>, Tom
>>>> Message-ID: <1380157813.24959.237.camel@snotra.buserror.net>
>>>> Content-Type: text/plain; charset="UTF-8"
>>>
>>>> On Wed, 2013-09-25 at 20:04 -0500, sun york-R58495 wrote:
>>>>> On Sep 25, 2013, at 4:52 PM, Scott Wood wrote:
>>>>>
>>>>>> On Wed, 2013-09-25 at 16:30 -0700, York Sun wrote:
>>>>>>> Dear Wolfgang,
>>>>>>>
>>>>>>> I failed to find the guideline, here is my question. Pardon me if this
>>>>>>> is a dump question as I am still new to ARM.
>>>>>>>
>>>>>>> As David Feng post his patch set to add ARMv8 support, I am trying to
>>>>>>> enable it for Freescale implementation. Let's name it as LS2 for this
>>>>>>> discussion. I am thinking to reuse as much as possible for existing
>>>>>>> codes, which include copying some header files from powerpc partially. I
>>>>>>> noticed the SoC field in boards.cfg file and I am wondering how to use
>>>>>>> it effectively. I want to put LS2 specific headers to
>>>>>>> arch/arm/include/asm/arch-ls2. Do I need to copy all files from
>>>>>>> arch/arm/include/asm/arch-armv8/? There aren't many but I see mmu.h is
>>>>>>> included in start.S. I have been searching case like this in ARMv7 but
>>>>>>> didn't see shared header file (maybe I missed it). Please advise.
>>>>>>
>>>>>> LS2 is (or perhaps more accurately, contains) an implementation of
>>>>>> ARMv8, so you should be using arch-armv8 rather than copying it.
>>>>>
>>>>> True. But I guess LS2 won't be the only "LS" Freescale is going to
>>>>> make. Where is the best place to put the header file for chassis
>>>>> related registers, like CCSR we have for mpc8xxx.
>>>
>>>> Anything that isn't deeply tied to the ARM architecture should probably
>>>> just go in include/.
>>>>>  I am thinking the
>>>>> best place is arch/arm/include/asm/ls2 (or a better name). Like other
>>>>> ARMv7 variants, I am thinking to put ls2 under arch/arm/cpu/armv8/ as
>>>>> well, to host LS-specific code.
>>>
>>>> Likewise, if it's specifically tied to armv8 it should go in
>>>> arch/arm/include/asm/arch-armv8, but I'm not sure what would be tied to
>>>> both armv8 and ls2.  Most likely anything LS-specific that needs to go
>>>> under arch/arm/ should go somewhere like arch/arm/include/asm/ls/
>>>> (similar to arch/arm/include/asm/imx-common).
>>>
>>>> -Scott
>>>
>>> all SOC specific include file should be in arch/arm/include/asm/arch-SOC/ or
>>> some common directory(like include/asm/imx-common). Currently, u-boot only link SOC specific(arch-SOC) include directory.
>>> You could touch a mmu.h file in arch/arm/include/asm/arch-ls2/ and include
>>> arch/arm/include/asm/arch-armv8/mmu.h.
>>> or move arch-armv8/mmu.h to arch/arm/include/asm/ to make it as a generic file.
>>> Maybe we should distinguish architecture specific include directory and SOC
>>>  specific include directory.
>>
>>
>> I was thinking to change the include in start.S to
>>
>> #include <asm/arch-armv8/mmu.h>
>>
> 
> The current arch-armv8/mum.h is based on armv8 architecture.
> Maybe just maybe some armv8 processor will not implement some features of it
> for example 64K page size, then it do not works.
> So, maybe it's better to touch a mmu.h file in include/asm/arch_SOC and 
> include arch-armv8/mmu.h or make different implementation.
> 
I think it is OK right now. It can be a subset or superset, as far as
there is no conflict. We will see when we have more SoCs.

York

[U-Boot] When to create a SoC directory for ARM

[York Sun]

On 09/26/2013 03:49 AM, FengHua wrote:
> 
> 
> 
>> -----????-----
>> ???: "sun york-R58495" <R58495@freescale.com>
>> ????: 2013?9?26? ???
>> ???: FengHua <fenghua@phytium.com.cn>
>> ??: "albert.u.boot" <albert.u.boot@aribaud.net>, trini <trini@ti.com>, "Wood
>>  Scott-B07421" <B07421@freescale.com>, u-boot <u-boot@lists.denx.de>
>> ??: Re: [U-Boot] When to create a SoC directory for ARM
>>
>>
>> On Sep 25, 2013, at 10:23 PM, FengHua wrote:
>>
>>>> Date: Wed, 25 Sep 2013 20:10:13 -0500
>>>> From: Scott Wood <scottwood@freescale.com>
>>>> Subject: Re: [U-Boot] When to create a SoC directory for ARM
>>>> To: sun york-R58495 <R58495@freescale.com>
>>>> Cc: Rini <trini@ti.com>, Wood Scott-B07421 <B07421@freescale.com>,
>>>> 	"u-boot at lists.denx.de" <u-boot@lists.denx.de>, Tom
>>>> Message-ID: <1380157813.24959.237.camel@snotra.buserror.net>
>>>> Content-Type: text/plain; charset="UTF-8"
>>>
>>>> On Wed, 2013-09-25 at 20:04 -0500, sun york-R58495 wrote:
>>>>> On Sep 25, 2013, at 4:52 PM, Scott Wood wrote:
>>>>>
>>>>>> On Wed, 2013-09-25 at 16:30 -0700, York Sun wrote:
>>>>>>> Dear Wolfgang,
>>>>>>>
>>>>>>> I failed to find the guideline, here is my question. Pardon me if this
>>>>>>> is a dump question as I am still new to ARM.
>>>>>>>
>>>>>>> As David Feng post his patch set to add ARMv8 support, I am trying to
>>>>>>> enable it for Freescale implementation. Let's name it as LS2 for this
>>>>>>> discussion. I am thinking to reuse as much as possible for existing
>>>>>>> codes, which include copying some header files from powerpc partially. I
>>>>>>> noticed the SoC field in boards.cfg file and I am wondering how to use
>>>>>>> it effectively. I want to put LS2 specific headers to
>>>>>>> arch/arm/include/asm/arch-ls2. Do I need to copy all files from
>>>>>>> arch/arm/include/asm/arch-armv8/? There aren't many but I see mmu.h is
>>>>>>> included in start.S. I have been searching case like this in ARMv7 but
>>>>>>> didn't see shared header file (maybe I missed it). Please advise.
>>>>>>
>>>>>> LS2 is (or perhaps more accurately, contains) an implementation of
>>>>>> ARMv8, so you should be using arch-armv8 rather than copying it.
>>>>>
>>>>> True. But I guess LS2 won't be the only "LS" Freescale is going to
>>>>> make. Where is the best place to put the header file for chassis
>>>>> related registers, like CCSR we have for mpc8xxx.
>>>
>>>> Anything that isn't deeply tied to the ARM architecture should probably
>>>> just go in include/.
>>>>>  I am thinking the
>>>>> best place is arch/arm/include/asm/ls2 (or a better name). Like other
>>>>> ARMv7 variants, I am thinking to put ls2 under arch/arm/cpu/armv8/ as
>>>>> well, to host LS-specific code.
>>>
>>>> Likewise, if it's specifically tied to armv8 it should go in
>>>> arch/arm/include/asm/arch-armv8, but I'm not sure what would be tied to
>>>> both armv8 and ls2.  Most likely anything LS-specific that needs to go
>>>> under arch/arm/ should go somewhere like arch/arm/include/asm/ls/
>>>> (similar to arch/arm/include/asm/imx-common).
>>>
>>>> -Scott
>>>
>>> all SOC specific include file should be in arch/arm/include/asm/arch-SOC/ or
>>> some common directory(like include/asm/imx-common). Currently, u-boot only link SOC specific(arch-SOC) include directory.
>>> You could touch a mmu.h file in arch/arm/include/asm/arch-ls2/ and include
>>> arch/arm/include/asm/arch-armv8/mmu.h.
>>> or move arch-armv8/mmu.h to arch/arm/include/asm/ to make it as a generic file.
>>> Maybe we should distinguish architecture specific include directory and SOC
>>>  specific include directory.
>>
>>
>> I was thinking to change the include in start.S to
>>
>> #include <asm/arch-armv8/mmu.h>
>>
> 
> The current arch-armv8/mum.h is based on armv8 architecture.
> Maybe just maybe some armv8 processor will not implement some features of it
> for example 64K page size, then it do not works.
> So, maybe it's better to touch a mmu.h file in include/asm/arch_SOC and 
> include arch-armv8/mmu.h or make different implementation.

How does the arch-xxx work in general? I found no example to use header
files from both asm/arch-xxx and asm/arch directories.

York

[U-Boot] When to create a SoC directory for ARM

[Scott Wood]

On Thu, 2013-09-26 at 13:23 +0800, FengHua wrote:
> > Date: Wed, 25 Sep 2013 20:10:13 -0500
> > From: Scott Wood <scottwood@freescale.com>
> > Subject: Re: [U-Boot] When to create a SoC directory for ARM
> > To: sun york-R58495 <R58495@freescale.com>
> > Cc: Rini <trini@ti.com>, Wood Scott-B07421 <B07421@freescale.com>,
> > 	"u-boot at lists.denx.de" <u-boot@lists.denx.de>, Tom
> > Message-ID: <1380157813.24959.237.camel@snotra.buserror.net>
> > Content-Type: text/plain; charset="UTF-8"
> > On Wed, 2013-09-25 at 20:04 -0500, sun york-R58495 wrote:
> > > On Sep 25, 2013, at 4:52 PM, Scott Wood wrote:
> > > 
> > > > On Wed, 2013-09-25 at 16:30 -0700, York Sun wrote:
> > > >> Dear Wolfgang,
> > > >> 
> > > >> I failed to find the guideline, here is my question. Pardon me if this
> > > >> is a dump question as I am still new to ARM.
> > > >> 
> > > >> As David Feng post his patch set to add ARMv8 support, I am trying to
> > > >> enable it for Freescale implementation. Let's name it as LS2 for this
> > > >> discussion. I am thinking to reuse as much as possible for existing
> > > >> codes, which include copying some header files from powerpc partially. I
> > > >> noticed the SoC field in boards.cfg file and I am wondering how to use
> > > >> it effectively. I want to put LS2 specific headers to
> > > >> arch/arm/include/asm/arch-ls2. Do I need to copy all files from
> > > >> arch/arm/include/asm/arch-armv8/? There aren't many but I see mmu.h is
> > > >> included in start.S. I have been searching case like this in ARMv7 but
> > > >> didn't see shared header file (maybe I missed it). Please advise.
> > > > 
> > > > LS2 is (or perhaps more accurately, contains) an implementation of
> > > > ARMv8, so you should be using arch-armv8 rather than copying it.
> > > 
> > > True. But I guess LS2 won't be the only "LS" Freescale is going to
> > > make. Where is the best place to put the header file for chassis
> > > related registers, like CCSR we have for mpc8xxx.
> > Anything that isn't deeply tied to the ARM architecture should probably
> > just go in include/.
> > >  I am thinking the
> > > best place is arch/arm/include/asm/ls2 (or a better name). Like other
> > > ARMv7 variants, I am thinking to put ls2 under arch/arm/cpu/armv8/ as
> > > well, to host LS-specific code.
> 
> > Likewise, if it's specifically tied to armv8 it should go in
> > arch/arm/include/asm/arch-armv8, but I'm not sure what would be tied to
> > both armv8 and ls2.  Most likely anything LS-specific that needs to go
> > under arch/arm/ should go somewhere like arch/arm/include/asm/ls/
> > (similar to arch/arm/include/asm/imx-common).
> 
> > -Scott
> all SOC specific include file should be
> in arch/arm/include/asm/arch-SOC/ or
> some common directory(like include/asm/imx-common). Currently, u-boot
> only link SOC specific(arch-SOC) include directory.
> You could touch a mmu.h file in arch/arm/include/asm/arch-ls2/ and
> include
> arch/arm/include/asm/arch-armv8/mmu.h.
> or move arch-armv8/mmu.h to arch/arm/include/asm/ to make it as a
> generic file.
> Maybe we should distinguish architecture specific include directory
> and SOC
>  specific include directory.

Is the XXX arch-XXX supposed to be an SoC family or a CPU
family/architectutre?

-Scott

[U-Boot] When to create a SoC directory for ARM

[Sharma Bhupesh-B45370]

> -----Original Message-----
> From: u-boot-bounces at lists.denx.de [mailto:u-boot-bounces at lists.denx.de]
> On Behalf Of Scott Wood
> Sent: Friday, September 27, 2013 12:53 AM
> To: FengHua
> Cc: trini; sun york-R58495; u-boot
> Subject: Re: [U-Boot] When to create a SoC directory for ARM
> 
> On Thu, 2013-09-26 at 13:23 +0800, FengHua wrote:
> > > Date: Wed, 25 Sep 2013 20:10:13 -0500
> > > From: Scott Wood <scottwood@freescale.com>
> > > Subject: Re: [U-Boot] When to create a SoC directory for ARM
> > > To: sun york-R58495 <R58495@freescale.com>
> > > Cc: Rini <trini@ti.com>, Wood Scott-B07421 <B07421@freescale.com>,
> > > 	"u-boot at lists.denx.de" <u-boot@lists.denx.de>, Tom
> > > Message-ID: <1380157813.24959.237.camel@snotra.buserror.net>
> > > Content-Type: text/plain; charset="UTF-8"
> > > On Wed, 2013-09-25 at 20:04 -0500, sun york-R58495 wrote:
> > > > On Sep 25, 2013, at 4:52 PM, Scott Wood wrote:
> > > >
> > > > > On Wed, 2013-09-25 at 16:30 -0700, York Sun wrote:
> > > > >> Dear Wolfgang,
> > > > >>
> > > > >> I failed to find the guideline, here is my question. Pardon me
> > > > >> if this is a dump question as I am still new to ARM.
> > > > >>
> > > > >> As David Feng post his patch set to add ARMv8 support, I am
> > > > >> trying to enable it for Freescale implementation. Let's name it
> > > > >> as LS2 for this discussion. I am thinking to reuse as much as
> > > > >> possible for existing codes, which include copying some header
> > > > >> files from powerpc partially. I noticed the SoC field in
> > > > >> boards.cfg file and I am wondering how to use it effectively. I
> > > > >> want to put LS2 specific headers to
> > > > >> arch/arm/include/asm/arch-ls2. Do I need to copy all files from
> > > > >> arch/arm/include/asm/arch-armv8/? There aren't many but I see
> > > > >> mmu.h is included in start.S. I have been searching case like
> this in ARMv7 but didn't see shared header file (maybe I missed it).
> Please advise.
> > > > >
> > > > > LS2 is (or perhaps more accurately, contains) an implementation
> > > > > of ARMv8, so you should be using arch-armv8 rather than copying
> it.
> > > >
> > > > True. But I guess LS2 won't be the only "LS" Freescale is going to
> > > > make. Where is the best place to put the header file for chassis
> > > > related registers, like CCSR we have for mpc8xxx.
> > > Anything that isn't deeply tied to the ARM architecture should
> > > probably just go in include/.
> > > >  I am thinking the
> > > > best place is arch/arm/include/asm/ls2 (or a better name). Like
> > > > other
> > > > ARMv7 variants, I am thinking to put ls2 under arch/arm/cpu/armv8/
> > > > as well, to host LS-specific code.
> >
> > > Likewise, if it's specifically tied to armv8 it should go in
> > > arch/arm/include/asm/arch-armv8, but I'm not sure what would be tied
> > > to both armv8 and ls2.  Most likely anything LS-specific that needs
> > > to go under arch/arm/ should go somewhere like
> > > arch/arm/include/asm/ls/ (similar to arch/arm/include/asm/imx-
> common).
> >
> > > -Scott
> > all SOC specific include file should be in
> > arch/arm/include/asm/arch-SOC/ or some common directory(like
> > include/asm/imx-common). Currently, u-boot only link SOC
> > specific(arch-SOC) include directory.
> > You could touch a mmu.h file in arch/arm/include/asm/arch-ls2/ and
> > include arch/arm/include/asm/arch-armv8/mmu.h.
> > or move arch-armv8/mmu.h to arch/arm/include/asm/ to make it as a
> > generic file.
> > Maybe we should distinguish architecture specific include directory
> > and SOC  specific include directory.
> 
> Is the XXX arch-XXX supposed to be an SoC family or a CPU
> family/architectutre?
> 

Usually in 'arch/arm/include/asm' we have both:
- arch-armv7 (Arch specific. Houses stuff common to ARMv7 CPU, e.g. Global timer, SP805 WDT..)
- arch-mx6 (SoC family specific. Houses stuff like SoC specific IOMUX pads..)

We should have something similar for LayerScape.

Regards,
Bhupesh

[U-Boot] When to create a SoC directory for ARM

[York Sun]

On 09/26/2013 12:46 PM, Sharma Bhupesh-B45370 wrote:
> 
>> -----Original Message-----
>> From: u-boot-bounces at lists.denx.de [mailto:u-boot-bounces at lists.denx.de]
>> On Behalf Of Scott Wood
>> Sent: Friday, September 27, 2013 12:53 AM
>> To: FengHua
>> Cc: trini; sun york-R58495; u-boot
>> Subject: Re: [U-Boot] When to create a SoC directory for ARM
>>
>> On Thu, 2013-09-26 at 13:23 +0800, FengHua wrote:
>>>> Date: Wed, 25 Sep 2013 20:10:13 -0500
>>>> From: Scott Wood <scottwood@freescale.com>
>>>> Subject: Re: [U-Boot] When to create a SoC directory for ARM
>>>> To: sun york-R58495 <R58495@freescale.com>
>>>> Cc: Rini <trini@ti.com>, Wood Scott-B07421 <B07421@freescale.com>,
>>>> 	"u-boot at lists.denx.de" <u-boot@lists.denx.de>, Tom
>>>> Message-ID: <1380157813.24959.237.camel@snotra.buserror.net>
>>>> Content-Type: text/plain; charset="UTF-8"
>>>> On Wed, 2013-09-25 at 20:04 -0500, sun york-R58495 wrote:
>>>>> On Sep 25, 2013, at 4:52 PM, Scott Wood wrote:
>>>>>
>>>>>> On Wed, 2013-09-25 at 16:30 -0700, York Sun wrote:
>>>>>>> Dear Wolfgang,
>>>>>>>
>>>>>>> I failed to find the guideline, here is my question. Pardon me
>>>>>>> if this is a dump question as I am still new to ARM.
>>>>>>>
>>>>>>> As David Feng post his patch set to add ARMv8 support, I am
>>>>>>> trying to enable it for Freescale implementation. Let's name it
>>>>>>> as LS2 for this discussion. I am thinking to reuse as much as
>>>>>>> possible for existing codes, which include copying some header
>>>>>>> files from powerpc partially. I noticed the SoC field in
>>>>>>> boards.cfg file and I am wondering how to use it effectively. I
>>>>>>> want to put LS2 specific headers to
>>>>>>> arch/arm/include/asm/arch-ls2. Do I need to copy all files from
>>>>>>> arch/arm/include/asm/arch-armv8/? There aren't many but I see
>>>>>>> mmu.h is included in start.S. I have been searching case like
>> this in ARMv7 but didn't see shared header file (maybe I missed it).
>> Please advise.
>>>>>>
>>>>>> LS2 is (or perhaps more accurately, contains) an implementation
>>>>>> of ARMv8, so you should be using arch-armv8 rather than copying
>> it.
>>>>>
>>>>> True. But I guess LS2 won't be the only "LS" Freescale is going to
>>>>> make. Where is the best place to put the header file for chassis
>>>>> related registers, like CCSR we have for mpc8xxx.
>>>> Anything that isn't deeply tied to the ARM architecture should
>>>> probably just go in include/.
>>>>>  I am thinking the
>>>>> best place is arch/arm/include/asm/ls2 (or a better name). Like
>>>>> other
>>>>> ARMv7 variants, I am thinking to put ls2 under arch/arm/cpu/armv8/
>>>>> as well, to host LS-specific code.
>>>
>>>> Likewise, if it's specifically tied to armv8 it should go in
>>>> arch/arm/include/asm/arch-armv8, but I'm not sure what would be tied
>>>> to both armv8 and ls2.  Most likely anything LS-specific that needs
>>>> to go under arch/arm/ should go somewhere like
>>>> arch/arm/include/asm/ls/ (similar to arch/arm/include/asm/imx-
>> common).
>>>
>>>> -Scott
>>> all SOC specific include file should be in
>>> arch/arm/include/asm/arch-SOC/ or some common directory(like
>>> include/asm/imx-common). Currently, u-boot only link SOC
>>> specific(arch-SOC) include directory.
>>> You could touch a mmu.h file in arch/arm/include/asm/arch-ls2/ and
>>> include arch/arm/include/asm/arch-armv8/mmu.h.
>>> or move arch-armv8/mmu.h to arch/arm/include/asm/ to make it as a
>>> generic file.
>>> Maybe we should distinguish architecture specific include directory
>>> and SOC  specific include directory.
>>
>> Is the XXX arch-XXX supposed to be an SoC family or a CPU
>> family/architectutre?
>>
> 
> Usually in 'arch/arm/include/asm' we have both:
> - arch-armv7 (Arch specific. Houses stuff common to ARMv7 CPU, e.g. Global timer, SP805 WDT..)
> - arch-mx6 (SoC family specific. Houses stuff like SoC specific IOMUX pads..)
> 
> We should have something similar for LayerScape.
> 
>
If you look closely, you will find arch-armv7 and its sub-arch including
am33xx, at91, exynos, etc.

York

[U-Boot] When to create a SoC directory for ARM

[Scott Wood]

On Thu, 2013-09-26 at 12:48 -0700, York Sun wrote:
> On 09/26/2013 12:46 PM, Sharma Bhupesh-B45370 wrote:
> > 
> >> -----Original Message-----
> >> From: u-boot-bounces at lists.denx.de [mailto:u-boot-bounces at lists.denx.de]
> >> On Behalf Of Scott Wood
> >> Sent: Friday, September 27, 2013 12:53 AM
> >> To: FengHua
> >> Cc: trini; sun york-R58495; u-boot
> >> Subject: Re: [U-Boot] When to create a SoC directory for ARM
> >>
> >> On Thu, 2013-09-26 at 13:23 +0800, FengHua wrote:
> >>>> Date: Wed, 25 Sep 2013 20:10:13 -0500
> >>>> From: Scott Wood <scottwood@freescale.com>
> >>>> Subject: Re: [U-Boot] When to create a SoC directory for ARM
> >>>> To: sun york-R58495 <R58495@freescale.com>
> >>>> Cc: Rini <trini@ti.com>, Wood Scott-B07421 <B07421@freescale.com>,
> >>>> 	"u-boot at lists.denx.de" <u-boot@lists.denx.de>, Tom
> >>>> Message-ID: <1380157813.24959.237.camel@snotra.buserror.net>
> >>>> Content-Type: text/plain; charset="UTF-8"
> >>>> On Wed, 2013-09-25 at 20:04 -0500, sun york-R58495 wrote:
> >>>>> On Sep 25, 2013, at 4:52 PM, Scott Wood wrote:
> >>>>>
> >>>>>> On Wed, 2013-09-25 at 16:30 -0700, York Sun wrote:
> >>>>>>> Dear Wolfgang,
> >>>>>>>
> >>>>>>> I failed to find the guideline, here is my question. Pardon me
> >>>>>>> if this is a dump question as I am still new to ARM.
> >>>>>>>
> >>>>>>> As David Feng post his patch set to add ARMv8 support, I am
> >>>>>>> trying to enable it for Freescale implementation. Let's name it
> >>>>>>> as LS2 for this discussion. I am thinking to reuse as much as
> >>>>>>> possible for existing codes, which include copying some header
> >>>>>>> files from powerpc partially. I noticed the SoC field in
> >>>>>>> boards.cfg file and I am wondering how to use it effectively. I
> >>>>>>> want to put LS2 specific headers to
> >>>>>>> arch/arm/include/asm/arch-ls2. Do I need to copy all files from
> >>>>>>> arch/arm/include/asm/arch-armv8/? There aren't many but I see
> >>>>>>> mmu.h is included in start.S. I have been searching case like
> >> this in ARMv7 but didn't see shared header file (maybe I missed it).
> >> Please advise.
> >>>>>>
> >>>>>> LS2 is (or perhaps more accurately, contains) an implementation
> >>>>>> of ARMv8, so you should be using arch-armv8 rather than copying
> >> it.
> >>>>>
> >>>>> True. But I guess LS2 won't be the only "LS" Freescale is going to
> >>>>> make. Where is the best place to put the header file for chassis
> >>>>> related registers, like CCSR we have for mpc8xxx.
> >>>> Anything that isn't deeply tied to the ARM architecture should
> >>>> probably just go in include/.
> >>>>>  I am thinking the
> >>>>> best place is arch/arm/include/asm/ls2 (or a better name). Like
> >>>>> other
> >>>>> ARMv7 variants, I am thinking to put ls2 under arch/arm/cpu/armv8/
> >>>>> as well, to host LS-specific code.
> >>>
> >>>> Likewise, if it's specifically tied to armv8 it should go in
> >>>> arch/arm/include/asm/arch-armv8, but I'm not sure what would be tied
> >>>> to both armv8 and ls2.  Most likely anything LS-specific that needs
> >>>> to go under arch/arm/ should go somewhere like
> >>>> arch/arm/include/asm/ls/ (similar to arch/arm/include/asm/imx-
> >> common).
> >>>
> >>>> -Scott
> >>> all SOC specific include file should be in
> >>> arch/arm/include/asm/arch-SOC/ or some common directory(like
> >>> include/asm/imx-common). Currently, u-boot only link SOC
> >>> specific(arch-SOC) include directory.
> >>> You could touch a mmu.h file in arch/arm/include/asm/arch-ls2/ and
> >>> include arch/arm/include/asm/arch-armv8/mmu.h.
> >>> or move arch-armv8/mmu.h to arch/arm/include/asm/ to make it as a
> >>> generic file.
> >>> Maybe we should distinguish architecture specific include directory
> >>> and SOC  specific include directory.
> >>
> >> Is the XXX arch-XXX supposed to be an SoC family or a CPU
> >> family/architectutre?
> >>
> > 
> > Usually in 'arch/arm/include/asm' we have both:
> > - arch-armv7 (Arch specific. Houses stuff common to ARMv7 CPU, e.g. Global timer, SP805 WDT..)
> > - arch-mx6 (SoC family specific. Houses stuff like SoC specific IOMUX pads..)

Which one does "#inculde <asm/arch/foo.h>" refer to?

-Scott

[U-Boot] When to create a SoC directory for ARM

[Sharma Bhupesh-B45370]

> -----Original Message-----
> From: sun york-R58495
> Sent: Friday, September 27, 2013 1:19 AM
> To: Sharma Bhupesh-B45370; Wood Scott-B07421; 'FengHua'
> Cc: 'trini'; sun york-R58495; 'u-boot'
> Subject: Re: [U-Boot] When to create a SoC directory for ARM
> 
> On 09/26/2013 12:46 PM, Sharma Bhupesh-B45370 wrote:
> >
> >> -----Original Message-----
> >> From: u-boot-bounces at lists.denx.de
> >> [mailto:u-boot-bounces at lists.denx.de]
> >> On Behalf Of Scott Wood
> >> Sent: Friday, September 27, 2013 12:53 AM
> >> To: FengHua
> >> Cc: trini; sun york-R58495; u-boot
> >> Subject: Re: [U-Boot] When to create a SoC directory for ARM
> >>
> >> On Thu, 2013-09-26 at 13:23 +0800, FengHua wrote:
> >>>> Date: Wed, 25 Sep 2013 20:10:13 -0500
> >>>> From: Scott Wood <scottwood@freescale.com>
> >>>> Subject: Re: [U-Boot] When to create a SoC directory for ARM
> >>>> To: sun york-R58495 <R58495@freescale.com>
> >>>> Cc: Rini <trini@ti.com>, Wood Scott-B07421 <B07421@freescale.com>,
> >>>> 	"u-boot at lists.denx.de" <u-boot@lists.denx.de>, Tom
> >>>> Message-ID: <1380157813.24959.237.camel@snotra.buserror.net>
> >>>> Content-Type: text/plain; charset="UTF-8"
> >>>> On Wed, 2013-09-25 at 20:04 -0500, sun york-R58495 wrote:
> >>>>> On Sep 25, 2013, at 4:52 PM, Scott Wood wrote:
> >>>>>
> >>>>>> On Wed, 2013-09-25 at 16:30 -0700, York Sun wrote:
> >>>>>>> Dear Wolfgang,
> >>>>>>>
> >>>>>>> I failed to find the guideline, here is my question. Pardon me
> >>>>>>> if this is a dump question as I am still new to ARM.
> >>>>>>>
> >>>>>>> As David Feng post his patch set to add ARMv8 support, I am
> >>>>>>> trying to enable it for Freescale implementation. Let's name it
> >>>>>>> as LS2 for this discussion. I am thinking to reuse as much as
> >>>>>>> possible for existing codes, which include copying some header
> >>>>>>> files from powerpc partially. I noticed the SoC field in
> >>>>>>> boards.cfg file and I am wondering how to use it effectively. I
> >>>>>>> want to put LS2 specific headers to
> >>>>>>> arch/arm/include/asm/arch-ls2. Do I need to copy all files from
> >>>>>>> arch/arm/include/asm/arch-armv8/? There aren't many but I see
> >>>>>>> mmu.h is included in start.S. I have been searching case like
> >> this in ARMv7 but didn't see shared header file (maybe I missed it).
> >> Please advise.
> >>>>>>
> >>>>>> LS2 is (or perhaps more accurately, contains) an implementation
> >>>>>> of ARMv8, so you should be using arch-armv8 rather than copying
> >> it.
> >>>>>
> >>>>> True. But I guess LS2 won't be the only "LS" Freescale is going to
> >>>>> make. Where is the best place to put the header file for chassis
> >>>>> related registers, like CCSR we have for mpc8xxx.
> >>>> Anything that isn't deeply tied to the ARM architecture should
> >>>> probably just go in include/.
> >>>>>  I am thinking the
> >>>>> best place is arch/arm/include/asm/ls2 (or a better name). Like
> >>>>> other
> >>>>> ARMv7 variants, I am thinking to put ls2 under arch/arm/cpu/armv8/
> >>>>> as well, to host LS-specific code.
> >>>
> >>>> Likewise, if it's specifically tied to armv8 it should go in
> >>>> arch/arm/include/asm/arch-armv8, but I'm not sure what would be
> >>>> tied to both armv8 and ls2.  Most likely anything LS-specific that
> >>>> needs to go under arch/arm/ should go somewhere like
> >>>> arch/arm/include/asm/ls/ (similar to arch/arm/include/asm/imx-
> >> common).
> >>>
> >>>> -Scott
> >>> all SOC specific include file should be in
> >>> arch/arm/include/asm/arch-SOC/ or some common directory(like
> >>> include/asm/imx-common). Currently, u-boot only link SOC
> >>> specific(arch-SOC) include directory.
> >>> You could touch a mmu.h file in arch/arm/include/asm/arch-ls2/ and
> >>> include arch/arm/include/asm/arch-armv8/mmu.h.
> >>> or move arch-armv8/mmu.h to arch/arm/include/asm/ to make it as a
> >>> generic file.
> >>> Maybe we should distinguish architecture specific include directory
> >>> and SOC  specific include directory.
> >>
> >> Is the XXX arch-XXX supposed to be an SoC family or a CPU
> >> family/architectutre?
> >>
> >
> > Usually in 'arch/arm/include/asm' we have both:
> > - arch-armv7 (Arch specific. Houses stuff common to ARMv7 CPU, e.g.
> > Global timer, SP805 WDT..)
> > - arch-mx6 (SoC family specific. Houses stuff like SoC specific IOMUX
> > pads..)
> >
> > We should have something similar for LayerScape.
> >
> >
> If you look closely, you will find arch-armv7 and its sub-arch including
> am33xx, at91, exynos, etc.
> 

I cannot find any sub-arch inside 'arch/arm/include/asm/arch-armv7' (I am referring to reference [1])
I think you are talking about 'arch/arm/cpu/arch-armv7'. That's not what I was referring to my original
mail.

I believe David was mentioning the same in his mail (mmu.h inside 'arch/arm/include/asm/arch-armv8') .

References:
[1] http://git.denx.de/?p=u-boot.git;a=tree;f=arch/arm/include/asm/arch-armv7;h=cc9d1ccedcba6881922b12ae8377627cb8632c46;hb=HEAD

Regards,
Bhupesh

[U-Boot] When to create a SoC directory for ARM

[York Sun]

On 09/26/2013 12:55 PM, Scott Wood wrote:
> On Thu, 2013-09-26 at 12:48 -0700, York Sun wrote:
>> On 09/26/2013 12:46 PM, Sharma Bhupesh-B45370 wrote:
>>>
>>>> -----Original Message-----
>>>> From: u-boot-bounces at lists.denx.de [mailto:u-boot-bounces at lists.denx.de]
>>>> On Behalf Of Scott Wood
>>>> Sent: Friday, September 27, 2013 12:53 AM
>>>> To: FengHua
>>>> Cc: trini; sun york-R58495; u-boot
>>>> Subject: Re: [U-Boot] When to create a SoC directory for ARM
>>>>
>>>> On Thu, 2013-09-26 at 13:23 +0800, FengHua wrote:
>>>>>> Date: Wed, 25 Sep 2013 20:10:13 -0500
>>>>>> From: Scott Wood <scottwood@freescale.com>
>>>>>> Subject: Re: [U-Boot] When to create a SoC directory for ARM
>>>>>> To: sun york-R58495 <R58495@freescale.com>
>>>>>> Cc: Rini <trini@ti.com>, Wood Scott-B07421 <B07421@freescale.com>,
>>>>>> 	"u-boot at lists.denx.de" <u-boot@lists.denx.de>, Tom
>>>>>> Message-ID: <1380157813.24959.237.camel@snotra.buserror.net>
>>>>>> Content-Type: text/plain; charset="UTF-8"
>>>>>> On Wed, 2013-09-25 at 20:04 -0500, sun york-R58495 wrote:
>>>>>>> On Sep 25, 2013, at 4:52 PM, Scott Wood wrote:
>>>>>>>
>>>>>>>> On Wed, 2013-09-25 at 16:30 -0700, York Sun wrote:
>>>>>>>>> Dear Wolfgang,
>>>>>>>>>
>>>>>>>>> I failed to find the guideline, here is my question. Pardon me
>>>>>>>>> if this is a dump question as I am still new to ARM.
>>>>>>>>>
>>>>>>>>> As David Feng post his patch set to add ARMv8 support, I am
>>>>>>>>> trying to enable it for Freescale implementation. Let's name it
>>>>>>>>> as LS2 for this discussion. I am thinking to reuse as much as
>>>>>>>>> possible for existing codes, which include copying some header
>>>>>>>>> files from powerpc partially. I noticed the SoC field in
>>>>>>>>> boards.cfg file and I am wondering how to use it effectively. I
>>>>>>>>> want to put LS2 specific headers to
>>>>>>>>> arch/arm/include/asm/arch-ls2. Do I need to copy all files from
>>>>>>>>> arch/arm/include/asm/arch-armv8/? There aren't many but I see
>>>>>>>>> mmu.h is included in start.S. I have been searching case like
>>>> this in ARMv7 but didn't see shared header file (maybe I missed it).
>>>> Please advise.
>>>>>>>>
>>>>>>>> LS2 is (or perhaps more accurately, contains) an implementation
>>>>>>>> of ARMv8, so you should be using arch-armv8 rather than copying
>>>> it.
>>>>>>>
>>>>>>> True. But I guess LS2 won't be the only "LS" Freescale is going to
>>>>>>> make. Where is the best place to put the header file for chassis
>>>>>>> related registers, like CCSR we have for mpc8xxx.
>>>>>> Anything that isn't deeply tied to the ARM architecture should
>>>>>> probably just go in include/.
>>>>>>>  I am thinking the
>>>>>>> best place is arch/arm/include/asm/ls2 (or a better name). Like
>>>>>>> other
>>>>>>> ARMv7 variants, I am thinking to put ls2 under arch/arm/cpu/armv8/
>>>>>>> as well, to host LS-specific code.
>>>>>
>>>>>> Likewise, if it's specifically tied to armv8 it should go in
>>>>>> arch/arm/include/asm/arch-armv8, but I'm not sure what would be tied
>>>>>> to both armv8 and ls2.  Most likely anything LS-specific that needs
>>>>>> to go under arch/arm/ should go somewhere like
>>>>>> arch/arm/include/asm/ls/ (similar to arch/arm/include/asm/imx-
>>>> common).
>>>>>
>>>>>> -Scott
>>>>> all SOC specific include file should be in
>>>>> arch/arm/include/asm/arch-SOC/ or some common directory(like
>>>>> include/asm/imx-common). Currently, u-boot only link SOC
>>>>> specific(arch-SOC) include directory.
>>>>> You could touch a mmu.h file in arch/arm/include/asm/arch-ls2/ and
>>>>> include arch/arm/include/asm/arch-armv8/mmu.h.
>>>>> or move arch-armv8/mmu.h to arch/arm/include/asm/ to make it as a
>>>>> generic file.
>>>>> Maybe we should distinguish architecture specific include directory
>>>>> and SOC  specific include directory.
>>>>
>>>> Is the XXX arch-XXX supposed to be an SoC family or a CPU
>>>> family/architectutre?
>>>>
>>>
>>> Usually in 'arch/arm/include/asm' we have both:
>>> - arch-armv7 (Arch specific. Houses stuff common to ARMv7 CPU, e.g. Global timer, SP805 WDT..)
>>> - arch-mx6 (SoC family specific. Houses stuff like SoC specific IOMUX pads..)
> 
> Which one does "#inculde <asm/arch/foo.h>" refer to?
> 

arm/arch is a symbolic link created at compiling time. It points to
arm/arch-$(soc), if $(soc) is not defined, then it points to
asm/arch-$(arch). That's my understanding.

York

[U-Boot] When to create a SoC directory for ARM

[Scott Wood]

On Thu, 2013-09-26 at 12:57 -0700, York Sun wrote:
> On 09/26/2013 12:55 PM, Scott Wood wrote:
> > On Thu, 2013-09-26 at 12:48 -0700, York Sun wrote:
> >> On 09/26/2013 12:46 PM, Sharma Bhupesh-B45370 wrote:
> >>>
> >>>> -----Original Message-----
> >>>> From: u-boot-bounces at lists.denx.de [mailto:u-boot-bounces at lists.denx.de]
> >>>> On Behalf Of Scott Wood
> >>>> Sent: Friday, September 27, 2013 12:53 AM
> >>>> To: FengHua
> >>>> Cc: trini; sun york-R58495; u-boot
> >>>> Subject: Re: [U-Boot] When to create a SoC directory for ARM
> >>>>
> >>>> On Thu, 2013-09-26 at 13:23 +0800, FengHua wrote:
> >>>>> all SOC specific include file should be in
> >>>>> arch/arm/include/asm/arch-SOC/ or some common directory(like
> >>>>> include/asm/imx-common). Currently, u-boot only link SOC
> >>>>> specific(arch-SOC) include directory.
> >>>>> You could touch a mmu.h file in arch/arm/include/asm/arch-ls2/ and
> >>>>> include arch/arm/include/asm/arch-armv8/mmu.h.
> >>>>> or move arch-armv8/mmu.h to arch/arm/include/asm/ to make it as a
> >>>>> generic file.
> >>>>> Maybe we should distinguish architecture specific include directory
> >>>>> and SOC  specific include directory.
> >>>>
> >>>> Is the XXX arch-XXX supposed to be an SoC family or a CPU
> >>>> family/architectutre?
> >>>>
> >>>
> >>> Usually in 'arch/arm/include/asm' we have both:
> >>> - arch-armv7 (Arch specific. Houses stuff common to ARMv7 CPU, e.g. Global timer, SP805 WDT..)
> >>> - arch-mx6 (SoC family specific. Houses stuff like SoC specific IOMUX pads..)
> > 
> > Which one does "#inculde <asm/arch/foo.h>" refer to?
> > 
> 
> arm/arch is a symbolic link created at compiling time. It points to
> arm/arch-$(soc), if $(soc) is not defined, then it points to
> asm/arch-$(arch). That's my understanding.

How is that supposed to work when both arch-$(soc) and arch-$(arch) are
present?  Why are SoC and CPU arch confused in this way?

-Scott

[U-Boot] When to create a SoC directory for ARM

[York Sun]

On 09/26/2013 01:44 PM, Scott Wood wrote:
> On Thu, 2013-09-26 at 12:57 -0700, York Sun wrote:
>> On 09/26/2013 12:55 PM, Scott Wood wrote:
>>> On Thu, 2013-09-26 at 12:48 -0700, York Sun wrote:
>>>> On 09/26/2013 12:46 PM, Sharma Bhupesh-B45370 wrote:
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: u-boot-bounces at lists.denx.de [mailto:u-boot-bounces at lists.denx.de]
>>>>>> On Behalf Of Scott Wood
>>>>>> Sent: Friday, September 27, 2013 12:53 AM
>>>>>> To: FengHua
>>>>>> Cc: trini; sun york-R58495; u-boot
>>>>>> Subject: Re: [U-Boot] When to create a SoC directory for ARM
>>>>>>
>>>>>> On Thu, 2013-09-26 at 13:23 +0800, FengHua wrote:
>>>>>>> all SOC specific include file should be in
>>>>>>> arch/arm/include/asm/arch-SOC/ or some common directory(like
>>>>>>> include/asm/imx-common). Currently, u-boot only link SOC
>>>>>>> specific(arch-SOC) include directory.
>>>>>>> You could touch a mmu.h file in arch/arm/include/asm/arch-ls2/ and
>>>>>>> include arch/arm/include/asm/arch-armv8/mmu.h.
>>>>>>> or move arch-armv8/mmu.h to arch/arm/include/asm/ to make it as a
>>>>>>> generic file.
>>>>>>> Maybe we should distinguish architecture specific include directory
>>>>>>> and SOC  specific include directory.
>>>>>>
>>>>>> Is the XXX arch-XXX supposed to be an SoC family or a CPU
>>>>>> family/architectutre?
>>>>>>
>>>>>
>>>>> Usually in 'arch/arm/include/asm' we have both:
>>>>> - arch-armv7 (Arch specific. Houses stuff common to ARMv7 CPU, e.g. Global timer, SP805 WDT..)
>>>>> - arch-mx6 (SoC family specific. Houses stuff like SoC specific IOMUX pads..)
>>>
>>> Which one does "#inculde <asm/arch/foo.h>" refer to?
>>>
>>
>> arm/arch is a symbolic link created at compiling time. It points to
>> arm/arch-$(soc), if $(soc) is not defined, then it points to
>> asm/arch-$(arch). That's my understanding.
> 
> How is that supposed to work when both arch-$(soc) and arch-$(arch) are
> present?  Why are SoC and CPU arch confused in this way?
> 

It can't. That's why I am struggling. My temporary workaround is to
include those headers in sub-arch headers.

York

[U-Boot] When to create a SoC directory for ARM

[Scott Wood]

On Thu, 2013-09-26 at 13:46 -0700, York Sun wrote:
> On 09/26/2013 01:44 PM, Scott Wood wrote:
> > On Thu, 2013-09-26 at 12:57 -0700, York Sun wrote:
> >> On 09/26/2013 12:55 PM, Scott Wood wrote:
> >>> On Thu, 2013-09-26 at 12:48 -0700, York Sun wrote:
> >>>> On 09/26/2013 12:46 PM, Sharma Bhupesh-B45370 wrote:
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: u-boot-bounces at lists.denx.de [mailto:u-boot-bounces at lists.denx.de]
> >>>>>> On Behalf Of Scott Wood
> >>>>>> Sent: Friday, September 27, 2013 12:53 AM
> >>>>>> To: FengHua
> >>>>>> Cc: trini; sun york-R58495; u-boot
> >>>>>> Subject: Re: [U-Boot] When to create a SoC directory for ARM
> >>>>>>
> >>>>>> On Thu, 2013-09-26 at 13:23 +0800, FengHua wrote:
> >>>>>>> all SOC specific include file should be in
> >>>>>>> arch/arm/include/asm/arch-SOC/ or some common directory(like
> >>>>>>> include/asm/imx-common). Currently, u-boot only link SOC
> >>>>>>> specific(arch-SOC) include directory.
> >>>>>>> You could touch a mmu.h file in arch/arm/include/asm/arch-ls2/ and
> >>>>>>> include arch/arm/include/asm/arch-armv8/mmu.h.
> >>>>>>> or move arch-armv8/mmu.h to arch/arm/include/asm/ to make it as a
> >>>>>>> generic file.
> >>>>>>> Maybe we should distinguish architecture specific include directory
> >>>>>>> and SOC  specific include directory.
> >>>>>>
> >>>>>> Is the XXX arch-XXX supposed to be an SoC family or a CPU
> >>>>>> family/architectutre?
> >>>>>>
> >>>>>
> >>>>> Usually in 'arch/arm/include/asm' we have both:
> >>>>> - arch-armv7 (Arch specific. Houses stuff common to ARMv7 CPU, e.g. Global timer, SP805 WDT..)
> >>>>> - arch-mx6 (SoC family specific. Houses stuff like SoC specific IOMUX pads..)
> >>>
> >>> Which one does "#inculde <asm/arch/foo.h>" refer to?
> >>>
> >>
> >> arm/arch is a symbolic link created at compiling time. It points to
> >> arm/arch-$(soc), if $(soc) is not defined, then it points to
> >> asm/arch-$(arch). That's my understanding.
> > 
> > How is that supposed to work when both arch-$(soc) and arch-$(arch) are
> > present?  Why are SoC and CPU arch confused in this way?
> > 
> 
> It can't. That's why I am struggling. My temporary workaround is to
> include those headers in sub-arch headers.

My question is, more specifically, what is happening today on armv7
relative to this problem?

-Scott

[U-Boot] When to create a SoC directory for ARM

[Tom Rini]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/26/2013 04:44 PM, Scott Wood wrote:
> On Thu, 2013-09-26 at 12:57 -0700, York Sun wrote:
>> On 09/26/2013 12:55 PM, Scott Wood wrote:
>>> On Thu, 2013-09-26 at 12:48 -0700, York Sun wrote:
>>>> On 09/26/2013 12:46 PM, Sharma Bhupesh-B45370 wrote:
>>>>> 
>>>>>> -----Original Message----- From:
>>>>>> u-boot-bounces at lists.denx.de
>>>>>> [mailto:u-boot-bounces at lists.denx.de] On Behalf Of Scott
>>>>>> Wood Sent: Friday, September 27, 2013 12:53 AM To:
>>>>>> FengHua Cc: trini; sun york-R58495; u-boot Subject: Re:
>>>>>> [U-Boot] When to create a SoC directory for ARM
>>>>>> 
>>>>>> On Thu, 2013-09-26 at 13:23 +0800, FengHua wrote:
>>>>>>> all SOC specific include file should be in 
>>>>>>> arch/arm/include/asm/arch-SOC/ or some common
>>>>>>> directory(like include/asm/imx-common). Currently,
>>>>>>> u-boot only link SOC specific(arch-SOC) include
>>>>>>> directory. You could touch a mmu.h file in
>>>>>>> arch/arm/include/asm/arch-ls2/ and include
>>>>>>> arch/arm/include/asm/arch-armv8/mmu.h. or move
>>>>>>> arch-armv8/mmu.h to arch/arm/include/asm/ to make it as
>>>>>>> a generic file. Maybe we should distinguish
>>>>>>> architecture specific include directory and SOC
>>>>>>> specific include directory.
>>>>>> 
>>>>>> Is the XXX arch-XXX supposed to be an SoC family or a
>>>>>> CPU family/architectutre?
>>>>>> 
>>>>> 
>>>>> Usually in 'arch/arm/include/asm' we have both: -
>>>>> arch-armv7 (Arch specific. Houses stuff common to ARMv7
>>>>> CPU, e.g. Global timer, SP805 WDT..) - arch-mx6 (SoC family
>>>>> specific. Houses stuff like SoC specific IOMUX pads..)
>>> 
>>> Which one does "#inculde <asm/arch/foo.h>" refer to?
>>> 
>> 
>> arm/arch is a symbolic link created at compiling time. It points
>> to arm/arch-$(soc), if $(soc) is not defined, then it points to 
>> asm/arch-$(arch). That's my understanding.
> 
> How is that supposed to work when both arch-$(soc) and arch-$(arch)
> are present?  Why are SoC and CPU arch confused in this way?

Primarily because it hasn't been an issue until now really.  What's
wrong with just saying <asm/arch-armv[78]/foo.h> as needed ?  Or do we
have a volunteer for a big re-jiggering of includes?  Adding a <plat/>
like the kernel has would be helpful in some cases, like this.

- -- 
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSRJ3CAAoJENk4IS6UOR1WA7UQALKfEQBWv6KC9poxU5FWy0fF
zcoT8i1YB1jsPsEnSa/QZPZJ0XLeJmJicPbctNImj1WuljMVO8cu50RTfcXgEKuX
g7fLczioupYCV+2fd7FMKsG3JXG0vbLkkDTzSuFNdd4uE2awcoiKCK9LO6XK56gs
/a8oS5fsPJlVPaKnvxy0xI1h2w56FtKScqUOxb4l8JpCBo/5B3FzNQ1tL1ZcG/hn
Lfg09WYNUJOe0axuHE1VGIQOM8KN1d/qwZXwsPcZ8wYH+pF4kwAcg/A9TwWmvJHu
VS+jz0I9wDAXyYPJEcvlDXNWOUKHjRfWLTnh4BKGPVa6jXmuq1UL1KnLBnhntxik
OOsAt45mKru1VTihjqk1+1K2W7zNl100/bX1d3R902mQz/5n4t/H47DRhUa+uLOz
CEdjglOASmZjnLkk8PLKOM3ZoKgJtrrePQO7xX5LPOkFytQ2AphBd1hrFLE3DG2S
r3Bskj5g+FWt+c+jU+pw+P6Ct2tZFAk4uZHjnYI2sE5j0cd7P9OnR2hvEpILDUXo
/Tz5sGuyBaERKKNW3965SrydetMiZZuPfQzxYczIF0ZpQaoOuHaAApyfq8VJbU4q
b7frLpyvO8G/yoh4Wid6i7dQNm8FDnGWz+z+lNub9EIqSAIavIb9otFl2O6T4MvF
b2sHtCcEIdjZH8SIoe/v
=ETM5
-----END PGP SIGNATURE-----

[U-Boot] When to create a SoC directory for ARM

[Scott Wood]

On Thu, 2013-09-26 at 16:49 -0400, Tom Rini wrote:
> On 09/26/2013 04:44 PM, Scott Wood wrote:
> > On Thu, 2013-09-26 at 12:57 -0700, York Sun wrote:
> >> On 09/26/2013 12:55 PM, Scott Wood wrote:
> >>> On Thu, 2013-09-26 at 12:48 -0700, York Sun wrote:
> >>>> On 09/26/2013 12:46 PM, Sharma Bhupesh-B45370 wrote:
> >>>>> 
> >>>>>> -----Original Message----- From:
> >>>>>> u-boot-bounces at lists.denx.de
> >>>>>> [mailto:u-boot-bounces at lists.denx.de] On Behalf Of Scott
> >>>>>> Wood Sent: Friday, September 27, 2013 12:53 AM To:
> >>>>>> FengHua Cc: trini; sun york-R58495; u-boot Subject: Re:
> >>>>>> [U-Boot] When to create a SoC directory for ARM
> >>>>>> 
> >>>>>> On Thu, 2013-09-26 at 13:23 +0800, FengHua wrote:
> >>>>>>> all SOC specific include file should be in 
> >>>>>>> arch/arm/include/asm/arch-SOC/ or some common
> >>>>>>> directory(like include/asm/imx-common). Currently,
> >>>>>>> u-boot only link SOC specific(arch-SOC) include
> >>>>>>> directory. You could touch a mmu.h file in
> >>>>>>> arch/arm/include/asm/arch-ls2/ and include
> >>>>>>> arch/arm/include/asm/arch-armv8/mmu.h. or move
> >>>>>>> arch-armv8/mmu.h to arch/arm/include/asm/ to make it as
> >>>>>>> a generic file. Maybe we should distinguish
> >>>>>>> architecture specific include directory and SOC
> >>>>>>> specific include directory.
> >>>>>> 
> >>>>>> Is the XXX arch-XXX supposed to be an SoC family or a
> >>>>>> CPU family/architectutre?
> >>>>>> 
> >>>>> 
> >>>>> Usually in 'arch/arm/include/asm' we have both: -
> >>>>> arch-armv7 (Arch specific. Houses stuff common to ARMv7
> >>>>> CPU, e.g. Global timer, SP805 WDT..) - arch-mx6 (SoC family
> >>>>> specific. Houses stuff like SoC specific IOMUX pads..)
> >>> 
> >>> Which one does "#inculde <asm/arch/foo.h>" refer to?
> >>> 
> >> 
> >> arm/arch is a symbolic link created at compiling time. It points
> >> to arm/arch-$(soc), if $(soc) is not defined, then it points to 
> >> asm/arch-$(arch). That's my understanding.
> > 
> > How is that supposed to work when both arch-$(soc) and arch-$(arch)
> > are present?  Why are SoC and CPU arch confused in this way?
> 
> Primarily because it hasn't been an issue until now really.  What's
> wrong with just saying <asm/arch-armv[78]/foo.h> as needed ?

Hmm, the only relevant <asm/arch/mmu.h> are in armv8-specific files, so
I suppose we could do that.  Why not just rename it asm/armv[78],
though?  There are only a handful of files in both armv7 and armv8, so
it shouldn't be too much of a problem.  Then there's no question of
where the symlink points.

-Scott

[U-Boot] When to create a SoC directory for ARM

[Tom Rini]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/26/2013 04:59 PM, Scott Wood wrote:
> On Thu, 2013-09-26 at 16:49 -0400, Tom Rini wrote:
>> On 09/26/2013 04:44 PM, Scott Wood wrote:
>>> On Thu, 2013-09-26 at 12:57 -0700, York Sun wrote:
>>>> On 09/26/2013 12:55 PM, Scott Wood wrote:
>>>>> On Thu, 2013-09-26 at 12:48 -0700, York Sun wrote:
>>>>>> On 09/26/2013 12:46 PM, Sharma Bhupesh-B45370 wrote:
>>>>>>> 
>>>>>>>> -----Original Message----- From: 
>>>>>>>> u-boot-bounces at lists.denx.de 
>>>>>>>> [mailto:u-boot-bounces at lists.denx.de] On Behalf Of
>>>>>>>> Scott Wood Sent: Friday, September 27, 2013 12:53 AM
>>>>>>>> To: FengHua Cc: trini; sun york-R58495; u-boot
>>>>>>>> Subject: Re: [U-Boot] When to create a SoC directory
>>>>>>>> for ARM
>>>>>>>> 
>>>>>>>> On Thu, 2013-09-26 at 13:23 +0800, FengHua wrote:
>>>>>>>>> all SOC specific include file should be in 
>>>>>>>>> arch/arm/include/asm/arch-SOC/ or some common 
>>>>>>>>> directory(like include/asm/imx-common). Currently, 
>>>>>>>>> u-boot only link SOC specific(arch-SOC) include 
>>>>>>>>> directory. You could touch a mmu.h file in 
>>>>>>>>> arch/arm/include/asm/arch-ls2/ and include 
>>>>>>>>> arch/arm/include/asm/arch-armv8/mmu.h. or move 
>>>>>>>>> arch-armv8/mmu.h to arch/arm/include/asm/ to make
>>>>>>>>> it as a generic file. Maybe we should distinguish 
>>>>>>>>> architecture specific include directory and SOC 
>>>>>>>>> specific include directory.
>>>>>>>> 
>>>>>>>> Is the XXX arch-XXX supposed to be an SoC family or
>>>>>>>> a CPU family/architectutre?
>>>>>>>> 
>>>>>>> 
>>>>>>> Usually in 'arch/arm/include/asm' we have both: - 
>>>>>>> arch-armv7 (Arch specific. Houses stuff common to
>>>>>>> ARMv7 CPU, e.g. Global timer, SP805 WDT..) - arch-mx6
>>>>>>> (SoC family specific. Houses stuff like SoC specific
>>>>>>> IOMUX pads..)
>>>>> 
>>>>> Which one does "#inculde <asm/arch/foo.h>" refer to?
>>>>> 
>>>> 
>>>> arm/arch is a symbolic link created at compiling time. It
>>>> points to arm/arch-$(soc), if $(soc) is not defined, then it
>>>> points to asm/arch-$(arch). That's my understanding.
>>> 
>>> How is that supposed to work when both arch-$(soc) and
>>> arch-$(arch) are present?  Why are SoC and CPU arch confused in
>>> this way?
>> 
>> Primarily because it hasn't been an issue until now really.
>> What's wrong with just saying <asm/arch-armv[78]/foo.h> as needed
>> ?
> 
> Hmm, the only relevant <asm/arch/mmu.h> are in armv8-specific
> files, so I suppose we could do that.  Why not just rename it
> asm/armv[78], though?  There are only a handful of files in both
> armv7 and armv8, so it shouldn't be too much of a problem.  Then
> there's no question of where the symlink points.

That should also be fine, after a quick git grep around..

- -- 
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSRKEdAAoJENk4IS6UOR1WPEQP/1FtxXn3AgEFS/Sz0MCRb6ZK
YCm1gum5DUHY7kHZfF1+jFYdUP5sFSD4mzH/V90UVPqW8atubA5jggbwC8vk4E+j
HWZuv+fZJRDfMZQjs4b47EdgYh1ErTe3Xq8I5rnrgz+9+EuL5wo8Q88+7Lk9ftBd
9dIxHIRzPqixiZZy3rAbqvzrsGHzpnA1Qk9qyZwVow8PcW7bJ9B4yfOkZdxPvXVQ
MEAbxhph7Z8O9E5LqI7gjjr3mCQAFNhChKBDxBxF07SurDyyf1bjnzI39HFdZJAy
hWL6p+dBRVG3Jxhew6E9pEKHqvlvd5A76qaP7R9FssvaxRO777peLiP2JSHpPJoi
WwwZT6p8i8+xr92PQkDYCoOrO4gAVrco1e5cOC/0Qw3eaOMyFl8HqPnPGud6t66z
wgDjmsc3gBrX9rfXEMMBDk1Ef+rajJGYBcxOLhHqTM5iFhAJVNYgKPu70f/JioVW
4XpjV9r4x9pKF00ULM9Qh0bk63P0eS8oIwPjnKNS80mpBAD/awZu6wYclTgsdik6
hT0+TY/nNyu9Mr4zvUJMHAclZ+wwYmGrVaqkfREIrO9FBuiGP2Z0Pq/a5T+1KIWw
0gZx9S+vG9RquVcvkJSo0w3ieh+cBHgKLPtOOpKE726zvTNmXDodstBARQB3TauA
uG8hvetIlDgJabGhu2Xk
=zmTf
-----END PGP SIGNATURE-----

[U-Boot] When to create a SoC directory for ARM

[York Sun]

On 09/26/2013 02:03 PM, Tom Rini wrote:
> On 09/26/2013 04:59 PM, Scott Wood wrote:
>> On Thu, 2013-09-26 at 16:49 -0400, Tom Rini wrote:
>>> On 09/26/2013 04:44 PM, Scott Wood wrote:
>>>> On Thu, 2013-09-26 at 12:57 -0700, York Sun wrote:
>>>>> On 09/26/2013 12:55 PM, Scott Wood wrote:
>>>>>> On Thu, 2013-09-26 at 12:48 -0700, York Sun wrote:
>>>>>>> On 09/26/2013 12:46 PM, Sharma Bhupesh-B45370 wrote:
>>>>>>>>
>>>>>>>>> -----Original Message----- From: 
>>>>>>>>> u-boot-bounces at lists.denx.de 
>>>>>>>>> [mailto:u-boot-bounces at lists.denx.de] On Behalf Of
>>>>>>>>> Scott Wood Sent: Friday, September 27, 2013 12:53 AM
>>>>>>>>> To: FengHua Cc: trini; sun york-R58495; u-boot
>>>>>>>>> Subject: Re: [U-Boot] When to create a SoC directory
>>>>>>>>> for ARM
>>>>>>>>>
>>>>>>>>> On Thu, 2013-09-26 at 13:23 +0800, FengHua wrote:
>>>>>>>>>> all SOC specific include file should be in 
>>>>>>>>>> arch/arm/include/asm/arch-SOC/ or some common 
>>>>>>>>>> directory(like include/asm/imx-common). Currently, 
>>>>>>>>>> u-boot only link SOC specific(arch-SOC) include 
>>>>>>>>>> directory. You could touch a mmu.h file in 
>>>>>>>>>> arch/arm/include/asm/arch-ls2/ and include 
>>>>>>>>>> arch/arm/include/asm/arch-armv8/mmu.h. or move 
>>>>>>>>>> arch-armv8/mmu.h to arch/arm/include/asm/ to make
>>>>>>>>>> it as a generic file. Maybe we should distinguish 
>>>>>>>>>> architecture specific include directory and SOC 
>>>>>>>>>> specific include directory.
>>>>>>>>>
>>>>>>>>> Is the XXX arch-XXX supposed to be an SoC family or
>>>>>>>>> a CPU family/architectutre?
>>>>>>>>>
>>>>>>>>
>>>>>>>> Usually in 'arch/arm/include/asm' we have both: - 
>>>>>>>> arch-armv7 (Arch specific. Houses stuff common to
>>>>>>>> ARMv7 CPU, e.g. Global timer, SP805 WDT..) - arch-mx6
>>>>>>>> (SoC family specific. Houses stuff like SoC specific
>>>>>>>> IOMUX pads..)
>>>>>>
>>>>>> Which one does "#inculde <asm/arch/foo.h>" refer to?
>>>>>>
>>>>>
>>>>> arm/arch is a symbolic link created at compiling time. It
>>>>> points to arm/arch-$(soc), if $(soc) is not defined, then it
>>>>> points to asm/arch-$(arch). That's my understanding.
>>>>
>>>> How is that supposed to work when both arch-$(soc) and
>>>> arch-$(arch) are present?  Why are SoC and CPU arch confused in
>>>> this way?
>>>
>>> Primarily because it hasn't been an issue until now really.
>>> What's wrong with just saying <asm/arch-armv[78]/foo.h> as needed
>>> ?
> 
>> Hmm, the only relevant <asm/arch/mmu.h> are in armv8-specific
>> files, so I suppose we could do that.  Why not just rename it
>> asm/armv[78], though?  There are only a handful of files in both
>> armv7 and armv8, so it shouldn't be too much of a problem.  Then
>> there's no question of where the symlink points.
> 
> That should also be fine, after a quick git grep around..
> 
How about arch/arm/include/asm/gpio.h? it includes <asm/arch/gpio.h>.

York

[U-Boot] When to create a SoC directory for ARM

[Scott Wood]

On Thu, 2013-09-26 at 14:07 -0700, York Sun wrote:
> On 09/26/2013 02:03 PM, Tom Rini wrote:
> > On 09/26/2013 04:59 PM, Scott Wood wrote:
> >> On Thu, 2013-09-26 at 16:49 -0400, Tom Rini wrote:
> >>> On 09/26/2013 04:44 PM, Scott Wood wrote:
> >>>> On Thu, 2013-09-26 at 12:57 -0700, York Sun wrote:
> >>>>> On 09/26/2013 12:55 PM, Scott Wood wrote:
> >>>>>> On Thu, 2013-09-26 at 12:48 -0700, York Sun wrote:
> >>>>>>> On 09/26/2013 12:46 PM, Sharma Bhupesh-B45370 wrote:
> >>>>>>>>
> >>>>>>>>> -----Original Message----- From: 
> >>>>>>>>> u-boot-bounces at lists.denx.de 
> >>>>>>>>> [mailto:u-boot-bounces at lists.denx.de] On Behalf Of
> >>>>>>>>> Scott Wood Sent: Friday, September 27, 2013 12:53 AM
> >>>>>>>>> To: FengHua Cc: trini; sun york-R58495; u-boot
> >>>>>>>>> Subject: Re: [U-Boot] When to create a SoC directory
> >>>>>>>>> for ARM
> >>>>>>>>>
> >>>>>>>>> On Thu, 2013-09-26 at 13:23 +0800, FengHua wrote:
> >>>>>>>>>> all SOC specific include file should be in 
> >>>>>>>>>> arch/arm/include/asm/arch-SOC/ or some common 
> >>>>>>>>>> directory(like include/asm/imx-common). Currently, 
> >>>>>>>>>> u-boot only link SOC specific(arch-SOC) include 
> >>>>>>>>>> directory. You could touch a mmu.h file in 
> >>>>>>>>>> arch/arm/include/asm/arch-ls2/ and include 
> >>>>>>>>>> arch/arm/include/asm/arch-armv8/mmu.h. or move 
> >>>>>>>>>> arch-armv8/mmu.h to arch/arm/include/asm/ to make
> >>>>>>>>>> it as a generic file. Maybe we should distinguish 
> >>>>>>>>>> architecture specific include directory and SOC 
> >>>>>>>>>> specific include directory.
> >>>>>>>>>
> >>>>>>>>> Is the XXX arch-XXX supposed to be an SoC family or
> >>>>>>>>> a CPU family/architectutre?
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> Usually in 'arch/arm/include/asm' we have both: - 
> >>>>>>>> arch-armv7 (Arch specific. Houses stuff common to
> >>>>>>>> ARMv7 CPU, e.g. Global timer, SP805 WDT..) - arch-mx6
> >>>>>>>> (SoC family specific. Houses stuff like SoC specific
> >>>>>>>> IOMUX pads..)
> >>>>>>
> >>>>>> Which one does "#inculde <asm/arch/foo.h>" refer to?
> >>>>>>
> >>>>>
> >>>>> arm/arch is a symbolic link created at compiling time. It
> >>>>> points to arm/arch-$(soc), if $(soc) is not defined, then it
> >>>>> points to asm/arch-$(arch). That's my understanding.
> >>>>
> >>>> How is that supposed to work when both arch-$(soc) and
> >>>> arch-$(arch) are present?  Why are SoC and CPU arch confused in
> >>>> this way?
> >>>
> >>> Primarily because it hasn't been an issue until now really.
> >>> What's wrong with just saying <asm/arch-armv[78]/foo.h> as needed
> >>> ?
> > 
> >> Hmm, the only relevant <asm/arch/mmu.h> are in armv8-specific
> >> files, so I suppose we could do that.  Why not just rename it
> >> asm/armv[78], though?  There are only a handful of files in both
> >> armv7 and armv8, so it shouldn't be too much of a problem.  Then
> >> there's no question of where the symlink points.
> > 
> > That should also be fine, after a quick git grep around..
> > 
> How about arch/arm/include/asm/gpio.h? it includes <asm/arch/gpio.h>.

gpio.h doesn't belong in the armv8 directory.

-Scott

[U-Boot] When to create a SoC directory for ARM

[York Sun]

On 09/26/2013 02:26 PM, Scott Wood wrote:
> On Thu, 2013-09-26 at 14:07 -0700, York Sun wrote:
>> On 09/26/2013 02:03 PM, Tom Rini wrote:
>>> On 09/26/2013 04:59 PM, Scott Wood wrote:
>>>> On Thu, 2013-09-26 at 16:49 -0400, Tom Rini wrote:
>>>>> On 09/26/2013 04:44 PM, Scott Wood wrote:
>>>>>> On Thu, 2013-09-26 at 12:57 -0700, York Sun wrote:
>>>>>>> On 09/26/2013 12:55 PM, Scott Wood wrote:
>>>>>>>> On Thu, 2013-09-26 at 12:48 -0700, York Sun wrote:
>>>>>>>>> On 09/26/2013 12:46 PM, Sharma Bhupesh-B45370 wrote:
>>>>>>>>>>
>>>>>>>>>>> -----Original Message----- From: 
>>>>>>>>>>> u-boot-bounces at lists.denx.de 
>>>>>>>>>>> [mailto:u-boot-bounces at lists.denx.de] On Behalf Of
>>>>>>>>>>> Scott Wood Sent: Friday, September 27, 2013 12:53 AM
>>>>>>>>>>> To: FengHua Cc: trini; sun york-R58495; u-boot
>>>>>>>>>>> Subject: Re: [U-Boot] When to create a SoC directory
>>>>>>>>>>> for ARM
>>>>>>>>>>>
>>>>>>>>>>> On Thu, 2013-09-26 at 13:23 +0800, FengHua wrote:
>>>>>>>>>>>> all SOC specific include file should be in 
>>>>>>>>>>>> arch/arm/include/asm/arch-SOC/ or some common 
>>>>>>>>>>>> directory(like include/asm/imx-common). Currently, 
>>>>>>>>>>>> u-boot only link SOC specific(arch-SOC) include 
>>>>>>>>>>>> directory. You could touch a mmu.h file in 
>>>>>>>>>>>> arch/arm/include/asm/arch-ls2/ and include 
>>>>>>>>>>>> arch/arm/include/asm/arch-armv8/mmu.h. or move 
>>>>>>>>>>>> arch-armv8/mmu.h to arch/arm/include/asm/ to make
>>>>>>>>>>>> it as a generic file. Maybe we should distinguish 
>>>>>>>>>>>> architecture specific include directory and SOC 
>>>>>>>>>>>> specific include directory.
>>>>>>>>>>>
>>>>>>>>>>> Is the XXX arch-XXX supposed to be an SoC family or
>>>>>>>>>>> a CPU family/architectutre?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Usually in 'arch/arm/include/asm' we have both: - 
>>>>>>>>>> arch-armv7 (Arch specific. Houses stuff common to
>>>>>>>>>> ARMv7 CPU, e.g. Global timer, SP805 WDT..) - arch-mx6
>>>>>>>>>> (SoC family specific. Houses stuff like SoC specific
>>>>>>>>>> IOMUX pads..)
>>>>>>>>
>>>>>>>> Which one does "#inculde <asm/arch/foo.h>" refer to?
>>>>>>>>
>>>>>>>
>>>>>>> arm/arch is a symbolic link created at compiling time. It
>>>>>>> points to arm/arch-$(soc), if $(soc) is not defined, then it
>>>>>>> points to asm/arch-$(arch). That's my understanding.
>>>>>>
>>>>>> How is that supposed to work when both arch-$(soc) and
>>>>>> arch-$(arch) are present?  Why are SoC and CPU arch confused in
>>>>>> this way?
>>>>>
>>>>> Primarily because it hasn't been an issue until now really.
>>>>> What's wrong with just saying <asm/arch-armv[78]/foo.h> as needed
>>>>> ?
>>>
>>>> Hmm, the only relevant <asm/arch/mmu.h> are in armv8-specific
>>>> files, so I suppose we could do that.  Why not just rename it
>>>> asm/armv[78], though?  There are only a handful of files in both
>>>> armv7 and armv8, so it shouldn't be too much of a problem.  Then
>>>> there's no question of where the symlink points.
>>>
>>> That should also be fine, after a quick git grep around..
>>>
>> How about arch/arm/include/asm/gpio.h? it includes <asm/arch/gpio.h>.
> 
> gpio.h doesn't belong in the armv8 directory.
> 

No, it doesn't. But oddly we have a lot of them. And since it is
including <asm/arch/gpio.h>, we have to make it happy.

$ find arch/arm/include/ -name gpio.h
arch/arm/include/asm/arch-spear/gpio.h
arch/arm/include/asm/arch-am33xx/gpio.h
arch/arm/include/asm/arch-omap3/gpio.h
arch/arm/include/asm/imx-common/gpio.h
arch/arm/include/asm/arch-mx5/gpio.h
arch/arm/include/asm/arch-tegra20/gpio.h
arch/arm/include/asm/arch-rmobile/gpio.h
arch/arm/include/asm/arch-tegra/gpio.h
arch/arm/include/asm/gpio.h
arch/arm/include/asm/arch-bcm2835/gpio.h
arch/arm/include/asm/arch-mxs/gpio.h
arch/arm/include/asm/arch-s3c24x0/gpio.h
arch/arm/include/asm/arch-davinci/gpio.h
arch/arm/include/asm/arch-nomadik/gpio.h
arch/arm/include/asm/arch-armada100/gpio.h
arch/arm/include/asm/arch-tegra114/gpio.h
arch/arm/include/asm/arch-armv8/gpio.h
arch/arm/include/asm/arch-mx6/gpio.h
arch/arm/include/asm/arch-exynos/gpio.h
arch/arm/include/asm/arch-omap4/gpio.h
arch/arm/include/asm/arch-mx27/gpio.h
arch/arm/include/asm/arch-mx35/gpio.h
arch/arm/include/asm/arch-u8500/gpio.h
arch/arm/include/asm/arch-mx25/gpio.h
arch/arm/include/asm/arch-kirkwood/gpio.h
arch/arm/include/asm/arch-omap5/gpio.h
arch/arm/include/asm/arch-tegra30/gpio.h
arch/arm/include/asm/arch-at91/gpio.h
arch/arm/include/asm/arch-s5pc1xx/gpio.h
arch/arm/include/asm/arch-mx31/gpio.h

York

[U-Boot] When to create a SoC directory for ARM

[Tom Rini]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/26/2013 05:32 PM, York Sun wrote:
> On 09/26/2013 02:26 PM, Scott Wood wrote:
>> On Thu, 2013-09-26 at 14:07 -0700, York Sun wrote:
>>> On 09/26/2013 02:03 PM, Tom Rini wrote:
>>>> On 09/26/2013 04:59 PM, Scott Wood wrote:
>>>>> On Thu, 2013-09-26 at 16:49 -0400, Tom Rini wrote:
>>>>>> On 09/26/2013 04:44 PM, Scott Wood wrote:
>>>>>>> On Thu, 2013-09-26 at 12:57 -0700, York Sun wrote:
>>>>>>>> On 09/26/2013 12:55 PM, Scott Wood wrote:
>>>>>>>>> On Thu, 2013-09-26 at 12:48 -0700, York Sun wrote:
>>>>>>>>>> On 09/26/2013 12:46 PM, Sharma Bhupesh-B45370
>>>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> -----Original Message----- From: 
>>>>>>>>>>>> u-boot-bounces at lists.denx.de 
>>>>>>>>>>>> [mailto:u-boot-bounces at lists.denx.de] On
>>>>>>>>>>>> Behalf Of Scott Wood Sent: Friday, September
>>>>>>>>>>>> 27, 2013 12:53 AM To: FengHua Cc: trini; sun
>>>>>>>>>>>> york-R58495; u-boot Subject: Re: [U-Boot]
>>>>>>>>>>>> When to create a SoC directory for ARM
>>>>>>>>>>>> 
>>>>>>>>>>>> On Thu, 2013-09-26 at 13:23 +0800, FengHua
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> all SOC specific include file should be in
>>>>>>>>>>>>>  arch/arm/include/asm/arch-SOC/ or some
>>>>>>>>>>>>> common directory(like
>>>>>>>>>>>>> include/asm/imx-common). Currently, u-boot
>>>>>>>>>>>>> only link SOC specific(arch-SOC) include 
>>>>>>>>>>>>> directory. You could touch a mmu.h file in
>>>>>>>>>>>>>  arch/arm/include/asm/arch-ls2/ and include
>>>>>>>>>>>>>  arch/arm/include/asm/arch-armv8/mmu.h. or
>>>>>>>>>>>>> move arch-armv8/mmu.h to
>>>>>>>>>>>>> arch/arm/include/asm/ to make it as a
>>>>>>>>>>>>> generic file. Maybe we should distinguish 
>>>>>>>>>>>>> architecture specific include directory and
>>>>>>>>>>>>> SOC specific include directory.
>>>>>>>>>>>> 
>>>>>>>>>>>> Is the XXX arch-XXX supposed to be an SoC
>>>>>>>>>>>> family or a CPU family/architectutre?
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Usually in 'arch/arm/include/asm' we have both:
>>>>>>>>>>> - arch-armv7 (Arch specific. Houses stuff
>>>>>>>>>>> common to ARMv7 CPU, e.g. Global timer, SP805
>>>>>>>>>>> WDT..) - arch-mx6 (SoC family specific. Houses
>>>>>>>>>>> stuff like SoC specific IOMUX pads..)
>>>>>>>>> 
>>>>>>>>> Which one does "#inculde <asm/arch/foo.h>" refer
>>>>>>>>> to?
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> arm/arch is a symbolic link created at compiling
>>>>>>>> time. It points to arm/arch-$(soc), if $(soc) is not
>>>>>>>> defined, then it points to asm/arch-$(arch). That's
>>>>>>>> my understanding.
>>>>>>> 
>>>>>>> How is that supposed to work when both arch-$(soc) and 
>>>>>>> arch-$(arch) are present?  Why are SoC and CPU arch
>>>>>>> confused in this way?
>>>>>> 
>>>>>> Primarily because it hasn't been an issue until now
>>>>>> really. What's wrong with just saying
>>>>>> <asm/arch-armv[78]/foo.h> as needed ?
>>>> 
>>>>> Hmm, the only relevant <asm/arch/mmu.h> are in
>>>>> armv8-specific files, so I suppose we could do that.  Why
>>>>> not just rename it asm/armv[78], though?  There are only a
>>>>> handful of files in both armv7 and armv8, so it shouldn't
>>>>> be too much of a problem.  Then there's no question of
>>>>> where the symlink points.
>>>> 
>>>> That should also be fine, after a quick git grep around..
>>>> 
>>> How about arch/arm/include/asm/gpio.h? it includes
>>> <asm/arch/gpio.h>.
>> 
>> gpio.h doesn't belong in the armv8 directory.
>> 
> 
> No, it doesn't. But oddly we have a lot of them. And since it is 
> including <asm/arch/gpio.h>, we have to make it happy.

No, we have to move it from asm/arch-armv8/gpio.h to
asm/arch-soc/gpio.h for that family.

- -- 
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSRKmaAAoJENk4IS6UOR1WHWsQAJFfQLT7zDAQ/QODxKFecwZH
yJyXQaENoHtyF3Rvbzxt6mbupjJ3gviVJrhFQUSZ9jmTokbeLRC+26g7FPqtGeWh
EfpfcRHaEJ5hMkZxa/V97357DOrfitX68uCXpBMmzQcj2l1DF6SPJ3CcV8+XjoCO
5ZjKQpahBC2Pxd++cH3oPEGvy00DH55giOpVxwdBHKZGP3X/ySqoY5C54Nojg6+P
r7d33vceIKLBVh4kln8bZPjFNR3BqoYfRBphgNRP6AyhEBDvuTbF0JjT107Ym1yX
awo3wcmm+oGl3/ptUZh9nk8rsIbLkirhx84UZJUrb812QZnO5ORwxgExp5IRgO9T
Y0ofH9bLFy2jBZwyNVzp0QPi5bhBPe8ehYTW0aFIK9eydhbNTIuxMjDXdp8TaSjC
w3pq+iE13clfoFL51iI/gm09RDH4/vpb2G5VRO9tCwVCzPIxO5hG3NJ0FE3S0sJR
SItirnxs+ekH/vCCC5elJRrI89kAK8OJwe0KyhQAZJYfY9R6jwmrwJxcFEvw6qwU
rRrc3u6yiHUgbgnuNwUZQKoGLmVh4/5TFpE8h12zzMlI7XZmq5QnEPbSfOeiR1Np
vCZZKbyMbsdc/+UNiQYABGvpOJV8OIO7fkGhhS3+LChehWYsYnff23E522QPnKn6
Kcnvd4U5EP3erixNFWc7
=A+o+
-----END PGP SIGNATURE-----