Hi,
I'm trying to put together an "introduction to Linux" training based on
Linaro and BeagleBoard/BeagleBoard-xM(as it becomes available) and want
to launch it in Feb/March 2011.
The hardware choice is due to the low price and because it's cool.
The distro choice it because I think that's the way to go for
contemporary ARM processors.
Your opinions might be biased, but what do you think about my choices?
Any suggestions?
Is linaro stable enough for it?
I'm playing around with https://wiki.linaro.org/Source/ImageInstallation
and daily snapshots.
Which git trees should be used to build from source
http://git.linaro.org/gitweb?
What's the preferred way to build/install additional packages?
Are there trees which utilize the multimedia features a bit more than
the headless stuff? (audio,video,...)
Regards,
Robert
--
Robert Berger
Embedded Software Specialist
Reliable Embedded Systems
Consulting Training Engineering
Tel.: (+30) 697 593 3428
Fax.:(+30) 210 684 7881
URL: http://www.reliableembeddedsystems.com
..."To be or not to be... that is the question." - The answer is 0xff
since: 0x2b | ~0x2b = 0xff
My public pgp key is available at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1
The item name is too long and bugs the choice list. The items in the
list are not displayed correctly.
This patch moves the list of supported system in the help instead of
the bool choice.
Signed-off-by: Daniel Lezcano <daniel.lezcano(a)free.fr>
---
arch/arm/Kconfig | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 47a9084..5a827b1 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -631,15 +631,17 @@ config ARCH_SA1100
Support for StrongARM 11x0 based boards.
config ARCH_S3C2410
- bool "Samsung S3C2410, S3C2412, S3C2413, S3C2416, S3C2440, S3C2442, S3C2443, S3C2450"
+ bool "Samsung S3C24xx"
select GENERIC_GPIO
select ARCH_HAS_CPUFREQ
select HAVE_CLK
select ARCH_USES_GETTIMEOFFSET
help
- Samsung S3C2410X CPU based systems, such as the Simtec Electronics
- BAST (<http://www.simtec.co.uk/products/EB110ITX/>), the IPAQ 1940 or
- the Samsung SMDK2410 development board (and derivatives).
+ Samsung S3C2410X CPU based systems (S3C2410, S3C2412, S3C2413,
+ S3C2416, S3C2440, S3C2442, S3C2443, S3C2450), such as the Simtec
+ Electronics BAST (<http://www.simtec.co.uk/products/EB110ITX/>),
+ the IPAQ 1940 or the Samsung SMDK2410 development board (and
+ derivatives).
Note, the S3C2416 and the S3C2450 are so close that they even share
the same SoC ID code. This means that there is no seperate machine
--
1.7.0.4
This is for powertop to run better on kernel. the first patch is back port from 8d4b9d1bf on 2.6.36.
They have been tested on freescale's babage 3.0 board.
Yong
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
>
Hi there. We all have the November release coming up. Even though
the different groups have different release cycles, it would be nice
to do a coordinated release in November that shows off the work we've
all been doing.
As part of that I want to make sure the toolchain outputs play well
together with the outputs from other groups. At least we need a QEMU
(toolchain), kernel, and test head (user platforms) that work well
together. A GDB and kernel combination with interrupted syscall and
hardware watchpoint support would be good as well. Benchmark numbers
up in the dashboard too.
Past that it would be nice to have a common 'Linaro' PPA where you can
get the latest of everything, including cross compilers, QEMU, and
similar on the host side, and also compilers, libraries, power
management tools, and similar on the device side. I know we have the
overlay PPA but it focuses on stability and is for the test head only.
Even past that it would be nice to have easy to consume examples as
well such as:
* A demo showing a cross compiled OpenGL app, run on a device due to
a good kernel, showing better numbers due to driver and compiler
improvements, and profiled using valgrind and oprofile
* A package with startup scripts, QEMU, kernel, and test head all ready to run
* The same but with the latest versions of all packages from all
groups already installed
* The same but installed as part of a Ubuntu Maverick VMWare image to
give a very low barrier to entry, and to let Windows users try things
out
I normally overdo these things so feel free to bring me back down to
earth. I'm going to at least talk with Loic and Alexander about the
QEMU/Kernel/Test head combo.
-- Michael
