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@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
