> -----Original Message-----
> From: [email protected] [mailto:meta-xilinx-
> [email protected]] On Behalf Of Giordon Stark
> Sent: Thursday, December 07, 2017 10:26 PM
> To: Mike Looijmans <[email protected]>
> Cc: Tang, Shaochun <[email protected]>; [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]> > 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]> >>
> wrote:
>       >
>       >     On 7 December 2017 at 11:37, Giordon Stark <[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]> >>
>       >      > wrote:
>       >      >>
>       >      >> On Wed, Dec 6, 2017 at 4:45 PM, Giordon Stark 
> <[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>
>       E-mail: [email protected]
> <mailto:[email protected]>
>       Website: 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:[email protected] <mailto:meta-
> [email protected]> >
>       >      > https://lists.yoctoproject.org/listinfo/meta-xilinx
>       >      >
>       >
>       >
>       >
> 
> 

-- 
_______________________________________________
meta-xilinx mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/meta-xilinx

Reply via email to