Skip to content

Inconsistent SPI GPIO Behavior on PC Engines APU3 with RTE and OSFV #86

@pietrushnic

Description

@pietrushnic

While setting up a PC Engines APU3 with RTE v1.1 and OSFV CLI in a homelab, several challenges were encountered, primarily related to SPI GPIO configuration and its management across different setups. The issues include discrepancies between lab and homelab environments, missing or incomplete documentation, and confusion around OSFV CLI configuration for different RTE versions.

Key piece of code relevant to this issue is here.

  • SPI GPIO pins (e.g., gpio404-406) are not enabled by default in the homelab setup, preventing SPI flash detection.
  • Enabling these GPIOs manually resolves the issue, suggesting that OSFV CLI does not handle SPI GPIO states automatically in this configuration.
  • Lab setups should use older RTE versions (v1.0), which do not manage SPI GPIO enable/disable states. Our database reported this, but the behavior shows something different (SPI GPIO enable/disable works).
  • The homelab uses RTE v1.1, where SPI GPIO management should be handled but seems misconfigured.
  • The current APU3 model configuration in OSFV CLI assumes older RTE versions and does not correctly handle SPI GPIO states for RTE v1.1.
  • Creating a custom configuration with the correct programmer (rte_1_1) resolves the issue.
  • Information on setting up GPIOs, RTE versions, and configuration is scattered and incomplete. I had no idea I had to create additional configuration while adding my homelab platform.
  • Existing guides potentially do not adequately address RTE v1.1-specific behaviors or how to create customized configurations for homelab setups.
  • SPI GPIO configuration seems to persist across reboots, which may lead to even more significant confusion I get into.

What can we do?

  • Add the OSFV CLI APU3 model to include the correct configuration for RTE v1.1. src/osfv/models: add my apu3 homelab model #87
  • Enhance documentation:
  • Introduce better mechanisms in OSFV CLI to allow overriding configurations via arguments or external files.
    • Maybe all model parameters should be configurable by the command line. IMHO, I would notice that, but the configuration in the model I completely missed.
  • Educate users, partners, and 3mdeb employees on adding and customizing configurations, possibly through Dasharo User Guide (DUG) or vPub.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions