Re: export kernel clock information to user space

[Arnd Bergmann]

On Wednesday 13 October 2010 08:49:42 Amit Kucheria wrote:
> That is something I've been wondering about too. At the moment, tools like
> powerdebug have to periodically re-read the entire clock tree to show
> updates. AFAIK, sysfs and debugfs don't support inotify/poll/select 
> mechanisms to
> notify changes.
> 
> It would be nice to have notification, but I don't know how hard that would
> be for a virtual filesystem.

Sysfs normally uses udev events to notify the user of changes. Not sure what
the mechanics behind this are, probably a netlink socket.

Supporting fanotify or inotify in your own file system should be very easy,
the somewhat harder part is to write the file system in the first place.

Arnd

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

Re: Login headless serial console

[Alexander Sack]

On Wed, Oct 13, 2010 at 8:10 AM, Amit Kucheria  wrote:
> On Wed, Oct 13, 2010 at 8:48 AM, Shawn Guo  wrote:
>> I'm trying to login mx51evk headless on serial console, and facing the
>> following problems.
>>
>> - No /etc/init/ttymxc0.conf in headless rootfs
>> - Do not know what username and passwd to login
>>
>> Should we get these addressed in headless build?  We do not expect
>> users to do extra manual works after l-m-c, right?
>
> Doesn't the --dev beagle option create a ttyS2.conf?

We don't create such a .conf there. in linaro-media-create we just set
the cmdline. On top, we have the magic upstart job in overlay package
that sets up a login console for whatever is in the cmdline. I
uploaded a potential fix for that as jammy said, so maybe try the
latest headless and see if thats better.

-- 

 - Alexander

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

Re: Cortex A9 vexpress MMC I/O problems.

[Dave Martin]

On Tue, Oct 12, 2010 at 11:31 AM, Scott Bambrough
 wrote:
> On Tue, 2010-10-12 at 11:17 +0100, Dave Martin wrote:
>> Sincle I believe this is a known issue with the hardware, it could be
>> wise to streamline the putting of bootloader and filesystem on
>> separate devices.

[...]

>> Is this feasible?
>
> This is what is being worked on ATM.
>
> Scott

Great :)

---Dave

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

Re: linaro-media-create speedup

[Dave Martin]

Hi,

On Tue, Oct 12, 2010 at 5:44 PM, Arnd Bergmann  wrote:
> On Tuesday 12 October 2010, Loïc Minier wrote:
[...]
>>  Right; ideally, we'd offset it so that it's still on a nice boundary
>>  e.g. we start at sector 512 (1, 8, 8)
>
> IIRC, Windows uses 1MB partition alignment these days. It's probably
> a good idea to do the same everywhere because SD card vendors might
> decide to "optimize" for the common case.

Could be... although the Beagle ROM seems to be very sensitive to the
precise layout.  We might find that the partition must start at sector
63 (but I'm not sure I understand the behaviour yet).

It's not the end of the world if the vfat partition is misaligned,
since this isn't accessed much, and written only occasionally.  If we
can have the rootfs partition aligned, that probably brings most of
the benefit.

[...]

>> > # --force is needed so that sfdisk accepts the non-cylinder aligned
>> > partition boundaries.
>
> I think --linux should allow you to do this as well without dropping all
> the safety nets.

Could be worth a try.

---Dave

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

Re: linaro-media-create speedup

[Arnd Bergmann]

On Wednesday 13 October 2010 09:53:17 Dave Martin wrote:
> Could be... although the Beagle ROM seems to be very sensitive to the
> precise layout.  We might find that the partition must start at sector
> 63 (but I'm not sure I understand the behaviour yet).

That would be a serious bug in the firmware, probably serious enough
that we could require updating.

> It's not the end of the world if the vfat partition is misaligned,
> since this isn't accessed much, and written only occasionally.  If we
> can have the rootfs partition aligned, that probably brings most of
> the benefit.

You can also manually align the FAT and the start of data to individual
sectors, which is how some SD cards do it when they use the 255/63
geometry.

Arnd

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

Re: Common ARM context save/restore code

[Amit Kucheria]

Jon,

Yes, the earlier the better to starting incorporating the changes in
Linux. Especially if you're interested in seeing this included in the
kernel in 6 months time.

/Amit


On Tue, Oct 12, 2010 at 3:57 PM, Jon Callan  wrote:
> Amit,
>
> Yes, it does seem a little tight doesn't it? Bobby is who I'm working with on 
> this, btw.
>
> Maybe I could get the source code tidied and open it up in 2-3 weeks time? 
> Then we can all work on it together :-)
>
> Jon.
>
> -Original Message-
> From: Amit Kucheria [mailto:amit.kuche...@linaro.org]
> Sent: 12 October 2010 13:32
> To: Jon Callan
> Cc: linaro-dev@lists.linaro.org
> Subject: Re: Common ARM context save/restore code
>
> :)
>
> As you can see, if you make the source available somewhere, there is plenty
> of people interested in dissecting it.
>
> Jon, if you start working on them in December, we'll almost certainly miss
> the 2.6.38 merge window to get it integrated to mainline.
>
> /Amit
> p.s. /me makes a note to talk to bo...@arm et al. regarding this.
>
> On 10 Oct 12, Jon Callan wrote:
>> Well, my plan was to... er... post a message on linaro-dev and see happened!
>>
>> And yes, refactor as an ARM-common driver + SoC-specific stubs, that sounds 
>> about right.
>>
>> I plan to work on the Linux integration from 1st December. I have done some 
>> Linux kernel work before but I'm a little rusty.
>>
>> Jon.
>>
>> -Original Message-
>> From: Amit Kucheria [mailto:amit.kuche...@linaro.org]
>> Sent: 12 October 2010 12:04
>> To: Jon Callan
>> Cc: linaro-dev@lists.linaro.org
>> Subject: Re: Common ARM context save/restore code
>>
>> Jon,
>>
>> I'm sure you anticipated this - What is your plan for pushing this out
>> to the kernel? :)
>>
>> And how can we help?
>>
>> On Tue, Oct 12, 2010 at 1:39 PM, Jon Callan  wrote:
>> > Vishwa,
>> >
>> > I have a more-or-less complete set of example code for CPU context 
>> > save/restore, currently supporting A5/A8/A9 and with planned support for 
>> > Eagle.
>> >
>> > It is structured as "firmware" at the moment, but it would be much better 
>> > if it was integrated into the ARM Linux kernel. The idea is the kernel 
>> > calls it from CPUidle, and it saves all CPU context and cuts the power. 
>> > Then when power returns, it restores all CPU context and returns to the 
>> > kernel as if nothing has happened.
>> >
>> > It handles just the CPU and cluster context, which on A9mpcore includes 
>> > MMU, GIC, VFP, SCU, L2cc, Debug, etc. It takes care of cleaning caches and 
>> > entering/leaving the coherency domain. There is also support for 
>> > TrustZone, but as you say that's quite platform-specific.
>> >
>> > So we would need to integrate this with the SoC-specific code somehow.
>>
>> So you need to refactor these to an ARM-common driver and SoC-specific stubs?
>>
>> /Amit
>>
>> -- IMPORTANT NOTICE: The contents of this email and any attachments are 
>> confidential and may also be privileged. If you are not the intended 
>> recipient, please notify the sender immediately and do not disclose the 
>> contents to any other person, use it for any purpose, or store or copy the 
>> information in any medium.  Thank you.
>
> -- IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium.  Thank you.
>

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

