linaro-dev March 2011

linaro-dev@lists.linaro.org

123 participants
172 discussions

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, 12 months

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, 12 months

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, 12 months

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, 12 months

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

15 years

(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

15 years

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

15 years

RFC: ARM: Support for VFP/NEON registers in coredumps

by Dave Martin

Hi all, Considering how to add the VFP/NEON register state to Coredumps, there's no single obvious solution, so I'd like to put this out for people's comments. Currently, the coredump consists of several notes, the interesting ones currently being: * NT_PRSTATUS - general process status, including the integer registers * NT_FPREGSET - the FPA registers (only present if FPA is in use) These notes are duplicated per thread when a multithreaded process dumps core. There are few options I see: a) Dump the VFP/NEON state in NT_FPREGSET. This could be appended to, or in place of the legacy FPA regs, with flags in a header or (struct elf_prstatus).pr_fpvalid to describe what was dumped. Old gdb etc. may read the resulting information as random FPA register contents; this could perhaps be avoided by always dumping a dummy FPA regs structure at the start of this note, though this seems wasteful. Possibly, gdb may explode if the NT_FPREGSET note is larger then expected. I've not investigated this. b) Dump the VFP/NEON regs in a note of type NT_PRXFPREG. This avoids defining a new note type; however, this note type is really for x86 -- so overloading it in this way may just be nonsensical / confusing. c) Create a new note type specially for this, and dump the VFP/NEON regs in there. This is closest to the model followed by ptrace, where PTRACE_GETREGS, PTRACE_GETFPREGS and PTRAGE_GETVFPREGS are all distinct. Going for (c) seems sanest to me, and also means that old gdb will just ignore the new data; this is probably what we want. Comments are welcome. Cheers ---Dave

15 years

[PATCH 0/5] make sdhci device drivers self registered

by Shawn Guo

This patch set is to take sdhci device driver specific things out from sdhci-pltfm.c and make them self registered. Here are the differences it makes. * Get the sdhci device driver follow the Linux trend that driver take the registration by its own * sdhci-pltfm.c becomes significantly simpler and only has common support functions there * All sdhci device specific stuff are going back its own driver * The dt and non-dt support share the same pair of .probe and .remove hooks. The first one patch adds common support function into sdhci-pltfm.c when changing sdhci-esdhc-imx driver, while the last one cleans up sdhci-pltfm.c when changing sdhci-tegra driver. Only the patch of sdhci-esdhc-imx are tested on hardware, and others are just build tested. And it is based on the tree below. git://git.secretlab.ca/git/linux-2.6.git devicetree/test Comments are welcomed and appreciated. Regards, Shawn Shawn Guo (5): mmc: sdhci: make sdhci-esdhc-imx driver self registered mmc: sdhci: make sdhci-cns3xxx driver self registered mmc: sdhci: make sdhci-dove driver self registered mmc: sdhci: make sdhci-tegra driver self registered mmc: sdhci: update Makefile/Kconfig for sdhci_pltfm change drivers/mmc/host/Kconfig | 24 +++-- drivers/mmc/host/Makefile | 11 +- drivers/mmc/host/sdhci-cns3xxx.c | 68 +++++++++++++- drivers/mmc/host/sdhci-dove.c | 70 +++++++++++++- drivers/mmc/host/sdhci-esdhc-imx.c | 98 +++++++++++++++---- drivers/mmc/host/sdhci-pltfm.c | 165 ++----------------------------- drivers/mmc/host/sdhci-pltfm.h | 14 ++- drivers/mmc/host/sdhci-tegra.c | 189 +++++++++++++++++++++---------------

15 years

Re: [powerdebug V2: 01/14] encapsulate the options code

by Amit Kucheria

Re'adding linaro-dev On 11 Mar 25, Yong Shen wrote: > On Fri, Mar 25, 2011 at 2:48 PM, Amit Kucheria <amit.kucheria(a)linaro.org>wrote: > > > On Fri, Mar 25, 2011 at 4:10 AM, Yong Shen <yong.shen(a)linaro.org> wrote: > > > > > Hi Daniel, > > > Yes. I had started the work for several days. > > > Previously, every time when clock info is refreshed, the data structure > > will > > > be reallocated as if it is the first time of building up clock info. The > > > goal is only allocating memory once, which means less system call made by > > > malloc and also reducing potential memory fragment. > > > I am coding and debuging right now, hoping it comes out soon. > > > Yong > > > > So as to avoid the (inevitable) conflicts, may I propose that I first > > apply Yong's patch sent last week to add inotify support. It is not a > > very invasive patch. > > > No, Amit, no need apply the patch I post last time. It will be involved in > my coming patch(s) Ahh, ok. I was just about to start fixing up your patch to apply after Daniel's changes. > > > > Yong, for the mem allocation work, perhaps it is best if we wait for > > Daniel to send his latest series and work on top of that. > > > No problem for me. Alright. So let's wait a day or so for Daniel to post his series and review it. /Amit

15 years

← Newer
1
2
3
4
5
6
7
8
...
18
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev March 2011