Hi Jehudi, Currently the persistent flash storage is something that's left as the responsibility of the application. Eventually, there will be proper integrated support for this, but I'd wait for

Congratulations on adding the BLE mesh functionality to zephyr so quick after the release of the standard. I am working on a smartlight based upon zephyr and would like to add the mesh functionality.

Not sure. ;-) Mostly it is illustrating that the DT status of a peripheral is (pretty much) unrelated to the mcuboot protocols to hand over peripherals. Another minor point is that while it is

Sorry, I'm not following how this is relevant to the questions about the bootloader/Zephyr boundary. Am I missing something? If this is a Zephyr internals discussion, could you please move it to

I'd describe it that Linux uses *drivers* for activation. For example, it is the driver that makes the appropriate calls (usually via clock framework, etc) to enable and clock its peripheral. So

A little bit :), perhaps. This thread is about clocks, peripherals, etc. which mcuboot may use and what should happen to them before control is passed to Zephyr; please note that this thread is also

And if connected to HW, should it be enabled and clocked? Linux uses mix of Kconfig/dt. Kconfig for compilation/dt for activation. Do we want the same in Zephyr and keep these 2 levels of

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

OK, so it sounds like these DT changes aren't expressing expectations about the state of the peripheral. But based on David's response, it does seem like it matters to Zephyr what state the

The enabled property doesn't describe whether the peripheral is active or not at bootloader handover. It is more like whether that peripheral is connected to something useful. DT describes the

I don't think so. Part of the definition of the bootloader needs to be to describe what state it leaves things in. For most compatibility, it would seem best to leave things in as close to

Hi, David's threads didn't get much response, but while looking at some STM32 rework in Zephyr, I thought it was worth another try. I especially want to highlight this part: ^^ Erwan, I noticed while

Hi All, I'll be happy to follow your work on F0, I'll like to target the F051 from the F0x1 family. Thanks, Neil

Dear All, I am currently working on a 4G(LTE) Networking task, Then I turned to zephyr to try to set it as a beginning. The Internet articles told me it supports 3GPP protocols but I didn't find

Dear All, I am currently working on a 4G(LTE) Networking task, Then I turned to zephyr to try to set it as a beginning. The Internet articles told me it supports 3GPP protocols but I didn't find

Dear all, I installed the SDK on Ubuntu 16.04 64bit system today, it's OK. So, I guess there is something wrong in the installing script of "zephyr-sdk-0.9.1-setup.run" Or the tools(x86, arm, arc....)

Hi all, I'm currently working on a pull request to introduce a Lightweight Machine-to-Machine (LwM2M) library to Zephyr. If you are interested, please

Hello, David Brown <david.brown@...> wrote: I recently hit a case when I needed to run Zephyr SDK on 32-bit system and of course, it was a rather unpleasant surprise to remember that I can't.

The SDK is indeed built for 64 bit systems. It could be built for a 32-bit host, although I don't think there has been that much demand for it. David

Dear All I got a trouble when installing zephyr SDK on Ubuntu 16.04.2 desktop i386 (32 bit) I followed the instructions exactly on page