Fedora ARM 12 on IGEPv2 (Beagle Board clone)
by Matthew Wilson
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&id...
[2] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344j/Beih...
7 years, 8 months
Re: [fedora-arm] Guruplug | uaputl fail
by Martin Stadtler
Mine is on order, with specific intent to use the WLAN so this thread has my full attention. More than happy to pitch in once mine comes in.
Martin Stadtler
Red Hat Inc.
240.813.0122
-----Original Message-----
From: Bernhard Schuster [schuster.bernhard(a)googlemail.com]
Received: 8/19/10 1:07 PM
To: Jon Hermansen [jon.hermansen(a)gmail.com]
CC: Fedora ARM secondary architecture list [arm(a)lists.fedoraproject.org]
Subject: Re: [fedora-arm] Guruplug | uaputl fail
Other question, did any one else ever try toget wlan workin on GuruPlug
Server? Success? fail?
Regards
Bernhard
12 years, 10 months
SheevaPlug donation, where to send?
by Adam Miller
Hello all,
I purchased a SheevaPlug because I was planning to use it for a
masters thesis about embedded computing but I honestly never even got
around to pulling it out of the box before my topic of focus changed
so I would like to donate it to the koji-arm effort and I wanted to
know who/where I should send it to.
Many thanks,
-AdamM
--
http://maxamillion.googlepages.com
---------------------------------------------------------
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
13 years
Re: [fedora-arm] bad link on http://fedoraproject.org/wiki/Architectures/ARM page
by Till Maas
On Thu, Aug 19, 2010 at 02:15:06PM -0400, Paul W. Frields wrote:
> On Sun, Aug 15, 2010 at 12:54:47PM -0700, rihoward1(a)gmail.com wrote:
> > If you go to http://fedoraproject.org/wiki/Architectures/ARM and then scroll down to
> >
> > Latest Release: Fedora 12
> >
> > The following is available for F12:
> >
> > A set of patches necessary to make Fedora packages build for ARM.
> > A set of source RPMs from the base F12 repository which also includes packages that have been modified to build for ARM. (still being rsyned...).
> >
> >
> > If you then click on the base F12 repository link it goes to http://fedora-arm.wantstofly.org/pub/fedora/linux/releases/12/Everything/... and this results in a 404.
>
> Fixed:
> https://fedoraproject.org/w/index.php?title=Architectures%2FARM&diff=1933...
Actually this is not a proper fix, because the linked SRPMS contained ARM
specific patches, that are probably now gone. I updated the wiki to reflect
this. Unluckily most of the ARM SIG communication happens in the IRC or private
channels, therefore I do not really know what is going on. But the RPMs were
generated by a previous setup of the SIG. I CC'ed the ARM list, so someone with
more knowledge can update this even better.
Regards
Till
13 years, 1 month
Guruplug | uaputl fail
by Bernhard Schuster
Has anyone stumbled upon uaputl failing to bss_start? Everything else works
as it seems.
[root@fedora-arm home]# uaputl sys_cfg_radio_ctl 0
Radio setting successful
[root@fedora-arm home]# uaputl sys_cfg_channel 5
Channel setting successful
[root@fedora-arm home]# uaputl sys_cfg_ssid "dummyssid"
SSID setting successful
[root@fedora-arm home]# uaputl sys_cfg_protocol 32
protocol setting successful
[root@fedora-arm home]# uaputl sys_cfg_cipher 8 8
cipher setting successful
[root@fedora-arm home]# uaputl sys_cfg_wpa_passphrase "dummypasswd"
WPA passphrase setting successful
[root@fedora-arm home]# uaputl bss_start
ERR:UAP_BSS_CTRL fail, result=0
ERR:Could not start BSS!
ifconfig uap0
Link encap:Ethernet HWaddr 00:24:23:1F:B1:7B
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Some uaputl <option> give ERR: not supported "blah".
any ideas?
Note: I compiled a patched kernel (based on vanilla 2.6.34.1) with full
support for libertas_uap, kopied the mrvl firmware folder from the debian
rootfs over to my SDHC card, copied uaputl from the debian rootfs, did
modules_install firmware_install header_install and blacklisted libertas and
libertas_sdio to prevent them hogging the hardware before libertas_uap comes
onto the playfield.
Help is very much appreaciate. If required I can "send"(torrent or alike)
the full image (~15GiB), the KernelBuild env, uImage and modules.
Thanks for any help or tipps
Regards
Bernhard
13 years, 1 month
Fedora 13 status
by Lorenzo Villani
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi,
what's the status with Fedora 13 ARM builds? Since I have a Sheevaplug
with Fedora 12 installed on it, I'm interested in getting F-13 working
as a server ASAP (though I am not really interested in the graphical stuff).
However, I don't know ARM architecture internals and this will probably
limit the extent of my contributions.
If there's something I can do with my limited skills and knowledge just
tell me.
Regards,
Lorenzo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iQIcBAEBCgAGBQJMXn6kAAoJENiW/JDIQberN1MQAJFxz8AP2Nenpnmkcukrflbb
P9EAVLC5hjrZDNCVb8hBXBGU+6yG6N+IbEBNOOwASCCpqk8moasOjiybRXUB4cbc
gD+Dx2Z9WcYxfftz3Tnc29p2J2YvyOZg28gWJfIIM2jQ+57fs4GfzRLor8Dw6nQa
pSAzY/WcqJ1RLJskYRTW1SEOYACK0B3Ut2m+ociTL9I8agqyx3uEgkGfEl1d5NiK
+0nC2U2Vl+josC1KBa7Uy6x7yCyyPmLZaXJNDwWSVoq1wRJYmrFhKB99RrLNgsLF
/2zHbZD/5Zj8U23NvA9+OAM/HrM5JkLQEcKkS+owZ3EOLLcpDJsfthaP5EDkoGLj
qX0IqUxzXh3AYdEW/U0TNdgfsVeivL4+CoivHIFODDfoAYk6n0Byma5RcMdXHNd8
egeN+ecCRITDG3yd9lOjyHxLRXiWsGCHByNDdlyzF22BeGwg+0B0fQnAL+mqd4Us
mfZykwsF8ULo4KfMr7/odKmERXiT70lZuQCdXJVkr5hxoQ5wBQz8GReNGEUoANTr
ONPE/CCif/OiTKefA6d1AoD8dGEDaUvbsiTETtbMuazDuHZ8J+0rs++HfKeyJGzo
JofvWj/oMCADt64hG5Vb6wLhwIvxJ7WDjbBZreUzCMURoT9ej80K7/cx0JkXHOMr
rXfwzxXTQYf7p1W6+9/l
=WmhY
-----END PGP SIGNATURE-----
13 years, 1 month
Re: [fedora-arm] Regenerating the cross stuff
by Andy Green
On 08/03/10 12:02, Somebody in the thread at some point said:
>> The original is 1560 the extracted is only 686, it just because it's
>> stripped though
>
> And stripping it by hand doesn't set the machine type to None?
>
> Can you re-try the whole build and see if it screws up again (or did
> you try this already)?
Yeah I built it a couple of times since this issue, I read a hint that
the wrong %{__strip}, host one, might have been used, so I set __strip
to /bin/true, didn't help.
And indeed -->
[agreen@otae libgcc]$ cp _thumb1_case_sqi.o test-_thumb1_case_sqi.o
[agreen@otae libgcc]$ armv5tel-redhat-linux-gnueabi-strip
test-_thumb1_case_sqi.o
[agreen@otae libgcc]$ armv5tel-redhat-linux-gnueabi-readelf -a
test-_thumb1_case_sqi.o
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: REL (Relocatable file)
Machine: ARM
Version: 0x1
Entry point address: 0x0
Start of program headers: 0 (bytes into file)
Start of section headers: 156 (bytes into file)
Flags: 0x5000000, Version5 EABI
Size of this header: 52 (bytes)
Size of program headers: 0 (bytes)
Number of program headers: 0
Size of section headers: 40 (bytes)
Number of section headers: 7
Section header string table index: 6
Section Headers:
[Nr] Name Type Addr Off Size ES Flg
Lk Inf Al
[ 0] NULL 00000000 000000 000000 00
0 0 0
[ 1] .text PROGBITS 00000000 000034 000014 00 AX
0 0 4
[ 2] .data PROGBITS 00000000 000048 000000 00 WA
0 0 1
[ 3] .bss NOBITS 00000000 000048 000000 00 WA
0 0 1
[ 4] .note.GNU-stack PROGBITS 00000000 000048 000000 00
0 0 1
[ 5] .ARM.attributes ARM_ATTRIBUTES 00000000 000048 000016 00
0 0 1
[ 6] .shstrtab STRTAB 00000000 00005e 00003c 00
0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)
There are no section groups in this file.
There are no program headers in this file.
There are no relocations in this file.
There are no unwind sections in this file.
No version information found in this file.
Attribute Section: aeabi
File Attributes
Tag_CPU_arch: v4T
Tag_THUMB_ISA_use: Thumb-1
Tag_ABI_align8_preserved: Yes, except leaf SP
I'll look into how it makes the ar archive I guess.
-Andy
13 years, 1 month
Re: [fedora-arm] Regenerating the cross stuff
by Andy Green
On 08/03/10 11:50, Somebody in the thread at some point said:
>> Hum if I go down into the rpmbuild/BUILD where it was made, I can see
>> the original .o and it's fine
>>
>> [agreen@otae libgcc]$ armv5tel-redhat-linux-gnueabi-objdump -f
>> _thumb1_case_sqi.o
>>
>> _thumb1_case_sqi.o: file format elf32-littlearm
>> architecture: arm, flags 0x00000011:
>> HAS_RELOC, HAS_SYMS
>> start address 0x00000000
>>
>> The one that is extracted from the .a file -- surely it is from the
>> above file though -- is broken
>>
>> [agreen@otae tmp]$ armv5tel-redhat-linux-gnueabi-objdump -f
>> _thumb1_case_sqi.o
>>
>> _thumb1_case_sqi.o: file format elf32-little
>> architecture: UNKNOWN!, flags 0x00000010:
>> HAS_SYMS
>> start address 0x00000000
>
> Can you do a bitwise compare between the two files? (Are they even the
> same length?) Bitflip somewhere maybe?
The original is 1560 the extracted is only 686, it just because it's
stripped though
[agreen@otae libgcc]$ armv5tel-redhat-linux-gnueabi-readelf -a
_thumb1_case_sqi.o
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: REL (Relocatable file)
Machine: ARM
Version: 0x1
Entry point address: 0x0
Start of program headers: 0 (bytes into file)
Start of section headers: 624 (bytes into file)
Flags: 0x5000000, Version5 EABI
Size of this header: 52 (bytes)
Size of program headers: 0 (bytes)
Number of program headers: 0
Size of section headers: 40 (bytes)
Number of section headers: 16
Section header string table index: 13
Section Headers:
[Nr] Name Type Addr Off Size ES Flg
Lk Inf Al
[ 0] NULL 00000000 000000 000000 00
0 0 0
[ 1] .text PROGBITS 00000000 000034 000014 00 AX
0 0 4
[ 2] .data PROGBITS 00000000 000048 000000 00 WA
0 0 1
[ 3] .bss NOBITS 00000000 000048 000000 00 WA
0 0 1
[ 4] .note.GNU-stack PROGBITS 00000000 000048 000000 00
0 0 1
[ 5] .ARM.attributes ARM_ATTRIBUTES 00000000 000048 000016 00
0 0 1
[ 6] .debug_line PROGBITS 00000000 00005e 000068 00
0 0 1
[ 7] .rel.debug_line REL 00000000 0005e0 000008 08
14 6 4
[ 8] .debug_info PROGBITS 00000000 0000c6 0000e1 00
0 0 1
[ 9] .rel.debug_info REL 00000000 0005e8 000020 08
14 8 4
[10] .debug_abbrev PROGBITS 00000000 0001a7 000014 00
0 0 1
[11] .debug_aranges PROGBITS 00000000 0001c0 000020 00
0 0 8
[12] .rel.debug_arange REL 00000000 000608 000010 08
14 11 4
[13] .shstrtab STRTAB 00000000 0001e0 00008d 00
0 0 1
[14] .symtab SYMTAB 00000000 0004f0 0000d0 10
15 12 4
[15] .strtab STRTAB 00000000 0005c0 00001d 00
0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)
There are no section groups in this file.
There are no program headers in this file.
Relocation section '.rel.debug_line' at offset 0x5e0 contains 1 entries:
Offset Info Type Sym.Value Sym. Name
00000053 00000102 R_ARM_ABS32 00000000 .text
Relocation section '.rel.debug_info' at offset 0x5e8 contains 4 entries:
Offset Info Type Sym.Value Sym. Name
00000006 00000802 R_ARM_ABS32 00000000 .debug_abbrev
0000000c 00000902 R_ARM_ABS32 00000000 .debug_line
00000010 00000102 R_ARM_ABS32 00000000 .text
00000014 00000102 R_ARM_ABS32 00000000 .text
Relocation section '.rel.debug_aranges' at offset 0x608 contains 2 entries:
Offset Info Type Sym.Value Sym. Name
00000006 00000602 R_ARM_ABS32 00000000 .debug_info
00000010 00000102 R_ARM_ABS32 00000000 .text
There are no unwind sections in this file.
Symbol table '.symtab' contains 13 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 00000000 0 NOTYPE LOCAL DEFAULT UND
1: 00000000 0 SECTION LOCAL DEFAULT 1
2: 00000000 0 SECTION LOCAL DEFAULT 2
3: 00000000 0 SECTION LOCAL DEFAULT 3
4: 00000000 0 SECTION LOCAL DEFAULT 4
5: 00000000 0 NOTYPE LOCAL DEFAULT 1 $t
6: 00000000 0 SECTION LOCAL DEFAULT 8
7: 0000000c 0 NOTYPE LOCAL DEFAULT 11 $d
8: 00000000 0 SECTION LOCAL DEFAULT 10
9: 00000000 0 SECTION LOCAL DEFAULT 6
10: 00000000 0 SECTION LOCAL DEFAULT 11
11: 00000000 0 SECTION LOCAL DEFAULT 5
12: 00000001 18 FUNC GLOBAL HIDDEN 1 __gnu_thumb1_case_sqi
No version information found in this file.
Attribute Section: aeabi
File Attributes
Tag_CPU_arch: v4T
Tag_THUMB_ISA_use: Thumb-1
Tag_ABI_align8_preserved: Yes, except leaf SP
(this next guy was pulled from the .a like this -->
[agreen@otae tmp]$ armv5tel-redhat-linux-gnueabi-ar x
/usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.5.0/libgcc.a )
[agreen@otae tmp]$ armv5tel-redhat-linux-gnueabi-readelf -a
_thumb1_case_sqi.o
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: REL (Relocatable file)
Machine: None
Version: 0x1
Entry point address: 0x0
Start of program headers: 0 (bytes into file)
Start of section headers: 172 (bytes into file)
Flags: 0x5000000
Size of this header: 52 (bytes)
Size of program headers: 0 (bytes)
Number of program headers: 0
Size of section headers: 40 (bytes)
Number of section headers: 9
Section header string table index: 6
Section Headers:
[Nr] Name Type Addr Off Size ES Flg
Lk Inf Al
[ 0] NULL 00000000 000000 000000 00
0 0 0
[ 1] .text PROGBITS 00000000 000034 000014 00 AX
0 0 4
[ 2] .data PROGBITS 00000000 000048 000000 00 WA
0 0 1
[ 3] .bss NOBITS 00000000 000048 000000 00 WA
0 0 1
[ 4] .note.GNU-stack PROGBITS 00000000 000048 000000 00
0 0 1
[ 5] .ARM.attributes LOPROC+3 00000000 000048 000016 00
0 0 1
[ 6] .shstrtab STRTAB 00000000 00005e 00004c 00
0 0 1
[ 7] .symtab SYMTAB 00000000 000214 000080 10
8 7 4
[ 8] .strtab STRTAB 00000000 000294 00001a 00
0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)
There are no section groups in this file.
There are no program headers in this file.
There are no relocations in this file.
There are no unwind sections in this file.
Symbol table '.symtab' contains 8 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 00000000 0 NOTYPE LOCAL DEFAULT UND
1: 00000000 0 NOTYPE LOCAL DEFAULT 1 $t
2: 00000000 0 SECTION LOCAL DEFAULT 1
3: 00000000 0 SECTION LOCAL DEFAULT 2
4: 00000000 0 SECTION LOCAL DEFAULT 3
5: 00000000 0 SECTION LOCAL DEFAULT 4
6: 00000000 0 SECTION LOCAL DEFAULT 5
7: 00000001 18 FUNC GLOBAL HIDDEN 1 __gnu_thumb1_case_sqi
No version information found in this file.
It's a bit like something wrote an int to the wrong place in the header
somewhere along the line.
-Andy
13 years, 1 month
Re: [fedora-arm] Regenerating the cross stuff
by Andy Green
On 08/03/10 11:44, Somebody in the thread at some point said:
>> Unfortunately there's no simple way of working around that by glueing
>> that option into the defaults I could find.
>
> That seems like a bad idea in any case -- then people would start
> inadvertently linking against x86 object files and wondering what went
> wrong.
Yeah, I'm just thinking about getting through this but you're right at
the distro level it'd be a pretty bad workaround.
>> I studied your 4.1 libgcc.a contents as well, there isn't any thumb
>> related routine in that old version but nothing in that guy reports "no
>> machine".
>
> Right, I didn't run into this problem myself at any point with the 4.1
> stuff.
Hum if I go down into the rpmbuild/BUILD where it was made, I can see
the original .o and it's fine
[agreen@otae libgcc]$ armv5tel-redhat-linux-gnueabi-objdump -f
_thumb1_case_sqi.o
_thumb1_case_sqi.o: file format elf32-littlearm
architecture: arm, flags 0x00000011:
HAS_RELOC, HAS_SYMS
start address 0x00000000
The one that is extracted from the .a file -- surely it is from the
above file though -- is broken
[agreen@otae tmp]$ armv5tel-redhat-linux-gnueabi-objdump -f
_thumb1_case_sqi.o
_thumb1_case_sqi.o: file format elf32-little
architecture: UNKNOWN!, flags 0x00000010:
HAS_SYMS
start address 0x00000000
-Andy
13 years, 1 month
Re: [fedora-arm] Regenerating the cross stuff
by Andy Green
On 08/03/10 11:20, Somebody in the thread at some point said:
>> _thumb1_case_sqi.o: ELF 32-bit LSB relocatable, no machine,
>> version 1 (SYSV), not stripped
> I'm not sure either, but I would e.g. try capturing the output of the
> build process somewhere to make sure that, say, _thumb1_case_sqi.o and
> _thumb1_case_uhi.o are compiled/assembled with the same command line
> options. If they are, I'd check whether there are directives in one
> of the files that aren't in the other.
Thanks. I found out a little more, if I pass
-Wl,--accept-unknown-input-arch
on the gcc commandline, it's happy and falls through to complaining
about the lack of cross libc which is correct for me. So it seems it
has the idea that the libgcc.a file has "unknown arch" and that makes
the problem.
Unfortunately there's no simple way of working around that by glueing
that option into the defaults I could find.
I studied your 4.1 libgcc.a contents as well, there isn't any thumb
related routine in that old version but nothing in that guy reports "no
machine".
Maybe it's a genuine issue with 4.5.0 libgcc build somehow, I'll try
your suggestion.
-Andy
13 years, 1 month