Re: Login headless serial console

[Shawn Guo]

On Wed, Oct 13, 2010 at 3:36 PM, Alexander Sack  wrote:
> We don't create such a .conf there. in linaro-media-create we just set
> the cmdline. On top, we have the magic upstart job in overlay package
> that sets up a login console for whatever is in the cmdline. I
> uploaded a potential fix for that as jammy said, so maybe try the
> latest headless and see if thats better.
>
I just tested today's headless image
linaro-m-headless-tar-20101013-0.tar.gz, and saw the fix is not there
yet. But the fix suggested by Jammy works fine for me, with no need of
ttymxc0.conf and login username and passwd.

Thanks all, and hope the fix will be in soon.

-- 
Regards,
Shawn

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

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

[Amit Kucheria]

Hi everyone,

The minutes of the weekly call can be found at:
https://wiki.linaro.org/WorkingGroups/PowerManagement/Meetings/2010-10-13

Attendees:
Linaro: Amit K, Vincent, Yong, Vishwa
ARM: Srinivas

Highlight: ARM common-code for cpu context save/restore

Regards,
Amit

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

Re: linaro-media-create speedup

[Loïc Minier]

On Wed, Oct 13, 2010, Arnd Bergmann wrote:
> You can also manually align the FAT and the start of data to individual
> sectors, which is how some SD cards do it when they use the 255/63
> geometry.

 Yup

 1 MiB is the value I use myself when creating partitions manually, but
 I didn't know Windows used this; sounds like a good idea to use that

 Let's go for 255/63 and a boot part starting at a 1 MiB: (130,138,8)

-- 
Loïc Minier

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

Re: [PATCHv2] cpufreq for freescale mx51

[Amit Kucheria]

Yong,

Some more comments. But the patch is looking good now.

On Fri, Oct 8, 2010 at 11:08 AM,   wrote:
> From: Yong Shen 
>
> it is tested on babbage 3.0

Change to

"Cpufreq driver for imx51. The operating points are currently tested
on babbage 3.0."

> Signed-off-by: Yong Shen 
> ---
>  arch/arm/Kconfig                       |    6 +
>  arch/arm/mach-mx5/Kconfig              |    1 +
>  arch/arm/mach-mx5/Makefile             |    1 +
>  arch/arm/mach-mx5/board-mx51_babbage.c |   12 ++-
>  arch/arm/mach-mx5/clock-mx51.c         |   24 
>  arch/arm/mach-mx5/cpu.c                |    2 +
>  arch/arm/mach-mx5/cpu_wp-mx51.c        |   42 ++
>  arch/arm/mach-mx5/cpu_wp-mx51.h        |   14 ++
>  arch/arm/plat-mxc/Makefile             |    2 +
>  arch/arm/plat-mxc/cpufreq.c            |  236 
> 
>  arch/arm/plat-mxc/include/mach/mxc.h   |   20 +++-
>  11 files changed, 358 insertions(+), 2 deletions(-)
>  create mode 100644 arch/arm/mach-mx5/cpu_wp-mx51.c
>  create mode 100644 arch/arm/mach-mx5/cpu_wp-mx51.h
>  create mode 100644 arch/arm/plat-mxc/cpufreq.c
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index d203b84..71a572a 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1690,6 +1690,12 @@ if ARCH_HAS_CPUFREQ
>
>  source "drivers/cpufreq/Kconfig"
>
> +config CPU_FREQ_IMX
> +       tristate "CPUfreq driver for i.MX CPUs"
> +       depends on ARCH_MXC && CPU_FREQ
> +       help
> +         This enables the CPUfreq driver for i.MX CPUs.
> +
>  config CPU_FREQ_SA1100
>        bool
>
> diff --git a/arch/arm/mach-mx5/Kconfig b/arch/arm/mach-mx5/Kconfig
> index 0848db5..7a621b4 100644
> --- a/arch/arm/mach-mx5/Kconfig
> +++ b/arch/arm/mach-mx5/Kconfig
> @@ -5,6 +5,7 @@ config ARCH_MX51
>        default y
>        select MXC_TZIC
>        select ARCH_MXC_IOMUX_V3
> +       select ARCH_HAS_CPUFREQ
>
>  comment "MX5 platforms:"
>
> diff --git a/arch/arm/mach-mx5/Makefile b/arch/arm/mach-mx5/Makefile
> index 86c66e7..e2af3fb 100644
> --- a/arch/arm/mach-mx5/Makefile
> +++ b/arch/arm/mach-mx5/Makefile
> @@ -5,6 +5,7 @@
>  # Object file lists.
>  obj-y   := cpu.o mm.o clock-mx51.o devices.o
>
> +obj-$(CONFIG_CPU_FREQ_IMX)    += cpu_wp-mx51.o

s/wp/op/ ?

Operating point is a more widely used word for frequency/voltage pairs
in the ARM world. We will also want to consider using the OPP library
currently being discussed elsewhere on LAKML. So change all instances
of working point or wp to operating point or op.

