On Fri, May 31, 2024 at 05:21:41PM +0900, Jaewon Kim wrote: >>On Thu, May 30, 2024 at 07:49:28PM +0900, Jaewon Kim wrote: >>>>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 >>> >> >>This looks not printed by memblock_reserve(), right? It is printed by your own >>driver? > >AFAIK these log came from the commit below. >aeb9267eb6b1 of: reserved-mem: print out reserved-mem details during boot > >> >>>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 >>> >> >>I am sorry, I still not catch your point. Let me try to understand your message. >> >>You mentioned several regions, let me put them in order. >> >>(1) 0x0000000080000000..0x0000000080dfffff printed by driver >>(2) 0x0000000080e00000..0x00000000811fffff printed by driver >>(3) 0x0000000081200000..0x00000000813fffff printed by driver >>(4) 0x0000000081400000..0x0000000081960000 expected to print in new debugfs >>(5) 0x0000000081960000..0x00000000819fffff listed in reg/memory >>(6) 0x0000000081a00000..0x0000000081a3ffff printed by driver >>(7) 0x0000000081a40000..0x0000000081bfffff listed in reg/memory >>(8) 0x0000000082800000..0x00000000847fffff listed in reserved >> >>If you just want information for region (4), sound we can do it in user-space? >> >>BTW, are region 1, 2, 3, 6, reserved in membock? > >Yes correct, I though (4) case could be shown to easily catch these hidden regions. >As I said, I think 1, 2, 3, 6 seem to be not passed to kernel, it was just tried as >they are defined in kernel device tree. > As you mentioned above, 1, 2, 3, 6, is printed by "of" driver. And those information is not shown in memblock/reserve. I am afraid the proper way is to let memblock know those ranges. Sounds "of" driver doesn't tell memblock about these. > >> >>-- >>Wei Yang >>Help you, Help me -- Wei Yang Help you, Help me
