[meta-xilinx] Wrong DRAM set for custom board using FSBL + u-boot?
Giordon Stark
kratsg at gmail.com
Wed Dec 13 06:53:27 PST 2017
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.
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?
>
> 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.
Thanks! None of this seems obvious for people new to yocto (or meta-xilinx)
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/20171213/0bec2b81/attachment.html>
More information about the meta-xilinx
mailing list