linaro-dev

linaro-dev@lists.linaro.org

4332 discussions

Linaro 11.05 weekly testing 2011-07-07

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.07. * Android: http://snapshots.linaro.org/11.05-daily/linaro-android/leb-panda/20110707/ * Ubuntu: http://snapshots.linaro.org/11.05-daily/linaro-ubuntu-desktop/20110707/0/im… http://snapshots.linaro.org/11.05-daily/linaro-hwpacks/panda-x11-base/20110… 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/11.05-daily/linaro-android/beaglexm/20110707/ * Android Mainline for PandaBoard: http://snapshots.linaro.org/11.05-daily/linaro-android/panda/20110707/ 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/11.05-daily/linaro-nano/20110707/0/images/tar/ * ALIP: http://snapshots.linaro.org/11.05-daily/linaro-alip/20110707/0/images/tar/ * Developer: http://snapshots.linaro.org/11.05-daily/linaro-developer/20110707/0/images/… 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/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 -- Fathi Boudra Linaro Release Manager | Platform Project Manager Linaro.org | Open source software for ARM SoCs

14 years

trouble with should-be-bootable SD cards and kernel versions

by AJ ONeal

I have a few inter-related issues: - Why would one kernel boot a card that another kernel can't? - Why would a card's disk geometry matter for boot? - Who is a good manufacturer for getting hardware-identical cards in bulk? - How can I probe the actual "disk geometry" of an sd card? I bought 100 Transcend SD cards a little while ago and duplicated them with an OpenEmbedded-based filesystem (linux-2.6.36). There were a few "bad" cards that I threw out, but the success rate was acceptable. In the next round of 40 SD cards I used a Linaro-based filesystem (linux-2.6.39) and had about a 50% failure rate when testing that the cards would boot, which is absurd. There kernel reports: [ 1.003204] mmcblk0: unknown partition table However, the cards would mount and show files just fine. I reduplicated one of the non-booting cards with an OpenEmbedded filesystem and then it booted. Weird! After some investigation I found that using `gparted` (instead of `fdisk`) to create a new partition table and then `rsync`ing the contents of the original filesystem resulted in a booting Linaro card. Rinse and repeat and I ended up with 3 images which only vary by the disk geometry as reported by `fdisk -l`: - 50% -- 255 heads, 63 sectors/track, 974 cylinders - 40% -- 2 heads, 4 sectors/track, 1957632 cylinders - 10% -- 247 heads, 62 sectors/track, 1022 cylinders - 1 card still didn't boot I'm lost. Please advise. AJ ONeal Non-booting kernel message [ 0.923309] Waiting for root device /dev/mmcblk0p2... [ 0.957885] mmc0: host does not support reading read-only switch. assuming write-enable. [ 0.982025] mmc0: new high speed SDHC card at address b368 [ 0.988494] mmcblk0: mmc0:b368 USD 7.46 GiB [ 0.993957] mmcblk0: detected capacity change from 0 to 8018460672 [ 1.003204] mmcblk0: unknown partition table [ 1.036926] VFS: Cannot open root device "mmcblk0p2" or unknown-block(179,2) [ 1.044433] Please append a correct "root=" boot option; here are the available partitions: [ 1.053344] b300 7830528 mmcblk0 driver: mmcblk [ 1.058959] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(179,2) Booting kernel message [ 1.122070] mmc0: host does not support reading read-only switch. assuming write-enable. [ 1.146087] mmc0: new high speed SDHC card at address b368 [ 1.152557] mmcblk0: mmc0:b368 USD 7.46 GiB [ 1.158020] mmcblk0: detected capacity change from 0 to 8018460672 [ 1.166351] mmcblk0: p1 p2 p3 [ 1.259674] EXT3-fs: barriers not enabled [ 1.265411] kjournald starting. Commit interval 5 seconds [ 1.271331] EXT3-fs (mmcblk0p2): mounted filesystem with ordered data mode [ 1.278686] VFS: Mounted root (ext3 filesystem) readonly on device 179:2.

