Zynq-7020 SoC on-chip-memory
Thomas Skibo
thomasskibo at sbcglobal.net
Thu Mar 19 19:22:28 UTC 2015
> 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.
>
> 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.
>
> 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.
>
>
> 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