linaro-dev

linaro-dev@lists.linaro.org

4332 discussions

by Michael Hope

I'm considering starting an extra branch of Linaro GCC for use in the final stages of development and would like your input. Our goal is improve the performance of real, shipping products and to help the their time to market. We make improvements and fixes to FSF GCC and then backport them to Linaro GCC so that you can pick up these improvements early. The problem comes when you're nearing release time as picking up a new release for a needed bug fix also pulls in new features which might introduce bugs. To reduce the risk, we could run a stable branch or bolster up the FSF stable branch. The Linaro stable branch would: * Start from Linaro GCC and its many performance improvements * Only take bug fixes * Be tested and released every month * Run for six months at a time * Work in the same way as our main release including support and having binary builds The idea is that you could track the main branch during development and switch to the stable branch during the last few months. This gives a good mix of the latest performance with less risk at release time. Bolstering up the FSF stable branch approaches the problem a different way. We work upstream, so all of our improvements are available in an upstream release, but perhaps a year later than via Linaro GCC. We could take the mainline releases, add binary builds, and generally boost mainline support. The FSF stable branch would: * Start at the upstream 4.x.1 release such as 4.6.1 * Only take regression fixes * Be tested and release with each (roughly quarterly) mainline release * Run for the roughly twelve months until the next mainline 4.y.1 release * Give a good path if you move away from Linaro in the future Any comments are appreciated. There's more background and discussion on the wiki at: https://wiki.linaro.org/MichaelHope/Sandbox/StableBranch I'm particularly interested in comments from people making products, distributions, or IDEs such as: * Is a stable branch useful? * How long does it need to be supported for? * When do you freeze your toolchain? * Should we spend our time elsewhere such as on more performance, faster bug fixes, more documentation, being in more distributions, or being available in other ways such as binary builds? -- Michael

13 years, 10 months

[PATCH 0/6] Add basic device tree support for Samsung's Exynos4 platform

by Thomas Abraham

This patch series adds a basic device tree based boot for Samsung's Exynos4 platforms and specifically for smdkv310 board. Device tree based driver probe is added for uart, sdhci and watchdog drivers. These patches enable booting to console on smdkv310 board with some of the devices initialized with data from the device tree. This patch series is based on git.secretlab.ca/git/linux-2.6.git devicetree/test and depends on the following patches which are not yet available in the devicetree/test branch. 1. [PATCH] ARM: EXYNOS4: Fix card detection for sdhci 0 and 2 [http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg04704.html] 2. [PATCH] ARM: EXYNOS4: Fix missing S5P_VA_AUDSS definition [http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg04866.html] 3. [PATCH 0/9] Add clkdev support for Samsung platforms [http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg04874.html] 4. Consolidate the clkdev header files [http://patchwork.ozlabs.org/patch/97862/] Thomas Abraham (6): serial: samsung: Keep a copy of platform data in driver's private data serial: samsung: Add device tree support for s5pv210 uart driver watchdog: s3c2410: Add support for device tree based probe mmc: sdhci-s3c: Add support for device tree based probe arm: dts: Add nodes in smdkv310 device tree source file arm: exynos4: Add a new Exynos4 device tree enabled machine Documentation/devicetree/bindings/arm/samsung.txt | 3 +- .../bindings/tty/serial/samsung_uart.txt | 50 +++++++ .../devicetree/bindings/watchdog/samsung-wdt.txt | 12 ++ arch/arm/boot/dts/exynos4-smdkv310.dts | 135 +++++++++++++++++++- arch/arm/mach-exynos4/Kconfig | 11 ++ arch/arm/mach-exynos4/Makefile | 1 + arch/arm/mach-exynos4/mach-exynos4-dt.c | 94 ++++++++++++++ drivers/mmc/host/sdhci-s3c.c | 11 ++ drivers/tty/serial/s5pv210.c | 39 +++++- drivers/tty/serial/samsung.c | 114 ++++++++++++++++- drivers/tty/serial/samsung.h | 4 +- drivers/watchdog/s3c2410_wdt.c | 10 ++ 12 files changed, 473 insertions(+), 11 deletions(-) create mode 100644 Documentation/devicetree/bindings/tty/serial/samsung_uart.txt create mode 100644 Documentation/devicetree/bindings/watchdog/samsung-wdt.txt create mode 100644 arch/arm/mach-exynos4/mach-exynos4-dt.c

