[meta-xilinx] Wrong DRAM set for custom board using FSBL + u-boot?
Manjukumar Harthikote Matha
MANJUKUM at xilinx.com
Tue Jan 2 14:30:09 PST 2018
Hi,
> -----Original Message-----
> From: Giordon Stark [mailto:kratsg at gmail.com]
> Sent: Tuesday, January 02, 2018 2:15 PM
> To: Nathan Rossi <nathan at nathanrossi.com>
> Cc: Manjukumar Harthikote Matha <MANJUKUM at xilinx.com>; 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,
>
> 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 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 <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 <nathan at nathanrossi.com
> <mailto:nathan at nathanrossi.com> > wrote:
>
>
> On 14 December 2017 at 00:53, Giordon Stark <kratsg at gmail.com
> <mailto:kratsg at gmail.com> > wrote:
> > Hi Nathan, replies inline.
> >
> > On Wed, Dec 13, 2017 at 8:33 AM Nathan Rossi
> <nathan at nathanrossi.com <mailto: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 <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 <kratsg at gmail.com
> <mailto: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
> <mailto: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 <mailto:MANJUKUM at xilinx.com> >
> wrote:
> >> >>>
> >> >>>
> >> >>>
> >> >>> > -----Original Message-----
> >> >>> > From: Giordon Stark [mailto:kratsg at gmail.com
> <mailto:kratsg at gmail.com> ]
> >> >>> > Sent: Friday, December 08, 2017 9:05 AM
> >> >>> > To: Manjukumar Harthikote Matha <MANJUKUM at xilinx.com
> <mailto:MANJUKUM at xilinx.com> >
> >> >>> > Cc: Mike Looijmans <mike.looijmans at topic.nl
> <mailto:mike.looijmans at topic.nl> >; 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 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>
> <mailto: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>
> > [mailto:meta-xilinx- <mailto:meta-xilinx->
> >> >>> > <mailto:meta-xilinx- <mailto:meta-xilinx-> >
> >> >>> > > bounces at yoctoproject.org
> <mailto:bounces at yoctoproject.org> <mailto: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>
> >> >>> > <mailto:mike.looijmans at topic.nl
> <mailto:mike.looijmans at topic.nl> > >
> >> >>> > > Cc: Tang, Shaochun <stang at bnl.gov
> <mailto:stang at bnl.gov> <mailto:stang at bnl.gov <mailto:stang at bnl.gov> > >;
> >> >>> > meta-
> >> >>> > xilinx at yoctoproject.org <mailto:xilinx at yoctoproject.org>
> <mailto: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> >
> >> >>> > > <mailto: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> >
> >> >>> > >
> >> >>> > > > <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
> <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> > >
> >> >>> > > > <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 <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> > >
> >> >>> > > > <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 <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> > >
> >> >>> > > > <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 <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
> <tel:+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> >
> >> >>> > > <mailto: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>
> >> >>> > <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- <mailto:meta-> <mailto:meta- <mailto:meta-> >
> >> >>> > > xilinx at yoctoproject.org <mailto:xilinx at yoctoproject.org>
> <mailto:xilinx at yoctoproject.org <mailto:xilinx at yoctoproject.org> > >
> >> >>> > <mailto:meta-xilinx at yoctoproject.org <mailto:meta-
> xilinx at yoctoproject.org>
> >> >>> > <mailto:meta-xilinx at yoctoproject.org <mailto:meta-
> xilinx at yoctoproject.org> >
> >> >>> > <mailto:meta- <mailto:meta-> <mailto:meta- <mailto:meta-> >
> >> >>> > > xilinx at yoctoproject.org <mailto:xilinx at yoctoproject.org>
> <mailto: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 <mailto:meta-xilinx at yoctoproject.org>
> >> > https://lists.yoctoproject.org/listinfo/meta-xilinx
> >> >
>
More information about the meta-xilinx
mailing list