Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Contiki-NG OAP Engine - Work-in-Progress #623

Open
wants to merge 67 commits into
base: develop
from

Conversation

@g-oikonomou
Copy link
Member

g-oikonomou commented Aug 19, 2018

This is work in progress towards a Contiki-NG cross-platform OAP engine.

The design has the following components:

  • A platform-independent OAP engine under os/net/app-layer/ota.

    This is capable of manipulating an external flash (using our generic ext flash driver) in order to save an incoming image. In the future this is where we will also implement network transport, I am thinking we can have multiple different transports, e.g. pull over HTTP, push over CoAP, whathaveyou.

    Currently it just provides some external flash manipulation functions and the basic defines required by the engine.

  • A Bootloader under exampes/oap/bootloader

    Knows how to move images from external flash to internal flash and vice-versa. Knows how to validate images, how to fallback to a golden image, how to upgrade to an image of a higher version number. Knows how to jump to the main firmware once validated successfully.

    Without debugging this occupies the 2 low pages on the CC13xx/CC26xx flash (so, 8192 bytes). Third page required with debugging, which can be enabled by running make BOOTLOADER_DEBUG=1

  • Changes to the build system (Using CC13xx/CC26xx as example) in order to be able to link a relocated firmware.

  • An example of how to write/build relocated firmware under exampes/oap/golden-image.

    Just a relocated hello-world for the time being, but once we have transport layers they will be integrated here.

  • A python script tools/oap/generate-metadata.py that reads images, generates metadata for them and saves them in a hex file.

The easiest way to start is to cd into examples/oap and run make. This will build the bootloader and the golden-image, will invoke generate-metadata.py with correct arguments and will combine the two images + metadata into a hex file called image.hex. Use your favorite tool to program your device with it.

Tested on launchpad/cc2650 only and still quite rough, but I thought I'd throw it out here anyway.

Bunch of things we need to do before this can be considered seriously:

  • Tidy-up the design
  • Port for CC2538 devices
  • Test
  • Develop transport layers. (For the avoidance of doubt, I have no immediate plans to work on this. Not at this moment in time anyway.)

Shameless ping @tdesmet @MartinNPN since we've had plenty of discussions about this.

Based to a very large extent on this work by @msolters, with many many thanks. There are though fundamental differences that make the two non-interoperable.

@joakimeriksson

This comment has been minimized.

Copy link
Member

joakimeriksson commented Aug 20, 2018

Cool - we need this and we should also be compliant with this: https://github.com/runtimeco/mcuboot . Which is the base for the RIOT, Zephyr OS and Mynewt OTA/secure boot loaders.

@joakimeriksson

This comment has been minimized.

Copy link
Member

joakimeriksson commented Aug 20, 2018

