[meta-xilinx] Wrong DRAM set for custom board using FSBL + u-boot?
Giordon Stark
kratsg at gmail.com
Tue Jan 2 14:14:58 PST 2018
Hi,
I've followed along with everything so far. I'm finding that 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 at 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 happy. Am I doing this
wrong? Is my structure wrong or is 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.
Thanks!
Giordon
On Wed, Dec 13, 2017 at 10:22 AM Nathan Rossi <nathan at nathanrossi.com>
wrote:
> On 14 December 2017 at 00:53, Giordon Stark <kratsg at gmail.com> wrote:
> > Hi Nathan, replies inline.
> >
> > On Wed, Dec 13, 2017 at 8:33 AM Nathan Rossi <nathan at 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 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:
> >
> 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.
> >
> >
> > It looks like, if I somehow get the 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 <kratsg at gmail.com> wrote:
> >> > Hi all,
> >> >
> >> > Any ideas what else I can do?
> >> >
> >> > Giordon
> >> >
> >> > On Fri, Dec 8, 2017 at 11:47 AM Giordon Stark <kratsg at 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 at 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
> >> >> <MANJUKUM at xilinx.com> wrote:
> >> >>>
> >> >>>
> >> >>>
> >> >>> > -----Original Message-----
> >> >>> > From: Giordon Stark [mailto:kratsg at gmail.com]
> >> >>> > Sent: Friday, December 08, 2017 9:05 AM
> >> >>> > To: Manjukumar Harthikote Matha <MANJUKUM at xilinx.com>
> >> >>> > Cc: Mike Looijmans <mike.looijmans at topic.nl>; Tang, Shaochun
> >> >>> > <stang at bnl.gov>;
> >> >>> > meta-xilinx at 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
> >> >>> > <MANJUKUM at xilinx.com <mailto:MANJUKUM at xilinx.com> > wrote:
> >> >>> >
> >> >>> >
> >> >>> >
> >> >>> >
> >> >>> > > -----Original Message-----
> >> >>> > > From: meta-xilinx-bounces at yoctoproject.org
> >> >>> > <mailto:meta-xilinx-
> >> >>> > bounces at yoctoproject.org> [mailto:meta-xilinx-
> >> >>> > <mailto:meta-xilinx->
> >> >>> > > bounces at yoctoproject.org <mailto:bounces at yoctoproject.org>
> ]
> >> >>> > On
> >> >>> > Behalf Of Giordon Stark
> >> >>> > > Sent: Thursday, December 07, 2017 10:26 PM
> >> >>> > > To: Mike Looijmans <mike.looijmans at topic.nl
> >> >>> > <mailto:mike.looijmans at topic.nl> >
> >> >>> > > Cc: Tang, Shaochun <stang at bnl.gov <mailto:stang at bnl.gov>
> >;
> >> >>> > meta-
> >> >>> > xilinx at yoctoproject.org <mailto:meta-xilinx at 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.looijmans at topic.nl <mailto:mike.looijmans at topic.nl>
> >> >>> > > <mailto:mike.looijmans at topic.nl
> >> >>> > <mailto:mike.looijmans at 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
> >> >>> > <nathan at nathanrossi.com <mailto:nathan at nathanrossi.com>
> >> >>> > > <mailto:nathan at nathanrossi.com
> >> >>> > <mailto:nathan at nathanrossi.com>
> >> >>> > >
> >> >>> > > > <mailto:nathan at nathanrossi.com
> >> >>> > <mailto:nathan at nathanrossi.com> <mailto:nathan at nathanrossi.com
> >> >>> > <mailto:nathan at nathanrossi.com> > >>
> >> >>> > > wrote:
> >> >>> > > >
> >> >>> > > > On 7 December 2017 at 11:37, Giordon Stark
> >> >>> > <kratsg at gmail.com
> >> >>> > <mailto:kratsg at gmail.com>
> >> >>> > > <mailto:kratsg at gmail.com <mailto:kratsg at gmail.com> >
> >> >>> > > > <mailto:kratsg at gmail.com
> >> >>> > <mailto:kratsg at gmail.com>
> >> >>> > <mailto:kratsg at gmail.com <mailto:kratsg at gmail.com> > >> wrote:
> >> >>> > > > > Hi Alistair,
> >> >>> > > > >
> >> >>> > > > >
> >> >>> > > > > On Wed, Dec 6, 2017 at 7:23 PM Alistair
> >> >>> > Francis
> >> >>> > > <alistair23 at gmail.com <mailto:alistair23 at gmail.com>
> >> >>> > <mailto:alistair23 at gmail.com <mailto:alistair23 at gmail.com> >
> >> >>> > > > <mailto:alistair23 at gmail.com
> >> >>> > <mailto:alistair23 at gmail.com>
> >> >>> > <mailto:alistair23 at gmail.com <mailto:alistair23 at gmail.com> > >>
> >> >>> > > > > wrote:
> >> >>> > > > >>
> >> >>> > > > >> On Wed, Dec 6, 2017 at 4:45 PM, Giordon
> >> >>> > Stark
> >> >>> > <kratsg at gmail.com <mailto:kratsg at gmail.com>
> >> >>> > > <mailto:kratsg at gmail.com <mailto:kratsg at gmail.com> >
> >> >>> > > > <mailto:kratsg at gmail.com
> >> >>> > <mailto:kratsg at gmail.com>
> >> >>> > <mailto:kratsg at gmail.com <mailto:kratsg at 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>
> >> >>> > > E-mail: mike.looijmans at topicproducts.com
> >> >>> > <mailto:mike.looijmans at topicproducts.com>
> >> >>> > > <mailto:mike.looijmans at topicproducts.com
> >> >>> > <mailto:mike.looijmans at topicproducts.com> >
> >> >>> > > Website: 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 at yoctoproject.org <mailto:meta-
> >> >>> > xilinx at yoctoproject.org> <mailto:meta- <mailto:meta->
> >> >>> > > xilinx at yoctoproject.org <mailto:xilinx at yoctoproject.org>
> >
> >> >>> > <mailto:meta-xilinx at yoctoproject.org
> >> >>> > <mailto:meta-xilinx at yoctoproject.org>
> >> >>> > <mailto:meta- <mailto:meta->
> >> >>> > > xilinx at yoctoproject.org <mailto:xilinx at yoctoproject.org>
> > >
> >> >>> > > > >
> >> >>> > https://lists.yoctoproject.org/listinfo/meta-xilinx
> >> >>> > > > >
> >> >>> > > >
> >> >>> > > >
> >> >>> > > >
> >> >>> > >
> >> >>> > >
> >> >>> >
> >> >>> >
> >> >>>
> >> >
> >> > --
> >> > _______________________________________________
> >> > meta-xilinx mailing list
> >> > meta-xilinx at yoctoproject.org
> >> > https://lists.yoctoproject.org/listinfo/meta-xilinx
> >> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-xilinx/attachments/20180102/65225638/attachment-0001.html>
More information about the meta-xilinx
mailing list