Diff for /wikisrc/ports/evbarm/raspberry_pi.mdwn between versions 1.78 and 1.85

version 1.78, 2018/10/30 23:09:40 version 1.85, 2018/11/06 02:38:43
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 73  Both will provide rpi.img.gz and rpi_ins Line 75  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
   
 ### NetBSD FTP servers  Consider setting RELEASEMACHINEDIR if you wish to build multiple MACHINE_ARCH values on the same system; see build.sh.
   
 NetBSD provides nightly builds on [nyftp.netbsd.org](http://nyftp.netbsd.org/pub/NetBSD-daily/).  These are equivalent to building yourself.  ### NetBSD autobuild HTTPS/FTP servers
   
  - The 'evbarm-earmv6hf/binary/gzimg/' directory contains an rpi.img file that can be used as a single image for both boards.  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-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 'evbarm-earmv6hf/binary/gzimg/' directory contains an rpi.img file that will run on any of the RPI boards.
  - 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 '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 HEAD/current directory build will be under HEAD/YYYYMMDDHHMMZ/ (for example, http://nyftp.netbsd.org/pub/NetBSD-daily/HEAD/201710202210Z/evbarm-earmv7hf/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/
   
 ## Preparing a uSD card  ## Preparing a uSD card
   
Line 136  every few weeks. Line 139  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 162  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 170  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.
   

Removed from v.1.78  
changed lines
  Added in v.1.85


CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb