Better documentation for compiling optiboot #355
Comments
|
Example under Windows using CMD or PowerShell. |
|
Under Windows I need to use git bash to get it working, |
|
MSYS2 works as well with its bundled toolchain. |
|
And I believe WinAVR is no longer supported. |
|
For macOS, I have encountered issues with Atmel provided toolchain due to macOS security thingy. I have figured the solution. |
|
It would also be good to have some benchmarks about using different toolchains. I've seen some old 2018 threads with some data. It would be good to compare the code size generated using different version of the toolchain, at least the avr-gcc 5.4 based version and 7.3 based version. Example output for hex files generated by different toolchain using hexls is a neat utility from urboot project.
|
|
The older toolchain does not work with the custom linker script, so I checked out one commit earlier than that (68b7a55) This may not be comparable with the above git main results though.
|
|
Nice refernce from here, back in August 2018. Atmel avr-gcc 5.4.0 based toolchain was the winner at that time. I think it is still the overall best now.
|
|
@WestfW @MCUdude and @stefanrueger Maybe you will be interested in the results above. Interestingly the conclusion is a bit different from urboot test results below. For urboot, 4.8.1 performs better than 5.4.0. |
|
Im happy to help here in some capacity, however It seems that at the moment there is way too many combinations of compilers , compiler versions, environments and target platforms to make some baseline for CI/CD. Im kind of inclined to suggest having one or two environments fully officially supported and clean-up the whole repo, Makefiles etc. The Microchip version of gcc toolchain for Linux seems like one of those envs that make sense to be officially supported by Optiboot. Im not sure about the other ones as it seems they lack some uC support that Microchip version has (like atmega328pb). I have made a reference Dockerfile for compiling against Microchip toolchain in https://github.com/hecko/optiboot_docker_build - this can be easily ran using GitHub Actions and hex files can be automagically published / analyzed somewhere. Someone authoritative should really make a decision here. Especially now that HEAD version of Optiboot has different compilation options to the 8.0 version that will definitely confuse many people / compilation systems once 9.0 or whatever is released. |
@WestfW |
|
There is actually Travis-CI in the repo but it seems that it is not utlized. Maybe you can model that for your Docker Container or even better create a PR for github action. Your Dockerfile works great -- just tested it under Ubuntu 20.04 on my mini PC. |
|
If you look at @hecko's Dockerfile, it actually uses Microchip/Atmel DFPs. This should sort out your comments here. On the other hand, I htink the DFPs are meant to be used with Atmel toolchain based on avr-gcc 7.3.0, which does produce binaries with bigger code size than the older toolchain based on avr-gcc 5.4.0. But at least we can use the older 5.4.0 for most of the build and only use 7.3.0 for the chips 5.4.0 does not support. urboot uses this strategy -- it uses 4.8.1 or 5.4.0 based on certain conditions. |
|
#362 is pretty good, the only thing is that I will prefer to use Microchip toolchain based on avr-gcc 5.4.0 based on the code size tests mentioned earlier in this issue. |
|
I have created another workflow for the Microchip toolchain building all targets by running makeall.everycpu.sh, but Im unhappy about the Makefiles overdrive directive for CFLAGS as the environmental variables are not accepted and I havent found a quick way to integrrate the -I and -B flags into the process quickly Please have a look at this change what you think @mcuee hecko@6189777 |
|
Pretty impressive fast move. Thanks. The main missing thing is the archive of the resultant files now. BTW, |
|
Thats the thing @mcuee - are you sure you actually want to be releasing HEX files from this repository or simply run those workflows to make sure the build process still works correctly with new releases of the source codes? I think having a separate repository (something like optiboot-releases) would make more sense - we can then build the HEX files in this optiboot repo, but push them into a different repo for each official release. Its going to be lots and lots of files and I think having a separate entity for this is better way to go than storing the files in the main optiboot devel repo. |
Just archive the build artifacts so that the users can try the snapshot if they want, not really meant for release.
I do not think a seperate repo is necessary. When it comes to release, you can always release the hex files as you can see from the past optiboot release. |
|
so, this is the example of automatically generating hex files from a GitHub action: There needs to be a little cleanup as there are some non-hex, lst and elf files included, but this demonstrates that this can easily be done. Now the question is - if there are more environments in which files are be compiled - like the mentioned two different versions of Microchip toolkit - what do you aim to do about that? Do you want to create two dirs for the generated files depending on the toolchain being used? |
Nice. It would be good to zip the generated hex/elf/lst files and give the user the option to download the zip file. Reference from avrdude github action: you can see the last step is to upload the archive.
Yes that will be nice -- two seperate dirs for two toolchains. But let's hear from @WestfW as well. |
|
The output for both toolchains as discussed: |
I would like the optiboot source repository to remain "uncluttered" by hex and lst files.
That would be OK. I'm also happy to have the "boards packages" contain the .hex files. But the number of possible combinations that "might be useful" (even for testing) grows very large very quickly (The @MCUdude collection of optiboot hex files is over 10000 individual files!), and I think that's ridiculously bloaty to add to a source repsository (not to mention, as soon as it looks like you're providing .hex files, SOMEONE will complain that the particular one that they want isn't there. ("how about a 328pb .hex, pretending to be a 328p, but one the 2nd UART?") |
|
I think it is okay to skip the hex file other than the few most common ones in optiboot, then create another repo for the large collection if that is desired to have (personally I do not think it is necessary). What I was trying to say is to create github action which can generate the big collection of hex files (either automatically after each commit, or only on-demand). Then let the users download the artificat from github action which contains the hex files. But then the hex files are not part of the repo, just provided for convenience sake and not officially supported. Example from @stefanrueger's urboot project. To me it is good enough to have the representative hex files like here. But I agree it is too much to have the following big collection of hex files in the source repo. As for @MCUdude's optiboot_flash, I think the situation is different, he has a few Arduino Cores to support and the hex files are indeed necessary. Of course, it could be possible to split the hex file collections into a seperate repo as well. Maybe @stefanrueger has that in mind as well. @WestfW |
I think Wiki is a good start as well as
README.TXT.https://github.com/Optiboot/optiboot/wiki/CompilingOptiboot
https://github.com/Optiboot/optiboot/blob/master/optiboot/bootloaders/optiboot/README.TXT
But there are a few questions.
Toolchain -- is WinAVR really supported now? Is Atmel toolchain (avr-gcc 5.4 based and 7.3 based) supported?
I believe WinAVR is no longer supported. So it is better to remove it from the Wiki.
I think Atmel toolchain links should be provided in the Wiki and they should work based on my testing.
https://www.microchip.com/en-us/tools-resources/develop/microchip-studio/gcc-compilers
Atmel version 3.7.0 --> avr-gcc 7.3.0
Atmel version 3.6.2 --> avr-gcc 5.4.0
README.TXT -- which part is still relevant?
Build environment under Windows -- is CMD really supported? What about PowerShell and MSYS2 mingw?
I have no issued building under Linux and macOS. Windows is not a big problem but the building process needs to be better documented. I need to use git bash to get it work or use MSYS2.
Build environment under macOS -- CrossPacks is too old to work for newe version of macOS. It is better to only mention Arduino toolchains which works out of the box.
The text was updated successfully, but these errors were encountered: