nerves-project / nerves_system_rpi4 Goto Github PK

View Code? Open in Web Editor NEW

82.0 8.0 39.0 530 KB

Base Nerves system configuration for the Raspberry Pi 4

License: Apache License 2.0

Shell 11.14% Elixir 88.86%

nerves_system_rpi4's Introduction

Raspberry Pi 4 Model B (64-bit)

This is the base Nerves System configuration for the Raspberry Pi 4 Model B.

^{Michael Henzler / Wikimedia Commons / CC BY-SA
4.0}

Feature	Description
CPU	1.5 GHz quad-core Cortex-A72 (64-bit mode)
Memory	1 GB, 2 GB, 4 GB DRAM
Storage	MicroSD
Linux kernel	6.1 w/ Raspberry Pi patches
IEx terminal	HDMI and USB keyboard (can be changed to UART)
GPIO, I2C, SPI	Yes - Elixir Circuits
ADC	No
PWM	Yes, but no Elixir support
UART	1 available - `ttyS0`
Display	HDMI or 7" RPi Touchscreen
Camera	Official RPi Cameras (libcamera)
Ethernet	Yes
WiFi	Yes - VintageNet
Bluetooth	Untested
Audio	HDMI/Stereo out

Using

The most common way of using this Nerves System is create a project with mix nerves.new and to export MIX_TARGET=rpi4. See the Getting started guide for more information.

If you need custom modifications to this system for your device, clone this repository and update as described in Making custom systems.

Supported WiFi devices

The base image includes drivers for the onboard Raspberry Pi 4 wifi module (brcmfmac driver).

Camera

This system supports the official Raspberry Pi camera modules via libcamera. The libcamera applications are included so it's possible to replicate many of the examples in the official Raspberry Pi Camera Documentation.

Here's an example commandline to run:

cmd("libcamera-jpeg -n -v -o /data/test.jpeg")

On success, you'll get an image in /data that you can copy off with sftp.

Since libcamera is being used instead of MMAL, the Elixir picam library won't work.

Audio

The Raspberry Pi has many options for audio output. This system supports the HDMI and stereo audio jack output. The Linux ALSA drivers are used for audio output.

The general Raspberry Pi audio documentation mostly applies to Nerves. For example, to force audio out the HDMI port, run:

cmd("amixer cset numid=3 2")

Change the last argument to amixer to 1 to output to the stereo output jack.

Provisioning devices

This system supports storing provisioning information in a small key-value store outside of any filesystem. Provisioning is an optional step and reasonable defaults are provided if this is missing.

Provisioning information can be queried using the Nerves.Runtime KV store's Nerves.Runtime.KV.get/1 function.

Keys used by this system are:

Key	Example Value	Description
`nerves_serial_number`	`"12345678"`	By default, this string is used to create unique hostnames and Erlang node names. If unset, it defaults to part of the Raspberry Pi's device ID.

The normal procedure would be to set these keys once in manufacturing or before deployment and then leave them alone.

For example, to provision a serial number on a running device, run the following and reboot:

iex> cmd("fw_setenv nerves_serial_number 12345678")

This system supports setting the serial number offline. To do this, set the NERVES_SERIAL_NUMBER environment variable when burning the firmware. If you're programming MicroSD cards using fwup, the commandline is:

sudo NERVES_SERIAL_NUMBER=12345678 fwup path_to_firmware.fw

Serial numbers are stored on the MicroSD card so if the MicroSD card is replaced, the serial number will need to be reprogrammed. The numbers are stored in a U-boot environment block. This is a special region that is separate from the application partition so reformatting the application partition will not lose the serial number or any other data stored in this block.

Additional key value pairs can be provisioned by overriding the default provisioning.conf file location by setting the environment variable NERVES_PROVISIONING=/path/to/provisioning.conf. The default provisioning.conf will set the nerves_serial_number, if you override the location to this file, you will be responsible for setting this yourself.

Linux kernel and RPi firmware/userland

There's a subtle coupling between the nerves_system_br version and the Linux kernel version used here. nerves_system_br provides the versions of rpi-userland and rpi-firmware that get installed. I prefer to match them to the Linux kernel to avoid any issues. Unfortunately, none of these are tagged by the Raspberry Pi Foundation so I either attempt to match what's in Raspbian or take versions of the repositories that have similar commit times.

