From owner-freebsd-arm@FreeBSD.ORG Thu Mar 19 21:35:41 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 40C54241 for ; Thu, 19 Mar 2015 21:35:41 +0000 (UTC) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EA6CAC45 for ; Thu, 19 Mar 2015 21:35:40 +0000 (UTC) Received: by qgf3 with SMTP id 3so77544817qgf.3 for ; Thu, 19 Mar 2015 14:35:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=caTkOw5kxL5IlxVCnK8IKXY3av/kSQmykzMV6spNjVo=; b=nPnay2R8iEbjq2Q+M5qXWaQiJscSLcynSTXzutJDgn0k7mQmITLpkDuVvScLVF0fnR mAfkqEQz5dQbNamGOSJbbO8SjkuylAVX3YAa/uVENvQQP82eyMaU0s2Qj2hk5iNDHDNT Nh+ypHDoY0NwW4VcCoePlQtG/tRiixCljiySSbXvE7Af/uq5LvBM1/tnoRDsxb2dT/aL aZhwbd+vh+iMO24afzg3G9aaD5w0IQe+ru2q/ekatmZilXUZ0WlL4g5OpRpXzNvBq/my Q2ghbIl+8wsTajhSSb3kfK3hZjc5mIOwoWvlLvcuruSYOpbH63yXF23sSpTyeXSIadIQ RvQQ== MIME-Version: 1.0 X-Received: by 10.140.98.2 with SMTP id n2mr61971954qge.62.1426800940122; Thu, 19 Mar 2015 14:35:40 -0700 (PDT) Received: by 10.140.37.82 with HTTP; Thu, 19 Mar 2015 14:35:40 -0700 (PDT) In-Reply-To: References: Date: Thu, 19 Mar 2015 18:35:40 -0300 Message-ID: Subject: Re: Zynq-7020 SoC on-chip-memory From: =?UTF-8?Q?Mat=C3=ADas_Perret_Cantoni?= To: Thomas Skibo Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 21:35:41 -0000 2015-03-19 16:19 GMT-03:00 Thomas Skibo : > > > > On Mar 19, 2015, at 9:58 AM, Mat=C3=ADas Perret Cantoni 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 map= ping > > and the address filtering behavior of the Snoop Control Unit, and it lo= oks > > 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=E2=80=A60x1FFF_FFFF is off chip RAM. The first megabyte= , 0x0000_0000..0x000F_FFFF, has a lot of caveats WRT devices accessing it s= o 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 a= ddress 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 betwee= n the CPUs. And, I=E2=80=99m 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]=3D1111 mpcore.SCU_CONTROL_REGISTER[Address_Filtering_Enable]=3D1 mpcore.Filtering_Star_Address_Register=3D 0x0000_0000 mpcore.Filtering_End_Address_Register=3D 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 specificat= ion > > says that If a system has multiple memory ranges one can create multipl= e > > 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 =3D "memory"; > > reg =3D <0x100000 0x1ff00000>; /* 511MB RAM at 0x100000 */ > > }; > > > > My first attempt was to modify the reg property of the memory node: > > > > 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 stil= l 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 n= ode > > for the on-chip-mem: > > > > > > memory@100000 { // DDR3 RAM off-chip > > device_type =3D "memory"; > > reg =3D <0x100000 0x1ff00000>; /* 511MB RAM at 0x100000 */ > > }; > > > > > > 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= : > > > > root@zedboard:~ # dmesg | grep memory > > real memory =3D 535822336 (511 MB) > > avail memory =3D 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 nod= e in > > the dts that represents the on-chip-memory. This isn't really useful bu= t at > > least I was able to read/write the memory with a simple newbus characte= r > > driver. The dts node I added is: > > > > 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 > > > > ocm: ocm@0 { > > compatible =3D "lac,ocm"; > > reg =3D <0x0 0xFF>; // First 128Bytes of OCM > > }; > > > > So the driver gets the resources: > > > > root@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 n= ot: > > > > 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 zy= 7_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-u= p. 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=E2=80=99s worth. > > Cheers, > =E2=80=94Thomas > > > =E2=80=94=E2=80=94=E2=80=94 > Thomas Skibo > thomasskibo@sbcglobal.net > > >