linaro-dev April 2012

linaro-dev@lists.linaro.org

113 participants
85 discussions

by Zach Pfeffer

While we're planning for connect, I'd like to suggest that we do away with team tracks all together and just have topic tracks. This would align with our topic based approach to things now, and would be a way to breakdown our silo's. The topic track would be lead by a topic champion. What do people think? -- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

13 years

[PATCH 00/18][V3] ARM: OMAP3/4 : cpuidle34xx and cpuidle44xx cleanups

by Daniel Lezcano

This patchset makes some cleanup on these cpuidle drivers and consolidate the code across both architecture. Tested on OMAP3 (igepV2). Partially tested on OMAP4 (pandaboard), without offlining the cpu1. V3 : * replace OMAP4_NUM_STATES and OMAP3_NUM_STATES by ARRAY_SIZE * Fixed changelog * Fixed OMAP4_NUM_STATES going back and forth in the patchset * Removed erratum check at init time V2 : * Fixed a couple of typos in the patch description V1 : Initial Post Daniel Lezcano (18): ARM: OMAP4: cpuidle - Remove unused valid field ARM: OMAP4: cpuidle - Declare the states with the driver declaration ARM: OMAP4: cpuidle - Remove the cpuidle_params_table table ARM: OMAP4: cpuidle - fix static omap4_idle_data declaration ARM: OMAP4: cpuidle - Initialize omap4_idle_data at compile time ARM: OMAP4: cpuidle - use the omap4_idle_data variable directly ARM: OMAP4: cpuidle - remove omap4_idle_data initialization at boot time ARM: OMAP3: cpuidle - remove rx51 cpuidle parameters table ARM: OMAP3: define cpuidle statically ARM: OMAP3: cpuidle - remove errata check in the init function ARM: OMAP3: cpuidle - remove the 'valid' field ARM: OMAP3: cpuidle - remove cpuidle_params_table ARM: OMAP3: define statically the omap3_idle_data ARM: OMAP3: cpuidle - use omap3_idle_data directly ARM: OMAP3: cpuidle - simplify next_valid_state ARM: OMAP3: set omap3_idle_data as static ARM: OMAP3/4: consolidate cpuidle Makefile ARM: OMAP3: cpuidle - set global variables static arch/arm/mach-omap2/Makefile | 11 +- arch/arm/mach-omap2/board-rx51.c | 38 +++--- arch/arm/mach-omap2/cpuidle34xx.c | 306 +++++++++++++++---------------------- arch/arm/mach-omap2/cpuidle44xx.c | 134 +++++++---------- arch/arm/mach-omap2/pm.h | 38 ++--- 5 files changed, 212 insertions(+), 315 deletions(-) -- 1.7.5.4

13 years

pull build configs into Git.

by Zach Pfeffer

Fathi, Since we're at the start of 12.05 we need to shift the builds over to the tip toolchain and stop daily builds for various baselines. I figure we can also get the configs into git. Do you want to take care of getting the current configs into git and then shift the builds or the other way around? For 12.05 I'd kill all dailies except for the tips listed on android-build.linaro.org under: "Users who are interested in tip builds with Linaro goodness should use:" People can always re-enable dalies they're interested in. -- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

13 years

Quantal open for development

by Matthias Klose

