* Discussion to generalize the maintenance process of kernel branches
> for the periodic Linaro releases. This still needs documenting in the
> wiki.
>
> * Merged a set of patches put together by Anand Gadiyar to add display
> support to the PandaBoard.
>
> * Merged the following additional patches:
>
> * d983450 cpufreq: Add documentation for sampling_down_factor
> * 054fcd5 ARM: S5P: Fix end address in memory resource information for UART devices
> * bf47520 ARM: make SWP emulation explicit on !CPU_USE_DOMAINS
> * 459967a ARM: fixup SMP alternatives in modules
> * 7144fbc ARM: 6654/1: perf/oprofile: fix off-by-one in stack check
> * 067dfdf ARM: 6659/1: Thumb-2: Make CONFIG_OABI_COMPAT depend on !CONFIG_THUMB2_KERNEL
> * cc0f308 ARM: 6656/1: hw_breakpoint: avoid UNPREDICTABLE behaviour when reading DBGDSCR
> * 40ef21c ARM: 6657/1: hw_breakpoint: fix ptrace breakpoint advertising on unsupported arch
> * 9e97118 ARM: ptrace: remove single-step emulation code
>
== Upstream oriented activities ==
* Review of Arnd Bergmann's flash card article for LWN.
* Incorporation of feedback to the patch adding Thumb2 support to the
P2V branch.
* Another look at the Thumb-2 compatibility fixes for OMAP from Dave
Martin.
* Review of a patch series adding support for SDHCI v3.00.
* Posted patches:
* Rework of the kernel decompressor code to improve efficiency
* Removal of the 4x expansion presumption while decompressing the kernel
* kprobes insn decoding fix
* Ignore mdesc->boot_params if out of range
* Fold lookup_machine_type() into setup_machine()
== Linaro kernel activities ==
* Looked at some bugs:
* Bug 660811
* Bug 720055
* Merged 2.6.37.1 into linaro-2.6.37
* Merged Dave Martin's Thumb2 compatibility patches for OMAP.
* Merged core ARM ffixes from RMK.
* Merged OMAP fixes from Tony Lindgren.
* Opened up the linaro-2.6.38 branch.
Nicolas
To everyone, and especially to those who are expected to work on this
topic next week, please find below a list of tasks that needs to be
investigated and/or accomplished. I'll coordinate the work and collect
patches for the team.
If you have comments on this, or if you know about some omissions,
please feel free to provide them as a reply to this message.
I'd like to know if people are particularly interested in one (or more :-))
items they would like to work on. If so please say so as well.
Without further ado, here it is:
<><><><><>
0) The so called "single zImage" project
We wish to provide the ability to build as many ARM platforms as
possible into a single kernel binary image. This will greatly simplify
the archive packaging and maintenance effort by having only one kernel
that could be built and booted on multiple ARM targets. A side effect
of this is also to enforce better source code architecture even if the
resulting binaries are not always supporting multiple targets.
This work started a while ago. Some initial description can be found
here:
https://wiki.ubuntu.com/Specs/ARMSingleKernel
Part of it has been implemented already, namely the runtime determined
PHYS_OFFSET, the AUTO_ZRELADDR and some other items referenced below.
But there is still a large amount of work remaining.
1) Removal of any dependencies on <mach/*.h> from generic header files
To see the current culprits:
$ git grep "#include <mach/.*.h>" arch/arm/include/
arch/arm/include/asm/clkdev.h:#include <mach/clkdev.h>
arch/arm/include/asm/dma.h:#include <mach/isa-dma.h>
arch/arm/include/asm/floppy.h:#include <mach/floppy.h>
arch/arm/include/asm/gpio.h:#include <mach/gpio.h>
arch/arm/include/asm/hardware/dec21285.h:#include <mach/hardware.h>
arch/arm/include/asm/hardware/iop3xx-adma.h:#include <mach/hardware.h>
arch/arm/include/asm/hardware/iop3xx-gpio.h:#include <mach/hardware.h>
arch/arm/include/asm/hardware/sa1111.h:#include <mach/bitfield.h>
arch/arm/include/asm/io.h:#include <mach/io.h>
arch/arm/include/asm/irq.h:#include <mach/irqs.h>
arch/arm/include/asm/mc146818rtc.h:#include <mach/irqs.h>
arch/arm/include/asm/memory.h:#include <mach/memory.h>
arch/arm/include/asm/mtd-xip.h:#include <mach/mtd-xip.h>
arch/arm/include/asm/pci.h:#include <mach/hardware.h> /* for PCIBIOS_MIN_* */
arch/arm/include/asm/pgtable.h:#include <mach/vmalloc.h>
arch/arm/include/asm/system.h:#include <mach/barriers.h>
arch/arm/include/asm/timex.h:#include <mach/timex.h>
arch/arm/include/asm/vga.h:#include <mach/hardware.h>
1.1) mach/memory.h
This may contain the following defines:
1.1.1) ARM_DMA_ZONE_SIZE
This can be eliminated by moving that value into struct machine_desc.
The work is done already, but presented as an example for other tasks:
http://git.linaro.org/gitweb?p=people/nico/linux.git;a=shortlog;h=refs/head…
And as of now this is merged in mainline already for v3.1-rc1.
1.1.2) PLAT_PHYS_OFFSET
Most occurrences can be eliminated. With CONFIG_ARM_PATCH_PHYS_VIRT, it
is possible to determine PHYS_OFFSET at run time. Remains to remove the
direct uses, mostly by mdesc->boot_params initializers. Changing
boot_params into atag_offset has two effects: that makes it clearer that
it is only about ATAGs and not DT, and a relative offset plays more
nicely with a runtime determined PHYS_OFFSET.
This work is done but not yet accepted:
http://news.gmane.org/group/gmane.linux.ports.arm.kernel/thread=123480
1.1.3) FLUSH_BASE, FLUSH_BASE_PHYS, FLUSH_BASE_MINICACHE, UNCACHEABLE_ADDR
Those are StrongARM related constants, and different for each variants.
Fixing this involves making the virtual addresses constant for all
variants, and hiding the differences in the physical addresses during
the actual mapping.
The solution is here:
http://news.gmane.org/group/gmane.linux.ports.arm.kernel/thread=123477/forc…
1.1.4) CONSISTENT_DMA_SIZE
Maybe the CMA work will make this obsolete and the consistent DMA area
could be dynamically adjusted. In the mean time, the easiest solution
is probably to store this in the machine_desc structure just like with
ARM_DMA_ZONE_SIZE.
This has not been addressed yet.
1.1.5) Other weird things
Some machines have non linear memory maps or bus address translations,
sparsemem, etc. Examples of that are:
arch/arm/mach-realview/include/mach/memory.h
arch/arm/mach-integrator/include/mach/memory.h
I think solving this is out of scope for this round. Deleting
arch/arm/mach-*/include/mach/memory.h can't be done universally. So a
new Kconfig symbol (NO_MACH_MEMORY_H) is introduced to indicate which
machine class has its legacy <mach/memory.h> file removed. The single
zImage for multiple targets will be restricted, amongst other things, to
those machines or SOCs with that symbol selected. Partial result here:
http://git.linaro.org/gitweb?p=people/nico/linux.git;a=shortlog;h=refs/head…
1.2) mach/io.h
This contains things like IO_SPACE_LIMIT, __io(), __mem_pci(), and
sometimes __arch_ioremap()/__arch_unmap(). but in most cases, the
definitions here are pretty similar from one machine class to another.
Arnd says:
|I have a plan. When CONFIG_PCI is disabled (along with CONFIG_ISA and
|CONFIG_PCMCIA), we should have neither of IO_SPACE_LIMIT, __io()
|and get no inb/outb functions as a result.
|
|When it is enabled, the 'common' platforms need only one I/O window
|of 64KB, so we should find a common place in the virtual address space
|for that and hardcode __io, while the platform specific PCI initialization
|code (or map_io for that matter) ensures that the window is pointing
|to the physical window.
|
|__arch_ioremap()/__arch_unmap() are not really needed as far as I can
|tell but are used as an optimization to redirect ioremap to the
|hardcoded virtal address mapping. In the first step we can disable
|this for combined kernels, later we can find a generic way so
|__arch_ioremap walks the list of static mappings.
1.3) mach/timex.h
Most instances simply define a dummy CLOCK_TICK_RATE value. This can
probably be removed altogether, or simply have a common value in
arch/arm/include/asm/timex.h, as nothing seriously uses that anymore.
Reference: http://lkml.org/lkml/2011/2/21/323
1.4) mach/vmalloc.h
This universally contains only a definition for VMALLOC_END, but not an
universal definition. Would be nice to have VMALLOC_eND dynamically
determined from the static IO mappings, but the highmem threshold
depends on the value of VMALLOC_END, and memory has to be initialized
before the static IO mappings can be processed.
Therefore the best solution so far appears to use another value in
struct machine_desc for it so it can be set at run time. this is a
mechanical conversion that has to be done.
1.5) mach/irqs.h
The only information globally required from those files is the value of
NR_IRQS. Yet there is already a nr_irqs member in the machine_desc
structure for this, used by arch_probe_nr_irqs() in
arch/arm/kernel/irq.c).
So the first step would be to add
.nr_irqs = NR_IRQS,
to all machine_desc instances, making sure that <mach/irqs.h> is
included in those files. Then, <mach/irqs.h> should be removed from
arch/arm/include/asm/irq.h, and adjust things so everything still
compiles.
1.6) mach/gpio.h
This is a tough one. This depends on CONFIG_GENERIC_GPIO which is
selected by many machine types. They should all be converted to (or
configurable with) CONFIG_GPIOLIB so each SOC's specific GPIO handling
is made into runtime code instead of static inline functions. Care to
preserve the ability to not use gpiolib might be desireable in some
cases for performance reasons.
Definitely in need of serious investigation.
1.7) mach/mtd-xip.h
No need to care about those. This is for running the kernel XIP from
ROM memory. A XIP kernel is already incompatible with the notion of a
single kernel image since it obviously can't be modified at run time (as
needed by CONFIG_ARM_PATCH_PHYS_VIRT).
1.8) mach/isa-dma.h, mach/floppy.h
Those are used by old targets we might not care much about.
1.9) mach/entry-macro.S
This one gets included directly from arch/arm/kernel/entry-armv.S.
The only relevant macro still widely used is get_irqnr_preamble and
get_irqnr_and_base. They can be overridden by CONFIG_MULTI_IRQ_HANDLER
and the equivalent code hooked to the handle_irq member of the
machine_desc structure.
1.10) mach/debug-macro.S
This is used when CONFIG_DEBUG_LL is set. Supporting that option with a
single kernel image might prove very difficult with a rapidly
diminishing return on the investment.
This code is in need of some refactoring already:
http://article.gmane.org/gmane.linux.ports.arm.kernel/118525
To still benefit from the most likely needed debugging aid, we might
consider the ability to still allow the selection of one amongst the
existing implementation when building a kernel with many SOC support.
Obviously that would only work on the one hardware platform for which the selected printch implementation was
designed, but that should be good enough for debugging purposes.
1.11) mach/system.h
This is included from arch/arm/kernel/process.c and expected to provide
the following static inline functions or equivalent:
1.11.1) arch_idle()
Called when system is idle. Most of them just call cpu_do_idle().
The call to cpu_do_idle() should be moved to default_idle() and the exception
cases moved out of line where they can be hooked to the pm_idle callback.
1.11.2) arch_reset()
Used to reset the system. This is far from being a hot path and doesn't
justify a static inline function. An out-of-line version hooked to a
global arch_reset function pointer would work just fine.
1.12) mach/uncompress.h
This is used to define per SOC methods to output some progress feedback
from the kernel decompressor over a serial port. Once again, supporting
this with a single kernel image might prove very difficult with a
rapidly diminishing return on the investment. So it is probably best to
simply use generic empty stubs whenever more than one SOC family is
configured in a common kernel image.
2) Removal of any dependencies on <mach/*.h> from driver code
A couple possibilities:
a) We move the required header files next to the driver code. In many
cases, having a .h file with only the defines relevant to the concerned
driver is best. But this is a _lot_ of work.
b) We change those <mach/foo.h> into something more absolute, such as
<mach/omap2/foo.h>. This can be done on a per SOC basis, first by
moving the header files one level deeper, and then fixing up all
affected drivers.
c) We change those <mach/foo.h> files into something more precise, e.g.
<mach/omap2_foo.h> and fix concerned drivers.
I think the best solution here is (b) which doesn't preclude (a)
eventually or if it is trivial. But (c) is dangerous as files might be
added easily without paying too much attention to the file prefix.
3) Change thes to the build system
We need to move towards the ability to actually build more than one SOC
family at the same time.
3.1) Kconfig
This involves changes to Kconfig where currently only one out of all the
different architectures is selected through the big "ARM system type"
choice prompt. We need to determine a good way to move some of them
into simply bool prompts and keep track of which architecture can be
built concurrently with which. We know for instance that it is unlikely
that pre-ARMv6 and ARMv6/7 will ever be buildable together. Today we
know that nothing can be built with anything else and therefore this
should be the starting default. This needs investigating.
3.2) Makefile
Currently the arch/arm/Makefile is organized so the lowest instruction
set level and the highest optimization level are selected from all the
configured options. So this part should already be fine.
However the machine-$(*), plat-$(*), machdirs and platdirs variables
must go. In (2) above we should have removed the need for adding to the
global KBUILD_CPPFLAGS to add a path to some specific architecture
includes already. Keeping them only for the code under each
architecture subdirectory should be sufficient.
For example, this might be all that is needed:
obj-$(CONFIG_ARCH_MSM) += mach-msm/
or
obj-$(CONFIG_ARCH_KIRKWOOD) += mach-kirkwood/ plat-orion/
obj-$(CONFIG_ARCH_ORION5X) += mach-orion5x/ plat-orion/
Etc.
And within each of these directories, using the subdir-ccflags-y
variable to include the locally needed architecture specific include
files will do the trick.
3.3) defconfig
We need a defconfig file adding as many architectures to it as possible
for build coverage. Ideally the resulting binary should be boot tested
on as many targets it supports as possible.
4) Picking up broken pieces
Things will certainly break along the way. There are certainly issues
that I didn't foresee. My experience so far tend to indicate that
this is a somewhat recursive process where the tackling of one work item
reveals a few more which are prerequisite to the first one, etc. So any
estimate for this work needs to consider a large fudge factor.
Nicolas
=== Highlights ===
* Work on blueprint "Investigate block allocation in FS"
I have now completed the flash simulation tool 'flashsim'.
Automated test cases have been run on all target file systems using
default options (but mounted with 'noatime'). Also, different standard
i/o schedulers were tried.
Work items completed:
- Implement algorithm "pure linear access": DONE
- Implement algorithm "block remapping within one erase-block": DONE
- Implement algorithm "data logging": DONE
- Implement algorithm "cache for small writes": DONE
=== Plans ===
* Attend Linaro Connect
=== Device Tree ===
* Arnd pulled i.mx driver device tree support patches for v3.1.
* Reworked smsc911x for getting gpio irq from irq domain as well.
* Reposted mx5 board dt patch set with i.mx51 babbage added.
=== Misc ===
* Boot-tested linaro-3.0 kernel on babbage and mx53 quickstart boards
=== Plan ===
* Linaro Connect
--
Regards,
Shawn
== Highlights ==
* I.MX51/53 u-boot mainline issue analysis and fix, patch ready.
This issue was caused
by d-cache was enabled silently by one commit, which will cause
various issue on all
ARM platform. The current fix is to disable D-cache explicitly
before the issues addressed.
* Review the imx_i2c rework driver and give some comments and test.
* study the one zImage information.
* Linaro Q3 connection preparation, visa, air ticket, hotel, register...
== Plans ==
* Linaro Q3 connection. Will focus on the 11.11 task
== issues ==
* N/A
=== Highlights ===
* Reviewed and merged Tglx's fixes for rtc/hrtimer related deadlock
* Merged musb patch needed for ADB into Linaro Android 11.07 tree. Also
got feedback from maintainer that the patch is queued for 3.1.
* Made Linaro Android 11.07 final tag.
* Got a hotel for Linaro Connect!
* Helped Paul diagnose RCU stall (actually a hardware issue)
* Setup and tested imx51 11.07 for Mounir
* Got feedback from Arve on my Android Alarm Timer mending patches.
Started reworking patches based on feedback.
* Prepped & packed for Linaro Connect.
=== Plans ===
* Linaro Connect!
* Focus on Kconfig work(eek! only 1 month until my Linux Plumbers talk!)
* Try another swing at sched_clock cyc2ns fixup for 200+day uptime
issue.
=== Issues ===
* Jet Lag!
== Thomas Abraham <thomas-ab> ==
=== Highlights ===
* Submitted patch for exynos4 irq controller device tree support.
* Tested all Exynos4 device tree patches with Grant's test-3.0 branch.
* Reworking gpio controller device tree support patch.
=== Plans ===
* Complete GPIO controller device tree support.
* Participate in Linaro connect event
* Discuss with dt team about doubts I have on dt implementation.
Hi all,
This is a slightly belated email with information about the overall plans for
next weeks face to face summit. As has been mentioned a few times,
the main focus for our time there is going to be hands on hacking
and we'll be splitting our focus between two main topics related to
kernel consolidation and cleanup:
Device Tree: Shawn, Manjunath, Thomas, and Niklas will continue to work
on device tree bring up on their platforms. Related to this, Grant will be
doing some training on Tuesday morning (Grant, correct me if I'm wrong)
for anyone who's interested in learning more about how to use DT.
Single zImage: The rest of the KWG will be focused on the task of
cleaning up the ARM kernel sources to allow for building a zImage
that can be booted across heterogeneous SOCs. Nicolas will
be sending off an email to linaro-kernel and linaro-dev with a
list of all the items that need to be worked on so please read
that and ask any questions you have. Our plan is to have folks
take on a topic and work on it, sending patches to Nicolas and
myself for real-time review. We likely will not have a kernel booting
across multiple machines but we should be much closer to
getting this working.
Monday morning at 11:00 we'll have a full team meeting and
we'll go over some of this in more detail. The kernel team
has been assigned room Trinity for the week and we will have
unlimited coffee and tea at our disposal to keep us going. :)
Arnd is presenting an advanced git training session on Tuesday
from 11:00-13:00 and there should be a lot of good tricks to learn!
We've also got a team dinner in Cambridge on Wed night, location TBD.
Beyond all that, I will be scheduling 1:1s with everyone
on the team. As per Linaro process, we're at the end of the
review cycle for most folks, so I'll go over your review with
you, get an update on where things are at with current tasks,
etc. I'll also setup some small team meets (storage, DT, etc) to
discuss next steps.
All together, this will be a busy week but should also be a lot
of fun to get a chance to all work in the same room and solve
some problems as a team.
Please fill out the following so we all know when to expect each
other and can coordinate travel:
https://wiki.linaro.org/Internal/Events/LinaroConnectQ3.11/Planning/BelfryT…
Thanks!
~Deepak
ps: Please bring all cables and power adapters you need for using your
boards. Linaro has certain items but not enough to go around for everyone.
The Linaro Kernel Working Group (KWG) is excited to announce the
availability our July 2011 development snapshot:
linux-linaro-3.0-2011.07-1
As the word "snapshot" implies, these are meant as development kernels
and have not been fully validated. You should expect issues and to help
us deliver a better kernel in the future, please file bugs in Launchpad at
https://bugs.launchpad.net/linux-linaro.
The source tarball is available at:
http://launchpad.net/linux-linaro/3.0/3.0-2011.07/+download/linux-linaro-3.…
The kernel sources can also be accessed using git at:
git://git.linaro.org/kernel/linux-linaro-3.0.git
tag: linux-linaro-3.0-2011.07-1
This snapshot is based on the 3.0 stable kernel with a number
of changes developed by Linaro and integrated from the 3.1-rc
cycle. The changes since our 11.07 release, other than what is
already in 3.0 include:
* The comprehensive ARM kprobes work from Jon (Tixy) Medhurst
* The new processor struct macros from Dave Martin
* A small part of the single zImage work from Nicolas Pitre
* The ARM cpu topology definition from Vincent Guittot
* Basic Cortex A15 support from Will Deacon & Pawel Moll
* DMA infrastructure cleanups from Russell King
* A kernel helper to perform 64-bit atomic operations from Nicolas Pitre
* Enhanced DT support for boards from Grant Likely, Shawn Guo,
Manjunath Kondaiah, and Thomas Abraham.
A full changelog against 3.0 is available at:
http://launchpad.net/linux-linaro/3.0/3.0-2011.07/+download/CHANGELOG-linux…
High Priority Known Issues:
* Only half of RAM useable when using Device Tree on Panda board
(LP #707047)
* Nicolas has run into EHCI not working on the Panda board. This
is a config issue and is being looked into.
Mailing list: http://lists.linaro.org/mailman/listinfo/linaro-dev
Questions? https://ask.linaro.org/
=== Device Tree ===
* Add device tree support for gpio-keys. Unfortunately, maintainer
chose to pick up another version.
* Add device tree probe support for imx2_wdt, mma8450, smsc911x, m25p
* arm/mx5: parse iomuxc pad configuratoin from device tree
* Convert i.mx53 ARD, EVK, QSB (aka LOCO) and SMD to device tree
=== Misc ===
* gpio/mxc/mxs: fix build error introduced by the reanming of irq_gc_ack()
* arm/mxc: add the missing UART_PADDR for i.mx53
* usb/ehci-mxc: add missing inclusion of mach/hardware.h
=== Plan ===
* Test linaro-3.0 kernel on i.mx boards
* Since Grant's devicetree for-next and Chris' mmc for-next has been
merged by Linus, it's time to repost other dt driver patches based
on that.
* Post device tree patches for i.mx51 boards (babbage and efika)
--
Regards,
Shawn
