Re: [PATCH V4 2/5] arm/dt: add very basic dts file for babbage board
On Fri, Mar 11, 2011 at 03:33:24PM +0800, Jason Hui wrote:
> Hi, Shawn,
>
> On Fri, Mar 11, 2011 at 2:56 PM, Shawn Guo wrote:
> > Hi Jason,
> >
> > On Thu, Mar 10, 2011 at 12:59:42PM +0800, Jason Liu wrote:
> >> Signed-off-by: Jason Liu
> >> Signed-off-by: Jason Liu
> >> Singed-off-by: Rob Herring
> >> ---
> >> arch/arm/boot/dts/babbage.dts | 122
> >> +
> >> 1 files changed, 122 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/arch/arm/boot/dts/babbage.dts b/arch/arm/boot/dts/babbage.dts
> >> new file mode 100644
> >> index 000..ab87a1b
> >> --- /dev/null
> >> +++ b/arch/arm/boot/dts/babbage.dts
> >> @@ -0,0 +1,122 @@
> >> +/*
> >> + * Copyright 2011 Linaro Ltd.
> >> + * Copyright 2011 Freescale Semiconductor, Inc.
> >> + *
> >> + * The code contained herein is licensed under the GNU General Public
> >> + * License. You may obtain a copy of the GNU General Public License
> >> + * Version 2 or later at the following locations:
> >> + *
> >> + * http://www.opensource.org/licenses/gpl-license.html
> >> + * http://www.gnu.org/copyleft/gpl.html
> >> + */
> >> +
> >> +/dts-v1/;
> >> +
> >> +/ {
> >> + model = "Freescale i.MX51 Babbage";
> >> + compatible = "fsl,mx51-babbage";
> >> + #address-cells = <1>;
> >> + #size-cells = <1>;
> >> + #interrupt-cells = <1>;
> >> + interrupt-parent = <&tzic>;
> >> +
> >> + memory {
> >> + reg = <0x9000 0x2000>;
> >> + };
> >> +
> >> + chosen {
> >> + bootargs = "console=ttymxc0,115200n8 debug earlyprintk
> >> ip=dhcp";
> >> + };
> >> +
> >> + soc {
> >> + #address-cells = <1>;
> >> + #size-cells = <1>;
> >> + compatible = "simple-bus";
> >> + ranges;
> >> +
> >> + tzic: tz-interrupt-controller {
> >> + #address-cells = <0>;
> >> + #interrupt-cells = <1>;
> >> + interrupt-controller;
> >> + reg = <0xe000 0x1000>;
> >> + compatible = "fsl,imx51-tzic";
> >> + };
> >> + };
> >> +
> >> + clocks {
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> +
> >> + uart0_clk: uart0 {
> >> + compatible = "clock";
> >> + clock-outputs = "imx-uart.0";
> >> + };
> >> +
> >> + uart1_clk: uart1 {
> >> + compatible = "clock";
> >> + clock-outputs = "imx-uart.1";
> >> + };
> >> +
> >> + uart2_clk: uart2 {
> >> + compatible = "clock";
> >> + clock-outputs = "imx-uart.2";
> >> + };
> >> +
> >> + fec_clk: fec {
> >> + compatible = "clock";
> >> + clock-outputs = "fec.0";
> >> + };
> >> + };
> >> +
> >> + aips@73f0 {
> >> + #address-cells = <1>;
> >> + #size-cells = <1>;
> >> + compatible = "simple-bus";
> >> + ranges = <0x0 0x73f0 0x10>;
> >> +
> >> + imx-uart@bc000 {
> >> + compatible = "fsl,imx51-uart";
> >> + reg = <0xbc000 0x1000>;
> >> + interrupts = <0x1f>;
> >> + fsl,has-rts-cts;
> >> + uart-clock = <&uart0_clk>, "uart";
> >> + };
> >> +
> >> + imx-uart@c {
> >> + compatible = "fsl,imx51-uart";
> >> + reg = <0xc 0x1000>;
> >> + interrupts = <0x20>;
> >> + fsl,has-rts-cts;
> >> + uart-clock = <&uart1_clk>, "uart";
> >> + };
> >> + };
> >> +
> >> + spba@7000 {
> >> + #address-cells = <1>;
> >> + #size-cells = <1>;
> >> + compatible = "simple-bus";
> >> + ranges = <0x0 0x7000 0x10>;
> >> +
> >> + imx-uart@c000 {
> >> + compatible = "fsl,imx51-uart";
> >> + reg = <0xc000 0x1000>;
> >> + interrupts = <0x21>;
> >> + fsl,has-rts-cts;
> >> + uart-clock = <&uart2_clk>, "uart";
> >> + };
> >> + };
> >> +
> > Moving spba@7000 section after aips@73f0 seems a quick fix to
> > get console=ttymxc0, but not a right fix to me.
> >
> > I do not find a real example on mx51, but let's make one, saying
> > there are two instance of one IP block, xyz1 and xyz2, and xyz1 is on
> > bus spba@7000) while xyz2 is on bus apis@73f0. Your fix is
> > broken here, as you need to put spba@7000 after aips@73f0 for
> > uart driver, while xyz driver requires spba@7000 stays before
> > aips@73f0.
>
> No, I don't think so. Where the section is put is not one strict rule,
> take a look at
> powe
Re: [PATCH V4 2/5] arm/dt: add very basic dts file for babbage board
Hi, Shawn, On Fri, Mar 11, 2011 at 4:36 PM, Shawn Guo wrote: > On Fri, Mar 11, 2011 at 03:33:24PM +0800, Jason Hui wrote: >> Hi, Shawn, [...] >> >> No, I don't think so. Where the section is put is not one strict rule, >> take a look at >> powerpc dts file, you will see that. >> > Maybe I did not make my point clear. I would try it one more time. > Let's see this virtual example. > [...] >> I don't see what's wrong with eCSPI and SSI when put spba behind aips >> just like uart. > > Sorry. Allow me correct the point here. eCSPI is not the example I > intended to put. Let's see SSI below. You do not get the correct > order anyway, either you put spba@7000 before or after > aips@83f0, unless you split the aips@83f0 section into > mulitples, which again I'm not sure if we should go for. > [...] > It does not matter at all whether you take my comments or not. The > thing matters is if we have the solution working for all the possible > cases. I know your meanings from the beginning. The case is that, There always will be solution for this case. I will adjust it when I met such issue in-deed. for example when adding SSI support at that time. I don't want to make things complex here for the basic DT support. BR, Jason. > > -- > Regards, > Shawn > > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 00/12][RFC] Intial Kconfig Fragment Demo
On Wed, Mar 9, 2011 at 9:13 AM, Andy Green wrote: > On 03/09/2011 09:04 AM, Somebody in the thread at some point said: > >>> I take it this magic of SMP or not is hidden in this config layering >>> scheme >>> you mentioned and it isn't really using the same config for say igep0020 >>> and >> >> No, it is in the black depths of ARM assembly and TBH, it is voodoo to >> me. Nothing to do with kernel config as such. The SMP kernel, at >> runtime, (binary) patches itself to convert locking primitives to >> no-ops in the UP case. Or something to the effect. > > Hum my IGEP0020 config here has CONFIG_BROKEN_ON_SMP=y set so I guess this > is to do with what you mentioned. > >>> Panda. In any event, there's a performance tradeoff running SMP kernel >>> on >>> uniprocessor to consider too. >> >> Apparently, with this one-time patching (per boot) there isn't such a >> tradeoff. > > OK thanks for the explanation. SMP-on-UP appears to be fully working nowadays. We currently don't build a single SMP kernel for omap4 and omap3, but I've been playing with that and it's been shown to work. Does anyone know whether we're planning to move to a single OMAP kernel? Has anyone measured the performance delta? In principle, we could make this move; but there could be issues I'm not aware of. Note that the SMP-on-UP support is fairly minimal -- only those things which literally will fail on UP are patched out. Cheers ---Dave > >>> Absolutely that's the future... in fact the bootloader should work the >>> same >>> way with one per-arch bootloader that detects what it is running on at >>> runtime, and at that point device-specific point hwpacks become very thin >>> or >>> non-existent and there's an epic reduction in how many different binaries >>> are needed to support many boards. >> >> I can hear the collective sighs of appreciation from distribution >> maintainers :) > > ^^ > > -Andy > > ___ > 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
[REPORT] 2011-03-10 Developer Platform team weekly report
Hi, The Developer Platform team weekly report for 2011-03-10 is now available and can be found at: https://wiki.linaro.org/Platform/DevPlatform/Status/2011-03-10 The report is also reproduced in full below. Regards, Jamie. -- Linaro Release Manager | Platform Project Manager -- * Period: (20110303-20110309) * PM: JamieBennett * Past reports : https://wiki.linaro.org/Platform/DevPlatform/Status * Burndown information : http://status.linaro.org/linaro-foundations.html == Key Points for wider discussion == * The process to produce and upstream ALIP cross-compile fixes is slow, what can we do to speed this up? * Multi-arch changes are still landing to the Ubuntu archive, lots of testing is needed here. * Panda display issues are now resolved so more testing of images on the Panda board is possible. * The Nano image needs to be slimmed down further. Tom has proposed some changes but others need to review and comment on them. == Team Highlights == * LTTng 0.245 has been ported to the linux-linaro-2.6.38 kernel. The changes are available at: http://git.linaro.org/gitweb?p=people/aviksil/linux-2.6-lttng-linaro.git;a=summary * Work continues on parts of kdelibs with the GL dependency removed from libplasma and kdebase-window-manager updated. * After many investigations the Panda non-display issue (bug:728603) has a fix. A config option change will enable the display to work with a knock-on effect of other bugs such as bug:720055 also being resolved. * A thumb2 enabled kernel build has been turned on after work by both the Kernel Working Group and the Developer Platform team. * Linaro's smallest full image, Nano, got reduced in size to 125mb installed. Proposed changes to eventually get closer to the 64mb installed target are currently in discussion. * libjpeg-turbo got further work this week as lintian errors were fixed. * Several more packages have been fixed for cross-compilation in the Ubuntu archive. * dpkg support for multiarch library installation is in the Ubuntu archive but needs another upload due to changes in the planned dpkg database format. There has also been some patches submitted to apt for the major multiarch blocker bugs as the team continue towards a true multi-arch solution. * Cross toolchain packages got reuploaded to the archive fixing recent issues. == Upcoming Deliverables == * Beta Freeze 2011-03-24 * New build of Linaro Linux kernel * systemtap v1.3 + cherry-picked fixes * apt fixes to Ubuntu * New dpkg to Ubuntu that implements support for the final multi-arch library paths == Risks / Issues == * '''MEDIUM IMPACT''': Peter Pearce reports that bootstrapping & making cross-compile patches upstreamable are slowing the rate of package fixing. The (current) alip package list will not be complete for beta freeze. * '''LOW IMPACT''': All multiarch work is landing past feature-freeze. Requires exception approval from the Ubuntu and Linaro release teams. == Miscellaneous == * Wiki pages of note this week: * http://wiki.debian.org/DebianBootstrap * https://wiki.linaro.org/Chromiumos/ChromeosWm ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 00/12][RFC] Intial Kconfig Fragment Demo
On Fri, Mar 11, 2011 at 12:32 PM, Dave Martin wrote: > On Wed, Mar 9, 2011 at 9:13 AM, Andy Green wrote: >> On 03/09/2011 09:04 AM, Somebody in the thread at some point said: >> I take it this magic of SMP or not is hidden in this config layering scheme you mentioned and it isn't really using the same config for say igep0020 and >>> >>> No, it is in the black depths of ARM assembly and TBH, it is voodoo to >>> me. Nothing to do with kernel config as such. The SMP kernel, at >>> runtime, (binary) patches itself to convert locking primitives to >>> no-ops in the UP case. Or something to the effect. >> >> Hum my IGEP0020 config here has CONFIG_BROKEN_ON_SMP=y set so I guess this >> is to do with what you mentioned. >> Panda. In any event, there's a performance tradeoff running SMP kernel on uniprocessor to consider too. >>> >>> Apparently, with this one-time patching (per boot) there isn't such a >>> tradeoff. >> >> OK thanks for the explanation. > > SMP-on-UP appears to be fully working nowadays. We currently don't > build a single SMP kernel for omap4 and omap3, but I've been playing > with that and it's been shown to work. Does anyone know whether we're > planning to move to a single OMAP kernel? Has anyone measured the > performance delta? > > In principle, we could make this move; but there could be issues I'm > not aware of. > > Note that the SMP-on-UP support is fairly minimal -- only those things > which literally will fail on UP are patched out. Do you have a pointer to the patches that enabled this support? SHA ids are fine. I'm curious what the runtime patching voodoo looks like. /Amit ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Making linaro-nano smaller or Give Up Disk Space for Lent
On Thu, Mar 10, 2011 at 4:43 PM, Loïc Minier wrote: > On Wed, Mar 09, 2011, Tom Gall wrote: >> Specifically from the installed image after the hwpack deps are >> installed get rid of the following: >> rm -f ./var/lib/apt/lists/*Packages >> rm -f ./var/lib/apt/lists/*Sources >> rm -f ./var/lib/apt/lists/*Release >> rm -f ./var/lib/apt/lists/*Release.gpg >> rm -f ./var/cache/apt/pkgcache.bin >> rm -f ./var/cache/apt/srcpkgcache.bin > > I think there is a way for APT to keep compressed versions of these > files; it's the Acquire::GzipIndexes option There are some possible disadvantages with this: a) there may be a speed / memory overhead for some operations which need to access the lists b) doesn't reduce the size of the (compressed) tarball / cramfs / ramdisk image If we don't mind a packager performance hit (probably acceptable for an explicitly footprint-conscious image such as nano), then an additional option is to disable the apt cache, which contains yet another (uncompressed) copy of the information in the package lists. A slower packager is still much more use than no packager. apt.conf(5) says: "Dir::Cache contains locations pertaining to local cache information, such as the two package caches srcpkgcache and pkgcache as well as the location to place downloaded archives, Dir::Cache::archives. Generation of caches can be turned off by setting their names to be blank. This will slow down startup but save disk space. It is probably preferred to turn off the pkgcache rather than the srcpkgcache. Like Dir::State the default directory is contained in Dir::Cache" /var/lib/dpkg/info is often pretty big too; if there was a way to keep this compressed and/or remove certain files, that could be interesting. Cheers ---Dave > > -- > Loïc Minier > > ___ > 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: ARM cross compiler backport available for Lucid and Maverick
Dnia 2011-01-21, pią o godzinie 16:44 +0100, Marcin Juszkiewicz pisze: > > > I would like to announce new Linaro PPA available for all users of Ubuntu > > > 10.04 Lucid and 10.10 Maverick releases: > > > > > > https://launchpad.net/~linaro-maintainers/+archive/toolchain > > > > > > What is inside? Packages with current (gcc-linaro 2011.01-1 based on > > > 4.5.2 release) cross toolchain backported from Ubuntu 11.04 Natty. > > > Please test them and report any problems. PPA got updated to following components: - eglibc 2.13-0ubuntu4 - binutils 2.21.0.20110302-1ubuntu1 - gcc 4.5.2-5ubuntu2 - gdb 7.2-1ubuntu9 - gcc-defaults-armel-cross 1.4 Users of Lucid and Maverick editions can now cross compile applications for ARM targets running Natty. To install cross compilers you can use "apt-get install gcc-arm-linux-gnueabi" command. Replace gcc with g++, gfortran, gobjc, gobjc++ if you need any of those languages. To debug your cross binaries please install gdb-multiarch as it knows how to handle ARM code properly. Please report any problems against "armel-cross-toolchain-base" and "gcc-4.5-armel-cross" packages at launchpad. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Making linaro-nano smaller or Give Up Disk Space for Lent
On Wed, Mar 9, 2011 at 7:15 PM, Tom Gall wrote:
> Hi All,
>
> In the developer platforms team we're working on getting the
> linaro-nano image so that it is considerably smaller. To date I've
> been using the approach I outlined last fall in a previous post to
> this list.
>
> Some highlights to nano:
> * The linaro-image boots just as our linaro-headless image did
> (upstart and friends)
> * it can be updated, or additional pkgs installed via apt-get
> * networking works
> * busybox is in use tho not necessarily universally
> * ureadahead, python, have been removed
> * docs have been removed
> * linux-firmware has been removed (binary kernel firmware blobs)
> * locales is remove
>
> Installed image is 125 Megs. (Down from 290 Meg) We're on the cusp of
> being able to fit into 128 megs of flash.
>
> This brings me to the subject of the kernel. hwpacks besides
> installing linux-firmware (32 Megs) but also approx 50 Megs in
> modules. Yet on my beagleboard lsmod notes
>
> Module Size Used by
> asix 12805 0
> usbnet 17027 1 asix
> omap2_mcspi 8441 0
> omap_wdt 4093 0
> hid_apple 4999 0
> twl4030_usb 4950 0
> twl4030_pwrbutton 1298 0
> gpio_keys 6072 0
> leds_gpio 2198 0
> usbhid 39072 0
> hid 74787 2 hid_apple,usbhid
>
> Clearly we don't need all of these modules and I don't think it's an
> unreasonable change our policy to "build what's needed + some
> reasonable subset of function that our average user might neeed".
>
> I don't know why we're installed the firmware deb, does any of the
> hardware we're supporting even use that?
>
> From the directories where modules are located there is the following size
> info:
> 812 ./crypto
> 7568 ./net
> 2456 ./sound
> 60 ./arch
> 28372 ./drivers
> 172 ./lib
> 272 ./ubuntu
> 8316 ./fs
> 48032 .
>
> Going deeper it's pretty easy to spot low hanging fruit:
> From fs - Do we need afs, jfs, code, minix, hpfs, xfs, hfs, hfsplus,
> gfs2, reiserfs... I'm thinking no.
> From drivers - net and media make about about 1/3rd of the 28 meg in
> use, I'm sure there's a number of drivers in here that can just be
> turned off.
> From sound - ac97, are there arm boards that use that?
> From net - x25, decnet, appletalk ?
>
> So that said, what is the best way to proceed?
>
> 1) Is there agreement that for all the kernels we supply that we
> should change the policy for kernel configs to not default to
> everything on?
> (Maybe we should be using the upstream config with minimal modifications?)
>
> Pro: everyone benefits from the diet
> Con: Our kernel would be build slightly different than ubuntu's
> others:
>
> 2) Linaro-media-create shouldn't install linux-firmware_1.47_all.deb ?
> Do we have any any hardware that needs it? If so could there be a
> --nano option to not install it?
>
> 3) linaro-media-create should have some kind of option (--nano) to
> clear out apt caches (saves ~40 meg of space)
>
> Specifically from the installed image after the hwpack deps are
> installed get rid of the following:
> rm -f ./var/lib/apt/lists/*Packages
> rm -f ./var/lib/apt/lists/*Sources
> rm -f ./var/lib/apt/lists/*Release
> rm -f ./var/lib/apt/lists/*Release.gpg
> rm -f ./var/cache/apt/pkgcache.bin
> rm -f ./var/cache/apt/srcpkgcache.bin
>
> Pro: if you never run apt* you won't mind the cold caches
> Con: if you're running out of nand and you're going to apt-get upgrade
> your system, you're probably going to run out of space (Probably a
> problem to solve in a future cycle)
>
>
> It's important through this exercise for people to speak up about what
> can and can NOT be safely turned off.
>
> Thanks for your time, attention, suggestions and feedback.
>
> Regards,
> Tom
>
> ___
> linaro-dev mailing list
> linaro-dev@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-dev
>
Although it's not directly related to nano (which is useful in itself
as a miminal usable system) it could make sense to be able to generate
images with no built-in packager support - i.e., the packer must
effectively be run offline to generate the filesystem. There's also
the possibility of keeping the packager information outside the main
tarball, so the filesystem can be modified/updated offline after
creation.
Such images don't need dpkg or apt built in; and hence don't need
/var/lib/dpkg or /var/{lib,cache}/apt, and may not need perl,
libstdc++ etc. Altogether, that will be a very significant saving
compared with something like the nano image.
As I understand it, debootstrap or germinate basically do the right
thing. All we would need would be to document the use of the existing
tools, and provide suitable ultra-minimal seeds (at the level of
busybox+libc only) and/or an ultra-minimal --variant for debootstrap.
If that's see
Re: Making linaro-nano smaller or Give Up Disk Space for Lent
On Fri, Mar 11, 2011, Dave Martin wrote: > As I understand it, debootstrap or germinate basically do the right > thing. All we would need would be to document the use of the existing > tools, and provide suitable ultra-minimal seeds (at the level of > busybox+libc only) and/or an ultra-minimal --variant for debootstrap. So far, the two approaches which had been proposed were: * an initramfs-tools based initrd which would copy selected binaries manually; this probably gives a very minimal root image, but it's a bit cumbersome to manage for us * a classic seed based image; this is convenient to generate, but it's not particularly small The custom debootstrap script you're proposing is one way; I would also think we could consider the udeb route: udebs are meant to be small and used in Debian Installer which offers a rescue system. D-I also has fancy things like openssh, and can retrieve additional components from the network -- as long as they are udeb-ified. D-I images already exist as initrds today, with very small sizes; you can browse random image types under http://ftp.debian.org/debian/dists/stable/main/installer-armel/current/images/ Even full images not requiring the network to start the installer like the hd-media boot image have an easy time beating our current sizes: http://ftp.debian.org/debian/dists/stable/main/installer-i386/current/images/hd-media/ (this is i386 as there is no armel one) Note that boot.img above is 24M compressed and 250M decompressed, but I'm assuming we can use a compressed initrd for everything so that the compressed size would be what matters. Cheers, -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Making linaro-nano smaller or Give Up Disk Space for Lent
+++ Dave Martin [2011-03-11 11:20 +]: > Although it's not directly related to nano (which is useful in itself > as a miminal usable system) it could make sense to be able to generate > images with no built-in packager support - i.e., the packer must > effectively be run offline to generate the filesystem. Yes. Emdebian calls this 'baked', and has some support for it - mostly in postprocessing the packages to remove all the stuff which is only needed for package-management. http://www.emdebian.org/baked/ > There's also > the possibility of keeping the packager information outside the main > tarball, so the filesystem can be modified/updated offline after > creation. Yep - and so long as you have cross-installing working. The problem is that whilst apt has always had excellent suppport for 'install things over there, and keep the database somewhere else', maintainer scripts have no way of being pointed at a sub-dir, so have to be chrooted. I don't think we currently have support for keeping the dpkg database outside the chroot but being able to run all the maintiner scripts in the chroot (also needs qemu, so no use where that is not available). We did show (Ed Bartosh did the work) back in 2005 that's it dead simple to add $(ROOTFS) all over all the scripts and have this work from outside (for most things - there are a few things that go wrong due to useing host config instead of target config), but it's an intrusive solution and we didn't try to push it further. It's nice because it avoids the need for qemu so you get genuine cross-installing. This issue highlights the way that we don't distinguish between install-dependencies and runtime dependencies in packages. A lot of package deps are actually only needed by the install scripts, so on an externally-maintained system are not needed - again making for much smaller images. I'd love to see support for these things in Debian, but both are intrusive - especially the former, so we'd need good justification for it. Perhaps Linaro can provide that... > As I understand it, debootstrap or germinate basically do the right > thing. All we would need would be to document the use of the existing > tools, and provide suitable ultra-minimal seeds (at the level of > busybox+libc only) and/or an ultra-minimal --variant for debootstrap. I don't think it's that simple - as explained above. But perhaps there is stuff to deal with this. I haven't been keeping up with all the new chroot and image-making tools. > If that's seen to be interesting, we should probably discuss it with > the emdebian folks-- there's a risk of reinventing what they do; plus > they certainly have tools which are useful for this. Indeed. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Making linaro-nano smaller or Give Up Disk Space for Lent
Hi, > > Installed image is 125 Megs. (Down from 290 Meg) We're on the cusp > > of being able to fit into 128 megs of flash. > > If that's seen to be interesting, we should probably discuss it with > the emdebian folks-- there's a risk of reinventing what they do; plus > they certainly have tools which are useful for this. It is interesting indeed... The "old style" ALIP from ARM's PDSW, in it's minimal configuration, used to take 26MB of space (uncompressed!) providing very simple, yet still functional environment. Frankly speaking, when the "nano" idea was born, I was hoping that it would be comparable size-wise. Well, at most 50 Megs? (it's already twice bigger ;-) Cheers! Paweł ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH V2 1/3] arm/dt: add basic mx51 device tree support
On Friday 11 March 2011, Jason Hui wrote: > >> Alternatively, it could be done the other way round: rename the identifiers > >> in the file from mx51_ to mx5_, and make sure that they don't contain > >> any mx51 specific settings but always refer to properties in the > >> device tree for the differences. > > > > I saw that your V4 still implements neither Shawn's suggestion nor mine. > > As you said, I don't want to make thing complex too. I don't want to > have mx51_dt or > mx53_dt as Shawn Suggests and I still don't want to make it change to > mx5 now as you suggest > Since this patch only support mx51 currently. I think it's easy to > make change later once mx53 in-deed > added in DT support, what do you think? It would also be easy to rename the file from mx51_dt to board_dt when it becomes more generic. I don't consider it a show-stopper though and am comfortable with leaving it to your own judgement. Generally speaking, you don't have to do everything that reviewers suggest, but please reply to explain your reasons if you disagree. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[REPORT] 2011-03-10 Validation team weekly report
Hi, The Validation team weekly report for 2011-03-10 is now available and can be found at: https://wiki.linaro.org/Platform/Validation/Status/2011-03-10 The report is also reproduced in full below. Regards, Jamie. -- Linaro Release Manager | Platform Project Manager -- * Period: (20110302-20110309) * PM: JamieBennett * Past reports : https://wiki.linaro.org/Platform/Validation/Status * Burndown information : http://status.linaro.org/linaro-validation.html == Key Points for wider discussion == * A request for comments on the Debian Django packaging guide has been made. Please read and give comments on: http://wiki.debian.org/DjangoPackagingDraft. * Power Management tests are planned to be integrated into the test suite and visualisation tools. The best way to do this is under discussion and the team invites more comments. == Team Highlights == * The Django packaging guideline for Debian was produced and is available at http://wiki.debian.org/DjangoPackagingDraft. There are discussions ongoing on the debian-python mailing list for feedback. * A first (and second) release of the django-debian package was made for connecting django database settings to dbconfig-common. This is being used on the LAVA project for database integration. * Initial discussions have been made to integrate some of the work the Power Management Working Group is doing in to abrek (the test-suite framework) and launch-control (the test visualisation tool). The ability to automatically test and visualise the power consumption on boards will take the Validation team around 2-4 weeks to complete. * Work continues on LAVA with two new branches containing improvements done this week. * abrek gained the ability to save bundles at the end of a test run. == Upcoming Deliverables == * launch-control 0.3c2 deployed on validation.linaro.org == Risks / Issues == * '''HIGH IMPACT''': Zygmunt's Beagle Board C4 appears to have hardware issues (1 week). * '''HIGH IMPACT''': The validation scheduler Blueprint continues to lag behind with 37 work items to complete (none completed so far) - https://launchpad.net/lava/+spec/linaro-n-validation-scheduler (several weeks). Discussions are on going to find a way to unblock this project. == Miscellaneous == * Wiki pages of note this week: * http://wiki.debian.org/DjangoPackagingDraft ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH] [android/devices/linaro/common] Correct permission, owner and group on files in the root tarball
Fix for LP #731780.
---
tasks/mktarball.sh | 60
tasks/tarballs.mk |4 ++-
2 files changed, 63 insertions(+), 1 deletions(-)
create mode 100755 tasks/mktarball.sh
diff --git a/tasks/mktarball.sh b/tasks/mktarball.sh
new file mode 100755
index 000..622ff47
--- /dev/null
+++ b/tasks/mktarball.sh
@@ -0,0 +1,60 @@
+#!/bin/bash
+
+# This is a modified copy of build/tools/mktarball.sh
+
+# $1: path to fs_get_stats program
+# $2: start dir
+# $3: subdir to tar up (from $2)
+# $4: target tar name
+# $5: target tarball name (usually $(3).bz2)
+
+if [ $# -ne 5 ]; then
+echo "Error: wrong number of arguments in cmd: $0 $* "
+exit 1
+fi
+
+fs_get_stats=`readlink -f $1`
+start_dir=`readlink -f $2`
+dir_to_tar=$3
+target_tar=`readlink -f $4`
+target_tarball=`readlink -f $5`
+
+cd $2
+
+#tar --no-recursion -cvf ${target_tar} ${dir_to_tar}
+rm ${target_tar} > /dev/null 2>&1
+
+# do dirs first
+subdirs=`find ${dir_to_tar} -type d -print`
+files=`find ${dir_to_tar} \! -type d -print`
+for f in ${subdirs} ${files} ; do
+curr_perms=`stat -c 0%a $f`
+[ -d "$f" ] && is_dir=1 || is_dir=0
+f2=`echo ${f#*/}`
+new_info=`${fs_get_stats} ${curr_perms} ${is_dir} ${f2}`
+new_uid=`echo ${new_info} | awk '{print $1;}'`
+new_gid=`echo ${new_info} | awk '{print $2;}'`
+new_perms=`echo ${new_info} | awk '{print $3;}'`
+#echo "$f: dir: $is_dir curr: $curr_perms uid: $new_uid gid: $new_gid "\
+# "perms: $new_perms"
+tar --no-recursion --numeric-owner --owner $new_uid \
+--group $new_gid --mode $new_perms -p -rf ${target_tar} ${f}
+done
+
+if [ $? -eq 0 ] ; then
+case "${target_tarball}" in
+*.bz2 )
+bzip2 -c ${target_tar} > ${target_tarball}
+;;
+*.gz )
+gzip -c ${target_tar} > ${target_tarball}
+;;
+esac
+success=$?
+[ $success -eq 0 ] || rm -f ${target_tarball}
+rm -f ${target_tar}
+exit $success
+fi
+
+rm -f ${target_tar}
+exit 1
diff --git a/tasks/tarballs.mk b/tasks/tarballs.mk
index e569e98..e6354fc 100644
--- a/tasks/tarballs.mk
+++ b/tasks/tarballs.mk
@@ -2,11 +2,13 @@
# Trigger build of tar balls for the linaro boards
#
+LINARO_MKTARBALL := device/linaro/common/tasks/mktarball.sh
+
###
## root tarball
define build-roottarball-target
$(hide) echo "Target root fs tarball:" $(INSTALLED_ROOTTARBALL_TARGET)
-$(hide) $(MKTARBALL) $(FS_GET_STATS) \
+$(hide) $(LINARO_MKTARBALL) $(FS_GET_STATS) \
$(PRODUCT_OUT)/root . $(PRIVATE_ROOT_TAR) \
$(INSTALLED_ROOTTARBALL_TARGET)
endef
--
1.7.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
storage liability test
Hi, I am looking for a test framework to verify liability of I/O storage. Most of the test tool I find focus on performance. I would like to run test that compares in-buffer and out-buffer, use different address and size alignment for in-buffer and out-buffer, runs tests simultaneously on multiple block devices, etc... The test can run on FS level or block level either way is fine. Any suggestions? /Per ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[RFC] kprobes with thumb2 conditional code
Hello All
I'm about to start work on getting kprobes working with thumb2.
One of the issues I have is that when probes are placed onto
conditionally executed instructions in a IT block, they may not fire if
the condition is not met. This is because on ARM we use invalid
instructions for breakpoints, and the ARM ARM says:
"it is IMPLEMENTATION DEFINED whether the instruction executes as a
NOP or causes an Undefined Instruction exception"
This is a similar issue to that already encountered by GDB [1][2]
If we take this code as an example...
probe1:
if(condition) {
probe2:
some_code;
}
It seams reasonable at first sight that probe2 would only fire if the
condition is true. This will always be the case if the compiler
generates test-and-branch code, but if it generates conditionally
executed instructions for 'some_code' then it gets complicated...
The current arm kprobes implementation will always fire probe2 because
it uses unconditional instructions for its breakpoints. With thumb
instructions we can't force unconditional execution, so we would have an
'implementation defined' situation whether it would fire or not when the
condition is false. (Thought you would hope it would be consistent on a
particular device.)
Some options for dealing with this, in increasing order of
complexity...
1. Accept the situation as described.
2. Change arm probes to use conditional instructions so we would
(hopefully) have consistent undefined behaviour in both arm and thumb
code. (If that isn't an oxymoron :-)
3. Do 2, and modify kprobe_handler to test for false firings (breakpoint
when condition false) and not execute the probe's callback functions in
these cases. E.g. consistently make probe2 appear to not fire when
condition is false.
4. Make thumb probes fire unconditionally like current arm
implementation...
4a. Use breakpoint instructions rather than undefined instructions for
kprobes. Apparently this doesn't play nicely with hardware debuggers [2]
though I don't have enough experience in this area to otherwise comment.
4b. Rewrite IT blocks when probes are inserted into them to make the
breakpoint unconditional. This would require parsing backwards through
the instruction stream to find the IT instruction, which I don't believe
is possible with variable length thumb instructions. Or, another
possibility which was suggested to me, use the unwind table to find the
start of the containing function and parse forwards to find the IT
instruction. Though the kernel doesn't currently have enough information
to skip things like inline data that may be the function.
The effort, complexity and bloat involved in 4b seems to be rather
excessive to me, even before getting into the book-keeping required to
handle multiple probes in the same IT block. So 4b is a bit of a straw
man.
BTW, does anyone know of any test code for kprobes, particularly with
regard to checking emulation/single-stepping of the different CPU
instructions?
Thanks for any feedback
--
Tixy
[1] http://permalink.gmane.org/gmane.comp.gdb.patches/54862
[2]
http://thread.gmane.org/gmane.linux.ports.arm.kernel/72199/focus=73489
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Making linaro-nano smaller or Give Up Disk Space for Lent
On Fri, Mar 11, 2011 at 01:01:46PM +0100, Loïc Minier wrote: > On Fri, Mar 11, 2011, Dave Martin wrote: > > As I understand it, debootstrap or germinate basically do the right > > thing. All we would need would be to document the use of the existing > > tools, and provide suitable ultra-minimal seeds (at the level of > > busybox+libc only) and/or an ultra-minimal --variant for debootstrap. > So far, the two approaches which had been proposed were: > * an initramfs-tools based initrd which would copy selected binaries >manually; this probably gives a very minimal root image, but it's a >bit cumbersome to manage for us > * a classic seed based image; this is convenient to generate, but it's >not particularly small > The custom debootstrap script you're proposing is one way; I would also > think we could consider the udeb route: udebs are meant to be small and > used in Debian Installer which offers a rescue system. D-I also has > fancy things like openssh, and can retrieve additional components from > the network -- as long as they are udeb-ified. D-I images already > exist as initrds today, with very small sizes; you can browse random > image types under > > http://ftp.debian.org/debian/dists/stable/main/installer-armel/current/images/ I'm not keen on this route because we are limited then to precisely that set of components that currently build udebs for inclusion in our image. We don't want to be in the position of having to add udebs to the archive in order to make changes to our nano image, that's just too high a barrier. We should be able to get an equivalent effect with an initramfs, which can reuse the existing .debs and extract contents as appropriate. The main thing this won't get us is building with -Os by default; I'm not sure how much that helps on armel, but I wouldn't expect it to offset the maintenance cost? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Making linaro-nano smaller or Give Up Disk Space for Lent
On Fri, Mar 11, 2011 at 11:20:35AM +, Dave Martin wrote: > Although it's not directly related to nano (which is useful in itself > as a miminal usable system) it could make sense to be able to generate > images with no built-in packager support - i.e., the packer must > effectively be run offline to generate the filesystem. There's also > the possibility of keeping the packager information outside the main > tarball, so the filesystem can be modified/updated offline after > creation. For the nano image, upgradability with dpkg/apt is not a hard requirement. Given a constrained footprint, you aren't likely to have room to download .debs and do the upgrade anyway! (And one of the alternatives being considered, initramfs, definitely has no upgrade support.) Tom, if we were to blow away /var/lib/dpkg/, /var/lib/apt, /var/cache/apt, and /var/cache/debconf entirely, how much space does that buy us on nano? > As I understand it, debootstrap or germinate basically do the right > thing. All we would need would be to document the use of the existing > tools, and provide suitable ultra-minimal seeds (at the level of > busybox+libc only) and/or an ultra-minimal --variant for debootstrap. debootstrap will balk at trying to install a system with no dpkg installed, because dpkg is an essential package. And indeed, various packages will fail to configure properly if dpkg is absent - I don't know if any of the packages in the current nano seed are affected, but no sense borrowing trouble. If we want the package manager out, we should do this with postprocessing. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Making linaro-nano smaller or Give Up Disk Space for Lent
On Fri, Mar 11, 2011 at 11:08:57AM +, Dave Martin wrote: > /var/lib/dpkg/info is often pretty big too; if there was a way to keep > this compressed and/or remove certain files, that could be > interesting. Nope, this is the package manager db; removing things from this directory corrupts the db. So this is an all or nothing proposition. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Making linaro-nano smaller or Give Up Disk Space for Lent
+++ Steve Langasek [2011-03-11 09:52 -0800]: > On Fri, Mar 11, 2011 at 11:20:35AM +, Dave Martin wrote: > debootstrap will balk at trying to install a system with no dpkg installed, > because dpkg is an essential package. And indeed, various packages will > fail to configure properly if dpkg is absent - I don't know if any of the > packages in the current nano seed are affected, but no sense borrowing > trouble. If we want the package manager out, we should do this with > postprocessing. multistrap can be run with 'omitrequired' in the config in which case it really will only put in what you asked for and the stated dependencies of those packages, as resolved by apt. This is excellent foot-shooting territory, but it does allow the making of smaller rootfses, which is one of the things it was designed for (small, cross-architecture rootfses, using apt and dpkg for resolving and installing). It's probably a better tool for making nano images than debootstrap, which has a more conventional focus. Certainly worth looking into. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: A good skia [was: Re: [RFC] Linaro Toolchain for Android and NDK]
On 8 March 2011 02:37, Jim Huang wrote: > I just updated wiki page about Google's compiler benchmark suite: > https://wiki.linaro.org/Platform/Android/UpstreamToolchain > Please check the section, "Evaluate Benchmark suite". > Through adb[1], it is highly convenient to bench generated binary > files on Android device: [...] > time adb shell 'cd /data/local/perflab; echo > Android_TIME_STAMP_$(timestamp); /data/local/perflab/skia_bench > -repeat 15; echo Android_TIME_STAMP_$(timestamp)' > > 0.00user 0.00system 4:33.25elapsed 0%CPU (0avgtext+0avgdata 4208maxresident)k > 0inputs+0outputs (0major+325minor)pagefaults 0swaps > timestamp: not found [...] > The function "timestamp" is broken at the moment, and I am still > looking for the details. Here "timestamp" is an Android command line tool which reports the current time in seconds. You can get it from scripts/timestamp/src/timestamp.c http://android.git.kernel.org/?p=toolchain/benchmark.git;a=blob;f=scripts/timestamp/src/timestamp.c;hb=HEAD To build the tool, enter the timestamp directory and type ../bench.py --action=build --toolchain= adb push out/timestamp to /system/bin on Android device. Then you are able to call timestamp to report time stamp in seconds. Sincerely, -jserv ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[NOTES] 2011-03-11 Engineering Resources weekly meeting
Hi, The minutes from the Engineering Resources team meeting can be found here: https://wiki.linaro.org/Mentoring/Status/WeeklyMeeting/2011-03-11 Summary below. --Matt === Action Items from This Meeting === * AddNewHardware/HardwarePack pages need to explain kernel packages as Steve noted below * HardwarePacks page refers to Maverick instead of Natty * Mentoring section needs to be renamed and back links should be fixed * A better header for wiki that includes things like a "Resources" link in banner/header * Toolchain documentation improvement === Minutes === Feedback from Steve L * No super hot button issues with team * come up with clearer idea of what goes in hwpacks and policies around them * snag with v310 hwpack. needed u-boot not built by John R * missing linux-meta package in their hwpack. package name changes each time ABI is bumped. (Scott has had people confused by Meta-Packages) * Do we need new "types/names" of hwpacks for situations like this * Maybe ER team needs to add some to HWPACK documentation to mention these things. * Scott B - ask Andy Green for feedback on documentation changes * HardwarePacks page refers to Maverick. Should be Natty and probably say "CURRENT RELEASE" * documentation under mentoring. needs to be promoted * rename to how-to * put something on main page and list latest updates * suggestions for front page: * change the way the header looks so that people will actually start to notice it again. Put some main links in this new header * joey links: https://wiki.canonical.com/OEMServices https://wiki.linaro.org/LinaroHeader Feedback from Scott B * cross-compiler documentation is still confusing * break up page by 4.4/4.5 versions into 2 pages. and then versions. * we shouldn't even suggest 4.4. 4.5 is what should be used * explain why you do a add-apt-repository * Cross-development Environment for userspace. There's nothing. We don't have a good story on this. Steve says we're improving so not spend much time trying to explain Feedback from Kiko * echo steve's comments on hwpacks * (scott) naming convention for community/landing team to indicate what is supported Discussion after leads * RequirementsProcessHowto - should be per release for as things change * ProductRequirement is a little off. Its not needed * Joey to ask if release will just use TechnicalTopics or still do a TechnicalRequirements page ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Making linaro-nano smaller or Give Up Disk Space for Lent
On Wed, Mar 9, 2011 at 8:15 PM, Tom Gall wrote: > I don't know why we're installed the firmware deb, does any of the > hardware we're supporting even use that? > fwiw... TI wlan chipset firmware (wl127x) is in this package. so on pandaboard with current mainline + linux-firmware you can get wifi out-of-the-box. not sure you are interested in wifi on -nano though... ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 00/12][RFC] Intial Kconfig Fragment Demo
On Fri, Mar 11, 2011 at 3:32 AM, Dave Martin wrote: > On Wed, Mar 9, 2011 at 9:13 AM, Andy Green wrote: >> On 03/09/2011 09:04 AM, Somebody in the thread at some point said: >> I take it this magic of SMP or not is hidden in this config layering scheme you mentioned and it isn't really using the same config for say igep0020 and >>> >>> No, it is in the black depths of ARM assembly and TBH, it is voodoo to >>> me. Nothing to do with kernel config as such. The SMP kernel, at >>> runtime, (binary) patches itself to convert locking primitives to >>> no-ops in the UP case. Or something to the effect. >> >> Hum my IGEP0020 config here has CONFIG_BROKEN_ON_SMP=y set so I guess this >> is to do with what you mentioned. >> Panda. In any event, there's a performance tradeoff running SMP kernel on uniprocessor to consider too. >>> >>> Apparently, with this one-time patching (per boot) there isn't such a >>> tradeoff. >> >> OK thanks for the explanation. > > SMP-on-UP appears to be fully working nowadays. We currently don't > build a single SMP kernel for omap4 and omap3, but I've been playing > with that and it's been shown to work. Does anyone know whether we're > planning to move to a single OMAP kernel? Has anyone measured the > performance delta? linux-linaro-omap runs on omap[34] and has for most of this cycle. Currently CONFIG_SMP and CONFIG_SMP_ON_UP are both on. OMAP4 has had some glitches, first no display then broken display. The next release has display with blue text just like the Ubuntu kernel:). Since linux-linaro-omap is based on upstream or headed upstream patches it does not have all the functionality of the Ubuntu ti-omap4 kernel. > > In principle, we could make this move; but there could be issues I'm > not aware of. > > Note that the SMP-on-UP support is fairly minimal -- only those things > which literally will fail on UP are patched out. > > Cheers > ---Dave > >> Absolutely that's the future... in fact the bootloader should work the same way with one per-arch bootloader that detects what it is running on at runtime, and at that point device-specific point hwpacks become very thin or non-existent and there's an epic reduction in how many different binaries are needed to support many boards. >>> >>> I can hear the collective sighs of appreciation from distribution >>> maintainers :) >> >> ^^ >> >> -Andy >> >> ___ >> 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 > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 1/5] arm/dts: babbage: add gpt and uart related clock nodes
On Tue, Mar 08, 2011 at 11:44:48AM +0800, Shawn Guo wrote:
> On Mon, Mar 07, 2011 at 10:48:10AM -0700, Grant Likely wrote:
> > On Mon, Mar 7, 2011 at 9:22 AM, Shawn Guo wrote:
> > > The patch is to add all gpt, uart related dt clock nodes for babbage.
> > > It sticks to the clock name used in clock-mx51-mx53.c, so that
> > > everything gets consistent to Reference Manual. For example, the
> > > numbering in clock name usually starts from 1, while 'reg' property
> > > numbering starts from 0 to easy clock binding.
> > >
> > > Besides the generally used clock bindings, the following properties
> > > are proposed in this patch.
> > >
> > > * clock-alias
> > > Like clock-outputs to reflect cl->dev_id, property clock-alias is
> > > defined to reflect cl->con_id.
> >
> > This feels like leakage of Linux kernel implementation details getting
> > encoded into the binding. There shouldn't be any need for a clock
> > alias property. It should all just work to have multiple devices
> > explicitly refer to the same clock node because the dt clock support
> > patch gets first crack at resolving a struct clk pointer before clkdev
> > does its lookup.
> >
> This is to make clk_get() work. Let's take a look at this example.
> i.MX28 integrates a amba-pl011 uart controller, and there are two
> places calling clk_get() with the same dev_id to get the different
> 'clk'.
>
> static struct clk_lookup lookups[] = {
> /* for amba bus driver */
> _REGISTER_CLOCK("duart", "apb_pclk", xbus_clk)
> /* for amba-pl011 driver */
> _REGISTER_CLOCK("duart", NULL, uart_clk)
> ...
> };
>
> * drivers/amba/bus.c - to get xbus_clk
> static int amba_get_enable_pclk(struct amba_device *pcdev)
> {
> struct clk *pclk = clk_get(&pcdev->dev, "apb_pclk");
> int ret;
>
> pcdev->pclk = pclk;
>
> if (IS_ERR(pclk))
> return PTR_ERR(pclk);
>
> ret = clk_enable(pclk);
> if (ret)
> clk_put(pclk);
>
> return ret;
> }
>
> * drivers/tty/serial/amba-pl011.c - to get uart_clk
> static int pl011_probe(struct amba_device *dev, struct amba_id *id)
> {
> ...
>
> uap->clk = clk_get(&dev->dev, NULL);
> if (IS_ERR(uap->clk)) {
> ret = PTR_ERR(uap->clk);
> goto unmap;
> }
>
> ...
> }
>
> Will this be broken if we do not have an alias in dt clock to reflect
> con_id?
>
> > >
> > > * clock-depend
> > > The mxc 'struct clk' has the member 'secondary' to refer to the clock
> > > that the 'clk' has dependency on. This 'secondary' clock needs to be
> > > on whenever the 'clk' is set to on. This clock-depend property is
> > > defined to reflect this 'secondary' clock.
> >
> > This is fine, but it is a Freescale specific binding. Each of the
> > imx51 clock nodes should have compatible set to something like
> > "fsl,imx51-clock" so that the OS can know that it should be using this
> > binding.
> >
> I doubt this is Freescale clock only use case. But I will do what you
> suggest here anyway.
>
[...]
> > > + pll1_main_clk: pll1_main {
> > > + compatible = "clock";
> >
> > As hinted on above, "clock" doesn't look like a good compatible
> > property. It should specify the specific implementation of a clock
> > device. ie. "fsl,imx51-clock". Even that example may be too generic
> > if there are multiple types of clock controllers in the imx51 SoC.
> >
> We are implementing clock-mx51-mx53.c. Would it be better to use
> 'fsl,mx5-clock'? Or, we will have to scan 'fsl,imx51-clock' and
> 'fsl,imx53-clock'. Oh, i.MX50 is also coming.
>
I'm going to use 'fsl,mxc-clock', as the 'clk' is currently defined
under plat-mxc. Let me know if anyone is uncomfortable with it.
--
Regards,
Shawn
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
No support of platform device instance id?
Hello all, I'm looking at function of_device_alloc in drivers/of/platform.c, and surprisingly found that the platform device instance id is being hard-coded as -1 when calling platform_device_alloc. Does this mean that there is no support of pdev id in DT? If yes, can anyone please help me understand why we do not have something in DT node to reflect this id and get it supported? Or this is something on TODO list? I'm asking this because I feel we still need pdev id support in DT when reviewing the patch set of 'mx51 basic DT support'. -- Regards, Shawn ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