>  obj-$(CONFIG_MACH_MX51_BABBAGE) += board-mx51_babbage.o
>  obj-$(CONFIG_MACH_MX51_3DS) += board-mx51_3ds.o
>  obj-$(CONFIG_MACH_EUKREA_CPUIMX51) += board-cpuimx51.o
> diff --git a/arch/arm/mach-mx5/board-mx51_babbage.c 
> b/arch/arm/mach-mx5/board-mx51_babbage.c
> index 6e384d9..2d2a052 100644
> --- a/arch/arm/mach-mx5/board-mx51_babbage.c
> +++ b/arch/arm/mach-mx5/board-mx51_babbage.c
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright 2009 Freescale Semiconductor, Inc. All Rights Reserved.
> + * Copyright 2009-2010 Freescale Semiconductor, Inc. All Rights Reserved.
>  * Copyright (C) 2009-2010 Amit Kucheria 
>  *
>  * The code contained herein is licensed under the GNU General Public
> @@ -32,6 +32,7 @@
>  #include 
>
>  #include "devices.h"
> +#include "cpu_wp-mx51.h"
>
>  #define BABBAGE_USB_HUB_RESET  (0*32 + 7)      /* GPIO_1_7 */
>  #define BABBAGE_USBH1_STP      (0*32 + 27)     /* GPIO_1_27 */
> @@ -279,8 +280,17 @@ static struct sys_timer mxc_timer = {
>        .init   = mx51_babbage_timer_init,
>  };
>
> +static void __init fixup_mxc_board(struct machine_desc *desc, struct tag 
> *tags,
> +                                  char **cmdline, struct meminfo *mi)
> +{
> +#if defined(CONFIG_CPU_FREQ_IMX)
> +       get_cpu_wp = mx51_get_cpu_wp;

s/wp/op

> +#endif
> +}
> +
>  MACHINE_START(MX51_BABBAGE, "Freescale MX51 Babbage Board")
>        /* Maintainer: Amit Kucheria  */
> +       .fixup = fixup_mxc_board,
>        .phys_io = MX51_AIPS1_BASE_ADDR,
>        .io_pg_offst = ((MX51_AIPS1_BASE_ADDR_VIRT) >> 18) & 0xfffc,
>        .boot_params = PHYS_OFFSET + 0x100,
> diff --git a/arch/arm/mach-mx5/clock-mx51.c b/arch/arm/mach-mx5/clock-mx51.c
> index 6af69de..f23cfab 100644
> --- a/arch/arm/mach-mx5/clock-mx51.c
> +++ b/arch/arm/mach-mx5/clock-mx51.c
> @@ -39,6 +39,8 @@ static struct clk ahb_clk;
>  static struct clk ipg_clk;
>  static struct clk usboh3_clk;
>
> +DEFINE_SPINLOCK(clk_lock);
> +
>  #define MAX_DPLL_WAIT_TRIES    1000 /* 1000 * udelay(1) = 1ms */
>
>  static int _clk_ccgr_enable(struct clk *clk)
> @@ -342,6 +344,26 @@ static unsigned long clk_arm_get_rate(struct clk *clk)
>        return parent_rate / div;
>  }
>
> +static int _clk_cpu_set_rate(struct clk *clk, unsigned long rate)
> +{
> +       u32 reg, cpu_podf;
> +       unsigned long flags, parent_rate;
> +
> +       parent_rate = clk_get_rate(clk->parent);
> +       cpu_podf = parent_rate / rate - 1;
> +       /* use post divider to change freq */
> +       spin_lock_irqsave(&clk_lock, fla

Re: export kernel clock information to user space

[Yong Shen]

Thanks for your guys' brainstorm. I will take all the thoughts into account
while implementing this.

On Wed, Oct 13, 2010 at 2:49 PM, Amit Kucheria wrote:

> On 10 Oct 12, Arnd Bergmann wrote:
> > On Tuesday 12 October 2010, Amit Kucheria wrote:
> > > Adding linaro-dev to cc. Kernel consolidation WG might have comments.
> > >
> > > On Tue, Oct 12, 2010 at 9:04 AM, Yong Shen 
> wrote:
> > > > Hi Amit and Jeremy,
> > > >
> > > > This is not a patch review. But patch may better present my idea.
> Basically,
> > > > I want to add some code in common clock code to export clock
> information, so
> > > > every platform can benefit. This information is present in a
> tree-like
> > > > pattern.
> > > > Currently, each platform uses their own way to show clock info, which
> is
> > > > hard to use a common user space tool to collect information.
> > > > For this purpose, I need do the rest:
> > > > 1. Add a clock name check in the clkdev_add. We don't accept two
> clocks with
> > > > the same name to clkdev_add, do we? otherwise, it is impossible to
> create a
> > > > tree-like structure under file system, cause no same names under a
> > > > directory.
> > > > 2. Recursive function creates the clock tree in debugfs, which
> referred
> > > > omap's clock implementation.
> > > > 3. Add interface needed to let mach related drivers to report their
> > > > information. clk_get_rate is already there. Maybe we need
> clk_get_flags()
> > > > and clk_get_usecount() and more.
> > >
> > > Agreed, this functionality is necessary for common clk infrastructure
> > > to be useful.
> >
> > I like the idea, too.
> >
> > One question I immediately had was whether it should be integrated into
> > sysfs or remain standalone in debugfs.
> >
> > In general, no core functionality should require debugfs, so if we find
> > it important enough to write user level tools on top of this, it should
> > probably become a stable interface either in sysfs or its own "clkfs"
> > file system if necessary.
>
> That is something I've been wondering about too. At the moment, tools like
> powerdebug have to periodically re-read the entire clock tree to show
> updates. AFAIK, sysfs and debugfs don't support inotify/poll/select
> mechanisms to
> notify changes.
>
> It would be nice to have notification, but I don't know how hard that would
> be for a virtual filesystem.
>
> > The main disadvantage of sysfs is probably memory consumption, which will
> > have to be evaluated carefully: on systems with little RAM but many
> clocks
> > this might amount to a few percent of the system memory just to manage
> > the inodes.
> >
> > The main advantage of sysfs is that we can interface it with the device
> tree,
> > e.g. have a "clk" symlink in each device pointing to the entry in
> > the clock tree, and possibly vice versa.
>
> Agreed.
>
> /Amit
>
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: linaro-media-create speedup

[Dave Martin]

Hi,

On Wed, Oct 13, 2010 at 10:58 AM, Loïc Minier  wrote:
> On Wed, Oct 13, 2010, Arnd Bergmann wrote:
>> You can also manually align the FAT and the start of data to individual
>> sectors, which is how some SD cards do it when they use the 255/63
>> geometry.
>
>  Yup
>
>  1 MiB is the value I use myself when creating partitions manually, but
>  I didn't know Windows used this; sounds like a good idea to use that
>
>  Let's go for 255/63 and a boot part starting at a 1 MiB: (130,138,8)

As far as I can make out, the partition must be an exact number of
"cylinders", must have enough sectors for a FAT32 filesystem and must
start at sector 63.  This gives a minumum size is 5 cylinders (80262
sectors), which seems to work OK.
Anything else causes the ROM to print out the characters "60" and
halt, at least on my board.

Of course, if you follow TI's instructions for setting up the board,
you do get the right (if silly) layout.

Conversely, if the FAT partition doesn't start at sector 63, you get this:

Error: reading boot sector
u-boot.bin not found or blank nand contents - attempting serial boot . . .

...which suggests that the ROM is maybe making an assumption and
reading sector 63 regardless of what the partition table says.

Notwithstanding this, it looks like the rootfs partition can have any
configuration you like, so long as it doesn't overlap the FAT
partition.  This configuration worked for me, for example:
   Device Boot  Start End  Blocks   Id  System
/dev/sdg1   *  63   80324   40131c  W95 FAT32 (LBA)
/dev/sdg2   81920 7843839 3880960   83  Linux

So, unfortunately to avoid other people wasting a lot of time ... I
think the boot partition must start at sector 63, with size 63*(255*n
- 1) sectors, and minimum size 80262 sectors (n=5).  Perhaps there are
some (in)sanity checks and/or assumptions in the ROM which are
requiring this.  For the filesystem partition, I guess aligning up to
the next 1MB boundary is indeed the sensible thing to do (as in the
above example).

We should check it works with non-xM boards too...

Cheers
---Dave

___
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 10/11/2010 01:18 PM, John Rigby wrote:

git://git.linaro.org/ubuntu/linux-meta-linaro.git master


pushed 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: linaro-media-create speedup

[Loïc Minier]

On Wed, Oct 13, 2010, Dave Martin wrote:
> As far as I can make out, the partition must be an exact number of
> "cylinders", must have enough sectors for a FAT32 filesystem and must
> start at sector 63.  This gives a minumum size is 5 cylinders (80262
> sectors), which seems to work OK.
> Anything else causes the ROM to print out the characters "60" and
> halt, at least on my board.

 Is this the ROM or x-loader?

 What's your board again?  if beagle, are you pressing the user button?

-- 
Loïc Minier

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

Re: export kernel clock information to user space

[Vincent Guittot]

Hi,

Exporting the clock tree state is help us to monitor clocks state and
to find the guilty clocks. But could it be also possible to have a
write access to the clock tree ? During power consumption optimization
step, we need to identify clock/regulator which should be disable but
we also want to know what will be the gain. Instead of waiting for the
new code with the right clock management, we generally want to
directly disable it and look at the 1st result. It will be also useful
when we are looking for the best clock tree configuration without
developing/modifying a lot of source code.

For sure, such kind of feature is quite dangerous and must be enable
carefully but it would help for optimizing power consumption.

Vincent


On 13 October 2010 12:40, Yong Shen  wrote:
> Thanks for your guys' brainstorm. I will take all the thoughts into account
> while implementing this.
>
> On Wed, Oct 13, 2010 at 2:49 PM, Amit Kucheria 
> wrote:
>>
>> On 10 Oct 12, Arnd Bergmann wrote:
>> > On Tuesday 12 October 2010, Amit Kucheria wrote:
>> > > Adding linaro-dev to cc. Kernel consolidation WG might have comments.
>> > >
>> > > On Tue, Oct 12, 2010 at 9:04 AM, Yong Shen 
>> > > wrote:
>> > > > Hi Amit and Jeremy,
>> > > >
>> > > > This is not a patch review. But patch may better present my idea.
>> > > > Basically,
>> > > > I want to add some code in common clock code to export clock
>> > > > information, so
>> > > > every platform can benefit. This information is present in a
>> > > > tree-like
>> > > > pattern.
>> > > > Currently, each platform uses their own way to show clock info,
>> > > > which is
>> > > > hard to use a common user space tool to collect information.
>> > > > For this purpose, I need do the rest:
>> > > > 1. Add a clock name check in the clkdev_add. We don't accept two
>> > > > clocks with
>> > > > the same name to clkdev_add, do we? otherwise, it is impossible to
>> > > > create a
>> > > > tree-like structure under file system, cause no same names under a
>> > > > directory.
>> > > > 2. Recursive function creates the clock tree in debugfs, which
>> > > > referred
>> > > > omap's clock implementation.
>> > > > 3. Add interface needed to let mach related drivers to report their
>> > > > information. clk_get_rate is already there. Maybe we need
>> > > > clk_get_flags()
>> > > > and clk_get_usecount() and more.
>> > >
>> > > Agreed, this functionality is necessary for common clk infrastructure
>> > > to be useful.
>> >
>> > I like the idea, too.
>> >
>> > One question I immediately had was whether it should be integrated into
>> > sysfs or remain standalone in debugfs.
>> >
>> > In general, no core functionality should require debugfs, so if we find
>> > it important enough to write user level tools on top of this, it should
>> > probably become a stable interface either in sysfs or its own "clkfs"
>> > file system if necessary.
>>
>> That is something I've been wondering about too. At the moment, tools like
>> powerdebug have to periodically re-read the entire clock tree to show
>> updates. AFAIK, sysfs and debugfs don't support inotify/poll/select
>> mechanisms to
>> notify changes.
>>
>> It would be nice to have notification, but I don't know how hard that
>> would
>> be for a virtual filesystem.
>>
>> > The main disadvantage of sysfs is probably memory consumption, which
>> > will
>> > have to be evaluated carefully: on systems with little RAM but many
>> > clocks
>> > this might amount to a few percent of the system memory just to manage
>> > the inodes.
>> >
>> > The main advantage of sysfs is that we can interface it with the device
>> > tree,
>> > e.g. have a "clk" symlink in each device pointing to the entry in
>> > the clock tree, and possibly vice versa.
>>
>> Agreed.
>>
>> /Amit
>
>
> ___
> 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-media-create speedup

[Dave Martin]

Hi,

On Wed, Oct 13, 2010 at 2:32 PM, Dave Martin  wrote:
> On Wed, Oct 13, 2010 at 2:27 PM, Loïc Minier  wrote:
>> On Wed, Oct 13, 2010, Dave Martin wrote:
>>> As far as I can make out, the partition must be an exact number of
>>> "cylinders", must have enough sectors for a FAT32 filesystem and must
>>> start at sector 63.  This gives a minumum size is 5 cylinders (80262
>>> sectors), which seems to work OK.
>>> Anything else causes the ROM to print out the characters "60" and
>>> halt, at least on my board.
>>
>>  Is this the ROM or x-loader?
>
> No X-Loader banner (or anything else) is printed before the "60", so
> I'm assuming it's the ROM.
>
>>  What's your board again?  if beagle, are you pressing the user button?

Note, I've been playing with *xM* A2, not Beagle A2.

Is MLO the same thing as X-loader?

Interestingly, holding down the user button when there is no boot
sector at sector 63, causes just "60" to be printed out instead of the
X-loader banner and "empty boot sector" mesages.

Cheers
---Dave

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

Re: linaro-media-create speedup

[Robert Nelson]

On Wed, Oct 13, 2010 at 8:53 AM, Dave Martin  wrote:
> Hi,
>
> On Wed, Oct 13, 2010 at 2:32 PM, Dave Martin  wrote:
>> On Wed, Oct 13, 2010 at 2:27 PM, Loïc Minier  wrote:
>>> On Wed, Oct 13, 2010, Dave Martin wrote:
 As far as I can make out, the partition must be an exact number of
 "cylinders", must have enough sectors for a FAT32 filesystem and must
 start at sector 63.  This gives a minumum size is 5 cylinders (80262
 sectors), which seems to work OK.
 Anything else causes the ROM to print out the characters "60" and
 halt, at least on my board.
>>>
>>>  Is this the ROM or x-loader?
>>
>> No X-Loader banner (or anything else) is printed before the "60", so
>> I'm assuming it's the ROM.
>>
>>>  What's your board again?  if beagle, are you pressing the user button?
>
> Note, I've been playing with *xM* A2, not Beagle A2.
>
> Is MLO the same thing as X-loader?
>
> Interestingly, holding down the user button when there is no boot
> sector at sector 63, causes just "60" to be printed out instead of the
> X-loader banner and "empty boot sector" mesages.

On the "xM A2" holding down the user button just forces u-boot to use
'user.scr' vs 'boot.scr' it doesn't change anything related to the
bootrom/x-load sequence as mmc is default on those boards.

Regards,

-- 
Robert Nelson
http://www.rcn-ee.com/

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

Re: linaro-media-create speedup

[Dave Martin]

On Wed, Oct 13, 2010 at 2:58 PM, Robert Nelson  wrote:

[...]

>
> On the "xM A2" holding down the user button just forces u-boot to use
> 'user.scr' vs 'boot.scr' it doesn't change anything related to the
> bootrom/x-load sequence as mmc is default on those boards.

Interesting... I guess that's consistent with what I was seeing.  The
configuration I just described isn't identical to what I tried before,
so maybe the different message was caused by something else.

Cheers
---Dave

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

Re: linaro-media-create speedup

[Loïc Minier]

On Wed, Oct 13, 2010, Dave Martin wrote:
> Note, I've been playing with *xM* A2, not Beagle A2.

 ohhh, ok

> Is MLO the same thing as X-loader?

 Yes; MLO is the filename which the ROM uses to load the bootloader from
 MMC, and is usually x-loader

-- 
Loïc Minier

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

Re: export kernel clock information to user space

[Amit Kucheria]

On Wed, Oct 13, 2010 at 4:35 PM, Vincent Guittot
 wrote:
> Hi,
>
> Exporting the clock tree state is help us to monitor clocks state and
> to find the guilty clocks. But could it be also possible to have a
> write access to the clock tree ? During power consumption optimization

That is an interesting idea.

> step, we need to identify clock/regulator which should be disable but
> we also want to know what will be the gain. Instead of waiting for the
> new code with the right clock management, we generally want to
> directly disable it and look at the 1st result. It will be also useful
> when we are looking for the best clock tree configuration without
> developing/modifying a lot of source code.

Do you anticipate any other interface besides making the 'rate' sysfs
file RW and controlling the clock by writing various rates to the
file?

So,
0 - clock off
any other positive value - round down to the nearest valid rate

and writing to the file would lead to a call to clk.set_rate()

> For sure, such kind of feature is quite dangerous and must be enable
> carefully but it would help for optimizing power consumption.

I'm not sure that all clock frameworks are even ready for this feature
today, especially if they don't handle recalculation of child clock
rates as part of set_rate().

/Amit

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

Re: Dashboard API authentication issues

[Guilherme Salgado]

On Tue, 2010-10-12 at 20:36 +0200, Zygmunt Krynicki wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hi.
> 
> As you know we've been trying to deliver an authenticated interface for
> the dashboard for quite some time now without success. Recently we've
> decided to add oauth support to the current XML-RPC interface we have.
> 
> James implemented a rough support for this here [1] but it's not clear
> that we should accept this work yet. To quote James there are some
> issues with it today:
> 
> 1. This relies on an external project that is unpackaged at this time.
> 2. That external project ships a patched embedded copy of python-oauth,
> though I don't know what the patches are for.
> 3. That project requires consumers to be pre-registered, and I'm not
> sure we want that. It would be possible to work around it, but would
> require some work.
> 4. I'm not sure I have the Resource stuff correct in this branch.
> 5. I'm not convinced that I have thought through all the corners and so
> there may be security holes.
> 6. There is nothing so far for the view to know if the request is oauth,
> which consumer it is etc., and no support for differing token access
> levels. We won't need any of that right away, but if we want that then
> django-piston may be the way to go rather than adding all of that.
> 
> 
> All in all those issues make me think that it's not as easy as we
> assumed and we should pursue another path. Before we do that let's
> summarize our current needs and priorities:
> 
> 1) We need to allow users to authenticate before we allow them to upload
> test results (bundles) to certain directories (bundle streams) in a
> simple and efficient manner (client side code matters)
> 
> 2) Currently our only client is abrek
> 
> 3) We'd like to offer this very quickly, definitely before the UDS
> 
> 
> Having said that let's look at the options we have:
> 
> A) Continue hacking oauth in good faith that it'll work as intended
> without falling apart/being insecure/being hard to deploy/missing deadlines.
> 
> B) Fall back to one of the B-plans:
>  B1) use something other than oauth (like HTTP digest authentication)
>  B2) use something entirely different like:
>   B2.1) django-piston

