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]>> wrote:
On 7 December 2017 at 11:37, Giordon Stark <[email protected]
<mailto:[email protected]>> wrote:
> Hi Alistair,
>
>
> On Wed, Dec 6, 2017 at 7:23 PM Alistair Francis <[email protected]
<mailto:[email protected]>>
> wrote:
>>
>> On Wed, Dec 6, 2017 at 4:45 PM, Giordon Stark <[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
E-mail: [email protected]
Website: www.topicproducts.com
Please consider the environment before printing this e-mail
_______________________________________________
> meta-xilinx mailing list
> [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
