[meta-xilinx] Wrong DRAM set for custom board using FSBL + u-boot?

Mike Looijmans mike.looijmans at topic.nl
Thu Dec 7 22:08:11 PST 2017


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>> wrote:
> 
>     On 7 December 2017 at 11:37, Giordon Stark <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>>
>      > wrote:
>      >>
>      >> On Wed, Dec 6, 2017 at 4:45 PM, Giordon Stark <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
E-mail: mike.looijmans at topicproducts.com
Website: 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>
>      > https://lists.yoctoproject.org/listinfo/meta-xilinx
>      >
> 
> 
> 




More information about the meta-xilinx mailing list