Linux kernel configuration

The Linux kernel compiled for Nerves is a stripped down version of the default Raspberry Pi Linux kernel. This is done to remove unnecessary features, select some Nerves-specific features like F2FS and SquashFS support, and to save space.

nerves_system_rpi4's People

Contributors

Stargazers

Watchers

nerves_system_rpi4's Issues

rpi3 to rpi4 project upgrade failure

Environment

Elixir version (elixir -v):

Erlang/OTP 22 [erts-10.4.3] [source] [64-bit] [smp:2:2] [ds:2:2:10] [async-threads:1] [hipe]

Elixir 1.9.0 (compiled with Erlang/OTP 22)

Nerves environment: (mix nerves.env --info)
|nerves_bootstrap| Environment Package List

Pkg: nerves_system_br
Vsn: 1.8.5
Type: system_platform
BuildRunner: {nil, []}

Pkg: nerves_system_rpi4
Vsn: 1.8.2
Type: system
BuildRunner: {Nerves.Artifact.BuildRunners.Local, []}

Pkg: nerves_toolchain_arm_unknown_linux_gnueabihf
Vsn: 1.2.0
Type: toolchain
BuildRunner: {Nerves.Artifact.BuildRunners.Local, []}

Pkg: nerves_toolchain_ctng
Vsn: 1.6.0
Type: toolchain_platform
BuildRunner: {nil, []}

|nerves_bootstrap| Loadpaths Start

Nerves environment
MIX_TARGET: rpi4
MIX_ENV: dev

|nerves_bootstrap| Environment Variable List
target: rpi4
toolchain: /home/jhs/.nerves/artifacts/nerves_toolchain_arm_unknown_linux_gnueabihf-linux_x86_64-1.2.0
system: /home/jhs/.nerves/artifacts/nerves_system_rpi4-portable-1.8.2
app: /home/jhs/src/RasPi3BPlus/Blinkers/Nerves/fb2

|nerves_bootstrap| Loadpaths End

Additional information about your host, target hardware or environment that
may help

Just taking a simple project that makes working firmware for rpi3 and changing target to rpi4 with this git diff

Current behavior

Include errors, stacktraces, screenshots or code that may help us reproduce the
issue.

Expected behavior

Nice firmware file that I can try out in my shiny new RPi4 :)

Enable Additional UART of Raspberry Pi 4B

I am trying to enable Additional UART(s) on Raspberry PI, as stated in the specs the Pi4 has 6UARTs but I am only able to access UART0 named ttsy0, I tried modifying the config file but that didn't help.

Is there a way we can use additional UART(s)

Camera Support

Environment

Elixir version:

Erlang/OTP 23 [erts-11.0.2] [source] [64-bit] [smp:12:12] [ds:12:12:10] [async-threads:1] [hipe]
Elixir 1.10.4 (compiled with Erlang/OTP 23)

Nerves environment:

|nerves_bootstrap| Environment Package List

  Pkg:         nerves_system_br
  Vsn:         1.12.0
  Type:        system_platform
  BuildRunner: {nil, []}

  Pkg:         nerves_system_rpi4
  Vsn:         1.12.1
  Type:        system
  BuildRunner: {Nerves.Artifact.BuildRunners.Docker, []}

  Pkg:         nerves_toolchain_ctng
  Vsn:         1.7.2
  Type:        toolchain_platform
  BuildRunner: {nil, []}

  Pkg:         nerves_toolchain_arm_unknown_linux_gnueabihf
  Vsn:         1.3.2
  Type:        toolchain
  BuildRunner: {Nerves.Artifact.BuildRunners.Local, []}

Additional information about your host, target hardware or environment that
may help

Current behavior

I'm building an application on top of Picam and it works (e.g. I can read from an attached camera) on a RPI3, but on a RPI4 the camera hardware is non-functional / not-detected.

Expected behavior

The README says that cameras are supported, has that been verified? I've got a new RPI4 incoming to see if this is reproducible on a second board.

Nerves Hub connection fails after upgrading to 1.19.0

Environment

Elixir version (elixir -v):

