Re: IGEPv2 kernel changes

[Michael Hope]

> hmm. Those should have been in initramfs iirc. I assume you did not install
> the kernel as a package?

Correct.  I'm afraid I'm doing things in a random way.

Out of interest, where would the initramfs go in NAND?

-- Michael

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

How to involve into the linaro development

[nvhariharan]

Hi All,

I am having experience in Omap, imx based linux platforms.
How shall I involve myself into the linaro development,
I am into this maillist and using the linaro distribution into beagle board, 
since all the participants are having linaro mail ids,
Kindly advise me and use me as a resource for this  development.

Thanks,
Hariharan Veerappan
Software Architect,
EmbDes Technologies,
Bangalore, India.
Sent from BlackBerry® on Airtel
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Common data for uImage generation

[Dave Martin]

>
> It would be great if we agreed that U-Boot should be able to cope with
> zImage directly.  Adding the necessary support to U-Boot is trivial.

I did come across a ramdom version of U-Boot which could load zImages,
but I don't have a pointer to that any more.

Also, does anyone know why U-Boot always prints "loading legacy image"
when loading images created with mkimage?  Kinda suggests the U-Boot
folks think this image format has been superseded by _something_ but I
never figured out why.

Cheers
---Dave

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Common data for uImage generation

[Loïc Minier]

On Wed, Aug 25, 2010, Dave Martin wrote:
> Also, does anyone know why U-Boot always prints "loading legacy image"
> when loading images created with mkimage?  Kinda suggests the U-Boot
> folks think this image format has been superseded by _something_ but I
> never figured out why.

 From a quick look at U-Boot, it defaults to IMAGE_FORMAT_LEGACY if
 there is the U-Boot image magic number, else if U-Boot is built with
 FDT (DeviceTree) support, it uses IMAGE_FORMAT_FIT.  In any other case,
 the image is considered invalid (IMAGE_FORMAT_INVALID).

 I found this old submission of bootz to boot zImages:
 http://lists.denx.de/pipermail/u-boot/2003-June/001589.html

 The patches had many issues (I for one would have been unhappy about
 having a new bootz command, but perhaps I'm missing the reason why
 bootm can't be used).

-- 
Loïc Minier

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Efika kernel

[Jammy Zhou]

For accelerated graphics on MX51 (Z430 and Z160), the kernel module driver
has been open sourced recently, but for user space libraries, they are still
proprietary, and NDA is needed to access source code as well as related
documents.

Regards,
Jammy

On Wed, Aug 25, 2010 at 3:02 AM, Scott Bambrough  wrote:

> On Tue, 2010-08-24 at 15:46 -0300, Christian Robottom Reis wrote:
> > On Tue, Aug 24, 2010 at 08:39:00PM +0200, Robert Schwebel wrote:
> > > If anyone knows how the state regarding accelerated graphics is, let me
> > > know. It would be pretty interesting to support that in mainline as
> > > well. Until now, we don't have any idea if there is some documentation
> > > for the z430 core available, and if not, if that's by accident (because
> > > nobody knows) or on purpose (because it is top secret).
> >
> > I'm sure someone at Freescale knows; I'll write to the Linaro TSC
> > contacts and find out who can give us input here. There are not a lot of
> > SoCs that ship with AMD mobile on them, so talking to FSCL is probably
> > our best bet.
> >
> > I'm sure somebody on the Linaro team has had access to graphics drivers
> > in the mx51 BSP at some point in time, though I'm not sure what terms
> > the BSP was provided under.
>
> I've had access to this code under NDA at Xandros.  It was not supplied
> with documentation for the graphics core.  I suspect this is because the
> core is Qualcomm's and supplied to FreeScale under NDA.  The only two
> SoC's I am aware of that use that core are SnapDragon and iMX51.
>
> Scott
>
> --
> Scott Bambrough 
> Linaro Infrastructure Team Lead
>
>
> ___
> linaro-dev mailing list
> linaro-dev@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-dev
>
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Efika kernel

[Robert Schwebel]

