Add support for the STM32Gxx chipset and add CANFD functionality to the driver #126

ryedwards · 2022-11-02T03:30:45Z

There are a lot of commits with this PR which will make @marckleinebudde happy.

I've broken the changes down into bite sized parts.

The last commit is the one I need the most help with. Please read the notes on the commit.

I confirmed that the code works on my G0 hardware and I had one old canable device (F042) here that I was able to load and verify that the USB functionality works but I wasn't able to test CAN due to my soldering skills being poor when I built it about 2 years ago.

fenugrec

Lots of work went into this, I can tell. Thanks for splitting the commits.

Some comments sprinkled through my review.

For struct gs_host_frame, do I understand correctly that it could be chosen at compile-time ? I.e. on a CANFD device, does the kernel driver always send the larger struct (even if the channel is opened in Classic mode) ?
(Trying to see if a simple typedef would do the trick)
Allocating the fifos with the large struct is indeed a waste - smaller targets can't afford the RAM. In fact, the CI tests fail at the linking step due to overflowing RAM. Will look at this later.
Would prefer not to reduce fifo depth.

include/usbd_gs_can.h

src/can.c

fenugrec · 2022-11-02T04:38:30Z

src/main.c

-					last_can_error_status = can_err;
-				} else {
-					queue_push_back(q_frame_pool, frame);
+				// If there are frames to receive, don't report any error frames. The


what happened to these ~15 lines' whitespace ?

Yeah. git had a hard time with the diff on this file. You have to turn your head sideways to line everything up.

yeah... I'll try reverting the whitespace changes here (i.e. when I do the final merge), it's too distracting

src/flash.c

src/main.c

ldscripts/STM32G0B1XK.ld

libs/STM32_HAL/config/stm32g0xx_hal_conf.h

src/can.c

ryedwards · 2022-11-02T14:25:52Z

I added the changes to support resizing the gs_host_frame for non-CANFD builds.

ryedwards · 2022-11-02T20:42:34Z

There were a few major issues causing the F0/F4 to not operate on CAN. Simple things that I missed. Will commit the changes shortly. Is there anyone that can test the code on a few other devices?

fenugrec · 2022-11-02T22:05:39Z

Is there anyone that can test the code on a few other devices?

I lent almost all my prototypes, I just have one left. Can test enumeration etc but not much else atm

ryedwards · 2022-11-02T23:35:47Z

Is there anyone that can test the code on a few other devices?

I lent almost all my prototypes, I just have one left. Can test enumeration etc but not much else atm

I have an extra prototype of the budgetcan if you are interested in testing it out or just adding it to your spare electronics bin.

ryedwards · 2022-11-02T23:50:40Z

src/can.c

@@ -1,26 +1,26 @@
 /*



Well, I guess turn off whitespace for review. I tried to "uncrustify" the file on my own and forgot that I turned off whitespace checking in my GitHub Desktop.

ryedwards · 2022-11-02T23:59:19Z

Well crap I tried to squash two commits I think I broke something. Let me know if this is a problem.

fenugrec · 2022-11-03T00:19:18Z

I have an extra prototype of the budgetcan if you are interested in testing it out

Sure, how about a trade, I can spare one of mine (bonus : galvanically isolated).

ryedwards · 2022-11-03T00:39:11Z

I have an extra prototype of the budgetcan if you are interested in testing it out

Sure, how about a trade, I can spare one of mine (bonus : galvanically isolated).

Fire me an email and we can exchange info (bonus : 2 FDCAN channels, 1 SWCAN channel and 1 LIN) :)

ryedwards · 2022-11-03T20:36:13Z

src/can.c

 // The STM32F0 only has one CAN interface, define it as CAN1 as
 // well, so it doesn't need to be handled separately.
 #if !defined(CAN1) && defined(CAN)
 #define CAN1 CAN
 #endif

 // Completely reset the CAN pheriperal, including bus-state and error counters
-static void rcc_reset(CAN_TypeDef *instance)
+static void rcc_reset(CAN_TYPEDEF *instance)


@fenugrec I've found an issue with this function. For FDCAN multichannel devices if you reset the clock when you enable one channel it will kill the other channel. Since all channels in FDCAN use the same clock I noticed that the CubeMX generated init functions use a global counter to track when to enable/disable the clock (there is no handler for just resets). At this point I am going to remove this reset handler for the FDCAN implementation.

ryedwards · 2022-11-03T20:53:41Z

src/can.c

 #ifdef nCANSTBY_Pin
-	HAL_GPIO_WritePin(nCANSTBY_Port, nCANSTBY_Pin, GPIO_PIN_SET);
+	HAL_GPIO_WritePin(nCANSTBY_Port, nCANSTBY_Pin, nCANSTBY_Active_High == 1 ? GPIO_PIN_SET : GPIO_PIN_RESET);


Also should have tested this area better before I opened the pull request but it was masked by the clock reset issue. This design will not work (each channel has it's own standby pin). Also I will need to redesign the termination resistor design. I'm thinking as this point I create another PR to handle those two as it will be a big change to implement it properly. I don't think "per channel" GPIO was ever considered in the design. For now the 2nd and 3rd channels will not work.

Agreed, let's focus on just single-channel canFD for now

ryedwards · 2022-11-03T22:55:35Z

So as of right now I've tested all of the functionality on my STM32G0B1xx hardware and on a canable (STM32F042xx). Sanity checks out. As discussed above the CANFD only works for a single channel right now but since I think I'm the only one with FDCAN capable hardware I'll live with it.

fenugrec · 2022-11-06T00:30:06Z

btw you should really really be working on a branch, not directly on master... will make it easier to rebase as I slowly merge in the easier commits

marckleinebudde · 2022-11-08T15:47:08Z

For struct gs_host_frame, do I understand correctly that it could be chosen at compile-time ? I.e. on a CANFD device, does the kernel driver always send the larger struct (even if the channel is opened in Classic mode) ?

The Linux driver sends classic-CAN frames if the device is opened in classic-CAN mode. Currently it will always send CAN-FD sized frames if the device is opened in CAN-FD mode, even if sending classic-CAN frames. Although it might be an optimization on the Linux side to send classic-CAN frames in CAN-FD mode, if a classic-CAN frame is send.

(Trying to see if a simple typedef would do the trick) Allocating the fifos with the large struct is indeed a waste - smaller targets can't afford the RAM. In fact, the CI tests fail at the linking step due to overflowing RAM. Will look at this later. Would prefer not to reduce fifo depth.

ACK

For completeness: On the receiving side under Linux, as soon as at least one channel (of a multi channel device) supports CAN-FD mode and/or timestamps, the RX USB frame size is setup accordingly. All CAN channels are multiplexed into the same endpoint, so we have to deal the maximum USB RX size possible.

marckleinebudde · 2022-11-08T15:37:33Z

include/gs_usb.h

@@ -275,34 +275,44 @@ struct gs_device_termination_state {
 	u32 state;
 } __packed;

-struct gs_host_frame {


I can try to port the DECLARE_FLEX_ARRAY from BSD to the candlelight FW, so we can make use of it here, too.

ryedwards · 2022-11-08T22:41:12Z

The Linux driver sends classic-CAN frames if the device is opened in classic-CAN mode. Currently it will always send CAN-FD sized frames if the device is opened in CAN-FD mode, even if sending classic-CAN frames. Although it might be an optimization on the Linux side to send classic-CAN frames in CAN-FD mode, if a classic-CAN frame is send.

The way the firmware is written it can handle any size incoming. But, if the device supports CANFD the buffer sizes default to the CANFD frame size pre-compile. As for bus bandwidth, the firmware will send "classic can" frames (24 bytes) when it's a non-FD frame and the full "can" frame (80 bytes) when it's FD data. I think the kernel does the same.

(Trying to see if a simple typedef would do the trick) Allocating the fifos with the large struct is indeed a waste - smaller targets can't afford the RAM. In fact, the CI tests fail at the linking step due to overflowing RAM. Will look at this later. Would prefer not to reduce fifo depth.

I did create a pre-compile define for devices that don't support CANFD (276fb49). Those devices will only use classic can buffers. All of the devices that support CANFD have tons of RAM so there's not a real concern with those.

fenugrec · 2022-11-10T14:36:16Z

Those devices will only use classic can buffers. All of the devices that support CANFD have tons of RAM so there's not a real concern with those.

Agreed.

Apologies for the delays, part of the issues in merging this "as-is" is that some commits break the build - temporarily, of course, but I haven't decided how much it bothers me. I started reordering / rebasing commits in a separate branch, but that would make any further work on your side much more complicated.
You were reporting some issues with multiple channels, how is that progressing ? I'm fine with merging a single-channel canFD + G0 implementation just to get this in trunk , for a good start.

marckleinebudde · 2022-11-10T14:49:57Z

From my point of view breaking builds is not desirable (/me wearing my Linux Maintainer glasses).
I started hacking on cleanups for multi channel support - available here: https://github.com/marckleinebudde/candleLight_fw/tree/multichannel. Consider this as a WIP branch, subject to rebase.

marckleinebudde · 2022-11-10T14:51:12Z

I started reordering / rebasing commits in a separate branch, but that would make any further work on your side much more complicated.

Can you push that branch somewhere?

ryedwards · 2022-11-10T14:52:47Z

Those devices will only use classic can buffers. All of the devices that support CANFD have tons of RAM so there's not a real concern with those.

Agreed.

Apologies for the delays, part of the issues in merging this "as-is" is that some commits break the build - temporarily, of course, but I haven't decided how much it bothers me. I started reordering / rebasing commits in a separate branch, but that would make any further work on your side much more complicated. You were reporting some issues with multiple channels, how is that progressing ? I'm fine with merging a single-channel canFD + G0 implementation just to get this in trunk , for a good start.

I took a look at it. It's going to be a huge tear-up to the GPIO design to assign ports/pins to different channels. I tried a few ways and the best bet was to create indexed lookup tables for all GPIO. The biggest issue right now is that the gpio.c tries to handle all of the GPIOs for all the different boards. It's becoming a mashup of defines that'll be even worse if I add channel based GPIO.

marckleinebudde · 2022-11-10T14:56:17Z

IMHO this should be different topics:

multi channel
STM32G0
CANFD

Not necessarily needed to be addressed in this order.

fenugrec · 2022-11-10T16:06:10Z

Then I suggest leaving multichannel well alone until G0 + CANFD gets merged, and then give me time to start splitting out some code into platform-specific folder/files. I think we have just about enough #ifdefs in can.c and gpio.c ...

Can you push that branch somewhere?

Will do - possibly even later today.

fenugrec · 2022-11-11T00:57:26Z

Can you push that branch somewhere?

https://github.com/fenugrec/candleLight_fw/tree/g0_1

WIP of course, could be rebased / push -f'ed at any time . I was cherry-picking + rebasing a few commits at a time.

marckleinebudde · 2022-11-11T23:13:29Z

Can you push that branch somewhere?

https://github.com/fenugrec/candleLight_fw/tree/g0_1

WIP of course, could be rebased / push -f'ed at any time . I was cherry-picking + rebasing a few commits at a time.

That looks really nicely cleaned up!

marckleinebudde · 2022-11-11T23:38:57Z

Just updated https://github.com/marckleinebudde/candleLight_fw/tree/multichannel

The firmware is now free of dynamic memory management, everything is allocated statically. The queues are replaced by a Linux compatible list implementation.

The last patch sets the heap size for the F042 and F072 to 0, otherwise linking fails, as the data sections has grown and contains now all the variables that were prior allocated on the heap. If we squash that patch into the whole series is fully bisectable.

Next I'd continue to work on multi channel support....and I need a better name for the struct that holds the struct gs_host_frame and the struct list_head:

struct gs_host_frame_entry {
	struct gs_host_frame frame;
	struct list_head list;
};

ryedwards · 2022-11-12T13:12:56Z

At what point does it make sense to close this PR and open new ones to merge in the changes on various branches? I think my changes incorporated many of the features that @marckleinebudde is including, just not as elegantly :)

Looks like the branch created by @fenugrec already has done 90% of this. I just need to help out with the CANFD part.

Again, github newbie here.

Thoughts?

ryedwards · 2022-11-12T13:23:45Z

Just updated https://github.com/marckleinebudde/candleLight_fw/tree/multichannel

The firmware is now free of dynamic memory management, everything is allocated statically. The queues are replaced by a Linux compatible list implementation.

The last patch sets the heap size for the F042 and F072 to 0, otherwise linking fails, as the data sections has grown and contains now all the variables that were prior allocated on the heap. If we squash that patch into the whole series is fully bisectable.

Next I'd continue to work on multi channel support....and I need a better name for the struct that holds the struct gs_host_frame and the struct list_head:
struct gs_host_frame_entry {
	struct gs_host_frame frame;
	struct list_head list;
};

Also, to support multi-channel, does it make sense to move the CAN RX into an interrupt driven design vs. the current poling design? For multichannel polling you need to create a for loop to poll each channel in main. With the interrupt you simply add to the list within the interrupt (skip a whole extra step in the main loop). I've been running it in my budgetcan codebase for a while and it saves on ROM and makes it so that when messages come in they are just added to list immediately.

Again, thoughts?

marckleinebudde · 2023-02-08T22:37:51Z

@ghent360 I've updated my branch again. The LEDs are not properly integrated, yet. 2 Channels and CAN-FD are working.

ghent360 · 2023-02-10T20:10:47Z

Merged and tested. The CAN_btconst.features were wrong again. Somehow the IS_ENABLED(CONFIG_CANFD) was not working correctly. After updating that. it is working again.

Separate topic: I tested the canboot bootloader from the klipper folks, it is convenient since the mks UTC board does not have a good way to set 'boot0' and enable DFU mode.

fenugrec · 2023-02-10T20:25:10Z

Separate topic: I tested the canboot bootloader from the klipper folks, it is convenient since the mks UTC board does not have a good way to set 'boot0' and enable DFU mode.

I haven't needed to short the BOOT pins in a long time... does the DFU alternate interface not work on G0 ?

ghent360 · 2023-02-10T20:38:12Z

DFU likely does work in general, however I think there is a bug in the mks_utc board, so it does not work there.

marckleinebudde · 2023-02-11T08:10:25Z

I haven't needed to short the BOOT pins in a long time... does the DFU alternate interface not work on G0 ?

Just implemented the missing bits in src/dfu.c, it works. I don't have my private key with me I'll push the changes on Sunday evening.

marckleinebudde · 2023-02-13T08:15:14Z

I've pushed the dfu changes.

ghent360 · 2023-02-16T00:45:21Z

@marckleinebudde merged your changes and took a stab at the LED /channel integration.
How is the dfu stuff supposed to work? Flashed the latest fw with st-link, tried make flash-xxx_fw, the DFU tool says:

Match vendor ID from file: 1d50
Match product ID from file: 606f
dfu-util: Cannot open DFU device 1d50:606f
dfu-util: No DFU capable USB device available

the board does not reset/reboot, does it need a button to trigger DFU mode?

fenugrec · 2023-02-16T01:51:51Z

the board does not reset/reboot, does it need a button to trigger DFU mode?

No (Haven't tried with G0 however). Does dfu-util -llist the expected DFU interface ?

I normally don't use the " make flash-...." target since I always have more than one board connected and therefore need to invoke dfu-util manually to specify serial number.

ghent360 · 2023-02-16T03:01:51Z

DFU is working correctly. I'm stupid and did not update the udev rules. CAN functions were working fine, just the DFU could not open the device. Updated the udev rules and works like a charm.

marckleinebudde · 2023-02-18T21:16:19Z

took a stab at the LED /channel integration.

Thanks for the work, I've polished it a bit and added to my https://github.com/marckleinebudde/candleLight_fw/tree/multichannel branch.

ghent360 · 2023-03-09T09:14:30Z

@marckleinebudde I figured out what I thought is a layout issue with my board. On some transceivers one has to use the controller's delay compensation. I added this to the board config structure as it seems to be board dependent.

My board works fine at 1/5 Mbps now.

ghent360 · 2023-03-09T09:19:09Z

I also re-worked the clock config on the G0. The default 40MHz CAN clock is a bit low when you get into high speeds. I managed to squeeze 80MHz CAN clock / 64MHz cpu clock.

marckleinebudde · 2023-03-12T11:26:35Z

I figured out what I thought is a layout issue with my board. On some transceivers one has to use the controller's delay compensation. I added this to the board config structure as it seems to be board dependent.

TDC is bitrate dependent. See https://elixir.bootlin.com/linux/v6.2.5/source/drivers/net/can/m_can/m_can.c#L1204

marckleinebudde · 2023-03-12T11:35:03Z

I also re-worked the clock config on the G0. The default 40MHz CAN clock is a bit low when you get into high speeds. I managed to squeeze 80MHz CAN clock / 64MHz cpu clock.

20 or 40 MHz are the CIA recommended values for the CAN clock. I have a peak USB adapter that uses 80 MHz, though. Which problems do you see with 40 MHz only?

These are the default timing parameters calculated by the algorithm in the Linux Kernel:

Data Bit timing parameters for mcan-v3.1+ with 40.000000 MHz ref clock (cmd-line) using algo 'v5.19'
 nominal                                  real  Bitrt    nom   real  SampP
 Bitrate TQ[ns] PrS PhS1 PhS2 SJW BRP  Bitrate  Error  SampP  SampP  Error         NBTP
12000000 ***bitrate not possible***
10000000     25   1    1    1   1   1 10000000   0.0%  75.0%  75.0%   0.0%   0x00000100
 8000000     25   1    1    2   1   1  8000000   0.0%  75.0%  60.0%  20.0%   0x00000101
 5000000     25   2    3    2   1   1  5000000   0.0%  75.0%  75.0%   0.0%   0x00000401
 4000000     25   3    3    3   1   1  4000000   0.0%  75.0%  70.0%   6.7%   0x00000502
 2000000     25   7    7    5   1   1  2000000   0.0%  75.0%  75.0%   0.0%   0x00000d04
 1000000     25  14   15   10   1   1  1000000   0.0%  75.0%  75.0%   0.0%   0x00001c09

Data Bit timing parameters for mcan-v3.1+ with 80.000000 MHz ref clock (cmd-line) using algo 'v5.19'
 nominal                                  real  Bitrt    nom   real  SampP
 Bitrate TQ[ns] PrS PhS1 PhS2 SJW BRP  Bitrate  Error  SampP  SampP  Error         NBTP
12000000     12   2    2    2   1   1 11428571   4.8%  75.0%  71.4%   4.8%   0x00000301
10000000     12   2    3    2   1   1 10000000   0.0%  75.0%  75.0%   0.0%   0x00000401
 8000000     12   3    3    3   1   1  8000000   0.0%  75.0%  70.0%   6.7%   0x00000502
 5000000     12   5    6    4   1   1  5000000   0.0%  75.0%  75.0%   0.0%   0x00000a03
 4000000     12   7    7    5   1   1  4000000   0.0%  75.0%  75.0%   0.0%   0x00000d04
 2000000     12  14   15   10   1   1  2000000   0.0%  75.0%  75.0%   0.0%   0x00001c09
 1000000     25  14   15   10   1   2  1000000   0.0%  75.0%  75.0%   0.0%   0x00011c09

sammcj · 2023-04-17T22:23:34Z

Howdy STM32Gxx folks - at present is it best to use this PR's source branch/fork - or the BTT fork without a PR for STM32G based devices such as the EBB36?

master...bigtreetech:candleLight_fw:stm32g0_support

marckleinebudde · 2023-04-18T06:34:52Z

Hey @sammcj,

my Work-in-Progress stm32g0b1 branch is here: https://github.com/marckleinebudde/candleLight_fw/tree/multichannel. It contains the newest g0b1 support.

michaelmyc · 2023-04-19T05:10:42Z

@marckleinebudde Thank you! I was hesitant to use BTT's compiled binary firmware as they did not provide any explanation of how the binary was created. I'm able to confirm that your branch with "make nucleo_g0b1re_fw" works perfectly with the BTT U2C v2.1 board.

Do you have a rough timeline of when this will be merged into mainline?

vtjballeng · 2023-04-19T06:44:50Z

@marckleinebudde Thank you! I was hesitant to use BTT's compiled binary firmware as they did not provide any explanation of how the binary was created. I'm able to confirm that your branch with "make nucleo_g0b1re_fw" works perfectly with the BTT U2C v2.1 board.

Do you have a rough timeline of when this will be merged into mainline?

Were you able to validate that 2 CAN Bus interfaces work on the BTT U2C?

marckleinebudde · 2023-04-19T06:46:06Z

Were you able to validate that 2 CAN Bus interfaces work on the BTT U2C?

Your board might need a different pinmux, if so create a new board and send a PR against my branch.

marckleinebudde · 2023-04-19T06:47:54Z

Do you have a rough timeline of when this will be merged into mainline?

I'm not happy with the LED stuff, yet. And @fenugrec has to have a look at the board abstraction. 😸

michaelmyc · 2023-04-19T07:20:22Z

I did see 2 interfaces when running ip a, so I assume yes? Though I did not need CAN1 so I have never set it to up. I'm building a small 3d printer that has 1 toolhead board I'm communicating through CAN, and I don't have a 2nd board that accepts CAN, so I can't test if the 2 channels will work simultaneously.

marckleinebudde · 2023-04-19T07:33:25Z

I did see 2 interfaces when running ip a, so I assume yes?

That proofs that the device announces 2 devices. So the the µC firmware and kernel are working together. But it does not show, that the µC is configured properly towards the hardware...

Though I did not need CAN1 so I have never set it to up. I'm building a small 3d printer that has 1 toolhead board I'm communicating through CAN, and I don't have a 2nd board that accepts CAN, so I can't test if the 2 channels will work simultaneously.

Can you use the other connector on the board and configure can1 instead of can0 unter Linux and test?

vtjballeng · 2023-04-19T08:18:47Z

I did see 2 interfaces when running ip a, so I assume yes? Though I did not need CAN1 so I have never set it to up. I'm building a small 3d printer that has 1 toolhead board I'm communicating through CAN, and I don't have a 2nd board that accepts CAN, so I can't test if the 2 channels will work simultaneously.

Another simple test method is to connect the busses together and validate tx from one to the other and vice versa.

michaelmyc · 2023-04-19T10:29:26Z

OK. Still wiring things up. Will do both tests once I get the chance.

fenugrec · 2023-04-20T02:45:57Z

And @fenugrec has to have a look at the board abstraction.

Oops, I thought the huge pile in #139 was still essentially 'WIP, don't merge' and I took advantage of the intervening time to work on other projects. (one of those, trying to get reasonable performance on windows, has proven to be one of the most infuriating things I've ever worked on, and left me completely discouraged about USB in general)

Board abstractions : are you referring to a specific set of commits that I may be overlooking ? Else, I know I've expressed the intention of working on that (had some kind of rework in mind) but unfortunately I've had to greatly reduce the amount of coding I do. Reviewing, testing and merging is still fine though.

marckleinebudde · 2023-04-20T07:25:10Z

I took advantage of the intervening time to work on other projects. (one of those, trying to get reasonable performance on windows, has proven to be one of the most infuriating things I've ever worked on, and left me completely discouraged about USB in general)

Oh dear, luckily I don't have to work on Windows....

Board abstractions : are you referring to a specific set of commits that I may be overlooking ?

Yes, commit 048601f and newer in #139.

fenugrec · 2023-04-22T15:10:27Z

Yes, commit 048601f and newer in #139.

I'm looking at 048601f...1c6e7cb , mostly OK but I don't think that range can be cherry-picked as-is ? e.g. it depends on earlier commits adding m_can.c

sammcj · 2023-09-10T21:54:58Z

Did this ever get updated and merged in another PR? I'm still running off this branch 😅

akohlsmith · 2023-11-29T20:09:51Z

How do I build for STM32G4? I don't see anything obvious in make help -- I'm trying to build for canable2 with FD support.

sammcj · 2024-08-10T02:26:28Z

Is building from this branch still required?

ryedwards mentioned this pull request Nov 2, 2022

Adding support for the STM32G0 #123

Open

fenugrec reviewed Nov 2, 2022

View reviewed changes

ryedwards commented Nov 2, 2022

View reviewed changes

ryedwards force-pushed the master branch from 3543d48 to 1b9faeb Compare November 2, 2022 23:56

ryedwards commented Nov 3, 2022

View reviewed changes

marckleinebudde suggested changes Nov 8, 2022

View reviewed changes

marckleinebudde mentioned this pull request Nov 9, 2022

Prepare for stm32g0 #127

Merged

Add support for the STM32Gxx chipset and add CANFD functionality to the driver #126

Are you sure you want to change the base?

Add support for the STM32Gxx chipset and add CANFD functionality to the driver #126

Conversation

ryedwards commented Nov 2, 2022

fenugrec left a comment

Choose a reason for hiding this comment

fenugrec Nov 2, 2022

Choose a reason for hiding this comment

ryedwards Nov 2, 2022

Choose a reason for hiding this comment

fenugrec Nov 2, 2022 • edited Loading

Choose a reason for hiding this comment

ryedwards commented Nov 2, 2022

ryedwards commented Nov 2, 2022

fenugrec commented Nov 2, 2022

ryedwards commented Nov 2, 2022

ryedwards Nov 2, 2022

Choose a reason for hiding this comment

ryedwards commented Nov 2, 2022

fenugrec commented Nov 3, 2022

ryedwards commented Nov 3, 2022

ryedwards Nov 3, 2022

Choose a reason for hiding this comment

ryedwards Nov 3, 2022

Choose a reason for hiding this comment

fenugrec Nov 3, 2022

Choose a reason for hiding this comment

ryedwards commented Nov 3, 2022

fenugrec commented Nov 6, 2022

marckleinebudde commented Nov 8, 2022 • edited Loading

marckleinebudde Nov 8, 2022

Choose a reason for hiding this comment

ryedwards commented Nov 8, 2022

fenugrec commented Nov 10, 2022

marckleinebudde commented Nov 10, 2022

marckleinebudde commented Nov 10, 2022

ryedwards commented Nov 10, 2022

marckleinebudde commented Nov 10, 2022

fenugrec commented Nov 10, 2022

fenugrec commented Nov 11, 2022 • edited Loading

marckleinebudde commented Nov 11, 2022

marckleinebudde commented Nov 11, 2022

ryedwards commented Nov 12, 2022 • edited Loading

ryedwards commented Nov 12, 2022

marckleinebudde commented Feb 8, 2023 • edited Loading

ghent360 commented Feb 10, 2023

fenugrec commented Feb 10, 2023

ghent360 commented Feb 10, 2023

marckleinebudde commented Feb 11, 2023

marckleinebudde commented Feb 13, 2023

ghent360 commented Feb 16, 2023

fenugrec commented Feb 16, 2023

ghent360 commented Feb 16, 2023

marckleinebudde commented Feb 18, 2023

ghent360 commented Mar 9, 2023

ghent360 commented Mar 9, 2023

marckleinebudde commented Mar 12, 2023

marckleinebudde commented Mar 12, 2023

sammcj commented Apr 17, 2023

marckleinebudde commented Apr 18, 2023

michaelmyc commented Apr 19, 2023 • edited Loading

vtjballeng commented Apr 19, 2023

marckleinebudde commented Apr 19, 2023

marckleinebudde commented Apr 19, 2023

michaelmyc commented Apr 19, 2023

marckleinebudde commented Apr 19, 2023

vtjballeng commented Apr 19, 2023

michaelmyc commented Apr 19, 2023

fenugrec commented Apr 20, 2023

marckleinebudde commented Apr 20, 2023

fenugrec commented Apr 22, 2023

sammcj commented Sep 10, 2023

akohlsmith commented Nov 29, 2023

sammcj commented Aug 10, 2024

fenugrec Nov 2, 2022 •

edited

Loading

marckleinebudde commented Nov 8, 2022 •

edited

Loading

fenugrec commented Nov 11, 2022 •

edited

Loading

ryedwards commented Nov 12, 2022 •

edited

Loading

marckleinebudde commented Feb 8, 2023 •

edited

Loading

michaelmyc commented Apr 19, 2023 •

edited

Loading