Review reserved memory sections for samsung-milletwifi

[Susurrus]

I'm working on upstreaming my code changes, and there are some patches pending to upstream much beyond the initial boot. The memory sections that I copied from matisse-wifi were:

    reserved-memory {
        #address-cells = <1>;
        #size-cells = <1>;
        ranges;

        framebuffer@3200000 {
            reg = <0x03200000 0x800000>;
            no-map;
        };

        mpss_region: mpss@8400000 {
            reg = <0x08400000 0x1f00000>;
            no-map;
        };

        mba_region: mba@a300000 {
            reg = <0x0a300000 0x100000>;
            no-map;
        };

        reserved@cb00000 {
            reg = <0x0cb00000 0x700000>;
            no-map;
        };

        wcnss_region: wcnss@d200000 {
            reg = <0x0d200000 0x700000>;
            no-map;
        };

        adsp_region: adsp@d900000 {
            reg = <0x0d900000 0x1800000>;
            no-map;
        };

        venus@f100000 {
            reg = <0x0f100000 0x500000>;
            no-map;
        };

        smem_region: smem@fa00000 {
            reg = <0x0fa00000 0x100000>;
            no-map;
        };

        reserved@fb00000 {
            reg = <0x0fb00000 0x260000>;
            no-map;
        };

        rfsa@fd60000 {
            reg = <0x0fd60000 0x20000>;
            no-map;
        };

        rmtfs@fd80000 {
            compatible = "qcom,rmtfs-mem";
            reg = <0x0fd80000 0x180000>;
            no-map;

            qcom,client-id = <1>;
        };
    };

However, upstream doesn't have mba_region, mpss_region, or wcnss_region defined. So I'm trying to figure out how to approach this. I have a few options:

1. Just leave those names off and still declare that memory space reserved
2. Leave out the memory spaces entirely.

I would think Option 1 makes the most sense, what do folks think?

---

However, this got my reviewing the memory locations as I blindly copy/pasted them from matisse-wifi. I tried to get dmesg logs from a rooted LineageOS build, but there's so much noise in the kernel buffer, I didn't get the early stuff. I don't want to try to recompile a few kernel with a larger buffer. However, I think the DTS has most of what I need.

Here's a comparison of the reserved memory values I had above and relevant items I found in the downstream downstream DTS:

framebuffer@3200000 {reg = <0x03200000 0x800000>; no-map};

I'm thinking it should be slightly larger at 0xfa0000 in size based on:

            qcom,mdss_fb_primary {
                cell-index = <0x00>;
                compatible = "qcom,mdss-fb";
                qcom,memory-reservation-type = "EBI1";
                qcom,memory-reservation-size = <0x800000>;
                qcom,memblock-reserve = <0x3200000 0xfa0000>;
                linux,phandle = <0x1c>;
                phandle = <0x1c>;
            };

mpss_region: mpss@8400000 {reg = <0x08400000 0x1f00000>; no-map;};

From downstream DTS, there's the qcom,msm-mem-hole, which lists this same address, but 0x2000000 in size (so slightly larger):

        qcom,msm-mem-hole {
            compatible = "qcom,msm-mem-hole";
            qcom,memblock-remove = <0x8400000 0x2000000 0xcb00000 0x2b00000 0xfa00000 0x500000>;
        };

mba_region@a300000 {reg = <0x0a300000 0x100000>;no-map;};

I see no reference to this anywhere in the downstream DTS, so I don't know where this comes from...

reserved@cb00000 {reg = <0x0cb00000 0x700000>;no-map;};

This memory address was also in the qcom,msm-mem-hole node shown above, but much larger at 0x2b00000.

wcnss_region@d200000 {reg = <0x0d200000 0x700000>;no-map;};

Couldn't find anything with this memory address. However, given the naming, I'm confused what this is versus qcom,wcnss-wlan@fb000000 in downstream.

adsp_region: adsp@d900000 {reg = <0x0d900000 0x1800000>;no-map;};

I think this should have a size of 0x1d00000 based on:

            qcom,ion-heap@23 {
                compatible = "qcom,msm-ion-reserve";
                reg = <0x17>;
                qcom,heap-align = <0x1000>;
                qcom,memory-fixed = <0xd900000 0x1d00000>;
                qcom,ion-heap-type = "CARVEOUT";
            };

