linaro-dev

linaro-dev@lists.linaro.org

4332 discussions

Re: Linus being annoyed by the ARM kernel code

by Eric Miao

On Fri, Apr 1, 2011 at 11:57 PM, Philippe Robin <philippe.robin(a)arm.com> wrote: > Eric, > >>> So maybe it's just a right time to talk about using linaro ARM kernel >>> tree as a fork for quick merge of the ever expanding SoC and board >>> support, and using it more as a productive kernel for downstream. > > I don't think that a 'fork' is really a solution we are looking for. Using > Linaro as a staging and consolidation tree and at the same time improving > the upstream kernel is more what I would be looking for and what Linaro is > currently working on. Yeah, staging is more close to what I meant, a 'fork' is not appropriate here, as getting the support into mainline will always be our goal. Yet there seems to be necessary to have such a temporary place for those patches to live before the mainline is in a good enough shape. And it should not be an arm-next tree, which is just for detecting merge conflict. I expect it to be more usable, end users can just download and build a basically usable kernel. > > Regards, > Philippe > > -----Original Message----- > From: linaro-dev-bounces(a)lists.linaro.org > [mailto:linaro-dev-bounces@lists.linaro.org] On Behalf Of Eric Miao > Sent: 01 April 2011 16:44 > To: Linaro Dev > Subject: Linus being annoyed by the ARM kernel code > > Just FYI - lengthy but very interesting read, Linus was really good at > wording, enjoy heh :-) > > https://lkml.org/lkml/2011/3/17/283 > > So maybe it's just a right time to talk about using linaro ARM kernel > tree as a fork for quick merge of the ever expanding SoC and board > support, and using it more as a productive kernel for downstream. > And in the mean time, improve the mainline kernel into such a good > shape that with less crappy code we could support more platforms? > > Just a bit thought on that possibility. > > - eric > > _______________________________________________ > linaro-dev mailing list > linaro-dev(a)lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > > > > > > _______________________________________________ > linaro-dev mailing list > linaro-dev(a)lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev >

15 years

Linus being annoyed by the ARM kernel code

by Eric Miao

Just FYI - lengthy but very interesting read, Linus was really good at wording, enjoy heh :-) https://lkml.org/lkml/2011/3/17/283 So maybe it's just a right time to talk about using linaro ARM kernel tree as a fork for quick merge of the ever expanding SoC and board support, and using it more as a productive kernel for downstream. And in the mean time, improve the mainline kernel into such a good shape that with less crappy code we could support more platforms? Just a bit thought on that possibility. - eric

15 years

armhf progress: 2.6.38 kernel for the efikasb/mx, SD card bootable image

by Konstantinos Margaritis

Hi all, I tried to upload the kernel debs to ftp.debian-ports.org, but I'm getting some upload errors, so I uploaded them to http://www.freevec.org/packages/ the armhf sd card image is finally uploaded here: http://www.freevec.org/packages/efikamx-armhf.img.xz it is very recent, includes pbuilder in case one wants to try building packages for armhf. But console only, though gnome/kde packages exist in the repo. Btw, there is no video display support for the smarttop yet, but ssh works. It includes PATA/fb/ethernet/wifi(untested). Default root password: efika, default hostname: efika-armhf Enjoy Konstantinos

15 years

Re: Bug#616111: Bootstrapping a foreign architecture with multiarch

by Neil Williams

