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

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

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

[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] 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?

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

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