Erlang/OTP 25 [erts-13.0] [source] [64-bit] [smp:12:12] [ds:12:12:10] [async-threads:1] [jit:ns]

Elixir 1.13.4 (compiled with Erlang/OTP 25)

Nerves environment: (mix nerves.env --info)

|nerves_bootstrap| Environment Package List

  Pkg:         nerves_toolchain_ctng
  Vsn:         1.8.5
  Type:        toolchain_platform
  BuildRunner: {nil, []}

  Pkg:         nerves_system_br
  Vsn:         1.19.0
  Type:        system_platform
  BuildRunner: {nil, []}

  Pkg:         nerves_system_rpi4
  Vsn:         1.19.0
  Type:        system
  BuildRunner: {Nerves.Artifact.BuildRunners.Docker, [make_args: ["source", "all", "legal-info"]]}

  Pkg:         nerves_toolchain_aarch64_nerves_linux_gnu
  Vsn:         1.5.0
  Type:        toolchain
  BuildRunner: {Nerves.Artifact.BuildRunners.Local, []}

|nerves_bootstrap| Loadpaths Start


Nerves environment
  MIX_TARGET:   ft_access
  MIX_ENV:      prod

|nerves_bootstrap| Environment Variable List
  target:     ft_access
  toolchain:  /Users/tonnenpinguin/.nerves/artifacts/nerves_toolchain_aarch64_nerves_linux_gnu-darwin_x86_64-1.5.0
  system:     /Users/tonnenpinguin/.nerves/artifacts/nerves_system_rpi4-portable-1.19.0
  app:        .

|nerves_bootstrap| Loadpaths End

Additional information about your host, target hardware or environment that
may help

Current behavior

After upgrading from 1.18.4 devices fail to connect to our self-hosted nerves hub instance (running on OTP 24) with the following error