On Wed, Aug 25, 2010 at 05:34:37PM +0800, Jammy Zhou wrote:
> For accelerated graphics on MX51 (Z430 and Z160), the kernel module
> driver has been open sourced recently, but for user space libraries,
> they are still proprietary, and NDA is needed to access source code as
> well as related documents.

Do you know where we can find this open sourced version of the kernel
driver?

rsc
-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PM] 25/08/10 - Minutes for the Power Management WG weekly call

[Amit Kucheria]

The minutes of the weekly call can be found at:

https://wiki.linaro.org/WorkingGroups/PowerManagement/Meetings/2010-08-25

The minutes and actions are copied below.

Regards,
Amit

Attendees:

Linaro: Amit Kucheria, Amit Arora, Yong Shen
ARM: Robin Randhawa, Bobby Batacharia, Srinivas Kalaga


== Action Items from this Meeting ==
 * ACTION: Yong to work with John Rigby and Ubuntu kernel team to make sure the 
Linaro kernel contains powertop kernel patches
 * ACTION: Vishwa to verify powertop on 2.6.35
 * ACTION: Vishwa to check with cpuidle/cpufreq experts in TI for verifying 
cpufreq behavior on multi-core OMAP
 * ACTION: Amit A to get the powertop patch integrated into Linaro/Ubuntu 
packages
 * ACTION: Yong to test common clk API patches on imx5 and help get it booting 
on babbage 3.0
 
== Action Items from Previous Meeting ==

 * ACTIVE (Immediate):  
   * ACTION: Amit A to test on pm enabled OMAP3 board: DONE on 2.6.32 on zoom3 
board
 * New ACTION: Vishwa to verify on 2.6.35
   * ACTION: Amit A to document details on power supply class (battery info) to 
PowerTOP internal wiki page: DONE
   * ACTION: Yong to look into getting powertop kernel patches applied to 
Linaro kernel tree: Not DONE
 * New ACTION: Yong to work with John Rigby and make sure the Linaro kernel 
contains it
   * ACTION: Robin to send links to patches sent to linux-pm: DONE
 * http://www.spinics.net/lists/cpufreq/msg01740.html
 * It was a pointer to a discussion on having different governors on 
different cores
   * ACTION: Amit K to spend some time on usecase to reproduce ondemand 
governor problems: POSTPONED
   * ACTION: Yong to look at common clock FW, find out if debug info being 
exported (usage count, clk rate, dependencies): DONE

 * DORMANT :  
 
  * ACTION: ARM to share  internal  instrumentation flow (BAB: we might also 
align with Linaro on workload discussions)  
 * Might take couple of months   
  * ACTION: Amit K to talk to jeremy about power domain framework: DONE
 * Jeremy needs help, will revisit in a few weeks
  * ACTION: Srinivas to provide details of where he believes userspace - kernel 
interaction is required. (low prio)  
  * ACTION: Bobby to check on multi-core boards availability (request open)  
  * ACTION: ARM to discuss giving out internal Eclipse based tool (similar to 
powertop)  (no ETA as of now)   
  * ACTION: Amit Kucheria and Vishwa to get inputs from community on the issues 
related to CPUIDLE governor: POSTPONED until instrumentation work 


== Minutes ==
  * Discussion on http://www.spinics.net/lists/cpufreq/msg01740.html
* For ARM, both cores run at same frequency (CMP)
  * Does it make sense for them to run different governors on each core?
* The consensus currently is NO
* TI uses ondemand governor + policy manager
  * One core is kept OFF, all processing happens on the other one.
  * If load on one core goes above a threshold, they turn ON other core
  * Both cores run at same Operating Point once ON
  * Debug info in common clk API being discussed upstream by Jeremy
* There is currently no debug info
* clock name is not part of the common struct clk to keep size down
* Need to engage with Jeremy
* Yong will test the patches from Jeremy on imx5 and report back
  * Powerdebug: should we visualise the clock and power dependencies using 
information from /sys or debugfs?
* No immediate horror expressed at the idea
* Freescale and TI already do it to a certain extent by dumping the clock 
tree and rates into a table
* The entire tree is too complex to depict
* We could represent it in parts e.g. start at a peripheral and plot it's 
clock and power dependencies all the way up


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PM] 25/08/10 - Minutes for the Power Management WG weekly call