django-piston is a library to generate/expose a RESTFul API out of
existing code, and it happens to have an OAuth implementation built in,
so I don't think we should use that just for its OAuth implementation.
And even if we decide to convert launch-control's API into a RESTFul
one, I'm not sure django-piston is the right tool for the job, for the
reason you mention below.

>   B2.2) lazr.restful

lazr.restful won't be of any help with supporting OAuth as it doesn't
have an implementation of that built in.

lazr.authentication, though, is used by other django projects in
Canonical to support OAuth.

> 
> B2.1 (piston) cannot directly replace our current API as it does not
> support named methods (it only has CREATE/READ/UPDATE/DELETE). The
> upsides are that is seems to support oauth out of the box. The downside
> is that it's not packaged (at least properly on lucid which we target).
> We'd also have to pick a client-side library to use (lazr.resful most
> likely but I'm not sure really). We're also not sure if they work
> together out of the box.
> 
> B2.2 (lazr-restful) might work but I don't know anything about it.
> 
> Some other points to consider:
> 1) Offspring nee lexbuilder also has an XML-RPC interface (cody, please
> correct me if I'm wrong) and we should align the technology if possible
> 2) We're not sure if we need full API but we're not sure that we don't

What do you mean by full API?

> need it either. Currently our _only_ requirement is to "allow people to
> submit test results" in whatever means necessary.
> 3) Having looked at various "web APIs" it seems that passing an API key
> is a common practice. While not as fancy as oauth perhaps we should
> consider this.

