Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 1 | ========================= |
| 2 | BOOTING FR-V LINUX KERNEL |
| 3 | ========================= |
| 4 | |
| 5 | ====================== |
| 6 | PROVIDING A FILESYSTEM |
| 7 | ====================== |
| 8 | |
| 9 | First of all, a root filesystem must be made available. This can be done in |
| 10 | one 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 | ======================== |
| 26 | LOADING THE KERNEL IMAGE |
| 27 | ======================== |
| 28 | |
| 29 | The kernel will need to be loaded into RAM by RedBoot (or by some alternative |
| 30 | boot loader) before it can be run. The kernel image (arch/frv/boot/Image) may |
| 31 | be 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 | ================== |
| 67 | BOOTING THE KERNEL |
| 68 | ================== |
| 69 | |
| 70 | Boot the image with the following RedBoot command: |
| 71 | |
| 72 | exec -c "<CMDLINE>" 0x00100000 |
| 73 | |
| 74 | For example: |
| 75 | |
| 76 | exec -c "console=ttySM0,115200 ip=:::::dhcp root=/dev/mtdblock2 rw" |
| 77 | |
| 78 | This will start the kernel running. Note that if the GDB-stub is compiled in, |
| 79 | then the kernel will immediately wait for GDB to connect over serial before |
| 80 | doing anything else. See the section on kernel debugging with GDB. |
| 81 | |
| 82 | The kernel command line <CMDLINE> tells the kernel where its console is and |
| 83 | how to find its root filesystem. This is made up of the following components, |
| 84 | separated 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 | |
Will Drewry | f2d34fd9 | 2011-08-03 16:21:08 -0700 | [diff] [blame] | 109 | (*) root=<xxxx> |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 110 | |
Will Drewry | f2d34fd9 | 2011-08-03 16:21:08 -0700 | [diff] [blame] | 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: |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 114 | |
| 115 | /dev/nfs NFS root filesystem |
| 116 | /dev/mtdblock3 Fourth RedBoot partition on the System Flash |
Will Drewry | f2d34fd9 | 2011-08-03 16:21:08 -0700 | [diff] [blame] | 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 |
Mauro Carvalho Chehab | 8c27ceff3 | 2016-10-18 10:12:27 -0200 | [diff] [blame] | 122 | "Documentation/admin-guide/kernel-parameters.rst". |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 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. |