Date   

Re: Zephyr DFU protocol

David Brown
 

On Wed, Aug 30, 2017 at 09:38:44AM +0000, Cufi, Carles wrote:

That would be my preference as well, but it might not be as trivial
as it sounds. I need to discuss this further with the Mynewt
developers, because some of the abstractions (namely mbuf) might not
be easy to port. Once we choose a protocol, and if this ends up being
NMP, I would like to start those discussions ASAP with the
contributions of the Mynewt community.
I think we should go ahead and start the conversation with them, on
mailing lists.

Unfortunately, the Mynewt mailing lists add a Reply-to header, which
causes that list to "steal" replies that are cross posted. So, you
if you send to both the Zephyr and the Mynewt list, the replies will
randomly discard the Zephyr list, which tends to fork threads
(randomly because it depends on which mailing list server replies
quicker, and which message a given recipient's mail system decides to
use, gmail tends to use the first one, for example).

Feel free to help me apply pressure to get their list configuration
fixed.

David


Re: Zephyr DFU protocol

David Brown
 

On Tue, Aug 29, 2017 at 04:24:14PM -0700, Pushpal Sidhu wrote:
On Tue, Aug 29, 2017 at 12:24 PM, David Brown <david.brown@linaro.org> wrote:
On Tue, Aug 29, 2017 at 12:03:04PM -0700, Pushpal Sidhu wrote:

Sounds like you want an SPL (which I'm for).
We've discussed this, because it does seem like it could be useful.
But, the conclusion we mostly come to is that nearly everything that
would be in the secondary loader has to be in the primary, and the
secondary doesn't end up doing much.
I'm having trouble finding that discussion. Could you point me to it?
I'm curious as to why the primary was thought to re-perform the same
functions as the SPL in this case. We don't have to follow the
traditional u-boot model I would think.
I'm not sure it was written down, or just verbal or IRC chat. I
didn't find any logs about it.

To be honest, I'm unfamiliar with mcuboot for now so I'm not totally
sure what it's doing. I'm also unaware of how zephyr is loaded by the
bootloader (I'm new to this project) so I may be speaking nonsense.
Currently, the bootloader doesn't really "load" anything, since it is
only being used on execute-in-place targets. It's main job is to:

- Verify the signature of the image before booting it.

- Detect a properly signed image in an upgrade partition, and safely
exchanging the two images.

David


Re: request of help

Boie, Andrew P
 

Per https://www.zephyrproject.org/doc/getting_started/installation_linux.html

You need to install python 3 dependencies with pip:

 

$ pip3 install --user -r scripts/requirements.txt

 

I wonder if there is a way to make this clearer, a few people have tripped over this.

 

Andrew

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Novello Giampiero
Sent: Wednesday, August 30, 2017 5:21 AM
To: devel@...
Subject: [Zephyr-devel] request of help

 

I try to compile samples/hello_word
following the instruction on the web.
I'm using an ubuntu 16.04  64bit.

I find a mistake ...

It never find this tools ==> elftools.elf.elffile import ELFFile

I made pip install  pip install pyelftools  but i have the same mistake.

May You help me?

I want to compile forn stm32f4 have you got some suggestion?

May I use the lava tools for the test of my board? in with way ?

Best Regards end Thanks

Novello G.

 

 

Se the error...

 

cd  zephyr/zephyr-git/samples/hello_world
cd make BOARD=arduino_101
And I have this error in a ubuntu 16.04 64 bit
2]: Entering directory
'/home/novello/stm32/zephyr/zephyr-git/samples/hello_world/outdir/arduino_101'
   GEN     ./Makefile
scripts/kconfig/conf --silentoldconfig Kconfig
   DTC     dts/x86/arduino_101.dts_compiled
   CHK     include/generated/generated_dts_board.conf
   UPD     include/generated/generated_dts_board.conf
   CHK     include/generated/generated_dts_board.conf
   Using /home/novello/stm32/zephyr/zephyr as source for kernel
   GEN     ./Makefile
   CHK     include/generated/version.h
   UPD     include/generated/version.h
   CHK     include/generated/generated_dts_board.h
   UPD     include/generated/generated_dts_board.h
   CHK     misc/generated/configs.c
   UPD     misc/generated/configs.c
   CHK     include/generated/offsets.h
Traceback (most recent call last):
   File "/home/novello/stm32/zephyr/zephyr/scripts/gen_offset_header.py",line
8, in
     from elftools.elf.elffile import ELFFile
ImportError: No module named 'elftools'
/home/novello/stm32/zephyr/zephyr/./Kbuild:54: recipe for target
'include/generated/offsets.h' failed
make[3]: *** [include/generated/offsets.h] Error 1
/home/novello/stm32/zephyr/zephyr/Makefile:1085: recipe for target 'prepare'
failed
make[2]: *** [prepare] Error 2
make[2]: Leaving directory
'/home/novello/stm32/zephyr/zephyr-git/samples/hello_world/outdir/arduino_101'
Makefile:178: recipe for target 'sub-make' failed
make[1]: *** [sub-make] Error 2
make[1]: Leaving directory '/home/novello/stm32/zephyr/zephyr'
/home/novello/stm32/zephyr/zephyr/Makefile.inc:82: recipe for target 'all'
failed
make: *** [all] Error 2


Re: bitfields

Kumar Gala
 

On Aug 29, 2017, at 4:20 AM, Cufi, Carles <Carles.Cufi@nordicsemi.no> wrote:

Hi Andrew,

-----Original Message-----
From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-
bounces@lists.zephyrproject.org] On Behalf Of Boie, Andrew P
Sent: 28 August 2017 18:52
To: Piotr Mienkowski <piotr.mienkowski@gmail.com>; zephyr-
devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] bitfields

