linaro-dev February 2011

linaro-dev@lists.linaro.org

120 participants
166 discussions

Minutes & Actions: Kernel Working Group meeting of Feb 07, 2011

by Mounir Bsaibes

Greetings, Enclosed you'll find a link to the agenda, minutes and actions from the Linaro kernel working group weekly meeting of Feb 07, 2011. https://wiki.linaro.org/WorkingGroups/KernelConsolidation/Meetings/2011-02-… === Summary === * Redesigned flash remapper and started implementing UBD based remapper * Reposted omap3/4 Thumb-2 compatiblity patches, generally positive feedback and some positive test results * MX53 uboot support done, already in Wolfgang's master tree. * Posted proposal for clk_enable/clk_prepare API & locking semantics * Completed next revision of clk API patches with clk_prepare interface * Started proof of concept port of clk_prepare API for versatile, integrator and realview * Discussed Linaro Android platform goals and possible future work items, see minutes here: https://wiki.linaro.org/Platform/Android/2011-02-04 * Submitted CLOCK_BOOTTIME patches to lkml. * RTC re-work, large amount of changes to push for 2.6.39. * Developed algorithm for finding PLL multiplier/divider values automatically with least divisor (helps in faster locking) consulting with TI hw design team. * Moved bss to SDRAM as per community suggestions. * Linaro kernel maintenance, merged multiple ARM patches into Linaro tree * Device Tree * devicetree/arm on git://git.secretlab.ca/git/linux-2.6 has everything needed to turn on basic device tree support for any platform. * Similarly, u-boot just needs to have the CONFIG_OF_LIBFDT defined to turn on device tree support. * IRQ handling is still a problem and only one interrupt controller can be supported at the moment, but Lennert is working on a solution. * Posted a patch that will allow dt and non-dt device registration to co-exist peacefully by snooping platform device registrations. I could use some feedback and testing. * Looking into merging the the basic dt support into Nicolas' tree this * Added basic device tree support for Samsung's SMDKV310 board. * Bootargs and memory information is obtained from the device tree correctly. * Added device tree support in Samsung's watchdog timer driver and driver works fine in both DT and non-DT mode. * Submitted patches for enabling basic device tree support for SMDKV310 board. * Andy Green: TI looking to port their BSP from 2.6.35 to 2.6.38. They have been getting some of their patches into mainline-ready form, and will continue maintaining their BSP on recent mainline. Mounir

14 years, 2 months

Minutes & actions: Toolchain Working Group meetings of Feb 9 & 7, 2011

by Mounir Bsaibes

Greetings, Enclosed you'll find a link to the agenda, minutes and actions from the Linaro toolchain working group weekly meetings of Feb 07 & Feb 09, 2011. https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2011-02-07 https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2011-02-09 == Summary == * Did the 2011.02 releases * Linaro GCC 4.4 and 4.5 * Third release of Linaro GDB (second one of interest) * First release of Linaro QEMU * Swing-modulo-scheduling based performance work is ready, pending copyright issues * Perparing to get the string routines into Ubuntu before the feature freeze * IFUNC work has started going upstream. EABI addition is partly approved Mounir

14 years, 2 months

Linaro 11.05 Weekly Testing 2011-02-10

by Jamie Bennett

Hi, This is a message sent out once per week to call on our community to help test the Linaro evaluation builds we produce. If you have supported hardware, as found on: http://snapshots.linaro.org/11.05-daily/linaro-hwpacks/ please help our initiative by testing: Headless: http://snapshots.linaro.org/11.05-daily/linaro-headless/ ALIP: http://snapshots.linaro.org/11.05-daily/linaro-alip/ Netbook: http://snapshots.linaro.org/11.05-daily/linaro-netbook-efl/ Developer Tools: http://snapshots.linaro.org/11.05-daily/linaro-developer/ Make your way to: http://wiki.linaro.org/Releases/DailyBuilds 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

14 years, 2 months

Fun with libtool and cross-builds

by Wookey