14 years

linaro-android-3.0 git tree is up!

by john stultz

I've just pushed a 3.0 based branch to the Linaro+Android git tree, which can be found here: git://git.linaro.org/people/jstultz/android.git linaro-android-3.0 See the revision log here: http://git.linaro.org/gitweb?p=people/jstultz/android.git;a=shortlog;h=refs… At the moment there isn't a 3.0 based linaro tree, so in order to facilitate early testing with 3.0 for the 11.07 release, I've gone ahead and pushed out only the android-3.0 branch + a few defconfig changes. Once Nico makes the 3.0 linaro tree available, I'll merge it in as I normally do. Known issues: ------------- o The ADB code has changed in 3.0, and requires some commands from userland at boot in order to be enabled. See bug #807230 for details. o EDID isn't yet working, so to get graphics on pandaboard, I needed to add: "omapfb.mode=dvi:1280x1024MR-16@60" to the boot prompt. Zach is looking into this w/ the TI developers. o USB goes to sleep periodically, and requires a keystroke to wake up. Unfortunately usb adb connections don't survive these cat-naps. o I've not finished testing on beagleboard, but it was working a few days ago without major issues. Please let me know if anyone runs into any additional issues. thanks -john

14 years

Launch Control to LAVA migration script

by Zygmunt Krynicki

Hi folks. I wrote this script that allows one to upgrade from l-c to lava-dashboard. The script is interactive due to debconf which we are currently stuck with. I tested it in several configurations on a snapshot of l-c 0.4.1 I would like to use this script in the migration guide, feedback welcome! Thanks ZK

14 years

Customization of Gerrit for Android

by James Westby

Hi Zach, We have a request in the queue to set up Gerrit for the Android team, and I know it's something that you consider very important. We haven't yet talked specifics of the configuration of Gerrit, and so I don't yet have a solid idea of what work there is for the Infrastructure team there. I'd like to rectify that and create an implementation plan for the first steps to where you want to go. To that end, if we had a vanilla Gerrit instance up and running tomorrow, what would be the first things that you would want to do to it before it would be useful to you? Thanks, James

14 years

Jenkins upgrade on android-build

by Paul Sokolovsky

Hello, I'd like to upgrade Jenkins on the production to be close to sandboxes (which always use latest) and local development to be performed per this milestone's blueprints. android-build.linaro.org runs 1.400, latest is 1.418. Interim versions were tested regularly on sandboxes, and I reviewed changelog and saw no backwards-incompatible changes which might affect us. Actually, it has few nice fixes and features useful for us, including those which raised discontent with using Jenkins for our usage patterns: * Label expression logic wasn't supporting a binary operator sequence like "a || b || c" (issue 8537) * Move Jenkins URL setting from E-mail Notification to its own section in the main configuration. * Added an extension point to allow prodding the NodeProvisioner into taking action faster than it might usually. * When there are absolutely no executors for a specific label, there was an unnecessary delay in provisioning the first node for that label. * Added a new build parameter type that shows a text area So, I'd propose to perform upgrade European morning on Thursday, 7th. Please let me know if there're any concerns. -- Best Regards, Paul

14 years

3.0 kernel Android wakelocks and mmc delayed work

by Andy Green

Hi - Yesterday I studied suspend status on 3.0 kernel for Panda, for mem suspend it's working pretty well in Ubuntu case, desktop is coming back up woken by USB keyboard action, WLAN is workable after reassociation. However in Android case, the same tree merged with common-android-3.0 to get Androidization is blowing chunks in suspend / resume, entering a loop where it aborts suspend and then tries to suspend again all the time. Increasing the debug level in wakelock code shows at least two guys that can make trouble, locks "mmc_delayed_work" and "alarm_rtc". "mmc_delayed_work" casues wakelock stuff to return -EAGAIN, and "alarm_rtc" seems to timeout as a wakelock, but leave the alarm device in a state where it will abort suspend on -EBUSY. I took a look in drivers/mmc/core/core.c to see what the wakelock support patches had done there and was a bit surprised. They have a single wakelock to cover delayed work in there, however there are multiple delayed works possible to be queued, eg delayed disable and delayed detect actions, and although they wrap scheduling the delayed work to also lock the wakelock, they don't wrap cancelling it, eg --> void mmc_stop_host(struct mmc_host *host) { ... if (host->caps & MMC_CAP_DISABLE) cancel_delayed_work(&host->disable); cancel_delayed_work_sync(&host->detect); mmc_flush_scheduled_work(); Nor do wakelocks seem to maintain counters, they're either locked or unlocked. So the following code looks highly suspicious: static int mmc_schedule_delayed_work(struct delayed_work *work, unsigned long delay) { wake_lock(&mmc_delayed_work_wake_lock); return queue_delayed_work(workqueue, work, delay); } static int mmc_host_do_disable(struct mmc_host *host, int lazy) { .... (conditionally) mmc_schedule_delayed_work(&host->disable, delay); ... } void mmc_host_deeper_disable(struct work_struct *work) { ... mmc_host_do_disable(host, 1); ... wake_unlock(&mmc_delayed_work_wake_lock); } Ie mmc_host_deeper_disable() can provoke delayed work which it proceeds to unlock wakelock coverage for. To the point of the symptoms: int mmc_pm_notify(struct notifier_block *notify_block, unsigned long mode, void *unused) { ... switch (mode) { case PM_HIBERNATION_PREPARE: case PM_SUSPEND_PREPARE: ... cancel_delayed_work_sync(&host->detect); So here when preparing for suspend we can cancel the delayed work we presumably arranged wakelock coverage for, without unlocking the wakelock. Am I missing the point or is some work needed to improve wakelock application for mmc stuff in common-android-3.0? -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

14 years

[PATCH 02/11] GPIO: DA9052 GPIO module v3

by ashishj3

DA9052 PMIC has 16 bit GPIO bus for peripheral control. This patch add support for the GPIO pins on the DA9052. Signed-off-by: David Dajun Chen <dchen(a)diasemi.com> Signed-off-by: Ashish Jangam <ashish.jangam(a)kpitcummins.com> CC: Arnd Bergmann <arnd(a)arndb.de> CC: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- Changes since v3: - Remove da9052 gpio header file Changes since v2: - change of file name - correct reference to irq_base in function to_irq() - remove pdata dependency --- drivers/gpio/Kconfig | 6 + drivers/gpio/Makefile | 1 + drivers/gpio/gpio-da9052.c | 279 ++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 286 insertions(+), 0 deletions(-) create mode 100755 drivers/gpio/gpio-da9052.c diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig index d3b2953..df510d4 100644 --- a/drivers/gpio/Kconfig +++ b/drivers/gpio/Kconfig @@ -65,6 +65,12 @@ config GPIO_SYSFS # put expanders in the right section, in alphabetical order +config GPIO_DA9052 + tristate "Dialog DA9052 GPIO" + depends on PMIC_DA9052 + help + Say yes here to enable the GPIO driver for the DA9052 chip. + config GPIO_MAX730X tristate diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile index becef59..cbee503 100644 --- a/drivers/gpio/Makefile +++ b/drivers/gpio/Makefile @@ -11,6 +11,7 @@ obj-$(CONFIG_GPIOLIB) += gpiolib.o obj-$(CONFIG_GPIO_ADP5520) += adp5520-gpio.o obj-$(CONFIG_GPIO_ADP5588) += adp5588-gpio.o obj-$(CONFIG_GPIO_BASIC_MMIO) += basic_mmio_gpio.o +obj-$(CONFIG_GPIO_DA9052) += gpio-da9052.o obj-$(CONFIG_GPIO_LANGWELL) += langwell_gpio.o obj-$(CONFIG_GPIO_MAX730X) += max730x.o obj-$(CONFIG_GPIO_MAX7300) += max7300.o diff --git a/drivers/gpio/gpio-da9052.c b/drivers/gpio/gpio-da9052.c new file mode 100755 index 0000000..5623369 --- /dev/null +++ b/drivers/gpio/gpio-da9052.c @@ -0,0 +1,279 @@ +/* + * GPIO Driver for Dialog DA9052 PMICs. + * + * Copyright(c) 2011 Dialog Semiconductor Ltd. + * + * Author: David Dajun Chen <dchen(a)diasemi.com> + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + * + */ +#include <linux/module.h> +#include <linux/fs.h> +#include <linux/uaccess.h> +#include <linux/platform_device.h> +#include <linux/gpio.h> +#include <linux/syscalls.h> +#include <linux/seq_file.h> + +#include <linux/mfd/da9052/da9052.h> +#include <linux/mfd/da9052/reg.h> +#include <linux/mfd/da9052/pdata.h> +#include <linux/mfd/da9052/gpio.h> + +#define DA9052_INPUT 1 +#define DA9052_OUTPUT_OPENDRAIN 2 +#define DA9052_OUTPUT_PUSHPULL 3 + +#define DA9052_SUPPLY_VDD_IO1 0 + +#define DA9052_DEBOUNCING_OFF 0 +#define DA9052_DEBOUNCING_ON 1 + +#define DA9052_OUTPUT_LOWLEVEL 0 + +#define DA9052_ACTIVE_LOW 0 +#define DA9052_ACTIVE_HIGH 1 + +#define DA9052_GPIO_MAX_PORTS_PER_REGISTER 8 +#define DA9052_GPIO_SHIFT_COUNT(no) (no%8) +#define DA9052_GPIO_MASK_UPPER_NIBBLE 0xF0 +#define DA9052_GPIO_MASK_LOWER_NIBBLE 0x0F +#define DA9052_GPIO_NIBBLE_SHIFT 4 + +struct da9052_gpio { + struct da9052 *da9052; + struct gpio_chip gp; +}; + +static inline struct da9052_gpio *to_da9052_gpio(struct gpio_chip *chip) +{ + return container_of(chip, struct da9052_gpio, gp); +} + +static unsigned char da9052_gpio_port_odd(unsigned offset) +{ + return offset % 2; +} + +static int da9052_gpio_get(struct gpio_chip *gc, unsigned offset) +{ + struct da9052_gpio *gpio = to_da9052_gpio(gc); + int da9052_port_direction = 0; + int ret; + + ret = da9052_reg_read(gpio->da9052, + DA9052_GPIO_0_1_REG + (offset >> 1)); + if (ret < 0) + return ret; + + if (da9052_gpio_port_odd(offset)) { + da9052_port_direction = ret & DA9052_GPIO_ODD_PORT_PIN; + da9052_port_direction >>= 4; + } else { + da9052_port_direction = ret & DA9052_GPIO_EVEN_PORT_PIN; + } + + switch (da9052_port_direction) { + case DA9052_INPUT: + if (offset < DA9052_GPIO_MAX_PORTS_PER_REGISTER) + ret = da9052_reg_read(gpio->da9052, + DA9052_STATUS_C_REG); + else + ret = da9052_reg_read(gpio->da9052, + DA9052_STATUS_D_REG); + if (ret < 0) + return ret; + if (ret & (1 << DA9052_GPIO_SHIFT_COUNT(offset))) + return 1; + else + return 0; + case DA9052_OUTPUT_PUSHPULL: + if (da9052_gpio_port_odd(offset)) + return ret & DA9052_GPIO_ODD_PORT_MODE; + else + return ret & DA9052_GPIO_EVEN_PORT_MODE; + default: + return -EINVAL; + } +} + +static void da9052_gpio_set(struct gpio_chip *gc, unsigned offset, int value) +{ + struct da9052_gpio *gpio = to_da9052_gpio(gc); + unsigned char register_value = 0; + int ret; + + if (da9052_gpio_port_odd(offset)) { + if (value) { + register_value = DA9052_GPIO_ODD_PORT_MODE; + ret = da9052_reg_update(gpio->da9052, (offset >> 1) + + DA9052_GPIO_0_1_REG, + DA9052_GPIO_ODD_PORT_MODE, + register_value); + if (ret != 0) + dev_err(gpio->da9052->dev, + "Failed to updated gpio odd reg,%d", + ret); + } + } else { + if (value) { + register_value = DA9052_GPIO_EVEN_PORT_MODE; + ret = da9052_reg_update(gpio->da9052, (offset >> 1) + + DA9052_GPIO_0_1_REG, + DA9052_GPIO_EVEN_PORT_MODE, + register_value); + if (ret != 0) + dev_err(gpio->da9052->dev, + "Failed to updated gpio even reg,%d", + ret); + } + } +} + +static int da9052_gpio_direction_input(struct gpio_chip *gc, unsigned offset) +{ + struct da9052_gpio *gpio = to_da9052_gpio(gc); + unsigned char register_value; + int ret; + + /* Format: function - 2 bits type - 1 bit mode - 1 bit */ + register_value = DA9052_INPUT | DA9052_ACTIVE_LOW << 2 | + DA9052_DEBOUNCING_ON << 3; + + if (da9052_gpio_port_odd(offset)) + ret = da9052_reg_update(gpio->da9052, (offset >> 1) + + DA9052_GPIO_0_1_REG, + DA9052_GPIO_MASK_UPPER_NIBBLE, + (register_value << + DA9052_GPIO_NIBBLE_SHIFT)); + else + ret = da9052_reg_update(gpio->da9052, (offset >> 1) + + DA9052_GPIO_0_1_REG, + DA9052_GPIO_MASK_LOWER_NIBBLE, + register_value); + + return ret; +} + +static int da9052_gpio_direction_output(struct gpio_chip *gc, + unsigned offset, int value) +{ + struct da9052_gpio *gpio = to_da9052_gpio(gc); + unsigned char register_value; + int ret; + + /* Format: Function - 2 bits Type - 1 bit Mode - 1 bit */ + register_value = DA9052_OUTPUT_PUSHPULL | DA9052_SUPPLY_VDD_IO1 << 2 | + value << 3; + + if (da9052_gpio_port_odd(offset)) + ret = da9052_reg_update(gpio->da9052, (offset >> 1) + + DA9052_GPIO_0_1_REG, + DA9052_GPIO_MASK_UPPER_NIBBLE, + (register_value << + DA9052_GPIO_NIBBLE_SHIFT)); + else + ret = da9052_reg_update(gpio->da9052, (offset >> 1) + + DA9052_GPIO_0_1_REG, + DA9052_GPIO_MASK_LOWER_NIBBLE, + register_value); + + return ret; +} + +static int da9052_gpio_to_irq(struct gpio_chip *gc, u32 offset) +{ + struct da9052_gpio *gpio = to_da9052_gpio(gc); + struct da9052 *da9052 = gpio->da9052; + + return da9052->irq_base + DA9052_IRQ_GPI0 + offset; +} + +static struct gpio_chip reference_gp{ + .label = "da9052-gpio", + .owner = THIS_MODULE, + .get = da9052_gpio_get, + .set = da9052_gpio_set, + .direction_input = da9052_gpio_direction_input, + .direction_output = da9052_gpio_direction_output, + .to_irq = da9052_gpio_to_irq, + .can_sleep = 1; +}; + +static int __devinit da9052_gpio_probe(struct platform_device *pdev) +{ + struct da9052_gpio *gpio; + struct da9052_pdata *pdata; + int ret; + + gpio = kzalloc(sizeof(*gpio), GFP_KERNEL); + if (gpio == NULL) + return -ENOMEM; + + gpio->da9052 = dev_get_drvdata(pdev->dev.parent); + pdata = gpio->da9052->dev->platform_data; + + gpio->da9052 = dev_get_drvdata(pdev->dev.parent); + gpio->gp = reference_gp; + gpio->gp.ngpio = 16; + if (pdata && pdata->gpio_base) + gpio->gp.base = pdata->gpio_base; + else + gpio->gp.base = -1; + + ret = gpiochip_add(&gpio->gp); + if (ret < 0) { + dev_err(&pdev->dev, "Could not register gpiochip, %d\n", ret); + goto err_mem; + } + + platform_set_drvdata(pdev, gpio); + + return 0; + +err_mem: + kfree(gpio); + return ret; +} + +static int __devexit da9052_gpio_remove(struct platform_device *pdev) +{ + struct da9052_gpio *gpio = platform_get_drvdata(pdev); + int ret; + + ret = gpiochip_remove(&gpio->gp); + if (ret == 0) + kfree(gpio); + + return ret; +} + +static struct platform_driver da9052_gpio_driver = { + .probe = da9052_gpio_probe, + .remove = __devexit_p(da9052_gpio_remove), + .driver = { + .name = "da9052-gpio", + .owner = THIS_MODULE, + }, +}; + +static int __init da9052_gpio_init(void) +{ + return platform_driver_register(&da9052_gpio_driver); +} +module_init(da9052_gpio_init); + +static void __exit da9052_gpio_exit(void) +{ + return platform_driver_unregister(&da9052_gpio_driver); +} +module_exit(da9052_gpio_exit); + +MODULE_AUTHOR("David Dajun Chen <dchen(a)diasemi.com>"); +MODULE_DESCRIPTION("DA9052 GPIO Device Driver"); +MODULE_LICENSE("GPL"); +MODULE_ALIAS("platform:da9052-gpio");

14 years

CFP: Please test July 6th daily Images

by Tom Gall

All, We need your help. Over the weekend we "upgraded" our building of natty based images from using live-helper 2 to live-build 3. (same tool just slightly newer name and more shiny) It is possible that given evolutionary changes to the build tool that there maybe new and interesting bugs introduced. 11.07 isn't that far away so time spent testing NOW will mean less late night debug sessions later. Here's what you need to do. >From snapshots.linaro.org download a the July 6th build: one of alip, developer, nano or ubuntu-desktop and a hwpack for your board. Use linaro-media-create to get the image onto an SD. Boot said combination on your board and report the results on qatracker.linaro.org. Please take some time to DO THIS TODAY. The earlier we find regressions in what will be 11.07 the better. If you're able to test more than one image/hwpack combination, that's all the more awesome, with awesome sauce! Thanks! -- Regards, Tom "We want great men who, when fortune frowns will not be discouraged." - Colonel Henry Knox Linaro.org │ Open source software for ARM SoCs w) tom.gall att linaro.org w) tom_gall att vnet.ibm.com h) tom_gall att mac.com

14 years

Updated armel cross toolchains for lucid/maverick/natty releases

by Marcin Juszkiewicz

Hi Linaro backport PPA [1] got updated to latest versions of armel cross toolchains -- oneiric packages were used as a base. What got changed: - gcc 4.4 was updated to 4.4.6-3ubuntu1 - gcc 4.5 was updated to 4.5.3-1ubuntu2 - binutils was updated to 2.21.52.20110606-1ubuntu1 - eglibc was updated to 2.13-6ubuntu2 - gcc 4.6 was provided as 4.6.0-14ubuntu1 in Maverick, Natty - gcc-defaults-armel-cross was updated to 1.6 in Maverick, Natty (uses gcc-4.6 as default) There is no gcc-4.6 for Lucid currently as it requires newer versions of few libraries (mpfr, mpc) and one of rule of this PPA is "do not update packages which may affect other packages". Please test them and report any bugs found. 1. https://launchpad.net/~linaro-maintainers/+archive/toolchain/

14 years

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev