| 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 |  | 
 | 109 |   (*) root=/dev/<xxxx> | 
 | 110 |  | 
 | 111 |       This specifies the device upon which the root filesystem resides. For | 
 | 112 |       example: | 
 | 113 |  | 
 | 114 | 	/dev/nfs	NFS root filesystem | 
 | 115 | 	/dev/mtdblock3	Fourth RedBoot partition on the System Flash | 
 | 116 |  | 
 | 117 |   (*) rw | 
 | 118 |  | 
 | 119 |       Start with the root filesystem mounted Read/Write. | 
 | 120 |  | 
 | 121 |   The remaining components are all optional: | 
 | 122 |  | 
 | 123 |   (*) ip=<ip>::::<host>:<iface>:<cfg> | 
 | 124 |  | 
 | 125 |       Configure the network interface. If <cfg> is "off" then <ip> should | 
 | 126 |       specify the IP address for the network device <iface>. <host> provide | 
 | 127 |       the hostname for the device. | 
 | 128 |  | 
 | 129 |       If <cfg> is "bootp" or "dhcp", then all of these parameters will be | 
 | 130 |       discovered by consulting a BOOTP or DHCP server. | 
 | 131 |  | 
 | 132 |       For example, the following might be used: | 
 | 133 |  | 
 | 134 | 	ip=192.168.73.12::::frv:eth0:off | 
 | 135 |  | 
 | 136 |       This sets the IP address on the VDK motherboard RTL8029 ethernet chipset | 
 | 137 |       (eth0) to be 192.168.73.12, and sets the board's hostname to be "frv". | 
 | 138 |  | 
 | 139 |   (*) nfsroot=<server>:<dir>[,v<vers>] | 
 | 140 |  | 
 | 141 |       This is mandatory if "root=/dev/nfs" is given as an option. It tells the | 
 | 142 |       kernel the IP address of the NFS server providing its root filesystem, | 
 | 143 |       and the pathname on that server of the filesystem. | 
 | 144 |  | 
 | 145 |       The NFS version to use can also be specified. v2 and v3 are supported by | 
 | 146 |       Linux. | 
 | 147 |  | 
 | 148 |       For example: | 
 | 149 |  | 
 | 150 | 	nfsroot=192.168.73.1:/nfsroot-frv | 
 | 151 |  | 
 | 152 |   (*) profile=1 | 
 | 153 |  | 
 | 154 |       Turns on the kernel profiler (accessible through /proc/profile). | 
 | 155 |  | 
 | 156 |   (*) console=gdb0 | 
 | 157 |  | 
 | 158 |       This can be used as an alternative to the "console=ttyS..." listed | 
 | 159 |       above. I tells the kernel to pass the console output to GDB if the | 
 | 160 |       gdbstub is compiled in to the kernel. | 
 | 161 |  | 
 | 162 |       If this is used, then the gdbstub passes the text to GDB, which then | 
 | 163 |       simply dumps it to its standard output. | 
 | 164 |  | 
 | 165 |   (*) mem=<xxx>M | 
 | 166 |  | 
 | 167 |       Normally the kernel will work out how much SDRAM it has by reading the | 
 | 168 |       SDRAM controller registers. That can be overridden with this | 
 | 169 |       option. This allows the kernel to be told that it has <xxx> megabytes of | 
 | 170 |       memory available. | 
 | 171 |  | 
 | 172 |   (*) init=<prog> [<arg> [<arg> [<arg> ...]]] | 
 | 173 |  | 
 | 174 |       This tells the kernel what program to run initially. By default this is | 
 | 175 |       /sbin/init, but /sbin/sash or /bin/sh are common alternatives. | 
 | 176 |  | 
 | 177 |   (*) vdc=... | 
 | 178 |  | 
 | 179 |       This option configures the MB93493 companion chip visual display | 
| Adrian Bunk | 0868ff7 | 2008-02-03 15:54:28 +0200 | [diff] [blame] | 180 |       driver. Please see Documentation/frv/mb93493/vdc.txt for more | 
| Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 181 |       information. |