venus@f100000 {reg = <0x0f100000 0x500000>;no-map;};

Various addresses in the downstream DTS, but nothing that has this one or looks otherwise obviously applicable.

smem_region: smem@fa00000 {reg = <0x0fa00000 0x100000>;no-map;};

This memory address was also in the qcom,msm-mem-hole node shown above, but much larger at 0x500000.

reserved@fb00000 {reg = <0x0fb00000 0x260000>;no-map;};

Not certain what this is for. It's suspiciously close to qcom,wcnss-wlan@fb000000 (just off by a 0) in the downstream kernel, but that refers to wcnss, which has a separate memory reserved location above:

        qcom,wcnss-wlan@fb000000 {
            compatible = "qcom,wcnss_wlan";
            reg = <0xfb000000 0x280000 0xf9011008 0x04>;
            reg-names = "wcnss_mmio\0wcnss_fiq";
            interrupts = <0x00 0x91 0x00 0x00 0x92 0x00>;
            interrupt-names = "wcnss_wlantx_irq\0wcnss_wlanrx_irq";
            qcom,pronto-vddmx-supply = <0x42>;
            qcom,pronto-vddcx-supply = <0x43>;
            qcom,pronto-vddpx-supply = <0x3d>;
            qcom,iris-vddxo-supply = <0x35>;
            qcom,iris-vddrfa-supply = <0x44>;
            qcom,iris-vddpa-supply = <0x45>;
            qcom,iris-vdddig-supply = <0x44>;
            gpios = <0x09 0x28 0x00 0x09 0x29 0x00 0x09 0x2a 0x00 0x09 0x2b 0x00 0x09 0x2c 0x00>;
            qcom,has-pronto-hw;
            qcom,has-autodetect-xo;
            qcom,wcnss-adc_tm = <0x46>;
        };

rfsa@fd60000 {reg = <0x0fd60000 0x20000>;no-map;};

Looks correct based on the following:

        dsp_sharedmem {
            compatible = "qcom,sharedmem-uio";
            reg = <0xfd60000 0x20000>;
            reg-names = "rfsa_dsp";
        };

        mdm_sharedmem {
            compatible = "qcom,sharedmem-uio";
            reg = <0xfd60000 0x20000>;
            reg-names = "rfsa_mdm";
        };

rmtfs@fd80000 {compatible = "qcom,rmtfs-mem";reg = <0x0fd80000 0x180000>;no-map;qcom,client-id = <1>;};

Looks correct based on the following:

        rmtfs_sharedmem {
            compatible = "qcom,sharedmem-uio";
            reg = <0xfd80000 0x180000>;
            reg-names = "rmtfs";
        };

---

Now there's some other items of note:

A memory node that seems related to ion-heap:

    memory {
        #address-cells = <0x01>;
        #size-cells = <0x01>;
        device_type = "memory";
        reg = <0x00 0x00>;

        secure_region {
            linux,contiguous-region;
            reg = <0x00 0x6d00000>;
            label = "secure_mem";
            linux,phandle = <0x02>;
            phandle = <0x02>;
        };

        adsp_region {
            linux,contiguous-region;
            reg = <0x00 0x2a00000>;
            label = "adsp_mem";
            linux,phandle = <0x03>;
            phandle = <0x03>;
        };

        qsecom_region {
            linux,contiguous-region;
            reg = <0x00 0xd00000>;
            label = "qsecom_mem";
            linux,phandle = <0x04>;
            phandle = <0x04>;
        };
    };
...
            qcom,ion-heap@8 {
                compatible = "qcom,msm-ion-reserve";
                reg = <0x08>;
                qcom,heap-align = <0x1000>;
                linux,contiguous-region = <0x02>;
                qcom,ion-heap-type = "SECURE_DMA";
                qcom,default-prefetch-size = <0x3c00000>;
            };

            qcom,ion-heap@22 {
                compatible = "qcom,msm-ion-reserve";
                reg = <0x16>;
                qcom,heap-align = <0x1000>;
                linux,contiguous-region = <0x03>;
                qcom,ion-heap-type = "DMA";
            };

            qcom,ion-heap@27 {
                compatible = "qcom,msm-ion-reserve";
                reg = <0x1b>;
                linux,contiguous-region = <0x04>;
                qcom,ion-heap-type = "DMA";
            };

