Hi all,
We need to start planning for Linaro Connect/UDS in Orlando. For those that have not attended one of these events before, the way they are run is very different than a traditional conference. We will be running summit sessions which are focused discussions on specific topics with the goal of getting a list of concrete action items, both technical and logistical, towards solving a problem. Unlike prior UDS events, where Linaro was 100% focused on planning, we will split the day with planning summits in the morning and hacking in the afternoon. I'd like to gather a list of topics from everyone so that I can start creating the session blueprints that will be used by the scheduler and the notetaking system. My current list of topics:
- Single zImage (2 sessions?) - Device Tree (2 sessions?) - Blueprint/Work Item process - eMMC 4.5/UFS - Flash storage optimizations (follow up from last connect) - Android Upstreaming - Kernel CI Loop
Please provide any other ideas you may have.
Thanks, ~Deepak
On Wed, 21 Sep 2011, Deepak Saxena wrote:
I'd like to gather a list of topics from everyone so that I can start creating the session blueprints that will be used by the scheduler and the notetaking system. My current list of topics:
- Single zImage (2 sessions?)
- Device Tree (2 sessions?)
- Blueprint/Work Item process
- eMMC 4.5/UFS
- Flash storage optimizations (follow up from last connect)
- Android Upstreaming
- Kernel CI Loop
Please provide any other ideas you may have.
- UEFI / boot architecture, secure services API, etc.
- Neon assisted in-kernel algorithms (CRC32, crypto, etc)
- Early serial output facility (separate from CONFIG_DEBUG_LL) [this may or may not be related to single zImage]
- ARM-SoC upstream maintenance process review
- struct_clk
- faith of the Linaro kernel
Nicolas
On 21 September 2011 13:09, Nicolas Pitre nicolas.pitre@linaro.org wrote:
On Wed, 21 Sep 2011, Deepak Saxena wrote:
I'd like to gather a list of topics from everyone so that I can start creating the session blueprints that will be used by the scheduler and the notetaking system. My current list of topics:
- Single zImage (2 sessions?)
- Device Tree (2 sessions?)
- Blueprint/Work Item process
- eMMC 4.5/UFS
- Flash storage optimizations (follow up from last connect)
- Android Upstreaming
- Kernel CI Loop
Please provide any other ideas you may have.
- UEFI / boot architecture, secure services API, etc.
Grant, David, is OCTO already planning a session on this @ connect?
- Neon assisted in-kernel algorithms (CRC32, crypto, etc)
+1
- Early serial output facility (separate from CONFIG_DEBUG_LL)
[this may or may not be related to single zImage]
I think this one is probably best rolled into the zImage session? It seems like a lot to talk about for an hour. Note that we can also use the hacking time to dive deep into a specific sub-topic.
- ARM-SoC upstream maintenance process review
+20. I'm assuming/hoping that this will also be discussed the week before at the sub-arch summit.
- struct_clk
Amit, are you planning on running a session on Linaro on the topic?
- faith of the Linaro kernel
I'll find a more politically correct way to word that. :)
~Deepak
On Wed, Sep 21, 2011 at 11:17 PM, Deepak Saxena dsaxena@linaro.org wrote:
On 21 September 2011 13:09, Nicolas Pitre nicolas.pitre@linaro.org wrote:
- struct_clk
Amit, are you planning on running a session on Linaro on the topic?
I was planning a hacking session around this (say, 2 half days) and invite the various clock tree engineers from members and non-members to hack with us. But if there is an interest in a discussion, we could ask Mike to lead a session on the first day that leads into the hacking sessions.
The target for October is to get a small subset of the clock tree for OMAP, Exynos and i.MX (still to find a resource to do u8500) working with the common code and make it available in a git tree for Nico's tree.
Regards, Amit
On Wed, 21 Sep 2011, Deepak Saxena wrote:
On 21 September 2011 13:09, Nicolas Pitre nicolas.pitre@linaro.org wrote:
On Wed, 21 Sep 2011, Deepak Saxena wrote:
Please provide any other ideas you may have.
- Early serial output facility (separate from CONFIG_DEBUG_LL)
[this may or may not be related to single zImage]
I think this one is probably best rolled into the zImage session? It seems like a lot to talk about for an hour. Note that we can also use the hacking time to dive deep into a specific sub-topic.
True. I just wanted this to be on the radar, given recent complaints from RMK about this.
- ARM-SoC upstream maintenance process review
+20. I'm assuming/hoping that this will also be discussed the week before at the sub-arch summit.
Obviously. But not everyone will make both events.
- faith of the Linaro kernel
I'll find a more politically correct way to word that. :)
Hmmm... I _did_ reword this already before hitting the send key! LOL But hey, I trust you more than myself on the topic of political correctness.
Nicolas
On Wed, Sep 21, 2011 at 01:17:30PM -0700, Deepak Saxena wrote:
On 21 September 2011 13:09, Nicolas Pitre nicolas.pitre@linaro.org wrote:
On Wed, 21 Sep 2011, Deepak Saxena wrote:
I'd like to gather a list of topics from everyone so that I can start creating the session blueprints that will be used by the scheduler and the notetaking system. My current list of topics:
- Single zImage (2 sessions?)
- Device Tree (2 sessions?)
- Blueprint/Work Item process
- eMMC 4.5/UFS
- Flash storage optimizations (follow up from last connect)
- Android Upstreaming
- Kernel CI Loop
Please provide any other ideas you may have.
- UEFI / boot architecture, secure services API, etc.
Grant, David, is OCTO already planning a session on this @ connect?
No, there aren't any plans to have a boot architecture summit @ connect. Mostly because I won't be there. Instead I'm going to organize a boot architecture meeting at ELC-E the week before in Prague.
- Early serial output facility (separate from CONFIG_DEBUG_LL)
[this may or may not be related to single zImage]
I think this one is probably best rolled into the zImage session? It seems like a lot to talk about for an hour. Note that we can also use the hacking time to dive deep into a specific sub-topic.
- ARM-SoC upstream maintenance process review
+20. I'm assuming/hoping that this will also be discussed the week before at the sub-arch summit.
Yes, absolutely.
g.
On Wed, Sep 21, 2011 at 04:09:19PM -0400, Nicolas Pitre wrote:
On Wed, 21 Sep 2011, Deepak Saxena wrote:
I'd like to gather a list of topics from everyone so that I can start creating the session blueprints that will be used by the scheduler and the notetaking system. My current list of topics:
- Single zImage (2 sessions?)
- Device Tree (2 sessions?)
- Blueprint/Work Item process
- eMMC 4.5/UFS
- Flash storage optimizations (follow up from last connect)
- Android Upstreaming
- Kernel CI Loop
Please provide any other ideas you may have.
UEFI / boot architecture, secure services API, etc.
Neon assisted in-kernel algorithms (CRC32, crypto, etc)
Early serial output facility (separate from CONFIG_DEBUG_LL) [this may or may not be related to single zImage]
Should we add "early FDT parser" to that?
The current fact that we have a hardware description which is opaque to the early boot process seems to be a recurring problem for us, affecting zImage, low-level debug and some early board init code.
My idea would be to have a malloc-less parser which can pull individual nodes and properties out of the fdt blob, and resolve physical addresses. I feel that the amount of functionality required in order to make this useful is really quite modest.
ARM-SoC upstream maintenance process review
struct_clk
faith of the Linaro kernel
Nicolas
linaro-kernel mailing list linaro-kernel@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-kernel
On Thu, Sep 22, 2011 at 7:21 AM, Dave Martin dave.martin@linaro.org wrote:
On Wed, Sep 21, 2011 at 04:09:19PM -0400, Nicolas Pitre wrote:
On Wed, 21 Sep 2011, Deepak Saxena wrote:
I'd like to gather a list of topics from everyone so that I can start creating the session blueprints that will be used by the scheduler and the notetaking system. My current list of topics:
- Single zImage (2 sessions?)
- Device Tree (2 sessions?)
- Blueprint/Work Item process
- eMMC 4.5/UFS
- Flash storage optimizations (follow up from last connect)
- Android Upstreaming
- Kernel CI Loop
Please provide any other ideas you may have.
UEFI / boot architecture, secure services API, etc.
Neon assisted in-kernel algorithms (CRC32, crypto, etc)
Early serial output facility (separate from CONFIG_DEBUG_LL)
[this may or may not be related to single zImage]
Should we add "early FDT parser" to that?
The current fact that we have a hardware description which is opaque to the early boot process seems to be a recurring problem for us, affecting zImage, low-level debug and some early board init code.
My idea would be to have a malloc-less parser which can pull individual nodes and properties out of the fdt blob, and resolve physical addresses. I feel that the amount of functionality required in order to make this useful is really quite modest.
We already have this for the zImage wrapper. The dtb append patches pull in libfdt which does what you're suggesting. However, we do need to add some parsing code for physical addresses.
g.
On Thu, Sep 22, 2011 at 07:55:37AM -0600, Grant Likely wrote:
On Thu, Sep 22, 2011 at 7:21 AM, Dave Martin dave.martin@linaro.org wrote:
On Wed, Sep 21, 2011 at 04:09:19PM -0400, Nicolas Pitre wrote:
On Wed, 21 Sep 2011, Deepak Saxena wrote:
I'd like to gather a list of topics from everyone so that I can start creating the session blueprints that will be used by the scheduler and the notetaking system. My current list of topics:
- Single zImage (2 sessions?)
- Device Tree (2 sessions?)
- Blueprint/Work Item process
- eMMC 4.5/UFS
- Flash storage optimizations (follow up from last connect)
- Android Upstreaming
- Kernel CI Loop
Please provide any other ideas you may have.
UEFI / boot architecture, secure services API, etc.
Neon assisted in-kernel algorithms (CRC32, crypto, etc)
Early serial output facility (separate from CONFIG_DEBUG_LL)
[this may or may not be related to single zImage]
Should we add "early FDT parser" to that?
The current fact that we have a hardware description which is opaque to the early boot process seems to be a recurring problem for us, affecting zImage, low-level debug and some early board init code.
My idea would be to have a malloc-less parser which can pull individual nodes and properties out of the fdt blob, and resolve physical addresses. I feel that the amount of functionality required in order to make this useful is really quite modest.
We already have this for the zImage wrapper. The dtb append patches pull in libfdt which does what you're suggesting. However, we do need to add some parsing code for physical addresses.
Fair enough -- so there is work needed, but it is already partly done.
Cheers ---Dave
On Thu, 22 Sep 2011, Dave Martin wrote:
On Wed, Sep 21, 2011 at 04:09:19PM -0400, Nicolas Pitre wrote:
On Wed, 21 Sep 2011, Deepak Saxena wrote:
I'd like to gather a list of topics from everyone so that I can start creating the session blueprints that will be used by the scheduler and the notetaking system. My current list of topics:
- Single zImage (2 sessions?)
- Device Tree (2 sessions?)
- Blueprint/Work Item process
- eMMC 4.5/UFS
- Flash storage optimizations (follow up from last connect)
- Android Upstreaming
- Kernel CI Loop
Please provide any other ideas you may have.
UEFI / boot architecture, secure services API, etc.
Neon assisted in-kernel algorithms (CRC32, crypto, etc)
Early serial output facility (separate from CONFIG_DEBUG_LL) [this may or may not be related to single zImage]
Should we add "early FDT parser" to that?
I think this is implied.
The current fact that we have a hardware description which is opaque to the early boot process seems to be a recurring problem for us, affecting zImage, low-level debug and some early board init code.
Right.
Nicolas
On Wednesday 21 September 2011 12:45:48 Deepak Saxena wrote:
- Single zImage (2 sessions?)
- Device Tree (2 sessions?)
- Blueprint/Work Item process
- eMMC 4.5/UFS
- Flash storage optimizations (follow up from last connect)
- Android Upstreaming
- Kernel CI Loop
Please provide any other ideas you may have.
I think we need to start making KVM a priority. Not sure how the TSC views this, but I know that a lot of people are interested and time is running out before Cortex-A15 becomes available. If this gets delayed for another cycle, we might miss it.
Arnd
On Wed, 2011-09-21 at 12:45 -0700, Deepak Saxena wrote:
Hi all,
We need to start planning for Linaro Connect/UDS in Orlando. For those that have not attended one of these events before, the way they are run is very different than a traditional conference. We will be running summit sessions which are focused discussions on specific topics with the goal of getting a list of concrete action items, both technical and logistical, towards solving a problem. Unlike prior UDS events, where Linaro was 100% focused on planning, we will split the day with planning summits in the morning and hacking in the afternoon. I'd like to gather a list of topics from everyone so that I can start creating the session blueprints that will be used by the scheduler and the notetaking system. My current list of topics:
...
- Android Upstreaming
I'd break these out into two major items for next cycle: o Wakelock equivalent functionality o Ashmem equivalent functionality
As well as likely items from this cycle that have been back-burnered: o lowmemory killer functionality o alarm enabled timerfd
Although I'm ok covering all of these in one discussion.
Another item that is sort of un-related to previous Linaro work is the 2038 issue with 32 bit time_t and what sort of workarounds folks think are reasonable. Intel is pushing a new arch ABI x32, which is a 32bit architecture, but uses a 64 bit time_t. We may want to look for something similar (introducing a new ABI) so that 32bit applications written today continue to function past 26 years from now. Are there any other ABI cleanups needed that could go along with this? (Or did everything except time_t get sorted during the last ABI cleanup? :) Clearly this isn't super critical, as all other 32 bit arches have the same problem, so it can be deferred, but we should maybe start thinking about it.
thanks -john
linaro-kernel@lists.linaro.org
-
Amit Kucheria -
Arnd Bergmann -
Dave Martin -
Deepak Saxena -
Grant Likely -
john stultz -
Nicolas Pitre