12:27:21.835 [error] mfa=:gen_server.error_info/8 line=1399 GenServer #PID<0.2705.0> terminating
** (CaseClauseError) no case clause matching: {:error, %Mint.HTTP1{buffer: "", host: "device.nerves-hub.[...]", mode: :active, port: 443, private: %{extensions: [], scheme: :wss, sec_websocket_key: "SEC_WEBSOCKET_KEY"}, proxy_headers: [], request: %{body: nil, connection: [], content_length: nil, data_buffer: [], headers_buffer: [], method: "GET", ref: #Reference<0.578604679.268435457.124554>, state: :status, status: nil, transfer_encoding: [], version: nil}, requests: {[], []}, scheme_as_string: "https", socket: {:sslsocket, {:gen_tcp, #Port<0.69>, :tls_connection, :undefined}, [#PID<0.2708.0>, #PID<0.2707.0>]}, state: :closed, streaming_request: nil, transport: Mint.Core.Transport.SSL}, %Mint.TransportError{reason: {:tls_alert, {:certificate_required, 'TLS client: In state connection received SERVER ALERT: Fatal - Certificate required\n'}}}, []}
    (slipstream 1.0.0) lib/slipstream/connection/pipeline.ex:140: Slipstream.Connection.Pipeline.decode_message/1
    (slipstream 1.0.0) lib/slipstream/connection/pipeline.ex:34: anonymous fn/1 in Slipstream.Connection.Pipeline.handle/2
    (slipstream 1.0.0) lib/slipstream/connection/telemetry.ex:29: anonymous fn/2 in Slipstream.Connection.Telemetry.span/2
    (telemetry 1.1.0) /Users/tonnenpinguin/src/cardreader/deps/telemetry/src/telemetry.erl:320: :telemetry.span/3
    (slipstream 1.0.0) lib/slipstream/connection/telemetry.ex:25: Slipstream.Connection.Telemetry.span/2
    (stdlib 4.0) gen_server.erl:1120: :gen_server.try_dispatch/4
    (stdlib 4.0) gen_server.erl:1197: :gen_server.handle_msg/6
    (stdlib 4.0) proc_lib.erl:240: :proc_lib.init_p_do_apply/3
Last message: {:ssl_error, {:sslsocket, {:gen_tcp, #Port<0.69>, :tls_connection, :undefined}, [#PID<0.2708.0>, #PID<0.2707.0>]}, {:tls_alert, {:certificate_required, 'TLS client: In state connection received SERVER ALERT: Fatal - Certificate required\n'}}}

No changes have been made on the server side, and after reverting everything works as expected again.

On Slack @LostKobrakai suggested this might have something to do with the changes made to ssl in OTP 25.
After some further digging we found out that the underlying problem isn't triggered when the server is running OTP23.

This is very problematic, since the way slipstream works in all but the latest version (1.0.1, released yesterday) we actually do not recover from a failed connection attempt, meaning devices might not be able to connect to NH until they are rebooted (and the server is set to run on OTP 23).

To be clear the problem doesn't seem to be specific to nerves_system_rpi4, but rather a general interop issue between OTP 25 clients and OTP 24/OTP 25 server versions, but I wanted to raise a flag anyway

Expected behavior

For devices to connect to nerves hub :)

Switch to 64-bit

We're considering switching nerves_system_rpi4 from 32-bit Linux to 64-bit Linux.

Previous arguments to stay with 32-bit Linux centered around 1. that's what Raspbian does and how much work is there in supporting a non-mainstream configuration, 2. would anyone notice a change in performance, 3. what's the point since Nerves disables swap and all DRAM can be addressed with 32-bit Linux.

We're revisiting that decision. Here are some reasons:

The new BeamJIT looks like it will support 64-bit ARM well before 32-bit ARM. Currently, Nerves doesn't have an official 64-bit ARM target so switching to 64-bit ARM would enable Nerves users to try out the BeamJIT.
Raspberry Pi 4's can have 8 GB DRAM. Switching to 64-bits would allow the BEAM to use it.
Non-Raspbian distros and some Nerves users have been using 64-bit Linux on RPi4 for over a year, so 64-bit on RPi4 isn't bleeding edge.

It doesn't look like the switch from 32-bit to 64-bits will impact existing RPi4 Nerves users. If anyone knows of issues, please let us know.

Support VL805 firmware updates

The Raspberry Pi firmware is stored on an EEPROM so it needs to be updated periodically. This is inconvenient right now with Nerves. It would be nice if there were an easy way to do this.

Information is at https://github.com/raspberrypi/rpi-eeprom.

USB Serial Device not being recognised/loaded

Environment

Elixir version (elixir -v): Elixir 1.12.3 (compiled with Erlang/OTP 24)
Nerves environment: (mix nerves.env --info)

|nerves_bootstrap| Environment Package List

  Pkg:         nerves_toolchain_ctng
  Vsn:         1.8.5
  Type:        toolchain_platform
  BuildRunner: {nil, []}

  Pkg:         nerves_toolchain_aarch64_nerves_linux_gnu
  Vsn:         1.5.0
  Type:        toolchain
  BuildRunner: {Nerves.Artifact.BuildRunners.Local, []}

  Pkg:         nerves_system_br
  Vsn:         1.18.4
  Type:        system_platform
  BuildRunner: {nil, []}

  Pkg:         nerves_system_rpi4
  Vsn:         1.18.2
  Type:        system
  BuildRunner: {Nerves.Artifact.BuildRunners.Docker, [make_args: ["source", "all", "legal-info"]]}

|nerves_bootstrap| Loadpaths Start


Nerves environment
  MIX_TARGET:   rpi4
  MIX_ENV:      dev

|nerves_bootstrap| Environment Variable List
  target:     rpi4
  toolchain:  /Users/*/.nerves/artifacts/nerves_toolchain_aarch64_nerves_linux_gnu-darwin_arm-1.5.0
  system:     /Users/*/.nerves/artifacts/nerves_system_rpi4-portable-1.18.2
  app:        .

|nerves_bootstrap| Loadpaths End

Additional information about your host, target hardware or environment that
may help

Building on MacOS 12.1 on M1, target is a Pi4.

Current behavior

I have a Plugable USB-RS232 adaptor connected to the Pi on USB, it contains a Prolific PL2303 chip. It is detected as follows from dmesg:

[ 4032.061149] usb 1-1.1: new full-speed USB device number 5 using xhci_hcd
[ 4032.165601] usb 1-1.1: New USB device found, idVendor=067b, idProduct=2303, bcdDevice= 4.00
[ 4032.165616] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 4032.165625] usb 1-1.1: Product: USB-Serial Controller D
[ 4032.165635] usb 1-1.1: Manufacturer: Prolific Technology Inc.

However it is not mapped to a serial port as I would expect. If I do the same on Raspbian I get the following additional lines when attaching it to the system:

[ 1439.746797] pl2303 1-1.3:1.0: pl2303 converter detected
[ 1439.763784] usb 1-1.3: pl2303 converter now attached to ttyUSB0

I'm pretty new to Nerves and not 100% sure on all the moving parts, but the driver for this I think it included in the USB_SERIAL module which is compiled as part of the image?

Expected behavior

The device to be detected and then mapped to a serial port on the device.

Boot hangs.

Environment

Host:

Mac 10.14 Mojave

Elixir version (elixir -v):

Erlang/OTP 22 [erts-10.5.1] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1] [hipe]
Elixir 1.9.1 (compiled with Erlang/OTP 22)

(via asdf tool)

Nerves environment: (mix nerves.env --info):

|nerves_bootstrap| Environment Package List

  Pkg:         nerves_system_br
  Vsn:         1.9.2
  Type:        system_platform
  BuildRunner: {nil, []}

  Pkg:         nerves_system_rpi4
  Vsn:         1.9.0
  Type:        system
  BuildRunner: {Nerves.Artifact.BuildRunners.Docker, []}

  Pkg:         nerves_toolchain_arm_unknown_linux_gnueabihf
  Vsn:         1.2.0
  Type:        toolchain
  BuildRunner: {Nerves.Artifact.BuildRunners.Local, []}

  Pkg:         nerves_toolchain_ctng
  Vsn:         1.6.0
  Type:        toolchain_platform
  BuildRunner: {nil, []}

|nerves_bootstrap| Loadpaths Start


Nerves environment
  MIX_TARGET:   rpi4
  MIX_ENV:      dev

|nerves_bootstrap| Environment Variable List
  target:     rpi4
  toolchain:  /Users/nicolafiorillo/.nerves/artifacts/nerves_toolchain_arm_unknown_linux_gnueabihf-darwin_x86_64-1.2.0
  system:     /Users/nicolafiorillo/.nerves/artifacts/nerves_system_rpi4-portable-1.9.0
  app:        /Users/nicolafiorillo/Projects/nerves/hello_nerves

|nerves_bootstrap| Loadpaths End

Current behavior

I'm new on both Raspberry Pi and Nerves. I followed documentation from https://hexdocs.pm/nerves/installation.html and https://hexdocs.pm/nerves/getting-started.html#creating-a-new-nerves-app creating a clean app (adding no customization) using

export MIX_TARGET=rpi4
mix nerves.new hello_nerves
cd hello_nerves/
mix do deps.get, firmware, firmware.burn

Build and burn seem end correctly but RPI4 boot hangs as in screenshot:

Expected behavior

iex console

Thanks for help!

Archive size quadrupled from 1.15 to 1.16 release

Hello there,

I noticed that the size of the nerves artifact went from 237 MB to 985MB from release 1.15.1 to 1.16. Is there any reason for this? Compared to other nerves systems this seems quite high.

Thanks!

Increasing uboot size

Current behavior

I couldn't change to any value in fwup.conf for "UBOOT_ENV_COUNT" that works

Expected behavior

I should be able to increase uboot size!

[bug / v1.11.0] Erlang VM not started

Environment

Elixir version (elixir -v):

Erlang/OTP 22 [erts-10.5.3] [source] [64-bit] [smp:2:2] [ds:2:2:10] [async-threads:1] [hipe]
Elixir 1.9.2 (compiled with Erlang/OTP 22)

Nerves environment: (mix nerves.env --info)

|nerves_bootstrap| Environment Package List

  Pkg:         nerves_system_rpi4
  Vsn:         1.11.0
  Type:        system
  BuildRunner: {Nerves.Artifact.BuildRunners.Local, []}

  Pkg:         nerves_toolchain_arm_unknown_linux_gnueabihf
  Vsn:         1.3.1
  Type:        toolchain
  BuildRunner: {Nerves.Artifact.BuildRunners.Local, []}

  Pkg:         nerves_system_br
  Vsn:         1.11.0
  Type:        system_platform
  BuildRunner: {nil, []}

  Pkg:         nerves_toolchain_ctng
  Vsn:         1.7.1
  Type:        toolchain_platform
  BuildRunner: {nil, []}

|nerves_bootstrap| Loadpaths Start


Nerves environment
  MIX_TARGET:   rpi4
  MIX_ENV:      prod

|nerves_bootstrap| Environment Variable List
  target:     rpi4
  toolchain:  /home/jhs/.nerves/artifacts/nerves_toolchain_arm_unknown_linux_gnueabihf-linux_x86_64-1.3.1
  system:     /home/jhs/.nerves/artifacts/nerves_system_rpi4-portable-1.11.0
  app:        /home/jhs/src/jsimmonds2/RasPi3BPlus/Blinkers/Nerves/fb2

|nerves_bootstrap| Loadpaths End

Additional information about your host, target hardware or environment that
may help

nerves_system_rpi4 v1.10.2 worked correctly, repeatably.

Current behavior

Boot hangs here :

Expected behavior

Erlang VM is started successfully and base app runs.

Raspberry Pi Global Shutter Camera

Hey team! Been a while :) Was wondering if there are any plans to add support for the new-ish Global Shutter camera?

Looks like we would need to add the imx296 overlay. I'm not positive where those are sourced from.

Can't connect 5GHz WiFi when using 1.13.1

Environment

Elixir version (elixir -v): Elixir 1.11.2 (compiled with Erlang/OTP 23)
Nerves environment: (mix nerves.env --info)

|nerves_bootstrap| Environment Package List

  Pkg:         nerves_toolchain_ctng
  Vsn:         1.7.2
  Type:        toolchain_platform
  BuildRunner: {nil, []}

  Pkg:         nerves_system_br
  Vsn:         1.13.4
  Type:        system_platform
  BuildRunner: {nil, []}

  Pkg:         nerves_toolchain_aarch64_unknown_linux_gnu
  Vsn:         1.3.2
  Type:        toolchain
  BuildRunner: {Nerves.Artifact.BuildRunners.Local, []}

  Pkg:         nerves_system_rpi4
  Vsn:         1.13.1
  Type:        system
  BuildRunner: {Nerves.Artifact.BuildRunners.Local, []}

|nerves_bootstrap| Loadpaths Start


Nerves environment
  MIX_TARGET:   rpi4
  MIX_ENV:      dev

|nerves_bootstrap| Environment Variable List
  target:     rpi4
  toolchain:  /home/pojiro/.nerves/artifacts/nerves_toolchain_aarch64_unknown_linux_gnu-linux_x86_64-1.3.2
  system:     /home/pojiro/.nerves/artifacts/nerves_system_rpi4-portable-1.13.1

Additional information about your host, target hardware or environment that
may help

Current behavior

Connecting 5GHz WiFi is failed, cause of below error, when we use nerves_system_rpi4 1.13.1.
This doesn't happen on nerves_system_rpi4 1.13.0.

I asked my friends to reproduce this, then it also happened with friend's WiFI 5GHz AP.

13:55:41.858 [info]  WPASupplicant ignoring {:event, "WPS-AP-AVAILABLE"}

13:55:41.858 [info]  WPASupplicant ignoring {:event, "CTRL-EVENT-NETWORK-NOT-FOUND"}

13:56:11.393 [error] ieee80211 phy0: brcmf_fw_crashed: Firmware has halted or crashed

13:56:13.929 [error] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout

13:56:16.291 [error] GenServer {VintageNet.Interface.Registry, {VintageNetWiFi.WPASupplicant, "wlan0"}} terminating
** (stop) exited in: GenServer.call(#PID<0.1525.0>, {:control_request, "BSS 12:66:82:09:bf:3a"}, 5000)
    ** (EXIT) time out
    (elixir 1.11.2) lib/gen_server.ex:1027: GenServer.call/3
    (vintage_net_wifi 0.9.1) lib/vintage_net_wifi/wpa_supplicant.ex:486: VintageNetWiFi.WPASupplicant.get_access_point_info/2
    (vintage_net_wifi 0.9.1) lib/vintage_net_wifi/wpa_supplicant.ex:212: VintageNetWiFi.WPASupplicant.handle_notification/2
    (vintage_net_wifi 0.9.1) lib/vintage_net_wifi/wpa_supplicant.ex:197: VintageNetWiFi.WPASupplicant.handle_info/2
    (stdlib 3.13.2) gen_server.erl:680: :gen_server.try_dispatch/4
    (stdlib 3.13.2) gen_server.erl:756: :gen_server.handle_msg/6
    (stdlib 3.13.2) proc_lib.erl:226: :proc_lib.init_p_do_apply/3
Last message: {VintageNetWiFi.WPASupplicantLL, 3, "CTRL-EVENT-BSS-ADDED 9 12:66:82:09:bf:3a"}
State: %{access_points: %{"10:66:82:09:bf:3a" => %VintageNetWiFi.AccessPoint{band: :wifi_2_4_ghz, bssid: "10:66:82:09:bf:3a", channel: 1, flags: [:wpa2_psk_ccmp, :wps, :ess], frequency: 2412, signal_dbm: -81, signal_percent: 28, ssid: "ctc-g-00d190"}, "10:66:82:09:bf:3b" => %VintageNetWiFi.AccessPoint{band: :wifi_5_ghz, bssid: "10:66:82:09:bf:3b", channel: 36, flags: [:wpa2_psk_ccmp, :wps, :ess], frequency: 5180, signal_dbm: -85, signal_percent: 34, ssid: "ctc-a-00d190"}, "30:f7:72:b1:97:72" => %VintageNetWiFi.AccessPoint{band: :wifi_2_4_ghz, bssid: "30:f7:72:b1:97:72", channel: 6, flags: [:wpa2_psk_ccmp, :wps, :ess], frequency: 2437, signal_dbm: -74, signal_percent: 42, ssid: "30F772B19770-2G"}, "34:3d:c4:4f:72:28" => %VintageNetWiFi.AccessPoint{band: :wifi_2_4_ghz, bssid: "34:3d:c4:4f:72:28", channel: 11, flags: [:wpa2_psk_ccmp, :wps, :ess], frequency: 2462, signal_dbm: -82, signal_percent: 26, ssid: "Buffalo-G-7228"}, "60:84:bd:4f:1b:21" => %VintageNetWiFi.AccessPoint{band: :wifi_2_4_ghz, bssid: "60:84:bd:4f:1b:21", channel: 2, flags: [:wpa2_psk_ccmp, :wps, :ess], frequency: 2417, signal_dbm: -80, signal_percent: 30, ssid: "Buffalo-G-1B20"}, "60:84:bd:4f:1b:24" => %VintageNetWiFi.AccessPoint{band: :wifi_5_ghz, bssid: "60:84:bd:4f:1b:24", channel: 56, flags: [:wpa2_psk_ccmp, :wps, :ess], frequency: 5280, signal_dbm: -87, signal_percent: 29, ssid: "Buffalo-A-1B20"}, "c0:25:a2:b1:4c:8e" => %VintageNetWiFi.AccessPoint{band: :wifi_2_4_ghz, bssid: "c0:25:a2:b1:4c:8e", channel: 7, flags: [:wpa2_psk_ccmp, :wps, :ess], frequency: 2442, signal_dbm: -50, signal_percent: 79, ssid: "ctc-g-a6f52c"}, "c2:25:a2:82:dc:4e" => %VintageNetWiFi.AccessPoint{band: :wifi_2_4_ghz, bssid: "c2:25:a2:82:dc:4e", channel: 5, flags: [:ess], frequency: 2432, signal_dbm: -84, signal_percent: 22, ssid: <<0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0>>}, "c2:25:a2:b1:4c:8e" => %VintageNetWiFi.AccessPoint{band: :wifi_2_4_ghz, bssid: "c2:25:a2:b1:4c:8e", channel: 7, flags: [:ess], frequency: 2442, signal_dbm: -47, signal_percent: 82, ssid: <<0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0>>}}, ap_mode: false, clients: [], control_dir: "/tmp/vintage_net/wpa_supplicant", current_ap: nil, eap_status: %VintageNet.Interface.EAPStatus{method: nil, remote_certificate_verified?: false, status: nil, timestamp: nil}, ifname: "wlan0", keep_alive_interval: 60000, ll: #PID<0.1525.0>, peers: [], verbose: false, wpa_supplicant: "wpa_supplicant", wpa_supplicant_conf_path: "/tmp/vintage_net/wpa_supplicant.conf.wlan0"}

13:56:16.309 [error] ieee80211 phy0: brcmf_pno_clean: failed code -512

Expected behavior

This phenomenon may be due to rpi4 drivers rather than "Nerves", but user should know.
Please let me know if there is any other information you need. Thanks.

v1.12.2 still looks for fixup4.dat

Environment

Elixir version (elixir -v):

Erlang/OTP 23 [erts-11.0.3] [source] [64-bit] [smp:2:2] [ds:2:2:10] [async-threads:1] [hipe]

Elixir 1.10.4 (compiled with Erlang/OTP 23)

Nerves environment: (mix nerves.env --info)

|nerves_bootstrap| Environment Package List
  Pkg:         nerves_system_rpi4
  Vsn:         1.12.2
  Type:        system
  BuildRunner: {Nerves.Artifact.BuildRunners.Local, []}

  Pkg:         nerves_toolchain_ctng
  Vsn:         1.7.2
  Type:        toolchain_platform
  BuildRunner: {nil, []}

  Pkg:         nerves_toolchain_arm_unknown_linux_gnueabihf
  Vsn:         1.3.2
  Type:        toolchain
  BuildRunner: {Nerves.Artifact.BuildRunners.Local, []}

  Pkg:         nerves_system_br
  Vsn:         1.12.4
  Type:        system_platform
  BuildRunner: {nil, []}

|nerves_bootstrap| Loadpaths Start


Nerves environment
  MIX_TARGET:   rpi4
  MIX_ENV:      dev

|nerves_bootstrap| Environment Variable List
  target:     rpi4
  toolchain:  /home/jhs/.nerves/artifacts/nerves_toolchain_arm_unknown_linux_gnueabihf-linux_x86_64-1.3.2
  system:     /home/jhs/.nerves/artifacts/nerves_system_rpi4-portable-1.12.2
  app:        /home/jhs/src/jsimmonds2/RasPi3BPlus/Blinkers/Nerves/fb2

|nerves_bootstrap| Loadpaths End

Additional information about your host, target hardware or environment that
may help

Current behavior

Include errors, stacktraces, screenshots or code that may help us reproduce the
issue.

Building /home/jhs/src/jsimmonds2/RasPi3BPlus/Blinkers/Nerves/fb2/_build/rpi4/rpi4_dev/nerves/images/fb2.fw...
fwup: can't open path '/home/jhs/.nerves/artifacts/nerves_system_rpi4-portable-1.12.2/images/rpi-firmware/fixup4.dat' in file-resource 'fixup4.dat'
** (Mix) Nerves encountered an error. %IO.Stream{device: :standard_io, line_or_bytes: :line, raw: true}

[jhs@f32v-on-comet fb2]$

Expected behavior

Clean firmware build ( as previously when using nerves_system_rpi4 v1.12.1

USB-C Gadget mode

To my knowledge we currently don't have USB-C gadget mode for the Pi 4. This post seems to say that's possible. So that would be neat. I guess it might even get enough power :)

nerves-project / nerves_system_rpi4 Goto Github PK

nerves_system_rpi4's Introduction

Raspberry Pi 4 Model B (64-bit)

Using

Supported WiFi devices

Camera

Audio

Provisioning devices

Linux kernel and RPi firmware/userland

Linux kernel configuration

nerves_system_rpi4's People

Contributors

Stargazers

Watchers

Forkers

nerves_system_rpi4's Issues

Environment

Current behavior

Expected behavior

Environment

Current behavior

Expected behavior

Environment

Current behavior

Expected behavior

Environment

Current behavior

Expected behavior

Environment

Current behavior

Expected behavior

Current behavior

Expected behavior

Environment

Current behavior

Expected behavior

Environment

Current behavior

Expected behavior

Environment

Current behavior

Expected behavior

Recommend Projects

Recommend Topics

Recommend Org