I believe you are talking about a solution used currently by Zephyr's
I2C API.
There we have:

union dev_config {
u32_t raw;
struct __bits {
u32_t use_10_bit_addr : 1;
u32_t speed : 3;
u32_t is_master_device : 1;
u32_t reserved : 26;
} bits;
};

This is however incorrect. C99 §6.7.2.1, paragraph 10 says: "The order
of allocation of bit-fields within a unit (high-order to low-order or
low-order to
high-order) is implementation-defined.". I.e. - using union dev_config
as an example - compiler is free to map use_10_bit_addr either to MSB
or to LSB. The two methods of specifying bit fields are not equivalent
and should not be mixed.

I think we have a fair number of drivers that define structs that use
the above technique, to have fields in the struct which correspond to
particular bits in a register.

Or see the data structures like in

arch/x86/include/mmustructs.h
include/arch/x86/segmentation.h

Which have complex data structures to define segment descriptors and
page table entries.

You are saying that these are all incorrect? Should we change them?
GCC at least, seems to always do low order to high order.
We have exactly the same in all of our Link Layer definitions in Bluetooth, which all use bitfields for the packet structures (and which must obviously be endianness independent):
https://github.com/zephyrproject-rtos/zephyr/blob/master/subsys/bluetooth/controller/ll_sw/pdu.h#L344

Coincidentally while looking into a firmware update protocol I saw that the Newt Manager Protocol does indeed compile the bitfields differently based on endianness:

https://github.com/apache/mynewt-core/blob/master/mgmt/mgmt/include/mgmt/mgmt.h#L72
I wondering when we try and support compilers beyond gcc & clang if we will run into issues with bitfields. I think we should stay away from them unless we can figure out an assert or something to catch issues really early on.

- k


Re: request of help

Maciej Dębski <maciej.debski@...>
 

Hello Novello,

there was this informative e-mail on zephyr-devel group on 24th of July, which might help you:

Some changes are coming in to convert host build tools like gen_idt and gen_offset_header to Python, as well as some new tools to support memory protection which involve parsing DWARF information in the built ELF binaries.

 

To support this change, we will additionally require the Python 3 build of the pyelftools package, version 0.24 or later. You will need to install this on your development workstation. Please note that some Linux distristributions are out-of-date on this package, including the current version of Fedora and Ubuntu 16.04 and earlier. Because of this we recommend installing this via 'pip'. The documentation will be updated when the patches land, but in brief:

 

  pip3 install --user pyelftools

 

You may need to install the Python 3 version of pip, the package name on both Ubuntu and Fedora is 'python3-pip'.

also, be sure you did all the steps correctly from zephyr documentation:

That is it from me, I know it is not much, but I had a similar issue so I am trying to help. You surely have to look into your python packages, maybe someone else will provide you with more in-depth analysis. Good luck!


 

