linaro-dev

linaro-dev@lists.linaro.org

4332 discussions

by Joey Stanford

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

14 years, 1 month

Re: Device Tree on ARM status report - Mar 20

by Grant Likely

[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.

14 years, 1 month

Notes & Actions: Linaro Graphics Working Group - Mar 23, 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-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

14 years, 1 month

Starting a cookbook

by Michael Hope

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

14 years, 1 month

RE: ELC and memory management

by Stephen Doel

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 *******************************************

14 years, 1 month

Yet another memory provider: can linaro organize a meeting?

by Hans Verkuil

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

14 years, 1 month

Re: Device Tree on ARM status report - Mar 20

by Grant Likely

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.

14 years, 1 month

ELC and memory management

by Gross, Andy

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

14 years, 1 month

(Lack of) signatures on snapshots.l.o nano images

by Dave Martin

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

14 years, 1 month

regarding memebership to linaro

by ravi nanjundappa

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

14 years, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev