4G RAM on C100P

[andre]

I have been taking a look at the device trees, and there is a reference to memory after all, if you follow the includes:
https://github.com/torvalds/linux/blob/ ... eyron.dtsi

$this->bbcode_second_pass_code('', 'memory@0 {
device_type = "memory";
reg = <0x0 0x80000000>;
};')


0x80000000 = 2147483648 bytes = 2 GiB

So the memory size is limited by the device tree.

[yaroze]

Cool, great find.

So can we override this setting or does it need to be fixed up stream.

[WarheadsSE]

Because this is in the DTSI, you'd need to override it on the specific platform DTS, IIRC

[yaroze]

Is there a example of how to make a overlay on the rockchip flip?

I am reading as much as I can and am finding it pretty complicated and seeming different depending on the hardware.

I cant seem to find anything specifically for this rockchip chromebook.

I did find that Andre is correct, if I look at the value in the memory setting 'reg' in both /sys/firmware/devicetree/base/memory@0/ and /proc/device-tree/memory@0 are both 2048

hexdump -C '../base/memory@0/reg'
00000000 00 00 00 00 80 00 00 00

I am confused on what I have to do now to change this. I think I have create a file with the correct setting ie

memory@0 {
device_type = "memory";
reg = <0x0 0xFDF00000>;
};

then do I have to compile it with dtc or just put it a folder called overlays in boot?

Any help greatly appreciated!

[yaroze]

So far I have this I dont know if the target is corrrect as the one in the blob is called memory@0. But dts will not compile with that name.

And memory in the original blob looks like this I dont know what the last 2 addresses are for?

memory {
reg = <0x0 0x80000000 0x80000000 0x7efeb000>;
};




But it does compile, it moans but what do I do with this dtb file now? Where do I put it?



/dts-v1/;


/plugin/;

/ {

compatible = "google,veyron-minnie-rev4", "google,veyron-minnie-rev3", "google,veyron-minnie-rev2", "google,veyron-minnie-rev1", "google,veyron-minnie-rev0", "google,veyron-minnie", "google,veyron", "rockchip,rk3288";
model = "Google Minnie";

fragment@0 {
target = <&memory>;
__overlay__ {
reg = <0x0 0xFDF00000>;
};
};
};

becomes
<stdout>: Warning (reg_format): "reg" property in /fragment@0/__overlay__ has invalid length (8 bytes) (#address-cells == 2, #size-cells == 1)
<stdout>: Warning (unit_address_vs_reg): Node /fragment@0 has a unit name, but no reg property
<stdout>: Warning (unit_address_vs_reg): Node /fragment@0/__overlay__ has a reg or ranges property, but no unit name
<stdout>: Warning (avoid_default_addr_size): Relying on default #address-cells value for /fragment@0/__overlay__
<stdout>: Warning (avoid_default_addr_size): Relying on default #size-cells value for /fragment@0/__overlay__
/dts-v1/;

/ {
compatible = "google,veyron-minnie-rev4", "google,veyron-minnie-rev3", "google,veyron-minnie-rev2", "google,veyron-minnie-rev1", "google,veyron-minnie-rev0", "google,veyron-minnie", "google,veyron", "rockchip,rk3288";
model = "Google Minnie";

fragment@0 {
target = <0xffffffff>;

__overlay__ {
reg = <0x0 0xfdf00000>;
};
};

__fixups__ {
memory = "/fragment@0:target:0";
};
};

Feel free to advise - my head hurts!

[summers]

I'd have guess the ting to change the device tree too would be:

memory@0 {
device_type = "memory";
reg = <0x0 0x100000000>;
};

Probably in a dvice specific .dts file that includes rk3288-veyron.dtsi

Yes the device tree compiler, is I think distributed with tyhe linux kernel, so just look in the directory arch/arm/boot

Once compiled into a blob, it goes somewhere where in can be loaded at boot time. So with uboot its in /boot/dtbs/ - and you'll need to check the boot loader loads it (in uboot there is some code for which device tree is chosen). So you'll need to check what the chrome book booter needs ...

[yaroze]

Yes I thought I could just take the specific .dtb file and use dtc to convert it to a .dts file make the change, compile it to dtb and copy it back I tried that but it didnt make any difference.

I need to make sure I am using the correct one, I changed the rk3288-veyron-minnie.dtb.

I did read that converting a dtb back to a dts was not reliable and it was best to compile from the source dts files, so do you know where I can get the dts files from?

I want to use the overlay I made but I dont know how to load it into the kernel i read there is a kernel api but I have no idea where to start with that:-)

[yaroze]

I tired changing the defualt vetron-minnie again and copied it back to /boot/dtbs but it wont pick up the change I dumped the contents and the memory value is different to the original value.

Is there a cache I need to clear or is there a way to know exactly what .dtb file is being used at boot?

[summers]

So you need to find how the dtb is passed to the kernel during boot. My uboot has env set up:
$this->bbcode_second_pass_code('', 'fdtdir=/boot/dtbs
fdtfile=kirkwood-nsa325.dtb')
Then the rest of the code arround it loads it into a bit of memory, and that memory location is passed to the kernel on booting.

So in my case you can see how a particular file is accessed. Chromebooks have different booking, IIRC usually coreboot. So you'll need to read up on how that boots the kernel, see if it can pass kernel options, or at least find out which dtb the kernel loads, and where it is located.

I think dts to dtb is reversable, but I usually read the dts, as its more readable. As I said above you can find the device trees in the lionux kernel source, so you'll have to download a src then go into arch/arm/boot.

[yaroze]

I went back into chrome to have a look for a bootloader and ran the current devicetree out and strangely it says the same 2gig values for the memory

memory {
reg = <0x0 0x80000000 0x80000000 0x7efeb000>;
device_type = "memory";
};

but it has 4 gig available

total used free shared buffers cached
Mem: 4015 1544 2470 8 195 421
-/+ buffers/cache: 926 3088
Swap: 3921 0 3921

I guess there is more going on to this than meets the eye and I dont have much more time to spare on fixing it, maybe somebody who develops these images can throw me rope?

Otherwise I have to choose whether to have a smooth running system but with only 2gigs of Ram or a old kernel and dodgy video drivers?

I only need ssh and vscode maybe Ill look into running crouton again with ubutu but that is probably pants right?