CC2538dk Riotboot support

Help archive
#1

Hey guys, has anyone succeeded in providing riotboot support for the cc2538dk board as yet?

#2

Hi Brenton!

So far I remember we didn't take it into account, and I don't know if someone is taking care of it.

As far as I know, there are two ways of supporting that CPU:

1. The way we do it now, which is linking the image in another start address so the bootloader can recognise it and boot it.

2. Modify the start address on the CC2538 register dedicated to this. This might be a bit tricky but also interesting for the sake of research and compatibility.

However, I'd advice the first option to have the full benefits of the bootloader and struggling less with the particular settings on that chip.

Overall, the steps would be the following:

1. Adapt the linker scripts to succeed tests/cortexm_common_ldscript. This consists on making the linker scripts on cpu/cc2838/ldscripts comply with cpu/cortexm_common/ldscrpts/cortexm.ld. You might take a look how is it done for stm32 or sam0 families.

2. Provide the length and start variables to link slots correctly:    - ROM_LEN    - RAM_LEN    - ROM_START_ADDR    - RAM_START_ADDR

Again, take a look on the supported CPUs as examples.

3. Make tests/riotboot pass

4. Perform a firmware update or flash different firmwares with different versions so the bootloader choses the newest.

Optionally you might want to test if the WIP SUIT update format works.

Don't hesitate to make more questions if you have some!

Cheers,

Paco.

#3

Hi Brenton,

if you only use the default `riotboot/flash` or `flash` in `tests/riotboot` targets, you do not need flasher changes. But you should not use `riotboot/flash-slot0` and `riotboot/flash-slot1` targets for the moment.

To have the support declared and merged in RIOT, it also needs to support flashing the `slot-` firmwares alone. These require having flasher that can flash with an offset`.

For `cc2538-bsl.py` it looks like there is the `-a` option for this.

Maybe changing it to use `IMAGE_OFFSET` if set would be enough. An example is in https://github.com/RIOT-OS/RIOT/blob/8fe12bc82cfbb83a90efd018e11c044d0a40696b/makefiles/tools/edbg.inc.mk#L14-L15

The `flash.sh` is currently using `jlink` without using the common `jlink` scripts thing, it is in my todo list after https://github.com/RIOT-OS/RIOT/pull/11554 to migrate to use the common one where applicable.

Cheers, Gaëtan

#4

Seems to me that a quick riotboot porting guide could be useful somewhere in the wiki.

1 Like
#5

Seems to me that a quick riotboot porting guide could be useful somewhere in the wiki.

More in the `riotboot` documentation in the repository I would say.

#6

FYI I opened a PR adding a WIP porting guide: https://github.com/RIOT-OS/RIOT/pull/11597

#7

Thanks for the advice guys, but I’m still struggling to get the cc2538dk to pass the riotboot tests.

I provided the length and start variables to link the slots. I used the cc2538sf53.ld Linker Script.

I was not sure how to get the offset required, so i used 255 as the offset, this value made the slot0.riot.bin file = 512KB.

I assume this correct because whenever you compile an example (not with riotboot), it generates a .bin file with this size.

Any ideas on what i could be doing wrong?

With thanks! Brenton

#8

Hey guys, i kind of managed to get the riotboot tests to pass. Whenever i program via terminal (gcc-arm) i receive the error “[FAILED] You’re not running riotboot”. But when i program via the UniFlash tool, it works. Note, so far only “tests_riotboot-slot0-combined.bin” works. I assume its an offset issue as GaĂ«tan mentioned. Also, I used the cortexm_base.ld Linker Script.

Thanks for the help guys

#9

Hi GaĂ«tan, i managed to get the tests/riotboot to pass whilst using ‘riotboot/flash-combined-slot0’. I also used the ‘-a’ option For ‘cc2538-bsl.py’. This allowed me to use the ‘riotboot/flash-slot0’ successfully. However, i couldn’t get slot 1 working. How do think i should approach this problem. And currently i can only use ‘riotboot/flash-slot0’ whilst using the ‘-a’ option For ‘cc2538-bsl.py’. What is the RIOT approach to implementing this?

With regards Brenton

#10

Hi Brenton,

I noticed there is `-e` in `FFLAGS` which performs a full erase of the rom so flashing a second slot while the first one or the bootloader is there cannot work.

We removed this full erase from all flashers for boards using `riotboot`. If the flasher erases only what is required for flashing it could be removed from the default configuration. And it was the case for `edbg/openocd/jlink`.

Regards, Gaëtan

So you can try without the `-e` in `FFLAGS` and see if first flashing `slot1` works and if it is also not destroying your normal workflow ?

#11

Hi Gaëtan

I managed to get riotboot to select the newer image between slots 0 and 1. I had to first flash “riotboot.bin” (from $RIOTBASE/bootloaders), then slots 0 and 1 without doing a full erase.

How do i link the Makefile in (boards/cc2538dk/Makefile.include) to (sys/riotboot/Makefile.include) so that i can use ‘IMAGE_OFFSET’ for the ‘-a’ option in ‘cc2538-bsl.py’. It currently says ‘IMAGE_OFFSET’ was not declared (same with SLOT(0/1)_OFFSET). Also, why was it that i needed to flash “riotboot.bin” first. Shouldn’t the bootloader automatically be flashed when using the “riotboot/flash-combined-slot0” command?

Note, the flashbase address for the cc2538 is 0x200000. I flashed “riotboot.bin” at 0x200000, then slot0 at 0x201000, then slot1 at 0x240700. For “riotboot.bin”, I compiled using SECTIONS { .flashcca : { KEEP(*(.flashcca)) } > cca } // so the filesize for “riotboot.bin” was 512KB, then slot images were around 15KB each. The CCA section consists of 44 bytes at the end of flash

Regards Brenton

#12

Please ignore my previous email. I forgot to add ‘$()’ for $(IMAGE_OFFSET). Everything seems fine now. Just need to find out how to erase the necessary flash instead of a complete erase.

Regards Brenton

#13

Please ignore my previous email. I forgot to add '$()' for $(IMAGE_OFFSET). Everything seems fine now. Just need to find out how to erase the necessary flash instead of a complete erase.

The `-e` option is used by default, if it works without it at all, you should be good.

      -e Erase (full)-