On Wed, Aug 30, 2017 at 2:21 PM, Novello Giampiero <novellogp64@...> wrote:
I try to compile samples/hello_word
following the instruction on the web.
I'm using an ubuntu 16.04  64bit.
I find a mistake ...
It never find this tools ==> elftools.elf.elffile import ELFFile
I made pip install  pip install pyelftools  but i have the same mistake.
May You help me?
I want to compile forn stm32f4 have you got some suggestion?
May I use the lava tools for the test of my board? in with way ?
Best Regards end Thanks
Novello G.


Se the error...

cd  zephyr/zephyr-git/samples/hello_world
cd make BOARD=arduino_101
And I have this error in a ubuntu 16.04 64 bit
2]: Entering directory
'/home/novello/stm32/zephyr/zephyr-git/samples/hello_world/outdir/arduino_101'
   GEN     ./Makefile
scripts/kconfig/conf --silentoldconfig Kconfig
   DTC     dts/x86/arduino_101.dts_compiled
   CHK     include/generated/generated_dts_board.conf
   UPD     include/generated/generated_dts_board.conf
   CHK     include/generated/generated_dts_board.conf
   Using /home/novello/stm32/zephyr/zephyr as source for kernel
   GEN     ./Makefile
   CHK     include/generated/version.h
   UPD     include/generated/version.h
   CHK     include/generated/generated_dts_board.h
   UPD     include/generated/generated_dts_board.h
   CHK     misc/generated/configs.c
   UPD     misc/generated/configs.c
   CHK     include/generated/offsets.h
Traceback (most recent call last):
   File "/home/novello/stm32/zephyr/zephyr/scripts/gen_offset_header.py",line
8, in
     from elftools.elf.elffile import ELFFile
ImportError: No module named 'elftools'
/home/novello/stm32/zephyr/zephyr/./Kbuild:54: recipe for target
'include/generated/offsets.h' failed
make[3]: *** [include/generated/offsets.h] Error 1
/home/novello/stm32/zephyr/zephyr/Makefile:1085: recipe for target 'prepare'
failed
make[2]: *** [prepare] Error 2
make[2]: Leaving directory
'/home/novello/stm32/zephyr/zephyr-git/samples/hello_world/outdir/arduino_101'
Makefile:178: recipe for target 'sub-make' failed
make[1]: *** [sub-make] Error 2
make[1]: Leaving directory '/home/novello/stm32/zephyr/zephyr'
/home/novello/stm32/zephyr/zephyr/Makefile.inc:82: recipe for target 'all'
failed
make: *** [all] Error 2


_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel



Re: Direct flash access from filesystem

David Brown
 

On Mon, Aug 21, 2017 at 11:30:29AM +0000, Cufi, Carles wrote:

Well, NFFS is a *flash* filesystem, it's expected that it would require
more specific underlying device type than a generic FS like FAT which
can work on any block device. The situation is similar to Linux, where
JFFS2, etc. require not just a block device, but /dev/mtd (memory
technology device).

So, I wouldn't be surprised that such a requirement arises, but how to
deal with it - extend existing block device interface in Zephyr,
introduce a separate MTD interface, or just work on top of existing
flash drivers, if they are generic enough - that's what more
experienced folks may suggest, I hope.
I think that working directly on top of (standard) flash drivers for
a flash filesystem is quite reasonable, since there is no reason to
have an additional layer in this particular case. Whether that might
have consequences in the future if multiple filesystems are mounted I
do not know.
Sorry to chime in later here. It isn't just that there is no reason
to have intermediate layers, NFFS _needs_ to be talking directly to
the flash in order for it to be robust. NFFS has an understanding of
how flash works, and is setup to erase whole blocks, and then
incrementally write to them, and then perform garbage collection. It
does this in a way that keeps the filesystem always consistent, and
any types of power failures can be recovered from.

If there were another layer managing the flash device, not only would
it be inefficient (esentially doing flash mapping twice), but the
robustness and recovery wouldn't work.

Unless there is a lot of flash, it will probably need to be a
configuration choise between NFFS and FAT. NFFS is appropraite for a
NOR type device that is typically found internally on MCUs. FAT is
more appropriate for a managed flash memory, such as SD or eMMC. FAT
also has the advantage that it can be exported via USB mass storage,
whereas that is much more difficult with NFFS.

David


Zephyr SDK 0.9.2-rc1

Nashif, Anas
 

Hi,

 

We have a new SDK release candidate available @ https://github.com/zephyrproject-rtos/meta-zephyr-sdk/releases/tag/0.9.2-rc1:

 

 

