Hi, I have a Freescale FRDM-K64 board. I cannot get the samples/hello_world/microkernel to work. Compiling with this: # make O=out-arm BOARD=frdm_k64f It compiles fine and the out-arm/zephyr.bin can

That was my first thought but I don't think we have the liberty of changing our 1.0 APIs. Andrew

Sounds good. We can use the SYS_INIT_NAMED() macro for devices that need a name for PM purpose. Do you think we should replace SYS_INIT() with the new one? i.e. just modify SYS_INIT(). I am ok

Hi all, Quoting Andre Guedes (2016-03-03 16:43:24) Do we have a consensus about this? After the "errno-drivers" patchset, DEV_* codes will be used only at 'board' and 'arch' layers. Actually, all

Hi all, Quoting Andre Guedes (2016-03-04 10:55:24) I just sent a patchset with topic "errno-drivers" implementing what we have discussed in this RFC. The patchset basically redefines DEV_* using -E*

Something that also occurred to me: we have the same issue with our boards/ directory. As Zephyr gets put on more and more boards we're going to find ourselves with different variants of each board. I

I see. So at boot it could use device_get_binding() or DEVICE_GET() to populate some data structure with device pointers which is then used at suspend/resume time. You're already calling .suspend the

The list enables the PMA to choose the order in which it suspends/resumes the devices by creating its own ordered list based on policies. If the iteration is done by the kernel then the order will

If you just need to iterate over all devices this code does the job: struct device *info; for (info = __device_init_start; info != __device_init_end; info++) { /* do stuff */ } Could add an API to

Hi, "Thomas, Ramesh" <ramesh.thomas(a)intel.com> writes: Ah, I see. Thanks. Cheers, -- Vinicius

The power manager application should be able to handle that case. It can either retry after trying other drivers, ignore that driver or abort suspend. The callback is not going to help because

Hey Vinicius,

Hi, "Thomas, Ramesh" <ramesh.thomas(a)intel.com> writes: I am thinking about the case when DEV_BUSY is returned, I am considering this would happen, for example, in the SPI case when there's a

I really think that officially supporting both printk() and printf() in the kernel is a bad idea. Having Zephyr depend on libc APIs really isn't the way to go. Zephyr should not care whether printf()

Why do you need this for the LOAPIC/IOAPIC? All its functions are private to the kernel and do not require a device pointer. Please provide a specific example on where you would need to run

Yes, I got a similar comment on gerrit, this has been done in such way because in the future more "back ends" are expected, i.e., other functions could be called hence a "back end" menu choice. But

I am not in favour of adding the stm32 layer. I am all for adding the "SoC series" or "family layer”. What this means: instead of arch/ arm/ soc/ stm32/ st_stm32f1/ st_stm32f2/

Hi Genaro, Could you give the gerrit links? Aren't these 2 being mitigated by CONFIG_STDOUT_CONSOLE ? If this option is set: printf will be used, printk otherwise. Tomasz