--- wikisrc/ports/evbarm/raspberry_pi.mdwn 2018/10/30 23:09:40 1.78 +++ wikisrc/ports/evbarm/raspberry_pi.mdwn 2018/11/06 13:27:25 1.87 @@ -43,8 +43,10 @@ Initial, limited, Raspberry Pi support w # CPU types - Raspberry Pi 1 uses "earmv6hf". + - Raspberry Pi 0 uses "\todo". - Raspberry Pi 2 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 [[NetBSD/aarch64|aarch64]] for running the Pi 2/3 in 64-bit mode. @@ -53,11 +55,10 @@ Note that one can run earmv6hf code on t ## 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. The NetBSD filesystem will be expanded to fit. +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. ## Choosing a version @@ -73,21 +74,22 @@ Both will provide rpi.img.gz and rpi_ins ### 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 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-earmv7hf/binary/gzimg/' directory contains an armv7.img file that is optimized for Raspberry Pi 2/3. - - 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/) - - 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/) + - 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 uses the armv7 instruction set, and thus can run only on the Raspberry Pi 2/3, but is also faster than rpi.img. + +An example URL, arguably the standard approach for beginners, is https://nyftp.netbsd.org/pub/NetBSD-daily/netbsd-8/latest/evbarm-earmv7hf/binary/gzimg/ ## Preparing a uSD card @@ -136,8 +138,7 @@ every few weeks. ## 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 @@ -156,11 +157,11 @@ The program vcgencmd can be found in pkg A section below describes the process of updating NetBSD's copy of the firmware from upstream, with testing, by NetBSD developers. This section is about updating a system's firmware from the firmware in a version of NetBSD. -TODO: Explain where the firmware is in the source tree, and if it is in the installed system image (such as /usr/mdec). Explain any particular cautions. +\todo Explain where the firmware is in the source tree, and if it is in the installed system image (such as /usr/mdec). Explain any particular cautions. ## 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. @@ -168,8 +169,8 @@ 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. -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. -\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. +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 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.