linux/meta-raspberrypi.git, branch fix

sdcard_image-rpi.bbclass: Fix when RPI_SDIMG_EXTRA_DEPENDS not defined

2020-08-06T11:27:54+00:00

If the variable is not defined, bitbake will fail: [...] Task 'depends' should be specified in the form 'packagename:task' [...] This is because not expanding the variable leaves an invalid entry. Signed-off-by: Andrei Gherzan

Generalize the naming of the bootfiles deploy directory

2020-08-06T10:00:29+00:00

The raspberry pi 4 variant has a BCM2711 chip, however it still uses the same boot files as the BCM2835 used in previous generations. This change generalizes the naming of the directory generated in the $DEPLOY_DIR to avoid the implication that the files are only meant for the BCM2835. Signed-off-by: Jeff Ithier

docs/extra-build-config.md: document vars to add to boot partition

2020-07-29T10:54:14+00:00

FATPAYLOAD, DEPLOYPAYLOAD and RPI_SDIMG_EXTRA_DEPENDS Signed-off-by: Christopher Clark

sdcard_image-rpi.bbclass: enable extensible inclusion into boot

2020-07-29T10:54:14+00:00

Add DEPLOYPAYLOAD, similar to the existing FATPAYLOAD, to enable adding files to the boot partition from the image deploy directory. Files such as hypervisor binaries may not be present (and in fact unwanted) within the root filesystem, so FATPAYLOAD is not sufficient. DEPLOYPAYLOAD is implemented with support for file renaming from the source file in the image deploy directory to the filename written into the boot image. DEPLOYPAYLOAD is a space-separated list of entries for additions, each of which can optionally be colon-separated: : If the colon separator is omitted, the source deploy directory filename is used as the destination filename. The support for specifying the destination filename is used for including Xen, which produces a machine-specific file in the image deploy directory, and is written to the image partition with its expected filename: xen. Files that are to be included from the image deploy directory will be produced by tasks that the do_image_rpi_sdimg[depends] must list, so enable adding entries to that via a new variable: RPI_SDIMG_EXTRA_DEPENDS. These changes enable retiring a Xen-specific Raspberry Pi SD card bbclass from meta-virtualization and have been tested on the Raspberry Pi 4. Signed-off-by: Christopher Clark

docs/extra-build-config.md: Document CAN_OSCILLATOR variable

2020-07-29T10:52:09+00:00

Add instructions how to use CAN_OSCILLATOR variable and declare support for the Waveshare RS485 CAN HAT. Signed-off-by: Jakub Luzny

rpi-config: Add CAN_OSCILLATOR variable to set mcp2515 crystal frequency

2020-07-29T10:52:09+00:00

Current configuration (16MHz) is made for the PiCAN2 board that uses 16MHz crystal. This setting allows for use of Waveshare RS485 CAN HAT that has 8MHz crystal soldered (although according to Waveshare there is also a 12MHz crystal version of the board). Signed-off-by: Jakub Luzny

u-boot: Move fw_env.config to u-boot append

2020-07-27T14:34:17+00:00

The u-boot-env is provided by u-boot recipe and not by libubootenv, so right recipe to append is the u-boot. Adding the rpi-u-boot-scr in DEPENDS variable is wrong because it is forcing rpi-u-boot-scr to be a dependency, but it'll fail if I have another recipe that provides bootscript, once both recipes provide the same file. The default value of u-boot-default-script is rpi-u-boot-scr, so right way is to use u-boot-default-script and change the PREFERRED_PROVIDER_u-boot-default-script if needed. Signed-off-by: Fabio Berton

docs: Added documentation for Pican2 Duo support

2020-07-23T12:03:23+00:00

Added documentation for ENABLE_DUAL_CAN build configuration and support for Pican2 Duo board. Signed-off-by: Colin McAllister

rpi-config_git: Added ENABLE_DUAL_CAN build configuration

2020-07-23T12:03:23+00:00

Currently ENABLE_CAN adds mcp2525-can0 to the dtoverlay. ENABLE_DUAL_CAN was added to also add mcp2515-can1 to the dtoverlay. This will allow a user to enable dual CAN when using a hat like the PiCAN 2 Duo board. Signed-off-by: Colin McAllister

conf/machine/include/rpi-base.inc: Added can1 interface to bsp

2020-07-23T12:03:23+00:00

The device tree only supports a single CAN interface. This prevents compatiblity with dual-CAN boards like the PiCAN2 Duo. The mcp2515-can1 device tree blob for overlay was added to RPI_KERNEL_DEVICETREE_OVERLAYS in order to support dual-CAN hats. Signed-off-by: Colin McAllister