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
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.
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.
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.
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.
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.
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.
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.
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.
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
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:
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.
Non-trivial information is generally:
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.
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.
The Linux tools are straightforward to compile and contain documentation.
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.