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]

Add to Google Follow linuxarm on Twitter