On 14 December 2017 at 00:53, Giordon Stark <kra...@gmail.com> wrote: > Hi Nathan, replies inline. > > On Wed, Dec 13, 2017 at 8:33 AM Nathan Rossi <nat...@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.
For the zc706 the device tree was changed to use the kernel as the source of the dtb. This is where KERNEL_DEVICETREE comes in, its the name of the make target/dts to build the device tree in the kernel. The more important change relevant to your use case was this one: https://github.com/Xilinx/meta-xilinx/commit/e448d3c1de3ce284ef42a591fd89cf4c2b6a81cf > > 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? As for using the device-tree recipe, you should supply your device tree files via SRC_URI with a bbappend. See the bbappend in the meta-xilinx layer for an example of how to set that up. https://github.com/Xilinx/meta-xilinx/blob/master/recipes-bsp/device-tree/device-tree.bbappend And their sources: https://github.com/Xilinx/meta-xilinx/tree/master/recipes-bsp/device-tree/files Your layer would append to the recipe and add your device tree sources that are located in your layer. > >> >> >> 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. Yes that would be the append you want. u-boot/u-boot-xlnx are basically the same from a build perspective. I had only pointed at the u-boot bbappend for an example of the content for how to setup the recipe, I did not have an example that uses u-boot-xlnx :). > > Thanks! None of this seems obvious for people new to yocto (or meta-xilinx) Unfortunately there are many ways to deal with setting up BSPs, and U-Boot has only more recently become more easy to setup with just DTBs and defconfig (previously it required source patching to support BSPs). So documenting or providing recipes for this in OE/Yocto has not really matured. But you are welcome to contribute documentation/etc. based on your experiences to meta-xilinx, OE or Yocto :). Regards, Nathan > btw. > >> >> >> Regards, >> Nathan >> >> On 14 December 2017 at 00:11, Giordon Stark <kra...@gmail.com> wrote: >> > Hi all, >> > >> > Any ideas what else I can do? >> > >> > Giordon >> > >> > On Fri, Dec 8, 2017 at 11:47 AM Giordon Stark <kra...@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@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 >> >> <manju...@xilinx.com> wrote: >> >>> >> >>> >> >>> >> >>> > -----Original Message----- >> >>> > From: Giordon Stark [mailto:kra...@gmail.com] >> >>> > Sent: Friday, December 08, 2017 9:05 AM >> >>> > To: Manjukumar Harthikote Matha <manju...@xilinx.com> >> >>> > Cc: Mike Looijmans <mike.looijm...@topic.nl>; Tang, Shaochun >> >>> > <st...@bnl.gov>; >> >>> > meta-xilinx@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 >> >>> > <manju...@xilinx.com <mailto:manju...@xilinx.com> > wrote: >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > > -----Original Message----- >> >>> > > From: meta-xilinx-boun...@yoctoproject.org >> >>> > <mailto:meta-xilinx- >> >>> > boun...@yoctoproject.org> [mailto:meta-xilinx- >> >>> > <mailto:meta-xilinx-> >> >>> > > boun...@yoctoproject.org <mailto:boun...@yoctoproject.org> ] >> >>> > On >> >>> > Behalf Of Giordon Stark >> >>> > > Sent: Thursday, December 07, 2017 10:26 PM >> >>> > > To: Mike Looijmans <mike.looijm...@topic.nl >> >>> > <mailto:mike.looijm...@topic.nl> > >> >>> > > Cc: Tang, Shaochun <st...@bnl.gov <mailto:st...@bnl.gov> >; >> >>> > meta- >> >>> > xil...@yoctoproject.org <mailto:meta-xilinx@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.looijm...@topic.nl <mailto:mike.looijm...@topic.nl> >> >>> > > <mailto:mike.looijm...@topic.nl >> >>> > <mailto:mike.looijm...@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 >> >>> > <nat...@nathanrossi.com <mailto:nat...@nathanrossi.com> >> >>> > > <mailto:nat...@nathanrossi.com >> >>> > <mailto:nat...@nathanrossi.com> >> >>> > > >> >>> > > > <mailto:nat...@nathanrossi.com >> >>> > <mailto:nat...@nathanrossi.com> <mailto:nat...@nathanrossi.com >> >>> > <mailto:nat...@nathanrossi.com> > >> >> >>> > > wrote: >> >>> > > > >> >>> > > > On 7 December 2017 at 11:37, Giordon Stark >> >>> > <kra...@gmail.com >> >>> > <mailto:kra...@gmail.com> >> >>> > > <mailto:kra...@gmail.com <mailto:kra...@gmail.com> > >> >>> > > > <mailto:kra...@gmail.com >> >>> > <mailto:kra...@gmail.com> >> >>> > <mailto:kra...@gmail.com <mailto:kra...@gmail.com> > >> wrote: >> >>> > > > > Hi Alistair, >> >>> > > > > >> >>> > > > > >> >>> > > > > On Wed, Dec 6, 2017 at 7:23 PM Alistair >> >>> > Francis >> >>> > > <alistai...@gmail.com <mailto:alistai...@gmail.com> >> >>> > <mailto:alistai...@gmail.com <mailto:alistai...@gmail.com> > >> >>> > > > <mailto:alistai...@gmail.com >> >>> > <mailto:alistai...@gmail.com> >> >>> > <mailto:alistai...@gmail.com <mailto:alistai...@gmail.com> > >> >> >>> > > > > wrote: >> >>> > > > >> >> >>> > > > >> On Wed, Dec 6, 2017 at 4:45 PM, Giordon >> >>> > Stark >> >>> > <kra...@gmail.com <mailto:kra...@gmail.com> >> >>> > > <mailto:kra...@gmail.com <mailto:kra...@gmail.com> > >> >>> > > > <mailto:kra...@gmail.com >> >>> > <mailto:kra...@gmail.com> >> >>> > <mailto:kra...@gmail.com <mailto:kra...@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.looijm...@topicproducts.com >> >>> > <mailto:mike.looijm...@topicproducts.com> >> >>> > > <mailto:mike.looijm...@topicproducts.com >> >>> > <mailto:mike.looijm...@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@yoctoproject.org <mailto:meta- >> >>> > xil...@yoctoproject.org> <mailto:meta- <mailto:meta-> >> >>> > > xil...@yoctoproject.org <mailto:xil...@yoctoproject.org> > >> >>> > <mailto:meta-xilinx@yoctoproject.org >> >>> > <mailto:meta-xilinx@yoctoproject.org> >> >>> > <mailto:meta- <mailto:meta-> >> >>> > > xil...@yoctoproject.org <mailto:xil...@yoctoproject.org> > > >> >>> > > > > >> >>> > https://lists.yoctoproject.org/listinfo/meta-xilinx >> >>> > > > > >> >>> > > > >> >>> > > > >> >>> > > > >> >>> > > >> >>> > > >> >>> > >> >>> > >> >>> >> > >> > -- >> > _______________________________________________ >> > meta-xilinx mailing list >> > meta-xilinx@yoctoproject.org >> > https://lists.yoctoproject.org/listinfo/meta-xilinx >> > -- _______________________________________________ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
