|
|
|
Mailing List FAQ | |
| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
|
|
This message is sent to this mailing list once a week.
This can also be found (with html links) at:
http://www.arm.linux.org.uk/mailinglists/faq.php
1. [12]How do I compile a kernel for ARM?
2. [13]Can I use Intel IXP425 AccessLibrary with 2.6 kernels?
3. [14]What are the available solutions for floating point support?
4. [15]Can I use the both hard & soft float at the same time or only choose one
of them?
5. [16]When I compile my 2.6.x kernel for ARM I get a compiler/assembler error.
Any idea ?
6. [17]When I trace kernel in head.S I found problems that may be caused by
__turn_mmu_on. Any idea ?
7. [18]I'm working on a bootloader, where can I find ARM Linux kernel booting
requirements ?
8. [19]How can I access /dev/mem ? - How can I map memory in user space ?
9. [20]I see '$a', '$d' and '$t' symbols in the backtrace/ksymoops
output/System.map/linker error messages. What are they and how can I get rid
of them ?
10. [21]Where can I find -rmk -pxa -* patches for the 2.6 kernel ?
11. [22]I'm using this 2.4 kernel, and ...
12. [23]I'm using this 2.6 kernel, and ...
13. [24]Why does my debugger trap in __arch_clear_user?
3. Patch Submission (via git/patches etc)
1. [25]Where should patches be reviewed?
2. [26]What does rmk's "ok" mean?
3. [27]Which git commit should I base my tree on?
4. [28]How should commits in my git tree be reviewed?
5. [29]What format should I use for the git pull request?
6. [30]I have one patch. How should I submit it?
1. Mailing list questions:
1.1. How do I subscribe or unsubscribe from the mailing lists.
The mailing list software appends a footer to every message sent via the mailing
lists:
-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm
FAQ: http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette: http://www.arm.linux.org.uk/mailinglists/etiquette.php
If you point your web browser to the "list admin" address and scroll to the bottom,
where you can enter your subscribed email address. Once this is done, you will be
given instructions on how to unsubscribe or change your options.
2. General questions:
2.1. How do I compile a kernel for ARM?
[[31]rmk]
Please see the [32]kernel compilation instructions.
2.2. I am trying to run a Linux kernel 2.6 on my Intel IXP42x. I am using the kernel
2.6.x. This kernel does not include support for the integrated ethernet controllers of
the IXP425. I have downloaded the AccessLibrary 1.x from Intel, but i have seen it
only supports kernel 2.4. Is there any news about a new version of the AccessLibrary
for 2.6 kernel?
[19 March 2004 - [33]ds]
Unfortunately, the only people who can help you are Intel b/c they need to port the
access library to 2.6 since the code is under a closed license and even if someone
outside Intel ported it to 2.6, they could not share the code due to the propietary
license.
[14 December 2004 - [34]rmk]
When we say "the only people who can help you are Intel" we mean it. Please do not
post questions about this to the ARM Linux mailing lists on the off chance. It just
winds certain people up. We can't help you. We can't even suggest where you might
get help from, other than Intel directly. Talk to your Intel representative, or if
you don't know who that is, your manager. The best information we have is in the
above FAQ entry.
The linux-arm* lists are for supporting Open Source only and not for random
proprietary closed source products.
[10 September 2008 - [35]rwhitby] As of 2.6.26, the kernel includes support for the
integrated ethernet controllers of the IXP42x (see drivers/net/arm/ixp4xx_eth.c,
arch/arm/mach-ixp4xx/ixp4xx_npe.c and arch/arm/mach-ixp4xx/ixp4xx_qmgr.c). You are
still required to download the proprietary firmware microcode from Intel, which is
loaded via hotplug.
2.3. I feel really confused about what's the difference with gcc soft-float support
and the kernel NWFPE/FastFPE support?
[31 January 2004 - [36]np]
Scenario 1 (hard-float): The compiler emits opcodes designed to be used with a
hardware floating point coprocessor (FPU). The FPU usually has a set of extra
registers for its use, and the compiler may as well pass floating point argument to
functions through those registers. This is of course the best performing solution
when a real hardware FPU is used.
Scenario 2 (soft-float): the compiler converts floating point operations into
function calls and a special library is used to provide all functions performing
the required operations, all in software with no FPU instructions at all. There is
obviously no extra floating point registers available in this case, therefore all
FP arguments to functions have to be passed through standard registers or on the
stack. This is of course the best performing solution when no hardware FPU is
available, given that the library implementing the FP operations is optimally
coded.
Now, unfortunately, the default on ARM Linux has traditionally been set to have the
compiler use hard-float, even if ARM Linux never ran on any ARM CPU with a real
hardware FPU. The CPU is therefore raising the invalid instruction exception each
time some FPU opcode is encountered. Then the kernel traps that exception, looks at
the given FPU instruction and emulates it in software. But here not only the kernel
must perform the FP operation, it must emulates the whole hardware FPU as well.
That's what NWFPE or FastFPE are doing. This is obviously the worst performing
arrangement that can be due to the exception trap and emulation overhead
2.4. Can I use the both hard & soft float at the same time or only choose one of them?
[31 January 2004 - [37]np]
Depends. You can use both at the same time, but not in the same application. The
problem as to do with the ABI incompatibility between soft-float and hard-float due
to the different floating point argument passing conventions. So, if you decide to
switch to using soft-float for some application, you MUST recompile ALL the
libraries that application is going to use, including system libraries like the C
library. If those libraries are dynamically linked libraries, you then must also
recompile all the applications that share those same libraries. And then your
application will run correctly only on systems with soft-float environments, unless
you link it statically in which case it will run anywhere (even on a kernel with
NWFPE configured in -- it will simply not be invoked). That's the main reason why
mainstream ARM distributions are still reluctant to switch to soft-float because of
the associated compatibility pain.
2.5. When I compile my 2.6.x kernel for ARM I get a compiler/assembler error. Any idea
?
[2 April 2004 - [38]rmk]
When reporting these problems, always show the full build line. This can be
obtained by re-running the make with an additional argument: V=1
2.6. When I trace kernel in head.S I found problems that may be caused by
__turn_mmu_on. Any idea ?
[5 April 2004 - [39]rmk]
Please read the comment in head.S:
/*
* Enable the MMU. This completely changes the structure of the visible
* memory space. You will not be able to trace execution through this.
* If you have an enquiry about this, *please* check the linux-arm-kernel
* mailing list archives BEFORE sending another post to the list.
*/
It's been asked soo many times that it really is a frequently asked question. The
above comment is supposed to head off further questions, but alas... Hopefully this
FAQ entry will do the job.
[11 January 2002 - [40]rmk]
The number 1 problem is that people just do not realise what "enabling the MMU"
means. It means that _all_ of the addressable memory _will_ change, and this
normally means various regions you'd like to write to no longer exist - in other
words, if you have debugging code present that doesn't cater for a complete change
in the memory structure, then your debugging code is buggy.
(Side note: I've even had people insist that their debugging code is perfect, even
after mentioning the above, and then we've gone through several mails, ended up
having the debugging code posted, and it turns out to buggy, assuming that the LEDs
at some random address are still accessible.)
The best advice is if you're using your own debugging code, remove it. Use the
debugging printascii() stuff for your platform in arch/arm/kernel/debug-armv.S
(enabled by CONFIG_DEBUG_LL) and drop a printascii() into printk()
(kernel/printk.c) just after the vsprintf() call, and monitor the relevant serial
port.
2.7. I'm working on a bootloader, where can I find ARM Linux kernel booting
requirements ?
[7 June 2004 - [41]rmk]
First of all, we don't need another boot loader. If you're planning on writing one
from scratch, please don't. Use one of the existing boot loaders, such as blob or
uboot.
For kernel booting requirements, please see the website:
* [42]2.4.18-rmk6 and 2.5.17 and later booting requirements
* [43]Setting R2 correctly for booting the kernel (explaination of booting
requirements).
2.8. How can I access /dev/mem ? - How can I map memory in user space ?
[10 July 2004 - [44]rmk]
No need to reinvent the wheel, you will find a sample implementation of this type
of thing in devmem2. See [45]http://www.lartmaker.nl/lartware/port/devmem2.c for
the source.
2.9. I see '$a', '$d' and '$t' symbols in the backtrace/ksymoops
output/System.map/linker error messages. What are they and how can I get rid of them ?
[12 July 2004 - [46]rmk]
These are "mapping symbols", which are used in the generation of some binary
formats, added by binutils 2.15. Unfortunately, they leak into the symbol table,
and as such interfere with the linkers ability to find the correct symbol to report
for error messages. They also appear in the objdump --syms and nm outputs, and
affect the operation of the kernel backtrace and ksymoops outputs.
In order to work around this problem, I recommend not using binutils 2.15 for the
time being. Please use an earlier binutils version like 2.14 instead. However,
please ensure that you have applied this [47]fix.
2.10. Where can I find -rmk -pxa -* patches for the 2.6 kernel ?
[21 December 2005 - [48]eb]
Since 2.6, all the ARM support is directly pushed in the mainstream kernel, so you
shouldn't need any patch. Just get the official 2.6.x stable kernel from
[49]http://www.kernel.org/ or the latest development version from the git tree at
[50]http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary.
Russell King's development git tree is synced every two days with Linus' tree so
you only need to keep synced with Linus' one. As usual, you will find patches
awaiting review in Russell King's patch system here:
[51]http://www.arm.linux.org.uk/developer/patches/
2.11. I'm using this 2.4 kernel, and...
[27 July 2006 - [52]erikm]
2.4 support has been abandoned. Don't ask questions about 2.4 on these lists, use
the latest 2.6 kernel, and try to recreate the problem. If it still persists, then
ask on the list.
2.12. I'm using this 2.6 kernel, and...
[27 July 2006 - [53]erikm]
First make sure that you are running the latest stable kernel. Bugs in older
kernels are a waste of everyone's time. Try to recreate your problem with the
latest stable kernel and if it persists, ask on the list. The latest stable kernel
releases can be found at [54]http://www.kernel.org/kdist/finger_banner
2.13. Why does my debugger trap in __arch_clear_user?
[24 August 2006 - [55]rmk]
This is normal. As the kernel operates a demand paged memory system, pages are
faulted in via data aborts and prefetch aborts. However, some debuggers assume that
data or prefetch aborts means that your program did something wrong, and halt
program execution on these events. Therefore, you need to disable this behaviour in
your debugger.
3. General questions:
3.1. Where should patches be reviewed?
[[56]rmk]
Patches should be reviewed on the mailing list prior to submission. This forfills
two aspects - allowing people on the mailing list to review your work, and letting
others know of your work.
3.2. What does rmk's "ok" mean?
[[57]rmk]
It means that rmk is happy with the patch for it to be submitted. It does not mean
you can add an 'Acked-by' tag for rmk to a patch going to the patch system.
'Signed-off-by' should also not be used - when patches are merged from the patch
system, rmk's sign-off will be automatically added.
3.3. Which git commit should I base my tree on?
[[58]rmk]
Linus' tree, or some previously submitted point. Never on rmk's constantly
regenerated devel branch - because it is constantly regenerated.
3.4. How should commits in my git tree be reviewed?
[[59]rmk]
A possible way to export patches for mailing list review is using git-format-patch.
This generates a set of patch files, one per commit, which can then be emailed as
separate attachments (one per email message).
Alternatively, git-send-email will send a set of emails for you, but requires some
configuration. Historically, git-send-email hasn't set proper email headers
resulting in some mail servers rejecting the generated messages for various
reasons.
3.5. What format should I use for the git pull request?
[[60]rmk]
git pull requests should be formatted so that they contain the following
information:
* The commit ID which the patches are based upon
* The URL and branch name (on the same line) to be pulled
* The diffstat for the changes being submitted
* A list of the changes contained within the pull
The 'git-request-pull' command generates a suitable pull message.
3.6. I have one patch. How should I submit it?
[[61]rmk]
git can be problematical for submission of one patch - if the parent git commit is
mischosen, or the pull request is of the wrong format, it takes time to resolve. A
patch sent to the patch system is much more flexible - it doesn't have those
issues. So, in some ways, having the patch outside of 'git' makes it quicker and
easier to merge into git.
--------------------------------------------------------------------------------------
People listed above:
* ds - Deepak Saxena
* eb - Eric Benard
* erikm - Erik Mouw
* np - Nicolas Pitre
* rfs - Ralph Siemsen
* rmk - Russell King
* rwhitby - Rod Whitby
Special thanks to Eric Benard for volunteering to look after this FAQ.
Last modified: July 27, 2006 Linux is a trademark of Linus Torvalds in
the US and some other countries.
(c) 2009 [62]Russell King All ARM and StrongARM are trademarks of [63]ARM
rights reserved. Ltd.
This site is hosted on a Thecus N2100
platform running Linux.
Connectivity for this site is provided by
[64]Deep Blue Solutions Ltd.
[65]Powered by Apache [66]Powered by PHP4 [67]Valid HTML 4.01!
References
Visible links
1. http://www.arm.linux.org.uk/
2. http://www.arm.linux.org.uk/docs/whatis.php
3. http://www.arm.linux.org.uk/docs/
4. http://www.arm.linux.org.uk/developer/
5. http://www.arm.linux.org.uk/mailinglists/
6. http://www.arm.linux.org.uk/contacting.php
7. http://www.arm.linux.org.uk/mailinglists/etiquette.php
8. http://www.arm.linux.org.uk/mailinglists/faq.php
9. http://lists.arm.linux.org.uk/lurker/splash/index.en.html
10. http://www.arm.linux.org.uk/mailinglists/lists.php
11. http://www.arm.linux.org.uk/mailinglists/faq.php#l1
12. http://www.arm.linux.org.uk/mailinglists/faq.php#f1
13. http://www.arm.linux.org.uk/mailinglists/faq.php#f2
14. http://www.arm.linux.org.uk/mailinglists/faq.php#f3
15. http://www.arm.linux.org.uk/mailinglists/faq.php#f4
16. http://www.arm.linux.org.uk/mailinglists/faq.php#f5
17. http://www.arm.linux.org.uk/mailinglists/faq.php#f6
18. http://www.arm.linux.org.uk/mailinglists/faq.php#f7
19. http://www.arm.linux.org.uk/mailinglists/faq.php#f8
20. http://www.arm.linux.org.uk/mailinglists/faq.php#f9
21. http://www.arm.linux.org.uk/mailinglists/faq.php#f10
22. http://www.arm.linux.org.uk/mailinglists/faq.php#f11
23. http://www.arm.linux.org.uk/mailinglists/faq.php#f12
24. http://www.arm.linux.org.uk/mailinglists/faq.php#f13
25. http://www.arm.linux.org.uk/mailinglists/faq.php#p1
26. http://www.arm.linux.org.uk/mailinglists/faq.php#p2
27. http://www.arm.linux.org.uk/mailinglists/faq.php#p3
28. http://www.arm.linux.org.uk/mailinglists/faq.php#p4
29. http://www.arm.linux.org.uk/mailinglists/faq.php#p5
30. http://www.arm.linux.org.uk/mailinglists/faq.php#p6
31. http://www.arm.linux.org.uk/mailinglists/faq.php#rmk
32. http://www.arm.linux.org.uk/docs/kerncomp.shtml
33. http://www.arm.linux.org.uk/mailinglists/faq.php#ds
34. http://www.arm.linux.org.uk/mailinglists/faq.php#rmk
35. http://www.arm.linux.org.uk/mailinglists/faq.php#rwhitby
36. http://www.arm.linux.org.uk/mailinglists/faq.php#np
37. http://www.arm.linux.org.uk/mailinglists/faq.php#np
38. http://www.arm.linux.org.uk/mailinglists/faq.php#rmk
39. http://www.arm.linux.org.uk/mailinglists/faq.php#rmk
40. http://www.arm.linux.org.uk/mailinglists/faq.php#rmk
41. http://www.arm.linux.org.uk/mailinglists/faq.php#rmk
42. http://www.arm.linux.org.uk/developer/booting.php
43. http://lists.arm.linux.org.uk/lurker/message/20030116.235716.0a430881.en.html
44. http://www.arm.linux.org.uk/mailinglists/faq.php#rmk
45. http://www.lartmaker.nl/lartware/port/devmem2.c
46. http://www.arm.linux.org.uk/mailinglists/faq.php#rmk
47. http://lists.arm.linux.org.uk/lurker/message/20040701.191631.bf88f2af.en.html
48. http://www.arm.linux.org.uk/mailinglists/faq.php#eb
49. http://www.kernel.org/
50. http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary
51. http://www.arm.linux.org.uk/developer/patches/
52. http://www.arm.linux.org.uk/mailinglists/faq.php#erikm
53. http://www.arm.linux.org.uk/mailinglists/faq.php#erikm
54. http://www.kernel.org/kdist/finger_banner
55. http://www.arm.linux.org.uk/mailinglists/faq.php#rmk
56. http://www.arm.linux.org.uk/mailinglists/faq.php#rmk
57. http://www.arm.linux.org.uk/mailinglists/faq.php#rmk
58. http://www.arm.linux.org.uk/mailinglists/faq.php#rmk
59. http://www.arm.linux.org.uk/mailinglists/faq.php#rmk
60. http://www.arm.linux.org.uk/mailinglists/faq.php#rmk
61. http://www.arm.linux.org.uk/mailinglists/faq.php#rmk
62. http://www.arm.linux.org.uk/contacting.php
63. http://www.arm.com/
64. http://www.deepbluesolutions.co.uk/
65. http://www.apache.org/
66. http://www.php.net/
67. http://validator.w3.org/check/referer
-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm
FAQ: http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette: http://www.arm.linux.org.uk/mailinglists/etiquette.php
[Linux ARM] [Linux ARM MSM] [Linux ARM Kernel] [Fedora ARM] [IETF Annouce] [Security] [Bugtraq] [Linux] [Linux OMAP] [Linux MIPS] [ECOS] [Asterisk Internet PBX] [Linux API]
|
|