I don't know what this Ion thing is, but this slidedeck references it. But it's really this post that clarifies that it's an Android-specific shared memory system. Since it's Android specific, I think I can ignore it.

[z3ntu]

It really helps to get downstream dmesg, you can also get it from e.g. TWRP, there should be quite a bit less spam. Otherwise running this on your host should get dmesg as early as possible which normally contains the beginning of the kernel logs also: adb wait-for-device && adb shell su root dmesg. In that dmesg you should find the exact addresses that downstream uses, which is quite a bit more helpful than trying to read the downstream dtb.

I didn't read through everything in detail but in general you should also include mba_region and friends upstream, as they will be used in the future and you also never know what kind of special restrictions this area of memory might have (normally it shouldn't because the firmware is mostly relocatable but who knows)

[Susurrus]

Thanks, really helpful knowing about adb wait-for-device. I tried that and am only getting dmesg logs starting at 11.2s, way after all of the memory reserve part of the logs. The best I've gotten so far is to extract logs from the bootloader. They don't have anything from what I can see, but they do verify the info above that I've extracted from the DTB:

[Susurrus]

I also saw this commit, so I'm thinking I need to get better names for the two reserved sections. Is that right?

I've been thinking about this more as I don't really know what to do to resolve this It seems reasonable to use the values I have from the downstream DTS, so for the clear values I have listed there I don't know what more I'll learn from the dmesg logs. But I'm not an expert here, am I missing something?

I think there are two ways to get more info from a downstream kernel:

1. I recompile it with a larger kernel buffer
2. I write a little C program calling the kernel memory apis to see all listed reserved memory and run it on a rooted downstream kernel

1 seems pretty complicated, not certain how to do that with pmOS or LineageOS. Will take a while to figure out. 2 seems like the better option, tho it won't tell me names of things.

Anyone have any advice?

[z3ntu]

You can also check cat /proc/iomem on downstream , that should at least give you the ranges where memory is mapped, not sure if it gives you names also. Make sure to run as root, otherwise some info is missing.

But if it's completely unclear what a given reserved-memory section does, call it unknown or reserved or something I guess. Just don't call the nodes memory

[Susurrus]

Just ran stress-ng --vm 1 --vm-bytes 97% --vm-method all --verify -t 10 -v, which was recommended in a separate discussion about reserved memory and it didn't crash.

[Susurrus]

@z3ntu Thanks, that gave me something more to go on as I could get it from TWRP (see below). I'll see if I can get it off downstream as I think it'll be much more revealing.

# cat /proc/iomem
00000000-083fffff : System RAM
  00008000-009257fb : Kernel code
  00b0c000-0100eb63 : Kernel data
0a400000-0cafffff : System RAM
0f600000-0f9fffff : System RAM
0ff00000-5f2fffff : System RAM
f9017000-f9017fff : msm-watchdog
f9824900-f9824a1b : mmc0
f98a4900-f98a4a1b : mmc1
f9923000-f9923fff : f9923000.i2c
f9924000-f9924fff : f9924000.i2c
f9925000-f9925fff : f9925000.i2c
f9926000-f9926fff : f9926000.i2c
f9927000-f9927fff : f9927000.i2c
f9928000-f9928fff : f9928000.i2c
f9a55000-f9a553ff : /soc/usb@f9a55000
  f9a55000-f9a553ff : /soc/usb@f9a55000
fc380000-fc3e9fff : fc380000.msm-bimc
fc4281d0-fc4291cf : vmpm
fc460000-fc463fff : fc460000.msm-sys-noc
fc468000-fc46bfff : fc468000.msm-periph-noc
fc478000-fc47bfff : fc478000.msm-mmss-noc
fc480000-fc483fff : fc480000.msm-config-noc
fc4a8000-fc4a9fff : tsens_physical
fc4bc000-fc4bcfff : tsens_eeprom_physical
fdb00000-fdb0ffff : kgsl-3d0
fdb20000-fdb2ffff : kgsl-3d0
fdc80000-fdc803ff : vbif_base
fdce0000-fdce3fff : wrapper_base
fec00000-fec1ffff : fdd00000.qcom,ocmem

[Susurrus]

Discussed this off-bug, since the stress testing went fine, these values should be good enough to get things upstreamed. THey can be revised as needed later on.