[Amit Kucheria]

On Wed, Aug 25, 2010 at 12:41 PM, Amit Kucheria
 wrote:
> The minutes of the weekly call can be found at:
>
> https://wiki.linaro.org/WorkingGroups/PowerManagement/Meetings/2010-08-25
>
> The minutes and actions are copied below.
>
> Regards,
> Amit
>
> Attendees:
>
> Linaro: Amit Kucheria, Amit Arora, Yong Shen

Vishwanath Sripathy is back from vacation and attended too.

> ARM: Robin Randhawa, Bobby Batacharia, Srinivas Kalaga

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: PowerTOP kernel patch

[Amit Kucheria]

Hi John/Yong,

Could you work with the Ubuntu kernel team to get these patches merged
into their tree?

Regards,
Amit

On Mon, Aug 23, 2010 at 6:25 AM, Yong Shen  wrote:
> only one patch, linux-2.6.35-rc4-annotate-device-pm.patch is involved in
> 2.6.36, at 8d4b9d1bfef117862a2889dec4dac227068544c9.
> So we may still need the rest two.
>
> On Sat, Aug 21, 2010 at 2:28 AM, Nicolas Pitre 
> wrote:
>>
>> On Fri, 20 Aug 2010, Yong Shen wrote:
>>
>> > Hi there,
>> >
>> > Power management WG is invistigating on a tool named PowerTOP, which can
>> > spit out real time data on various aspects of a running system, in terms
>> > of
>> > power related information.
>> > However, occasionally some PowerTOP features need kernel patch. We'd
>> > like
>> > users to be able to use these latest features without having to wait up
>> > to 3
>> > months for Linus to make a release with the kernel portion -- as the
>> > original patch developer(s) said.
>> > There are totally 3 patches which I had already enclosed them in the
>> > attachment. Except vfs.patch, the rest two are original and can be
>> > applied
>> > on linaro kernel without any changes. vfs.patch is changed a little from
>> > original one to adapt current linaro kernel.
>> > Hope John would give it a thought to merge these patch in Linaro kernel.
>>
>> I would be interested in them too!
>>
>> If I'm not mistaken, John is getting my kernel and adding the necessary
>> packaging to it.  So those patches would probably make more sense being
>> carried into the base Linaro repository that John is using.
>>
>>
>> Nicolas
>
>
> ___
> linaro-dev mailing list
> linaro-dev@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-dev
>
>

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Efika kernel

[Jammy Zhou]

http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX515&fpsp=1&tab=Design_Tools_Tab
download 
L2.6.31_10.07.11_ER_SOURCE
you can get the driver package in drivers/mxc/amd-gpu folder, I think

Regards,
Jammy

On Wed, Aug 25, 2010 at 5:40 PM, Robert Schwebel
wrote:

> On Wed, Aug 25, 2010 at 05:34:37PM +0800, Jammy Zhou wrote:
> > For accelerated graphics on MX51 (Z430 and Z160), the kernel module
> > driver has been open sourced recently, but for user space libraries,
> > they are still proprietary, and NDA is needed to access source code as
> > well as related documents.
>
> Do you know where we can find this open sourced version of the kernel
> driver?
>
> rsc
> --
> Pengutronix e.K.   | |
> Industrial Linux Solutions | http://www.pengutronix.de/  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
> Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
>
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Notes & Actions: Linaro graphics/multimedia - Aug 23, 2010

[Alexander Sack]

Hi,

notes and actions from our Monday graphics and multimedia cross-vendor
call are available on the wiki:

 + https://wiki.linaro.org/Platform/UserPlatforms/2010-08-23

Details about when and where of this meeting can be found here:

 +
https://wiki.linaro.org/WorkingGroups/Middleware/Graphics#Weekly%20Public%20Call


Thanks,

-- 

 - Alexander
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: linux-meta-linaro pull request

[Tim Gardner]

On 08/23/2010 07:37 PM, John Rigby wrote:
> git://git.linaro.org/ubuntu/linux-meta-linaro.git master

pulled and uploaded

-- 
Tim Gardner tim.gard...@canonical.com

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Cross compilation with debuild

[Wookey]

+++ Loïc Minier [2010-08-24 19:25 +0200]:
>  So I gave a try to cross-compiling gstreamer0.10 and it some
>  interesting issues.

me too, but I tried with pdebuild-cross too, to see how it worked.

>  First, I used an i386 chroot instead of an amd64 chroot since I thought
>  that might help a bit with package names; I'm not actually sure that
>  was needed, but it might influence results.

I'm using amd64 - hopefully it doesn't matter.

>  Next, the gstreamer0.10 cross-build started but promptly failed trying
>  to link to libxml2; this was the PKG_CONFIG_LIBDIR issue you mentioned.
>  I added:
> buildpackage.append('-ePKG_CONFIG_LIBDIR=/usr/%s/lib/pkgconfig' % 
> deb_host_gnu_type)
> 
>  This is LP #623478 which you filed.

I'm a biut confused about this. I got this error in pdebuild-cross
because xapt was initially missing so the cross-deps simly weren't
being installed. As soon as they were installed then this part went
fine. Which is what I would expect. So there must be something
different about the environment in the xdeb case. I'll try and work
out what is going on.

>  Interestingly, the build broke because it couldn't find gtk-doc
>  anymore; I didn't add /usr/share/pkgconfig, but it does show that host
>  versus build pkg-config dependencies are a problem, and we need a
>  $triplet-pkg-config to solve this!
> 
>  So I patched the gstreamer build to turn off docs; I think
>  gstreamer0.10 should --disable-gtk-doc when cross-compiling; in fact,
>  this should be done in gtk-doc upstream.

I left docs on. It correspondingly pulls in a lot of deps (157
cross-deps, but lots of them are null so it doesn't actually waste _too_
much time). Nothing broke.