Quantal is now open for development, with syncs from unstable starting shortly. The development version starts with updated versions of GCC and OpenJDK, some soname changes (boost, hdf5), and some changes with setting the build flags for package builds. We are finally targeting Python3 as the only Python version on the ISO/installation images. - GCC 4.7 is now the default, introducing some build failures caused by unknown compiler options, and more C++ strictness. Hints how to fix packages can be found at [1]. Bug reports for packages are not yet filed directly in Launchpad, but can be found on the Debian BTS instead [2]. - OpenJDK 7 is now used as the default, replacing OpenJDK 6, introducing some build failures. The build status can be tracked at [3], open issues are tracked at [4]. - Removing build flags exported from dpkg-buildpackage for quantal will get us in sync with Debian. Implications and fixes are discussed on the ubuntu-devel ML [5]. - Python 3 is now again part of a minimal chroot on quantal, and will be the only Python version provided on the ISO/installation images for quantal. Packages which need updates and ports for Python 3 are tracked at [6] Please check your uploads in a quantal chroot, don't just test in a precise environment. See [7] how to setup such a development chroot. [1] http://gcc.gnu.org/gcc-4.7/porting_to.html [2] http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-gcc-4.7;users=debian… [3] https://wiki.ubuntu.com/JavaTeam/Java7Default [4] https://bugs.launchpad.net/ubuntu/+bugs?search=Search&field.bug_reporter=ja… [5] https://lists.ubuntu.com/archives/ubuntu-devel/2012-April/035149.html [6] https://wiki.ubuntu.com/Python/FoundationsQPythonVersions [7] https://wiki.ubuntu.com/DebootstrapChroot

13 years, 1 month

Re: linaro-announce post from tim@eclectronics.org requires approval

by Fathi Boudra

Hi, > ---------- Forwarded message ---------- > From: Tim Redfern <tim(a)eclectronics.org> > To: linaro-announce(a)lists.linaro.org > Date: Sun, 29 Apr 2012 22:25:32 +0100 > Subject: re: Linaro 12.04 released > Hi I have a question, > > Will there be a community build of linaro for gumstix overo (as with > previous versions) ? > > Or was overo dropped for some reason? With the switch to Ubuntu Precise/armhf, several builds were broken or untested (LAVA was offline). That's the main reasons why BeagleBoard or Overo hasn't been published. Assuming we have a working, tested build and a sponsor, they'll be back. Cheers, -- Fathi Boudra Linaro Release Manager | Validation Project Manager Linaro.org | Open source software for ARM SoCs

13 years, 1 month

won't someone please think of the users!?

by Clark, Rob

just some random thoughts on our release model, etc.. I've been meaning to write up for a while but haven't had time There has been some feedback, for example on #pandaboard, that the monthly release cycle is confusing and detrimental for folks looking for something working and stable, and not necessarily bleeding edge, the question is, "should I upgrade?", "what is fixed and what is now broken?". Linaro is doing some great upstream work, and enabling features on these boards, and it is good to showcase that, but I'm not really sure the best way to do this is rush that into the next monthly release and break things for all the new users of their shiny new xyz-board. I tend to think that part of the problem is that the cadence of monthly releases is too fast for any sort of stability. Perhaps we should think more along the lines of releases roughly every quarter (potentially with "beta"s in between). I don't think we should strictly adhere to a time based release cycle, but we should call it a final/stable release when it actually is so. There is a reason that the linux kernel uses an approx 3 month release cycle, but doesn't stick to that dogmatically when things aren't really at release quality yet. But, we do still need a place for latest-and-greatest bleeding edge for folks who want to check out what we are working on. One approach, for example for ubuntu releases, we could have a "release" and "trunk" PPA for bleeding-edge.. that way folks looking for bleeding-edge can get it, and folks looking for "it just works" are not screwed. I'm not quite sure what android equivalent would be, but I guess we could figure something out. This gives folks in board specific channels like #pandaboard who are trying to help new users something to reliably point them at without having to worry if they are giving bad advice to recommend a linaro filesystem. And updates do not have to be tied to a time-based schedule. If something is broken for feature x for board y in the release PPA, then as soon as it is fixed (and if it doesn't break board z), then push an update to the release PPA. But maybe big new features shouldn't immediately go to the release PPA without some soak time first in the trunk PPA. It is great to be enabling new features, but for someone new to the arm platform I don't want to just frustrate and scare them off. Also, I wonder if we should split #linaro, either into #linaro-devel and leave #linaro as a place that users can come to for help, or setup a separate #linaro-users? This way we aren't just dumping out new releases with nowhere for users to turn to for help.. (Well, they can always come to #linaro but I guess this would help with the signal-to-noise..) BR, -R

13 years, 1 month