Following changes since 0.9.1:

 

* openocd 0.10.0

  * Zephyr support in openocd

* qemu 2.10.0-rc4

   * 2.10.0-rc4: x86, arm, nios, xtensa

   * 2.7.50: riscv32

* bossac tool update

 

Known Issues:

 

* qemu for NIOS is not compatible with the board configuration available in Zephyr. Work on a fix is in progress.

 

 

Please give it a try and report any issues.

 

Thanks

Anas

 

 


request of help

novello
 

I try to compile samples/hello_word
following the instruction on the web.
I'm using an ubuntu 16.04  64bit.
I find a mistake ...
It never find this tools ==> elftools.elf.elffile import ELFFile
I made pip install  pip install pyelftools  but i have the same mistake.
May You help me?
I want to compile forn stm32f4 have you got some suggestion?
May I use the lava tools for the test of my board? in with way ?
Best Regards end Thanks
Novello G.


Se the error...

cd  zephyr/zephyr-git/samples/hello_world
cd make BOARD=arduino_101
And I have this error in a ubuntu 16.04 64 bit
2]: Entering directory
'/home/novello/stm32/zephyr/zephyr-git/samples/hello_world/outdir/arduino_101'
   GEN     ./Makefile
scripts/kconfig/conf --silentoldconfig Kconfig
   DTC     dts/x86/arduino_101.dts_compiled
   CHK     include/generated/generated_dts_board.conf
   UPD     include/generated/generated_dts_board.conf
   CHK     include/generated/generated_dts_board.conf
   Using /home/novello/stm32/zephyr/zephyr as source for kernel
   GEN     ./Makefile
   CHK     include/generated/version.h
   UPD     include/generated/version.h
   CHK     include/generated/generated_dts_board.h
   UPD     include/generated/generated_dts_board.h
   CHK     misc/generated/configs.c
   UPD     misc/generated/configs.c
   CHK     include/generated/offsets.h
Traceback (most recent call last):
   File "/home/novello/stm32/zephyr/zephyr/scripts/gen_offset_header.py",line
8, in
     from elftools.elf.elffile import ELFFile
ImportError: No module named 'elftools'
/home/novello/stm32/zephyr/zephyr/./Kbuild:54: recipe for target
'include/generated/offsets.h' failed
make[3]: *** [include/generated/offsets.h] Error 1
/home/novello/stm32/zephyr/zephyr/Makefile:1085: recipe for target 'prepare'
failed
make[2]: *** [prepare] Error 2
make[2]: Leaving directory
'/home/novello/stm32/zephyr/zephyr-git/samples/hello_world/outdir/arduino_101'
Makefile:178: recipe for target 'sub-make' failed
make[1]: *** [sub-make] Error 2
make[1]: Leaving directory '/home/novello/stm32/zephyr/zephyr'
/home/novello/stm32/zephyr/zephyr/Makefile.inc:82: recipe for target 'all'
failed
make: *** [all] Error 2


Small ADC API update.

Kruszewski, Michal <Michal.Kruszewski@...>
 

I would like to introduce some small ADC API update. 


It changes timing units from clock ticks to human friendly microseconds.

It also introduces separate parameter for sampling interval as it may differ from sampling delay.


It needs updating existing ADC drivers but it should not take much time. especially for developers who know these platforms.


https://github.com/zephyrproject-rtos/zephyr/pull/1296


Regards,

Michał Kruszewski


Re: Zephyr DFU protocol

Carles Cufi
 

Hi David,

-----Original Message-----
From: David Brown [mailto:david.brown@linaro.org]
Sent: 29 August 2017 15:57
To: Cufi, Carles <Carles.Cufi@nordicsemi.no>
Cc: zephyr-devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] Zephyr DFU protocol

On Tue, Aug 29, 2017 at 09:14:31AM +0000, Cufi, Carles wrote:

