ZeroPhone DeviceTree configuration

From ZeroPhone
Jump to: navigation, search

Device Tree parameters are parameters you need to add to /boot/config.txt to enable various Raspberry Pi functions that ZeroPhone uses.

ZeroPhone Gamma

MCP23017 overlay

This overlay helps us make use of back board MCP23017 expander to control ZeroPhone power management and other functions. It loads a Linux kernel driver so that the MCP23017 GPIOs are exposed as sysfs GPIOs, which makes it slightly easier to work with them.


Disabling HAT EEPROM scan on boot

ZeroPhone doesn't allow for Pi HATs, and ID_SD and ID_SC lines are used for ESP8266 reset and MCP23017 INT lines. However, the GPU scans for EEPROM (to avoid toggling ESP8266 reset and MCP23017 INT line)


Audio parameters


GPU memory split

If you plan to use camera or start X, you'll want to increase the GPU memory to at least 128MB. Otherwise, you'll probably want to assign more RAM to Linux.


USB drivers

Pi Zero uses the USB drivers that allow for USB device (gadget mode) functionality. However, the USB host-only (OTG mode) drivers might be more stable and performant. Given that ZeroPhone for now doesn't even have a device mode port (only a host port), you'll likely want to explicitly use the OTG drivers


Enabling UART

The Pi Zero UART is used by the GSM modem, so we need to enable it.


Pi Zero-specific parameters

Enabling SDIO

#dtoverlay=pi3-miniuart-bt #Zero W-specific overlay has to be commented out

Pi Zero W-specific parameters

On Pi Zero W, the UART mapped onto GPIOs is the UART that has problems with maintaining constant baudrate by itself and is therefore problematic to use with the GSM modem. So, we need to map the stable UART back to GPIO header - and map the not-so-stable UART to Bluetooth to at least have a chance of Bluetooth still working.

#dtoverlay=sdio,poll_once=off #Non-Zero-W-specific overlay has to be commented out

For some reason, I haven't been able to make Bluetooth work with this configuration - it might need remapping somewhere else, so that's yet to be investigated (maybe setting the arm_freq parameter to constant speed is necessary).