I think we can use existing libraries (python-oauth and
lazr.authentication) and follow the examples of Canonical django
projects that support OAuth, to support OAuth on launch-control.
However, given that the deadline is very close, the alternative you
propose above might be acceptable if the API is served over HTTPS.

> 
> Having said that I'd like to propose my opinion:
> 
> 1) Postpone oauth for UDS milestone (7 days left)
> 2) Work on alternative scheme that can be integrated with abrek easily
> in time for release
> 3) Continue on oauth path in a longer cycle (while retaining current
> interface).
> 
> Thanks
> ZK
> 
> [1]
> https://code.edge.launchpad.net/~james-w/launch-control/oauth/+merge/38013

-- 
Guilherme Salgado 


signature.asc
Description: This is a digitally signed message part
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: export kernel clock information to user space

[Vincent Guittot]

On 13 October 2010 16:14, Amit Kucheria  wrote:
> On Wed, Oct 13, 2010 at 4:35 PM, Vincent Guittot
>  wrote:
>> Hi,
>>
>> Exporting the clock tree state is help us to monitor clocks state and
>> to find the guilty clocks. But could it be also possible to have a
>> write access to the clock tree ? During power consumption optimization
>
> That is an interesting idea.
>
>> step, we need to identify clock/regulator which should be disable but
>> we also want to know what will be the gain. Instead of waiting for the
>> new code with the right clock management, we generally want to
>> directly disable it and look at the 1st result. It will be also useful
>> when we are looking for the best clock tree configuration without
>> developing/modifying a lot of source code.
>
> Do you anticipate any other interface besides making the 'rate' sysfs
> file RW and controlling the clock by writing various rates to the
> file?
>
> So,
> 0 - clock off
> any other positive value - round down to the nearest valid rate
>
> and writing to the file would lead to a call to clk.set_rate()
>

my idea is to export the clock interface through the debugfs for the
optimization phase. Then each machine implements and exports the
supported function.

>> For sure, such kind of feature is quite dangerous and must be enable
>> carefully but it would help for optimizing power consumption.
>
> I'm not sure that all clock frameworks are even ready for this feature
> today, especially if they don't handle recalculation of child clock
> rates as part of set_rate().
>
> /Amit
>

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

Quick test of images from a different build farm

[Paul Larson]

Hi, I have a request for some testing on a few images that have been
produced in a different build farm.  The goal of this testing is not really
to validate the images themselves, but to make sure that we aren't seeing
anything broken that looks like it was due to the new build environment.
One thing to note, is that the test images I have for this are from
20101006, so I don't expect to see significant differences from the weekly
testing on the 7th, last week.

For convenience, I set up a milestone on the Linaro QA Tracker [1] under the
heading "New build farm" to track the results of this testing.  I would
greatly appreciate if someone has a few spare cycles and can help by loading
a few of these images on the boards they have available, and give it a quick
try.

The images for testing are located at:
http://people.canonical.com/~plars/linaro/images/

Instructions for installing these images are the same as for the ones that
we've produced in the past.  For reference, those instructions are posted
at: http://wiki.linaro.org/Source/ImageInstallation.

