Teensy (ARM Cortex 0) support

[pastcompute]

Hi

I'm pondering whether I can add support for the teensy (https://www.pjrc.com/teensy/gcc.html) which uses either ARM Cortex-M0+ or ARM Cortex-M4 CPU

Do you think much is involved beyond adding a new cortex/ directory under src/arch/arm/ with associated plumbing, and working out how to do the deploy stage?

[nekromant]

ARM Cortex-M0/M4 are CPU cores sold by ARM to folks that do actual chips. There are a dozen of cm0/cm4 chips in the wild. Teensy's just a board (I guess you are talking about ARM versions of that board with MKL26Z64VFT4). Antares never targets actual boards, but tries to target chips and (if possible) families of chips in general, like STM32. So you will be likely adding something like arch/arm/mkl/.

It will be more complicated than for esp8266. Since esp8266 flawed and blobbed design a lot of the cool features could never be implemented or required a lot of hackery. The workflow is somewhat like that:

1. Get yourself a toolchain with newlib. I use crosstool-ng for all the arm stuff.
2. Grab the source tarball from the chip vendor and have a look inside. You'll need the proper LD file and all the basic stuff to make things just jump to main(). On STM32 I use a template for the ld file and generate the actual ld file on the run using gcc's preprocessor. Try to target the whole chip series, like I've done with STM32 there. It's not really difficult, but adds more awesomeness. All the magic is in arch/arm/stm32/arch.mk
3. Implement your arch/arm/whatever/arch.mk and add all the glue to arch/arm/{arch.mk, Makefile, kcnf}. See stm32 as the reference and don't forget to hack the RAM/FLASH meter - it's highly addictive to have it ;)
4. On most architectures antares implements a 'list-interrupts' and 'sizecheck' targets. The first one's usually backed up by utter scripting hackery - but gets the job done. For STM32 there's also a hacky 'probe' target, that pokes the chip with stm32flash and detects all target specs and updates the config accordingly.
5. Once you've done with the most part (you should be blinking the led happily at this point) - you'll need to add support for all those ANTARES_INIT_LOW, ANTARES_INIT_HIGH and ANTARES_APP macros, as well as ANTARES_ATOMIC_BLOCK. See antares.h. On some architectures it is now possible to use __attribute__((constructor(X)), but that hasn't been fixed yet, so it's mostly assembly for everyone, save 8051. Since on 8051 sdcc can't do anything . See how it's done in other architectures, ask a question if you don't understand.
6. If the license allows that (e.g. BSD-style) - just merge all the vendor's libraries into antares and add all the Kconfig stuff. See how it is done for ST's periph libraries.
7. Finally - hacking around the earlycon driver may be very helpful.

Deployment is super-simple - just drop a kcnf and Makefile into deploy directory. Btw, your project can also have a deploy directory with it's own project-specific deployment stuff in PROJECT_ROOT/deploy/.

There are a few known bugs here and there I haven't fixed yet, e.g. ARCH_FEATURES variable from arch.mk isn't parsed properly into kcnf, so if it does weird stuff - let me know.
Good luck!

[pastcompute]

Ok, thanks
Theres a fair bit there so I might not get to it for a little while

[nekromant]

Feel free to ask. I will hopefully be back about hacking some cool new features to antares at the beginning of september.