[meta-xilinx] Wrong DRAM set for custom board using FSBL + u-boot?
Nathan Rossi
nathan at nathanrossi.com
Wed Dec 13 06:33:39 PST 2017
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.
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.
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.
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
>>> > <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
>
More information about the meta-xilinx
mailing list