Thanks,
Paul Larson

[1] http://qatracker.linaro.org/
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCHv2] cpufreq for freescale mx51

[Sascha Hauer]

On Fri, Oct 08, 2010 at 04:08:27PM +0800, yong.s...@linaro.org wrote:
> From: Yong Shen 
> 
> it is tested on babbage 3.0
> 
> Signed-off-by: Yong Shen 
> ---
>  arch/arm/Kconfig   |6 +
>  arch/arm/mach-mx5/Kconfig  |1 +
>  arch/arm/mach-mx5/Makefile |1 +
>  arch/arm/mach-mx5/board-mx51_babbage.c |   12 ++-
>  arch/arm/mach-mx5/clock-mx51.c |   24 
>  arch/arm/mach-mx5/cpu.c|2 +
>  arch/arm/mach-mx5/cpu_wp-mx51.c|   42 ++
>  arch/arm/mach-mx5/cpu_wp-mx51.h|   14 ++
>  arch/arm/plat-mxc/Makefile |2 +
>  arch/arm/plat-mxc/cpufreq.c|  236 
> 
>  arch/arm/plat-mxc/include/mach/mxc.h   |   20 +++-
>  11 files changed, 358 insertions(+), 2 deletions(-)
>  create mode 100644 arch/arm/mach-mx5/cpu_wp-mx51.c
>  create mode 100644 arch/arm/mach-mx5/cpu_wp-mx51.h
>  create mode 100644 arch/arm/plat-mxc/cpufreq.c
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index d203b84..71a572a 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1690,6 +1690,12 @@ if ARCH_HAS_CPUFREQ
>  
>  source "drivers/cpufreq/Kconfig"
>  
> +config CPU_FREQ_IMX
> + tristate "CPUfreq driver for i.MX CPUs"
> + depends on ARCH_MXC && CPU_FREQ
> + help
> +   This enables the CPUfreq driver for i.MX CPUs.
> +
>  config CPU_FREQ_SA1100
>   bool
>  
> diff --git a/arch/arm/mach-mx5/Kconfig b/arch/arm/mach-mx5/Kconfig
> index 0848db5..7a621b4 100644
> --- a/arch/arm/mach-mx5/Kconfig
> +++ b/arch/arm/mach-mx5/Kconfig
> @@ -5,6 +5,7 @@ config ARCH_MX51
>   default y
>   select MXC_TZIC
>   select ARCH_MXC_IOMUX_V3
> + select ARCH_HAS_CPUFREQ
>  
>  comment "MX5 platforms:"
>  
> diff --git a/arch/arm/mach-mx5/Makefile b/arch/arm/mach-mx5/Makefile
> index 86c66e7..e2af3fb 100644
> --- a/arch/arm/mach-mx5/Makefile
> +++ b/arch/arm/mach-mx5/Makefile
> @@ -5,6 +5,7 @@
>  # Object file lists.
>  obj-y   := cpu.o mm.o clock-mx51.o devices.o
>  
> +obj-$(CONFIG_CPU_FREQ_IMX)+= cpu_wp-mx51.o
>  obj-$(CONFIG_MACH_MX51_BABBAGE) += board-mx51_babbage.o
>  obj-$(CONFIG_MACH_MX51_3DS) += board-mx51_3ds.o
>  obj-$(CONFIG_MACH_EUKREA_CPUIMX51) += board-cpuimx51.o
> diff --git a/arch/arm/mach-mx5/board-mx51_babbage.c 
> b/arch/arm/mach-mx5/board-mx51_babbage.c
> index 6e384d9..2d2a052 100644
> --- a/arch/arm/mach-mx5/board-mx51_babbage.c
> +++ b/arch/arm/mach-mx5/board-mx51_babbage.c
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright 2009 Freescale Semiconductor, Inc. All Rights Reserved.
> + * Copyright 2009-2010 Freescale Semiconductor, Inc. All Rights Reserved.
>   * Copyright (C) 2009-2010 Amit Kucheria 
>   *
>   * The code contained herein is licensed under the GNU General Public
> @@ -32,6 +32,7 @@
>  #include 
>  
>  #include "devices.h"
> +#include "cpu_wp-mx51.h"
>  
>  #define BABBAGE_USB_HUB_RESET(0*32 + 7)  /* GPIO_1_7 */
>  #define BABBAGE_USBH1_STP(0*32 + 27) /* GPIO_1_27 */
> @@ -279,8 +280,17 @@ static struct sys_timer mxc_timer = {
>   .init   = mx51_babbage_timer_init,
>  };
>  
> +static void __init fixup_mxc_board(struct machine_desc *desc, struct tag 
> *tags,
> +char **cmdline, struct meminfo *mi)
> +{
> +#if defined(CONFIG_CPU_FREQ_IMX)
> + get_cpu_wp = mx51_get_cpu_wp;
> +#endif
> +}
> +
>  MACHINE_START(MX51_BABBAGE, "Freescale MX51 Babbage Board")
>   /* Maintainer: Amit Kucheria  */
> + .fixup = fixup_mxc_board,
>   .phys_io = MX51_AIPS1_BASE_ADDR,
>   .io_pg_offst = ((MX51_AIPS1_BASE_ADDR_VIRT) >> 18) & 0xfffc,
>   .boot_params = PHYS_OFFSET + 0x100,
> diff --git a/arch/arm/mach-mx5/clock-mx51.c b/arch/arm/mach-mx5/clock-mx51.c
> index 6af69de..f23cfab 100644
> --- a/arch/arm/mach-mx5/clock-mx51.c
> +++ b/arch/arm/mach-mx5/clock-mx51.c
> @@ -39,6 +39,8 @@ static struct clk ahb_clk;
>  static struct clk ipg_clk;
>  static struct clk usboh3_clk;
>  
> +DEFINE_SPINLOCK(clk_lock);

static, if needed at all.

> +
>  #define MAX_DPLL_WAIT_TRIES  1000 /* 1000 * udelay(1) = 1ms */
>  
>  static int _clk_ccgr_enable(struct clk *clk)
> @@ -342,6 +344,26 @@ static unsigned long clk_arm_get_rate(struct clk *clk)
>   return parent_rate / div;
>  }
>  
> +static int _clk_cpu_set_rate(struct clk *clk, unsigned long rate)
> +{
> + u32 reg, cpu_podf;
> + unsigned long flags, parent_rate;
> +
> + parent_rate = clk_get_rate(clk->parent);
> + cpu_podf = parent_rate / rate - 1;
> + /* use post divider to change freq */
> + spin_lock_irqsave(&clk_lock, flags);
> +
> + reg = __raw_readl(MXC_CCM_CACRR);
> + reg &= ~MXC_CCM_CACRR_ARM_PODF_MASK;
> + reg |= cpu_podf << MXC_CCM_CACRR_ARM_PODF_OFFSET;
> + __raw_writel(reg, MXC_CCM_CACRR);
> +
> + spin_unlock_irqrestore(&clk_lock, flags);

Why this spinlock? The whole clock code is protected by a mutex already.

> +
> + return 0;
> +}
> +
>  static int _clk_periph_apm_set_pare

Re: Problems with headless rootfs image lh build

[Michael Hudson]

On Wed, 13 Oct 2010 13:16:47 +0800, Shawn Guo  wrote:

