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