While having one single protocol would definitely be a boon, I am not
sure LWM2M will fit the bill in terms of RAM and ROM requirements, and
we still need something for the UART recovery mode in the bootloader,
which will probably end up being the Newt Manager Protocol since I
don't think we can fit LWM2M into a bootloader.
Given that there are other parties that have an interest in lwm2m, I
think we should put our focus into supporting newtmgr for upgrades.
The other protocols (lwm2m, and USB DFU) will probably be implemented as
there is need for them.
I completely agree with you. I would like to focus our (Nordic's) efforts into the simple protocol first, that works over UART and BLE, while the work towards LWM2M and other advanced protocols proceeds in parallel. The image management code will of course be protocol-independent, so once those PRs that Andrzej has sent are merged all other teams will be able to benefit from them.


What would be nice would be to take the target-side newtmgr code, and
make it into its own project. We would need to refactor and abstract
the operating system interfaces so that we can use the same codebase for
multiple platforms. This would be similar to how mcuboot is now its own
project that works on Zephyr and Mynewt (and soon RIOT).
That would be my preference as well, but it might not be as trivial as it sounds. I need to discuss this further with the Mynewt developers, because some of the abstractions (namely mbuf) might not be easy to port. Once we choose a protocol, and if this ends up being NMP, I would like to start those discussions ASAP with the contributions of the Mynewt community.

Regards,

Carles


Re: Zephyr DFU protocol

Carles Cufi
 

Hi David,

-----Original Message-----
From: David Brown [mailto:david.brown@linaro.org]
Sent: 29 August 2017 15:49
To: Cufi, Carles <Carles.Cufi@nordicsemi.no>
Cc: zephyr-devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] Zephyr DFU protocol

On Tue, Aug 29, 2017 at 09:14:31AM +0000, Cufi, Carles wrote:

One other protocol I just realized is already out there is lwm2m.
There is starting to be some support for it in Zephyr, it works over
other transports, supports device management, and has support for
firmware update.
I just read through the highlights of the spec and indeed this matches
relatively closely the concept we are trying to push here with a
"management" protocol. After looking through it a bit here are the
problems I see:

a) Complexity: By reading through the specification[i] this looks like
a pretty complex protocol to me, which in many cases might be a
drawback to users wanting to reduce ROM and RAM size. This is
particularly important for very constrained devices that only need to
send some sensor data over BLE for example
I had a conversation with Sterling Hughes yesterday, and he explained
that this was pretty much the primary reason for developing the news
manager protocol instead of just using lwm2m.
Good to hear we found the same issues then. The thing is that Device Firmware Upgrade can target a wide variety of different uses in wildly unrelated hardware. In the context of small sensor-type devices with a BLE stack and little more, having LWM2M seems to be overkill, so there does not seem to be a universal firmware update protocol that would fit the whole spectrum of MCUs and applications that can run Zephyr.


b) Suitability for other transports: The specification clearly states
2 main transports: UDP and SMS. While adapting this to other transports
would likely be feasible, the protocol doesn't look designed for it
c) Model: the protocol seems to rest on the basis of a "pull" model,
where clients are the target devices. For the reasons stated before,
this might not be suitable to simple UART, BLE or USB CDC ACM usecases.
This is the other main reason for its infeasibility.
Yep, I can't quite see a UART "client" polling for a server on the other side. I'm sure it can be done, I'm less sure that it makes sense.

But all in all we are completely aligned it seems with Runtime with regard to the necessity for a protocol like NMP.


That said, the protocol does match the Newt Manager Protocol quite
closely when it comes to supported functionality and purpose. My vote
here would be to have support for both, because I do not think running
LWM2M over UART or BLE is a good match for tiny constrained
applications that only require simple firmware updates.
Agreed. I think that lwm2m is going to end up needing to be implemented
because there will be environments that will require that specific
protocol. But, we will want something like newtmgr for other cases, and
situations where less code is desired.
Yes, and probably not only LWM2M. For example our Nordic Thread SDK uses multicast to distribute images to all devices in the Thread network. That might also be a valid mechanism (i.e. "multi-push") for certain transports. It is actually similar to what NMP is doing with OIC/OCF.

It is also possible for newtmgr to be layered differently, depending on
the situation. For serial, it can either be used directly, or in a
console friendly manner (with escape characters and base-64 encoding).
It is possible to leave minicom or picocom running, and have newtmgr
connect to the serial port to exchange packets.

On BLE, it can be transported directly over GATT.

And for network interfaces, layering it over COAP or COAPS makes sense.
Yep, and there are transports already for those except the CoAP one in the current Mynewt codebase (unless you count the OIC variant). That is one of the strengths of NMP: it makes almost no assumptions about the underlying transport.

I have also spoken to Sterling btw, and it looks like we are all of the same opinion.

Regards,

Carles


Re: [BLE] Qualification

