>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. > >-- >Wei Yang >Help you, Help me
