On Thu, 2011-03-31 at 19:41 +0200, Loïc Minier wrote:
[...]
> However, it will likely be needed to copy this dtb in a place where
> u-boot can read it, for instance in the boot partition probably as an
> u-boot image: uDeviceTree just like uImage, uInitrd etc.; I don't care
> too strongly about
On Thu, Mar 31, 2011 at 10:09:40AM -0600, Grant Likely wrote:
> On Fri, Mar 25, 2011 at 03:13:58PM +0800, Shawn Guo wrote:
> > After fec dt support is added, the following compile error will be
> > seen when building a pure non-dt kernel.
> >
> > drivers/net/fec.c: In function ‘fec_probe’:
> > dri
On Thu, Mar 31, 2011 at 07:41:53PM +0200, Loïc Minier wrote:
> On Fri, Apr 01, 2011, Shawn Guo wrote:
> > As the .dtb files will be naturally generated in the same kernel
> > folder as kernel image sits, why do not we ship .dtb in the same
> > folder as kernel image /boot?
>
> You could say the s
Hi all,
I tried to upload the kernel debs to ftp.debian-ports.org, but I'm
getting some upload errors, so I uploaded them to
http://www.freevec.org/packages/
the armhf sd card image is finally uploaded here:
http://www.freevec.org/packages/efikamx-armhf.img.xz
it is very recent, includes pbuil
Hi All,
A reminder that you need to book your hotel reservation by next Friday to
guarantee getting a room. Also, make sure you register at the links below.
Also, please check the Linaro@UDS website for additional details on getting
involved, specifically:
- We'll be organising a couple of se
On Fri, Apr 01, 2011, Shawn Guo wrote:
> With folder /boot/dtbs?
I don't really like "dtbs" because it limits to storing exactly dtb
files; if it's "device-tree" it's more generic and could be used for
other things like dts if needed.
I don't think it's impossible to put it in /boot; I'll let
Dear Chander Kashyap,
On 31 March 2011 18:14, Chander Kashyap wrote:
> SMDKV310 board is based on Samsung S5PV310 SOC. This SOC is very much
> similar to S5PC210.
>
> Signed-off-by: Chander Kashyap
> Signed-off-by: Tushar Behera
> ---
> board/samsung/smdkv310/Makefile | 46 +++
> boar
On Fri, Apr 01, 2011, Stephen Doel wrote:
>Contact matt.wadd...@linaro.org for more details
matt.wad...@linaro.org
--
Loïc Minier
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Hi everyone,
I am trying to assemble a reference for the sound device specifics for all
the platforms. The catch is that I don't have all the dev platforms
available to me.
Here is where you can help! I have Panda and Beagle C4. I need everything
else. If you have access to other platform(s), p
Just FYI - lengthy but very interesting read, Linus was really good at
wording, enjoy heh :-)
https://lkml.org/lkml/2011/3/17/283
So maybe it's just a right time to talk about using linaro ARM kernel
tree as a fork for quick merge of the ever expanding SoC and board
support, and using it more as
Eric,
yes, I found that interesting. I've been having discussions about how
to do this better, I'm interested in your thoughts. Are you by any
chance at ELC in SF?
Dave
On Fri, 2011-04-01 at 23:43 +0800, Eric Miao wrote:
> Just FYI - lengthy but very interesting read, Linus was rea
Eric,
>> So maybe it's just a right time to talk about using linaro ARM kernel
>> tree as a fork for quick merge of the ever expanding SoC and board
>> support, and using it more as a productive kernel for downstream.
I don't think that a 'fork' is really a solution we are looking for. Using
Lina
On Fri, Apr 1, 2011 at 11:55 PM, David Rusling wrote:
> Eric,
> yes, I found that interesting. I've been having discussions about how
> to do this better, I'm interested in your thoughts. Are you by any
> chance at ELC in SF?
Actually a bit busy with the involvement with Freescale, so
On Fri, Apr 1, 2011 at 11:57 PM, Philippe Robin wrote:
> Eric,
>
>>> So maybe it's just a right time to talk about using linaro ARM kernel
>>> tree as a fork for quick merge of the ever expanding SoC and board
>>> support, and using it more as a productive kernel for downstream.
>
> I don't think
Is there a bug tracking this? if not, would you mind opening one?
I fear this affects OMAP4 with the -omap flavor as well.
--
Loïc Minier
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
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-30
Details about when and where of this meeting can be found here:
+
https://wiki.linaro.org/WorkingGroups/Middleware/Grap
On Fri, 2011-04-01 at 19:02 +0200, Loïc Minier wrote:
> Is there a bug tracking this? if not, would you mind opening one?
>
> I fear this affects OMAP4 with the -omap flavor as well.
https://bugs.edge.launchpad.net/linux-linaro/+bug/747639
thanks
-john
__
On Sat, 2 Apr 2011, Eric Miao wrote:
> Yeah, staging is more close to what I meant, a 'fork' is not appropriate here,
> as getting the support into mainline will always be our goal. Yet there seems
> to be necessary to have such a temporary place for those patches to live
> before the mainline is
Hello Konstantinos,
2011/4/1 Konstantinos Margaritis :
> I tried to upload the kernel debs to ftp.debian-ports.org, but I'm
> getting some upload errors, so I uploaded them to
Right now I am getting some issues trying to create a rootfs with
multistrap from debian-ports.org
The following packag
On Fri, 1 Apr 2011, Vishwanath Sripathy wrote:
> Hi Nicolas,
>
> Pls find rebased OMAP DVFS patches attached. Apologies for the delay
> as I had to rework some of the patches because of kernel migration.
No problem.
Merged, thanks.
Nicolas
___
lina
On Sat, Apr 2, 2011 at 6:05 AM, Nicolas Pitre wrote:
> On Sat, 2 Apr 2011, Eric Miao wrote:
>
>> Yeah, staging is more close to what I meant, a 'fork' is not appropriate
>> here,
>> as getting the support into mainline will always be our goal. Yet there seems
>> to be necessary to have such a tem
On Sat, Apr 2, 2011 at 12:46 PM, Eric Miao wrote:
> On Sat, Apr 2, 2011 at 6:05 AM, Nicolas Pitre
> wrote:
>> On Sat, 2 Apr 2011, Eric Miao wrote:
>>
>>> Yeah, staging is more close to what I meant, a 'fork' is not appropriate
>>> here,
>>> as getting the support into mainline will always be ou
22 matches
Mail list logo