Chettimada, Vinayak Kariappa
 

Hi Richard,

if i am using a nordic nrf52832 or nrf52840 on a module, i often get a fully
bluetooth qualified solution, so just the bluetooth listing fees
(delcaration) must be paid for production.

Is the Zephyr-Stack also bluetooth qualified? Is there something special to
attend, if using a bluetooth module along with zephyr?
[vich] As of today, there is no qualification listing of the Zephyr host or controller component, but both Host and Controller components pass the PTS test suite and, HCI and LL conformance tests respectively for Full featured Bluetooth version 5.0 (except Advertising Extensions, under development).
You can contact me and Carles for more details on qualification listing for nRF5 SoCs.

I have seen this page in the docs, which seems to be related:
https://www.zephyrproject.org/doc/subsystems/bluetooth/qualification.ht
ml

But what does it mean exactly?
Do i have to do an own qualification testing, when using zephyr?
[vich]
The page represent the test coverage of the Host component. Unfortunately, we have not done similar page for Controller due to lack of time. We do have the ICS and test reports from conformance testers (Ellisys Bluetooth Qualifier).

-Vinayak


[BLE] Qualification

Richard Peters <mail@...>
 

Hi Community,

if i am using a nordic nrf52832 or nrf52840 on a module, i often get a
fully bluetooth qualified solution, so just the bluetooth listing fees
(delcaration) must be paid for production.

Is the Zephyr-Stack also bluetooth qualified? Is there something special
to attend, if using a bluetooth module along with zephyr?

I have seen this page in the docs, which seems to be related:
https://www.zephyrproject.org/doc/subsystems/bluetooth/qualification.html

But what does it mean exactly?
Do i have to do an own qualification testing, when using zephyr?

Thank you very much,

Regards,
Richard


Re: Zephyr DFU protocol

Pushpal Sidhu
 

On Tue, Aug 29, 2017 at 12:24 PM, David Brown <david.brown@linaro.org> wrote:
On Tue, Aug 29, 2017 at 12:03:04PM -0700, Pushpal Sidhu wrote:

