[BACK]Return to raspberry_pi.mdwn CVS log [TXT] [DIR] Up to [NetBSD Developer Wiki] / wikisrc / ports / evbarm

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

version 1.78, 2018/10/30 23:09:40 version 1.81, 2018/11/06 01:42:03
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 a MACHINE value, but denote both MACHINE and a MACHINE_ARCH.   The third line is an example (equal to the second in effect).
   
  - ./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 FTP servers
   
Line 136  every few weeks. Line 140  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 163  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 171  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.81

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