On Sat, 2 Apr 2011 05:47:47 +0200 Guillem Jover <guillem(a)debian.org> wrote: Adding linaro people and debian-embedded to CC: > Hi! > > On Fri, 2011-04-01 at 22:31:07 +0100, Neil Williams wrote: > > dpkg cannot be executed inside the chroot because it has not > > necessarily been unpacked at this stage, it certainly has not been > > configured. (dpkg is running from outside the chroot). > > (An Essential package does not need to be configured to be functional.) (It's quite possibly the wrong architecture inside the chroot, so this doesn't apply.) > > Yet dpkg-query won't work with --admindir to operate from outside: I'm checking on this - it could be an artefact of how the chroot was initially created. > > Anyways: > > > > > Multi-Arch: same packages will use > > > /var/lib/dpkg/info/<package>:<arch>.<something> > > > > > > > For Multistrap, every file in /var/lib/dpkg/ has to be created by > > > > multistrap, based on the data obtained from dpkg -e (basically the > > > > DEBIAN/ content). This data needs only to be sufficient that dpkg can > > > > correctly configure the packages once dpkg itself is able to be > > > > executed inside the new filesystem. > > > > > > It's sufficient, you just need to know the value of the Multi-Arch field. > > > > True. I've got a change now which uses dpkg -f to check the Multi-Arch > > field of the actual downloaded .deb (independent of arch) and use that > > to detect Multi-Arch: same, then lookup Architecture in the same way, > > add that to the filename of the created maintainer script etc. > > for /path/to/chroot/var/lib/dpkg/info/* > > If you are not going to install multiple instances of “Multi-Arch: same” > packages, then just keep writting the files as you are currently > doing, the next dpkg native run on that chroot image will > automatically upgrade the db layout. Which seems to be the less > onerous way to handle this. Otherwise you'll have to duplicate the > db layout handling, including format file, etc, and at that point I'd > say you are on your own. Multistrap will need to be able to create chroots containing multiple instances of Multi-Arch: same packages because it needs to be able to build cross-building chroots with libc6-dev of the build and host architectures, as well as other common dependencies like libglib2.0-0 (needed as build arch by pkg-config and as host arch by everything else). Multistrap, like debootstrap and other similar scripts, is commonly used in two roles - to create a chroot of the build architecture for building stuff in a contained environment and creating a chroot of a foreign architecture to act as a root filesystem. As with debootstrap, I see no reason to implement two different methods to creating these chroots inside a single tool, so when creating a build arch chroot multistrap uses the same processing as when creating a foreign arch chroot. That processing has to avoid a design flaw in dpkg where the normal --unpack method would attempt to run the preinst scripts. > On Fri, 2011-04-01 at 22:43:35 +0100, Neil Williams wrote: > > Further to this, --control-path doesn't include 'list' but > > $pkg:$arch.list files are created. > > This was done on purpose, .list and .conffiles are internal files, the > correct interfaces to access the information is dpkg-query. Internal files maybe, but multistrap still needs to create them to handle packages of a foreign architecture. Even once Multi-Arch is fully deployed, this will continue because the assumption with Multi-Arch is that the foreign architecture packages are being installed alongside the build architecture. When preparing a root filesystem for a foreign architecture (e.g. an embedded device), multistrap cannot put the amd64 binaries into the chroot and then add the armel, it needs to be able to unpack armel binaries into an armel chroot without running the preinst scripts or using the armel dpkg binary inside the chroot. The preinst scripts can't run on the build arch (amd64) because that would expose the chroot to the external configuration. i.e. it needs to be possible to create an armel chroot of Ubuntu natty from an i386 machine running Debian Wheezy and similarly from Ubuntu natty i386 to create a Debian Wheezy armel chroot. Currently, dpkg --unpack cannot cope with this and the existing Multi-Arch changes in dpkg do not address this problem. This has been covered before in this bug and elsewhere without resolution, but please reconsider how dpkg - even in a Multi-Arch world - needs to support unpacking foreign architecture binaries into a foreign architecture chroot and that this mandates that dpkg *must not* attempt to execute the preinst scripts inside the foreign chroot. It can *only* do so if the packages are to be unpacked into the main, external, system. When using --admindir and --instdir options to --unpack, dpkg *must* allow for the specified directories to actually be a foreign architecture chroot and act accordingly. Maybe this requires the addition of an --arch option to --unpack but it *does* need to be addressed. The files being created in /var/lib/dpkg/ are not architecture-dependent, it's only dpkg which needs to understand that when creating a foreign architecture chroot, the external dpkg must not execute the preinst scripts. That is all that is required. Working out how to configure the resulting system (probably by running the preinst scripts manually with the install argument prior to running dpkg --configure -a) and whether to use an emulator or after booting, is left to the admin of the device. dpkg doesn't need to care, it simply needs to "do the right thing" when unpacking. If this doesn't change, I will simply have to continue reimplementing dpkg behaviour in multistrap and elsewhere, causing this inconsistency to continue forever. That is not helpful. Let's solve this properly at this ideal opportunity when Multi-Arch is still in final development. I don't need to be "on my own" on this one (and I'm not anyway because a lot of people need to have this behaviour from dpkg or from some other tool which can hack around dpkg to avoid this design flaw). This can't be swept under the carpet again, it needs to be addressed. dpkg --unpack NEEDS to understand that when dealing with a foreign architecture chroot it CANNOT execute the preinst scripts. I will escalate this issue further if the dpkg team claim that this functionality is not possible to implement. Now is the perfect time to fix this long standing design flaw in dpkg. On the surface, it seems a simple thing to setup: if an --arch option is used alongside --admindir and --instdir to the --unpack command, then the preinst scripts are never executed. It doesn't have to be an option called --arch (although that is probably the easiest for embedded developers to find in the dpkg man page), it could be "--no-preinst" or something. It is just plain wrong that, even with Multi-Arch, dpkg cannot be used to bootstrap a foreign architecture into a chroot and that people like me have to invent a set of hacks to duplicate what dpkg should do itself. I've done this enough times already. -- Neil Williams ============= http://www.linux.codehelp.co.uk/

15 years

USB issues on OMAP3 (beagle/overo) with latest linaro-2.6.38 tree

by john stultz

Hey Nico, So I've been seeing USB issues on my beagle xm board with the latest linaro-2.6.38 tree, where when the system boots, lsusb will only show the hubs, but no devices. Andy reported seeing similar on his overo board, so I bisected the issue down to: 9e64bb1e9f0613093b3e34ac5402fcfef0dcc35a is the first bad commit commit 9e64bb1e9f0613093b3e34ac5402fcfef0dcc35a Author: Keshava Munegowda <keshava_mgowda(a)ti.com> Date: Tue Mar 1 20:08:19 2011 +0530 arm: omap: usb: Invoke usbhs core device initialization The usbhs intialization is invoked by all omap3 and omap4 variant board files. Signed-off-by: Keshava Munegowda <keshava_mgowda(a)ti.com> Signed-off-by: Felipe Balbi <balbi(a)ti.com> It looks like this patch is just converting the initialization over to usbhs, so it doesn't really point out the specific issue, but it does seem that something in the usbhs core isn't working properly. Any tips here? thanks -john The full bisect log is: git bisect start # good: [47dc59f22a6af00691a98975d05a8a1601714e1b] OMAP4: PandaBoard: remove unused power regulators git bisect good 47dc59f22a6af00691a98975d05a8a1601714e1b # bad: [8061f3a885ec3538bf405ff3957c205b1ab2aae4] mach-ux500: correct MMC/SDI parameters git bisect bad 8061f3a885ec3538bf405ff3957c205b1ab2aae4 # bad: [1c49cb09b5666aa0d6df3b58f6c621df92c5dd44] Merge commit '05f6894' (omap-for-linus) into linaro-2.6.38 git bisect bad 1c49cb09b5666aa0d6df3b58f6c621df92c5dd44 # bad: [0cd3fd78e5951c1631ee60a2026603d63c671d98] Merge commit '9ced9f0' (rmk/devel-stable) into linaro-2.6.38 git bisect bad 0cd3fd78e5951c1631ee60a2026603d63c671d98 # bad: [23e0d1066f429ab44305e96fbff13f1793886277] usb: Refactor irq enabling out of usb_add_hcd() git bisect bad 23e0d1066f429ab44305e96fbff13f1793886277 # good: [c9642374d0e969e8c17f4f31cd1a2bd111634227] USB: fix unsafe USB_SS_MAX_STREAMS() definition git bisect good c9642374d0e969e8c17f4f31cd1a2bd111634227 # bad: [45d1b7ae205e39e95ec65747f8871661aaa105e4] usb-gadget: fix warning in ethernet git bisect bad 45d1b7ae205e39e95ec65747f8871661aaa105e4 # good: [37db3af11f02c2ccdf44a788694da16062a0333c] usb: otg: TWL4030: Update the last_event variable. git bisect good 37db3af11f02c2ccdf44a788694da16062a0333c # good: [181b250cf53233a7a7c6d7e1e9df402506712e93] arm: omap: usb: create common enums and structures for ehci and ohci git bisect good 181b250cf53233a7a7c6d7e1e9df402506712e93 # bad: [19403165c272cc4ed00c97973e7271714b009708] usb: host: omap: ehci and ohci simplification git bisect bad 19403165c272cc4ed00c97973e7271714b009708 # good: [2236396d4d23828a0875a4d447103d0ab48aed0b] arm: omap: usb: usbhs core device initialization git bisect good 2236396d4d23828a0875a4d447103d0ab48aed0b # bad: [3b68ae73d8afa925807ebaae7eb14e2afd43f5b5] arm: omap: usb: cleanup ehci and ohci resources and devices git bisect bad 3b68ae73d8afa925807ebaae7eb14e2afd43f5b5 # bad: [9e64bb1e9f0613093b3e34ac5402fcfef0dcc35a] arm: omap: usb: Invoke usbhs core device initialization git bisect bad 9e64bb1e9f0613093b3e34ac5402fcfef0dcc35a

15 years

Notes & Actions: Linaro Graphics Working Group - Mar 30, 2011

by Alexandros Frantzis

Hi, notes and actions from our Wednesday graphics working group call are available on the wiki: + https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Notes/2011-03-30 Details about when and where of this meeting can be found here: + https://wiki.linaro.org/WorkingGroups/Middleware/Graphics#Weekly%20Public%2… Summary ======= * cairo-gles2: Patchset "Add r8g8b8a8 and r8g8b8x8 formats" accepted in pixman master (last commit: b514e63c). * glcompbench: finalizing initial version of profiling support. * skia: rebasing patches to support different upstream path. * Efikamx: 2 bugs fixed (lp #736924 and #736869). * compiz running on pandaboard * Branch http://git.compiz.org/~amaranth/mobilebling * Technical topics for 11.11 cycle presented to TSC. Risks / Issues ============== * Still no license update for Nux. * No feedback from landing teams on Mali kernel tree. * Progress on both of last week's issues (see above). Thanks, -- - Alexandros

15 years

IMPORTANT UPDATE: Details for Linaro Developer Summit in Budapest, 9-13 May

by Stephen Doel

Hi All, A reminder that you need to book your hotel reservation by next Friday to guarantee getting a room. Also, make sure you register at the links below. Also, please check the Linaro@UDS website for additional details on getting involved, specifically: - We'll be organising a couple of sessions to explain how Linaro@UDSworks later this month: https://wiki.linaro.org/Events/2011-05-LDS#An%20Introduction%20to%20the%20L…. Contact Matt.Waddell(a)linaro.org for more details - Please get involved in providing demos for the Linaro Showcase: https://wiki.linaro.org/Events/2011-05-LDS#Linaro%20Showcase%20Event%20on%2…. Contact Michael.Opdenacker(a)linaro.org for more details Thx Stephen On 25 February 2011 14:59, Stephen Doel <stephen.doel(a)linaro.org> wrote: > Hi All, > > I want to bring to your attention some important logistic points around the > Developer Summit in Budapest from 9 - 13 May ( > https://wiki.linaro.org/Events/2011-05-LDS) > > 1. Please register your attendance now: > https://forms.canonical.com/udsreg/ and here: > http://launchpad.net/sprints/uds-o. I'd like you to do this even if you > haven't yet booked your flights and so on, as we're using this attendee list > to drive a lot of our planning for the week > 2. You must make a room reservation at the hotel before* 8 April* to > benefit from our discounted rates, and to ensure you're staying where all > the action is happening ( > https://wiki.linaro.org/Events/2011-05-LDS#Hotel%20Booking) > 3. Bookmark https://wiki.linaro.org/Events/2011-05-LDS and check it > regularly, as we will grow the amount of information there to explain what's > happening and how to get the most out of the Summit as we get closer to May > (I'll also send periodic e-mails to update you all) > > -- > Thx > > Stephen Doel > Linaro Ltd > Chief Operating Officer > +44 77 66 014 247 > > -- Thx Stephen Doel Linaro Ltd Chief Operating Officer +44 77 66 014 247

15 years

Add packaging of .dtb files

by Shawn Guo

On Mon, Mar 21, 2011 at 03:25:16AM -0600, Grant Likely wrote: > - Add packaging of .dtb files into linux-image-linaro-* packages. > Loic and I discussed putting them under /lib/dtb/`uname -r`/, but > thinking about it more, it might make more sense to share the modules > directory and use /lib/modules/`uname -r`/dtbs. The dtc tool needed As the .dtb files will be naturally generated in the same kernel folder as kernel image sits, why do not we ship .dtb in the same folder as kernel image /boot? > to build the .dtbs is included with the kernel tree. > - Add relevant dtb files to boot partition in linaro-image tools The .dtb files will be generated and shipped with unique name, which comes from .dts file name. But I intend to use the generic name, maybe something like board.dtb along with l-m-c, just like we use zImage and u-boot for all platforms in boot partition, so that l-m-c does not need to encode platform specific dtb filename. Thoughts? -- Regards, Shawn

15 years

New blog engine (WordPress!) and Planet Linaro

by Michael Opdenacker

Greetings, We are pleased to announce that we now have a new blog engine (WordPress, so much better than the previous one), and also a Planet Linaro RSS aggregator. See http://www.linaro.org/linaro-blog/2011/03/31/wordpress-planet-linaro/ for details. Many thanks to Ian Davenport for the blog upgrade and to James Westby and Canonical IS for Planet Linaro. Your comments and suggestions are most welcome, as these have just been put on line. Cheers, Michael. -- Michael Opdenacker - Community Manager Linaro, http://linaro.org Cell: +33 621 604 642 IRC: 'opm' in #linaro on irc.freenode.net

15 years

Linaro 11.05 Beta Ubuntu images released

by Jamie Bennett

Hi, Linaro is pleased to announce that the 11.05 Beta Ubuntu images are now available to download. After much blood, sweat and tears we now have a total of 10 different boards supported (in our own unique hardware pack and board-neutral rootfs architecture) along with a more focused 4 different images to try out including the much coveted Ubuntu Unity interface on the Ubuntu Desktop image. This is in addition to the small nano image, the tools rich Developer image and the ARM Internet Platform (ALIP) image. A 2.6.38 kernel, state-of-the-art Linaro toolchain and a whole host of ARM-related improvements make for a thrilling release. What are you waiting for, go download it now! As always, if you have supported hardware, as found on: http://releases.linaro.org/platform/linaro-n/hwpacks/beta/ please help our initiative by testing the official Linaro Evaluation Build (LEB): Ubuntu Desktop: http://releases.linaro.org/platform/linaro-n/ubuntu-desktop/beta/ and our Developer images: Nano: http://releases.linaro.org/platform/linaro-n/nano/beta/ ALIP: http://releases.linaro.org/platform/linaro-n/alip/beta/ Developer Tools: http://releases.linaro.org/platform/linaro-n/developer/beta/ As a side note, hwpacks that have an -lt- in their name are outputs from the Linaro Landing teams, using some of their components. Make your way to: http://wiki.linaro.org/Releases/MilestoneBuilds 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 Regards, Jamie. -- Linaro Release Manager | Platform Project Manager

15 years

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev