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 <[email protected]> wrote: > Hi all, > > Any ideas what else I can do? > > Giordon > > On Fri, Dec 8, 2017 at 11:47 AM Giordon Stark <[email protected]> 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@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 >> <[email protected]> wrote: >>> >>> >>> >>> > -----Original Message----- >>> > From: Giordon Stark [mailto:[email protected]] >>> > Sent: Friday, December 08, 2017 9:05 AM >>> > To: Manjukumar Harthikote Matha <[email protected]> >>> > Cc: Mike Looijmans <[email protected]>; Tang, Shaochun >>> > <[email protected]>; >>> > [email protected] >>> > 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 >>> > <[email protected] <mailto:[email protected]> > wrote: >>> > >>> > >>> > >>> > >>> > > -----Original Message----- >>> > > From: [email protected] <mailto:meta-xilinx- >>> > [email protected]> [mailto:meta-xilinx- <mailto:meta-xilinx-> >>> > > [email protected] <mailto:[email protected]> ] On >>> > Behalf Of Giordon Stark >>> > > Sent: Thursday, December 07, 2017 10:26 PM >>> > > To: Mike Looijmans <[email protected] >>> > <mailto:[email protected]> > >>> > > Cc: Tang, Shaochun <[email protected] <mailto:[email protected]> >; >>> > meta- >>> > [email protected] <mailto:[email protected]> >>> > > 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 >>> > <[email protected] <mailto:[email protected]> >>> > > <mailto:[email protected] >>> > <mailto:[email protected]> > > >>> > 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 >>> > <[email protected] <mailto:[email protected]> >>> > > <mailto:[email protected] <mailto:[email protected]> >>> > > >>> > > > <mailto:[email protected] >>> > <mailto:[email protected]> <mailto:[email protected] >>> > <mailto:[email protected]> > >> >>> > > wrote: >>> > > > >>> > > > On 7 December 2017 at 11:37, Giordon Stark >>> > <[email protected] >>> > <mailto:[email protected]> >>> > > <mailto:[email protected] <mailto:[email protected]> > >>> > > > <mailto:[email protected] <mailto:[email protected]> >>> > <mailto:[email protected] <mailto:[email protected]> > >> wrote: >>> > > > > Hi Alistair, >>> > > > > >>> > > > > >>> > > > > On Wed, Dec 6, 2017 at 7:23 PM Alistair Francis >>> > > <[email protected] <mailto:[email protected]> >>> > <mailto:[email protected] <mailto:[email protected]> > >>> > > > <mailto:[email protected] >>> > <mailto:[email protected]> >>> > <mailto:[email protected] <mailto:[email protected]> > >> >>> > > > > wrote: >>> > > > >> >>> > > > >> On Wed, Dec 6, 2017 at 4:45 PM, Giordon Stark >>> > <[email protected] <mailto:[email protected]> >>> > > <mailto:[email protected] <mailto:[email protected]> > >>> > > > <mailto:[email protected] <mailto:[email protected]> >>> > <mailto:[email protected] <mailto:[email protected]> > >> 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: [email protected] >>> > <mailto:[email protected]> >>> > > <mailto:[email protected] >>> > <mailto:[email protected]> > >>> > > 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 >>> > > > > [email protected] <mailto:meta- >>> > [email protected]> <mailto:meta- <mailto:meta-> >>> > > [email protected] <mailto:[email protected]> > >>> > <mailto:[email protected] >>> > <mailto:[email protected]> >>> > <mailto:meta- <mailto:meta-> >>> > > [email protected] <mailto:[email protected]> > > >>> > > > > >>> > https://lists.yoctoproject.org/listinfo/meta-xilinx >>> > > > > >>> > > > >>> > > > >>> > > > >>> > > >>> > > >>> > >>> > >>> > > -- > _______________________________________________ > meta-xilinx mailing list > [email protected] > https://lists.yoctoproject.org/listinfo/meta-xilinx > -- _______________________________________________ meta-xilinx mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-xilinx
