Hi
I would like to request a working ".config" file for Gumstix
Overo Tide COM board to cross compile a custom kernel
with Linaro/Ubuntu compiler as I have lost my config file
for a customized kernel. I tried using linaro-media-create
to use the overoxxx.config file from /media/rootfs/boot/ but
coping that as .config file to build an uImage does not work.
I tried omap3-defconfig but it does not work, I will be glad
to receive a .config file that can be used to cross compile
an uImage image to boot my kernel. Thanks in advance.
Sincerely
Aung
Hi,
A little bit later than usual, but here it goes the announcement of
the 12.03 RC images. This time we got a bit delayed because we're
finally generating and maintaining all the kernel packages ourself,
and getting them in sync with Launchpad is something that still needs
some improvement.
This release should be the last one based on Ubuntu Oneiric (and
ARMEL), including the latest XBMC release and the usual kernel and
package updates. From 12.04 on we will be supporting only builds based
on Ubuntu Precise (12.04, ARMHF), so we should see quite many nice
improvements there (for early access, check the builds at
https://ci.linaro.org/jenkins/view/Ubuntu%20Build%20Service/).
You can find our current test cases at
https://wiki.linaro.org/Platform/QA/TestCases/Ubuntu, and the 12.03 RC
builds (for all boards and image flavors) at
http://snapshots.linaro.org/oneiric/, with build id 20120327-1 for
hwpacks and 20120327-0 for the rootfs (nano, developer, alip,
ubuntu-desktop and linaro-tv-xbmc).
For our main boards we also have a testing spreadsheet, were we
publish the official release testing, done by the dev platform
engineers. You can find the links at
https://wiki.linaro.org/Platform/DevPlatform/Testing (note that you
can find the bug reports from the test cases by looking at the QA page
tag links).
Fathi will be coordinating all respin requests in the next following
days at linaro-release m-l, and the final image will be published this
thursday, at releases.linaro.org.
Please also be sure to publish any bug report with the RC images
against https://launchpad.net/linaro-ubuntu, or just contact us at
#linaro @ freenode.
Thanks,
--
Ricardo Salveti de Araujo
The common clock framework defines a common struct clk as well as an
implementation of the clk api that unifies clock operations on various
platforms and devices.
The net result is consolidation of many different struct clk definitions
and platform-specific clock framework implementations.
This series is the feature freeze for the common clock framework.
Unless any major bugs are reported this should be the final version of
this patchset. Now is the time to add any acked-by's, reviewed-by's or
tested-by's. I've carried over the *-by's from v6; I hope everyone is
OK with that.
Big thanks to Sascha Hauer for his changes to clk_set_rate in this
version.
Major changes since v6:
* clk_set_rate rewritten to set clock rates from top-to-bottom
* should also reduce pre-rate change notifier noise (thanks Sascha)
* fixed up clk_divider's .round_rate logic (thanks Sascha)
* removed useless locking around basic clock types
* fixed return types for __clk_get_(enable|prepare)_count
* some NULL pointer fixes for handling .parent_names and .parents
* removed unnecessary checks for recursive calls in a few helpers
* made __clk_round_rate more sane and aligned with clk_round_rate
* parent rates are returned if .round_rate is not implemented
* fixed CONFIG_COMMON_CLK_DEBUGFS to select DEBUG_FS
* rebased onto Linus' v3.3-rc7 tag
Major changes since v5:
* removed redundant HAVE_CLK_PREPARE in Kconfig
* new CONFIG_COMMON_CLK_DISABLE_UNUSED feature
* results in a new clk_op callback, .is_enabled
* standardized the hw-specific locking in the basic clock types
* export the individual ops for each basic clock type
* improve registration for single-parent basic clocks (thanks Sascha)
* fixed bugs in gate clock's static initializers (thanks Andrew)
* overall improvements to Documentation/clk.txt
* rebased onto Linus' v3.3-rc6 tag
Major changes since v4:
* rolled in TGLX's comments on overall design. We now have,
* proper handling of root clocks and orphan clocks
* multi-parent clocks are handled in the core
* struct clk is shielded from struct clk_foo and vice versa
* this is a return to the previous struct clk_hw design
* split basic clock types out into separate files
* split headers up by purpose
* clk.h remains the driver-level interface
* declarations for rate change notifiers are the only additions
* clk-provider.h is primary header for implementing clock operations
* clk-private.h allows for static initialization of clock data
* validation and bug fixes
* rebased onto Linus' v3.3-rc5 tag
Patches can be pulled from:
git://git.linaro.org/people/mturquette/linux.git v3.3-rc7-clkv7
v6 can be found at,
http://article.gmane.org/gmane.linux.kernel/1265022
v5 can be found at,
http://article.gmane.org/gmane.linux.kernel/1261472
v4 can be found at,
http://article.gmane.org/gmane.linux.linaro.devel/8896/
v3 can be found at,
http://article.gmane.org/gmane.linux.kernel/1218622
Mike Turquette (3):
Documentation: common clk API
clk: introduce the common clock framework
clk: basic clock hardware types
Documentation/clk.txt | 233 +++++++
drivers/clk/Kconfig | 40 ++
drivers/clk/Makefile | 2 +
drivers/clk/clk-divider.c | 200 ++++++
drivers/clk/clk-fixed-rate.c | 82 +++
drivers/clk/clk-gate.c | 150 +++++
drivers/clk/clk-mux.c | 116 ++++
drivers/clk/clk.c | 1461 ++++++++++++++++++++++++++++++++++++++++++
include/linux/clk-private.h | 196 ++++++
include/linux/clk-provider.h | 300 +++++++++
include/linux/clk.h | 68 ++-
11 files changed, 2843 insertions(+), 5 deletions(-)
create mode 100644 Documentation/clk.txt
create mode 100644 drivers/clk/clk-divider.c
create mode 100644 drivers/clk/clk-fixed-rate.c
create mode 100644 drivers/clk/clk-gate.c
create mode 100644 drivers/clk/clk-mux.c
create mode 100644 drivers/clk/clk.c
create mode 100644 include/linux/clk-private.h
create mode 100644 include/linux/clk-provider.h
--
1.7.5.4
Hi there. The GCC build time is approaching 24 hours and our five
Panda boards can't keep up. Sounds like a good time to LAVAise the
toolchain build process a bit more...
Mike Hudson and I talked about doing a hybrid LAVA/cbuild as a first
step where LAVA manages the boards and cbuild does the build. The
idea is:
* There's a image with the standard toolchain kernel, rootfs, build
environment, and build scripts
* The LAVA scheduler manages access to the boards
* The LAVA dispatcher spins up the board and then invokes the cbuild
scripts to build and test GCC
This gives me a fixed environment and re-uses the existing build
scripts. In the future these can be replaced with different LAVA
components. There's a few details:
* cbuild self updates on start so the image can stay fixed
* Full results are pushed by cbuild to 'control'
* The dispatcher records the top level log and an overall pass/fail
* No other bundles are generated
Most of this fits in with the existing LAVA features. There's a few
additions like a 'run command' JSON action, passing the board name to
the instance, and passing the job name as an argument. These seem OK.
I'd like some of the boards to be fitted with fast USB flash drives
for temporary storage. SD cards are slow and unreliable especially
when GCC is involved.
Thoughts?
-- Michael