Notes on using Sonata board with Windows

[rmn30]

I tried following the instructions in David's recent blog post about using the RTOS and dev container with the Sonata board. I was using Windows so thought it'd be useful to report here and let others know some things I discovered.

Flashing RPI and FPGA

I plugged in and flashed the RPI and FGPA firmware using these instructions. I used rpi_rp2_v0.2.uf2 and sonata_bitstream_v0.2.bit with the main persistent flow (I had no problems so didn't use the 'temporary flow'). I tested with sonata_simple_demo_v0.2.uf and saw the lowRISC logo and flashing LEDs.

Using Putty for UART access

After plugging in the Sonata board I opened device manager and found that three COM ports had appeared (COM5-7 for me).
I'd previously discovered that the second of these, COM6, was the console UART so I opened a Putty to connect to it, selecting 'Serial' for the connection type and 115200 for the speed. I also ticked 'Implicit CR in every LF' from the Terminal settings to get the correct new line behaviour.

Using the dev container with Docker Desktop and WSL2

I already had the cheriot-rtos repo checked out in an Ubuntu WSL2 instance and Docker Desktop installed on Windows with WSL2 integration, so I git updated the repo and opened a VS code window by typing code. VS code prompted me to build the dev container and reopen in the container, which I did. I was then able to build the test suite for Sonata in the VS code terminal:

cd tests
xmake f --sdk=/cheriot-tools/ --board = sonata
xmake

I didn't have the SONATA drive mounted in the dev container so xmake run generated test-suite.uf2 then told me to copy it manually.
I found the file in File Explorer by clicking 'Linux' in the left pane and navigating to the given path in the WSL2 instance then dragged and dropped test-suite.uf2 to the SONATA drive and saw the test suite running in Putty:

bootloader: Loading software from flash...
bootloader: Booting into program, hopefully.
Test runner: Checking that rel-ro caprelocs work.  This will crash if they don't.  CHERI Permissions are:
Test runner: Global(0x0)
<snip>
Test runner: All tests finished in 61012484 cycles

Woohoo!

Binding the SONATA drive in the dev container (not quite working)

Next, to avoid having to drag and drop the firmware file I tried binding the SONATA drive in the dev container.
Initially I tried using the Windows drive letter for my SONATA board in the mounts section of devcontainer.json as suggested in the blog post but Docker gave an error about absolute paths.
After some searching I discovered that I could first mount the drive in my WSL2 instance (outside the dev container, where D is the letter of my SONATA drive):

sudo mkdir /mnt/d
sudo mount -t drvfs D: /mnt/d/

Then I added a section like this to devcontainer.json:

"mounts": [
    "source=/mnt/d/,target=/mnt/SONATA,type=bind"
  ]

After rebuilding the dev container I can now see the SONATA drive at /mnt/SONATA inside the dev container and xmake run attempts to copy the firmware there, but unfortunately things still don't quite work. In the UART I see some non-ASCII characters followed by a message:

bootloader: Failed Magic or numBlocks Check

In SONATA/LOG.TXT I messages like:

ERR: Verify error @ 10200

Looks like something has been lost in translation through the many layers of indirection. Fortunately the manual method still works!

[davidchisnall]

I wonder if it’s a speed thing. The only real translation is the 9p-over-VMBUS for mounting D: in WSL2. If that’s slow, the RPi may think it’s finished writing before it has.

I’m a bit surprised, since Docker on macOS is doing similar tricks to mount host filesystems in the guest VM then forward them into the container.