Hi folk, I’m new to RIOT and just exploring to find my way round and understand things.
I’ve been able to build and flash a ‘hello world’ for the arduino due that I’m playing with.
I ran the build system sanity check just to see what it would tell me, and noticed that, for the due, ‘riotboot’ is listed as both ‘required’ and ‘missing’.
Can anyone explain what this apparent contradiction is telling me ?
It means that you are trying to build an application that requires the riotboot feature but this feature is not provided by the arduino-due. There was an attempt to add it to that board but it never got merged.
I also started with RIOT OS on the Arduino. It works, but you are not getting that far with it. It is a 8-Bit Microcontroller with a lot of limitation. I recommend to switch to at least the STM32F1. The Bluepill is in a similar price range. You get the Bluepill + STLinkv2 for ~4 - 5 USD on eBay/Aliexpress. It’s a quite powerful MCU/board with a huge range of GPIO. The Bluepill even has a USB port. But I am not sure, if the STM32F1 USB is already supported in the kernel.
/e sorry, my mistake.
If I was using an 8 bit AVR I’d agree with you. But I’m using a DUE ( 32bit ARM Cortex M3 ).
Hmmm. I’m not trying to actually build any specific application here. I’m running the RIOT supplied build system consistency checker script ( save_all_dependencies_resolution_variables.sh ). This is the output I’m looking at :
BOARD = arduino-due CPU = sam3 CPU_MODEL = sam3x8e CPU_FAM = sam3 CPU_CORE = cortex-m3 CPU_ARCH = armv7m FEATURES_PROVIDED = periph_adc periph_dac periph_gpio periph_gpio_irq periph_pwm periph_rtt periph_spi periph_timer periph_uart arduino cortexm_mpu periph_cpuid periph_hwrng arch_32bit arch_arm cortexm_svc cpp cpu_check_address cpu_core_cortexm libstdcpp periph_pm puf_sram ssp no_idle_thread cpu_sam3 _FEATURES_PROVIDED_SORTED = arch_32bit arch_arm arduino cortexm_mpu cortexm_svc cpp cpu_check_address cpu_core_cortexm cpu_sam3 libstdcpp no_idle_thread periph_adc periph_cpuid periph_dac periph_gpio periph_gpio_irq periph_hwrng periph_pm periph_pwm periph_rtt periph_spi periph_timer periph_uart puf_sram ssp FEATURES_REQUIRED = riotboot arch_32bit arch_arm cpu_core_cortexm arch_32bit arch_arm cpu_core_cortexm _FEATURES_REQUIRED_SORTED = arch_32bit arch_arm cpu_core_cortexm riotboot FEATURES_REQUIRED_ANY = _FEATURES_REQUIRED_ANY_SORTED = FEATURES_OPTIONAL = cortexm_fpu periph_gpio periph_pm no_idle_thread cortexm_fpu periph_gpio periph_pm no_idle_thread FEATURES_USED = arch_32bit arch_arm cpu_core_cortexm no_idle_thread periph_gpio periph_pm riotboot FEATURES_MISSING = riotboot FEATURES_CONFLICT = FEATURES_CONFLICTING = USEMODULE = board boards_common_arduino_due checksum core cortexm_common cortexm_common_periph cpu newlib newlib_nano newlib_syscalls_default periph periph_common periph_gpio periph_init periph_init_gpio periph_init_pm periph_pm riotboot riotboot_hdr riotboot_slot stdio_null sys DEFAULT_MODULE = auto_init board core core_init core_msg core_panic cpu periph_init periph_init_gpio periph_init_pm sys DISABLE_MODULE = core_init core_msg core_panic auto_init auto_init_% auto_init_%
I’m just concerned in case this means that no application built for the DUE is going to work correctly.
Hi @mderouss,
That script is mainly used to make sure no dependencies change during potentially highly impactful changes, its fairly simple it just dumps all dependency related information for each BOARD/APPLICATION combination. It the allows to compare and check for changes, its a very simple and naive way of doing it, and usually you shouldn’t be needing this script unless making highly impactful changes in the build system.
From your ourput your probably did BOARD=Arduino-due DEPENDENCY_DEBUG=1 make -C {someApplication}. This dumps all the depency related variables only for one BOARD/APPLICATION combination.
Anyway having MISSING and REQUIRED features is normal, no BOARD/CPU has all features as some are architecture specific, or simply missing. If you can BOARD=arduino-due make -C {application/directory} then the BOARD should work, unless some specific manual configuration (mentioned in the application README) is mentioned.
E.g.: if you try to build tests/riotboot:
BOARD=arduino-due make -C tests/riotboot --no-print-directory
There are unsatisfied feature requirements: riotboot
/home/francisco/workspace/RIOT/tests/riotboot/../../Makefile.include:897: *** You can let the build continue on expected errors by setting CONTINUE_ON_EXPECTED_ERRORS=1 to the command line. Stop.
or you can also do
BOARD=arduino-due make -C tests/riotboot --no-print-directory info-boards-supported | grep arduino-due
#empty
But arduous-due should be supported by a lot of applications:
BOARD=arduino-due make -C examples/default/ --no-print-directory
Building application "default" for "arduino-due" with MCU "sam3".
"make" -C /home/francisco/workspace/RIOT/boards/arduino-due
"make" -C /home/francisco/workspace/RIOT/boards/common/arduino-due
"make" -C /home/francisco/workspace/RIOT/core
...
# Compilation works fine
For more information on FEATURES you can check http://riot-os.org/api/build-system-basics.html.
I’m just concerned in case this means that no application built for the DUE is going to work correctly.
Bottom line if when compiling you don’t have a There are unsatisfied feature requirements: message then the application should work, if it does not then either some manual configuration should be done (check README, it might require some extra hardware), or there is an issue and you should open a github issue for that.
Hope this answers your question.
Thanks for the comprehensive reply :). The information I posted is just a small fragment of the 240Mb of info produced by the script, it just happens to be a fragment that refers to the board that I’m using to experiment with RIOT, which is why I paid attention to it.
I can certainly see that a DUE application should be able to work without riotboot, as the SAM-BA ( Boot Assistant, aka bootloader ) tool is present in ROM on the SAM3x8e. But to me, that would imply that riotboot cannot be ‘REQUIRED’ in general for the DUE as a board.
So I’m just not understanding the semantics here. Are you saying that everything that I posted needs to be considered in the context of a specific application, and that what I’m seeing is the output from attempting to build an application for the DUE that requires riotboot ? i.e. I should read ‘FEATURES_REQUIRED’ as ‘FEATURES_REQUIRED_BY_APPLICATION’ ?
I have an ulterior motive for generating this information, which is that I’m wondering if I can visualise the entire build system in some useful way. It’s not a foregone conclusion that this is possible, but I’m a very visual/pattern oriented person, and looking at pretty graphs of complex data structures sometimes helps me to understand things. So in addition to learning about the specifics of the DUE, which I certainly need to understand, I’m trying to understand the dimensionality of the build system, so that I can extract and feed suitable vectors into a visualisation tool like Gephi. I’ve not found anyone else who’s tried this approach with a complex makesystem before, so I’ll just have a go and see what happens.
So I’m just not understanding the semantics here. Are you saying that everything that I posted needs to be considered in the context of a specific application, and that what I’m seeing is the output from attempting to build an application for the DUE that requires riotboot ? i.e. I should read ‘FEATURES_REQUIRED’ as ‘FEATURES_REQUIRED_BY_APPLICATION’ ?
As I mentioned the script you used is a very dump script, it’s definitively not the best, and honestly, whenever used it’s hard to debug. But it’s not used that much and usually, it gets the specific jobs it was declined for done: “testing for regression”. It is therefore not meant to display all debug information for an application.
That being said you can certainly modify that script and add a FEATURES_REQUIRED_$(APPLICATION) in save_all_dependencies_resolution_variables.sh if that suit your purpose. In the current state, the script only dumps information and as you mention some indication of the application would be for sure useful, at least printing the current application. Feel free to propose such modifications in a PR or any modified scripts you might develop, it would definitively be appreciated.
I’m trying to understand the dimensionality of the build system, so that I can extract and feed suitable vectors into a visualisation tool like Gephi. I’ve not found anyone else who’s tried this approach with a complex makesystem before, so I’ll just have a go and see what happens.
This is something that should become easier to achieve when the Kconfig migration is done, @leandrolanzieri already showed me a proof of concept for this. Maybe he could point you to this? But the completion of the migration is still far ahead.
Hi @mderouss,
This PR was the first PoC of the usage of Kconfig for modelling the dependencies of our build system: [PoC] Module dependency modelling using Kconfig by leandrolanzieri · Pull Request #14055 · RIOT-OS/RIOT · GitHub, which is outdated by now, but still valid from the concept side.
As @fjmolinas pointed out there I tried to generate a graph with the relationships between modules and features. It is based on the dependencies of the Kconfig symbols that represent the modules. It still needs work, but might help you to visualize things.
As it was a PoC, it only has some modules modelled, you can run: BOARD=samr21-xpro make info-kconfig-deps -C examples/hello-world > deps.dot, and it should generate a graph of dependencies. Run it after cleaning the previous build (BOARD=samr21-xpro make clean -C examples/hello-world). Probably it is not up to date with the current RIOT master. You will need to install some python packages to run it, I believe.
Hey great ! This certainly sounds like the sort of thing I was thinking about, I’ll investigate the PoC. Thanks.