Re: Single zImage and KVM
On Wed, 2012-03-07 at 06:42 +, Jon Medhurst (Tixy) wrote: > On Wed, 2012-03-07 at 08:23 +1300, Michael Hope wrote: > > On Wed, Mar 7, 2012 at 3:50 AM, Rob Herring wrote: > > > DT support for vexp A9 is going into 3.4 I believe. Pawel has been > > > working on it and can probably give details on A15 support. A single > > > kernel for these 2 platforms (and A7 as well) is much simpler than > > > getting to a single zImage in general (i.e. omap plus i.mx). But we'll > > > be a lot closer in 3.4. > > > > Linus 3.4 or the Landing Team 3.4? From other emails it seems that > > the work may be more on the packaging side. > > They should go in Linus 3.4 (though I can't find them in the arm-soc > branch). VExpress device trees _are_ in the arm-soc tree ready for 3.4... http://git.kernel.org/?p=linux/kernel/git/arm/arm-soc.git;a=commit;h=fdc24d4ba20499febb90ff17d3b75674026712f8 -- Tixy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Single zImage and KVM
On Wed, 2012-03-07 at 08:23 +1300, Michael Hope wrote: > On Wed, Mar 7, 2012 at 3:50 AM, Rob Herring wrote: > > DT support for vexp A9 is going into 3.4 I believe. Pawel has been > > working on it and can probably give details on A15 support. A single > > kernel for these 2 platforms (and A7 as well) is much simpler than > > getting to a single zImage in general (i.e. omap plus i.mx). But we'll > > be a lot closer in 3.4. > > Linus 3.4 or the Landing Team 3.4? From other emails it seems that > the work may be more on the packaging side. They should go in Linus 3.4 (though I can't find them in the arm-soc branch). The author's git repo is at: http://linux-arm.org/git?p=arm-dts.git;a=tree;h=refs/heads/master;hb=master The ARM Landing Team also have versions of these patches in their trees. > Where are the Device Trees hosted? Device trees for real hardware A5, A9 and A15 are in the same patches which submit device tree support. The above repo additionall has a device tree for RTSM. -- Tixy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro embedded Linux distro?
Hi Kevyn, On 03/06/2012 02:32 PM, Kevyn-Alexandre Paré wrote: > Hi, > > With some delay... > >> It is worth mentioning that you need a Debian/Ubuntu host >> (distribution supporting live-build). >> Anyway, if there's an audience for customizing Linaro Ubuntu images, >> we can provide tutorials. > > Will be interested in that! I will definitely try & test that tutorial. Besides the tutorial Fathi mentions in [3] below, I recently built a nano rootfs using this tutorial: https://wiki.linaro.org/Platform/DevPlatform/CrossCompile/LiveBuild Best regards, Matt > > thx, > > KA > >> >> [1] http://live.debian.net/manual/ >> [2] live-helper.config on https://code.launchpad.net/~linaro-maintainers >> [3] https://wiki.linaro.org/LiveHelper/Cross >> >> Cheers, >> -- >> Fathi Boudra >> Linaro Release Manager | Validation Project Manager >> Linaro.org | Open source software for ARM SoCs >> >> ___ >> 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: Linaro embedded Linux distro?
Hi, On 2012-02-20, at 2:55 PM, Wookey wrote: > +++ C.A, Subramaniam [2012-02-20 13:32 -0600]: >> On Mon, Feb 20, 2012 at 12:40 PM, Wookey wrote: >> Would there be a buildroot like setup? Like Wookey mentioned size does >> matter. > > No, if you want to use buildroot, use buildroot (or openbricks, or > yocto, or OE). Agreed > Debian/Ubuntu are binary distros and there is no mileage in > trying to occupy that space when other distros already do it well. But still Linaro offers Android stack that is in between or in another category... > > Making it relatively painless to rebuild or cross-rebuild your > package-set debian-style is a useful goal, but not supporting loads of > different package config options - that is something a source-based > distro can do so much better. > > We do plan to support minimal builds for bootstrapping purposes which > might be useful in this regard, but that's not really what it's for. k thanks for the clarification KA > > 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 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro embedded Linux distro?
Hi, On 2012-02-20, at 1:40 PM, Wookey wrote: > +++ Fathi Boudra [2012-02-20 09:34 -0800]: >> Hi >> >> On 20 February 2012 08:42, Zach Pfeffer wrote: >>> During ELC a few people asked me if Linaro had something bigger than >>> nano and smaller than Ubuntu that they could use to build stuff. Of >>> course I said Android, but a lot of people actually want a regular >>> Linux platform where they can easily recompile what they need to hack >>> on, add their own libs and scripts and generally work in an "embedded, >>> cross build way." > >> We provide 6 Ubuntu based images that we can consider as profiles. >> It's easy to customize or build your own image that will better fit >> your use case or requirements. >> >> In our case, we use live-build [1] which allow to put your >> customization on top of our images [2] or even from scratch. >> Tom has written a wiki page [3]. The page needs some update (I'm >> willing to help) to add upcoming armhf images and latest live-build >> with cross support. > > We should be clear what is meant by 'cross-support' in this context. > This is cross image-creation, not cross-building. If the > _cross-building_ part of this is important to punters then we don't > yet have a very good answer (not everything in the developer image > will crossbuild directly from the archive yet), although we are > getting there as multiarch, and sbuild-with-cross-support mature. > > But in general most people who think they want to cross-build > everything are wrong :-) In fact they really just want to cross-build > a few things that they build over and over, and getting most of the > system as binaries is just fine. I'm interested to hear of > counter-examples (the main one being complier improvements/options > which one wants to apply across the board). > > Another thing to note is that if the people asking for 'embedded > linaro linux' want smaller images we could run our packages through > the emdebian-grip tools to get smaller packages/images. (typically > 2/3rds size). I'm not sure anyone has got round to trying this, not > least because now everyone has SD-card based systems disk space mostly > stopped being an issue. no.. > People using 'proper flash' still care. yes! thx, KA > > 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 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro embedded Linux distro?
Hi, With some delay... On 2012-02-20, at 12:34 PM, Fathi Boudra wrote: > Hi > > On 20 February 2012 08:42, Zach Pfeffer wrote: >> During ELC a few people asked me if Linaro had something bigger than >> nano and smaller than Ubuntu that they could use to build stuff. Of >> course I said Android, but a lot of people actually want a regular >> Linux platform where they can easily recompile what they need to hack >> on, add their own libs and scripts and generally work in an "embedded, >> cross build way." I know there's OpenEmbedded and I've heard of >> something called "livebuild." Does anyone have anymore info? This >> class of users is arguably the largest class of people using these >> boards so creating something targeted at them would allow them to get >> all the benefits of Linaro in a easy to use fashion. > > We provide 6 Ubuntu based images that we can consider as profiles. > It's easy to customize or build your own image that will better fit > your use case or requirements. > > In our case, we use live-build [1] which allow to put your > customization on top of our images [2] or even from scratch. > Tom has written a wiki page [3]. The page needs some update (I'm > willing to help) to add upcoming armhf images and latest live-build > with cross support. > > It is worth mentioning that you need a Debian/Ubuntu host > (distribution supporting live-build). > Anyway, if there's an audience for customizing Linaro Ubuntu images, > we can provide tutorials. Will be interested in that! I will definitely try & test that tutorial. thx, KA > > [1] http://live.debian.net/manual/ > [2] live-helper.config on https://code.launchpad.net/~linaro-maintainers > [3] https://wiki.linaro.org/LiveHelper/Cross > > Cheers, > -- > Fathi Boudra > Linaro Release Manager | Validation Project Manager > Linaro.org | Open source software for ARM SoCs > > ___ > 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 v7 0/9] Consolidate cpuidle functionality
Robert Lee writes: > This patch series moves various functionality duplicated in platform > cpuidle drivers to the core cpuidle driver. Also, the platform irq > disabling was removed as it appears that all calls into > cpuidle_call_idle will have already called local_irq_disable(). Reviewed-by: Kevin Hilman ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] Makefile: Remove mmc_spl related enteries
Dear Chander Kashyap, In message <1320727394-3427-1-git-send-email-chander.kash...@linaro.org> you wrote: > As mmc_spl now follows spl infrastructure, removed unwanted > enteries in Makefile for mmc_spl related compilation. > > Signed-off-by: Chander Kashyap > --- > Makefile |8 > 1 files changed, 0 insertions(+), 8 deletions(-) Applied, thanks. [Typo fixed when committing]. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "IBM uses what I like to call the 'hole-in-the-ground technique' to destroy the competition. IBM digs a big HOLE in the ground and covers it with leaves. It then puts a big POT OF GOLD nearby. Then it gives the call, 'Hey, look at all this gold, get over here fast.' As soon as the competitor approaches the pot, he falls into the pit" - John C. Dvorak ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Single zImage and KVM
On 03/06/2012 01:23 PM, Michael Hope wrote: > On Wed, Mar 7, 2012 at 3:50 AM, Rob Herring wrote: >> On 03/04/2012 04:02 PM, Michael Hope wrote: >>> I'd like to have one KVM kernel image which is suitable for the real >>> hardware host and the virtio based guest. The single zImage plus >>> Device Tree work seem like a great way to do this. >>> >>> We're currently using the vexpress-a15 on a Fast Model as the host and >>> a vexpress-a15 as the guest. Device Tree support is required to >>> describe the virtio-mmio devices. As a bonus, the vexpress-a9 and >>> vexpress-a15 are the same hardware with a different memory map and can >>> help demonstrate the Device Tree support. >> >> Except LPAE and non-LPAE will be 2 different builds... At least you will >> be able to run the same non-LPAE kernel build on both. > > Hardware virtualisation requires LPAE and we're planning on LPAE in > the guest to match. Good, but both types of guests will be supported I presume. >>> What are the plans for single zImage? Where does the vexpress-a15 fit >>> in with that? Could I bump it to the front of the list? >> >> DT support for vexp A9 is going into 3.4 I believe. Pawel has been >> working on it and can probably give details on A15 support. A single >> kernel for these 2 platforms (and A7 as well) is much simpler than >> getting to a single zImage in general (i.e. omap plus i.mx). But we'll >> be a lot closer in 3.4. > > Linus 3.4 or the Landing Team 3.4? From other emails it seems that > the work may be more on the packaging side. Linus 3.4. I don't follow Linaro kernels, but sounds like support is already there in the kernel at least. > Where are the Device Trees hosted? Generally, in the kernel in arch/arm/boot/dts. Rob ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Single zImage and KVM
On Wed, Mar 7, 2012 at 3:50 AM, Rob Herring wrote: > On 03/04/2012 04:02 PM, Michael Hope wrote: >> I'd like to have one KVM kernel image which is suitable for the real >> hardware host and the virtio based guest. The single zImage plus >> Device Tree work seem like a great way to do this. >> >> We're currently using the vexpress-a15 on a Fast Model as the host and >> a vexpress-a15 as the guest. Device Tree support is required to >> describe the virtio-mmio devices. As a bonus, the vexpress-a9 and >> vexpress-a15 are the same hardware with a different memory map and can >> help demonstrate the Device Tree support. > > Except LPAE and non-LPAE will be 2 different builds... At least you will > be able to run the same non-LPAE kernel build on both. Hardware virtualisation requires LPAE and we're planning on LPAE in the guest to match. >> What are the plans for single zImage? Where does the vexpress-a15 fit >> in with that? Could I bump it to the front of the list? > > DT support for vexp A9 is going into 3.4 I believe. Pawel has been > working on it and can probably give details on A15 support. A single > kernel for these 2 platforms (and A7 as well) is much simpler than > getting to a single zImage in general (i.e. omap plus i.mx). But we'll > be a lot closer in 3.4. Linus 3.4 or the Landing Team 3.4? From other emails it seems that the work may be more on the packaging side. Where are the Device Trees hosted? -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v5 3/4] clk: introduce the common clock framework
On Mon, Mar 05, 2012 at 12:03:15PM -0800, Turquette, Mike wrote:
> On Sun, Mar 4, 2012 at 11:38 PM, Sascha Hauer wrote:
> > On Sun, Mar 04, 2012 at 04:12:21PM -0800, Turquette, Mike wrote:
> >> >>
> >> >> I believe this patch already does what you suggest, but I might be
> >> >> missing your point.
> >> >
> >> > In include/linux/clk-private.h you expose struct clk outside the core.
> >> > This has to be done to make static initializers possible. There is a big
> >> > warning in this file that it must not be included from files implementing
> >> > struct clk_ops. You can simply avoid this warning by declaring struct clk
> >> > with only a single member:
> >> >
> >> > include/linux/clk.h:
> >> >
> >> > struct clk {
> >> > struct clk_internal *internal;
> >> > };
> >> >
> >> > This way everybody knows struct clk (thus can embed it in their static
> >> > initializers), but doesn't know anything about the internal members. Now
> >> > in drivers/clk/clk.c you declare struct clk_internal exactly like struct
> >> > clk was declared before:
> >> >
> >> > struct clk_internal {
> >> > const char *name;
> >> > const struct clk_ops *ops;
> >> > struct clk_hw *hw;
> >> > struct clk *parent;
> >> > char **parent_names;
> >> > struct clk **parents;
> >> > u8 num_parents;
> >> > unsigned long rate;
> >> > unsigned long flags;
> >> > unsigned int enable_count;
> >> > unsigned int prepare_count;
> >> > struct hlist_head children;
> >> > struct hlist_node child_node;
> >> > unsigned int notifier_count;
> >> > #ifdef CONFIG_COMMON_CLK_DEBUG
> >> > struct dentry *dentry;
> >> > #endif
> >> > };
> >> >
> >> > An instance of struct clk_internal will be allocated in
> >> > __clk_init/clk_register. Now the private data stays completely inside
> >> > the core and noone can abuse it.
> >>
> >> Hi Sascha,
> >>
> >> I see the disconnect here. For OMAP (and possibly other platforms) at
> >> least some clock data is necessary during early boot, before the
> >> regular allocation methods are available (timers for instance).
> >
> > We had this problem on i.MX aswell. It turned out that the timer clock
> > is the only clock that is needed so early. We solved this by moving the
> > clock init to the system timer init function.
>
> When you say "mov[ed] the clock init to the system timer init
> function" do you mean that you statically allocated struct clk and
> used the clk framework api, or instead you just did some direct
> register writes to initialize things properly?
I meant that on i.MX we do the clock tree initialization when kmalloc is
available, see the attached patch for omap4 based on your branch which
does the same for Omap. The first clock you need is the one for the
timer, so you can initialize the clocktree at the beginning of
time_init() and don't need statically initialized clocks anymore.
> >
> > Well, the file is work in progress, you probably fix this before sending
> > it out, but I bet people will include clk-private.h and nobody else
> > notices it.
>
> clock44xx_data.c does not violate that rule. None of the logic that
> implements ops for those clocks is present clock44xx_data.c.
Indeed, I missed that. It only has the ops but not the individual
functions.
> All of
> the code in that file is simply initialization and registration of
> OMAP4 clocks. Many of the clocks are basic clock types (divider,
> multiplexer and fixed-rate are used in that file) with protected code
> drivers/clk/clk-*.c and the remaining clocks are of the struct
> clk_hw_omap variety, which has code spread across several files:
>
> arch/arm/mach-omap2/clock.c
> arch/arm/mach-omap2/clock.h
> arch/arm/mach-omap2/clkt_dpll.c
> arch/arm/mach-omap2/clkt_clksel.c
> arch/arm/mach-omap2/dpll3xxx.c
> arch/arm/mach-omap2/dpll4xxx.c
>
> All of the above files include linux/clk-provider.h, not
> linux/clk-private.h. That code makes heavy use of the
> __clk_get_whatever helpers and shows how a platform might honor the
> layer of separation between struct clk and stuct clk_ops/struct
> clk_foo. You are correct that the code is a work-in-progress, but
> there are no layering violations that I can see.
>
> I also think we are talking past each other to some degree. One point
> I would like to make (and maybe you already know this from code
> review) is that it is unnecessary to have pointers to your parent
> struct clk*'s when either initializing or registering your clocks. In
> fact the existing clk_register_foo functions don't even allow you to
> pass in parent pointers and rely wholly on string name matching. I
> just wanted to point that out in case it went unnoticed, as it is a
> new way of doing things from the previous series and was born out of
> Thomas' review o
Re: Single zImage and KVM
On Tue, 2012-03-06 at 08:50 -0600, Rob Herring wrote: > DT support for vexp A9 is going into 3.4 I believe. Pawel has been > working on it and can probably give details on A15 support. A single > kernel for these 2 platforms (and A7 as well) is much simpler than > getting to a single zImage in general (i.e. omap plus i.mx). But we'll > be a lot closer in 3.4. Linaro's Android release for VExpress as be using Pawel's device tree patches for several months to provide a single image which works on A9, A15 and A5 CoreTiles. We haven't do this yet for Ubuntu because hardware pack and media create tools don't yet support this. -- Tixy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Single zImage and KVM
On 03/04/2012 04:02 PM, Michael Hope wrote: > I'd like to have one KVM kernel image which is suitable for the real > hardware host and the virtio based guest. The single zImage plus > Device Tree work seem like a great way to do this. > > We're currently using the vexpress-a15 on a Fast Model as the host and > a vexpress-a15 as the guest. Device Tree support is required to > describe the virtio-mmio devices. As a bonus, the vexpress-a9 and > vexpress-a15 are the same hardware with a different memory map and can > help demonstrate the Device Tree support. Except LPAE and non-LPAE will be 2 different builds... At least you will be able to run the same non-LPAE kernel build on both. > > What are the plans for single zImage? Where does the vexpress-a15 fit > in with that? Could I bump it to the front of the list? DT support for vexp A9 is going into 3.4 I believe. Pawel has been working on it and can probably give details on A15 support. A single kernel for these 2 platforms (and A7 as well) is much simpler than getting to a single zImage in general (i.e. omap plus i.mx). But we'll be a lot closer in 3.4. Rob ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
