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

E: zab@zabbo.net

D: maestro pci sound

M: David Brownell

N: David Brownell

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

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

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

=====

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

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.

software necessary to run the 3.0 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,

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

running, the suggested command should tell you.

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

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

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

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

isdn4k-utils.

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

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

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

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

o  Gnu C                  3.2                     # gcc --version

o  Gnu make               3.80                    # make --version

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

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

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

(this also produces better output than ksymoops).

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

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

you can still decode that Oops with ksymoops.

It is generally preferred to build the kernel with CONFIG_KALLSYMS so

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

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

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

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

with ksymoops.

Module-Init-Tools

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

NFS-utils

---------

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

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

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

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

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

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

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

getting lots of old entries that never get removed.

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

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

export information to the kernel.  This removes the dependency on

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

active clients.

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

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

appropriate export information to the kernel.  This removes the

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

currently active clients.

To enable this new functionality, you need to:

		Chapter 14: Allocating memory

The kernel provides the following general purpose memory allocators:

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

documentation for further information about them.

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

the API documentation for further information about them.

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

  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