Hi Nathan, replies inline. On Wed, Dec 13, 2017 at 8:33 AM Nathan Rossi <[email protected]> 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 <[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 <+31%20499%20336%20979> > >>> > <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