(I'd be happy to help out implementing the LWM2M part of the app-layer for upgrade).

@g-oikonomou

This comment has been minimized.

Copy link
Member Author

g-oikonomou commented Aug 20, 2018

MCUboot compliance sounds like a good idea. As far as I can see they use double-buffering, swapping images using internal flash only. Have you seen it / heard about it used with ext flash?

They support signature verification which is a very desirable feature

@glaucopgomes

This comment has been minimized.

Copy link

glaucopgomes commented Oct 9, 2019

Any progress on this issue?

@g-oikonomou

This comment has been minimized.

Copy link
Member Author

g-oikonomou commented Oct 11, 2019

@glaucopgomes we discussed that a few days ago. The intention is to merge it into develop in the near future and document it as "experimental". I'll need to rabase this before we can do that of course.

The image manipulation on flash fundamentally works and rolling it out will speed-up discovery of bugs and give opportunities for improvements.

What we do not have is network transport. It makes sense for the first such transport to be lwm2m since it already provides a standard endpoint. Naturally this can also be done using a multitude of different methods.

In the longer term the plan is to also look deeper into mcuboot and upkit (ex libpull)

Lastly, this: https://tools.ietf.org/html/draft-ietf-suit-architecture-06

@g-oikonomou g-oikonomou reopened this Oct 27, 2019
@g-oikonomou g-oikonomou force-pushed the g-oikonomou:contrib/oap branch from 6f9468c to ccd472e Oct 27, 2019
@g-oikonomou

This comment has been minimized.

Copy link
Member Author

g-oikonomou commented Oct 27, 2019

I've now rebased this.

@CarlosEFML

This comment has been minimized.

Copy link

CarlosEFML commented Oct 31, 2019

If I understand, the bootloader code is located in the address range from 0x00000 to 0x02000. Are all other functions called by the bootloader (contiki functions, ti lib functions ...) also located in this range? If so, our firmware also executes the methods of these libs in this same memory region or it has these same libs replicated in the range from 0x02000 to 0x1FF9C

@CarlosEFML

This comment has been minimized.

Copy link

CarlosEFML commented Oct 31, 2019

Also, there is some errors building the example:

This is the errors when I run make in the example root dir:

acesse@acesse-550XBE-350XBE:~/Acesse/bl/contiki-ng/examples/oap$ make TARGET=cc26x0-cc13x0 BOARD=launchpad/cc1310
make -C bootloader/ bootloader.hex
make[1]: Entering directory '/home/acesse/Acesse/bl/contiki-ng/examples/oap/bootloader'
make[1]: *** No rule to make target 'bootloader.hex'. Stop.
make[1]: Leaving directory '/home/acesse/Acesse/bl/contiki-ng/examples/oap/bootloader'
Makefile:38: recipe for target 'bootloader/bootloader.hex' failed
make: *** [bootloader/bootloader.hex] Error 2


And this is the error running make inside the bootloader subdirectory:

acesse@acesse-550XBE-350XBE:~/Acesse/bl/contiki-ng/examples/oap/bootloader$ make TARGET=cc26x0-cc13x0 BOARD=launchpad/cc1310
CC ../../../../contiki-ng//arch/cpu/cc26x0-cc13x0/lib/cc13xxware/startup_files/ccfg.c
In file included from ../../../../contiki-ng//arch/platform/cc26x0-cc13x0/./contiki-conf.h:45:0,
from ../../../../contiki-ng//arch/cpu/cc26x0-cc13x0/./ccxxware-conf.h:44,
from :0:
./project-conf.h:36:25: fatal error: target-conf.h: No such file or directory
compilation terminated.
../../../../contiki-ng//arch/cpu/cc26x0-cc13x0/Makefile.cc26x0-cc13x0:76: recipe for target 'build/cc26x0-cc13x0/launchpad/cc1310/obj/ccfg.o' failed
make: *** [build/cc26x0-cc13x0/launchpad/cc1310/obj/ccfg.o] Error 1


And running from golden-image subdirectory:

acesse@acesse-550XBE-350XBE:~/Acesse/bl/contiki-ng/examples/oap/golden-image$ make TARGET=cc26x0-cc13x0 BOARD=launchpad/cc1310
Skipping golden-image: not for the 'cc26x0-cc13x0/launchpad/cc1310' platform!

@CarlosEFML

This comment has been minimized.

Copy link

CarlosEFML commented Nov 4, 2019

Hello, as I still could not compile the code, I have some doubts regarding the operation of the bootloader. My concern is if the bootloader (during update) is executing code located in an area that is being overwritten by the update process.

@g-oikonomou

This comment has been minimized.

Copy link
Member Author

g-oikonomou commented Nov 4, 2019

I'll have a look at it when I get a chance. Perhaps I broke something during the rebase, it was a rather painful one

@g-oikonomou g-oikonomou force-pushed the g-oikonomou:contrib/oap branch from ccd472e to f0a49bb Nov 9, 2019
@g-oikonomou

This comment has been minimized.

Copy link
Member Author

g-oikonomou commented Nov 9, 2019

@CarlosEFML I've fixed a few things. It should behave more reasonably now...

@CarlosEFML

This comment has been minimized.

Copy link

CarlosEFML commented Nov 13, 2019

Thank you g-oikonomou, it's working perfectly now!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.