arm August 2010

arm@lists.fedoraproject.org

9 participants
11 discussions

Fedora ARM 12 on IGEPv2 (Beagle Board clone)
by Matthew Wilson 01 Jan '16

01 Jan '16

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=4… [2] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344j/Beihgi…

11 15

Re: [fedora-arm] Guruplug | uaputl fail
by Martin Stadtler 01 Nov '10

01 Nov '10

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

3 5

SheevaPlug donation, where to send?
by Adam Miller 26 Aug '10

26 Aug '10

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

2 2

Re: [fedora-arm] bad link on http://fedoraproject.org/wiki/Architectures/ARM page
by Till Maas 19 Aug '10

19 Aug '10

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/so… and this results in a 404. > > Fixed: > https://fedoraproject.org/w/index.php?title=Architectures%2FARM&diff=193398… 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

1 0

Guruplug | uaputl fail
by Bernhard Schuster 19 Aug '10

19 Aug '10

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

3 6

Fedora 13 status
by Lorenzo Villani 08 Aug '10

08 Aug '10

-----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-----

1 0

Re: [fedora-arm] Regenerating the cross stuff
by Andy Green 03 Aug '10

03 Aug '10

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

1 0

Re: [fedora-arm] Regenerating the cross stuff
by Andy Green 03 Aug '10

03 Aug '10

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

1 0

Re: [fedora-arm] Regenerating the cross stuff
by Andy Green 03 Aug '10

03 Aug '10

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

1 0

Re: [fedora-arm] Regenerating the cross stuff
by Andy Green 03 Aug '10

03 Aug '10

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

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

arm August 2010