ARMLinux @ Simtec

ARM Linux FAQ

  1. What is KAutobuild?
  2. Who wrote KAutobuild?
  3. What does the message "Erase block size too small (16KiB). Using virtual blocks size (32KiB)" mean?
  4. What does the message "Empty flash at 0x00003ffc ends at 0x00004000" mean?
  5. What does the message "CLEANMARKER node found at 0x00000000 has totlen 0xc != normal 0x0" mean?
  6. How do I compile a kernel for ARM?
  7. I'm working on a bootloader, where can I find ARM Linux kernel booting requirements?
  8. How can I map physical memory in user space ?
  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?
  10. When I trace kernel in head.S I found problems that may be caused by __turn_mmu_on. Any idea ?
  11. When I compile my 2.6.x kernel for ARM I get a compiler/assembler error. Any idea ?
  12. Why get a machine identity number, and how do changes in hardware affect it
  13. If a Linux 2.6 kernel is compiled with OABI/EABI concurrent support enabled why do ALSA audio applications fail with bad ioctl errors?
  14. I2C tools are available for ABLE, are similar tools available from within Linux?
  15. My board has a TMP101 temprature sensor, can it be used under Linux?
  1. What is KAutobuild?

    The Kautobuild system attempts to build all the default configurations present in the kernel source. The system rebuilds the 2.6 series kernel every time the kernel.org finger banner updates and a new source set is available. This means in practice once a day as the -bk snapshots are built. The resulting infomation is made available on our ARMLinux community site

  2. Who wrote KAutobuild?

    Kautobuild was originally developed by Ben Dooks as a tool to gain insight into the kernels built by the ARM architecture. The system was further extended by Vincent Sanders, who also added an back-end database, and web-based front-end to allow mining of the data.

  3. What does the message "Erase block size too small (16KiB). Using virtual blocks size (32KiB)" mean?

    JFFS2 has a limit on how much memory it will use for erase block tables, and thus reduces the number on devices that are too large.

    The warning can be fixed by changing the options to mkfs.jffs2 and to nandwrite. For the above example, use mkfs2.jffs2 -b 0x8000 to produce an image with 32KiB eraseblocks, and use nandwrite --blockalign=2 (align writes to 2 16KiB blocks)

    Typically, the 64MiB NAND devices being fitted on the 2410/2440 line, should use either 16KiB (for small partitions) or 32KiB.

  4. What does the message "Empty flash at 0x00003ffc ends at 0x00004000" mean?

    This warning is due to the JFFS2 image being created with a different eraseblock size to the one being used by JFFS2. This may be due to not specifying the eraseblock size to mkfs.jffs2, or due to JFFS2 enlarging the eraseblock size due to memory limits.

  5. What does the message "CLEANMARKER node found at 0x00000000 has totlen 0xc != normal 0x0" mean?

    This warning is generated by writing an JFFS2 image built for NOR to a NAND based device. NAND flash has OOB data, which holds the clean markers, thus negating the need to have then in the normal JFFS2 nodes.

  6. How do I compile a kernel for ARM?

    Compiling a kernel for the ARM architecture is very similar to any other architecture. Russell King maintains a document detailing the process.

  7. I'm working on a bootloader, where can I find ARM Linux kernel booting requirements?

    There are many existing bootloaders on ARM, if you are planning on writing one from scratch, it will almost certainly be better to use one of them.

    The whole subject is discussed at length in the Definitive guide to booting ARM Linux and on the ARMLinux community website.

  8. How can I map physical memory in user space ?

    This is discussed in the acessing General Purpose I/O from Linux document. This is a very comman question and many devlopers introduce significant errors by reimplementing this code incorrectly. The devmem2 utility is generally considered the definitive source code reference.

  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?

    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.

    There is no a generally applicable workaround for this issue other than using an earlier binutils version such as 2.14 which may have other issues, as a minimum the 2.14 binutils requires a patch to prevent a silent build error.

  10. When I trace kernel in head.S I found problems that may be caused by __turn_mmu_on. Any idea ?

    This has been asked so often it has its own comment in the code

    /*
 * 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.
 */

    The main issue here is that developers 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 have a valid mapping and appear not to exist. If there is debugging code present that doesn't cater for a complete change in the memory structure, then that debugging code is buggy.

    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.

  11. When I compile my 2.6.x kernel for ARM I get a compiler/assembler error. Any idea ?

    Please ensure this is not caused by using a broken toolchain, binutils or third party patch. A quick look at the Kautobuild for kernel you are trying to build should give some idea if the error is expected.

    Once all these things have been checked the issue should be reported to the community mailing list. When reporting these problems, always include as much information as possible as a minimum the full build line. This can be obtained by re-running the make with an additional argument: V=1

  12. Why get a machine identity number, and how do changes in hardware affect it

    Each machine supported by the Linux/ARM kernel is identified by an unique machine number which is used to identify the hardware in use. This method is used as there is no standard method of identifying the hardware on any given machine without dangerous (or sometimes impossible) auto-probing.

    At the start of a project, a board of similar design is often selected and copied to support the new hardware. This FAQ entry attempts to explain when and why a new machine identity should be allocated.

    Typically, should the differences between the old and new support files become non-trivially detectable, then it is at this point a new allocation should be made. By trivially, we generally mean the following:

    • Any changes such that the kernel driver handling the particular hardware cannot detect the presence, or the identity of the device. Drivers such as the NAND MTD layer can find out some information by probing for a device identity from the attached chip.

      Many I2C drivers can do some auto detection, but since there is no defined identity method for the bus, detecting devices when a number of device drivers are included in the kernel can be difficult or cause problems with incorrect detection.

      Several subsystems, such as SPI need to be told the attached drivers when the bus initialised as there is no defined method of probing for devices.

    • Information that is passed in to the kernel from the bootloader, which includes the memory layout, command line, and optionally items such as an revision number.

    Non-trivial information is generally:

    • Driver setup information for drivers which can autoprobe. These can include different chip-selects or timing infromation for an NAND driver, or bus-speed for an I2S bus (if the designer has decided to save power by changing the pull-up values on the bus)

    When there are only minor changes between products, it is possible to pass the kernel some revision information without allocating a new machine number. The value of ATAG_REVISION can be read from the system_rev global variable when the board initialisation called.

    The system_rev can be used to alter the list of drivers added, such as changing the type of display being used, or indicating the presence of hardware fixes for bugs that no longer need working aroud.

    When changing the machine identity it does not mean that the whole driver set or support files need to be copied. An efficient set of source code calls are automatically provided by the kernel to allow compile and/or runtine checking. These functions are supplied as machine_is_<x>, so a source file which supports machines fred, jim and sheila can do the following:

    	if (machine_is_fred() || machine_is_sheila())
		do_first_thing();
	else
		do_other_thing();

    These functions will compile down to simple 1/0 returns if only one machine is selected (modern compilers such as gcc 3.4 or later will eliminate any code from an if() block that is determined unreachable at compile time), thus ensuring efficieny if it is really needed.

    Remember, the machine identity is there to help you and the maintainers when building kernels which support more than one board. For example, the s3c24xx build supports 18 different machines.

  13. If a Linux 2.6 kernel is compiled with OABI/EABI concurrent support enabled why do ALSA audio applications fail with bad ioctl errors?

    The EABI compatability causes the kernel internal data structures to be built with EABI alignments. This causes ioctl() calls which contain binary data structures (such as ALSA) to fail because the structure size and packing has changed.

    There is no known workaround except to build the kernel for only the required ABI.

  14. I2C tools are available for ABLE, are similar tools available from within Linux?

    The Linux I2C tools project contains tools which are comparable to the ABLE tools.

    The Linux tools are straightforward to compile and contain documentation.

  15. My board has a TMP101 temprature sensor, can it be used under Linux?

    Yes, the TMP101 sensor is supported using the lm75 kernel driver.

    The lm75 driver must be loaded with the correct parameters to successfully detect the TMP101 as the device usually appears at a different I2C bus address than the kernel driver default.

    The typical alternate I2C address is 0x49

    The command to load the driver with a device at 0x49 is:

    modprobe lm75 force_lm75_compat=0,0x49

    The temprature may then be read using the standard lmsensors tools or directly from the /sys/bus/i2c/devices/0-0049/temp1_input file.