> That's because I'm behind a proxy.  And the http_proxy setting in my
> shell does not work for sudo context. I have to do following to fix
> it.
> - sudo bash
> - export http_proxy=..
> - lh build

You can fix this by adding 'Defaults env_keep += "http_proxy"' to
/etc/sudoers btw.

Cheers,
mwh

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

Re: Dashboard API authentication issues

[Michael Hudson]

On Tue, 12 Oct 2010 20:36:26 +0200, Zygmunt Krynicki 
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hi.
> 
> As you know we've been trying to deliver an authenticated interface for
> the dashboard for quite some time now without success. Recently we've
> decided to add oauth support to the current XML-RPC interface we have.
> 
> James implemented a rough support for this here [1] but it's not clear
> that we should accept this work yet. To quote James there are some
> issues with it today:
> 
> 1. This relies on an external project that is unpackaged at this time.
> 2. That external project ships a patched embedded copy of python-oauth,
> though I don't know what the patches are for.
> 3. That project requires consumers to be pre-registered, and I'm not
> sure we want that. It would be possible to work around it, but would
> require some work.
> 4. I'm not sure I have the Resource stuff correct in this branch.
> 5. I'm not convinced that I have thought through all the corners and so
> there may be security holes.
> 6. There is nothing so far for the view to know if the request is oauth,
> which consumer it is etc., and no support for differing token access
> levels. We won't need any of that right away, but if we want that then
> django-piston may be the way to go rather than adding all of that.

It has to be said, I'm not sure the aesthetic appeal of oauth outweigh
these costs.  It smells a bit overengineered.

> All in all those issues make me think that it's not as easy as we
> assumed and we should pursue another path. Before we do that let's
> summarize our current needs and priorities:
> 
> 1) We need to allow users to authenticate before we allow them to upload
> test results (bundles) to certain directories (bundle streams) in a
> simple and efficient manner (client side code matters)

Is this all we want?  As salgado asked in another mail, where is this
API going?

> 2) Currently our only client is abrek

Is this going to change?

> 3) We'd like to offer this very quickly, definitely before the UDS

I don't think we should allow time pressures to force us into a bad
decision.  That said, I'm not sure the decision being made here is
necessarily that bad to get "wrong" at this stage.

> Having said that let's look at the options we have:
> 
> A) Continue hacking oauth in good faith that it'll work as intended
> without falling apart/being insecure/being hard to deploy/missing deadlines.

I think the tone of your voice suggests you don't like this plan :-)

> B) Fall back to one of the B-plans:
>  B1) use something other than oauth (like HTTP digest authentication)

This seems vaguely sane to me.

>  B2) use something entirely different like:
>   B2.1) django-piston
>   B2.2) lazr.restful
> 
> B2.1 (piston) cannot directly replace our current API as it does not
> support named methods (it only has CREATE/READ/UPDATE/DELETE). The
> upsides are that is seems to support oauth out of the box. The downside
> is that it's not packaged (at least properly on lucid which we target).
> We'd also have to pick a client-side library to use (lazr.resful most
> likely but I'm not sure really). We're also not sure if they work
> together out of the box.
> 
> B2.2 (lazr-restful) might work but I don't know anything about it.
> 
> Some other points to consider:
> 1) Offspring nee lexbuilder also has an XML-RPC interface (cody, please
> correct me if I'm wrong) and we should align the technology if
> possible

I don't really see the value in this, tbh.

> 2) We're not sure if we need full API but we're not sure that we don't
> need it either. Currently our _only_ requirement is to "allow people to
> submit test results" in whatever means necessary.

Right, so I think there is some value in keeping things simple until we
understand what our requirements are going to be.

> 3) Having looked at various "web APIs" it seems that passing an API key
> is a common practice. While not as fancy as oauth perhaps we should
> consider this.

This seems kinda ugly to me.  OAuth is the wait to get this approach
right, isn't it?

> Having said that I'd like to propose my opinion:
> 
> 1) Postpone oauth for UDS milestone (7 days left)
> 2) Work on alternative scheme that can be integrated with abrek easily
> in time for release
> 3) Continue on oauth path in a longer cycle (while retaining current
> interface).

Given that UDS is so soon, is there much value on working on it
furiously before UDS, where the real requirements might become clear?
Having authentication doesn't seem a requirement for doing demos at the
summit to me.

Cheers,
mwh

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

Re: Dashboard API authentication issues

[James Westby]

[ Apologies to anyone receiving this again, but I have had problems with
mail delivery and wanted to make sure that everyone got this ]

On Wed, 13 Oct 2010 12:35:54 -0300, Guilherme Salgado  
wrote:
> I think we can use existing libraries (python-oauth and
> lazr.authentication) and follow the examples of Canonical django
> projects that support OAuth, to support OAuth on launch-control.
> However, given that the deadline is very close, the alternative you
> propose above might be acceptable if the API is served over HTTPS.

lazr.authentication is fairly nice, but also fairly minimal. What is
missing from the combination of python-oauth and lazr.authentication is
the models for storing tokens etc. via the Django ORM.

We could extract those parts from canonical-identity-provider in to a
new app, which would be of use to everyone that wants to do this.

What I like about the lazr.authentication solution is that it integrates
with the Django auth system in that you just get a request.user that you
can check as you like. Plain django-oauth and django-piston don't seem
to have that, and I'd like to keep that separation of concerns if
possible.

I think that given that most of the code for the lazr.authentication
based solution already exists we could deliver something by Tuesday, but
we still don't have an answer to the question of external dependencies.

Zygmunt, have you discussed that question with Spike? Does anyone else
know what IS would prefer there?

Thanks,

James


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

Re: Problems with headless rootfs image lh build

[Shawn Guo]

On Thu, Oct 14, 2010 at 4:58 AM, Michael Hudson
 wrote:
> You can fix this by adding 'Defaults env_keep += "http_proxy"' to
> /etc/sudoers btw.
>
It works.  Thanks, Michael.

Hi Jamie,

I'm running into the following problem with latest headless lh config.
 Other repositories seem ok, and it only fails on maverick-proposed.

Err http://ports.ubuntu.com maverick-proposed/main armel Packages
  404  Not Found
Err http://ports.ubuntu.com maverick-proposed/universe armel Packages
  404  Not Found
W: Failed to fetch
http://ports.ubuntu.com/dists/dists/maverick-proposed/main/binary-armel/Packages.gz
 404  Not Found

W: Failed to fetch
http://ports.ubuntu.com/dists/dists/maverick-proposed/universe/binary-armel/Packages.gz
 404  Not Found

Any suggestion?  Thanks.

-- 
Regards,
Shawn

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

The summit and blueprints

[Michael Hope]

Hi there.  I'm confused about how we nominate and schedule things for
the upcoming summit.  I've got a bunch of tr-* TR blueprints and a
related set of engineering blueprints.  Some of these blueprints are
too big for one session and some need to be bundled up to fill up a
session.  No matter what, summit blueprints need the
other-linaro-n-foo naming convention to work.

What should I do?  My best guess is create other-linaro-n-foo
blueprints for scheduling's sake and add the TR and engineering
blueprints as dependencies.

BTW, I've written up my understanding of the workflow at:
 https://wiki.linaro.org/MichaelHope/Sandbox/SummitWorkflow

