Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 19 Mar 2015 12:19:32 -0700
From:      Thomas Skibo <thomasskibo@sbcglobal.net>
To:        =?utf-8?Q?Mat=C3=ADas_Perret_Cantoni?= <perretcantonim@gmail.com>
Cc:        freebsd-arm@freebsd.org
Subject:   Re: Zynq-7020 SoC on-chip-memory
Message-ID:  <D2F57338-AC51-4A2D-982B-F024A5E422E4@sbcglobal.net>
In-Reply-To: <CADLKG01oSQ=caZFOnZQM14=pAVPvLz45EznMes9mVfG2kD6TEQ@mail.gmail.com>
References:  <CADLKG01oSQ=caZFOnZQM14=pAVPvLz45EznMes9mVfG2kD6TEQ@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help

> On Mar 19, 2015, at 9:58 AM, Mat=C3=ADas Perret Cantoni =
<perretcantonim@gmail.com> wrote:
>=20
> Hi everyone.
>=20
> 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".
>=20
> Please let me know if this is not the right place to make this kind of
> questions, I'll try to clarify myself:
>=20
> 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:
>=20
> 0x0010_0000        0x1FF0_0000      0xFFFC_0000      0xFFFF_FFFF
> /                             /                           /
>       /
> +++++++++++++++++++++++++++++++
> |                           |****************|                         =
 |
> |       511MB         |****************|     256KB          |
> |  (off chip RAM)  |****************| (on chip RAM)  |
> |                           |****************|                         =
 |
> +++++++++++++++++++++++++++++++
>=20
> (I believe Thomas Skibo can easily correct me here)

Yes, 0x0010_0000=E2=80=A60x1FFF_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=E2=80=99t know much about the SCU =
but I assume that means the OCM region wouldn=E2=80=99t be =
cache-coherent between the CPUs.  And, I=E2=80=99m not sure where that =
register gets set.

>=20
> 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.
>=20
> The memory node of the dts file in HEAD is:
>=20
>  memory {
>  // First megabyte isn't accessible by all interconnect masters.
>  device_type =3D "memory";
>  reg =3D <0x100000 0x1ff00000>;  /* 511MB RAM at 0x100000 */
>  };
>=20
> My first attempt was to modify the reg property of the memory node:
>=20
>  memory {
>  device_type =3D "memory";
>  reg =3D <0x100000 0x1ff00000>,    /* 511MB RAM at 0x100000 */
>  <0xFFFC0000 0x3FFFF>;  /* 256KB on-chip-memory at 0xfffc0000 */
>  };

Shouldn=E2=80=99t it be <0xFFFC0000 0x40000>?  I think it=E2=80=99ll =
still cause trouble, though.


>=20
> But the system hangs during boot. Then I tried to add a second memory =
node
> for the on-chip-mem:
>=20
>=20
>  memory@100000 {   // DDR3 RAM off-chip
>        device_type =3D "memory";
>        reg =3D <0x100000 0x1ff00000>; /* 511MB RAM at 0x100000 */
>  };
>=20
>=20
>  memory@FFFC0000 {    // On-Chip-Memory
>        device_type =3D "memory";
>        reg =3D <0xFFFC0000 0x3FFFF>;  /* 256KB at 0xFFFC0000 */
>  };

I don=E2=80=99t think that (separate nodes) is supported.  ??


> In this case the system boots ok but I still see 511MB of system =
memory:
>=20
> root@zedboard:~ # dmesg | grep memory
> real memory  =3D 535822336 (511 MB)
> avail memory =3D 515801088 (491 MB)
>=20
> db> show physmem
> Physical memory chunk(s):
>  0x00100000 - 0x1fffffff,   511 MB ( 130816 pages)
> Excluded memory regions:
>  0x00100000 - 0x007effff,     6 MB (   1776 pages) NoAlloc
>=20
>=20
> (Maybe I'm not checking properly :/ )
>=20
> ------
> 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:
>=20
>  ocm_area@FFFC0000 {
>     device_type =3D "soc";
>     compatible =3D "simple-bus";
>     #address-cells =3D <1>;
>     #size-cells =3D <1>;
>     ranges =3D <0x0 0xFFFC0000 0x3FFFF>;   // OCM: 256KB
>=20
>     ocm: ocm@0 {
>           compatible =3D "lac,ocm";
>           reg =3D <0x0 0xFF>;  // First 128Bytes of OCM
>     };
>=20
> So the driver gets the resources:
>=20
> root@zedboard:/boot/msdos # devinfo -r | head
> nexus0
>  ofwbus0
>    simplebus0
>      ocm_driver0
>          Device Memory:
>              0xfffc0000-0xfffc00fe
>=20
> But here I would expected that the device's memory range
> (0xfffc0000-0xfffcffff) was included in the devmap's ranges, but it's =
not:
>=20
> 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 =E2=80=9Cshow devmap=E2=80=9D =
or you can put a printf in your driver that prints the virtual address =
of the device memory at boot-up.

>=20
>=20
> So I can't inspect the on-chip-memory range from the debugger either.
>=20
> Any advice on how to add this memory to my system?

I think it might be more trouble than it=E2=80=99s worth.

Cheers,
=E2=80=94Thomas


=E2=80=94=E2=80=94=E2=80=94
Thomas Skibo
thomasskibo@sbcglobal.net






Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D2F57338-AC51-4A2D-982B-F024A5E422E4>