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> wrote:

>
>
> > -----Original Message-----
> > From: Giordon Stark [mailto:kra...@gmail.com]
> > Sent: Friday, December 08, 2017 9:05 AM
> > To: Manjukumar Harthikote Matha <manju...@xilinx.com>
> > Cc: Mike Looijmans <mike.looijm...@topic.nl>; Tang, Shaochun <
> st...@bnl.gov>;
> > meta-xilinx@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> > 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> ] 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> >
> >       > Cc: Tang, Shaochun <st...@bnl.gov <mailto:st...@bnl.gov> >;
> meta-
> > xil...@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>
> > >
> > 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> > >>
> >       > 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> > >> 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> > >>
> >       >       >      > 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> > >> 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.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>
> >       >
> >       >       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-xilinx@yoctoproject.org <mailto:
> meta-xilinx@yoctoproject.org>
> > <mailto:meta- <mailto:meta->
> >       > xil...@yoctoproject.org <mailto:xil...@yoctoproject.org> > >
> >       >       >      >
> https://lists.yoctoproject.org/listinfo/meta-xilinx
> >       >       >      >
> >       >       >
> >       >       >
> >       >       >
> >       >
> >       >
> >
> >
>
>
-- 
_______________________________________________
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Reply via email to