13 years, 10 months

Re: Patches from the "Linaro Android Team" team

by Guilherme Salgado

Hi Jim, (I'm CCing linaro-dev@ because I figure others might have similar questions) This is because the android patches are going to the 'Unknown' project[1], which is ignored when generating the statistics[2]. We currently can't automatically detect the correct project for such patches because they are all sent to linaro-dev@ instead of their own mailing list like other projects. Maybe we could try and detect the correct project from the subject's prefix (e.g. [android/bionic]), but even then I suspect these patches are not really going to AOSP, in which case they wouldn't be included in the statistics either (much like the gcc-linaro and linaro-kernel projects). If I'm mistaken we can just create android projects and move the patches from the Unknown project to them. A thread I started recently (Subject: Please help us setup patches.linaro.org) on linaro-dev@ has more information on how to do that. [1] <http://patches.linaro.org/patchwork/project/other-unknown/list/?state=*> [2] <http://patches.linaro.org/faq> Cheers, On Wed, 2011-06-22 at 18:22 +0800, Jim Huang wrote: > hi Guilherme, > > I just checked the stat of Patches from the "Linaro Android Team" team: > http://patches.linaro.org/team/linaro-android/ > > I am quite confused about the number. I did submit patches to > linaro-dev and Cc. to patches(a)linaro.org and > you can find out the recent merged patches here: (Recently closed) > https://review.source.android.com//#dashboard,1002471 > > Is there any problem for stat? Or, can I help to improve it? > > Thanks, > -jserv -- Guilherme Salgado <https://launchpad.net/~salgado>

13 years, 10 months

[Notes] Power Management WG Weekly Status report week 2011-06-24

by Mounir Bsaibes

Enclosed please find the link to the Weekly Status report for the Power Management working group for the week ending 2011-06-24. == Weekly Status Report == https://wiki.linaro.org/WorkingGroups/PowerManagement/Status/2011-06-23 == Summary == * AMR cpu topology patch was sent * start to test cpu topo patch * Powerdebug various code addition and improvement, tagged version 0.5.0 * Reviewed kernel thermal framework implementation * Sent OMAP3 DVFS Fix for 11.05 kernel * Analyse & fix the issue of frequency not captured in latest powertop -- Mounir Bsaibes Project Manager Follow Linaro.org: facebook.com/pages/Linaro/155974581091106 http://twitter.com/#!/linaroorg http://www.linaro.org/linaro-blog <http://www.linaro.org/linaro-blog>

13 years, 10 months

[Notes] Kernel WG Weekly Status report week 2011-06-24

by Mounir Bsaibes

Enclosed please find the links to the meeting minutes and Weekly Status report for the kernel working group for the week ending 2011-06-24. == Meetings minutes == https://wiki.linaro.org/WorkingGroups/Kernel/Meetings/2011-06-20 == Weekly Status Report == https://wiki.linaro.org/WorkingGroups/Kernel/Status/2011-06-23 == Summary == * Linaro kernel freeze in preparation of monthly release * randconfig builds, now works on vexpress, exynos4, u8500, omap2+ and mxs * rebased mmc async request on Linux 3.0 rc3. * user space alignment faults discussion -- Mounir Bsaibes Project Manager Follow Linaro.org: facebook.com/pages/Linaro/155974581091106 http://twitter.com/#!/linaroorg http://www.linaro.org/linaro-blog

13 years, 10 months

TI LT 3.0 Tracking branches

by Andy Green

Hi - I mentioned this already to npitre but for various reasons we are planning to target 3.0 kernel rather than linux-linaro-2.6.39 at the moment. 2.6.39 has some known issues like no onboard audio or HDMI audio, but since 3.0 has a new and better ALSA implementation for Panda I'm not sure it's worth spending time on when the old implementation won't really go into linux-linaro even if we did forward-port it again. I introduced two new branches yesterday: http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git;a=shortlog;… - omap4_defconfig http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git;a=shortlog;… - android_omap4_defconfig that are linus' HEAD and common-3.0 (androidized nearly linus HEAD) based and have the API v4403 SGX stuff on them. The status is currently on linus HEAD, Panda EHCI is broken which is a bit of a downer; Jassi is taking a look at it. Also video is coming up nicely with 1080p raster, but it is stuck at 640 x 480 framebuffer viewport inside that right now. However, Android rootfs is able to boot to the desktop (v4403 3D accelerated) with tilt-tracking-android, and X can come up unaccelerated as usual as well on Ubuntu on tilt-tracking. So it's not a bad start. When linux-linaro-3.0 is coming in the next weeks, we will use that as a base instead as before. -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog

13 years, 10 months

Re: u-boot: initial support for smsc95xx and TFTP boot at Panda

by Kris

Hi, I tried with the precompiled u-boot and MLO and it is working fine. But failed with the sources downloaded from the link provided. Can you please any addition settngs need to be done for the sources. I have used OMAP4_PANDA_CONFIG. You can find my WIP tree at https://gitorious.org/ubuntu-experimental/linaro-u-boot/commits/u-boot-mast… Please comment. Regards Krishna M.

13 years, 10 months

RFC: drivers: swarren's pinmux API concept

by Stephen Warren

Linus W, This "patch" is a quick-and-dirty outline of where I'd love to see the pinmux API go, but this time in code rather than English description. Note that I elided a bunch of stuff from the headers; some comments weren't updated, I removed the inline functions for when pinmux is disabled, etc. The code has not been compiled. The main idea is just to give an idea of what I'm thinking. Let me know if any of this looks reasonable to you; if so, I can look into fixing the issues above, making the core pinmux code actually work in this model, or whatever. Thanks! --- drivers/pinctrl/pinmux-tegra2.c | 85 ++++++++++++++++++++++ include/linux/pinctrl/consumer.h | 47 ++++++++++++ include/linux/pinctrl/machine.h | 47 ++++++++++++ include/linux/pinctrl/provider.h | 149 ++++++++++++++++++++++++++++++++++++++ 4 files changed, 328 insertions(+), 0 deletions(-) create mode 100644 drivers/pinctrl/pinmux-tegra2.c create mode 100644 include/linux/pinctrl/consumer.h create mode 100644 include/linux/pinctrl/machine.h create mode 100644 include/linux/pinctrl/provider.h diff --git a/drivers/pinctrl/pinmux-tegra2.c b/drivers/pinctrl/pinmux-tegra2.c new file mode 100644 index 0000000..d010f9c --- /dev/null +++ b/drivers/pinctrl/pinmux-tegra2.c @@ -0,0 +1,85 @@ +/* + * pinctrl driver for NVIDIA Tegra 2 + * + * Author: Stephen Warren <swarren(a)nvidia.com> + * Copyright (C) 2011 NVIDIA, Inc. + * + * License terms: GNU General Public License (GPL) version 2 + */ + +#include <linux/pinmux/provider.h> + +struct tegra_pin { + struct pinctrl_pin core; + int reg_addr; /* e.g. for per-pin config */ + /* And other info */ +}; + +struct tegra_function { + struct pinctrl_function core; + int reg_value; + /* And other info */ +} + +struct tegra_group { + struct pinctrl_group core; + int reg_addr; /* e.g. for muxing and per-pin config */ + int reg_bit; + /* And other info */ +} + +struct tegra_pin tegra_pins[] = { + { .core = { .name = "a0", }, }, /* 0 */ + { .core = { .name = "a1", }, }, /* 1 */ + { .core = { .name = "b0", }, }, /* 2 */ + { .core = { .name = "b1", }, }, /* 3 */ + { .core = { .name = "c0", }, }, /* 4 */ + { .core = { .name = "c1", }, }, /* 5 */ + { .core = { .name = "d0", }, }, /* 6 */ + { .core = { .name = "d1", }, }, /* 7 */ + { .core = { .name = "e0", }, }, /* 8 */ + { .core = { .name = "e1", }, }, /* 9 */ + +/* Or: */ +#define PIN_B0 2 + .PIN_B0 = { .core = { .name = "b0", }, }, +}; + +struct tegra_function tegra_function[] = { + { .core = { .name = "kbc-col-1:0", }, 1 }, /* 0 */ + { .core = { .name = "kbc-row-1:0", }, 2 }, /* 1 */ + { .core = { .name = "i2c0", }, 3 }, /* 2 */ + { .core = { .name = "uartrxtx0", }, 4 }, /* 3 */ + { .core = { .name = "spiclkdata0", }, 5 }, /* 4 */ + { .core = { .name = "gpioctrlr0", }, 0x8001}, /* 5 */ + { .core = { .name = "gpioctrlr1", }, 0x8002}, /* 6 */ + +/* Or: */ +#define FUNC_I2C0 2 + .FUNC_I2C0 = { .core = { .name = "i2c0", }, 3}, + +}; + +int pins_kbca[] = { 0, 1 }; +int funcs_kbca[] = { 0, 5 }; + +int pins_kbcb[] = { 2, 3 }; +int funcs_kbcb[] = { 1, 5 }; + +int pins_ddca[] = { 4, 5 }; +int funcs_ddca[] = { 2, 3, 5, 6 }; + +int pins_ddcb[] = { 6, 7 }; +int funcs_ddcb[] = { 2, 4, 5, 6 }; + +int pins_xx[] = { 8, 9}; +int funcs_xx[] = { 5, 6}; + +struct tegra_group tegra_groups[] = { + { .core = { .name = "kbca", npins = 2, pins = pins_kbca, nfunctions = 2, functions = funcs_kbca} }, + { .core = { .name = "kbcb", npins = 2, pins = pins_kbcb, nfunctions = 2, functions = funcs_kbcb} }, + { .core = { .name = "ddca", npins = 2, pins = pins_ddca, nfunctions = 4, functions = funcs_ddca} }, + { .core = { .name = "ddcb", npins = 2, pins = pins_ddcb, nfunctions = 4, functions = funcs_ddcb} }, + { .core = { .name = "xx", npins = 2, pins = pins_xx, nfunctions = 2, functions = funcs_xx } }, +}; + diff --git a/include/linux/pinctrl/consumer.h b/include/linux/pinctrl/consumer.h new file mode 100644 index 0000000..81cedf3 --- /dev/null +++ b/include/linux/pinctrl/consumer.h @@ -0,0 +1,47 @@ +/* + * pinctrl subsystem's client/consumer interface + * + * Copyright (C) 2011 ST-Ericsson SA + * Written on behalf of Linaro for ST-Ericsson + * Based on bits of regulator core, gpio core and clk core + * + * Author: Linus Walleij <linus.walleij(a)linaro.org> + * + * Copyright (C) 2011 NVIDIA, Inc. + * + * License terms: GNU General Public License (GPL) version 2 + */ +#ifndef __LINUX_PINCTRL_CONSUMER_H +#define __LINUX_PINCTRL_CONSUMER_H + +#include <linux/list.h> +#include <linux/seq_file.h> + +/* This struct is private to the core and should be regarded as a cookie */ +struct pinctrl; + +/* Not sure this is useful: */ +extern bool pin_is_valid(int pin); + +/* Basic pinmux API: */ +extern struct pinctrl *pinctrl_get(struct device *dev, const char *mapping); +extern void pinctrl_put(struct pinctrl *pmx); +extern int pinctrl_enable(struct pinctrl *pmx); +extern void pinctrl_disable(struct pinctrl *pmx); + +/* + * Custom config interface: + * Drivers would probably use the first function, since they would + * already have pinctrl_get()d the mapping they want to configure. + * + * Generic setup code couuldn't use pinctrl_get since that actually + * reserved that mapping. Plus, we potentially need a way to configure + * individual pins + */ +extern int pinctrl_config(struct pinctrl *pmx, u16 param, unsigned long *data); +extern int pinctrl_config_group(const char *chip, const char* groupname, + u16 param, unsigned long *data); +extern int pinctrl_config_pin(const char *chip, const char* pinname, u16 param, + unsigned long *data); + +#endif /* __LINUX_PINCTRL_CONSUMER_H */ diff --git a/include/linux/pinctrl/machine.h b/include/linux/pinctrl/machine.h new file mode 100644 index 0000000..5797e84 --- /dev/null +++ b/include/linux/pinctrl/machine.h @@ -0,0 +1,47 @@ +/* + * pinctrl subsystem's machine/board mapping configuration interface + * + * Copyright (C) 2011 ST-Ericsson SA + * Written on behalf of Linaro for ST-Ericsson + * Based on bits of regulator core, gpio core and clk core + * + * Author: Linus Walleij <linus.walleij(a)linaro.org> + * + * Copyright (C) 2011 NVIDIA, Inc. + * + * License terms: GNU General Public License (GPL) version 2 + */ +#ifndef __LINUX_PINMUX_MACHINE_H +#define __LINUX_PINMUX_MACHINE_H + +/** + * struct pinctrl_map - boards/machines shall provide this map for devices + * @dev_name: the name of the device using this specific mapping, the name + * must be the same as in your struct device* + * @mapping: the mapping name being defined + * @chip: the chip on which to set the mux + * @group: the group on which to set the mux + * @function: the function to select + */ +/* + * Example: + * { "tegra-kbc", NULL, "tegra", "kbca", "kbc-col-1:0" }, + * { "tegra-kbc", NULL, "tegra", "kbcb", "kbc-row-1:0" }, + * { "tegra-i2c.0", "bus0", "tegra", "ddca", "i2c0" }, + * { "tegra-i2c.0", "bus1", "tegra", "ddcb", "i2c0" }, + * { NULL, "bootup", "tegra", "xx", "gpioctrlr0" }, + * + * (Machine boot code searches for "bootup" and activates everything there) + */ +struct pinctrl_map { + const char *dev_name; + const char *mapping; + const char *chip; + const char *group; + const char *function; +}; + +extern int pinctrl_register_mappings(struct pinctrl_map const *map, + unsigned num_maps); + +#endif /* __LINUX_PINCTRL_MACHINE_H */ diff --git a/include/linux/pinctrl/provider.h b/include/linux/pinctrl/provider.h new file mode 100644 index 0000000..ee355f3 --- /dev/null +++ b/include/linux/pinctrl/provider.h @@ -0,0 +1,149 @@ +/* + * pinctrl subsystem's pinctrl driver interface + * + * Copyright (C) 2011 ST-Ericsson SA + * Written on behalf of Linaro for ST-Ericsson + * Based on bits of regulator core, gpio core and clk core + * + * Author: Linus Walleij <linus.walleij(a)linaro.org> + * + * Copyright (C) 2011 NVIDIA, Inc. + * + * License terms: GNU General Public License (GPL) version 2 + */ +#ifndef __LINUX_PINCTRL_PROVIDER_H +#define __LINUX_PINCTRL_PROVIDER_H + +#include <linux/list.h> +#include <linux/seq_file.h> + +struct pinctrl_dev; + +struct pinctrl_pin { + char *name; +}; + +struct pinctrl_function { + char *name; +}; + +struct pinctrl_group { + char *name; + int npins; + int *pinids; + int nfunctions; + int *functionids; +}; + +/** + * struct pinctrl_ops - pinctrl operations, to be implemented by drivers + * @request: called by the core to see if a certain pin can be made available + * available for muxing. This is called by the core to acquire the pins + * before selecting any actual mux setting across a function. The driver + * is allowed to answer "no" by returning a negative error code + * @free: the reverse function of the request() callback, frees a pin after + * being requested + * @enable: enable a certain muxing enumerator. The driver does not need to + * figure out whether enabling this function conflicts some other use + * of the pins, such collisions are handled by the pinctrl subsystem + * @disable: disable a certain muxing enumerator + * @config: custom configuration function for a certain muxing enumerator - + * this works a bit like an ioctl() and can pass in and return arbitrary + * configuration data to the pinctrl + * @dbg_show: optional debugfs display hook that will provide per-device + * info for a certain pin in debugfs + */ +struct pinctrl_ops { + struct pinctrl_pin *(*get_pin) (struct pinctrl_dev *pctrldev, int id); + struct pinctrl_function *(*get_function) (struct pinctrl_dev *pctrldev, + int id); + struct pinctrl_group *(*get_group) (struct pinctrl_dev *pctrldev, + int id); + + /* + * request is still problematic; to perform any custom rules, the + * driver must compare the requested assignment to the previously + * requested, but not necessarily enabled, state. This means the + * driver must: + * a) Maintain a mirror of the requested state that the core is + * already managing. + * b) Have some way to look into the state that the core is + * already managing. This could be implemented by storing (part + * of) that state in the driver-provided struct pinctrl_groups + */ + int (*request) (struct pinctrl_dev *pctrldev, int groupid, + int functionid); + int (*free) (struct pinctrl_dev *pctrldev, int groupid); + + int (*enable) (struct pinctrl_dev *pctrldev, int groupid, + int functionid); + void (*disable) (struct pinctrl_dev *pctrldev, int groupid); + + int (*config_pin) (struct pinctrl_dev *pctrldev, int pinid, u16 param, + unsigned long *data); + int (*config_group) (struct pinctrl_dev *pctrldev, int groupid, + u16 param, unsigned long *data); + + void (*dbg_show_pin) (struct pinctrl_dev *pctrldev, struct seq_file *s, + int pinid); + void (*dbg_show_group) (struct pinctrl_dev *pctrldev, + struct seq_file *s, int groupid); +}; + +/** + * struct pinctrl_desc - pinctrl descriptor, register this to pinctrl subsystem + * @name: name for the pinctrl + * @ops: pinctrl operation table + * @owner: module providing the pinctrl, used for refcounting + * @base: the number of the first pin handled by this pinctrl, in the global + * pin space, subtracted from a given pin to get the offset into the range + * of a certain pinctrl + * @npins: the number of pins handled by this pinctrl - if your driver handles + * 8 pins that each can be muxed in 3 different ways, you reserve 8 + * pins in the global pin space and set this to 8 + */ +struct pinctrl_desc { + const char *name; + struct pinctrl_ops *ops; + struct module *owner; + int base; + int npins; + int nfunctions; + int ngroups; +}; + +/** + * struct pinctrl_dev - pinctrl class device + * @desc: the descriptor supplied when initializing this pinctrl + * @node: node to include this pinctrl in the global pinctrl list + * @dev: the device entry for this pinctrl + * @owner: module providing the pinctrl, used for refcounting + * @driver_data: driver data for drivers registering to the subsystem + * + * This should be dereferenced and used by the pinctrl core ONLY + */ +struct pinctrl_dev { + const struct pinctrl_desc *desc; + struct list_head node; + struct device dev; + struct module *owner; + void *driver_data; +}; + +/* These should only be used from drives */ +static inline const char *pctrldev_get_name(struct pinctrl_dev *pctrldev) +{ + /* We're not allowed to register devices without name */ + return pctrldev->desc->name; +} + +static inline void *pctrldev_get_drvdata(struct pinctrl_dev *pctrldev) +{ + return pctrldev->driver_data; +} + +extern struct pinctrl_dev *pinctrl_register(struct pinctrl_desc *pmxdesc, + struct device *dev, void *driver_data); +extern void pinctrl_unregister(struct pinctrl_dev *pctrldev); + +#endif /* __LINUX_PINCTRL_PROVIDER_H */ -- 1.7.0.4

13 years, 10 months

Linaro 11.05 weekly testing 2011-06-23

by Fathi Boudra

Hi, This is a message sent out once per week to call on our community to encourage all Linux/ARM enthusiasts to try out the latest preview images of our Linaro Evaluation Builds (LEBs) for Android Handset and Ubuntu Desktop/Netbook. These images showcase the current state of development on our LEBs images on their way to the next release: 11.06. * Android: http://snapshots.linaro.org/offspring/11.05-daily/linaro-android/leb-panda/… * Ubuntu: http://snapshots.linaro.org/offspring/11.05-daily/linaro-ubuntu-desktop/201… http://snapshots.linaro.org/offspring/11.05-daily/linaro-hwpacks/panda-x11-… On top of the official Linaro Evaluation Builds, the Platform Team hosts a set of functional images and board support packages that are typically released by Linaro engineers for developers that have different images requirements. These images are not officially supported release artifacts and are provided on a best-effort basis in the hope that they can be useful for the Linux/ARM enthusiasts community. The download locations for these so called "Developers and Community Builds" can be found below. Developer and Experimental Images based on Android (vanilla AOSP experience using linux-linaro mainline kernel): * Android Mainline for BeagleBoardr-xM: http://snapshots.linaro.org/offspring/11.05-daily/linaro-android/beaglexm/2… * Android Mainline for PandaBoard: http://snapshots.linaro.org/offspring/11.05-daily/linaro-android/panda/2011… Developer Images based on Ubuntu: Note: Ubuntu images are distributed in two parts: 1. a SoC independent userspace rootfs (the image) 2. a Soc specific BSP (the hwpack) * Nano: http://snapshots.linaro.org/offspring/11.05-daily/linaro-nano/20110623/0/im… * ALIP: http://snapshots.linaro.org/offspring/11.05-daily/linaro-alip/20110623/0/im… * Developer: http://snapshots.linaro.org/offspring/11.05-daily/linaro-developer/20110623… Not officially supported community board support packages are also provided for either boards that don't meet our Linaro Evaluation Builds criterias. The idea is that you can combine them freely (e.g. combine an imx51 hwpack with Nano or Developer); though in practice UI images might not work. A list of all hardware packs hosted by Linaro Platform can be found below: http://snapshots.linaro.org/offspring/11.05-daily/linaro-hwpacks/ Make your way to the installation instructions: https://wiki.linaro.org/Platform/Android/ImageInstallation https://wiki.linaro.org/Platform/DevPlatform/Ubuntu/ImageInstallation For an explanation on how to test and submit your results to the QA tracker at: http://qatracker.linaro.org For an explanation of how to use the qatracker please see: https://wiki.linaro.org/QA/QATracker Cheers, Fathi -- Linaro Release Manager | Platform Project Manager

13 years, 10 months

problem with todays linux-linaro-2.6.39 and THUMB2 kernel

by John Rigby

Nicolas, Dave, make omap4_defconfig make menuconfig and turn on THUMB2_KERNEL make ..... CC arch/arm/kernel/smp_twd.o CC arch/arm/kernel/machine_kexec.o AS arch/arm/kernel/relocate_kernel.o arch/arm/kernel/relocate_kernel.S: Assembler messages: arch/arm/kernel/relocate_kernel.S:10: Error: invalid offset, value too big (0xFFFFFFFFFFFFFFFC) arch/arm/kernel/relocate_kernel.S:11: Error: invalid offset, value too big (0xFFFFFFFFFFFFFFFC) arch/arm/kernel/relocate_kernel.S:58: Error: invalid offset, value too big (0xFFFFFFFFFFFFFFFC) arch/arm/kernel/relocate_kernel.S:59: Error: invalid offset, value too big (0xFFFFFFFFFFFFFFFC) make[1]: *** [arch/arm/kernel/relocate_kernel.o] Error 1 make: *** [arch/arm/kernel] Error 2

13 years, 10 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev