linux/Documentation/frv/booting.txt
<<
>>
Prefs
   1                          =========================
   2                          BOOTING FR-V LINUX KERNEL
   3                          =========================
   4
   5======================
   6PROVIDING A FILESYSTEM
   7======================
   8
   9First of all, a root filesystem must be made available. This can be done in
  10one of two ways:
  11
  12  (1) NFS Export
  13
  14      A filesystem should be constructed in a directory on an NFS server that
  15      the target board can reach. This directory should then be NFS exported
  16      such that the target board can read and write into it as root.
  17
  18  (2) Flash Filesystem (JFFS2 Recommended)
  19
  20      In this case, the image must be stored or built up on flash before it
  21      can be used. A complete image can be built using the mkfs.jffs2 or
  22      similar program and then downloaded and stored into flash by RedBoot.
  23
  24
  25========================
  26LOADING THE KERNEL IMAGE
  27========================
  28
  29The kernel will need to be loaded into RAM by RedBoot (or by some alternative
  30boot loader) before it can be run. The kernel image (arch/frv/boot/Image) may
  31be loaded in one of three ways:
  32
  33  (1) Load from Flash
  34
  35      This is the simplest. RedBoot can store an image in the flash (see the
  36      RedBoot documentation) and then load it back into RAM. RedBoot keeps
  37      track of the load address, entry point and size, so the command to do
  38      this is simply:
  39
  40        fis load linux
  41
  42      The image is then ready to be executed.
  43
  44  (2) Load by TFTP
  45
  46      The following command will download a raw binary kernel image from the
  47      default server (as negotiated by BOOTP) and store it into RAM:
  48
  49        load -b 0x00100000 -r /tftpboot/image.bin
  50
  51      The image is then ready to be executed.
  52
  53  (3) Load by Y-Modem
  54
  55      The following command will download a raw binary kernel image across the
  56      serial port that RedBoot is currently using:
  57
  58        load -m ymodem -b 0x00100000 -r zImage
  59
  60      The serial client (such as minicom) must then be told to transmit the
  61      program by Y-Modem.
  62
  63      When finished, the image will then be ready to be executed.
  64
  65
  66==================
  67BOOTING THE KERNEL
  68==================
  69
  70Boot the image with the following RedBoot command:
  71
  72        exec -c "<CMDLINE>" 0x00100000
  73
  74For example:
  75
  76        exec -c "console=ttySM0,115200 ip=:::::dhcp root=/dev/mtdblock2 rw"
  77
  78This will start the kernel running. Note that if the GDB-stub is compiled in,
  79then the kernel will immediately wait for GDB to connect over serial before
  80doing anything else. See the section on kernel debugging with GDB.
  81
  82The kernel command line <CMDLINE> tells the kernel where its console is and
  83how to find its root filesystem. This is made up of the following components,
  84separated by spaces:
  85
  86  (*) console=ttyS<x>[,<baud>[<parity>[<bits>[<flow>]]]]
  87
  88      This specifies that the system console should output through on-chip
  89      serial port <x> (which can be "0" or "1").
  90
  91      <baud> is a standard baud rate between 1200 and 115200 (default 9600).
  92
  93      <parity> is a parity setting of "N", "O", "E", "M" or "S" for None, Odd,
  94      Even, Mark or Space. "None" is the default.
  95
  96      <stop> is "7" or "8" for the number of bits per character. "8" is the
  97      default.
  98
  99      <flow> is "r" to use flow control (XCTS on serial port 2 only). The
 100      default is to not use flow control.
 101
 102      For example:
 103
 104        console=ttyS0,115200
 105
 106      To use the first on-chip serial port at baud rate 115200, no parity, 8
 107      bits, and no flow control.
 108
 109  (*) root=<xxxx>
 110
 111      This specifies the device upon which the root filesystem resides. It
 112      may be specified by major and minor number, device path, or even
 113      partition uuid, if supported.  For example:
 114
 115        /dev/nfs        NFS root filesystem
 116        /dev/mtdblock3  Fourth RedBoot partition on the System Flash
 117        PARTUUID=00112233-4455-6677-8899-AABBCCDDEEFF/PARTNROFF=1
 118                first partition after the partition with the given UUID
 119        253:0           Device with major 253 and minor 0
 120
 121      Authoritative information can be found in
 122      "Documentation/kernel-parameters.txt".
 123
 124  (*) rw
 125
 126      Start with the root filesystem mounted Read/Write.
 127
 128  The remaining components are all optional:
 129
 130  (*) ip=<ip>::::<host>:<iface>:<cfg>
 131
 132      Configure the network interface. If <cfg> is "off" then <ip> should
 133      specify the IP address for the network device <iface>. <host> provide
 134      the hostname for the device.
 135
 136      If <cfg> is "bootp" or "dhcp", then all of these parameters will be
 137      discovered by consulting a BOOTP or DHCP server.
 138
 139      For example, the following might be used:
 140
 141        ip=192.168.73.12::::frv:eth0:off
 142
 143      This sets the IP address on the VDK motherboard RTL8029 ethernet chipset
 144      (eth0) to be 192.168.73.12, and sets the board's hostname to be "frv".
 145
 146  (*) nfsroot=<server>:<dir>[,v<vers>]
 147
 148      This is mandatory if "root=/dev/nfs" is given as an option. It tells the
 149      kernel the IP address of the NFS server providing its root filesystem,
 150      and the pathname on that server of the filesystem.
 151
 152      The NFS version to use can also be specified. v2 and v3 are supported by
 153      Linux.
 154
 155      For example:
 156
 157        nfsroot=192.168.73.1:/nfsroot-frv
 158
 159  (*) profile=1
 160
 161      Turns on the kernel profiler (accessible through /proc/profile).
 162
 163  (*) console=gdb0
 164
 165      This can be used as an alternative to the "console=ttyS..." listed
 166      above. I tells the kernel to pass the console output to GDB if the
 167      gdbstub is compiled in to the kernel.
 168
 169      If this is used, then the gdbstub passes the text to GDB, which then
 170      simply dumps it to its standard output.
 171
 172  (*) mem=<xxx>M
 173
 174      Normally the kernel will work out how much SDRAM it has by reading the
 175      SDRAM controller registers. That can be overridden with this
 176      option. This allows the kernel to be told that it has <xxx> megabytes of
 177      memory available.
 178
 179  (*) init=<prog> [<arg> [<arg> [<arg> ...]]]
 180
 181      This tells the kernel what program to run initially. By default this is
 182      /sbin/init, but /sbin/sash or /bin/sh are common alternatives.
 183