Help with exporting memory power management info in u-boot
Hi,
Memory hardware today offers capabilities for managing power consumption, like multiple lower power statest. Few SoCs, like the TI Panda board, offers support for Partial Array Self Refresh (PASR), by which partial areas of memory could be turned off to save power. Further, few other SoCs have multiple memory controllers, like Samsung Exynos 4210, where each controller independently transitions memory under it into lower power states depending on certain criteria. Each of these capabilities are supported by the hardware at a particular granularity. For example, PASR could be supported at the level of a memory bank, i.e, a bank of memory that is free could be turned off, independent of the other banks.
Inorder to exploit these features, the Linux VM subsystem needs to be modified to take into account the physical memory topology when managing memory. We proposed a generic memory regions infrastructure, that could be used to tag boundaries of memory blocks which belong to a specific memory power management domain and further enable exploitation of platform capabilities. The details of this framework can be found here:
https://lkml.org/lkml/2011/5/27/177
Memory region is a layer of abstraction that would be created at boot time, with information from firmware regarding the granularity at which memory power can be managed on the platform. We would like to work towards having this information exported by u-boot. A sample interface we are looking at is a device tree node that would provide the number, size and starting address corresponding to the memory power domains on the underlying platform.
In this regard, we want some help from the u-boot community on designing the interfaces. Further, we would like to collaborate with all the SoCs that have support for managing memory power on their boards, so we could design a generic interface that can be exploited by all.
Signature · 5 lines
Regards, Ankita Garg (ankita at in.ibm.com) Linux Technology Center IBM India Systems & Technology Labs, Bangalore, India
Dear Ankita Garg,
Quoted 5 lines · In message <[email protected]> you wrote:
In this regard, we want some help from the u-boot community on designing the interfaces. Further, we would like to collaborate with all the SoCs that have support for managing memory power on their boards, so we could design a generic interface that can be exploited by all.
Could you please be so kind and explain which of such functionality you envision to see in ore expect from U-Boot?
I understand why all thisi s a very important topic for an operating system like Linux.
But U-Boot is a boot loader. It is being used mainly in two different environments or usage modes:
1) First, U-Boot is a powerful tool for board bringup and for software development purposes. In this environment, power consumption is usually the least of your concerns. Instead, we focus on simplicity and robustness.
2) Second, U-Boot is (sometimes) an inevitable intermediate step when booting an operating system. In this mode, whole purpose of U-Boot is to get it's job done and then get out of the way as quickly as possible.
So in real-world applications we may see a few ten, or maybe in worst case up to a few hundred milliseconds of U-Boot runtime compared to hours, days and often weeks and months of run time of the respective operating system.
Keeping this in mind, which are the parts of memory power management that are important for the U-Boot context?
Thanks.
Best regards,
Wolfgang Denk
Signature · 4 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de It's not an optical illusion, it just looks like one. -- Phil White
Hi,
Quoted 28 lines · Wolfgang Denk
Dear Ankita Garg,
Quoted 5 lines · In message <[email protected]> you wrote:
In this regard, we want some help from the u-boot community on designing the interfaces. Further, we would like to collaborate with all the SoCs that have support for managing memory power on their boards, so we could design a generic interface that can be exploited by all.
Could you please be so kind and explain which of such functionality you envision to see in ore expect from U-Boot?
I understand why all thisi s a very important topic for an operating system like Linux.
But U-Boot is a boot loader. It is being used mainly in two different environments or usage modes:
1) First, U-Boot is a powerful tool for board bringup and for software development purposes. In this environment, power consumption is usually the least of your concerns. Instead, we focus on simplicity and robustness.
2) Second, U-Boot is (sometimes) an inevitable intermediate step when booting an operating system. In this mode, whole purpose of U-Boot is to get it's job done and then get out of the way as quickly as possible.
Quoted 9 lines
So in real-world applications we may see a few ten, or maybe in worst case up to a few hundred milliseconds of U-Boot runtime compared to hours, days and often weeks and months of run time of the respective operating system.
Keeping this in mind, which are the parts of memory power management that are important for the U-Boot context?
I agree with the above. Its not the power consumed by u-boot that is of concern. We want u-boot support in exporting additional information to the kernel, regarding the memory hardware characteristics specific to power management. For instance, if u-boot could inform the kernel about the boundaries at which PASR is supported on the underlying platform, that information could then be used by the kernel to exploit this feature. Like, this information would be encapsulated in a device-tree node maybe ?
Signature · 5 lines
Regards, Ankita Garg (ankita at in.ibm.com) Linux Technology Center IBM India Systems & Technology Labs, Bangalore, India
Dear Ankita Garg,
Quoted 9 lines · In message <[email protected]> you wrote:
I agree with the above. Its not the power consumed by u-boot that is of concern. We want u-boot support in exporting additional information to the kernel, regarding the memory hardware characteristics specific to power management. For instance, if u-boot could inform the kernel about the boundaries at which PASR is supported on the underlying platform, that information could then be used by the kernel to exploit this feature. Like, this information would be encapsulated in a device-tree node maybe ?
I agree that is is a good idea to encode such information in the device tree. U-Boot can also help to update memory related notes in the device tree, for example by inserting their actual physical addresses and sizes.
The rest, including information about memory power management properties of such nodes in the device tree, is of no concern to U-Boot and should just be passed on unchanged.
In my opinion it is therefore the responsibility of the creator of the device tree to provide a proper description of the hardware, including the memory power management information.
Best regards,
Wolfgang Denk
Signature · 4 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Democracy is mob rule, but with income taxes.
Hi,
Quoted 18 lines · Wolfgang Denk
Dear Ankita Garg,
Quoted 9 lines · In message <[email protected]> you wrote:
I agree with the above. Its not the power consumed by u-boot that is of concern. We want u-boot support in exporting additional information to the kernel, regarding the memory hardware characteristics specific to power management. For instance, if u-boot could inform the kernel about the boundaries at which PASR is supported on the underlying platform, that information could then be used by the kernel to exploit this feature. Like, this information would be encapsulated in a device-tree node maybe ?
I agree that is is a good idea to encode such information in the device tree. U-Boot can also help to update memory related notes in the device tree, for example by inserting their actual physical addresses and sizes.
Quoted 8 lines
The rest, including information about memory power management properties of such nodes in the device tree, is of no concern to U-Boot and should just be passed on unchanged.
In my opinion it is therefore the responsibility of the creator of the device tree to provide a proper description of the hardware, including the memory power management information.
Ok, thats true. So I guess a better place would be the linux-arm-kernel list to discuss about potential device-tree interface design. Thanks Wolfgang !
Signature · 5 lines
Regards, Ankita Garg (ankita at in.ibm.com) Linux Technology Center IBM India Systems & Technology Labs, Bangalore, India
Dear Ankita Garg,
Quoted 7 lines · In message <[email protected]> you wrote:
Quoted 4 lines
In my opinion it is therefore the responsibility of the creator of the device tree to provide a proper description of the hardware, including the memory power management information.
Ok, thats true. So I guess a better place would be the linux-arm-kernel list to discuss about potential device-tree interface design.
Indeed.
Quoted 1 line
Thanks Wolfgang !
You are welcome. Please feel free to keep the U-Boot list on Cc: with any topics where the boot loader might help to fill in any parameters that should better be determined dynalically. We'll be happy to help with that.
Best regards,
Wolfgang Denk
Signature · 4 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de "I didn't know it was impossible when I did it."