>  This got quite far in the build:
> make[4]: Entering directory `/home/lool/gstreamer0.10/gstreamer0.10/gst'
> [...]
> libtool: link: arm-linux-gnueabi-ranlib .libs/libgstreamer-0.10.a
> libtool: link: rm -fr .libs/libgstreamer-0.10.lax
> libtool: link: ( cd ".libs" && rm -f "libgstreamer-0.10.la" && ln -s 
> "../libgstreamer-0.10.la" "libgstreamer-0.10.la" )
> /usr/bin/g-ir-scanner -v --namespace Gst \
> --nsversion=0.10 \
> -I.. \
> -I.. \
> -DIN_GOBJECT_INTROSPECTION=1 \
> --c-include='gst/gst.h' \
> --library=libgstreamer-0.10.la \
> --include=GLib-2.0 \
> --include=GObject-2.0 \
> --include=GModule-2.0 \
> --include=libxml2-2.0 \
> --libtool="../libtool" \
> --pkg glib-2.0 \
> --pkg gobject-2.0 \
> --pkg gmodule-no-export-2.0 \
> --pkg gthread-2.0 \
> --pkg libxml-2.0 \
> --output Gst-0.10.gir \
> ./gst.h ./glib-compat.h ./gstobject.h ./gstbin.h 
> ./gstbuffer.h ./gstbufferlist.h ./gstbus.h ./gstcaps.h ./gstchildproxy.h 
> ./gstclock.h ./gstcompat.h ./gstdebugutils.h ./gstelement.h 
> ./gstelementfactory.h ./gsterror.h ./gstevent.h ./gstfilter.h ./gstformat.h 
> ./gstghostpad.h ./gstindex.h ./gstindexfactory.h ./gstinfo.h ./gstinterface.h 
> ./gstiterator.h ./gstmacros.h ./gstmessage.h ./gstminiobject.h ./gstpad.h 
> ./gstpadtemplate.h ./gstparamspecs.h ./gstpipeline.h ./gstplugin.h 
> ./gstpluginfeature.h ./gstpoll.h ./gstpreset.h ./gstquery.h ./gstsegment.h 
> ./gststructure.h ./gstsystemclock.h ./gsttaglist.h ./gsttagsetter.h 
> ./gsttask.h ./gsttaskpool.h ./gsttrace.h ./gsttypefind.h 
> ./gsttypefindfactory.h ./gsturi.h ./gstutils.h ./gstvalue.h ./gstregistry.h 
> ./gstparse.h ./gstxml.h \
> ./gst.c ./gstobject.c ./gstbin.c ./gstbuffer.c 
> ./gstbufferlist.c ./gstbus.c ./gstcaps.c ./gstchildproxy.c ./gstclock.c 
> ./gstdebugutils.c ./gstelement.c ./gstelementfactory.c ./gsterror.c 
> ./gstevent.c ./gstfilter.c ./gstformat.c ./gstghostpad.c ./gstindex.c 
> ./gstindexfactory.c ./gstinfo.c ./gstinterface.c ./gstiterator.c 
> ./gstmessage.c ./gstminiobject.c ./gstpad.c ./gstpadtemplate.c 
> ./gstparamspecs.c ./gstpipeline.c ./gstplugin.c ./gstpluginfeature.c 
> ./gstpluginloader.c ./gstpoll.c ./gstpreset.c ./gstquark.c ./gstquery.c 
> ./gstregistry.c ./gstregistrychunks.c ./gstsegment.c ./gststructure.c 
> ./gstsystemclock.c ./gsttaglist.c ./gsttagsetter.c ./gsttask.c 
> ./gsttaskpool.c ./gsttrace.c ./gsttypefind.c ./gsttypefindfactory.c 
> ./gsturi.c ./gstutils.c ./gstvalue.c ./gstparse.c ./gstregistrybinary.c 
> ./gstxml.c
> /usr/lib/gcc/arm-linux-gnueabi/4.4.5/../../../../arm-linux-gnueabi/bin/ld: 
> warning: libxml2.so.2, needed by ./.libs/libgstreamer-0.10.so, not found (try 
> using -rpath or -rpath-link)
> /usr/lib/gcc/arm-linux-gnueabi/4.4.5/../../../../arm-linux-gnueabi/bin/ld: 
> warning: libm.so.6, needed by ./.libs/libgstreamer-0.10.so, not found (try 
> using -rpath or -rpath-link)
> [...]

Yep. pdebuild-cross+xapt dies in the same place, but not with the same
error

dies with:
./gst.c ./gstobject.c ./gstbin.c ./gstbuffer.c ./gstbu

Vexpress mtdparts question

[Matt Waddel]

I am trying to map the nor flash on the Versatile Express platform
to an mtd partition.  I have tried a bunch of variations with the
kernel command line "mtdparts" directive, without success.

Here is the last one I tried:
mtdparts=armflash-1.0:1M(uboot),9M(linux),16M(uInitrd)


The kernel seems to detect the flash parts correctly:
...
armflash-0: Found 2 x16 devices at 0x0 in 32-bit bank
Intel/Sharp Extended Query Table at 0x010A
Intel/Sharp Extended Query Table at 0x010A
Intel/Sharp Extended Query Table at 0x010A
Intel/Sharp Extended Query Table at 0x010A
Intel/Sharp Extended Query Table at 0x010A
Using buffer write method
Using auto-unlock on power-up/resume
cfi_cmdset_0001: Erase suspend on write enabled
armflash-1: Found 2 x16 devices at 0x0 in 32-bit bank
Intel/Sharp Extended Query Table at 0x010A
Intel/Sharp Extended Query Table at 0x010A
Intel/Sharp Extended Query Table at 0x010A
Intel/Sharp Extended Query Table at 0x010A
Intel/Sharp Extended Query Table at 0x010A
Using buffer write method
Using auto-unlock on power-up/resume
cfi_cmdset_0001: Erase suspend on write enabled
Concatenating MTD devices:
(0): "armflash-0"
(1): "armflash-1"
into device "armflash"
RedBoot partition parsing not available
...

$ cat /proc/mtd
dev:size   erasesize  name


Any ideas?

Thanks,
Matt

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Vexpress mtdparts question

[Loïc Minier]

On Wed, Aug 25, 2010, Matt Waddel wrote:
> mtdparts=armflash-1.0:1M(uboot),9M(linux),16M(uInitrd)

 Looks like it should be without that .0:
mtdparts=armflash-1:1M(uboot),9M(linux),16M(uInitrd)

 see linux/drivers/mtd/cmdlinepart.c

-- 
Loïc Minier

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: PowerTOP kernel patch

[Nicolas Pitre]

Those patches don't apply as is, and I prefer not venturing into merge 
conflict attempts.

What I'd suggest is:

1) get the stable linaro tree from 
git://git.linaro.org/kernel/linux-linaro-2.6.35.git

2) cherry-pick the upstream patch with 'git cherry-pick -x 8d4b9d1bf'

3) fix the conflicts, then commit

4) apply and commit the other patches on top

5) test _this_ resulting tree

6) put the result somewhere for me to pull.


On Wed, 25 Aug 2010, Amit Kucheria wrote:

> Hi John/Yong,
> 
> Could you work with the Ubuntu kernel team to get these patches merged
> into their tree?
> 
> Regards,
> Amit
> 
> On Mon, Aug 23, 2010 at 6:25 AM, Yong Shen  wrote:
> > only one patch, linux-2.6.35-rc4-annotate-device-pm.patch is involved in
> > 2.6.36, at 8d4b9d1bfef117862a2889dec4dac227068544c9.
> > So we may still need the rest two.
> >
> > On Sat, Aug 21, 2010 at 2:28 AM, Nicolas Pitre 
> > wrote:
> >>
> >> On Fri, 20 Aug 2010, Yong Shen wrote:
> >>
> >> > Hi there,
> >> >
> >> > Power management WG is invistigating on a tool named PowerTOP, which can
> >> > spit out real time data on various aspects of a running system, in terms
> >> > of
> >> > power related information.
> >> > However, occasionally some PowerTOP features need kernel patch. We'd
> >> > like
> >> > users to be able to use these latest features without having to wait up
> >> > to 3
> >> > months for Linus to make a release with the kernel portion -- as the
> >> > original patch developer(s) said.
> >> > There are totally 3 patches which I had already enclosed them in the
> >> > attachment. Except vfs.patch, the rest two are original and can be
> >> > applied
> >> > on linaro kernel without any changes. vfs.patch is changed a little from
> >> > original one to adapt current linaro kernel.
> >> > Hope John would give it a thought to merge these patch in Linaro kernel.
> >>
> >> I would be interested in them too!
> >>
> >> If I'm not mistaken, John is getting my kernel and adding the necessary
> >> packaging to it.  So those patches would probably make more sense being
> >> carried into the base Linaro repository that John is using.
> >>
> >>
> >> Nicolas
> >
> >
> > ___
> > linaro-dev mailing list
> > linaro-dev@lists.linaro.org
> > http://lists.linaro.org/mailman/listinfo/linaro-dev
> >
> >
> ___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Cross compilation with debuild

[Loïc Minier]

On Wed, Aug 25, 2010, Wookey wrote:
> I'm using amd64 - hopefully it doesn't matter.

 Well I feared it might influence xdeb, since there is this bug about
 the need to use two caches; notably, I thought at least using a 32-bits
 build arch was better than a 64-bits for the visible package names.
 Now I don't expect it actually makes a big difference, but I wanted to
 mention it.

> I'm a biut confused about this. I got this error in pdebuild-cross
> because xapt was initially missing so the cross-deps simly weren't
> being installed. As soon as they were installed then this part went
> fine. Which is what I would expect. So there must be something
> different about the environment in the xdeb case. I'll try and work
> out what is going on.

 Is this on an Ubuntu host with an Ubuntu rootfs in your build
 environment?  pbuilder doesn't cleanup the env, only debuild does.
 Also, dpkg-buildpackage used to set PKG_CONFIG_LIBDIR until recently,
 so if you're trying on an older distro (e.g. lucid) you might not see
 the issue we have now.

> >  Interestingly, the build broke because it couldn't find gtk-doc
> >  anymore; I didn't add /usr/share/pkgconfig, but it does show that host
> >  versus build pkg-config dependencies are a problem, and we need a
> >  $triplet-pkg-config to solve this!
> > 
> >  So I patched the gstreamer build to turn off docs; I think
> >  gstreamer0.10 should --disable-gtk-doc when cross-compiling; in fact,
> >  this should be done in gtk-doc upstream.
> 
> I left docs on. It correspondingly pulls in a lot of deps (157
> cross-deps, but lots of them are null so it doesn't actually waste _too_
> much time). Nothing broke.

 Problems were not with the deps but with a call to pkg-config; I didn't
 have /usr/$triplet/share/pkgconfig in my path and I didn't cross
 gtk-doc to have it, but gtk-doc.pc was in /usr/share/pkgconfig, and it
 would probably have been picked up if I had bothered setting
 PKG_CONFIG_LIBDIR to pick it up.  I thought the best fix here was
 actually to disable docs when cross-building because gtk-doc usually
 generates scanners and runs them, which obviously doens't work.

> Yep. I think we can agree on that. It's interesting that the two build
> methods don't quite give the same behaviour. I'll poke it some more to see
> what's going on.

 I think I saw your error message later down, but I looked at the first
 error I got.

-- 
Loïc Minier

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: PowerTOP kernel patch

[Yong Shen]

Hi Nicolas,

Thanks for your suggestion.s I am going to follow this.

Yong

On Thu, Aug 26, 2010 at 3:05 AM, Nicolas Pitre wrote:

>
> Those patches don't apply as is, and I prefer not venturing into merge
> conflict attempts.
>
> What I'd suggest is:
>
> 1) get the stable linaro tree from git://
> git.linaro.org/kernel/linux-linaro-2.6.35.git
>
> 2) cherry-pick the upstream patch with 'git cherry-pick -x 8d4b9d1bf'
>
> 3) fix the conflicts, then commit
>
> 4) apply and commit the other patches on top
>
> 5) test _this_ resulting tree
>
> 6) put the result somewhere for me to pull.
>
>
> On Wed, 25 Aug 2010, Amit Kucheria wrote:
>
> > Hi John/Yong,
> >
> > Could you work with the Ubuntu kernel team to get these patches merged
> > into their tree?
> >
> > Regards,
> > Amit
> >
> > On Mon, Aug 23, 2010 at 6:25 AM, Yong Shen  wrote:
> > > only one patch, linux-2.6.35-rc4-annotate-device-pm.patch is involved
> in
> > > 2.6.36, at 8d4b9d1bfef117862a2889dec4dac227068544c9.
> > > So we may still need the rest two.
> > >
> > > On Sat, Aug 21, 2010 at 2:28 AM, Nicolas Pitre <
> nicolas.pi...@linaro.org>
> > > wrote:
> > >>
> > >> On Fri, 20 Aug 2010, Yong Shen wrote:
> > >>
> > >> > Hi there,
> > >> >
> > >> > Power management WG is invistigating on a tool named PowerTOP, which
> can
> > >> > spit out real time data on various aspects of a running system, in
> terms
> > >> > of
> > >> > power related information.
> > >> > However, occasionally some PowerTOP features need kernel patch. We'd
> > >> > like
> > >> > users to be able to use these latest features without having to wait
> up
> > >> > to 3
> > >> > months for Linus to make a release with the kernel portion -- as the
> > >> > original patch developer(s) said.
> > >> > There are totally 3 patches which I had already enclosed them in the
> > >> > attachment. Except vfs.patch, the rest two are original and can be
> > >> > applied
> > >> > on linaro kernel without any changes. vfs.patch is changed a little
> from
> > >> > original one to adapt current linaro kernel.
> > >> > Hope John would give it a thought to merge these patch in Linaro
> kernel.
> > >>
> > >> I would be interested in them too!
> > >>
> > >> If I'm not mistaken, John is getting my kernel and adding the
> necessary
> > >> packaging to it.  So those patches would probably make more sense
> being
> > >> carried into the base Linaro repository that John is using.
> > >>
> > >>
> > >> Nicolas
> > >
> > >
> > > ___
> > > linaro-dev mailing list
> > > linaro-dev@lists.linaro.org
> > > http://lists.linaro.org/mailman/listinfo/linaro-dev
> > >
> > >
> >
>
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev