Hi, > -----Original Message----- > From: Giordon Stark [mailto:[email protected]] > Sent: Tuesday, January 02, 2018 2:15 PM > To: Nathan Rossi <[email protected]> > Cc: Manjukumar Harthikote Matha <[email protected]>; Tang, Shaochun > <[email protected]>; [email protected] > Subject: Re: [meta-xilinx] Wrong DRAM set for custom board using FSBL + > u-boot? > > Hi, > > I've followed along with everything so far. I'm finding that device-tree.bb > <http://device-tree.bb> is not very happy with my initial structure of > device-tree > files. Here > (https://github.com/kratsg/meta-l1calo/tree/master/recipes-bsp/device- > tree) you can see my device-tree.bbappend and the associated files. > > I was hoping to structure my device tree sources this way, because I will > eventually > want > > boards/gfex > boards/jfex > boards/... > > in the future, and each group has their own set of versioned codes. What I'm > seeing > now, when I run `bitbake device-tree` is this: > > ERROR: device-tree-1.0-r0 do_compile: Function failed: do_compile (log file is > located at /local/d4/gstark/poky/build/tmp/work/gfex_prototype3-poky- > linux/device-tree/1.0-r0/temp/log.do_compile.29239) > ERROR: Logfile of failure stored in: > /local/d4/gstark/poky/build/tmp/work/gfex_prototype3-poky-linux/device- > tree/1.0-r0/temp/log.do_compile.29239 > Log data follows: > | DEBUG: Executing shell function do_compile > | gcc: error: > | /local/d4/gstark/poky/build/tmp/work/gfex_prototype3-poky-linux/device > | -tree/1.0-r0/*.dts: No such file or directory > | gcc: warning: ‘-x assembler-with-cpp’ after last input file has no > | effect > | gcc: fatal error: no input files > | compilation terminated. > | WARNING: /local/d4/gstark/poky/build/tmp/work/gfex_prototype3-poky- > linux/device-tree/1.0-r0/temp/run.do_compile.29239:1 exit 1 from 'gcc -E - > nostdinc -Ulinux -x assembler-with-cpp - > I/local/d4/gstark/poky/build/tmp/work/gfex_prototype3-poky-linux/device- > tree/1.0-r0 -I/local/d4/gstark/poky/build/tmp/work-shared/gfex- > prototype3/kernel-source/arch/arm64/boot/dts - > I/local/d4/gstark/poky/build/tmp/work-shared/gfex-prototype3/kernel- > source/arch/arm64/boot/dts/include -I/local/d4/gstark/poky/build/tmp/work- > shared/gfex-prototype3/kernel-source/arch/arm64/boot/dts/xilinx -o `basename > ${DTS_FILE}`.pp ${DTS_FILE}' > | ERROR: Function failed: do_compile (log file is located at > | /local/d4/gstark/poky/build/tmp/work/gfex_prototype3-poky-linux/device > | -tree/1.0-r0/temp/log.do_compile.29239) > ERROR: Task (/local/d4/gstark/meta-xilinx/recipes-bsp/device-tree/device- > tree.bb:do_compile) failed with exit code '1' > NOTE: Tasks Summary: Attempted 504 tasks of which 502 didn't need to be rerun > and 1 failed. > > and when I look in this directory referenced: > > kratsg@dc:/local/d4/gstark/poky/build$ ls > /local/d4/gstark/poky/build/tmp/work/gfex_prototype3-poky-linux/device- > tree/1.0-r0/ > total 40K > drwxr-xr-x 9 kratsg atlas 4.0K Jan 2 14:58 . > drwxr-xr-x 3 kratsg atlas 4.0K Jan 2 14:50 .. > drwxr-xr-x 2 kratsg atlas 4.0K Jan 2 14:58 build > -rw-r--r-- 1 kratsg atlas 33 Jan 2 14:58 configure.sstate > drwxr-xr-x 3 kratsg atlas 4.0K Jan 2 14:50 gfex drwxr-xr-x 3 kratsg atlas > 4.0K Jan 2 > 14:52 license-destdir drwxr-xr-x 2 kratsg atlas 4.0K Jan 2 14:50 patches > drwxr-xr-x > 2 kratsg atlas 4.0K Jan 2 14:58 recipe-sysroot drwxr-xr-x 6 kratsg atlas > 4.0K Jan 2 > 14:50 recipe-sysroot-native drwxr-xr-x 2 kratsg atlas 4.0K Jan 2 16:06 temp > > it seems that it expects everything to be at the top-level... that I need > some sort of > system-top.dts to make device-tree.bb <http://device-tree.bb> happy. Am I > doing > this wrong? Is my structure wrong or is device-tree.bb > <http://device-tree.bb> a bit > more pickier than I realized? I also updated u-boot to add the extra OEMAKE > commands (https://github.com/kratsg/meta-l1calo/blob/master/recipes-bsp/u- > boot/u-boot-xlnx_2017.1.bbappend) so if those look wrong, let me know. >
The S is set to workdir https://github.com/Xilinx/meta-xilinx/blob/master/meta-xilinx-bsp/recipes-bsp/device-tree/device-tree.bb#L22 I think all the dts* files are under gfex, basically you need to set your S directory to the location where all the dts* files are present. You can also rearrange on how you store the dts files as boards/ gfex-prototype2/*.dts boards/ gfex-prototype3/*.dts etc and have bbappend as SRC_URI_append_gfex-prototype3 = " \ file://pcw.dtsi " This will allow all the dts* files to be copied in WORKDIR and build it from there. Thanks, Manju > Thanks! > > Giordon > > On Wed, Dec 13, 2017 at 10:22 AM Nathan Rossi <[email protected] > <mailto:[email protected]> > wrote: > > > On 14 December 2017 at 00:53, Giordon Stark <[email protected] > <mailto:[email protected]> > wrote: > > Hi Nathan, replies inline. > > > > On Wed, Dec 13, 2017 at 8:33 AM Nathan Rossi > <[email protected] <mailto:[email protected]> > wrote: > >> > >> Hi Giordon, > >> > >> Not exactly sure what state your configuration is in, so I'm just > >> going to cover some things you should check to ensure you have it all > >> setup such that it should result in u-boot running with the correct > >> device tree, and using said device trees memory information. > >> > >> 1. > >> > >> CONFIG_SYS_SDRAM_BASE=0x00000000 > >> CONFIG_SYS_SDRAM_SIZE=0x80000000 > >> > >> These override the use of device tree memory sizes, make sure you > have > >> them set correctly or not set at all. > > > > > > I have tried to override by setting these - and they had no effect. I > > definitely know my patch was working since I saw the "dirty u-boot" > version. > > So I'm not sure why it didn't work. > > > >> > >> > >> 2. The layer you link to uses MACHINE_DEVICETREE, this variable is no > >> longer used in meta-xilinx, make sure you are actually building what > >> you expect from a device tree perspective either with the > >> device-tree.bb <http://device-tree.bb> recipe or otherwise. Also > note > this variable never did > >> anything with regards to u-boot. > > > > > > I had initially gotten my code structure for machine definitions from > > Meta-Xilinx 2 years ago when I started > > (https://github.com/Xilinx/meta- > xilinx/commit/cad8934cba1ba92a612462ad6fa83b50116668a4#diff- > 14eb4dffd8249a14ad6a5e72b196b5b7) > > and I have a hard time keeping up with all of the changes. It looks > like you > > just replace it with a dtb file. > > For the zc706 the device tree was changed to use the kernel as the > source of the dtb. This is where KERNEL_DEVICETREE comes in, its the > name of the make target/dts to build the device tree in the kernel. > > The more important change relevant to your use case was this one: > > https://github.com/Xilinx/meta- > xilinx/commit/e448d3c1de3ce284ef42a591fd89cf4c2b6a81cf > > > > > Looking at device-tree.bb <http://device-tree.bb> : > > https://github.com/Xilinx/meta-xilinx/blob/master/recipes-bsp/device- > tree/device-tree.bb > > -- I'm not clear on how to "use" this recipe. What do I need to set? > > As for using the device-tree recipe, you should supply your device > tree files via SRC_URI with a bbappend. See the bbappend in the > meta-xilinx layer for an example of how to set that up. > > https://github.com/Xilinx/meta-xilinx/blob/master/recipes-bsp/device- > tree/device-tree.bbappend > > And their sources: > > https://github.com/Xilinx/meta-xilinx/tree/master/recipes-bsp/device- > tree/files > > Your layer would append to the recipe and add your device tree sources > that are located in your layer. > > > > >> > >> > >> 3. Your u-boot appears to be configured to use the zynqmp-zcu102 > device > >> tree? > >> > >> > >> https://github.com/kratsg/meta-l1calo/blob/master/recipes-bsp/u- > boot/u-boot-xlnx/0002-add-gfex-prototype3-defconfig.patch#L27 > >> > >> You will need to pass your device tree in, in order to build a u-boot > >> that uses your device tree (and thus your memory config). You can do > >> this by putting your device tree in the u-boot source, building it > and > >> using that device tree for both u-boot and optionally the kernel. > >> Alternatively you can build the device tree outside of u-boot and > pass > >> it in as a blob with EXT_DTB (as suggested by Manju). > >> > >> For an example of the EXT_DTB method, have a look at this bbappend, > >> > >> https://github.com/nathanrossi/meta- > xilinx/blob/60193934fc1c7717a71f272370aaad1bfeb118b4/recipes-bsp/u- > boot/u-boot_2017.09.bbappend. > >> This hooks up the dtb built by device-tree.bb > <http://device-tree.bb> . > > > > > > It looks like, if I somehow get the device-tree.bb > <http://device-tree.bb> > working, I need to append > > to the EXTRA_OEMAKE variable for my machine in this bbappend file: > > https://github.com/kratsg/meta-l1calo/blob/master/recipes-bsp/u- > boot/u-boot-xlnx_2017.1.bbappend > > -- correct? Although I'm not understanding why you reference u-boot > here, > > when it seems like u-boot-xlnx is what is being used. > > Yes that would be the append you want. u-boot/u-boot-xlnx are > basically the same from a build perspective. I had only pointed at the > u-boot bbappend for an example of the content for how to setup the > recipe, I did not have an example that uses u-boot-xlnx :). > > > > > Thanks! None of this seems obvious for people new to yocto (or meta- > xilinx) > > Unfortunately there are many ways to deal with setting up BSPs, and > U-Boot has only more recently become more easy to setup with just DTBs > and defconfig (previously it required source patching to support > BSPs). So documenting or providing recipes for this in OE/Yocto has > not really matured. But you are welcome to contribute > documentation/etc. based on your experiences to meta-xilinx, OE or > Yocto :). > > Regards, > Nathan > > > btw. > > > >> > >> > >> Regards, > >> Nathan > >> > >> On 14 December 2017 at 00:11, Giordon Stark <[email protected] > <mailto:[email protected]> > wrote: > >> > Hi all, > >> > > >> > Any ideas what else I can do? > >> > > >> > Giordon > >> > > >> > On Fri, Dec 8, 2017 at 11:47 AM Giordon Stark <[email protected] > <mailto:[email protected]> > wrote: > >> >> > >> >> Hi Manju, > >> >> > >> >> I guess I'm definitely not understanding. I'm using a custom > machine > >> >> defined here > >> >> > >> >> (https://github.com/kratsg/meta- > l1calo/blob/master/conf/machine/gfex-prototype3.conf) > >> >> which does inherit from zcu102-zynqmp -- but I override the > >> >> MACHINE_DEVICETREE setting here. From what I understood, u-boot > should > >> >> be > >> >> picking this up. (My custom layer is in bold below) > >> >> > >> >> Giordon > >> >> > >> >> kratsg@dc:/local/d4/gstark/poky/build$ bitbake-layers show-layers > >> >> layer path > >> >> priority > >> >> > >> >> > ================================================================ > ========== > >> >> meta /local/d4/gstark/poky/meta 5 > >> >> meta-poky /local/d4/gstark/poky/meta-poky 5 > >> >> meta-yocto-bsp /local/d4/gstark/poky/meta-yocto-bsp 5 > >> >> meta-xilinx /local/d4/gstark/meta-xilinx 5 > >> >> meta-oe /local/d4/gstark/meta-openembedded/meta-oe > 6 > >> >> meta-python /local/d4/gstark/meta-openembedded/meta- > python 7 > >> >> meta-l1calo /local/d4/gstark/meta-l1calo 7 > >> >> workspace /local/d4/gstark/poky/build/workspace 99 > >> >> > >> >> > >> >> On Fri, Dec 8, 2017 at 11:39 AM Manjukumar Harthikote Matha > >> >> <[email protected] <mailto:[email protected]> > > wrote: > >> >>> > >> >>> > >> >>> > >> >>> > -----Original Message----- > >> >>> > From: Giordon Stark [mailto:[email protected] > <mailto:[email protected]> ] > >> >>> > Sent: Friday, December 08, 2017 9:05 AM > >> >>> > To: Manjukumar Harthikote Matha <[email protected] > <mailto:[email protected]> > > >> >>> > Cc: Mike Looijmans <[email protected] > <mailto:[email protected]> >; Tang, Shaochun > >> >>> > <[email protected] <mailto:[email protected]> >; > >> >>> > [email protected] <mailto:meta- > [email protected]> > >> >>> > Subject: Re: [meta-xilinx] Wrong DRAM set for custom board > using > >> >>> > FSBL + > >> >>> > u-boot? > >> >>> > > >> >>> > Hi Manju, > >> >>> > > >> >>> > Sure, but what is EXT_DTB and where do I set it/to what value? > >> >>> > Googling > >> >>> > doesn't > >> >>> > give me a lot of help here. > >> >>> > > >> >>> > >> >>> Compile the dts to dtb and point the location of the DTB in > EXT_DTB > >> >>> while > >> >>> compiling u-boot. > >> >>> > >> >>> If you are using meta-xilinx-tools layer: > >> >>> Edit > >> >>> > >> >>> https://github.com/Xilinx/meta-xilinx-tools/blob/master/recipes- > bsp/u-boot/u-boot-xlnx_%25.bbappend > >> >>> and add > >> >>> UBOOT_MAKE_TARGET_append = " > >> >>> EXT_DTB=${DEPLOY_DIR_IMAGE}/${MACHINE}-system.dtb" > >> >>> > >> >>> Thanks, > >> >>> Manju > >> >>> > >> >>> > >> >>> > Giordon > >> >>> > > >> >>> > On Fri, Dec 8, 2017 at 11:03 AM Manjukumar Harthikote Matha > >> >>> > <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]> > > wrote: > >> >>> > > >> >>> > > >> >>> > > >> >>> > > >> >>> > > -----Original Message----- > >> >>> > > From: [email protected] > <mailto:meta- > [email protected]> > >> >>> > <mailto:meta-xilinx- <mailto:meta-xilinx-> > >> >>> > [email protected] <mailto:[email protected]> > > [mailto:meta-xilinx- <mailto:meta-xilinx-> > >> >>> > <mailto:meta-xilinx- <mailto:meta-xilinx-> > > >> >>> > > [email protected] > <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]> > ] > >> >>> > On > >> >>> > Behalf Of Giordon Stark > >> >>> > > Sent: Thursday, December 07, 2017 10:26 PM > >> >>> > > To: Mike Looijmans <[email protected] > <mailto:[email protected]> > >> >>> > <mailto:[email protected] > <mailto:[email protected]> > > > >> >>> > > Cc: Tang, Shaochun <[email protected] > <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]> > >; > >> >>> > meta- > >> >>> > [email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]> > > >> >>> > > Subject: Re: [meta-xilinx] Wrong DRAM set for custom > board > >> >>> > using FSBL + > >> >>> > u-boot? > >> >>> > > > >> >>> > > Hi Mike, > >> >>> > > > >> >>> > > Is that part of the defconfig or am I looking > somewhere else > >> >>> > for this? I > >> >>> > suppose > >> >>> > > you're not talking about the BOOTARGS here... > >> >>> > > > >> >>> > > >> >>> > Compile the u-boot against the dtb using EXT_DTB > >> >>> > > >> >>> > Thanks, > >> >>> > Manju > >> >>> > > >> >>> > > Giordon > >> >>> > > > >> >>> > > On Fri, Dec 8, 2017 at 12:08 AM Mike Looijmans > >> >>> > <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]> > > >> >>> > > <mailto:[email protected] > <mailto:[email protected]> > >> >>> > <mailto:[email protected] > <mailto:[email protected]> > > > > >> >>> > wrote: > >> >>> > > > >> >>> > > > >> >>> > > Change looks okay, but you (may also) need to > apply > >> >>> > this > >> >>> > to the > >> >>> > bootloader. > >> >>> > > u-boot passes the memory size on to the kernel, > and > >> >>> > the > >> >>> > kernel just > >> >>> > follows > >> >>> > > what u-boot reports. > >> >>> > > > >> >>> > > On 07-12-17 21:35, Giordon Stark wrote: > >> >>> > > > Thanks a lot for the explanation Nathan (and > all). > >> >>> > > > > >> >>> > > > When I implement the change (see diff): > >> >>> > > > > >> >>> > > > diff --git > >> >>> > a/conf/machine/boards/gfex/prototype3/system-top.dts > >> >>> > > > b/conf/machine/boards/gfex/prototype3/system- > top.dts > >> >>> > > > index 4e8ee15..e823bb8 100755 > >> >>> > > > --- > >> >>> > a/conf/machine/boards/gfex/prototype3/system-top.dts > >> >>> > > > +++ > >> >>> > b/conf/machine/boards/gfex/prototype3/system-top.dts > >> >>> > > > @@ -26,6 +26,6 @@ > >> >>> > > > }; > >> >>> > > > memory { > >> >>> > > > device_type = "memory"; > >> >>> > > > - reg = <0x0 0x0 0x0 0x80000000>, > >> >>> > <0x00000008 > >> >>> > 0x00000000 0x0 > >> >>> > > > 0x80000000>; > >> >>> > > > + reg = <0x0 0x0 0x0 0x80000000>, > >> >>> > <0x00000008 > >> >>> > 0x00000000 > >> >>> > > > 0x00000003 0x80000000>; > >> >>> > > > }; > >> >>> > > > }; > >> >>> > > > > >> >>> > > > re-run bitbake, and re-program the board -- we > still > >> >>> > see 4 GiB DRAM. > >> >>> > Any > >> >>> > > ideas? > >> >>> > > > > >> >>> > > > Giordon > >> >>> > > > > >> >>> > > > On Wed, Dec 6, 2017 at 8:49 PM Nathan Rossi > >> >>> > <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]> > > >> >>> > > <mailto:[email protected] > <mailto:[email protected]> > >> >>> > <mailto:[email protected] > <mailto:[email protected]> > > >> >>> > > > >> >>> > > > <mailto:[email protected] > <mailto:[email protected]> > >> >>> > <mailto:[email protected] > <mailto:[email protected]> > <mailto:[email protected] > <mailto:[email protected]> > >> >>> > <mailto:[email protected] > <mailto:[email protected]> > > >> > >> >>> > > wrote: > >> >>> > > > > >> >>> > > > On 7 December 2017 at 11:37, Giordon Stark > >> >>> > <[email protected] <mailto:[email protected]> > >> >>> > <mailto:[email protected] <mailto:[email protected]> > > >> >>> > > <mailto:[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]> > > > >> >>> > > > <mailto:[email protected] > <mailto:[email protected]> > >> >>> > <mailto:[email protected] <mailto:[email protected]> > > >> >>> > <mailto:[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]> > > >> wrote: > >> >>> > > > > Hi Alistair, > >> >>> > > > > > >> >>> > > > > > >> >>> > > > > On Wed, Dec 6, 2017 at 7:23 PM Alistair > >> >>> > Francis > >> >>> > > <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]> > > >> >>> > <mailto:[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]> > > > >> >>> > > > <mailto:[email protected] > <mailto:[email protected]> > >> >>> > <mailto:[email protected] <mailto:[email protected]> > > >> >>> > <mailto:[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]> > > >> > >> >>> > > > > wrote: > >> >>> > > > >> > >> >>> > > > >> On Wed, Dec 6, 2017 at 4:45 PM, Giordon > >> >>> > Stark > >> >>> > <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]> > > >> >>> > > <mailto:[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]> > > > >> >>> > > > <mailto:[email protected] > <mailto:[email protected]> > >> >>> > <mailto:[email protected] <mailto:[email protected]> > > >> >>> > <mailto:[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]> > > >> wrote: > >> >>> > > > >> > Hi Manju, > >> >>> > > > >> > > >> >>> > > > >> > Indeed, you might be right... I > guess now > >> >>> > I'm > >> >>> > confused by > >> >>> > why > >> >>> > > Xilinx is > >> >>> > > > >> > not > >> >>> > > > >> > exporting the HDF to a device tree > >> >>> > correctly: > >> >>> > > > >> > > >> >>> > > > >> > Our block design has the DDR set to > 16gigs > >> >>> > here: > >> >>> > > > >> > > >> >>> > > > >> > > >> >>> > > > > >> >>> > > https://www.dropbox.com/s/r8yzbvlf9kov8ei/Screenshot%202017-12- > >> >>> > > 06%2018.40.29.png?dl=0 > >> >>> > > > >> > Our HDF indicates 2 banks: > >> >>> > > > >> > > >> >>> > > > >> > > >> >>> > > > > >> >>> > > https://www.dropbox.com/s/atodjbt6jf5b4aw/Screenshot%202017-12- > >> >>> > > 06%2018.42.34.png?dl=0 > >> >>> > > > >> > >> >>> > > > >> The second bank there is 45GB isn't it > (it's > >> >>> > hard to count the > >> >>> > f's)? > >> >>> > > > > > >> >>> > > > > > >> >>> > > > > In Xilinx SDK, first column is base > addr, > >> >>> > second > >> >>> > column is high > >> >>> > addr > >> >>> > > (from > >> >>> > > > > xparameters.h I assume). So I'm > reading the > >> >>> > SDK > >> >>> > as: > >> >>> > > > > > >> >>> > > > > psu_ddr_0 0x0000_0000 -> > 0x7fff_ffff > >> >>> > > > > psu_ddr_1 0x8_0000_0000 -> > 0xb_7fff_ffff > >> >>> > > > > > >> >>> > > > > which looks like 2GiBs for the first > one, and > >> >>> > 15GiB for the > >> >>> > second. > >> >>> > > Maybe > >> >>> > > > > I'm not doing the math right here.. > >> >>> > > > >> > >> >>> > > > >> > >> >>> > > > >> > > >> >>> > > > >> > The device tree right now seems to be > >> >>> > saying: > >> >>> > > > >> > > >> >>> > > > >> > bank1 @ 0x0 of size 0x80000000 > >> >>> > > > >> > bank2 @ 0x0 of size 0x80000000 > >> >>> > > > >> > >> >>> > > > >> The device tree is saying two banks. > >> >>> > > > >> > >> >>> > > > >> 1 bank: addr: 0 size of: 0x80000000 > bytes > >> >>> > > > >> 2 bank: addr: 0x800000000 size of > 0x80000000 > >> >>> > bytes > >> >>> > > > > > >> >>> > > > > > >> >>> > > > > How are you seeing this? I'm a bit > confused, > >> >>> > since I understand > >> >>> > > > registers as > >> >>> > > > > > >> >>> > > > > reg = <base size> > >> >>> > > > > > >> >>> > > > > but the device tree has a tuple of 4. > So I'm > >> >>> > not > >> >>> > understanding > >> >>> > what > >> >>> > > each > >> >>> > > > > element in the tuple means semantically: > >> >>> > > > > >> >>> > > > Remember address-cells and size-cells are > set at > >> >>> > 2 > >> >>> > words, so the > >> >>> > > > values are 2 sets of 2. Aka 64-bit > addresses and > >> >>> > sizes. > >> >>> > > > > >> >>> > > > https://github.com/kratsg/meta- > >> >>> > > > >> >>> > > >> >>> > > l1calo/blob/master/conf/machine/boards/gfex/prototype3/zynqmp.dtsi#L16 > >> >>> > > > > >> >>> > > > > > >> >>> > > > > reg = <0x0 0x0 0x0 0x80000000>, > <0x00000008 > >> >>> > 0x00000000 > >> >>> > 0x0 > >> >>> > > 0x80000000>; > >> >>> > > > > > >> >>> > > > > Bank 1: A1=0x0 A2=0x0 > A3=0x0 > >> >>> > A4=0x80000000 > >> >>> > > > > Bank 2: A1=0x00000008 A2=0x00000000 > A3=0x0 > >> >>> > A4=0x80000000 > >> >>> > > > > >> >>> > > > It looks like DTG has generated the upper > word > >> >>> > for > >> >>> > the second > >> >>> > bank > >> >>> > > > size incorrectly? or maybe the issue is > that the > >> >>> > second bank > >> >>> > address > >> >>> > > > range is larger than the available memory? > Not > >> >>> > sure > >> >>> > the problem > >> >>> > on the > >> >>> > > > Vivado/HDF/DTG side. > >> >>> > > > > >> >>> > > > Either way the reg property should > probably be: > >> >>> > > > > >> >>> > > > reg = <0x0 0x0 0x0 0x80000000>, <0x00000008 > >> >>> > 0x00000000 > >> >>> > > 0x00000003 0x80000000>; > >> >>> > > > > >> >>> > > > 1 bank: addr: 0x0_0000_0000 size of: > >> >>> > 0x0_8000_0000 > >> >>> > bytes > >> >>> > > > 2 bank: addr: 0x8_0000_0000 size of: > >> >>> > 0x3_8000_0000 > >> >>> > bytes > >> >>> > > > > >> >>> > > > 0x3_8000_0000 + 0x8000_0000 = 0x4_0000_0000 > == > >> >>> > 16 > >> >>> > GiB > >> >>> > > > > >> >>> > > > Regards, > >> >>> > > > Nathan > >> >>> > > > > >> >>> > > > > > >> >>> > > > > But the sizes seem wrong to me. > >> >>> > > > > > >> >>> > > > >> > >> >>> > > > >> > > >> >>> > > > >> > I'm guessing the 1st and 3rd blocks > here > >> >>> > (size=0x0) could be > >> >>> > safely > >> >>> > > > >> > deleted. > >> >>> > > > >> > >> >>> > > > >> No, don't delete them. > >> >>> > > > >> > >> >>> > > > >> > So I'm misunderstanding this. Is > there a > >> >>> > reason for this not to > >> >>> > > match? A > >> >>> > > > >> > bug? > >> >>> > > > >> > >> >>> > > > >> Can you confirm that your project is > set to > >> >>> > 16GB of memory (I > >> >>> > don't > >> >>> > > > >> know how to do that). Otherwise you > can just > >> >>> > edit the device > >> >>> > tree. > >> >>> > > > > > >> >>> > > > > > >> >>> > > > > We set the DDR in the PS of the block > design > >> >>> > to > >> >>> > 16 GiB as > >> >>> > referenced > >> >>> > > in > >> >>> > > > this > >> >>> > > > > screenshot: > >> >>> > > > > > >> >>> > > > > > >> >>> > > > > >> >>> > > https://www.dropbox.com/s/r8yzbvlf9kov8ei/Screenshot%202017-12- > >> >>> > > 06%2018.40.29.png?dl=0 > >> >>> > > > > > >> >>> > > > > Thanks a lot for the help so far! > Greatly > >> >>> > appreciate it, > >> >>> > > > > > >> >>> > > > > Giordon > >> >>> > > > > > >> >>> > > > > -- > >> >>> > > > > > >> >>> > > > >> >>> > > Kind regards, > >> >>> > > > >> >>> > > Mike Looijmans > >> >>> > > System Expert > >> >>> > > > >> >>> > > TOPIC Products > >> >>> > > Materiaalweg 4, NL-5681 RJ Best > >> >>> > > Postbus 440, NL-5680 AK Best > >> >>> > > Telefoon: +31 (0) 499 33 69 79 > <tel:+31%20499%20336%20979> > >> >>> > <tel:+31%20499%20336%20979> > >> >>> > <tel:+31%20499%20336%20979> > >> >>> > > E-mail: [email protected] > <mailto:[email protected]> > >> >>> > <mailto:[email protected] > <mailto:[email protected]> > > >> >>> > > <mailto:[email protected] > <mailto:[email protected]> > >> >>> > <mailto:[email protected] > <mailto:[email protected]> > > > >> >>> > > Website: www.topicproducts.com > <http://www.topicproducts.com> > >> >>> > <http://www.topicproducts.com> > >> >>> > <http://www.topicproducts.com> > >> >>> > > > >> >>> > > Please consider the environment before printing > this > >> >>> > e-mail > >> >>> > > > >> >>> > > > >> >>> > > > >> >>> > > > _______________________________________________ > >> >>> > > > > meta-xilinx mailing list > >> >>> > > > > [email protected] > <mailto:meta- > [email protected]> <mailto:meta- <mailto:meta-> > >> >>> > [email protected] <mailto:[email protected]> > > <mailto:meta- <mailto:meta-> <mailto:meta- <mailto:meta-> > > >> >>> > > [email protected] > <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]> > > > >> >>> > <mailto:[email protected] <mailto:meta- > [email protected]> > >> >>> > <mailto:[email protected] <mailto:meta- > [email protected]> > > >> >>> > <mailto:meta- <mailto:meta-> <mailto:meta- <mailto:meta-> > > >> >>> > > [email protected] > <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]> > > > > >> >>> > > > > > >> >>> > https://lists.yoctoproject.org/listinfo/meta-xilinx > >> >>> > > > > > >> >>> > > > > >> >>> > > > > >> >>> > > > > >> >>> > > > >> >>> > > > >> >>> > > >> >>> > > >> >>> > >> > > >> > -- > >> > _______________________________________________ > >> > meta-xilinx mailing list > >> > [email protected] <mailto:[email protected]> > >> > https://lists.yoctoproject.org/listinfo/meta-xilinx > >> > > -- _______________________________________________ meta-xilinx mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-xilinx
