[meta-xilinx] Wrong DRAM set for custom board using FSBL + u-boot?
Giordon Stark
kratsg at gmail.com
Wed Dec 13 06:11:00 PST 2017
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
>> > > > >
>> > > >
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-xilinx/attachments/20171213/fa3c8e46/attachment.html>
More information about the meta-xilinx
mailing list