[PATCH 00/13] common clk framework misc fixes

by Mike Turquette

This series collects many of the fixes posted for the recently merged common clock framework as well as some general clean-up. Most of the code classifies as a clean-up moreso than a bug fix; hopefully this is not a problem since the common clk framework is new code pulled for 3.4. Patches are based on v3.4-rc2 and can be pulled from: git://git.linaro.org/people/mturquette/linux.git v3.4-rc2-clk-fixes Please let me know I missed any critical fixes that were posted to the list already. Arnd & Olof, if there are no objections to these changes can this get pulled through the arm-soc tree? Thanks, Mike Mark Brown (2): clk: Remove comment for end of CONFIG_COMMON_CLK section clk: Constify parent name arrays Mike Turquette (6): clk: core: correct clk_set_rate kerneldoc clk: core: remove dead code paths clk: core: clk_calc_new_rates handles NULL parents clk: core: enforce clk_ops consistency clk: core: copy parent_names & return error codes clk: basic: improve parent_names & return errors Rajendra Nayak (1): clk: Make clk_get_rate() return 0 on error Shawn Guo (4): clk: use kzalloc in clk_register_mux clk: remove unnecessary EXPORT_SYMBOL_GPL clk: add "const" for clk_ops of basic clks clk: declare clk_ops of basic clks in clk-provider.h drivers/clk/clk-divider.c | 51 +++++++++---- drivers/clk/clk-fixed-rate.c | 57 +++++++++------ drivers/clk/clk-gate.c | 53 ++++++++++----- drivers/clk/clk-mux.c | 16 +++-- drivers/clk/clk.c | 159 ++++++++++++++++++++++++++--------------- include/linux/clk-private.h | 14 +--- include/linux/clk-provider.h | 13 ++-- include/linux/clk.h | 2 +- 8 files changed, 230 insertions(+), 135 deletions(-) -- 1.7.5.4

13 years, 1 month

Linaro U-Boot 12.04 released

by John Rigby

