>On Wed, May 29, 2024 at 10:10:29PM +0900, Jaewon Kim wrote: >>(Sorry I might forget to change to be plain text) >> >>Oh good thing, I did not know this patch. Thanks. >> >>By the way, I've tried to get memblock/memory and kernel log from a >>device based on >>v6.6.17 kernel device, to see upstream patches above. >>memblok/memory does not show region for > >memblock/memory only shows ranges put in "memory". >memblock/reserved shows ranges put in "reserved". > >If we just put them in "reserved", it will not displayed in "memory". > Hi Let me explain more. In this case, the intially passed memory starts from 0000000081960000 so memblock/memory shows as it is. # xxd -g 8 /proc/device-tree/memory/reg 00000000: 0000000081960000 00000000000a0000 ................ 00000010: 0000000081a40000 00000000001c0000 ................ # cat sys/kernel/debug/memblock/memory 0: 0x0000000081960000..0x00000000819fffff 0 NONE 1: 0x0000000081a40000..0x0000000081bfffff 0 NONE # cat sys/kernel/debug/memblock/reserved 0: 0x0000000082800000..0x00000000847fffff 0 NONE The memblock information in the kernel log may report like it allocated those memblock regions, as there was not overlapped even though it is already no-map. (I removed the name.) <6>[ 0.000000][ T0] OF: reserved mem: 0x0000000080000000..0x0000000080dfffff (14336 KiB) nomap non-reusable AAA <6>[ 0.000000][ T0] OF: reserved mem: 0x0000000080e00000..0x00000000811fffff (4096 KiB) nomap non-reusable BBB <6>[ 0.000000][ T0] OF: reserved mem: 0x0000000081200000..0x00000000813fffff (2048 KiB) nomap non-reusable CCC <6>[ 0.000000][ T0] OF: reserved mem: 0x0000000081a00000..0x0000000081a3ffff (256 KiB) nomap non-reusable DDD So a smart parser should combine the krenel log and the memblock/memory log. In my memsize feature shows it like this though. 0x0000000081400000-0x0000000081960000 0x00560000 ( 5504 KB ) nomap unusable unknown BR >>0x00000000_80000000..0x0x00000000_8195ffff. >> >> 0: 0x0000000081960000..0x00000000819fffff 0 NONE >> >>The kernel log shows information for 0x0000000080000000..0x00000000813fffff, but >>we don't see information for 0x0000000081400000..0x000000008195ffff >>from kernel log. >> >>(I removed the name.) >><6>[ 0.000000][ T0] OF: reserved mem: >>0x0000000080000000..0x0000000080dfffff (14336 KiB) nomap non-reusable >>AAA >><6>[ 0.000000][ T0] OF: reserved mem: >>0x0000000080e00000..0x00000000811fffff (4096 KiB) nomap non-reusable >>BBB >><6>[ 0.000000][ T0] OF: reserved mem: >>0x0000000081200000..0x00000000813fffff (2048 KiB) nomap non-reusable >>CCC >><6>[ 0.000000][ T0] OF: reserved mem: >>0x0000000081a00000..0x0000000081a3ffff (256 KiB) nomap non-reusable DD >> > >I guess those ranges are only put into "reserved"? Have those ranges put in >"memory"? Would you mind point the code where those messages are printed? > >>A smart parser should gather these kernel log and memblock/memory log >>and should show >>log like my memsize logic shows below. >>0x0000000081400000-0x0000000081960000 0x00560000 ( 5504 KB ) nomap >>unusable unknown >> >>Thank you >>Jaewon >> >>On Wed, May 29, 2024 at 8:35?PM Wei Yang <richard.weiyang@xxxxxxxxx> wrote: >>> >>> On Wed, May 29, 2024 at 06:51:19PM +0900, Jaewon Kim wrote: >>> ><!DOCTYPE html> >>> ><html> >>> ><head> >>> ... >>> >>> Would you mind sending it in pure text again? >>> >>> -- >>> Wei Yang >>> Help you, Help me > >-- >Wei Yang >Help you, Help me
