Hi,
Kiko requested that we mass rename Releases to Cycles. This makes
sense since a release is a point in time event and we operate under a
larger cycle.
This is now done and a redirect has been put into place. As you see
references which are incorrect in wiki pages, please consider doing
some drive-by clean-up/gardening.
Thanks,
Joey
[cc'ing linaro-dev mailing list; other people will probably have the
same question]
On Mon, Mar 28, 2011 at 4:40 AM, Tixy <tixy(a)yxit.co.uk> wrote:
> On Mon, 2011-03-21 at 03:25 -0600, Grant Likely wrote:
>> For each board, I need an engineer to do the following:
>>
> [...]
>> 2) Enable CONFIG_OF and CONFIG_PROC_DEVICETREE in the kernel
> [...]
>
> Do we want these enabled by default when a supported platform is
> configured?. From someone else's example[1] I guess this would be done
> by editing arch/arm/mach-omap2/Kconfig like
>
> config MACH_OMAP3_BEAGLE
> bool "OMAP3 BEAGLE board"
> depends on ARCH_OMAP3
> default y
> select OMAP_PACKAGE_CBB
> + select USE_OF
> + select PROC_DEVICETREE
>
> Though I guess we could get PROC_DEVICETREE selected at a higher level
> if USE_OF is selected? (I'm new to Linux and its configuration methods).
I would omit these two lines. Device tree support is an optional feature.
g.
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-23
Details about when and where of this meeting can be found here:
+ https://wiki.linaro.org/WorkingGroups/Middleware/Graphics#Weekly%20Public%2…
Summary
=======
* Kernel tree for UMP and Mali device driver awaiting landing team approval.
* Benchmark/validation: cairo and Qt traces created, packaged and on developer PPA.
* cairo-gles2
* Patchset "Add r8g8b8a8 and r8g8b8x8 formats" sent to upstream Pixman for review.
* Key driver bugs affecting current work (may have been fixed, but not yet in archive):
* cairo-gles2
* eglInitialize performance on OMAP4 (LP #690821)
* color component swapping on efikamx (LP #736869)
* No GL_OES_texture_npot extension on OMAP4.
* glcompbench
* EGL_KHR_image_pixmap functionality flaky on efikamx (LP #733403)
* glcompbench rendering is not presented on screen on efikamx (LP #736811)
Risks / Issues
==============
* Aforementioned bugs may impact validation effort and release of work.
* Skia runtime detection of NEON work stalled in upstream apathy.
Thanks,
--
- Alexandros
Hi there. I'd like to start an official Linaro cookbook that has
recipes on how to build and use the various Linaro outputs. This
cookbook would answer questions such as 'how do I build Linaro GCC
from source?' and could be expanded into others.
I'm thinking of having a concise Makefile for each of the interesting
uses. The Makefiles would be executable documentation - something
that you can read and understand the steps, and also run to get a
valid output. They should be correct but very focused so, for
example, a broken download would be detected but make force a 'make
clean' instead of adding another line to the script.
I currently have a single stage cross GCC against the Linaro sysroot,
a bare metal cross GCC (unsupported), and a fancy cross GCC that works
against the Debian/Ubuntu ARM, PowerPC, and MIPS sysroots. This would
be an official Linaro product and would be updated with each monthly
release.
Thoughts? What scripts do people have tucked away that I could tidy
up and publish?
-- Michael
Hi Andy/All,
We're also planning this to be one of the (major) threads at Linaro@UDS -
https://wiki.linaro.org/Events/2011-05-LDS
Thx
Stephen Doel
Chief Operating Officer
Linaro Ltd
+44 77 66 014 247
Date: Sat, 26 Mar 2011 09:48:14 +0000
From: David Rusling <david.rusling(a)linaro.org>
To: "Gross, Andy" <andy.gross(a)ti.com>
Cc: "linaro-dev(a)lists.linaro.org" <linaro-dev(a)lists.linaro.org>
Subject: Re: ELC and memory management
Message-ID: <4EC4B3AF-39E6-4C64-B563-ADE7A69AAF37(a)linaro.org>
Content-Type: text/plain; charset=us-ascii
Andy,
good idea. Jesse will be there, so would be good to agree the problem
and start thinking of some directions...
Dave
Sent from yet another ARM powered mobile device
On 25 Mar 2011, at 21:08, "Gross, Andy" <andy.gross(a)ti.com> wrote:
> All,
>
> Are there plans of having a meeting to discuss memory management at the
ELC? There was a thread a week or so ago about all of the various
implementations of memory managers (pmem, cmem, ump, gem/ttm, etc) where
this was mentioned.
>
> Our interest in this stems from our current effort to migrate our OMAP
display and memory management functionality to the DRI/DRM model. Like
everyone else, we have to allocate large blocks of memory that are used for
display, video encode/decode, and capture. We're in the same boat of having
implementations that are not upstream.
>
> If there is not already a meeting, would it be possible to carve out some
time on one of the days where there is a graphics centric presentation
(Tues/Wed)?
>
>
> Best Regards,
>
> Andy Gross
> Linux Development Center
> Texas Instruments
> _______________________________________________
> 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
End of linaro-dev Digest, Vol 10, Issue 122
*******************************************
Hi all,
We had a discussion yesterday regarding ways in which linaro can assist
V4L2 development. One topic was that of sorting out memory providers like
GEM and HWMEM.
Today I learned of yet another one: UMP from ARM.
http://blogs.arm.com/multimedia/249-making-the-mali-gpu-device-driver-open-…
This is getting out of hand. I think that organizing a meeting to solve this
mess should be on the top of the list. Companies keep on solving the same
problem time and again and since none of it enters the mainline kernel any
driver using it is also impossible to upstream.
All these memory-related modules have the same purpose: make it possible to
allocate/reserve large amounts of memory and share it between different
subsystems (primarily framebuffer, GPU and V4L).
It really shouldn't be that hard to get everyone involved together and settle
on a single solution (either based on an existing proposal or create a 'the
best of' vendor-neutral solution).
I am currently aware of the following solutions floating around the net
that all solve different parts of the problem:
In the kernel: GEM and TTM.
Out-of-tree: HWMEM, UMP, CMA, VCM, CMEM, PMEM.
I'm sure that last list is incomplete.
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by Cisco
On Wed, Mar 23, 2011 at 3:11 PM, Grant Likely <grant.likely(a)secretlab.ca> wrote:
> On Tue, Mar 22, 2011 at 04:58:26PM -0700, Andy Doan wrote:
>> On 03/21/2011 02:25 AM, Grant Likely wrote:
>> > Here is the list of hwpacks that should be supported to the best of my
>> > knowledge. Please reply with the hwpacks you can take responsibility
>> > for:
>> >
>> > efikamx
>> > igep
>> > imx51
>> > omap3-x11-base
>> > omap3
>> > overo
>> > panda
>> > s5pv310
>> > vexpress
>>
>> Hey Grant,
>>
>> I'm one of the only people with Overo hardware. Its a bit out of my
>> realm of expertise, but I thought I'd give it a shot. All of my
>> knowledge is based on some prior PowerPC FDT work so my assumptions
>> could be off.
>>
>> The kernel's not coming up, so I thought I'd give you a run-down of what
>> I did to see what may have gone wrong.
>>
>> = NOTE: There's always option B - tell me not to bother and someone else
>> will do this :)
>>
>>
>> I worked from the tips of:
>> U-Boot:
>> git://git.linaro.org/boot/u-boot-linaro-stable.git
>>
>> Kernel:
>> git://git.linaro.org/kernel/linux-linaro-2.6.38.git
>>
>> I built u-boot adding these entries to the include/configs/omap3_overo.h:
>>
>> #define CONFIG_OF_LIBFDT
>> #define CONFIG_SYS_BOOTMAPSZ (8<<20)
>>
>> I then built the kernel using the options you mentioned in this email
>> and added a ".dt_compat" entry to the MACHINE definition in board-overo.c
>>
>> I then made a simple DTS file like what you suggested and compiled it
>> using the DTC package in Natty.
>>
>> I then updated my boot.scr to load to overo.dtb into memory(0x81600000)
>> and update the bootm command to take that address as the 3rd parameter
>> as follows:
>>
>> setenv bootcmd 'fatload mmc 0:1 0x80000000 uImage; fatload mmc 0:1
>> 0x81700000 uInitrd; fatload mmc 0:1 0x81600000 overo.dtb; bootm
>> 0x80000000 0x81700000 0x81600000'
>> setenv bootargs ' console=tty0 console=ttyO2,115200n8
>> root=UUID=b1c56ca5-da31-4042-9e1f-3f3144dd9fb6 rootwait ro earlyprintk
>> mpurate=720'
>> boot
>>
>> U-boot starts up and tries to launch the kernel. The kernel does nothing
>> (or at least nothing goes to my serial console):
>>
>> Here's the output:
>> Running bootscript from mmc ...
>> ## Executing script at 82000000
>> reading uImage
>>
>> 4332388 bytes read
>> reading uInitrd
>>
>> 4174199 bytes read
>> reading overo.dtb
>>
>> 312 bytes read
>> ## Booting kernel from Legacy Image at 80000000 ...
>> Image Name: Linux-2.6.38+
>> Image Type: ARM Linux Kernel Image (uncompressed)
>> Data Size: 4332324 Bytes = 4.1 MiB
>> Load Address: 80008000
>> Entry Point: 80008000
>> Verifying Checksum ... OK
>> ## Loading init Ramdisk from Legacy Image at 81700000 ...
>> Image Name: Ubuntu Initrd
>> Image Type: ARM Linux RAMDisk Image (uncompressed)
>> Data Size: 4174135 Bytes = 4 MiB
>> Load Address: 00000000
>> Entry Point: 00000000
>> Verifying Checksum ... OK
>> ## Flattened Device Tree blob at 81600000
>> Booting using the fdt blob at 0x81600000
>> Loading Kernel Image ... OK
>> OK
>> Loading Ramdisk to 8fc04000, end 8ffff137 ... OK
>> Loading Device Tree to 807fc000, end 807ff137 ... OK
>>
>> Starting kernel ...
>>
>> Uncompressing Linux... done, booting the kernel.
>
> Can you boot with the new u-boot, or new u-boot + new kernel using the old non-fdt boot command?
I've played with this a bit on my panda. It appears that when U-Boot
relocates the .dtb, it either moves it to a location that the kernel
cannot read during early boot, or it corrupts it when it is moved.
Either way, the kernel is hooped when it tries to parse the device
tree data, it falls back to the old ATAGs support, but there aren't
any ATAGs either so it cannot actually boot. I've got it working at
the moment by hacking u-boot to /not/ relocate the .dtb blob which
gets me much farther, but it also looks like it also causes problems
with the initramfs image. It currently has an oops when it cannot
mount the initramfs. Still investigating...
g.
All,
Are there plans of having a meeting to discuss memory management at the ELC?
There was a thread a week or so ago about all of the various
implementations of memory managers (pmem, cmem, ump, gem/ttm, etc) where
this was mentioned.
Our interest in this stems from our current effort to migrate our OMAP
display and memory management functionality to the DRI/DRM model. Like
everyone else, we have to allocate large blocks of memory that are used for
display, video encode/decode, and capture. We're in the same boat of having
implementations that are not upstream.
If there is not already a meeting, would it be possible to carve out some
time on one of the days where there is a graphics centric presentation
(Tues/Wed)?
Best Regards,
Andy Gross
Linux Development Center
Texas Instruments
Hi there,
Does anyone know why no signatures are being generated recently on the
nano images?
http://snapshots.linaro.org/11.05-daily/linaro-nano/
I don't know how cricual this is, but it's at least inconsistent; the
linaro-developer images are getting signatures.
Cheers
---Dave
hi,
I Would like to participate in the OpenGLES2.0 support to Cairo.
Could you please let me know the procedure to get involved in the GLES
backend support for Cairo ?
--
Thanks and Best Regards,
N Ravi