[This was also posted to debian-devel but I got the linaro addesss wrong: http://lists.debian.org/debian-devel/2011/02/msg00196.html] Libtool is intended to make library linking 'just work' whatever the details of your build mechanisms are. However in Debian/Ubuntu cross-building it seems to go out of its way to make it not-work. The problem is papered-over when using i386 machines, or amd64 machines and a new-enough (or old enough) version of binutils, but this seems to me to be a very poor solution as it has to be put into the linker for every cross-combination people might choose to build between. Making libtool actually do the right thing would be much better. In fact it would be correct, and we like correctness. This is not a new problem. In a bit of research I found a post suggesting it was actually broken in 2002 (I've not yet looked into this). (a long list of previous posts on the issue from OE, Debian, Ubuntu, astlinux and buildroot people is at the end of this mail). Now, before I get too carried away I want to check that I'm not just misunderstanding something. It seems faintly crazy that this very straightforward cross-comiling problem is not already solved. And I have to admit that I have always done my best to avoid understanding the details of libtool (like most people). However I think the time has come to sort this out properly, if in fact it hasn't been already. The problem ----------- We are crossbuilding Debian packages, that build libraries, which link to other libraries. There are lots of those, but I'm using unixodbc and libprce3 here as they seem fairly typical examples. The libraries to link against are installed into a directory, historically /usr/<triplet>/lib, but moving to /usr/lib/<host-multiarchtuple> using multiarch mechanisms. They could also be in sysroot locations if using sysroot mechanisms). The point is that they are _not_ in /usr/lib (or /usr/lib/<build-multiarchtuple> in multiarch world). libtool gets most of this process right (or at least not wrong), until the library is installed into the package location typically (debian/tmp/usr/lib) using libtool's 'install' mode, which then calls libtool with mode 'relink'. At this points it calls the linker and adds -L/usr/lib on the front - thereby adding this path in front of the default cross-compiler path. If called without this -L, or called with -L/usr/<triplet>/lib (i.e the correct path, wherever that is), then everything is fine because the libraries for the correct (host) architecture are found. So there are 2 ways to get this right and one way to get it wrong, which is the one libtool picks. The workarounds which mean this has not yet been fixed are that the linker used to just issue a warning and ignore libraries which it didn't understand: /usr/lib/libgcc_s.so: file not recognized: File format not recognized And more recently it has been taught to understand specific architectures enough to decide they are the wrong ones: /usr/arm-linux-gnueabi/bin/ld: skipping incompatible /usr/lib/libpthread.so when searching for -lpthread /usr/arm-linux-gnueabi/bin/ld: skipping incompatible /usr/lib/libpthread.so when searching for -lpthread /usr/arm-linux-gnueabi/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc However on amd64 machine with armel toolchain and binutils-arm-linux-gnueabi_2.20.51.20100908-0ubuntu2cross1.52 the skipping fails for static libs: /usr/lib/libc.a: could not read symbols: File format not recognized and the build fails. on i386, or later versions of binutils, these are skipped the same as the .so s. However as stated above I don't think relying on this linker behaviour is any real sort of solution - we should get libtool to either leave it up to the toolchain, or pass the correct explicit path. Here is the example unixodbc case that illustrates the problem: (Built with: xdeb -a armel --apt-source unixodbc, which runs: dpkg-buildpackage -rfakeroot -d -us -uc -aarmel -b -tc ) make[4]: Entering directory /home/chroot-user/build/unixodbc-2.2.14p2/samples' test -z "/usr/lib" || mkdir -p -- "/home/chroot-user/build/unixodbc-2.2.14p2/debian/tmp/usr/lib" /bin/bash ../libtool --mode=install /usr/bin/install -c 'libboundparam.la' '/home/chroot-user/build/unixodbc-2.2.14p2/debian/tmp/usr/lib/libboundparam.la' libtool: install: warning: relinking libboundparam.la' libtool: install: (cd /home/chroot-user/build/unixodbc-2.2.14p2/samples; /bin/bash /home/chroot-user/build/unixodbc-2.2.14p2/libtool --tag CC --mode=relink arm-l$ libtool: relink: arm-linux-gnueabi-gcc -shared .libs/boundparam.o .libs/helper.o .libs/cboundtimestampparam.o -Wl,--whole-archive ../autotest/.libs/libgtrtstlc.$ /usr/lib/gcc/arm-linux-gnueabi/4.5.1/../../../../arm-linux-gnueabi/bin/ld: skipping incompatible /usr/lib/libpthread.so when searching for -lpthread /usr/lib/gcc/arm-linux-gnueabi/4.5.1/../../../../arm-linux-gnueabi/bin/ld: skipping incompatible /usr/lib/libpthread.so when searching for -lpthread /usr/lib/gcc/arm-linux-gnueabi/4.5.1/../../../../arm-linux-gnueabi/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc /usr/lib/libc.a: could not read symbols: File format not recognized collect2: ld returned 1 exit status libtool: install: error: relink libboundparam.la' with the above command before installing it make[4]: *** [install-libLTLIBRARIES] Error 1 I note that when doing this libtool --config shows that it does have an idea of where the right place is: maverick)wookey@kh:~/ubuntu/maverick/build/pcre3$ ./libtool --config | grep sys_lib sys_lib_search_path_spec="/usr/lib/gcc/arm-linux-gnueabi/4.4.5 /usr/arm-linux-gnueabi/lib" sys_lib_dlsearch_path_spec="/usr/arm-linux-gnueabi/lib /lib /usr/lib /usr/local/lib" I haven't worked out exactly when and where libtool applies those, but as it seems to get the compiling and linking part right they may be being used (or the compiler defaults are just working as they should). It's only the install/relink phase that is bust (so far as I can tell). pcre3 provides a simpler and quicker-to-build example of the same problem. Here are various previous postings on the subject: Simon Richter in march last year, to libtool list: http://lists.gnu.org/archive/html/libtool/2010-03/msg00013.html (no response) Loic Minier in October last year, to libtool list http://thread.gmane.org/gmane.comp.gnu.libtool.bugs/7626 (response: yes that seems to be a bug, no time to fix now, does sysroot option fix it? 'Not for me' said lool) Philip Prindeville from astlinux, July 2010, to libtool list http://lists.gnu.org/archive/html/libtool/2010-07/msg00018.html (response: send us some reproducible examples, and 'heres a ptch for the sysroot-and-deleting-.la-files case') Martin Panter from Openembedded in December 2010, to libtool-patches-gnu http://osdir.com/ml/libtool-patches-gnu/2011-01/msg00025.html which includes a patch to fix it. (response: useful discussion of possible patches) Opinions on the best way to make libtool do the right thing both now and in the future are welcome. Ther are quite a few patches in the above threads providing different solutions, and I haven't yet determined which of them have been included where. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/

14 years, 2 months

Proposal for a MIPI System Trace Module driver

by Philippe Langlais

Hi All, This proposal is a call for contribution for a STM driver and its possible usages in kernel tracing infrastructure. I'd like to know if another ARM SoC plan to use or already use STM or some similar hardware enabling the same kind of MIPI trace points. If yes, we can share our works. What's STM? Hardware overview: ------------------ This hardware collects and provides simple tracepoints, so a system processor (in our case the main ARM CPU, or some small CPUs and DSPs) can write some data, up to 8 bytes, into a register and out comes a log entry with a time stamp on one of 256 channels. Also hardware tracepoints are supported. This module external interface is a pad on the chip which complies to the MIPI System Trace Protocol v1.0, and the actual trace output can be read by an electronic probe, not by software so it cannot be intercepted by the CPU and reach Linux userspace. Bandwidth depends on number of lines & bus frequency (for example on ux500 SoC 4 lines at max 100MHz eg max 400Mbit/s shared between 7 cores). Transmit FIFO size: 256 samples up to 8 bytes. Software overview: ------------------ - Put this platform driver in drivers/misc kernel tree - API: Configuration functions (trace output clock frequency, trace mode) Enable/disable STM trace functions Alloc/free STM trace channel functions Set of low level atomic trace functions for 1, 2, 4 or 8 bytes with & w/o time stamp Higher level lockless trace function (alloc a channel, output the trace buffer with arbitrary length then free the channel) Expose a debugfs interface for example to read/reset overflow status File IO output console like interface (open, close, write) Implement mmap to expose all STM trace channels memory access to userspace IOCTLs interface for configuration, enable/disable STM, alloc/free STM channels ... - Write atomicity and write order on STM trace channels is ensured by the fact we allocate one channel by execution thread (no concurrent access) Possible usages: ---------------- - Provide multiple output consoles for traces - Use it in standard kernel tracing infrastucture, possibilities: - Insert STM trace calls before trace ring buffer write - Substitute time stamping & trace ring buffer by STM - Implement the same functionality than the Ftrace function tracer without lock problem & very low overhead (in 8bytes + auto time stamp on 32bits arch we can have the function entry & its caller like Ftrace do). Remark: Problem is around lock to extract trace in right order when tracepoints buffer size > 8bytes (real time disturbance when tracing), a prototype must be done to find a clever lock system (use multiple channels) - other ideas... Many experiments must be done to validate its usage in kernel tracing infrastructure (performance, trace overflow, real time behavior...) Regards, Philippe

14 years, 2 months

Re: [PATCH 2/3] xloader-panda / new patchset sent to x-loader list

by Andy Green

On 02/08/11 15:40, Somebody in the thread at some point said: > Andy Green wrote, on 02/08/2011 08:54 PM: > [..] >>> btw, could you fix the following checkpatch warnings as well: Hi - I just sent a 17-patch patchset to the x-loader list cleaning out all the checkpatch problems in OMAP4 and Panda specific .c files, as well as fixing the compiler warnings and enabling -Werror. The code is refactored and symbols added to remove the magic constant addresses. I also found what look like some small bugs in the original code and provide fixes. The original patches to fix the OTG power Panda issue are included uplevelled and modified according to yesterday's comments. I didn't see it on the x-loader list yet but that may be because I couldn't figure out how to join the x-loader google list with the linaro.org address and it's held in moderation. -Andy

14 years, 2 months

Mentor Team Weekly Meeting - 2011/02/09

by Matt Waddel

The minutes from our weekly meeting can be found here: https://wiki.linaro.org/Mentoring/Status/2011-02-09 Highlights are: == Key Points for wider discussion == * Status of https://wiki.linaro.org/Mentoring * Suggestions and requested for HowTo and FAQ sections in wiki == Team Highlights == * Reviewed remaining items in "Linaro Mentoring Tasks" list * GIT usage in Linaro - Andy * Adding platforms to linaro-media-create - Andy * Debian Packaging skills - Matt * Ubuntu Developer Process - Matt * New hire/assignee checklist - Both * New hire readiness (people.linaro.org and git.linaro.org accounts) - Andy * Collected survey results from tech leads and assignees - Matt * Use survey results to develop training items - Both == Upcoming Deliverables == * Finish defined portions of wiki === Blueprint Milestones === * None == Risks / Issues == * Risk - Unable to recruit trainers within member organizations * Mitigation - Perform mentoring tasks from within this team * Mitigation - Break responsibilities into smaller portions and recruit multiple trainers

14 years, 2 months

Re: Re: v4l2 vs omx for camera

by Robert Fekete

Hi, Thanks for your ideas. If I am not mistaken all subdevices in the ISP media pipe could be interconnected without the need from ARM intervention. But I could be wrong. Why not ask Hans Verkuil and Laurent Pinchart? Sorry for bringing you in like this but you are the true experts in v4l2. Do you guys have any comments on the discussions in this mail? /BR /Robert Fekete On 8 February 2011 13:42, SUBASH PATEL <subash.rp(a)samsung.com> wrote: > Hi Robert, > > > > Thanks for sharing the slide. It was informative on OMAP3. My reference was > wrt to a similar hardware itself. > > > > In slide 20, the green blobs are mentioned to be drivers. Lets consider an > example where camera sensor is connected on a CSI2 interface. > > On every CSI2 interrupt (assuming frame based), we will have to take out > frame and pass on to each of ISP block in the diagram. ARM will > > be involved. > > > > If we are speaking of performance like HD/Full-HD @ 30fps, imagine the > processing required by the ARM processor for this. Everytime it has to > > take frame from one component and pass onto another until resizer gives a > final frame. From there it has to go to an encoder for encoding too. > > But if we use a dedicated imaging processor, which will run on its own and > provide us the desired frames (last yellow box - ISP resizer > > output), ARM can concentrate on something else in the meantime. > > > > We cannot do such a thing with V4L2. As far my knowledge is, since this is > two processor environment, we require some client/server architecture. OMX > > comes handy in these cases as it has all of client, core and component > parts. Thats why gstreamer is looked as a broker by many media applications. > > Gstreamer will appropriately forward controls to v4L2 or OMX depending on > how the hardware is delivering the frames. > > > > Regards, > > Subash > > > > ------- *Original Message* ------- > > *Sender* : Robert Fekete<robert.fekete(a)linaro.org> > > *Date* : Feb 08, 2011 17:40 (GMT+05:30) > > *Title* : Re: v4l2 vs omx for camera > > > Hi, > > This presentation from Hans Verkaul last V4L2 summit describes the Media > controller which is s perfect fit for an ISP. Pay special attention to Slide > 20. Yellow boxes are input/outpud devices, green blobs are > subdevices/drivers > > Thus V4L2 will fit any camera sensor whether it is yuv or raw camera. also > providing a neat kernel interface with all source available for customers > and happy hackers to use. > > BR > /Robert F > > On 8 February 2011 11:42, SUBASH PATEL <subash.rp(a)samsung.com> wrote: > >> Hi Sachin, >> >> I think when we speak of OMX, we are referring to the OMX-IL layer. This >> layer is supported as middleware component. >> >> I am putting down my experiences as below: >> - Generally Camera gives two streams. One is preview which can be YUV/RGB >> and another is capture (YUV/RGB/JPEG). Preview >> frame format must be in one of display systems supported(YUV/RGB) format. >> Else color conversion is required in the path. >> This adds overhead and latency. >> >> - If we have a camera sensor which is smart, i.e., it is capable of >> providing the processed image(RGB, YUV) frame rather >> than RAW pixel dump, and ARM is able to control the sensor interface, >> then V4L2 framework camera driver would work. >> User space wrapper/app would be invoking the V4L2 ioctl's to control the >> camera. >> >> - If we have a RAW sensor which produces, say Bayer pixel format, we will >> have to have an image pipe to process it before >> converting this to one of RGB/YUV formats. Image pipes involves >> conversions, resizing etc. It would be an overhead >> to do these stages in ARM, and some vendors have proprietary imaging >> processors for it. These processors may run a custom RTOS. >> >> They may have built a private IPC layer into linux kernel and proprietary >> OS. OMX layer works in such scenarios. >> A concept called distributed OMX works on RPC mechanism. OMX client calls >> will now land up on the image processor from ARM. >> Again some proprietary driver/s will be invoked from the remote OMX >> component which would do the image processing mentioned above. >> >> User space wrapper/app aka OMX client, is a set of OMX calls, which will >> get routed to proper OMX component through OMX core. This >> is similar to V4L2 client, but instead of controlling camera through >> IOCTL's, we use OMX specific functions Get/Set methods. >> >> From my view, the choice of choosing V4L2 or OMX is basically depending on >> the type of sensors and presence of dedicated hardware. >> If we already have a dedicated imaging processor, V4L2 can be absent, and >> we will have to leverage the OMX because of its capability. >> But if we are integrating a new sensor which has in-built accelerator, it >> makes sense to reduce the silicon area on SoC and use V4L2 instead. >> >> Regards, >> Subash >> -------Original Message-------- >> Sent: Sachin Gupta <sachin.gupta(a)linaro.org> >> Date: Tue, 8 Feb 2011 14:25:21 +0530 >> Subject: Re: v4l2 vs omx for camera >> >> >> >> Arnd, >> >> you are correct that omx and v4l2 sit at different levels one being >> userside API and other being kernel API.But from the point of view of >> integrating these API's in OS frameworks like gstreamer,Android camera >> service they are at the same level.I mean one will have to implement >> gstreamer source plugin based on either v4l2 or Omx.Also the way vendors(STE >> and TI) have gone about implementing OMX, they completely bypass v4l2 .The >> major reason being code sharing among different OS environments.The kernel >> side for OMX implementation just facilitates RPC between imaging coprocessor >> and ARM side.. >> >> Sachin >> >> >> On Tue, Feb 8, 2011 at 2:00 PM, Lee Jones <lee.jones(a)linaro.org> wrote: >> >> Bringing in my boys. >> >> Robert, Linus, what say you? >> >> >> On 07/02/11 12:33, Arnd Bergmann wrote: >> > On Monday 07 February 2011, Sachin Gupta wrote: >> >> In Multimedia WG we have been posed with a question regarding best >> way >> >> to expose low level API for camera.so this a questions mainly about >> pros and >> >> cons of v4l2 and omx over each other.So to involve a wider community to >> >> discuss this topic I am floating this mail on linaro-dev.Please share >> your >> >> view/experiences.Also please involve any body else in this mail who can >> >> provide valuable inputs on this. >> > I've had to look up with "omx" actually stands for [1][2], but from >> > an outsider view, they don't seem to be mutually exclusive or even >> > competing interfaces. v4l2 is the interface you use to get at camera >> > data, in whatever format the camera gives you. There are no alternatives >> > to that. OpenMax gives you a way to accelerate video codecs, which >> > is good, but this sits a layer higher up in the stack. Supporting omx >> > is probably a good idea, but would be totally optional. >> > >> > Arnd >> > >> > [1] http://www.khronos.org/openmax/ >> > [2] http://www.freedesktop.org/wiki/GstOpenMAX >> > >> >> > _______________________________________________ >> > 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 >> >> >> >> -------Original Message-------- >> Sent: Loïc Minier <loic.minier(a)linaro.org> >> Date: Tue, 8 Feb 2011 10:35:38 +0100 >> Subject: Re: Efikamx bootloader help >> >> hey adding my bits where I can On Tue, Feb 08, 2011, Eric Miao wrote: > 2. >> The three possible boot up methods: a) Internal SPI NOR flash, b) the > >> MicroSD card behind the battery and c) the normal SD card at the left > >> side, not really sure about the situation on Efika MX (smart top) as > I >> don't have one in my hands efikamx only has SD and internal flash; there >> might be other boot methods like serial or USB, but I don't think we need to >> care too much about these > 4. The boot sequence of the Internal SPI NOR >> flash, as it looks to me that > it's trying to find boot.scr from either the >> MicroSD or SD card on the > first partition? Also it would be helpful to >> document the envionment > variables of this specific u-boot. on my efikamx, >> this is the bootcmd it had when I received it and corresponding variables: >> bootcmd=run pata_boot pata_boot=run bootargs_base bootargs_pata >> bootargs_base=setenv bootargs noinitrd console=ttymxc0,115200 console=tty1 >> bootargs_pata=setenv bootargs ${bootargs} root=/dev/sda2 ${bootinfo};run >> boot_pata bootinfo=rw boot_pata=run base_cmds;ide reset;fatload ide 0:1 >> ${loadaddr} ${kernel}; bootm ${loadaddr} base_cmds=run base_cmd1;run >> base_cmd2;run base_cmd3;run base_cmd4;run base_cmd5;run base_cmd99 >> loadaddr=0x90007FC0 kernel=uImage base_cmd1=pmic 15 0x00400022;mw.l >> 0x73fa84b8 0xe7 1;mw.l 0x73fd4014 0x59239100 1 base_cmd2=mw.l 0x83fd9010 >> 0xcaaaf6d0 1;mw.l 0x73f88000 0x01025200 1;mw.l 0x73f84000 0x20 1 >> base_cmd3=mw.l 0x83fd9004 0x333574aa 1;mw.l 0x83fd900c 0x333574aa 1; >> base_cmd4=mw.l 0x83fd9020 0x00f48b00 1;mw.l 0x83fd9024 0x00f49700 1;mw.l >> 0x83fd9028 0x00f48700 1 base_cmd5=mw.l 0x83fd902c 0x00f48400 1;mw.l >> 0x83fd9030 0x00f44e00 1; > 5. If Linaro is going to support u-boot for Efika >> MX/SB, it's better to > follow what is in upstream. However, there could be >> some differences > between the u-boot in the recovery/installing image >> downloadable from > powerdeveloper.org and the one in upstream. We might >> need to figure > out those differences and see how to handle them. That was >> indeed the case; Marex, who developed the upstream u-boot bits, told me the >> same u-boot would work on SD and on flash; the one I've built from mainline >> uses the default imximage.cfg settings which is "BOOT_FROM spi", yet works >> fine from a SD card. So it seems the same u-boot can be used for both SD and >> flash -- just with different bootcmd. Cheers, -- Loïc Minier >> _______________________________________________ >> linaro-dev mailing list >> linaro-dev(a)lists.linaro.org >> http://lists.linaro.org/mailman/listinfo/linaro-dev >> > > > > > > > >

14 years, 2 months

Build assembler errors on Beagleboard ALIP

by Kurt Taylor

I am seeing the following when trying to build pulseaudio on a Beagleboard running a current ALIP daily: ... CC libpulsecore_1.0_la-svolume_ arm.lo {standard input}: Assembler messages: {standard input}:82: Error: thumb conditional instruction should be in IT block -- `addcs r0,r8' {standard input}:83: Error: thumb conditional instruction should be in IT block -- `movcs r6,r0' {standard input}:98: Error: thumb conditional instruction should be in IT block -- `addcs r0,r8' {standard input}:99: Error: thumb conditional instruction should be in IT block -- `movcs r6,r0' {standard input}:119: Error: thumb conditional instruction should be in IT block -- `addcs r0,r8' {standard input}:120: Error: thumb conditional instruction should be in IT block -- `movcs r6,r0' ... I am using the normal pulseaudio build (bootstrap.sh, configure, make). The build worked fine on a Pandaboard with Ubuntu 10.10. It looks like something is not being detected correctly via bootstrap/configure on ALIP. I have searched and seen commits in archive for adding "-Wa, -mimplicit-it=thumb". I have added this to CFLAGS without success. Anyone else seen any thing like this? Any thoughts on what else I could try? Kurt Taylor (irc krtaylor)

14 years, 2 months

Validation team weekly status

by Paul Larson

Wiki version: https://wiki.linaro.org/Platform/Validation/Status/2011-02-10 * Period: (20110203-20110209) * PM: TBD * Past reports : https://wiki.linaro.org/Platform/Validation * Burndown information : http://status.linaro.org == Key Points for wider discussion == * None == Team Highlights == * Zygmunt and Deepti's latest dashboard changes have been merged. This brings in chart support for the toolchain working group as well as uniform object ownership management. * Discussions with outside groups on participation in LAVA development * Lab hardware arrived in Cambridge, being worked on this week * Talk on LAVA submitted for ELC * Weekly/Alpha-2 qatracker testing on several boards == Upcoming Deliverables == * No immediate milestones due. === Blueprint Milestones === * No immediate milestones due == Risks / Issues == * No Project manager currently - Paul taking care of status, meetings, etc. until this is resolved == Miscellaneous == * Spring Zhang on leave February 1st - 11th. * Paul Larson on US holiday Feb 21 * Mirsad is still at 50%, will move to alternating days schedule (marked on his calendar)

14 years, 2 months

← Newer
1
...
9
10
11
12
13
14
15
16
17
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev February 2011