I have moved the linux-linaro, linux-meta-linaro and u-boot-linaro git
trees on git.linaro.org out from under my directory to their own
directories to make it obvious that they are official trees and not my
personal development trees.
The lnux and linux meta trees are now:
git://git.linaro.org/linux-linaro/linux-linaro.git
and
git://git.linaro.org/linux-linaro/linux-meta-linaro.git
The u-boot tree is now:
git://git.linaro.org/u-boot-linaro/u-boot-linaro-next.git
As the -next implies, this tree has branches that get rebased
periodically to current upstream plus extra patches.
We will soon have a -stable tree based on a recent official upstream
release. My preferred plan for our first -stable tree is for it to be
based on the upcoming v2010.09 upstream release. The anticipated
release date for v2010.09 is September 12, 2010. If this proves to be
too late then we will base the first stable release on a v2010.09-rcN
release or on v2010.06 plus cherry-picked patches.
Questions/comments are welcome.
Thanks,
John
The weekly report for the Linaro Infrastructure team may be found at:
Status report: https://wiki.linaro.org/Platform/Infrastructure/Status/2010-08-12
Burndown chart: http://people.canonical.com/~pitti/workitems/maverick/arm-infrastructure.ht…
Progress:
* LEP/DerivativeDistributions: Backend work under way. UI mockups look
good. User testing should be finished early next week, and then
frontend implementation will start.
* arm-m-private-archive-hosting-infrastructure: Navigation work
completed in vostok. Work to allow custom images. Basic preparation
for implementing new views in vostok. Plugging away at work items.
* arm-m-derived-archive-rebuild: Slow progress on the archive deletion
due to detailed DB work, and slow turnaround for checking changes when
doing DB work.
* arm-m-image-building-tool: Blueprint's one remaining work item
postponed. Blueprint now complete.
* arm-m-image-building-console: Working on getting several branches
landed. All security reviews complete, no surprises. New name for
release to be chosen by beta time. Started talking about
documentation. Postponed anything not necessary for open sourcing.
* arm-m-automated-testing-framework: License approved. Added support
for subcommands. Looking at test suites and benchmarks with eye to
correctness on ARM and inclusion in the test framework.
* arm-m-validation-dashboard: License approved. Working on getting
changes landed. Will start new work items when this happens.
* hardware-packs: New spec.
https://wiki.linaro.org/Platform/UserPlatforms/Specs/10.11/HardwarePacks.
Spec done, implementation to start next week.
Cheers,
Scott
--
Scott Bambrough <scott.bambrough(a)linaro.org>
Linaro Infrastructure Team Lead
On 08/20/2010 08:05 AM, Alexander Sack wrote:
> On Fri, Aug 20, 2010 at 4:01 PM, Tim Gardner<tim.gardner(a)canonical.com>wrote:
>
>> On 08/20/2010 03:20 AM, Alexander Sack wrote:
>>
>>> Hi,
>>>
>>> sorry (Tim) for this mess, but its a ramp up thing and we finally agreed
>>> what we really want.
>>>
>>> so we talked about our meta package naming and partly because of
>>> infrastructural requirements from live-helper, but also partly because we
>>> think its more consistent we would need the following changes to the
>>> linaro
>>> meta package naming:
>>>
>>> 1. Source: change to linux-meta-linaro
>>> 2. Binaries:
>>> Rename: linux-linaro-image-omap to linux-image-linaro-omap
>>> Rename: linux-linaro-image-vexpress to linux-image-linaro-vexpress
>>> 3. Headers:
>>> Rename: linux-linaro-headers-omap to linux-headers-linaro-omap
>>> Rename: linux-linaro-headers-vexpress to linux-headers-linaro-vexpress
>>>
>>> in this way the binaries/headers would be consistent with the current
>>> "normal" naming scheme that is: linux-image-$flavour ... with flavour
>>> being
>>> "linaro-X" for everything that gets produced from linaro tree this cycle.
>>>
The upshot of these change requests are:
1) The Linaro kernel meta package source name is changing from
linux-linaro-meta to linux-meta-linaro.
2) The meta package binary names are changing from linux-linaro-image*
to linux-image-linaro*. Similarly for headers packages, e.g.,
linux-linaro-headers* to linux-headers-linaro*
If you are a consumer of Linaro ARM images _and_ you are planning an
upgrade, then this _will_ affect you. If you are installing images from
scratch after this change is implemented, then you're likely OK.
This change will definitely require a change in the installer.
rtg
--
Tim Gardner tim.gardner(a)canonical.com
Hi all,
Lorenzo has posted his Versatile Express fdt support work to the
devicetree-discuss mailing list, copied below.
Be aware that this is still under discussion upstream, and very much a
work in progress. There may be significant rebasing / fixes... so
don't rely on it to be stable ;)
Cheers
---Dave
> -----Original Message-----
> From: Lorenzo Pieralisi
> Sent: 18 August 2010 20:00
> To: devicetree-discuss(a)lists.ozlabs.org; grant.likely(a)secretlab.ca
> Cc: linux(a)arm.linux.org.uk; nico(a)fluxnic.net; Catalin
> Marinas; Philippe Robin; jeremy.kerr(a)canonical.com
> Subject: [RFC PATCH 00/14] Versatile Express device tree port
>
> This patchset provides an initial version of device tree
> enabled kernel on an ARM Versatile Express board. The
> patchset applies to Jeremy Kerr's tree:
>
> git://kernel.ubuntu.com/jk/dt/linux-2.6.git dtbimage
> commit: 4cb80ac96489220554d28f6fde527aeef83e628b
>
> The patched kernel version is available on my public ARM git tree:
>
> git://linux-arm.org/linux-2.6-lp.git ve-fdt
>
> It has been tested on HW ARM Versatile Express board, with
> both static and DT configurations.
>
> It contains fixes for generic device tree features and clock
> configuration, code to patch Versatile Express peripherals
> drivers and build system.
>
> Clock names as well as amba device names are temporary
> waiting for OF bindings definition (clocks).
> The Versatile Express board specific init code has been split
> into DT and non-DT code in order to factor out common code
> between the two configs.
>
> A static inline function has been added to the platform bus
> in order to initialize the OF match table and avoid
> cluttering code with preprocessor macros.
>
> Drivers ( and GIC, sp804, PL310 specific code) device tree
> init is an initial stab at configuring peripherals with
> device tree data, so some choices especially concerning error
> codes are arguable and require thorough review.
>
> The whole patchset is a request for comments on code and methodology.
>
> Cheers.
>
> Lorenzo Pieralisi (14):
> ARM: amba device memory allocation fix
> ARM: vexpress: fix clocks definition to comply with new framework
> ARM: fix add instruction to set the flags
> ARM: r1 DT mach id init
> ARM: vexpress: fix typo in addruart
> platform: add function to initialize OF match table
> drivers/smsc911x: add DT support
> ARM: versatile-i2c driver DT port
> ARM: ARM flash driver DT port
> drivers/USB: isp1760 DT platform parsing and binding
> ARM: PMU: add device tree probing
> ARM: vexpress: add board support for DT probing
> ARM: vexpress: Definition of vexpress dts specification
> ARM: vexpress: add device tree build system and dtbuImage
>
> arch/arm/Kconfig | 4 +-
> arch/arm/Makefile | 2 +-
> arch/arm/boot/Makefile | 10 +-
> arch/arm/boot/dt/dtb.S | 3 +
> arch/arm/boot/dts/vexpress.dts | 199 +++++++++++++++++++++
> arch/arm/include/asm/pmu.h | 6 +
> arch/arm/kernel/Makefile | 3 +-
> arch/arm/kernel/head.S | 2 +-
> arch/arm/kernel/pmu-of.c | 30 +++
> arch/arm/kernel/pmu.c | 18 ++-
> arch/arm/mach-vexpress/Kconfig | 7 +
> arch/arm/mach-vexpress/Makefile | 5 +-
> arch/arm/mach-vexpress/core.h | 15 ++-
> arch/arm/mach-vexpress/ct-ca9x4-base.c | 108 +++++++++++
> arch/arm/mach-vexpress/ct-ca9x4-of.c | 192 ++++++++++++++++++++
> arch/arm/mach-vexpress/ct-ca9x4.c | 93 ----------
> arch/arm/mach-vexpress/include/mach/clkdev.h | 2 +-
> arch/arm/mach-vexpress/include/mach/ct-ca9x4.h | 2 +
> arch/arm/mach-vexpress/include/mach/debug-macro.S | 2 +-
> arch/arm/mach-vexpress/v2m-base.c | 197 ++++++++++++++++++++
> arch/arm/mach-vexpress/v2m-of.c | 94 ++++++++++
> arch/arm/mach-vexpress/v2m.c | 167 +-----------------
> arch/arm/mm/Kconfig | 2 +-
> drivers/amba/bus.c | 2 +-
> drivers/i2c/busses/i2c-versatile.c | 6 +
> drivers/mtd/maps/integrator-flash.c | 6 +
> drivers/net/Makefile | 3 +-
> drivers/net/smsc911x-of.c | 53 ++++++
> drivers/net/smsc911x.c | 28 ++-
> drivers/net/smsc911x.h | 8 +
> drivers/usb/host/Makefile | 4 +-
> drivers/usb/host/isp1760-hcd.h | 7 +
> drivers/usb/host/isp1760-if.c | 43 +++--
> drivers/usb/host/isp1760-of.c | 36 ++++
> include/linux/platform_device.h | 11 ++
> 35 files changed, 1067 insertions(+), 303 deletions(-)
> create mode 100644 arch/arm/boot/dts/vexpress.dts create
> mode 100644 arch/arm/kernel/pmu-of.c create mode 100644
> arch/arm/mach-vexpress/ct-ca9x4-base.c
> create mode 100644 arch/arm/mach-vexpress/ct-ca9x4-of.c
> create mode 100644 arch/arm/mach-vexpress/v2m-base.c create
> mode 100644 arch/arm/mach-vexpress/v2m-of.c create mode
> 100644 drivers/net/smsc911x-of.c create mode 100644
> drivers/usb/host/isp1760-of.c
>
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss(a)lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
Tim,
By changing the name of the linaro linux meta package to have linaro
at the end we can run the image builder with out modification. This
patch also takes into account the flavour name changes in the latest
linaro kernel pull request. In the process I re-wrote some history
rewriting so the basis is Ubuntu-2.6.35.15.16:
The following changes since commit 7b6185a7652f8309dcf9a46b96766b29bf33f338:
Leann Ogasawara (1):
UBUNTU: Ubuntu-2.6.35.15.16
are available in the git repository at:
git://git.linaro.org/jcrigby/linux-meta-linaro.git master
John Rigby (2):
LINARO: Linaro-2.6.35.1000.1
LINARO: Linaro-2.6.35.1001.2
Tim Gardner (1):
Dropped linux-source, linux-linaro-omap, linux-linaro-vexpress
Makefile | 4 +-
meta-source/debian/changelog | 502 +-----------------------------
meta-source/debian/control.common | 51 +---
meta-source/debian/control.d/generic | 47 ---
meta-source/debian/control.d/generic-pae | 47 ---
meta-source/debian/control.d/omap | 17 +-
meta-source/debian/control.d/server | 47 ---
meta-source/debian/control.d/versatile | 26 --
meta-source/debian/control.d/vexpress | 17 +
meta-source/debian/control.d/virtual | 26 --
10 files changed, 30 insertions(+), 754 deletions(-)
delete mode 100644 meta-source/debian/control.d/generic
delete mode 100644 meta-source/debian/control.d/generic-pae
delete mode 100644 meta-source/debian/control.d/server
delete mode 100644 meta-source/debian/control.d/versatile
create mode 100644 meta-source/debian/control.d/vexpress
delete mode 100644 meta-source/debian/control.d/virtual
Hi all,
tomorrow at 1300 UTC User Platforms team will have their weekly status
meeting in #linaro-meeting on freenode.
The proposed agenda is available on the status page:
+ https://wiki.linaro.org/Platform/UserPlatforms/WeeklyStatus/2010-08-18
Notes and actions will be posted to the same page after the meeting.
Remember to add your agenda items to the "Agenda Additions" section
and add your weekly status report to the page before the meeting.
For the record, last weeks notes and actions are available here:
+ https://wiki.linaro.org/Platform/UserPlatforms/WeeklyStatus/2010-08-12
Thanks,
--
- Alexander
Hi Amit and fellows in PM group,
After invistigating both freescale's DVFS driver and cpufreq driver, I got
some conclusion.
The hw-based governor could be designed in the way just like what the
performace or powersave governor did, which simply provide interfaces
CPUFREQ_GOV_START and CPUFREQ_GOV_STOP. That means this governor is only
responsible to turn the DVFS on or off, and leave the rest work to cpufreq
driver itself. Of course, to do so, we need add some code in the cpufreq
driver to handle DVFS interrupt and report the updated frequency in cpufreq
system.
At code level, one more file could be add for hw-based governor. And some
new fields needs to be added into those cpufreq related structures in order
to glue the newly added governor and cpufreq driver.
Do you guys have any more ideal?
Yong
The next big thing for the Toolchain WG is sending patches upstream
and beginning to track patches in general. Some of the use cases are:
* Do a change upstream in 4.7, backport it to our 4.5, and backport
it to our 4.6 when we make one
* Do a change locally, track where it lands upstream, and figure out
what we have to bring forward when we next rebase
* Track what is Linaro specific and can't go upstream so we know what
to bring forward
I'm currently planning to use the Launchpad bug tracker and some
custom reports to manage this. It's important that we don't lose any
patches.
Does anyone else have similar requirements, use for such a tool, or
know of tools that already cover this?
-- Michael
