Add UF2 output file generation #31066

petejohanson · 2020-12-31T22:00:23Z

Various devices are now shipping w/ UF2 compatible bootloaders. We've been hacking this into Zephyr ourselves w/ per-board post build commands for ZMK, but this adds proper upstream support for building UF2 files as part of the output, and adds support for the seeeduino_xiao board which has the BOSSA UF2 bootloader.

Tested locally building the samples/basic/blinky sample, double tapping reset, then cp build/xiao/zephyr/zephyr.uf2 /run/media/peter/Arduino and it is happily blinking away.

Adds new BUILD_OUTPUT_UF2_FAMILY_ID Kconfig setting for the family ID needed: https://github.com/Microsoft/uf2#family-id

The only thing I have an open question about would be the west.yml changes. I assume before merging the standard is to fork the upstream project into zephyrproject-rtos?

TIA!

tejlmand

Thanks for this PR.

The only thing I have an open question about would be the west.yml changes. I assume before merging the standard is to fork the upstream project into zephyrproject-rtos?

That is correct.
You can find some more information here:
https://docs.zephyrproject.org/latest/guides/modules.html#module-repositories

So we need a fork @nashif and @carlescufi can you take care of that ?

And in that fork we would need a zephyr/module.yml and a CMakeLists.txt file.

If you wait for: #30904, then you can place all Zephyr glue code in the main Zephyr repo, and only the zephyr/module.yml file will be needed in the fork.

CMakeLists.txt

Kconfig.zephyr

tejlmand · 2021-01-12T10:49:26Z

west.yml

@@ -144,6 +146,10 @@ manifest:
      repo-path: mcuboot
      path: modules/tee/tfm-mcuboot
      revision: 1.7.0-rc1
+    - name: uf2
+      repo-path: uf2
+      remote: microsoft


we would need a fork into Zephyr organization, as described:
https://docs.zephyrproject.org/latest/guides/modules.html#module-repositories

All modules included in the default manifest shall be hosted in repositories under the zephyrproject-rtos GitHub organization.

The module repository codebase shall include a module.yml file in a zephyr/ folder at the root of the repository.

...

as well as this:

Suggested change

remote: microsoft

pabigot · 2021-01-12T12:12:19Z

AFAICT this would enable Zephyr on a large number of Adafruit Nordic boards @carlescufi.

If true, I'd very much like to see this merged. Let me know if there's something I can do to help.

petejohanson · 2021-01-13T02:54:06Z

AFAICT this would enable Zephyr on a large number of Adafruit Nordic boards @carlescufi.

If true, I'd very much like to see this merged. Let me know if there's something I can do to help.

That is correct. This is based on our initial hacky post build command work we've done in https://github.com/zmkfirmware/zmk for now to support boards using that exact bootloader. Trying to "do this right" by getting this merged into Zephyr proper.

pabigot · 2021-01-16T15:20:18Z

Will review after @tejlmand's blocking change requests are addressed, as testing before that won't be much use.

petejohanson · 2021-01-16T15:25:04Z

My plan is to rework this once #30904 is in.

carlescufi · 2021-01-19T09:42:23Z

My plan is to rework this once #30904 is in.

It's in now @petejohanson

tejlmand · 2021-01-19T11:38:14Z

My plan is to rework this once #30904 is in.

It's in now @petejohanson

@carlescufi I think we also need a Zephyr fork, as mentioned: #31066 (review)

petejohanson · 2021-01-26T07:05:54Z

@tejlmand @pabigot @carlescufi @pabigot

Ok, I've just reworked this based on the new modules work.

Since we don't yet have the fork of the uf2 repo, the west.yml changes are still as is.

This assumes the following:

Checkout this PR.
Run west update
mkdir tools/uf2/zephyr
Add tools/uf2/zephyr/module.yml file with cmake-ext and kconfig-ext set to True
Build w/ the seeeduino_xiao, e.g. west build -d build/xiao -b seeeduino_xiao samples/basic/blinky

I've only updated the XIAO for this, since it is one known good board in upstream Zephyr that comes OOTB w/ a UF2 enabled bootloader.

If everyone is happy, and can get the uf2 repo forked into Zephyr's org, I can update the west.yml appropriately.

Thanks again!

petejohanson · 2021-01-30T05:56:46Z

Any thoughts on this?

pabigot · 2021-01-31T12:47:33Z

Any thoughts on this?