Version 12.04 of Linaro U-Boot has been released. Details on Launchpad here: https://launchpad.net/u-boot-linaro/trunk/12.04 And on git.linaro.org here: http://git.linaro.org/gitweb?p=boot/u-boot-linaro-stable.git;a=shortlog;h=r… >From the release notes: This release is primarily a rebase onto the latest upstream git.denx.de release v2012.04. Several patches that have been carried in u-boot-linaro have been dropped because that functionality has gone upstream. This includes OMAP[345] usb support including network support on Panda and Beagle xM and the Highbank support from Calxeda. This release continues to include some Snowball support but not enough to be usable. This release also still requires the cache disabling patch for OMAP3 that has been carried for months but upstream remains broken with Linaro kernels without it. See Changelog for list of all patches to v2012.04. Here are the Linaro patches on top of upstream v2012.04: 0b07b6e PXE: OMAP4: add standard env vars 9f4c29c arm: omap4_panda: Enable pxecfg support 948aae2 SAUCE: OMAP4 Make pxe boot fallback default boot 21c1a80 OMAP3: Beagle: Add standard addresses to env c448146 OMAP3: Beagle: Enable PXE support 84d1169 OMAP3: igep0020: Enable PXE support 1f18000 MX53LOCO: Enable PXE boot efa46fe ARM: vexpress: move files in preparation for adding a new platform 6721629 ARM: vexpress: create A9 specific board config 3dbbeb8 ARM: vexpress: create A5 specific board config b4673ba ARM: vexpress: Change maintainer for ARM Versatile Express platforms 8366422 ARM: vexpress: Extend default boot sequence to load script from MMC f412e91 net: allow setting env enetaddr from net device setting 9ac3e2d ARM: highbank: add autoboot script files de80572 ARM: highbank: update autoboot bootdelay value 5c7d44e Add a default env that will use boot.scr from the vfat partition d74b1a8 Origen: Enable CONFIG_OF_LIBFDT ed3b575 MMC: arm_pl180_mmci: allow multiple devices 6185c31 mx53loco: define ERRATUM_ESDHC111 1b02df5 mx5: Add clock config interface 2fd31d5 mx53loco: PMIC: Add dialog pmic support c450b5d mx53loco: Add power init support bfc8de9 mx53loco: workaround VPU TO2 Errata by increasing peripheral voltage 459a66c mx53loco: add support for MC34708 996306c arm: imx6q: add axi cache and qos setting 7ebf30e arm: imx6q: add anatop regulator init 67db864 fec_mxc: increase autonegotiation timeout 5a67a40 fec_mxc: move autonegoatiate restart after mii_postcall a7f6854 OMAP4: avoid null pointer access in save_boot_params b66a9b6 OMAP4: Make mmc and fat conditional in spl f388f20 OMAP4: Panda: Add usb peripheral boot 06fb246 OMAP4: Panda: Add USB_SPL variant 1631036 OMAP4: Force PXE booting when booting via spl-usb 4c62942 snowball: igloo copy port of armv7/u8500 and include/asm/arch-u8500 f68b175 snowball: igloo copy port of gpio driver support 2afb10a snowball: add snowball to boards.cfg 9053991 snowball: igloo copy port of board specific files 602bef8 snowball: arm cpu: inv and clean of L2 e3e64ab HACK: Copy in alternate mmc files for snowball c64a8a5 HACK: Bypass normal mmc if CONFIG_SNOWBALL_MMC_HACK 90b88ef debugX to debug 368cfd9 SAUCE: Snowball: init serial later aca528b PXE: look for usbethaddr if no ethaddr f1ed411 OMAP4 Panda: Generate a unique usbethaddr 923c7d8 OMAP3: Beagle: add back boot.scr support 9b2844c OMAP4: Panda: add uEnv.txt support 047161d OMAP4: Enable command line editing in omap4_common.h 554498e OMAP4: change MAXARGS to 32 46e0a24 OMAP3: Enable command line editing for omap3_beagle 1bf66b5 Allow loading of u-boot.bin for backward compatibility 9e97fcb OMAP3: Beagle: set mac addr from dieid 0a957f5 SAUCE: HACK: move omap spl base address 1551b1a OMAP4: add preEnv.txt support d4f7dc9 OMAP3 Beagle: add preEnv.txt support 05613f5 Revert "arm: Add Prep subcommand support to bootm" 6f8db25 Revert "armv7: adapt omap3 to the new cache maintenance framework"

13 years, 1 month

Screen sizes for a tablet device - Not related application development.

by Venkat Raghavulu

