Hi Manju,
On Tue, Jan 2, 2018 at 5:30 PM Manjukumar Harthikote Matha < manju...@xilinx.com> wrote: > Hi, > > > -----Original Message----- > > From: Giordon Stark [mailto:kra...@gmail.com] > > Sent: Tuesday, January 02, 2018 2:15 PM > > To: Nathan Rossi <nat...@nathanrossi.com> > > Cc: Manjukumar Harthikote Matha <manju...@xilinx.com>; Tang, Shaochun > > <st...@bnl.gov>; meta-xilinx@yoctoproject.org > > 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. > I've decided to go along with this method instead. I'd rather not change the source directory since that's probably less clear for people newer to this code moving forward... https://github.com/kratsg/meta-l1calo/commit/169090e527a5f350ff4d9649bcdbd136a97def2e *Slight question: how does it know to look under files/<MACHINE>/*.dts if I only append the "files/" or "boards/" as an extrafilespath?* Now when I run this, I found a few interesting things: - only works with windows-based line-endings (CLRF screws this up) - I get a complaint about the system.dts file ( https://github.com/kratsg/meta-l1calo/tree/master/recipes-bsp/device-tree/files/gfex-prototype3) which is interesting, but maybe expect. This is fine if I combine both of my dts files here -- but I should point out that this was automatically generated from Xilinx, so I wonder why there are two dts files. Giordon > > Thanks, > Manju > > > > Thanks! > > > > Giordon > > > > On Wed, Dec 13, 2017 at 10:22 AM Nathan Rossi <nat...@nathanrossi.com > > <mailto:nat...@nathanrossi.com> > wrote: > > > > > > On 14 December 2017 at 00:53, Giordon Stark <kra...@gmail.com > > <mailto:kra...@gmail.com> > wrote: > > > Hi Nathan, replies inline. > > > > > > On Wed, Dec 13, 2017 at 8:33 AM Nathan Rossi > > <nat...@nathanrossi.com <mailto:nat...@nathanrossi.com> > 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 <kra...@gmail.com > > <mailto:kra...@gmail.com> > wrote: > > >> > Hi all, > > >> > > > >> > Any ideas what else I can do? > > >> > > > >> > Giordon > > >> > > > >> > On Fri, Dec 8, 2017 at 11:47 AM Giordon Stark < > kra...@gmail.com > > <mailto:kra...@gmail.com> > 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 > > >> >> <manju...@xilinx.com <mailto:manju...@xilinx.com> > > > wrote: > > >> >>> > > >> >>> > > >> >>> > > >> >>> > -----Original Message----- > > >> >>> > From: Giordon Stark [mailto:kra...@gmail.com > > <mailto:kra...@gmail.com> ] > > >> >>> > Sent: Friday, December 08, 2017 9:05 AM > > >> >>> > To: Manjukumar Harthikote Matha <manju...@xilinx.com > > <mailto:manju...@xilinx.com> > > > >> >>> > Cc: Mike Looijmans <mike.looijm...@topic.nl > > <mailto:mike.looijm...@topic.nl> >; Tang, Shaochun > > >> >>> > <st...@bnl.gov <mailto:st...@bnl.gov> >; > > >> >>> > meta-xilinx@yoctoproject.org <mailto:meta- > > xil...@yoctoproject.org> > > >> >>> > 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 > > >> >>> > <manju...@xilinx.com <mailto:manju...@xilinx.com> > > <mailto:manju...@xilinx.com <mailto:manju...@xilinx.com> > > wrote: > > >> >>> > > > >> >>> > > > >> >>> > > > >> >>> > > > >> >>> > > -----Original Message----- > > >> >>> > > From: meta-xilinx-boun...@yoctoproject.org > <mailto:meta- > > xilinx-boun...@yoctoproject.org> > > >> >>> > <mailto:meta-xilinx- <mailto:meta-xilinx-> > > >> >>> > boun...@yoctoproject.org <mailto:boun...@yoctoproject.org > > > > > [mailto:meta-xilinx- <mailto:meta-xilinx-> > > >> >>> > <mailto:meta-xilinx- <mailto:meta-xilinx-> > > > >> >>> > > boun...@yoctoproject.org > > <mailto:boun...@yoctoproject.org> <mailto:boun...@yoctoproject.org > > <mailto:boun...@yoctoproject.org> > ] > > >> >>> > On > > >> >>> > Behalf Of Giordon Stark > > >> >>> > > Sent: Thursday, December 07, 2017 10:26 PM > > >> >>> > > To: Mike Looijmans <mike.looijm...@topic.nl > > <mailto:mike.looijm...@topic.nl> > > >> >>> > <mailto:mike.looijm...@topic.nl > > <mailto:mike.looijm...@topic.nl> > > > > >> >>> > > Cc: Tang, Shaochun <st...@bnl.gov > > <mailto:st...@bnl.gov> <mailto:st...@bnl.gov <mailto:st...@bnl.gov> > > >; > > >> >>> > meta- > > >> >>> > xil...@yoctoproject.org <mailto:xil...@yoctoproject.org> > > <mailto:meta-xilinx@yoctoproject.org <mailto: > meta-xilinx@yoctoproject.org> > > > >> >>> > > 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 > > >> >>> > <mike.looijm...@topic.nl <mailto:mike.looijm...@topic.nl> > > <mailto:mike.looijm...@topic.nl <mailto:mike.looijm...@topic.nl> > > > >> >>> > > <mailto:mike.looijm...@topic.nl > > <mailto:mike.looijm...@topic.nl> > > >> >>> > <mailto:mike.looijm...@topic.nl > > <mailto:mike.looijm...@topic.nl> > > > > > >> >>> > 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 > > >> >>> > <nat...@nathanrossi.com <mailto:nat...@nathanrossi.com> > > <mailto:nat...@nathanrossi.com <mailto:nat...@nathanrossi.com> > > > >> >>> > > <mailto:nat...@nathanrossi.com > > <mailto:nat...@nathanrossi.com> > > >> >>> > <mailto:nat...@nathanrossi.com > > <mailto:nat...@nathanrossi.com> > > > >> >>> > > > > >> >>> > > > <mailto:nat...@nathanrossi.com > > <mailto:nat...@nathanrossi.com> > > >> >>> > <mailto:nat...@nathanrossi.com > > <mailto:nat...@nathanrossi.com> > <mailto:nat...@nathanrossi.com > > <mailto:nat...@nathanrossi.com> > > >> >>> > <mailto:nat...@nathanrossi.com > > <mailto:nat...@nathanrossi.com> > > >> > > >> >>> > > wrote: > > >> >>> > > > > > >> >>> > > > On 7 December 2017 at 11:37, Giordon > Stark > > >> >>> > <kra...@gmail.com <mailto:kra...@gmail.com> > > >> >>> > <mailto:kra...@gmail.com <mailto:kra...@gmail.com> > > > >> >>> > > <mailto:kra...@gmail.com <mailto:kra...@gmail.com > > > > <mailto:kra...@gmail.com <mailto:kra...@gmail.com> > > > > >> >>> > > > <mailto:kra...@gmail.com > > <mailto:kra...@gmail.com> > > >> >>> > <mailto:kra...@gmail.com <mailto:kra...@gmail.com> > > > >> >>> > <mailto:kra...@gmail.com <mailto:kra...@gmail.com> > > <mailto:kra...@gmail.com <mailto:kra...@gmail.com> > > >> wrote: > > >> >>> > > > > Hi Alistair, > > >> >>> > > > > > > >> >>> > > > > > > >> >>> > > > > On Wed, Dec 6, 2017 at 7:23 PM > Alistair > > >> >>> > Francis > > >> >>> > > <alistai...@gmail.com <mailto: > alistai...@gmail.com> > > <mailto:alistai...@gmail.com <mailto:alistai...@gmail.com> > > > >> >>> > <mailto:alistai...@gmail.com <mailto:alistai...@gmail.com > > > > <mailto:alistai...@gmail.com <mailto:alistai...@gmail.com> > > > > >> >>> > > > <mailto:alistai...@gmail.com > > <mailto:alistai...@gmail.com> > > >> >>> > <mailto:alistai...@gmail.com <mailto:alistai...@gmail.com> > > > > >> >>> > <mailto:alistai...@gmail.com <mailto:alistai...@gmail.com > > > > <mailto:alistai...@gmail.com <mailto:alistai...@gmail.com> > > >> > > >> >>> > > > > wrote: > > >> >>> > > > >> > > >> >>> > > > >> On Wed, Dec 6, 2017 at 4:45 PM, > Giordon > > >> >>> > Stark > > >> >>> > <kra...@gmail.com <mailto:kra...@gmail.com> > > <mailto:kra...@gmail.com <mailto:kra...@gmail.com> > > > >> >>> > > <mailto:kra...@gmail.com <mailto:kra...@gmail.com > > > > <mailto:kra...@gmail.com <mailto:kra...@gmail.com> > > > > >> >>> > > > <mailto:kra...@gmail.com > > <mailto:kra...@gmail.com> > > >> >>> > <mailto:kra...@gmail.com <mailto:kra...@gmail.com> > > > >> >>> > <mailto:kra...@gmail.com <mailto:kra...@gmail.com> > > <mailto:kra...@gmail.com <mailto:kra...@gmail.com> > > >> 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 > <+31%20499%20336%20979> > > <tel:+31%20499%20336%20979> > > >> >>> > <tel:+31%20499%20336%20979> > > >> >>> > <tel:+31%20499%20336%20979> > > >> >>> > > E-mail: mike.looijm...@topicproducts.com > > <mailto:mike.looijm...@topicproducts.com> > > >> >>> > <mailto:mike.looijm...@topicproducts.com > > <mailto:mike.looijm...@topicproducts.com> > > > >> >>> > > <mailto:mike.looijm...@topicproducts.com > > <mailto:mike.looijm...@topicproducts.com> > > >> >>> > <mailto:mike.looijm...@topicproducts.com > > <mailto:mike.looijm...@topicproducts.com> > > > > >> >>> > > 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 > > >> >>> > > > > meta-xilinx@yoctoproject.org > <mailto:meta- > > xil...@yoctoproject.org> <mailto:meta- <mailto:meta-> > > >> >>> > xil...@yoctoproject.org <mailto:xil...@yoctoproject.org> > > > > <mailto:meta- <mailto:meta-> <mailto:meta- <mailto:meta-> > > > >> >>> > > xil...@yoctoproject.org <mailto: > xil...@yoctoproject.org> > > <mailto:xil...@yoctoproject.org <mailto:xil...@yoctoproject.org> > > > > >> >>> > <mailto:meta-xilinx@yoctoproject.org <mailto:meta- > > xil...@yoctoproject.org> > > >> >>> > <mailto:meta-xilinx@yoctoproject.org <mailto:meta- > > xil...@yoctoproject.org> > > > >> >>> > <mailto:meta- <mailto:meta-> <mailto:meta- <mailto:meta-> > > > > >> >>> > > xil...@yoctoproject.org <mailto: > xil...@yoctoproject.org> > > <mailto:xil...@yoctoproject.org <mailto:xil...@yoctoproject.org> > > > > > >> >>> > > > > > > >> >>> > https://lists.yoctoproject.org/listinfo/meta-xilinx > > >> >>> > > > > > > >> >>> > > > > > >> >>> > > > > > >> >>> > > > > > >> >>> > > > > >> >>> > > > > >> >>> > > > >> >>> > > > >> >>> > > >> > > > >> > -- > > >> > _______________________________________________ > > >> > meta-xilinx mailing list > > >> > meta-xilinx@yoctoproject.org <mailto: > meta-xilinx@yoctoproject.org> > > >> > https://lists.yoctoproject.org/listinfo/meta-xilinx > > >> > > > > >
-- _______________________________________________ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