A lot of us are pretty focused on the stabilization phase for 2.5 right now, so we may not get to this until 2.5.0 closer to being ready for the release in the second week of February. (At least, I probably won't look at this until then.)

carlescufi · 2021-02-01T21:49:45Z

Any thoughts on this?

Could you please state which repository exactly you need forked, what it provides to Zephyr and which changes do you expect to have in it?

petejohanson · 2021-02-02T03:31:31Z

Any thoughts on this?

Could you please state which repository exactly you need forked, what it provides to Zephyr and which changes do you expect to have in it?

Repo: https://github.com/microsoft/uf2
Why needed: It contains a python script, https://github.com/microsoft/uf2/blob/master/utils/uf2conv.py that can convert a bin/hex to a UF2 file. This is as authoritative a conversion tool that I've found, and being python, is easy for us to use.

The only modification needed is the creation of one file zephyr/module.yml which should contain;

build:
  cmake-ext: True
  kconfig-ext: True

This is based on the work in #30904.

With this in place, the extra CMakeLists.txt added in this PR will work along w/ the few extra Kconfig settings, to build UF2 files as an extra post build step.

tejlmand

Thanks for this.

Looks good, only a couple of small cleanups needed when the fork is in place.

tejlmand · 2021-02-02T10:19:57Z

modules/uf2/CMakeLists.txt

+if(CONFIG_BUILD_OUTPUT_BIN AND CONFIG_BUILD_OUTPUT_UF2)
+  set_property(GLOBAL APPEND PROPERTY
+    extra_post_build_commands
+    COMMAND ${PYTHON_EXECUTABLE} ${ZEPHYR_BASE}/../tools/uf2/utils/uf2conv.py


When we have this as a Zephyr module, you should use:

Suggested change

COMMAND ${PYTHON_EXECUTABLE} ${ZEPHYR_BASE}/../tools/uf2/utils/uf2conv.py

COMMAND ${PYTHON_EXECUTABLE} ${ZEPHYR_UF2_MODULE_DIR}/utils/uf2conv.py

tejlmand · 2021-02-02T10:20:54Z

west.yml

+    - name: microsoft
+      url-base: https://github.com/microsoft


when the fork is in place, this can be removed.

Suggested change

- name: microsoft

url-base: https://github.com/microsoft

tejlmand · 2021-02-02T10:21:16Z

west.yml

@@ -144,6 +146,10 @@ manifest:
      repo-path: mcuboot
      path: modules/tee/tfm-mcuboot
      revision: 1.7.0-rc1
+    - name: uf2
+      repo-path: uf2
+      remote: microsoft


as well as this:

Suggested change

remote: microsoft

tejlmand · 2021-02-02T10:25:22Z

@carlescufi please make the zephyr/module.yml file as:

name: uf2

build:
  cmake-ext: True
  kconfig-ext: True

carlescufi · 2021-02-05T17:12:09Z

Repo: https://github.com/microsoft/uf2
Why needed: It contains a python script, https://github.com/microsoft/uf2/blob/master/utils/uf2conv.py that can convert a bin/hex to a UF2 file. This is as authoritative a conversion tool that I've found, and being python, is easy for us to use.

Thanks for explaining. But does it make sense to fork a whole repo just for that single script in a utils/ folder? It's also a pretty simple script, why not just take it and place it in our scripts/ folder in the main tree?
@mbolivar-nordic and @tejlmand thoughts?

petejohanson · 2021-02-05T17:24:40Z

I don't particularly care. The only advantage I would see would be easier integration of future changes upstream. If you take a look, that script had updates 15 days ago to add the RP2040 family, so changes to support more families would require occasional updates to the version we integration into Zephyr.

Whether those updates take the form of a repo fork, or a copy of a single file into Zephyr, I'll defer to others.

petejohanson · 2021-02-15T22:11:27Z

I think this is a good enhancement that will make Adafruit boards a lot easier to use in Zephyr.

There's quite a few other boards supporting UF2 natively now, including the RP2040, which support UF2 from their default/onboard bootloader.

Please fix the commit messages:
feat(build): Add UF2 family IDs for registered SoCs.
is not how we format these.
soc: Add UF2 family IDs for supported SoCs
It's also unusual to make the commit messages lists of changes. Free-form text is standard.

The Purpose: and Maintained-By: lines should be removed from the cmake: commit; the purpose should be in the description, and once it's in Zephyr its Zephyr that maintains it. The commit message could/should document that the expectation is this is unmodified from the source repository version.

Will do.

pabigot · 2021-02-16T12:13:02Z

I think this is a good enhancement that will make Adafruit boards a lot easier to use in Zephyr.

There's quite a few other boards supporting UF2 natively now, including the RP2040, which support UF2 from their default/onboard bootloader.

OK. BTW my block is solely on this stuff:

Please fix the commit messages: ...
Will do.

For the other point of contention (defaulting BUILD_OUTPUT_UF2_FAMILY_ID based on SOC) , based on all discussion so far just putting the defaults as text identifiers in Kconfig.zepyhyr where config BUILD_OUTPUT_UF2_FAMILY_ID is introduced seems the most maintainable. It's not like it's hundreds of lines.

But if it has to be squirreled away in an include file under modules/ that's not something I'd block on. (I would block on using the hex constants instead of the text identifiers from the uf2 script, unless we actually need the hex constants explicitly.)

petejohanson · 2021-02-16T12:20:04Z

But if it has to be squirreled away in an include file under modules/ that's not something I'd block on. (I would block on using the hex constants instead of the text identifiers from the uf2 script, unless we actually need the hex constants explicitly.)

I was going to comment on this. It seems like going with the family name alias, instead of the actual hex value ties us to an implementation detail of uf2conv.py, which seemed good to avoid. The actual hex value seems to be a fixed thing, is the friendly name alias?

I don't care strongly either way, just a thought.

Should a wait for concensus on where to put the defaults?

pabigot · 2021-02-16T12:28:34Z

I was going to comment on this. It seems like going with the family name alias, instead of the actual hex value ties us to an implementation detail of uf2conv.py, which seemed good to avoid. The actual hex value seems to be a fixed thing, is the friendly name alias?

Is there a registry of known identifiers that is more canonical than the uf2conv script? In a quick search I didn't find one.

Is there an alternative to uf2conv.py that has any market share?

If the answers are "no" and "no", then for now I'd say that script is the reference definition, and using the names it supports should be pretty stable.

Should a wait for concensus on where to put the defaults?

Couldn't say. I'm not sure if @tejlmand is open to anything other than what he's proposed, but that solution is something I'm willing to accept. So I guess just run with it and see if we can get this merged before my Clue boards arrive this week.

petejohanson · 2021-02-16T14:34:28Z

I was going to comment on this. It seems like going with the family name alias, instead of the actual hex value ties us to an implementation detail of uf2conv.py, which seemed good to avoid. The actual hex value seems to be a fixed thing, is the friendly name alias?

Is there a registry of known identifiers that is more canonical than the uf2conv script? In a quick search I didn't find one.

Actually, yes. The toplevel README.md in the uf2 repository lists more chosen IDs than have aliases in the uf2conv.py script. In particular, the ESP32 family ID (0x1c5f21b0) doesn't have a corresponding alias. This may be oversight, on the part of the maintainers there, but it points to a bit of a disconnect.

Is there an alternative to uf2conv.py that has any market share?

No that I've seen, but I haven't gone looking.

If the answers are "no" and "no", then for now I'd say that script is the reference definition, and using the names it supports should be pretty stable.

Should a wait for concensus on where to put the defaults?

Couldn't say. I'm not sure if @tejlmand is open to anything other than what he's proposed, but that solution is something I'm willing to accept. So I guess just run with it and see if we can get this merged before my Clue boards arrive this week.

I'm going to update to put them inline in Kconfig.zephyr to start, it's easy enough to then move that to a separate (single) file if requested.

petejohanson · 2021-02-16T14:45:57Z

@pabigot @tejlmand Ok, pushed a rebased/updated version.

Defaults put in Kconfig.zephyr. Let me know if there is consensus on a different location, I'll happily move it.
Fixes up commit message based on @pabigot feedback.
Does not switch to the "friendly name" for the family ID defaults, pending some continued discussion w/ @pabigot. I don't have a strong opinion on this, just answering some follow up questions before switching. @pabigot if you still want me to switch to the name alias for those the script supports, let me know.

pabigot · 2021-02-16T14:48:13Z

I'm fine with the hex constants under the argument that the canonical source for the mapping is the identified URL. You need to add a signed-off-by to that commit.

Also my comments on commit format also applied to the third commit, which still has feat(board) with a list-format body.

Add ability to build a UF2 (https://github.com/Microsoft/uf2) image as an additional output type. This leverages the code partition offset for the UF2 base address, and a configurable UF2 family ID. Includes an unmodified (except for headers for licensing, pylit disabling) version of the uf2conv.py script copied the UF2 format specification repository, used to convert the bin to UF2. Origin: UF2 file format specification reference utilies License: MIT URL: https://github.com/microsoft/uf2/blob/master/utils/uf2conv.py commit: 587abb8b909266e9b468d6284f2fbd425235d1b5 Signed-off-by: Pete Johanson <peter@peterjohanson.com>

petejohanson · 2021-02-16T16:05:00Z

I'm fine with the hex constants under the argument that the canonical source for the mapping is the identified URL. You need to add a signed-off-by to that commit.

Also my comments on commit format also applied to the third commit, which still has feat(board) with a list-format body.

Thanks. missed that when I was rebasing. Hopefully all good now, from a commit message perspective.

tejlmand · 2021-02-16T20:55:46Z

1. Defaults put in `Kconfig.zephyr`. Let me know if there is consensus on a different location, I'll happily move it.

I think this is a good current solution.
I'm not really fond of any of the discussed alternative, and even though it does clutter Kconfig.zephyr, it's ok for now.

In Toolchain WG, it has been discussed to make a more proper Kconfig tree for the toolchain and compiler settings in general, and that work itself will clean up Kconfig.zephyr, so let's have the UF2 directly there, and we can see if the build outputs in general will deserve its own Kconfig.

tejlmand

Looking good. Thanks for the patience.

Just one small comment.

tejlmand · 2021-02-16T21:04:27Z

Kconfig.zephyr

+if BUILD_OUTPUT_UF2
+
+config BUILD_OUTPUT_UF2_FAMILY_ID
+	# Prompt less config to setup a list of default UF2 Family IDs


It should no longer be prompt less, as I suppose users should still be able to provide a custom string if current soc is not known. So you probably want to re-add.

Suggested change

# Prompt less config to setup a list of default UF2 Family IDs

string "UF2 Device Family"

Note: The prompt less was only in case we wanted to have the defaults located outside of Kconfig.zephyr

Ok. Prompt restored.

Defaults from https://github.com/Microsoft/uf2#family-list Signed-off-by: Pete Johanson <peter@peterjohanson.com>

Default BOSSA bootloader supports UF2 OOTB, so enabling UF2 output by default. Signed-off-by: Pete Johanson <peter@peterjohanson.com>

tejlmand

lgtm

pabigot

Implementation looks good now; thanks.

AFAICT this would enable Zephyr on a large number of [Adafruit Nordic boards]
That is correct.

For some definition of "large". From this:

Only Adafruit Express boards and the Trinket M0 and Gemma M0 boards ship with the UF2 bootloader installed. Feather M0 Basic, Feather M0 Adalogger, and similar boards use a regular Arduino-compatible bootloader, which does not show a boardnameBOOT drive.

So it's not clear whether this helps me.

petejohanson · 2021-02-19T14:58:58Z

Implementation looks good now; thanks.

AFAICT this would enable Zephyr on a large number of [Adafruit Nordic boards]
That is correct.

For some definition of "large". From this:

Only Adafruit Express boards and the Trinket M0 and Gemma M0 boards ship with the UF2 bootloader installed. Feather M0 Basic, Feather M0 Adalogger, and similar boards use a regular Arduino-compatible bootloader, which does not show a boardnameBOOT drive.

So it's not clear whether this helps me.

There's been some decent activity on https://github.com/adafruit/tinyuf2 recently, so maybe hope moving forward more of their boards will ship w/ uf2 out of the box?

MaureenHelm · 2021-02-19T15:51:15Z

Implementation looks good now; thanks.

AFAICT this would enable Zephyr on a large number of [Adafruit Nordic boards]
That is correct.

For some definition of "large". From this:

Only Adafruit Express boards and the Trinket M0 and Gemma M0 boards ship with the UF2 bootloader installed. Feather M0 Basic, Feather M0 Adalogger, and similar boards use a regular Arduino-compatible bootloader, which does not show a boardnameBOOT drive.

So it's not clear whether this helps me.

There's been some decent activity on adafruit/tinyuf2 recently, so maybe hope moving forward more of their boards will ship w/ uf2 out of the box?

cc: @tannewt

pabigot · 2021-02-19T17:00:51Z

There's been some decent activity on https://github.com/adafruit/tinyuf2 recently, so maybe hope moving forward more of their boards will ship w/ uf2 out of the box?

That could help.

I really wanted Zephyr on the Clue, but it only supports DFU/serial programming, and the bootloader is placed in high flash with a configuration register overwritten to make the system start there, so the chance of bricking the device during porting is really high. SWD pins are provided only on unlabeled test points, so there seems no solution but to throw the boards into a box or donate them to somebody who understands Arduino or CircuitPython.

Too bad: it would have been a really cool Zephyr platform.

tannewt · 2021-02-20T03:23:18Z

Only Adafruit Express boards and the Trinket M0 and Gemma M0 boards ship with the UF2 bootloader installed. Feather M0 Basic, Feather M0 Adalogger, and similar boards use a regular Arduino-compatible bootloader, which does not show a boardnameBOOT drive.

So it's not clear whether this helps me.

Sorry about this text. It's old. All nRF boards from Adafruit should have a UF2 bootloader.

There's been some decent activity on https://github.com/adafruit/tinyuf2 recently, so maybe hope moving forward more of their boards will ship w/ uf2 out of the box?

Generally we ship UF2 bootloaders on all of our boards. All SAMD51 and nRF boards will. The text above is for M0, SAMD21 boards only. Basically ones designed before UF2 may not have it. (It depends on if the test jig gets updated.)

It's less urgent for us on boards with ROM bootloaders (ESP32-S2, iMX RT, STM32) so the first batches may not have it because the UF2 bootloader isn't ready yet. Our long term goal is to always have UF2 to ensure a consistent experience for all of our boards. (Once UF2 is ready, it depends on updating the test jig.)

tinyuf2 is my hope for the future. We have separate SAMD and nRF implementations that have been a pain to keep consistent. tinyuf2 builds on top of tinyusb to bring the uf2 bootloader to all of the same platforms. (CircuitPython builds on tinyusb for the same purpose.)

I really wanted Zephyr on the Clue, but it only supports DFU/serial programming, and the bootloader is placed in high flash with a configuration register overwritten to make the system start there, so the chance of bricking the device during porting is really high.

Mine has a UF2 bootloader. Just double tap reset. The UF2 bootloader (source) may assume the soft device is present though.

If you do brick it during porting I can get you a new one.

SWD pins are provided only on unlabeled test points, so there seems no solution but to throw the boards into a box or donate them to somebody who understands Arduino or CircuitPython.

The Feather nRF52840 is the best board if you want 2x5 SWD. It should work similar enough to the clue if you need SWD to debug a bad crash. If you need SWD on the clue you can solder from the test points to a larger pad and then use a micro:bit breakout to get it to a bread board. Eagle files for it are here: https://github.com/adafruit/Adafruit-CLUE-PCB (To figure out which test point is which.)

You should try CircuitPython if you haven't. It's very easy to get started. This is the setup guide: learn.adafruit.com/welcome-to-circuitpython and the API overview is here: https://learn.adafruit.com/circuitpython-essentials/

Too bad: it would have been a really cool Zephyr platform.

It would be!

tannewt · 2021-02-20T03:29:44Z

Is there an alternative to uf2conv.py that has any market share?

Not that I know of. We use uf2conv.py. Raspberry Pi has their own converter I think.

tannewt

I skimmed the code and it looks reasonable to me.

carlescufi · 2021-02-23T17:50:58Z

Scancode error:

Error: * scan/scripts/uf2conv.py is not apache-2.0 licensed: mit

Since this is a script that does not end in the firmware, I believe this can be considered acceptable.

petejohanson requested review from galak, MaureenHelm, nashif and tejlmand as code owners December 31, 2020 22:00

github-actions bot added area: Boards area: Build System area: Kconfig area: Modules labels Dec 31, 2020

petejohanson force-pushed the build/uf2-file-generation branch 2 times, most recently from 22dab6d to 28aa0fe Compare January 2, 2021 03:39

zephyrbot assigned tejlmand Jan 8, 2021

tejlmand requested changes Jan 12, 2021

View reviewed changes

carlescufi requested a review from pabigot January 15, 2021 20:39

petejohanson force-pushed the build/uf2-file-generation branch from 28aa0fe to d58b513 Compare January 26, 2021 06:59

petejohanson force-pushed the build/uf2-file-generation branch from d58b513 to 030c6c7 Compare January 26, 2021 07:12

tejlmand requested changes Feb 2, 2021

View reviewed changes

petejohanson force-pushed the build/uf2-file-generation branch from fb775b2 to 9fa1c91 Compare February 16, 2021 14:40

petejohanson force-pushed the build/uf2-file-generation branch from 9fa1c91 to 7e51f93 Compare February 16, 2021 15:30

petejohanson force-pushed the build/uf2-file-generation branch from 7e51f93 to 370b274 Compare February 16, 2021 15:54

tejlmand reviewed Feb 16, 2021

View reviewed changes

petejohanson added 2 commits February 16, 2021 16:07

soc: Add standard UF2 family IDs for supported SoCs.

612af99

Defaults from https://github.com/Microsoft/uf2#family-list Signed-off-by: Pete Johanson <peter@peterjohanson.com>

boards: seeeduino_xiao: Output UF2 by default.

19443c4

Default BOSSA bootloader supports UF2 OOTB, so enabling UF2 output by default. Signed-off-by: Pete Johanson <peter@peterjohanson.com>

petejohanson force-pushed the build/uf2-file-generation branch from 370b274 to 19443c4 Compare February 16, 2021 21:07

tejlmand approved these changes Feb 16, 2021

View reviewed changes

pabigot approved these changes Feb 19, 2021

View reviewed changes

MaureenHelm requested a review from tannewt February 19, 2021 15:51

tannewt approved these changes Feb 20, 2021

View reviewed changes

carlescufi approved these changes Feb 23, 2021

View reviewed changes

carlescufi merged commit 32a28f9 into zephyrproject-rtos:master Feb 23, 2021

petejohanson mentioned this pull request Feb 24, 2021

V2.4.0 uf2 output cherry pick zmkfirmware/zephyr#4

Merged

	COMMAND ${PYTHON_EXECUTABLE} ${ZEPHYR_BASE}/../tools/uf2/utils/uf2conv.py
	COMMAND ${PYTHON_EXECUTABLE} ${ZEPHYR_UF2_MODULE_DIR}/utils/uf2conv.py

	# Prompt less config to setup a list of default UF2 Family IDs
	string "UF2 Device Family"

Add UF2 output file generation #31066

Add UF2 output file generation #31066

Conversation

petejohanson commented Dec 31, 2020

tejlmand left a comment

Choose a reason for hiding this comment

tejlmand Jan 12, 2021 • edited Loading

Choose a reason for hiding this comment

tejlmand Feb 2, 2021

Choose a reason for hiding this comment

pabigot commented Jan 12, 2021

petejohanson commented Jan 13, 2021

pabigot commented Jan 16, 2021

petejohanson commented Jan 16, 2021

carlescufi commented Jan 19, 2021

tejlmand commented Jan 19, 2021

petejohanson commented Jan 26, 2021

petejohanson commented Jan 30, 2021

pabigot commented Jan 31, 2021

carlescufi commented Feb 1, 2021

petejohanson commented Feb 2, 2021

tejlmand left a comment • edited Loading

Choose a reason for hiding this comment

tejlmand Feb 2, 2021

Choose a reason for hiding this comment

tejlmand Feb 2, 2021

Choose a reason for hiding this comment

tejlmand Feb 2, 2021

Choose a reason for hiding this comment

tejlmand commented Feb 2, 2021

carlescufi commented Feb 5, 2021 • edited Loading

petejohanson commented Feb 5, 2021

petejohanson commented Feb 15, 2021

pabigot commented Feb 16, 2021 • edited Loading

petejohanson commented Feb 16, 2021

pabigot commented Feb 16, 2021

petejohanson commented Feb 16, 2021

petejohanson commented Feb 16, 2021

pabigot commented Feb 16, 2021

petejohanson commented Feb 16, 2021

tejlmand commented Feb 16, 2021

tejlmand left a comment

Choose a reason for hiding this comment

tejlmand Feb 16, 2021

Choose a reason for hiding this comment

petejohanson Feb 16, 2021

Choose a reason for hiding this comment

tejlmand left a comment

Choose a reason for hiding this comment

pabigot left a comment

Choose a reason for hiding this comment

petejohanson commented Feb 19, 2021

MaureenHelm commented Feb 19, 2021

pabigot commented Feb 19, 2021 • edited Loading

tannewt commented Feb 20, 2021

tannewt commented Feb 20, 2021

tannewt left a comment

Choose a reason for hiding this comment

carlescufi commented Feb 23, 2021

tejlmand Jan 12, 2021 •

edited

Loading

tejlmand left a comment •

edited

Loading

carlescufi commented Feb 5, 2021 •

edited

Loading

pabigot commented Feb 16, 2021 •

edited

Loading

pabigot commented Feb 19, 2021 •

edited

Loading