-- Michael

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

linaro-media-create bug fix for mx51evk

[Shawn Guo]

The l-m-c is broken for mx51evk due to the following two bugs.  I
posted the patches there.  Please review the patches and
pick them up if they are ok.

The bootcmd setting for mx51evk in l-m-c exceeds max args
https://bugs.launchpad.net/linaro-image-tools/+bug/659720

=== modified file 'linaro-media-create'
--- linaro-media-create 2010-10-12 15:31:29 +
+++ linaro-media-create 2010-10-14 01:29:29 +
@@ -361,7 +361,7 @@

 mx51evk)
   cat > ${TMP_DIR}/boot.cmd << BOOTCMD
-setenv bootcmd 'mmcinfo; mmc init; fatload mmc 0:2 $KERNEL_ADDR
uImage; fatload mmc 0:2 $INITRD_ADDR uInitrd; bootm $KERNEL_ADDR
$INITRD_ADDR'
+setenv bootcmd 'fatload mmc 0:2 $KERNEL_ADDR uImage; fatload mmc 0:2
$INITRD_ADDR uInitrd; bootm $KERNEL_ADDR $INITRD_ADDR'
 setenv bootargs '${serial_opts} ${splash_opts} ${lowmem_opt}
${boot_snippet} rootwait ro'
 boot
 BOOTCMD

imx51 hwpack: bootloader installed incorrectly and configured incorrectly
https://bugs.launchpad.net/linux-linaro/+bug/656962

=== modified file 'linaro-media-create'
--- linaro-media-create 2010-10-12 15:31:29 +
+++ linaro-media-create 2010-10-14 06:27:53 +
@@ -503,7 +503,7 @@
   ;;

 mx51evk)
- sudo dd if=binary/usr/lib/u-boot/mx51evk/u-boot.imx of=/dev/mmcblk0 \
+ sudo dd if=binary/usr/lib/u-boot/mx51evk/u-boot.imx of=${MMC} \
bs=1024 seek=1
   sudo mkimage -A arm -O linux -T kernel -C none -a 0x90008000 \
-e 0x90008000 -n Linux \

-- 
Regards,
Shawn

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

Re: linaro-media-create bug fix for mx51evk

[Wolfgang Denk]

Dear Shawn Guo,

In message  you 
wrote:
> The l-m-c is broken for mx51evk due to the following two bugs.  I
> posted the patches there.  Please review the patches and
> pick them up if they are ok.
> 
> The bootcmd setting for mx51evk in l-m-c exceeds max args
> https://bugs.launchpad.net/linaro-image-tools/+bug/659720
> 
> === modified file 'linaro-media-create'
> --- linaro-media-create 2010-10-12 15:31:29 +
> +++ linaro-media-create 2010-10-14 01:29:29 +
> @@ -361,7 +361,7 @@
> 
>  mx51evk)
>cat > ${TMP_DIR}/boot.cmd << BOOTCMD
> -setenv bootcmd 'mmcinfo; mmc init; fatload mmc 0:2 $KERNEL_ADDR
> uImage; fatload mmc 0:2 $INITRD_ADDR uInitrd; bootm $KERNEL_ADDR
> $INITRD_ADDR'
> +setenv bootcmd 'fatload mmc 0:2 $KERNEL_ADDR uImage; fatload mmc 0:2
> $INITRD_ADDR uInitrd; bootm $KERNEL_ADDR $INITRD_ADDR'
>  setenv bootargs '${serial_opts} ${splash_opts} ${lowmem_opt}
> ${boot_snippet} rootwait ro'
>  boot
>  BOOTCMD

Another trivial change is just to omit some of the redundant spaces in
the command line: s/; /;/g

i.e. change into

setenv bootcmd 'mmcinfo;mmc init;fatload mmc 0:2 
$KERNEL_ADDRuImage;fatload mmc 0:2 $INITRD_ADDR uInitrd;bootm $KERNEL_ADDR


The correct way to fix this is of course to submit a patch to U-Boot
to increase the CONFIG_MAX_ARGS option.


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
The price of curiosity is a terminal experience.
 - Terry Pratchett, _The Dark Side of the Sun_

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

Re: linaro-media-create bug fix for mx51evk

[Shawn Guo]

Thanks for the comment, Wolfgang.

Agreed that u-boot needs a patch to increase CONFIG_MAX_ARGS.  But my
point is that it's not necessary to put "mmcinfo; mmc init;" in the
command, as I explained like below on the bug page.  With that
removed, the current CONFIG_MAX_ARGS still fits.

Quote from https://bugs.launchpad.net/linaro-image-tools/+bug/659720:
Actually, we do not need to add anything before the first "fatload".
We set the bootcmd in boot.scr, and boot.scr itself is in mmc boot
partition. We have to get mmc ready before doing "fatload boot.scr" in
u-boot. In another word, when u-boot runs at the command in boot.scr,
the mmc must be already initialized.

As mx51evk u-boot implements the generic mmc than legacy one, "mmc
rescan 0" should be used to initialize mmc instead of "mmc init". See
details and patch for mx51evk default env on
https://bugs.launchpad.net/u-boot-linaro/+bug/655461

On Thu, Oct 14, 2010 at 12:36 PM, Wolfgang Denk  wrote:
> Dear Shawn Guo,
>
> In message  you 
> wrote:
>> The l-m-c is broken for mx51evk due to the following two bugs.  I
>> posted the patches there.  Please review the patches and
>> pick them up if they are ok.
>>
>> The bootcmd setting for mx51evk in l-m-c exceeds max args
>> https://bugs.launchpad.net/linaro-image-tools/+bug/659720
>>
>> === modified file 'linaro-media-create'
>> --- linaro-media-create 2010-10-12 15:31:29 +
>> +++ linaro-media-create 2010-10-14 01:29:29 +
>> @@ -361,7 +361,7 @@
>>
>>      mx51evk)
>>        cat > ${TMP_DIR}/boot.cmd << BOOTCMD
>> -setenv bootcmd 'mmcinfo; mmc init; fatload mmc 0:2 $KERNEL_ADDR
>> uImage; fatload mmc 0:2 $INITRD_ADDR uInitrd; bootm $KERNEL_ADDR
>> $INITRD_ADDR'
>> +setenv bootcmd 'fatload mmc 0:2 $KERNEL_ADDR uImage; fatload mmc 0:2
>> $INITRD_ADDR uInitrd; bootm $KERNEL_ADDR $INITRD_ADDR'
>>  setenv bootargs '${serial_opts} ${splash_opts} ${lowmem_opt}
>> ${boot_snippet} rootwait ro'
>>  boot
>>  BOOTCMD
>
> Another trivial change is just to omit some of the redundant spaces in
> the command line: s/; /;/g
>
> i.e. change into
>
>        setenv bootcmd 'mmcinfo;mmc init;fatload mmc 0:2 
> $KERNEL_ADDRuImage;fatload mmc 0:2 $INITRD_ADDR uInitrd;bootm $KERNEL_ADDR
>
>
> The correct way to fix this is of course to submit a patch to U-Boot
> to increase the CONFIG_MAX_ARGS option.
>
>
> 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
> The price of curiosity is a terminal experience.
>                         - Terry Pratchett, _The Dark Side of the Sun_
>



-- 
Regards,
Shawn

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