Hello All, I need some help, checked the android documentation and related area, did not get a solution. This is on screen size for tablet devices during the boot stage. Problem statement: The device is a 7" LCD device (H=480, W=800 device), when Android boots "SYSTEM UI is not loaded" message pops up and the navigation/notification bar does NOT appear/display. However all operations like screen navigation etc are all working and we are able to navigate through a mouse!!! I am using a customised version which is a slight offset of SNOWBALL LINARO ICS. Logs: ~~~~~~~~~~~~~~~~~~~~~ I/ActivityManager( 1520): Config changed: {1.0 0mcc0mnc en_US layoutdir=0 sw640dp w1024dp h592dp lrg long land -touch -keyb/v/h -nav/h s.2} W/RecognitionManagerService( 1520): no available voice recognition services found D/SystemUIService( 2055): loading: class com.android.systemui.statusbar.tablet.TabletStatusBar D/SystemUIService( 2055): running: com.android.systemui.statusbar.tablet.TabletStatusBar@4111b118 D/dalvikvm( 1520): GC_CONCURRENT freed 142K, 13% free 8893K/10183K, paused 2ms+5ms I/StatusBar.HeightReceiver( 2055): Resizing status bar plugged=false height=36 old=0 D/dalvikvm( 1520): GC_FOR_ALLOC freed 1305K, 24% free 7758K/10183K, paused 31ms I/dalvikvm-heap( 1520): Grow heap (frag case) to 10.175MB for 1758292-byte allocation D/dalvikvm( 1520): GC_FOR_ALLOC freed <1K, 21% free 9475K/11911K, paused 35ms D/dalvikvm( 2055): GC_CONCURRENT freed 212K, 17% free 6070K/7239K, paused 2ms+2ms I/WindowManager( 1520): createSurface Window{41287de0 Keyguard paused=false}: DRAW NOW PENDING I/libblt_hw( 1337): Library opened (handle = 1, fd = 24) D/libEGL ( 1520): loaded /system/lib/egl/libGLES_android.so D/AndroidRuntime( 2055): Shutting down VM W/dalvikvm( 2055): threadid=1: thread exiting with uncaught exception (group=0x40a6c1f8) D/libEGL ( 1520): loaded /system/lib/egl/libEGL_mali.so E/AndroidRuntime( 2055): FATAL EXCEPTION: main E/AndroidRuntime( 2055): java.lang.RuntimeException: Unable to create service com.android.systemui.SystemUIService: java.lang.RuntimeException: Tablet device cannot show navigation bar and system bar E/AndroidRuntime( 2055): at android.app.ActivityThread.handleCreateService(ActivityThread.java:2262) E/AndroidRuntime( 2055): at android.app.ActivityThread.access $1600(ActivityThread.java:122) E/AndroidRuntime( 2055): at android.app.ActivityThread $H.handleMessage(ActivityThread.java:1200) E/AndroidRuntime( 2055): at android.os.Handler.dispatchMessage(Handler.java:99) E/AndroidRuntime( 2055): at android.os.Looper.loop(Looper.java:137) E/AndroidRuntime( 2055): at android.app.ActivityThread.main(ActivityThread.java:4340) E/AndroidRuntime( 2055): at java.lang.reflect.Method.invokeNative(Native Method) E/AndroidRuntime( 2055): at java.lang.reflect.Method.invoke(Method.java:511) E/AndroidRuntime( 2055): at com.android.internal.os.ZygoteInit $MethodAndArgsCaller.run(ZygoteInit.java:784) E/AndroidRuntime( 2055): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:551) E/AndroidRuntime( 2055): at dalvik.system.NativeStart.main(Native Method) E/AndroidRuntime( 2055): Caused by: java.lang.RuntimeException: Tablet device cannot show navigation bar and system bar E/AndroidRuntime( 2055): at com.android.systemui.statusbar.tablet.TabletStatusBar.makeStatusBarView(TabletStatusBar.java:451) E/AndroidRuntime( 2055): at com.android.systemui.statusbar.StatusBar.start(StatusBar.java:64) E/AndroidRuntime( 2055): at com.android.systemui.statusbar.tablet.TabletStatusBar.start(TabletStatusBar.java:390) E/AndroidRuntime( 2055): at com.android.systemui.SystemUIService.onCreate(SystemUIService.java:93) E/AndroidRuntime( 2055): at android.app.ActivityThread.handleCreateService(ActivityThread.java:2252) ~~~~~~~~~~~~~~~~~~~~~~~~ I understand the issue that it is a matter of setting the screen and device resolution. I had set the "ro.build.characteristics=tablet" in build.prop and rebooted, did not see any effect. Please note the lines in bold, blue. Can you please help me to solve this problem. Thanks and Regards, Venkat.

13 years, 1 month

Per build EULA handling

by Georgy Redkozubov

Greetings, We have depoyed per build EULA handling on http://snapshots.linaro.org as a part of downloads click through license protection. Now only "origen" and "snowball" builds that has binary blobs inside are protected by EULA and at the same time all other builds are open source and don't require license acceptance. To protect files in specific directory, the EULA.txt should be placed in that directory. Otherwise OPEN-EULA.txt should be there. These files triggers displaying license page based on build name and after accepting license downloading begins. If there are none of them the user get "Forbidden" page. Appropriate EULA is added automatically by the build system. -- WBR, Georgy Redkozubov Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

13 years, 1 month

← Newer
1
2
3
4
5
6
7
8
9
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev April 2012