Zynq-7020 SoC on-chip-memory

Matías Perret Cantoni perretcantonim at gmail.com
Thu Mar 19 21:35:41 UTC 2015


2015-03-19 16:19 GMT-03:00 Thomas Skibo <thomasskibo at sbcglobal.net>:
>
>
> > On Mar 19, 2015, at 9:58 AM, Matías Perret Cantoni <perretcantonim at gmail.com> wrote:
> >
> > Hi everyone.
> >
> > The board I'm using (Zedboard) has a Zynq-7020 SoC which has 256KB of
> > on-chip-memory (OCM) with execute-in-place capabilities.
> > I'd like to add this memory as part of the system memory, but either I
> > can't add it, or I don't know how to "see it".
> >
> > Please let me know if this is not the right place to make this kind of
> > questions, I'll try to clarify myself:
> >
> > First of all I've checked all the registers that defines the memory mapping
> > and the address filtering behavior of the Snoop Control Unit, and it looks
> > like both CPUs sees this memory map:
> >
> > 0x0010_0000        0x1FF0_0000      0xFFFC_0000      0xFFFF_FFFF
> > /                             /                           /
> >       /
> > +++++++++++++++++++++++++++++++
> > |                           |****************|                          |
> > |       511MB         |****************|     256KB          |
> > |  (off chip RAM)  |****************| (on chip RAM)  |
> > |                           |****************|                          |
> > +++++++++++++++++++++++++++++++
> >
> > (I believe Thomas Skibo can easily correct me here)
>
> Yes, 0x0010_0000…0x1FFF_FFFF is off chip RAM.  The first megabyte, 0x0000_0000..0x000F_FFFF, has a lot of caveats WRT devices accessing it so I ignore it (See Table 4.1 in the Zynq Ref manual).
>
> I looked at the Snoop Control Unit registers on my Zedboard and the end address is set to 0xffe00000.  I don’t know much about the SCU but I assume that means the OCM region wouldn’t be cache-coherent between the CPUs.  And, I’m not sure where that register gets set.

I don't know either where this registers get set, but they have the
values that table 29-6 of the Zynq Reference Manual describes:

slcr.OCM_CFG[RAM_HI]=1111
mpcore.SCU_CONTROL_REGISTER[Address_Filtering_Enable]=1
mpcore.Filtering_Star_Address_Register= 0x0000_0000
mpcore.Filtering_End_Address_Register= 0xFFE0_0000

This means, I guess, that we have the memory mapping I've described before.
About coherency, I've read many times the chapters of the manual that
I've found relevant and I still can't tell whether access are coherent
or not.

>
> >
> > So far I modified the memory node of the dts file: The ePAPR specification
> > says that If a system has multiple memory ranges one can create multiple
> > memory nodes or just specify the ranges in the reg property of a single
> > memory node.
> >
> > The memory node of the dts file in HEAD is:
> >
> >  memory {
> >  // First megabyte isn't accessible by all interconnect masters.
> >  device_type = "memory";
> >  reg = <0x100000 0x1ff00000>;  /* 511MB RAM at 0x100000 */
> >  };
> >
> > My first attempt was to modify the reg property of the memory node:
> >
> >  memory {
> >  device_type = "memory";
> >  reg = <0x100000 0x1ff00000>,    /* 511MB RAM at 0x100000 */
> >  <0xFFFC0000 0x3FFFF>;  /* 256KB on-chip-memory at 0xfffc0000 */
> >  };
>
> Shouldn’t it be <0xFFFC0000 0x40000>?  I think it’ll still cause trouble, though.

Hum, I don't know. I'll try it tomorrow when I get to use the Zed.

>
>
> >
> > But the system hangs during boot. Then I tried to add a second memory node
> > for the on-chip-mem:
> >
> >
> >  memory at 100000 {   // DDR3 RAM off-chip
> >        device_type = "memory";
> >        reg = <0x100000 0x1ff00000>; /* 511MB RAM at 0x100000 */
> >  };
> >
> >
> >  memory at FFFC0000 {    // On-Chip-Memory
> >        device_type = "memory";
> >        reg = <0xFFFC0000 0x3FFFF>;  /* 256KB at 0xFFFC0000 */
> >  };
>
> I don’t think that (separate nodes) is supported.  ??
>
>
> > In this case the system boots ok but I still see 511MB of system memory:
> >
> > root at zedboard:~ # dmesg | grep memory
> > real memory  = 535822336 (511 MB)
> > avail memory = 515801088 (491 MB)
> >
> > db> show physmem
> > Physical memory chunk(s):
> >  0x00100000 - 0x1fffffff,   511 MB ( 130816 pages)
> > Excluded memory regions:
> >  0x00100000 - 0x007effff,     6 MB (   1776 pages) NoAlloc
> >
> >
> > (Maybe I'm not checking properly :/ )
> >
> > ------
> > As an attempt to check If I can access this memory I added a device node in
> > the dts that represents the on-chip-memory. This isn't really useful but at
> > least I was able to read/write the memory with a simple newbus character
> > driver. The dts node I added is:
> >
> >  ocm_area at FFFC0000 {
> >     device_type = "soc";
> >     compatible = "simple-bus";
> >     #address-cells = <1>;
> >     #size-cells = <1>;
> >     ranges = <0x0 0xFFFC0000 0x3FFFF>;   // OCM: 256KB
> >
> >     ocm: ocm at 0 {
> >           compatible = "lac,ocm";
> >           reg = <0x0 0xFF>;  // First 128Bytes of OCM
> >     };
> >
> > So the driver gets the resources:
> >
> > root at zedboard:/boot/msdos # devinfo -r | head
> > nexus0
> >  ofwbus0
> >    simplebus0
> >      ocm_driver0
> >          Device Memory:
> >              0xfffc0000-0xfffc00fe
> >
> > But here I would expected that the device's memory range
> > (0xfffc0000-0xfffcffff) was included in the devmap's ranges, but it's not:
> >
> > db> show devmap
> > Static device mappings:
> >  0xe0000000 - 0xe02fffff mapped at VA 0xffc00000
> >  0xf8000000 - 0xf8ffffff mapped at VA 0xfec00000
>
> These are only the static mappings set up in platform_devmap_init() in zy7_machdep.c.  You can either add a static mapping in platform_devmap_init() so it shows up in “show devmap” or you can put a printf in your driver that prints the virtual address of the device memory at boot-up.

Great, I didn't know this.

Thank you Thomas!
Regards.
>
> >
> >
> > So I can't inspect the on-chip-memory range from the debugger either.
> >
> > Any advice on how to add this memory to my system?
>
> I think it might be more trouble than it’s worth.
>
> Cheers,
> —Thomas
>
>
> ———
> Thomas Skibo
> thomasskibo at sbcglobal.net
>
>
>


More information about the freebsd-arm mailing list