Sounds like you want an SPL (which I'm for).
We've discussed this, because it does seem like it could be useful.
But, the conclusion we mostly come to is that nearly everything that
would be in the secondary loader has to be in the primary, and the
secondary doesn't end up doing much.
I'm having trouble finding that discussion. Could you point me to it?
I'm curious as to why the primary was thought to re-perform the same
functions as the SPL in this case. We don't have to follow the
traditional u-boot model I would think.

To be honest, I'm unfamiliar with mcuboot for now so I'm not totally
sure what it's doing. I'm also unaware of how zephyr is loaded by the
bootloader (I'm new to this project) so I may be speaking nonsense.

It is also hard to work with such memory constrained devices. It is
difficult to get mcuboot down to 16KB (depends on the signature
algorithms), and with needing two code partitions to safely upgrade,
it limits a lot of what we can do with this.

Maybe doing a two stage boot would be useful for environments that
have larger codespace.

David


Re: Zephyr DFU protocol

David Brown
 

On Tue, Aug 29, 2017 at 12:03:04PM -0700, Pushpal Sidhu wrote:

However, one of the considerations of the bootloader is that it has to
be immutable (it can never be upgraded), since it is the beginning of
the root of trust. We'd like to keep as much complexity out of it as
possible. I've even pushed to get rid of the "swap" code it currently
has, and instead move that complexity up a layer or to, and deploy one
of two images at both addresses, and just run the images in place in
the slot containing the desired image.
Sounds like you want an SPL (which I'm for).
We've discussed this, because it does seem like it could be useful.
But, the conclusion we mostly come to is that nearly everything that
would be in the secondary loader has to be in the primary, and the
secondary doesn't end up doing much.

It is also hard to work with such memory constrained devices. It is
difficult to get mcuboot down to 16KB (depends on the signature
algorithms), and with needing two code partitions to safely upgrade,
it limits a lot of what we can do with this.

Maybe doing a two stage boot would be useful for environments that
have larger codespace.

David


Re: Zephyr DFU protocol

Pushpal Sidhu
 

On Tue, Aug 29, 2017 at 8:24 AM, David Brown <david.brown@linaro.org> wrote:

On Tue, Aug 29, 2017 at 04:03:13PM +0200, Richard Peters wrote:

There will need to be sufficient flash set aside for the second image.
In most configuration, this is a dedicated partition, which avoids
needing to have filesystem management code in the bootloader.

May be a zip compression helpful to reduce the image size in flash?

Something like this is certainly doable (choosing a compression
algorithm that doesn't have large memory requirements, though, is
important).

However, one of the considerations of the bootloader is that it has to
be immutable (it can never be upgraded), since it is the beginning of
the root of trust. We'd like to keep as much complexity out of it as
possible. I've even pushed to get rid of the "swap" code it currently
has, and instead move that complexity up a layer or to, and deploy one
of two images at both addresses, and just run the images in place in
the slot containing the desired image.
Sounds like you want an SPL (which I'm for).


David

_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: Zephyr DFU protocol

David Brown
 

On Tue, Aug 29, 2017 at 04:03:13PM +0200, Richard Peters wrote:

There will need to be sufficient flash set aside for the second image.
In most configuration, this is a dedicated partition, which avoids
needing to have filesystem management code in the bootloader.
May be a zip compression helpful to reduce the image size in flash?
Something like this is certainly doable (choosing a compression
algorithm that doesn't have large memory requirements, though, is
important).

However, one of the considerations of the bootloader is that it has to
be immutable (it can never be upgraded), since it is the beginning of
the root of trust. We'd like to keep as much complexity out of it as
possible. I've even pushed to get rid of the "swap" code it currently
has, and instead move that complexity up a layer or to, and deploy one
of two images at both addresses, and just run the images in place in
the slot containing the desired image.

David


Re: Zephyr DFU protocol

Richard Peters <mail@...>
 

Hi David,

There will need to be sufficient flash set aside for the second image.
In most configuration, this is a dedicated partition, which avoids
needing to have filesystem management code in the bootloader.
May be a zip compression helpful to reduce the image size in flash?

Richard


Re: Zephyr DFU protocol

David Brown
 

On Tue, Aug 29, 2017 at 09:14:31AM +0000, Cufi, Carles wrote:

While having one single protocol would definitely be a boon, I am not
sure LWM2M will fit the bill in terms of RAM and ROM requirements,
and we still need something for the UART recovery mode in the
bootloader, which will probably end up being the Newt Manager
Protocol since I don't think we can fit LWM2M into a bootloader.
Given that there are other parties that have an interest in lwm2m, I
think we should put our focus into supporting newtmgr for upgrades.
The other protocols (lwm2m, and USB DFU) will probably be implemented
as there is need for them.

What would be nice would be to take the target-side newtmgr code, and
make it into its own project. We would need to refactor and abstract
the operating system interfaces so that we can use the same codebase
for multiple platforms. This would be similar to how mcuboot is now
its own project that works on Zephyr and Mynewt (and soon RIOT).

David


Re: Zephyr DFU protocol

David Brown
 

On Tue, Aug 29, 2017 at 02:58:55PM +0200, Richard Peters wrote:

My devices are in a BLE mesh network with no direct internet
connectivity to the outer world.
The user can connect with a smartphone ot tablet to one of the devices
in the mesh over BLE.
There is an App, which downloads the latest firmware for the devices to
the smartphone.

A firmware update will be transfered via BLE to the connected device and
then spread to all devices in the mesh that need this update.

I think there are two possible ways to achieve this:

1.) The update gets transferred to the target devices via bluetooth.
This happend in the zephyr application and gets stored in a filesystem
(on internal or external flash memory). The bootloader performs the
update from the filesystem after a reboot.
How this works in Mynewt (and will with Zephyr, if we use newtmgr) is
that mcuboot has two partitions: slot0 is where the primary code
lives, and slot1 is where the upgrade is written. It can be written
a bit at a time until complete. Then, a reboot into mcuboot will
cause the bootloader to detect the upgrade, and initiate swapping the
two images.

2.) The bootloader starts and receives the firmware (on the fly) from
the next device in the mesh network (which is running zephyr, too).
I'm not sure if this has been implemented, but it certainly could be.
Again, it would take the firmware from slot0 on the source device, and
place it into slot1 on the upgrading device.

The whole process should be optimized for the memory usage.
There will need to be sufficient flash set aside for the second image.
In most configuration, this is a dedicated partition, which avoids
needing to have filesystem management code in the bootloader.

The images themselves are signed, and upgrades with invalid signatures
will just be ignored.

David

5241 - 5260 of 8513