Merge branches 'btc', 'dma', 'entry', 'fixes', 'linker-layout', 'misc',...

E: zab@zabbo.net

E: zab@zabbo.net

D: maestro pci sound

D: maestro pci sound

M: David Brownell

N: David Brownell

D: Kernel engineer, mentor, and friend.  Maintained USB EHCI and

D: Kernel engineer, mentor, and friend.  Maintained USB EHCI and

D: gadget layers, SPI subsystem, GPIO subsystem, and more than a few

D: gadget layers, SPI subsystem, GPIO subsystem, and more than a few

D: device drivers.  His encouragement also helped many engineers get

D: device drivers.  His encouragement also helped many engineers get

=====

=====

This document is designed to provide a list of the minimum levels of

This document is designed to provide a list of the minimum levels of

software necessary to run the 2.6 kernels, as well as provide brief

software necessary to run the 3.0 kernels.

instructions regarding any other "Gotchas" users may encounter when

trying life on the Bleeding Edge.  If upgrading from a pre-2.4.x

kernel, please consult the Changes file included with 2.4.x kernels for

additional information; most of that information will not be repeated

here.  Basically, this document assumes that your system is already

functional and running at least 2.4.x kernels.

This document is originally based on my "Changes" file for 2.0.x kernels

This document is originally based on my "Changes" file for 2.0.x kernels

and therefore owes credit to the same people as that file (Jared Mauch,

and therefore owes credit to the same people as that file (Jared Mauch,

encountered a bug!  If you're unsure what version you're currently

encountered a bug!  If you're unsure what version you're currently

running, the suggested command should tell you.

running, the suggested command should tell you.

Again, keep in mind that this list assumes you are already

Again, keep in mind that this list assumes you are already functionally

functionally running a Linux 2.4 kernel.  Also, not all tools are

running a Linux kernel.  Also, not all tools are necessary on all

necessary on all systems; obviously, if you don't have any ISDN

systems; obviously, if you don't have any ISDN hardware, for example,

hardware, for example, you probably needn't concern yourself with

you probably needn't concern yourself with isdn4k-utils.

isdn4k-utils.

o  Gnu C                  3.2                     # gcc --version

o  Gnu C                  3.2                     # gcc --version

o  Gnu make               3.80                    # make --version

o  Gnu make               3.80                    # make --version

If the unthinkable happens and your kernel oopses, you may need the

If the unthinkable happens and your kernel oopses, you may need the

ksymoops tool to decode it, but in most cases you don't.

ksymoops tool to decode it, but in most cases you don't.

In the 2.6 kernel it is generally preferred to build the kernel with

It is generally preferred to build the kernel with CONFIG_KALLSYMS so

CONFIG_KALLSYMS so that it produces readable dumps that can be used as-is

that it produces readable dumps that can be used as-is (this also

(this also produces better output than ksymoops).

produces better output than ksymoops).  If for some reason your kernel

If for some reason your kernel is not build with CONFIG_KALLSYMS and

is not build with CONFIG_KALLSYMS and you have no way to rebuild and

you have no way to rebuild and reproduce the Oops with that option, then

reproduce the Oops with that option, then you can still decode that Oops

you can still decode that Oops with ksymoops.

with ksymoops.

Module-Init-Tools

Module-Init-Tools

-----------------

-----------------

NFS-utils

NFS-utils

---------

---------

In 2.4 and earlier kernels, the nfs server needed to know about any

In ancient (2.4 and earlier) kernels, the nfs server needed to know

client that expected to be able to access files via NFS.  This

about any client that expected to be able to access files via NFS.  This

information would be given to the kernel by "mountd" when the client

information would be given to the kernel by "mountd" when the client

mounted the filesystem, or by "exportfs" at system startup.  exportfs

mounted the filesystem, or by "exportfs" at system startup.  exportfs

would take information about active clients from /var/lib/nfs/rmtab.

would take information about active clients from /var/lib/nfs/rmtab.

fail-over.  Even when the system is working well, rmtab suffers from

fail-over.  Even when the system is working well, rmtab suffers from

getting lots of old entries that never get removed.

getting lots of old entries that never get removed.

With 2.6 we have the option of having the kernel tell mountd when it

With modern kernels we have the option of having the kernel tell mountd

gets a request from an unknown host, and mountd can give appropriate

when it gets a request from an unknown host, and mountd can give

export information to the kernel.  This removes the dependency on

appropriate export information to the kernel.  This removes the

rmtab and means that the kernel only needs to know about currently

dependency on rmtab and means that the kernel only needs to know about

active clients.

currently active clients.

To enable this new functionality, you need to:

To enable this new functionality, you need to:

		Chapter 14: Allocating memory

		Chapter 14: Allocating memory

The kernel provides the following general purpose memory allocators:

The kernel provides the following general purpose memory allocators:

kmalloc(), kzalloc(), kcalloc(), and vmalloc().  Please refer to the API

kmalloc(), kzalloc(), kcalloc(), vmalloc(), and vzalloc().  Please refer to

documentation for further information about them.

the API documentation for further information about them.

The preferred form for passing a size of a struct is the following:

The preferred form for passing a size of a struct is the following:

- The boot loader is expected to call the kernel image by jumping

- The boot loader is expected to call the kernel image by jumping

  directly to the first instruction of the kernel image.

  directly to the first instruction of the kernel image.

  On CPUs supporting the ARM instruction set, the entry must be

  made in ARM state, even for a Thumb-2 kernel.

  On CPUs supporting only the Thumb instruction set such as

  Cortex-M class CPUs, the entry must be made in Thumb state.

ROM-able zImage boot from eSD

-----------------------------

An ROM-able zImage compiled with ZBOOT_ROM_SDHI may be written to eSD and

SuperH Mobile ARM will to boot directly from the SDHI hardware block.

This is achieved by the mask ROM loading the first portion of the image into

MERAM and then jumping to it. This portion contains loader code which

copies the entire image to SDRAM and jumps to it. From there the zImage

boot code proceeds as normal, uncompressing the image into its final

location and then jumping to it.

This code has been tested on an mackerel board using the developer 1A eSD

boot mode which is configured using the following jumper settings.

   8 7 6 5 4 3 2 1

   x|x|x|x| |x|x|

S4 -+-+-+-+-+-+-+-

    | | | |x| | |x on

The eSD card needs to be present in SDHI slot 1 (CN7).

As such S1 and S33 also need to be configured as per

the notes in arch/arm/mach-shmobile/board-mackerel.c.

A partial zImage must be written to physical partition #1 (boot)

of the eSD at sector 0 in vrl4 format. A utility vrl4 is supplied to

accomplish this.

e.g.

	vrl4 < zImage | dd of=/dev/sdX bs=512 count=17

A full copy of _the same_ zImage should be written to physical partition #1

(boot) of the eSD at sector 0. This should _not_ be in vrl4 format.

	vrl4 < zImage | dd of=/dev/sdX bs=512

Note: The commands above assume that the physical partition has been

switched. No such facility currently exists in the Linux Kernel.

Physical partitions are described in the eSD specification.  At the time of

writing they are not the same as partitions that are typically configured

using fdisk and visible through /proc/partitions