Currently, boards are defined in the TinyGo repository directly. This is good for off-the-shelf boards that can be purchased by anyone, but this model is no good for those of us who have custom boards and want to use TinyGo and I would be surprised if the original intent was to specifically add support for EVERY SINGLE BOARD IN EXISTANCE. There is some coupling within TinyGo's internals (mostly the machine package) that kept me from being able to define my board from within my project, some of which I was able to deal with:

1. The machine package assumes default pins for serial interfaces.
   • The machine package will use predefined pins for the first instance of a serial interface if no pins are specified by the respective config struct for the serial interface type.
     • Should instead the behavior be to return an error if the config is incorrect?

My solution: Returning an new error (ErrInvalidConfiguration) is how I was able to overcome this.

2. The USB implementation relies on constants defined by a board in the machine package.
   • The constants usb_STRING_PRODUCT and usb_STRING_MANUFACTURER are defined by each board in the machine package and the usb implementation will not compile if these constants are not present in the machine package for any reason.
     • Should these instead be set to some generic defaults and then able to be overridden later?
     • Should the USB implementation accept a config struct to allow a dev to specify these strings?

My solution: I disabled USB support in order to get the machine package to compile as USB support wasn't a priority for me (yet).

3. The default serial output cannot be changed because easily because the type that "machine.Serial" will be changed depending on build tags.
   • I honestly do not understand why there is no "Serialer" interface for serial output. Surprisingly the usb implementation will set the type it's "Serialer" interface type? Why not just have the machine package define an interface for anyone to implement as they please?

My solution: Just define a "Serialer" interface so that the type of the default serial interface doesn't matter so much.

With my above "solutions" I was able to get TinyGo running on my custom board without any build tag for a specific board set. I think that all boards definitions probably should be defined within a separate package (or repo entirely like drivers) to prevent unnecessary coupling and I think that the machine package (and runtime package) should focus solely on chip support. It is my opinion that I should be able to assume the responsibility of fully initializing my chip/board if I want to and therefore however I want to (within reasonable constraints).

Other nice-to-haves:

1. Have runtime optionally NOT setup clocks for me.
   • Currently the runtime package does this, but I think clock set up should be the responsibility of the developer.
   • The machine package or board (package) can provide a default clock set up function that can be optionally used.
2. Have the compiler look in the directory of the "main" package for target json files and linker files.
   -This will benefit anyone who wants to set up memories differently based their specific use case (bootloaders, chip variants, etc...).
   • EDIT: The -target option allows me to specify the target JSON and therefore the linker script.

For additional context: My custom board is based on ATSAME51G19A which is not a supported chip in mainstream TinyGo (yet). All of this stuff were issues I ran into while resisting adding specific support for my custom board nobody else will develop for directly. I added just what was required to get the chip working with TinyGo and my board specifics live in my local project.