|
version 1.78, 2018/10/30 23:09:40
|
version 1.86, 2018/11/06 03:13:59
|
|
Line 43 Initial, limited, Raspberry Pi support w
|
Line 43 Initial, limited, Raspberry Pi support w
|
| # CPU types |
# CPU types |
| |
|
| - Raspberry Pi 1 uses "earmv6hf". |
- Raspberry Pi 1 uses "earmv6hf". |
| |
- Raspberry Pi 0 uses "\todo". |
| - Raspberry Pi 2 uses "earmv7hf". |
- Raspberry Pi 2 uses "earmv7hf". |
| - Raspberry Pi 3 uses "earmv7hf". |
- Raspberry Pi 3 uses "earmv7hf". |
| |
- Raspberry Pi 0W uses "\todo". |
| |
|
| Note that one can run earmv6hf code on the 2 and 3. See also |
Note that one can run earmv6hf code on the 2 and 3. See also |
| [[NetBSD/aarch64|aarch64]] for running the Pi 2/3 in 64-bit mode. |
[[NetBSD/aarch64|aarch64]] for running the Pi 2/3 in 64-bit mode. |
|
Line 53 Note that one can run earmv6hf code on t
|
Line 55 Note that one can run earmv6hf code on t
|
| |
|
| ## SD card structure |
## SD card structure |
| |
|
| The Raspberry Pi looks for firmware and kernel.img on the first FAT32 partition of the uSD card. A separate kernel (kernel7.img) is used on RPI2 and RPI3. |
The Raspberry Pi looks for firmware and kernel.img on the first FAT32 MBR partition of the uSD card. A separate kernel (kernel7.img) is used on RPI2 and RPI3. |
| |
The NetBSD kernel will then find NetBSD MBR partition and within that the root disklabel partition, and use that FFS partition as the root filesystem. |
| |
|
| The NetBSD kernel will then use the FFS partition as the root filesystem. |
A 2 GB card is the smallest workable size, and the installation image will fit. After the first boot, the system resizes the NetBSD root partition to fill the card. Note that swap is after /boot and before /, and not contained in the NetBSD fdisk partition. However, if you don't try to change the partition structure, this should not cause you any trouble. |
| |
|
| A 2 GB card is the smallest workable size. The NetBSD filesystem will be expanded to fit. |
|
| |
|
| ## Choosing a version |
## Choosing a version |
| |
|
|
Line 73 Both will provide rpi.img.gz and rpi_ins
|
Line 74 Both will provide rpi.img.gz and rpi_ins
|
| |
|
| ### Building yourself |
### Building yourself |
| |
|
| Getting sources and building a release with build.sh is not special for evbarm. Pick a CPU type alias and pass it to build.sh with -m. Examples (the first two are equivalent): |
Getting sources and building a release with build.sh is not special for evbarm. However, the evbarm port has a very large number of CPU types, compared to i386 and amd64 which have one. The standard approach is to use -m to define MACHINE and -a to define MACHINE_ARCH. build.sh supports aliases that can be passed as a MACHINE value, but denote both MACHINE and a MACHINE_ARCH. The third line uses an alias and is equal to the second in effect, for RPI2/3. |
| |
|
| - ./build.sh -m earmv6hf -u release |
|
| - ./build.sh -m evbarm -a earmv6hf -u release |
- ./build.sh -m evbarm -a earmv6hf -u release |
| - ./build.sh -m evbarm -a earmv7hf -u release |
- ./build.sh -m evbarm -a earmv7hf -u release |
| |
- ./build.sh -m earmv7hf-el -u release |
| |
|
| |
Consider setting RELEASEMACHINEDIR if you wish to build multiple MACHINE_ARCH values on the same system; see build.sh. |
| |
|
| ### NetBSD FTP servers |
### NetBSD autobuild HTTPS/FTP servers |
| |
|
| NetBSD provides nightly builds on [nyftp.netbsd.org](http://nyftp.netbsd.org/pub/NetBSD-daily/). These are equivalent to building yourself. |
NetBSD provides nightly builds on [nyftp.netbsd.org](https://nyftp.netbsd.org/pub/NetBSD-daily/). These are equivalent to building yourself. The next directory level is the branch being built (netbsd-7, netbsd-8, HEAD, and more), plus optionally things like compiler type. It is followed by date/time, e.g. "HEAD/201811051650Z"; once a build is complete the symlink "latest" is adjusted to point to it. The next level is "${MACHINE}-${MACHINE_ARCH}", e.g. "evbarm-earmv7hf", and multiple combinations are provided. |
| |
|
| - The 'evbarm-earmv6hf/binary/gzimg/' directory contains an rpi.img file that can be used as a single image for both boards. |
- The 'evbarm-earmv6hf/binary/gzimg/' directory contains an rpi.img file that will run on any of the RPI boards. |
| - The 'evbarm-earmv7hf/binary/gzimg/' directory contains an armv7.img file that is optimized for Raspberry Pi 2/3. |
- The 'evbarm-earmv7hf/binary/gzimg/' directory contains an armv7.img file that uses the armv7 instruction set, and thus can run only on the Raspberry Pi 2/3, but is also faster than rpi.img. |
| - The old stable build directory will be under netbsd-7/YYYYMMDDHHMMZ/ (for example, http://nyftp.netbsd.org/pub/NetBSD-daily/netbsd-7/201710201440Z/evbarm-earmv6hf/binary/gzimg) |
|
| - The stable build directory will be under netbsd-8/YYYYMMDDHHMMZ/ (for example, http://nyftp.netbsd.org/pub/NetBSD-daily/netbsd-8/201710211010Z/evbarm-earmv6hf/binary/gzimg/) |
An example URL, arguably the standard approach for beginners, is https://nyftp.netbsd.org/pub/NetBSD-daily/netbsd-8/latest/evbarm-earmv7hf/binary/gzimg/ |
| - The HEAD/current directory build will be under HEAD/YYYYMMDDHHMMZ/ (for example, http://nyftp.netbsd.org/pub/NetBSD-daily/HEAD/201710202210Z/evbarm-earmv7hf/binary/gzimg/) |
|
| |
|
| ## Preparing a uSD card |
## Preparing a uSD card |
| |
|
|
Line 136 every few weeks.
|
Line 138 every few weeks.
|
| |
|
| ## vcgencmd |
## vcgencmd |
| |
|
| The program vcgencmd can be found in pkgsrc/misc/raspberrypi-userland. |
The program vcgencmd, referenced in the boot section, can be found in pkgsrc/misc/raspberrypi-userland. |
| |
|
| |
|
| ## Updating the kernel |
## Updating the kernel |
| |
|
|
Line 160 TODO: Explain where the firmware is in t
|
Line 161 TODO: Explain where the firmware is in t
|
| |
|
| ## Booting |
## Booting |
| |
|
| The device boots by finding a file "bootcode.bin". The primary location is a FAT32 partition on the uSD card, and an additional location is on a USB drive. See the [[upstream documentation on booting]](https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/) and read all the subpages. |
The device boots by finding a file "bootcode.bin". The primary location is a FAT32 partition on the uSD card, and an additional location is on a USB drive. See the [upstream documentation on booting](https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/) and read all the subpages. |
| |
|
| The standard approach is to use a uSD card, with a fdisk partition table containing a FAT32 partition marked active, and a NetBSD partition. The NetBSD partition will then contain a disklabel, pointing to an FFS partition (a), a swap paritiion (b) and the FAT32 boot partition mounted as /boot (e). The file /boot/cmdline.txt has a line to set the root partition. |
The standard approach is to use a uSD card, with a fdisk partition table containing a FAT32 partition marked active, and a NetBSD partition. The NetBSD partition will then contain a disklabel, pointing to an FFS partition (a), a swap paritiion (b) and the FAT32 boot partition mounted as /boot (e). The file /boot/cmdline.txt has a line to set the root partition. |
| |
|
|
Line 168 One wrinkle in the standard approach is
|
Line 169 One wrinkle in the standard approach is
|
| |
|
| An alternate approach is to have the boot FAT32 partition as above, but to have the entire system including root on an external disk. This is configured by changing root=ld0a to root=sd0a or root=dk0 (depending on disklabel/GPT). Besides greater space, part of the point is to avoid writing to the uSD card. |
An alternate approach is to have the boot FAT32 partition as above, but to have the entire system including root on an external disk. This is configured by changing root=ld0a to root=sd0a or root=dk0 (depending on disklabel/GPT). Besides greater space, part of the point is to avoid writing to the uSD card. |
| |
|
| A third approach, workable on the Pi 3 only, is to configure USB host booting (already enableed on the 3+; see the upstream documentation) and have the boot partition also on the external device. In this case the external device must have an MBR because the hardware's first-stage boot does not have GPT support. \todo Explain if this has been observed to work. |
A third approach, workable on the Pi 3 only, is to configure USB host booting (already enableed on the 3+; see the upstream documentation) and have the boot partition also on the external device. In this case the external device must have an MBR because the hardware's first-stage boot does not have GPT support. In theory the [procedure to program USB host boot mode](https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd.md) will function on a NetBSD system because the programming is done by bootcode.bin. |
| \todo In theory the [[procedure to program USB host boot mode]](https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd.md) will function on a NetBSD system because the programming is done by bootcode.bin. |
\todo Confirm that putting program_usb_boot_mode=1 in config.txt and booting works to program the OTP bit. Confirm that one can then boot NetBSD from external USB. |
| |
|
| \todo Explain USB enumeration and how to ensure that the correct boot and root devices are found if one has e.g. a small SSD for the system and a big disk. |
\todo Explain USB enumeration and how to ensure that the correct boot and root devices are found if one has e.g. a small SSD for the system and a big disk. |
| |
|
![[BACK]](/icons/back.gif){kind=icon}
Return to raspberry_pi.mdwn CVS log ![[TXT]](/icons/text.gif){kind=icon}
![[DIR]](/icons/dir.gif){kind=icon}
Up to [NetBSD Developer Wiki] / wikisrc / ports / evbarm