>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. > Yes that is the reason why I added some code to 'of' driver, too. As I said, if we don't change 'of' driver and memblck, we need a smart parser looking into kernel log and memblock info, and understand these special cases. BR >> >>> >>>-- >>>Wei Yang >>>Help you, Help me >
