[meta-xilinx] Wrong DRAM set for custom board using FSBL + u-boot?
Manjukumar Harthikote Matha
MANJUKUM at xilinx.com
Fri Dec 8 09:39:26 PST 2017
> -----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 <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
> > > >
> > >
> > >
> > >
> >
> >
>
>
More information about the meta-xilinx
mailing list