Hi all,
I would like to introduce myself to the group. I have recently received an IGEPv2 board [1], which is based on the Beagle Board, but with wifi, bluetooth, ethernet, and more RAM. I'm still at the "wow, it's tiny and it runs Linux" stage. I should get a bit more time over the next month and Christmas to play around properly with it.
I'm new to embedded development, but neither new to Linux nor ARM (writing my first ARM assembly some 15 years ago). However, for the past 6 years I've not even built a Linux kernel, preferring to use the default kernel in Fedora for simplicity :)
Firstly, a thank you to those involved in Fedora ARM for getting it to this stage. If I get the time, I'd really like to contribute some (probably small) effort to help get Fedora ARM working well on the IGEPv2 and Beagle Board. As I progress, I'd like to know what I can do to help.
In the meantime, I have some questions. Apologies in advance if these seem simple.
1) There are various different kernels from different sources. I'm used to there being a small set of "right" kernels (that is, Fedora's idea of "right") for x86. I fully appreciate that different ARM-based boards are quite different in capabilities (like different instruction set variants). a) Is there likely to be some standardised vanilla Fedora ARM kernel source? (Or is that simply the source RPM available for Fedora?) Then patches /could/ be offered for the more common systems (e.g. Beagle Board & clones, SheevaPlug). b) Would it then make sense to offer these as pre-built RPMs for common systems? c) Is there any guidance on which version is good to use as a base? I've seen quite different kernel versions being used (from 2.6.27 to 2.6.31).
2) I understand a little bit about the different calling conventions, FP differences (e.g. soft FPU versus VFP), and instruction set differences (v5 versus v7). a) Can the kernel can be safely built with a different instruction set targeted? (I know there are different optimisation options passed to GCC. Apologies if this seems a bit newbie-ish.) b) For FP-heavy programs (e.g. ogg encoding), is it possible to build the packages with VFP/NEON but still get them to work in a soft FPU system? I'd imagine any call to an external library would have to somehow be defined to use a different calling standard.
3) There seem to be some missing dependencies in the packages in the current Fedora ARM repository. For example, emacs is requiring libotf, which doesn't seem to be there in the repository. And likewise with the xorg-x11-font* packages needing ttmkdir. I'm confused as to how the RPM could have been successfully built without it. What am I missing?
4) I see there has been some discussion over unaligned data access. (Oh, I remember that from the ARM2 days.) It seems as if the Cortex-A8 cores allow unaligned data access when set up to do so [2]. Does this, in any way, help with the compatibility of packages targetting Cortex-A8?
5) I've managed to get various source packages missing from the Fedora ARM repositories to compile successfully (natively). I guess there is a reason why there are not in the repos right now -- is that reason down to time and priorities, or is there some blocking bugs with many of these packages?
I look forward to being able to contribute something back into Fedora!
Kind regards, Matthew
[1] http://www.igep-platform.com/index.php?option=com_content&view=article&a...
[2] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344j/Beihgif...
-----Original Message----- From: fedora-arm-bounces@redhat.com [mailto:fedora-arm- bounces@redhat.com] On Behalf Of Matthew Wilson
...snip...
In the meantime, I have some questions. Apologies in advance if these seem simple.
- There are various different kernels from different sources.
I'm used to there being a small set of "right" kernels (that is, Fedora's idea of "right") for x86. I fully appreciate that different ARM-based boards are quite different in capabilities (like different instruction set variants). a) Is there likely to be some standardised vanilla Fedora ARM kernel source? (Or is that simply the source RPM available for Fedora?) Then patches /could/ be offered for the more common systems (e.g. Beagle Board & clones, SheevaPlug).
Yes, you can pick up the kernel source rpm for Fedora and use that. Alternatively, you could just try the latest stable vanilla kernel.
b) Would it then make sense to offer these as pre-built RPMs for common systems?
I guess someone was looking into making this available. In the meanwhile, kernel images for commonly required boards are accessible from the Fedora-ARM wiki.
c) Is there any guidance on which version is good to use as a base? I've seen quite different kernel versions being used (from 2.6.27 to 2.6.31).
Treat the latest to be the greatest? :-)
- I understand a little bit about the different calling
conventions, FP differences (e.g. soft FPU versus VFP), and instruction set differences (v5 versus v7). a) Can the kernel can be safely built with a different instruction set targeted? (I know there are different optimisation options passed to GCC. Apologies if this seems a bit newbie-ish.) b) For FP-heavy programs (e.g. ogg encoding), is it possible to build the packages with VFP/NEON but still get them to work in a soft FPU system? I'd imagine any call to an external library would have to somehow be defined to use a different calling standard.
I am not entirely sure on this... Anyone?
- There seem to be some missing dependencies in the packages
in the current Fedora ARM repository. For example, emacs is requiring libotf, which doesn't seem to be there in the repository. And likewise with the xorg-x11-font* packages needing ttmkdir. I'm confused as to how the RPM could have been successfully built without it. What am I missing?
These rpms are now available on koji: http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=21323 http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=21322
This usually happens because we check for the repoclosure of a set of package groups. Packages beyond these may have dangling dependencies. These usually get addressed, during the mass build run (which will start in this week) or on-demand, like in this case.
- I see there has been some discussion over unaligned data
access. (Oh, I remember that from the ARM2 days.) It seems as if the Cortex-A8 cores allow unaligned data access when set up to do so [2]. Does this, in any way, help with the compatibility of packages targetting Cortex-A8?
You can fix alignment errors in the current versions as well by: # echo 2 > /proc/cpu/alignment
With hardware support it will be faster.
- I've managed to get various source packages missing from the
Fedora ARM repositories to compile successfully (natively). I guess there is a reason why there are not in the repos right now -- is that reason down to time and priorities, or is there some blocking bugs with many of these packages?
As you point out, it is about time and priorities. These will get addressed in the mass build run that will start this week. If you provide me with a list of packages I'll move them to the top of the list.
I look forward to being able to contribute something back into Fedora!
Great! You are welcome...
Kind regards, Matthew
Kedar.
[1] http://www.igep- platform.com/index.php?option=com_content&view=article&id=46&It emid=55
[2] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi 0344j/Beihgifg.html
On Fri, Nov 27, 2009 at 12:26:33AM -0800, Kedar Sovani wrote:
- I understand a little bit about the different calling
conventions, FP differences (e.g. soft FPU versus VFP), and instruction set differences (v5 versus v7). a) Can the kernel can be safely built with a different instruction set targeted? (I know there are different optimisation options passed to GCC. Apologies if this seems a bit newbie-ish.)
Yes, this is no problem -- you can run v4 applications on a v7 kernel just fine.
b) For FP-heavy programs (e.g. ogg encoding), is it possible to build the packages with VFP/NEON but still get them to work in a soft FPU system? I'd imagine any call to an external library would have to somehow be defined to use a different calling standard.
I am not entirely sure on this... Anyone?
The calling standard is actually compatible, so e.g. it's no problem to run an softfloat-compiled application with a library built for VFP and vice versa.
Matt,
I saw your posting on the fedora-arm mailing list.
I am doing some work for Ti, Freescale, and the folks who make the BeagleBoard, and I would like to get fedora on the BeagleBoard.
I was wondering if you made any progress? I am currently building for the arm5TE, but would be interested in any work an building fedora for an Arm7.
Regards.
Gregg
On Thu, Feb 4, 2010 at 12:31 PM, Gregg Lebovitz gregg@ics.com wrote:
Matt,
I saw your posting on the fedora-arm mailing list.
I am doing some work for Ti, Freescale, and the folks who make the BeagleBoard, and I would like to get fedora on the BeagleBoard.
I was wondering if you made any progress? I am currently building for the arm5TE, but would be interested in any work an building fedora for an Arm7.
Regards.
Hi Gregg,
I had started some initial work on this in the Fedora 10 days..
http://elinux.org/BeagleBoardFedora
The BeagleBoard works just fine with the current Fedora 12 arm root file systems.
I stopped due to problems getting mock/chroot to work correctly on the beagle (inexperienced fedora user), to generate proper armv7 optimized rpm's.. Then got busy working on ubuntu's arm distribution.
Regards,
Hi all,
Firstly, apologies for being so slow in replying. I had a flurry of activity over xmas with my IGEPv2, but since returning to work I've not been doing much with it. This is down to a lack of motivation on my part rather than having no time :(
Thank you for your replies.
I still have the medium-term goal to use it as a mini-server: simple things like local bookmark server (two laptops + desktop needing the same bookmarks), small fileserver (not masses of storage, but for sharing documents), print server, etc. I'd like to run it as a media player too (plugged into the TV) -- that's a longer-term goal.
The Fedora 12 root image and packages worked well. I had an issue that a lot of packages are missing. For example, to get cups running, I had to build a lot of packages. I hit some circular dependency issue too (can't recall the package OTTOMH -- maybe a LaTeX one?) but that only seemed to be needed for generating documentation in the package. It was usually a case of "yum install", collect missing deps, download source RPM, rpmbuild --rebuild, collect missing deps, etc.
(And using a microSD card for the rootfs was a mistake -- they are *so* slow at writing that doing any builds or package installs became painful. I now have a Samsung S1 mini -- low enough power that it doesn't need a powered hub.)
I am interested in ARMv7-optimised builds -- but, more crucially, getting updates from mainline Fedora pulled across. I have seen the list of patches applied for ARM and wonder what the strategy would be for applying those to the mainline packages.
I guess I ought to learn about koji if I'm *really* interested in building v7 packages... but the v5 ones work just fine for now.
[My remaining issue is about the kernel. ISEE (makers of the IGEPv2) now have a git repository (yay). Their kernel is based off of the linux-omap 2.6.28-10 branch. The linux-omap main branch is a bit too "bleeding edge" for me, but 28-10 is a little old.]
I have a few questions:
- What can be done to promote Fedora ARM? - Are the koji builds of Fedora updates being pushed into the Fedora ARM repository? - Is there sufficient interest in armv7 builds to add that as a support variant? - Can we collect experiences of usage of Fedora ARM (devices, purpose of use, problems, etc.)? - What can I do to help? - Would a step-by-step guide for IGEPv2 (BeagleBoard will be very similar) be useful?
And I shall make a concerted effort to be more active. :-)
Kind regards, Matthew
I have a few questions:
- What can be done to promote Fedora ARM?
some tutorials, videos, howtos talking about fedora-arm
- Are the koji builds of Fedora updates being pushed into the Fedora
ARM repository?
I think fedora-arm needs more guy's working on it to make it grow.
- Is there sufficient interest in armv7 builds to add that as a support variant?
no idea, I think dgilmore at fedoraproject.org can answer your question.
- Can we collect experiences of usage of Fedora ARM (devices, purpose
of use, problems, etc.)?
- What can I do to help?
I have talk with dgilmore some day ago, and we need more man-power to test some scripts and to put the things to work.
I need to take more care in buildsystem, automatic building packages for fedora-arm when the package is built for primary arch's
- Would a step-by-step guide for IGEPv2 (BeagleBoard will be very
similar) be useful?
I think so.
And I shall make a concerted effort to be more active. :-)
Kind regards, Matthew
On Thursday 04 February 2010 14:57:46 Matthew Wilson wrote:
- What can be done to promote Fedora ARM?
Make it run well on something cool.
- Is there sufficient interest in armv7 builds to add that as a support variant?
Yes! With NEON support and such. This would be nice for the Nokia N900. :)
- Can we collect experiences of usage of Fedora ARM (devices, purpose
of use, problems, etc.)?
It's just a start, but here's my mini-HOWTO about getting Fedora running on N900: http://wiki.maemo.org/User:Jebba/Fedora
- Would a step-by-step guide for IGEPv2 (BeagleBoard will be very
similar) be useful?
Perhaps it's there and I simply haven't tracked it down, but docs on how you build the rootfs.tar.gz would be nice.
Thanks!
-Jeff
Matthew Wilson píše v Čt 04. 02. 2010 v 21:57 +0000:
I have a few questions:
- What can be done to promote Fedora ARM?
show that it works on real hw
- Are the koji builds of Fedora updates being pushed into the Fedora
ARM repository?
AFAIK no, Fedora/ARM needs to start using koji-shadow
- Is there sufficient interest in armv7 builds to add that as a support variant?
the question is what needs to be built as armv7, maybe only few selected packages will profit from being built as armv7 - like it was in Intel world - only kernel+glibc+openssl were build as i686 while the rest was i386
- Can we collect experiences of usage of Fedora ARM (devices, purpose
of use, problems, etc.)?
I own 2 devices based on Marvell Kirkwood - QNAP TS-219 running as a server (file sharing/koji hub/...) and Sheevaplug as a development/testing environment.
I also have a Genesi Efika MX based on Freescale i.MX515 (armv7), but there is an issue that the kernel support is not yet in upstream.
The non-existency of kernel packages (together with means for their updating) is another issue that blocks wider adoption. The low level part (like flashing the kernel and ramdisk to flash memory) can be done with the flash-kernel utility from Debian, but it still needs an integration into grubby.
Dan
On 02/04/10 22:36, Somebody in the thread at some point said:
Matthew Wilson píše v Čt 04. 02. 2010 v 21:57 +0000:
I have a few questions:
- What can be done to promote Fedora ARM?
show that it works on real hw
FWIW I have been working for txtr e-book reader folks for 10 months, I have designed in Fedora as the rootfs for it. ARM Fedora works excellently. Really solves so many problems you would otherwise have getting any kind of quality from the rootfs, solid packaging, package availability by yum and so on.
The non-existency of kernel packages (together with means for their updating) is another issue that blocks wider adoption. The low level part (like flashing the kernel and ramdisk to flash memory) can be done with the flash-kernel utility from Debian, but it still needs an integration into grubby.
Fedora rootfs basis really really suits being on SD card not raw NAND if you can help it. With SD you can format the thing ext4 and it's very hard to tell you are not on a normal Fedora box.
I don't think lack of kernel packages is a problem, when someone targets a board with Fedora they will naturally make their own kernel package for the board.
The kernel package I made for txtr simply copies stuff to the name the bootloader expects in the /boot partition.
-Andy
On Thursday 04 February 2010 15:46:24 Andy Green wrote:
On 02/04/10 22:36, Somebody in the thread at some point said:
Matthew Wilson píše v Čt 04. 02. 2010 v 21:57 +0000:
I have a few questions:
- What can be done to promote Fedora ARM?
show that it works on real hw
FWIW I have been working for txtr e-book reader folks for 10 months, I have designed in Fedora as the rootfs for it. ARM Fedora works excellently. Really solves so many problems you would otherwise have getting any kind of quality from the rootfs, solid packaging, package availability by yum and so on.
Cool. Repos here: http://rpm.txtr.org/f11/txtr-a/
On this page: http://developer.txtr.com/SVN_Code_Repository it says to grab svn ala:
svn co https://developer.txtr.org/svn/ developer.txtr.org
But that isn't there and gives this error: svn: PROPFIND request failed on '/svn' svn: PROPFIND of '/svn': 302 Found (https://developer.txtr.org)
Thanks,
-Jeff
On 02/04/10 22:58, Somebody in the thread at some point said:
On Thursday 04 February 2010 15:46:24 Andy Green wrote:
On 02/04/10 22:36, Somebody in the thread at some point said:
Matthew Wilson píše v Čt 04. 02. 2010 v 21:57 +0000:
I have a few questions:
- What can be done to promote Fedora ARM?
show that it works on real hw
FWIW I have been working for txtr e-book reader folks for 10 months, I have designed in Fedora as the rootfs for it. ARM Fedora works excellently. Really solves so many problems you would otherwise have getting any kind of quality from the rootfs, solid packaging, package availability by yum and so on.
Cool. Repos here: http://rpm.txtr.org/f11/txtr-a/
On this page: http://developer.txtr.com/SVN_Code_Repository it says to grab svn ala:
svn co https://developer.txtr.org/svn/ developer.txtr.org
But that isn't there and gives this error: svn: PROPFIND request failed on '/svn' svn: PROPFIND of '/svn': 302 Found (https://developer.txtr.org)
It's outdated, we have private git for a bunch of packages that aren't released yet. This stuff isn't actually "out there" yet.
But you can get the kernel tree here (txtr-tracking branch)
http://git.warmcat.com/cgi-bin/cgit/txtr-kernel/log/?h=txtr-tracking
and the Qi bootloader (which boots directly from SD card -- the ROM actually pulls it in from SD) here
http://git.warmcat.com/cgi-bin/cgit/qi/log/?h=txtr
I'm planning to be at FOSDEM if anyone wants to get evangelized about the value of ARM Fedora with SD boot and see it in action please ping me :-)
-Andy
On Thursday 4 February 2010 19:31:09 Gregg Lebovitz wrote:
Matt,
I saw your posting on the fedora-arm mailing list.
I am doing some work for Ti, Freescale, and the folks who make the BeagleBoard, and I would like to get fedora on the BeagleBoard.
I was wondering if you made any progress? I am currently building for the arm5TE, but would be interested in any work an building fedora for an Arm7.
I have an IGEPv2 board too, and Fedora 12 seems to run well. I'm using a prebuilt kernel which I "stole" from the NAND, and the rootfs from Fedora wiki. I'd like to run a native kernel though. From the TODO in the wiki I see: - Add prebuilt kernel images for a number of popular ARM boards. Is there some automatic infrastructure to do that? I mean something like: * take latest Fedora kernel release source rpm * add machine specific patches * build various rpm (per-board) * expose them in a repository If there isn't such a thing yet, is anyone interested in setting it up? I have some spare bandwidth and diskspace on my VPS, and some spare time too. I don't know much of embedded development but probably enough to find the right patches around to build a working kernel.
I think that after the BeagleBoard & clones there is a new kind of Linux-ARM users which aren't really interested in embedded development, but just want a low power server/appliance/whatever without messing too much with the hardware.
On 14 February 2010 15:26, Stefano Cavallari stefano@cavallari.cjb.net wrote:
I have an IGEPv2 board too, and Fedora 12 seems to run well. I'm using a prebuilt kernel which I "stole" from the NAND, and the rootfs from Fedora wiki. I'd like to run a native kernel though.
I'm not sure which is better. The linux-omap branch (from which ISEE take their kernel) has lots more support for the OMAP hw. But, yes, I'd rather see something closer to mainline if possible.
If there isn't such a thing yet, is anyone interested in setting it up?
Yes, although I'm no expert.
I think the issue is getting a stable set of patches against the Fedora kernel for each supported board. I tried rebasing some of the ISEE changes against a 2.6.32 but failed to get something meaningful.
Perhaps we could chat off-list and work out a good set of patches for the IGEP?
I think that after the BeagleBoard & clones there is a new kind of Linux-ARM users which aren't really interested in embedded development, but just want a low power server/appliance/whatever without messing too much with the hardware.
Definitely! Someone commented, when I was running the Fedora GNOME desktop, "That's just like your PC!"
I was pleased to be able to buy the IGEPv2. There are lots of embedded dev boards available, but the dev kits often cost >1000 UKP.
I haven't had any time to spend on my board this week -- however, I'm still working on my howto guide. I'll email the list when I have something.
Regards, Matthew
On Sunday 14 February 2010 21:12:03 Matthew Wilson wrote:
On 14 February 2010 15:26, Stefano Cavallari stefano@cavallari.cjb.net
wrote:
I have an IGEPv2 board too, and Fedora 12 seems to run well. I'm using a prebuilt kernel which I "stole" from the NAND, and the rootfs from Fedora wiki. I'd like to run a native kernel though.
I'm not sure which is better. The linux-omap branch (from which ISEE take their kernel) has lots more support for the OMAP hw. But, yes, I'd rather see something closer to mainline if possible.
Maybe we can just apply relevant fedora patches to the omap branch. The important thing (IMHO) is to keep up with security updates and have a kernel config similar with the one of Fedora.
I think the issue is getting a stable set of patches against the Fedora kernel for each supported board. I tried rebasing some of the ISEE changes against a 2.6.32 but failed to get something meaningful.
Perhaps we could chat off-list and work out a good set of patches for the IGEP?
Good idea, I sent you a mail with my contacts.
With best compliments from
https://www.makingmove.com/ https://www.makingmove.com/packers-and-movers-ahmedabad https://www.makingmove.com/packers-and-movers-bangalore https://www.makingmove.com/packers-and-movers-chandigarh https://www.makingmove.com/packers-and-movers-chennai https://www.makingmove.com/packers-and-movers-cochin https://www.makingmove.com/packers-and-movers-hyderabad https://www.makingmove.com/packers-and-movers-new-delhi https://www.makingmove.com/packers-and-movers-kolkata https://www.makingmove.com/packers-and-movers-mumbai https://www.makingmove.com/packers-and-movers-pune https://www.makingmove.com/car-movers-motorcycle-carriers
-
Andy Green -
Dan Horák -
Gregg Lebovitz -
itamar -
jeff -
Kedar Sovani -
Lennert Buytenhek -
manish_d72＠yahoo.co.in -
Matthew Wilson -
Robert Nelson -
Stefano Cavallari