Hey Paul,
As promised, here is my list of topics, tasks and priorities for the 11.11 cycle. It's a bit of a rough list, but I'll refine it as we get closer to UDS
Boot Architecture - Refine UEFI position paper (draft of position paper will be prepared before UDS) - Refine boot architecture technical recommendations paper (draft will be prepared before UDS) - must include reference implementation (based on existing u-boot; not talking about writing something new here) - Upgrade procedure for OS - Upgrade procedure for Firmware - Security concerns? - Must guarantee reliability (no bricked boards). - Discuss kexec bootloader, possibly implement for 11.11 cycle - Implement appending of device tree and initrd to zImage - To support minimal bootloader and kexec bootloaders. - Simplify the process of installing a boot image. - Implement device tree bindings to describing boot method - So that Linux knows how to upgrade the kernel and possibly the bootloader. - SDcard? NAND? NOR? Which partition? etc. I've got a lot of topics on boot architecture. Most of the needed technology is in place, but I think it is needed to document best practices and methods that should be used when designing a system. What technologies, why, how to put them together, and how to maintain/support them. It's important to get the guidelines out onto paper instead of as 'tribal knowledge'
Device Tree - device tree board description and implementations for: - The omap3 boards are the priority since there are numerous expansion boards that can be described (Zippy, trainer, etc) which is an excellent use-case. - mx51 & mx53 eval and efika boards - samsung eval boards - OMAP3 BeagleBoard, Overo and IGEP boards. - device tree SoC descriptions for SoCs - A lot of work has already been done for Samsung and Freescale SoCs. It would be very interesting to converting an entire SoC over to use device tree with dtb linked into the kernel for bootloaders that cannot pass a dtb blob. That would eliminate the problem of duplicate setup paths - Would also need task to support linking multiple .dtbs into the kernel - Complete clock bindings - mostly depends on common clock framework - Complete virq implementation - **critical task**
Linux ARM Maintainership/Vision - Full multiplatform - Support multiple SoC families with a single kernel - to avoid either/or decisions when adding new features to the kernel - have guidelines for how new interfaces should be defined. Example: right now struct clk has a different implementation for every SoC, and only one can be compiled in at a time. New interfaces should be runtime pluggable wherever possible - to increase code coverage for allyesconfig/allmodconfig. - Document best practices for Linux driver model - Where does data come from (probed, device tree, platform_data) - How to generalize as much device registration as possible - How to get away from big lists of devices in board-*.c files. - How to reduce code duplication. Basically, I'd like to encourage embedded Linux engineers to think about the wider scope for the code that they write. To ask themselves if the work they are doing could be useful to the wider ARM Linux infrastructure. I'm not sure how to translate the above items into blueprints, but I think the tasks resolve to writing a lot of documentation and articles, and probably reviewing a lot of code.
You can probably take the first level bullet points in each category as names for blueprints. My priorities are to make sure at least one platform has a 100% complete device tree implementation by the 11.11 release, and that there is a good set of documentation to go with it covering both boot architecture and device tree. I'd actually like to see 2 or 3 platforms with a complete implementation, but I'd rather see 1 platform will a full solution than 3 half baked ones. Close second is the boot architecture documentation and any associated sample implementation.
Loïc, David, I'm sure I've missed some of the topics we've talked about. Is there anything else you can think of that should be added to this list?
g.
On Tue, Apr 05, 2011 at 01:11:43PM -0600, Grant Likely wrote:
Hey Paul,
As promised, here is my list of topics, tasks and priorities for the 11.11 cycle. It's a bit of a rough list, but I'll refine it as we get closer to UDS
Thank you, Grant! I have summarized this in the table that I am building:
https://wiki.linaro.org/Cycles/1111/TechnicalTopics/Kernel
I have made rough guesses at priorities, please let me know what priorities would be better.
Boot Architecture
I have this as K3. I put the boot-architecture paper as "high", kexec boot loader as "low", and all else as "medium".
- Refine UEFI position paper (draft of position paper will be prepared
before UDS)
- Refine boot architecture technical recommendations paper (draft will
be prepared before UDS)
- must include reference implementation (based on existing u-boot;
not talking about writing something new here)
- Upgrade procedure for OS
- Upgrade procedure for Firmware
- Security concerns?
- Must guarantee reliability (no bricked boards).
- Discuss kexec bootloader, possibly implement for 11.11 cycle
- Implement appending of device tree and initrd to zImage
- To support minimal bootloader and kexec bootloaders.
- Simplify the process of installing a boot image.
- Implement device tree bindings to describing boot method
- So that Linux knows how to upgrade the kernel and possibly the bootloader.
- SDcard? NAND? NOR? Which partition? etc.
I've got a lot of topics on boot architecture. Most of the needed technology is in place, but I think it is needed to document best practices and methods that should be used when designing a system. What technologies, why, how to put them together, and how to maintain/support them. It's important to get the guidelines out onto paper instead of as 'tribal knowledge'
Device Tree
I have this as K3. The virq work marked "essential", the others marked "high".
- device tree board description and implementations for:
- The omap3 boards are the priority since there are numerous
expansion boards that can be described (Zippy, trainer, etc) which is an excellent use-case.
- mx51 & mx53 eval and efika boards
- samsung eval boards
- OMAP3 BeagleBoard, Overo and IGEP boards.
- device tree SoC descriptions for SoCs
- A lot of work has already been done for Samsung and Freescale
SoCs. It would be very interesting to converting an entire SoC over to use device tree with dtb linked into the kernel for bootloaders that cannot pass a dtb blob. That would eliminate the problem of duplicate setup paths
- Would also need task to support linking multiple .dtbs into the kernel
- Complete clock bindings - mostly depends on common clock framework
- Complete virq implementation - **critical task**
Linux ARM Maintainership/Vision
I have added this to K1, which also includes "Fix ARM/Linus Interface", which is "essential". I have documenting driver best practice as "high" and single kernel binary as "medium".
Thanx, Paul
- Full multiplatform - Support multiple SoC families with a single kernel
- to avoid either/or decisions when adding new features to the kernel
- have guidelines for how new interfaces should be defined.
Example: right now struct clk has a different implementation for every SoC, and only one can be compiled in at a time. New interfaces should be runtime pluggable wherever possible
- to increase code coverage for allyesconfig/allmodconfig.
- Document best practices for Linux driver model
- Where does data come from (probed, device tree, platform_data)
- How to generalize as much device registration as possible
- How to get away from big lists of devices in board-*.c files.
- How to reduce code duplication.
Basically, I'd like to encourage embedded Linux engineers to think about the wider scope for the code that they write. To ask themselves if the work they are doing could be useful to the wider ARM Linux infrastructure. I'm not sure how to translate the above items into blueprints, but I think the tasks resolve to writing a lot of documentation and articles, and probably reviewing a lot of code.
You can probably take the first level bullet points in each category as names for blueprints. My priorities are to make sure at least one platform has a 100% complete device tree implementation by the 11.11 release, and that there is a good set of documentation to go with it covering both boot architecture and device tree. I'd actually like to see 2 or 3 platforms with a complete implementation, but I'd rather see 1 platform will a full solution than 3 half baked ones. Close second is the boot architecture documentation and any associated sample implementation.
Loïc, David, I'm sure I've missed some of the topics we've talked about. Is there anything else you can think of that should be added to this list?
g.
-- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd.
linaro-kernel mailing list linaro-kernel@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-kernel
On Tue, Apr 05, 2011 at 12:59:27PM -0700, Paul E. McKenney wrote:
On Tue, Apr 05, 2011 at 01:11:43PM -0600, Grant Likely wrote:
Hey Paul,
As promised, here is my list of topics, tasks and priorities for the 11.11 cycle. It's a bit of a rough list, but I'll refine it as we get closer to UDS
Thank you, Grant! I have summarized this in the table that I am building:
https://wiki.linaro.org/Cycles/1111/TechnicalTopics/Kernel
I have made rough guesses at priorities, please let me know what priorities would be better.
One other thing... Any rough guesses on the time required to do the development on these items?
Thanx, Paul
Boot Architecture
I have this as K3. I put the boot-architecture paper as "high", kexec boot loader as "low", and all else as "medium".
- Refine UEFI position paper (draft of position paper will be prepared
before UDS)
- Refine boot architecture technical recommendations paper (draft will
be prepared before UDS)
- must include reference implementation (based on existing u-boot;
not talking about writing something new here)
- Upgrade procedure for OS
- Upgrade procedure for Firmware
- Security concerns?
- Must guarantee reliability (no bricked boards).
- Discuss kexec bootloader, possibly implement for 11.11 cycle
- Implement appending of device tree and initrd to zImage
- To support minimal bootloader and kexec bootloaders.
- Simplify the process of installing a boot image.
- Implement device tree bindings to describing boot method
- So that Linux knows how to upgrade the kernel and possibly the bootloader.
- SDcard? NAND? NOR? Which partition? etc.
I've got a lot of topics on boot architecture. Most of the needed technology is in place, but I think it is needed to document best practices and methods that should be used when designing a system. What technologies, why, how to put them together, and how to maintain/support them. It's important to get the guidelines out onto paper instead of as 'tribal knowledge'
Device Tree
I have this as K3. The virq work marked "essential", the others marked "high".
- device tree board description and implementations for:
- The omap3 boards are the priority since there are numerous
expansion boards that can be described (Zippy, trainer, etc) which is an excellent use-case.
- mx51 & mx53 eval and efika boards
- samsung eval boards
- OMAP3 BeagleBoard, Overo and IGEP boards.
- device tree SoC descriptions for SoCs
- A lot of work has already been done for Samsung and Freescale
SoCs. It would be very interesting to converting an entire SoC over to use device tree with dtb linked into the kernel for bootloaders that cannot pass a dtb blob. That would eliminate the problem of duplicate setup paths
- Would also need task to support linking multiple .dtbs into the kernel
- Complete clock bindings - mostly depends on common clock framework
- Complete virq implementation - **critical task**
Linux ARM Maintainership/Vision
I have added this to K1, which also includes "Fix ARM/Linus Interface", which is "essential". I have documenting driver best practice as "high" and single kernel binary as "medium".
Thanx, Paul
- Full multiplatform - Support multiple SoC families with a single kernel
- to avoid either/or decisions when adding new features to the kernel
- have guidelines for how new interfaces should be defined.
Example: right now struct clk has a different implementation for every SoC, and only one can be compiled in at a time. New interfaces should be runtime pluggable wherever possible
- to increase code coverage for allyesconfig/allmodconfig.
- Document best practices for Linux driver model
- Where does data come from (probed, device tree, platform_data)
- How to generalize as much device registration as possible
- How to get away from big lists of devices in board-*.c files.
- How to reduce code duplication.
Basically, I'd like to encourage embedded Linux engineers to think about the wider scope for the code that they write. To ask themselves if the work they are doing could be useful to the wider ARM Linux infrastructure. I'm not sure how to translate the above items into blueprints, but I think the tasks resolve to writing a lot of documentation and articles, and probably reviewing a lot of code.
You can probably take the first level bullet points in each category as names for blueprints. My priorities are to make sure at least one platform has a 100% complete device tree implementation by the 11.11 release, and that there is a good set of documentation to go with it covering both boot architecture and device tree. I'd actually like to see 2 or 3 platforms with a complete implementation, but I'd rather see 1 platform will a full solution than 3 half baked ones. Close second is the boot architecture documentation and any associated sample implementation.
Loïc, David, I'm sure I've missed some of the topics we've talked about. Is there anything else you can think of that should be added to this list?
g.
-- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd.
linaro-kernel mailing list linaro-kernel@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-kernel
Hi Paul,
On Tue, Apr 05, 2011 at 12:59:27PM -0700, Paul E. McKenney wrote:
On Tue, Apr 05, 2011 at 01:11:43PM -0600, Grant Likely wrote:
Hey Paul,
As promised, here is my list of topics, tasks and priorities for the 11.11 cycle. It's a bit of a rough list, but I'll refine it as we get closer to UDS
Thank you, Grant! I have summarized this in the table that I am building:
https://wiki.linaro.org/Cycles/1111/TechnicalTopics/Kernel
I have made rough guesses at priorities, please let me know what priorities would be better.
Boot Architecture
I have this as K3. I put the boot-architecture paper as "high", kexec boot loader as "low", and all else as "medium".
- Refine UEFI position paper (draft of position paper will be prepared
before UDS)
- Refine boot architecture technical recommendations paper (draft will
be prepared before UDS)
- must include reference implementation (based on existing u-boot;
not talking about writing something new here)
- Upgrade procedure for OS
- Upgrade procedure for Firmware
- Security concerns?
- Must guarantee reliability (no bricked boards).
- Discuss kexec bootloader, possibly implement for 11.11 cycle
- Implement appending of device tree and initrd to zImage
- To support minimal bootloader and kexec bootloaders.
- Simplify the process of installing a boot image.
- Implement device tree bindings to describing boot method
- So that Linux knows how to upgrade the kernel and possibly the bootloader.
- SDcard? NAND? NOR? Which partition? etc.
I've got a lot of topics on boot architecture. Most of the needed technology is in place, but I think it is needed to document best practices and methods that should be used when designing a system. What technologies, why, how to put them together, and how to maintain/support them. It's important to get the guidelines out onto paper instead of as 'tribal knowledge'
Device Tree
I have this as K3. The virq work marked "essential", the others marked "high".
You probably meant K2 here.
On Wed, Apr 06, 2011 at 01:44:16PM +0800, Shawn Guo wrote:
Hi Paul,
On Tue, Apr 05, 2011 at 12:59:27PM -0700, Paul E. McKenney wrote:
On Tue, Apr 05, 2011 at 01:11:43PM -0600, Grant Likely wrote:
Hey Paul,
As promised, here is my list of topics, tasks and priorities for the 11.11 cycle. It's a bit of a rough list, but I'll refine it as we get closer to UDS
Thank you, Grant! I have summarized this in the table that I am building:
https://wiki.linaro.org/Cycles/1111/TechnicalTopics/Kernel
I have made rough guesses at priorities, please let me know what priorities would be better.
Boot Architecture
I have this as K3. I put the boot-architecture paper as "high", kexec boot loader as "low", and all else as "medium".
- Refine UEFI position paper (draft of position paper will be prepared
before UDS)
- Refine boot architecture technical recommendations paper (draft will
be prepared before UDS)
- must include reference implementation (based on existing u-boot;
not talking about writing something new here)
- Upgrade procedure for OS
- Upgrade procedure for Firmware
- Security concerns?
- Must guarantee reliability (no bricked boards).
- Discuss kexec bootloader, possibly implement for 11.11 cycle
- Implement appending of device tree and initrd to zImage
- To support minimal bootloader and kexec bootloaders.
- Simplify the process of installing a boot image.
- Implement device tree bindings to describing boot method
- So that Linux knows how to upgrade the kernel and possibly the bootloader.
- SDcard? NAND? NOR? Which partition? etc.
I've got a lot of topics on boot architecture. Most of the needed technology is in place, but I think it is needed to document best practices and methods that should be used when designing a system. What technologies, why, how to put them together, and how to maintain/support them. It's important to get the guidelines out onto paper instead of as 'tribal knowledge'
Device Tree
I have this as K3. The virq work marked "essential", the others marked "high".
You probably meant K2 here.
Indeed I did! I had both device tree and boot architecture as K3, which I have now fixed.
Thanx, Paul
On Tue, Apr 05, 2011, Grant Likely wrote:
Loïc, David, I'm sure I've missed some of the topics we've talked about. Is there anything else you can think of that should be added to this list?
The two things I can think of are: * Boot architecture: discuss how we could standardize the layout of boot media; this might relate to UEFI * (low) Recommendations on hardware changes for better discoverability of specific devices -- what we discussed today
On Apr 5, 2011 3:48 PM, "Loïc Minier" loic.minier@linaro.org wrote:
On Tue, Apr 05, 2011, Grant Likely wrote:
Loďc, David, I'm sure I've missed some of the topics we've talked about. Is there anything else you can think of that should be added to this list?
The two things I can think of are:
- Boot architecture: discuss how we could standardize the layout of
boot media; this might relate to UEFI
- (low) Recommendations on hardware changes for better discoverability
of specific devices -- what we discussed today
Yes, thanks.
Paul, please add to the list.
g.
-- Loďc Minier
On Wed, Apr 06, 2011 at 07:06:19AM -0600, Grant Likely wrote:
On Apr 5, 2011 3:48 PM, "Loïc Minier" loic.minier@linaro.org wrote:
On Tue, Apr 05, 2011, Grant Likely wrote:
Loďc, David, I'm sure I've missed some of the topics we've talked about. Is there anything else you can think of that should be added to this list?
The two things I can think of are:
- Boot architecture: discuss how we could standardize the layout of
boot media; this might relate to UEFI
- (low) Recommendations on hardware changes for better discoverability
of specific devices -- what we discussed today
Yes, thanks.
Paul, please add to the list.
Done, items K3.6 and K3.7, respectively. I put K3.6 as "medium".
From what I can see given current (and foreseeable) staffing, "low"
means "will happen only by accident" and "medium" means "at risk".
Thanx, Paul
On Tue, 5 Apr 2011, Grant Likely wrote:
Linux ARM Maintainership/Vision
- Full multiplatform - Support multiple SoC families with a single kernel
[...]
I'm not sure how to translate the above items into blueprints, but I think the tasks resolve to writing a lot of documentation and articles, and probably reviewing a lot of code.
For the above item, you can refer to the following:
https://wiki.ubuntu.com/Specs/ARMSingleKernel
A couple items have been implemented at this time already, some are partially implemented, and the list of not yet implemented items is probably incomplete.
Nicolas
On Tue, Apr 05, 2011 at 11:32:29PM -0400, Nicolas Pitre wrote:
On Tue, 5 Apr 2011, Grant Likely wrote:
Linux ARM Maintainership/Vision
- Full multiplatform - Support multiple SoC families with a single kernel
[...]
I'm not sure how to translate the above items into blueprints, but I think the tasks resolve to writing a lot of documentation and articles, and probably reviewing a lot of code.
For the above item, you can refer to the following:
https://wiki.ubuntu.com/Specs/ARMSingleKernel
A couple items have been implemented at this time already, some are partially implemented, and the list of not yet implemented items is probably incomplete.
I have added this URL as reference material. Thank you, Nicolas!
Thanx, Paul
linaro-kernel@lists.linaro.org
-
Grant Likely -
Loïc Minier -
Nicolas Pitre -
Paul E. McKenney -
Shawn Guo