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
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
>>
>
>
>
>
>
>
>
>
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)
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)
Hi,
Here's the weekly status report from the Infrastructure team. Enjoy!
You can read it in its formatted glory at
https://wiki.linaro.org/Platform/Infrastructure/Status/2011-02-10
Thanks,
James
* Period: (20110203-20110209)
* PM: None
* Past reports : https://wiki.linaro.org/Platform/Infrastructure
* Burndown information : http://status.linaro.org/linaro-infrastructure.html
* Stakeholders process: https://wiki.linaro.org/Platform/Infrastructure/CurrentProjects
== Key Points for wider discussion ==
* None this week
== Team Highlights ==
* First iteration of https://android-build.linaro.org is up and running.
* First prototype of https://wiki.linaro.org/Platform/Android/Specs/AndroidMirrorService coded.
* Wrote design and implementation plans for PatchTracking.
* Got series support in status.linaro.org deployed.
* Mattias is making progress with IT issues within ST-E.
* 3/5 of the team is booked for Budapest.
* Stakeholders meeting prioritized some new requests for working on soon.
* Assisted with getting a hwpack for the s5pv310 set up. It is now building daily and the Landing Team can improve it. http://snapshots.linaro.org/11.05-daily/linaro-hwpacks/lt-s5pv310/
* Two weeks of facilitating the co-ordination with IS has led to as many tickets being completed by them as the previous two months.
== Upcoming Deliverables ==
* status.linaro.org delivered to satisfaction of interested parties within the next week.
== Risks / Issues ==
* Mattias unable to work productively due to IT restrictions in ST-E (2 weeks, v. high): some progress. Has process now to request changes, but not all have been acted on yet.
* Mattias lacking a board to work with (2 weeks, medium): some progress, but proposed board is private currently, and is apparently wanted for use by several people. Mattias will work on a project that doesn't require a board in the meantime.
* Deepti lacking a board to work with (many weeks, high): A Panda board is earmarked, but Deepti has not yet received it. Working on tasks that don't require it, but unable to participate in image testing.
* PatchTracking requires deploying Patchwork (0 weeks, high): Co-ordination of this will start with IS immediately.
* Patchwork seems unmaintained upstream (0 weeks, low): Will monitor. Can always use a fork for our purposes.
* Gerrit instance needed for Android (0 weeks, high): Co-ordination with IS has started. Waiting to hear from them if we can get it this month, and what we need to do to help with that.
* OurOwnOffspring lacking hardware (many weeks, medium): x86 for master is ready and waiting, Joey has ordered XMs for slaves, should be here this month.
* Want a Hudson instance for Continuous Integration purposes (many weeks, medium): Discussions with IS, and they will provide one, but timeframe is unclear at this point. Will host ourselves until IS can provide.
* No project manager for the team (0 weeks, high): Joey is working to solve. James will do these duties for the team in the meantime.
== Miscellaneous ==
* Deepti spent 1 day at IBM internal meeting this week.
* Guilherme on vacation this Friday.
* James on vacation 17th-22nd February.
* Multiple absences planned for March.
In the reference architecture in ppt, we can directly wait for the RSZ interrupt, if we configure the hardware pipe. It was my mis-understanding as each of those hardware blocks can deliver interrupts too. In that way ARM needs to just work at finished frame, like forward it to the display or codec engine etc. V4L2 can be easily used for such hardware architecture.
But if a ISP chooses to do the above work in a seperate (dsp)processor, can we still use V4L2? OMX seems better in such environment. Let me know if there is any other alternative.
Regards,
Subash
[ Added linaro-dev for a wider diffusion ]
On Wed, 9 Feb 2011, Arnd Bergmann wrote:
> On Monday 07 February 2011, Paul E. McKenney wrote:
> >
> > The February 24th feature freeze is coming up very quickly. We therefore
> > need any kernel patches that are to be included into the 11.05 Linaro kernel
> > release to be submitted to linaro-dev (CCing nicolas.pitre(a)linaro.org)
> > as well as upstream as soon as possible. Otherwise, we cannot guarantee
> > that they will be included in the upcoming Linaro kernel release.
>
> I suppose by submitting upstream, you mean that the patches need to show
> up in one of the trees that are part of linux-next, right?
>
> The development phase for 2.6.38 is closed, and the merge window for 2.6.39
> will not be open until the Linaro feature freeze, so that is the only
> place where patches heading for upstream can go at the moment.
Here's what I intend to do with regard to the Linaro kernel to be used
for the 11.05 release.
I'll create a linaro-2.6.38 tree which will be seeded with v2.6.38-rc5
which should happen sometimes next week. That will be about the same
level of functionality as what we currently have in linaro-2.6.37 for
the ARM parts, and merging the remaining extra patches found in
linaro-2.6.37 not to be found in 2.6.38 yet should be quite easy.
So if you have more patches that you want to see included in the 11.05
Linaro release then it is a good thing to rebase them to the latest
mainline (currently 2.6.38-rc4) and make sure they are validated and
sent my way _before_ February 24th. Incidentally, while at it, this
would also be a good time to send those patches to the respective
upstream maintainers for inclusion into the mainline kernel tree during
the upcoming merge window.
Nicolas
Hi,
I have the task to check systemtap behaviour. It requires .config
(found in /boot so OK), Module.symvers and vmlinux. Well, I could
recompile the kernel but I have been used getting these packaged by
our integration team at Texas Instruments ;-)
I am wondering if these shall not be provided to end users and how
they could be provided. From various reading, I have the impression I
would need a linux-image-debug-xxx package:
* is there some for various hwpacks (especially panda in my case) ?
* is it sufficient ? vmlinux was not packaged as such by our
integration team so I have doubts about it
In any case, I am anticipating kernel recompilation. Is there any
Linaro deviation from Ubuntu method ?
thanks for your help
Regards
Fred
Hello Everyone,
The minutes of the weekly call can be found at:
https://wiki.linaro.org/WorkingGroups/PowerManagement/Meetings/2011-02-09
Highlights:
- thermal policy code ready to be published
- problems with work items where we're waiting for upstream feedback
since they stay open for long time, needs Linaro-wide solution on how
to handle
Regards,
Amit
Hi,
I am trying to boot my efikamx netbook with the Linaro 37 kernel. I
only have a usb-serial interface so I can't really see where I get
stuck.
I manage to boot a small ramfs with usb-serial suppport on the Genesi
kernel 2.6.31.14.12, but I haven't succeeded to get any usb-serial
output on the Linaro 37 kernel.
I still use the u-boot provided by Genesi. I will switch to the Linaro
u-boot tomorrow to see if that helps.
Is anyone running a mainline kernel on efika-mx together with an
usb-serial-connection?
Thanks,
Per