Hi all,
Scott asked me to take a look at the hwpack spec:
https://wiki.linaro.org/Platform/UserPlatforms/Specs/10.11/HardwarePacks
I took the liberty of editing it somewhat to make the definition of a
hardware pack clearer, and remove some contradiction in the
implementation suggestions.
I have some questions about the goals of the spec though:
1. Do we support installing more than one hardware pack on an image?
2. What is the purpose of the hwpack.deb that is mentioned in places?
3. Do we want to be able to pull in new versions of a hwpack on
request, or should it just be a case of updating the image, with a
hwpack-install call if you want to install a newer version that pulls
in new packages?
4. Do we want to support cross-installation in any way?
5. What are the use cases for tags? I can only see X/no X in the spec.
6. What are the use cases for support information?
There is also one larger question, which is that I disagree that we
shouldn't provide anything that will go in a hardware pack in the linaro
images. I think that having the images be useful by themselves has lots
of benefits.
- Being able to quickly spin up an image in QEMU makes for easier
testing.
- Requiring a hardware pack for every operation will make some things
more tedious.
- If everything in a hardware pack becomes more consolidated then
hardware packs probably become less useful.
Thanks,
James
[ resending with the correct address ]
On Fri, 27 Aug 2010 14:03:32 -0400, James Westby <james.westby(a)canonical.com> wrote:
> On Fri, 20 Aug 2010 16:26:46 -0400, James Westby <james.westby(a)linaro.org> wrote:
> > There is also one larger question, which is that I disagree that we
> > shouldn't provide anything that will go in a hardware pack in the linaro
> > images. I think that having the images be useful by themselves has lots
> > of benefits.
> >
> > - Being able to quickly spin up an image in QEMU makes for easier
> > testing.
> > - Requiring a hardware pack for every operation will make some things
> > more tedious.
> > - If everything in a hardware pack becomes more consolidated then
> > hardware packs probably become less useful.
> - Not having a flag day where suddenly our images aren't installable
> and hwpack-install has to work well, and before that date we can't
> test hwpack-install on the images we produce.
>
> Having not had anyone convince me that stripping our images is the right
> thing to do I have carried on attempting to write the spec without
> requiring this. There will be a few issues, such as ensuring that the
> kernel we want is the one that boots, but we have that problem on hwpack
> upgrades anyway, so it doesn't go away by stripping the images.
>
> I have
>
> https://wiki.linaro.org/Platform/UserPlatforms/Specs/10.11/HardwarePacks
>
> to a state where I am happy to start implementation now. Feedback on the
> spec is still welcome, and things will still be subject to change. In
> particular there are still a number of TODOs in the spec where I don't
> know how to proceed, but I believe that none of those block us starting
> implementation of other parts.
>
> Is the current status quo to create specs under the "linaro" project on
> Launchpad? I'll create a spec for this so that we can track work items
> for it.
>
> Thanks,
>
> James
>
The minutes of the weekly call can be found at:
https://wiki.linaro.org/WorkingGroups/PowerManagement/Meetings/2010-08-25
The minutes and actions are copied below.
Regards,
Amit
Attendees:
Linaro: Amit Kucheria, Amit Arora, Yong Shen
ARM: Robin Randhawa, Bobby Batacharia, Srinivas Kalaga
== Action Items from this Meeting ==
* ACTION: Yong to work with John Rigby and Ubuntu kernel team to make sure the Linaro kernel contains powertop kernel patches
* ACTION: Vishwa to verify powertop on 2.6.35
* ACTION: Vishwa to check with cpuidle/cpufreq experts in TI for verifying cpufreq behavior on multi-core OMAP
* ACTION: Amit A to get the powertop patch integrated into Linaro/Ubuntu packages
* ACTION: Yong to test common clk API patches on imx5 and help get it booting on babbage 3.0
== Action Items from Previous Meeting ==
* ACTIVE (Immediate):
* ACTION: Amit A to test on pm enabled OMAP3 board: DONE on 2.6.32 on zoom3 board
* New ACTION: Vishwa to verify on 2.6.35
* ACTION: Amit A to document details on power supply class (battery info) to PowerTOP internal wiki page: DONE
* ACTION: Yong to look into getting powertop kernel patches applied to Linaro kernel tree: Not DONE
* New ACTION: Yong to work with John Rigby and make sure the Linaro kernel contains it
* ACTION: Robin to send links to patches sent to linux-pm: DONE
* http://www.spinics.net/lists/cpufreq/msg01740.html
* It was a pointer to a discussion on having different governors on different cores
* ACTION: Amit K to spend some time on usecase to reproduce ondemand governor problems: POSTPONED
* ACTION: Yong to look at common clock FW, find out if debug info being exported (usage count, clk rate, dependencies): DONE
* DORMANT :
* ACTION: ARM to share internal instrumentation flow (BAB: we might also align with Linaro on workload discussions)
* Might take couple of months
* ACTION: Amit K to talk to jeremy about power domain framework: DONE
* Jeremy needs help, will revisit in a few weeks
* ACTION: Srinivas to provide details of where he believes userspace - kernel interaction is required. (low prio)
* ACTION: Bobby to check on multi-core boards availability (request open)
* ACTION: ARM to discuss giving out internal Eclipse based tool (similar to powertop) (no ETA as of now)
* ACTION: Amit Kucheria and Vishwa to get inputs from community on the issues related to CPUIDLE governor: POSTPONED until instrumentation work
== Minutes ==
* Discussion on http://www.spinics.net/lists/cpufreq/msg01740.html
* For ARM, both cores run at same frequency (CMP)
* Does it make sense for them to run different governors on each core?
* The consensus currently is NO
* TI uses ondemand governor + policy manager
* One core is kept OFF, all processing happens on the other one.
* If load on one core goes above a threshold, they turn ON other core
* Both cores run at same Operating Point once ON
* Debug info in common clk API being discussed upstream by Jeremy
* There is currently no debug info
* clock name is not part of the common struct clk to keep size down
* Need to engage with Jeremy
* Yong will test the patches from Jeremy on imx5 and report back
* Powerdebug: should we visualise the clock and power dependencies using information from /sys or debugfs?
* No immediate horror expressed at the idea
* Freescale and TI already do it to a certain extent by dumping the clock tree and rates into a table
* The entire tree is too complex to depict
* We could represent it in parts e.g. start at a peripheral and plot it's clock and power dependencies all the way up
Hi there. We've been having a discussion in the Toolchain WG
regarding Thumb-1 improvements. I want to decline doing them as I've
assumed that Linaro is focused on the Cortex-A series, but I can't
find that written down anywhere.
May I limit the Toolchain WG to currently or nearly shipping Cortex-A
implementations? This means:
* Cortex-A profile only
* ARMv7 only
* ARM and Thumb-2 instruction sets
* With or without NEON
* With either VFPv3 D16 or D32
* With or without SMP
We will try to do no harm to other architectures or earlier ARM
versions. The Thumb-2 routines may be applicable to the Cortex-M and
Cortex-R series but we will not optimise for them.
I'd like Linaro to state this explicitly in the next round.
https://wiki.linaro.org/Linaro1011/TechnicalRequirements defines a
'Standard ARMv7 Configuration' but there's no higher level statement
justifying it, no statement restricting us to it, and it includes ARM,
Thumb-2, and Thumb-1.
-- Michael
Amit, Bryan:
Do you know what the correct setting for CONFIG_NEON is for MX51? In
a discussion on IRC there was mention that there is a patch that makes
it safe to turn on. Do you know if that patch has made it upstream?
Thanks,
John
Hi
First some informations. "armel-cross-toolchain" is a package which will
generate armel cross toolchain for x86(-64) machines (but nothing keeps
from building powerpc->armel one etc). Do to that I am building several
stages of linux/eglibc/gcc-4.5/binutils in proper order. This is called
'bootstrap' way of building cross compiler and can be automated (which
can not be done with Embedian way which we used before).
In last week I did a split of package into 2 steps:
- armel-cross-toolchain-base
- armel-cross-toolchain
Where first one provides binutils, linux headers, libc6 and libgcc
packages. Second provides final gcc.
My armel-cross-toolchain-base package got to the moment when it builds
out of box on Ubuntu maverick.
But build != upload ;( And here I need some help.
As you can see on page [1] package got built [2] but then was rejected to
be uploaded [3]. Here my Debian/Ubuntu packaging skills ends as I never
imported any package to those systems.
According to people from #launchpad my package is buggy as it is producing
a binutils binary which expects to be built from a binutils source. Whereas
mine source package is neither named binutils nor does it have that version.
So problem is how to get it done... So far I tried ugly hacks like:
sed -i -e "s/^binutils/armel-cross-toolchain-base/g" debian/changelog; \
sed -i -e "s/^Source: binutils/Source: armel-cross-toolchain-base/g" debian/control.in; \
sed -i -e "s/^Source: binutils/Source: armel-cross-toolchain-base/g" debian/control; \
But this does not look right for me and require more changes in linux
packaging as it uses changelog name as base for package names.
So help me please if you have ideas.
1. https://edge.launchpad.net/~hrw/+archive/arm-cross-compiler/+build/1940050
2. http://launchpadlibrarian.net/54624642/buildlog_ubuntu-maverick-i386.armel-…
3. http://launchpadlibrarian.net/54624644/upload_1942031_log.txt
Regards,
--
JID: hrw(a)jabber.org
Website: http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz
I am trying to map the nor flash on the Versatile Express platform
to an mtd partition. I have tried a bunch of variations with the
kernel command line "mtdparts" directive, without success.
Here is the last one I tried:
mtdparts=armflash-1.0:1M(uboot),9M(linux),16M(uInitrd)
The kernel seems to detect the flash parts correctly:
...
armflash-0: Found 2 x16 devices at 0x0 in 32-bit bank
Intel/Sharp Extended Query Table at 0x010A
Intel/Sharp Extended Query Table at 0x010A
Intel/Sharp Extended Query Table at 0x010A
Intel/Sharp Extended Query Table at 0x010A
Intel/Sharp Extended Query Table at 0x010A
Using buffer write method
Using auto-unlock on power-up/resume
cfi_cmdset_0001: Erase suspend on write enabled
armflash-1: Found 2 x16 devices at 0x0 in 32-bit bank
Intel/Sharp Extended Query Table at 0x010A
Intel/Sharp Extended Query Table at 0x010A
Intel/Sharp Extended Query Table at 0x010A
Intel/Sharp Extended Query Table at 0x010A
Intel/Sharp Extended Query Table at 0x010A
Using buffer write method
Using auto-unlock on power-up/resume
cfi_cmdset_0001: Erase suspend on write enabled
Concatenating MTD devices:
(0): "armflash-0"
(1): "armflash-1"
into device "armflash"
RedBoot partition parsing not available
...
$ cat /proc/mtd
dev: size erasesize name
<nothing listed>
Any ideas?
Thanks,
Matt
Hi,
According to the schedule [1], the Beta release [2] is due in two days. The release team have selected
a beta candidate and would like your helping in testing the images to ensure that they are of Beta
quality. If you have the hardware available, currently OMAP Beagleboard and ARM Versatile Express
(ca9x4_ct_vxp) then you could help. The steps involved in testing are:
1) Download the correct image for your board, OMAP [3] or Versatile Express [4].
2) Install the image on your device (instructions can be found on the Beta release page [2]).
3) Log in or create an account at http://qatracker.linaro.org.
4) Test according to the test cases for your board by following the instructions on qatracker.
5) Submit your results to qatracker, file bugs, come joins us on the irc channel [5] to ask questions.
Hopefully with your help, we can make the Beta release rock.
Regards,
Jamie.
--
Linaro Release Manager
[1] http://wiki.linaro.org/Releases/1011#Linaro10.11Schedule
[2] http://wiki.linaro.org/Releases/1011/Beta
[3] OMAP - http://snapshots.linaro.org/10.11-daily/linaro-headless/20100831/1/images/t…
[4] Versatile Express - http://snapshots.linaro.org/10.11-daily/linaro-headless-vexpress/20100831/2…
[5] #linaro on irc.freenode.net
Hello,
I'm looking for some advice on the feasibility of using Linaro on one of
my projects based on an AT91SAM9260 Atmel processor, which has an
ARM926EJ-S ARMv5 processor core.
I see that the Linaro builds do not support v5 and I wonder, what would
be involved in "recompiling" Linaro with v5 support? Is there anyone
else looking at this possibility? Any suggestions?
Thanks,
--
Pedro
