Date   

about dynamic loadable module support at running time.

曹子龙
 

Hi:

   i am getting stated developting based on zephyr sdk 1.7.0,  i am trying to add the dynamic loadable module support function at running time,  some thinks like that:

    install a.drv during running time,  
    " mod_install("/path/to/a.drv")",

     and removing it out with calling 
       "mod_uninstall(handle)"

and i dont want to enable the MMU suport because it would affect the REAL-TIME ability  of the system,  so, the question is,  i have to manage the running address of each  loadable module manually  without MMU to avoid the address conflicts between modules.  so any suggestions about this?   did zephyr plat to support this feature in the future? and how ? 



 


Zephyr install on new board !

eladyaakovi@campus.technion.ac.il <eladyaakovi@...>
 

Hi,

I want to install and configure Zephyr OS to work on DragonBoard 410c,

can you please let me know the steps to support new hardware ?



Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/12786 : tests: tickless: remove unused code
- https://gerrit.zephyrproject.org/r/12787 : MAINTAINERS: update for network applications
- https://gerrit.zephyrproject.org/r/12785 : tests: move fs test to tests/subsys/
- https://gerrit.zephyrproject.org/r/12780 : timer: tickless: arcv2: Add tickless kernel support
- https://gerrit.zephyrproject.org/r/12781 : samples: power: Time is passed as mili seconds in tickless kernel
- https://gerrit.zephyrproject.org/r/12784 : Bluetooth: controller: Use defined keyword in #if cond compiles
- https://gerrit.zephyrproject.org/r/12783 : Bluetooth: controller: Group dup filter Kconfig with buf options

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/11187 : tests: kernel: add test point k_cpu_atomic_idle
- https://gerrit.zephyrproject.org/r/12605 : dma: stm32f4x: Fix warning when !SYS_LOG_INF
- https://gerrit.zephyrproject.org/r/12766 : arm: cortex-m: Allow flash image size to be constrained
- https://gerrit.zephyrproject.org/r/12721 : boards: arm: Add support for Silabs EFM32WG-STK3800
- https://gerrit.zephyrproject.org/r/12723 : drivers: serial: Add uart driver for Silabs EXX32 MCUs
- https://gerrit.zephyrproject.org/r/12720 : arm: exx32: Add Silabs EFM32WG soc files
- https://gerrit.zephyrproject.org/r/12739 : ext: Integrate Silabs Gecko SDK into Zephyr
- https://gerrit.zephyrproject.org/r/12722 : drivers: gpio_gecko: Add gpio driver for Silabs EXX32 MCUs
- https://gerrit.zephyrproject.org/r/11787 : timer: tickless: hpet: Add tickless kernel support
- https://gerrit.zephyrproject.org/r/12741 : timer: tickless: cortex_m: Add tickless kernel support
- https://gerrit.zephyrproject.org/r/11839 : timer: tickless: loapic: Add tickless kernel support
- https://gerrit.zephyrproject.org/r/11786 : kernel: tickless: Add tickless kernel support
- https://gerrit.zephyrproject.org/r/11667 : samples: tickless: Enables tickless kernel option in some apps
- https://gerrit.zephyrproject.org/r/11956 : [RFC] boards: add board meta-data
- https://gerrit.zephyrproject.org/r/11954 : [RFC] tests: samples: convert testcase files to yaml
- https://gerrit.zephyrproject.org/r/12693 : [RFC] sanitycheck: support testcases in yaml instead of ini
- https://gerrit.zephyrproject.org/r/12745 : kernel: tickless: Rename _Swap to allow creation of macro
- https://gerrit.zephyrproject.org/r/11785 : kernel: tickless: Add function to check if list contains multiple nodes
- https://gerrit.zephyrproject.org/r/12763 : Bluetooth: conn: Pass disconnect error properly to the conn struct
- https://gerrit.zephyrproject.org/r/12764 : Bluetooth: conn: Set initial responder address when connecting

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/12782 : build: use -O2 instead of -Os for ARC with SDK 0.9
- https://gerrit.zephyrproject.org/r/12751 : tests: driver: uart: fix unchecked return value
- https://gerrit.zephyrproject.org/r/11216 : tests: kernel: added clock_test
- https://gerrit.zephyrproject.org/r/12439 : scripts/dfuutil: support both "alternate setting" name and number
- https://gerrit.zephyrproject.org/r/12611 : debug: Remove dependency of unsetting X86_IAMCU for CONFIG_DEBUG_INFO.


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/12764 : Bluetooth: conn: Set initial responder address when connecting
- https://gerrit.zephyrproject.org/r/12763 : Bluetooth: conn: Pass disconnect error properly to the conn struct
- https://gerrit.zephyrproject.org/r/12768 : net: dns: Invalid memory access
- https://gerrit.zephyrproject.org/r/12769 : tests: net: tcp: Fix NULL pointer dereference
- https://gerrit.zephyrproject.org/r/12770 : drivers/eth/mcux: Make sure not to leak net_buf in RX
- https://gerrit.zephyrproject.org/r/12779 : net: tcp: Release buf after failing to send.
- https://gerrit.zephyrproject.org/r/12778 : drivers: i2c: rename IRQ SHARED/DIRECT Kconfig options
- https://gerrit.zephyrproject.org/r/12766 : arm: cortex-m: Allow flash image size to be constrained
- https://gerrit.zephyrproject.org/r/12767 : net: tcp: Store MSS in tcp header correctly

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/12610 : Timer: Add TICKLESS_KERNEL support for nrf_rtc_timer.
- https://gerrit.zephyrproject.org/r/11967 : xtensa: switch toolchain to shared overlay
- https://gerrit.zephyrproject.org/r/12752 : build: add MSYS dependenc to Makefile
- https://gerrit.zephyrproject.org/r/12623 : net: nbuf: Add function to split a data fragment
- https://gerrit.zephyrproject.org/r/12627 : net: shell: Add IPv6 fragmentation info printing
- https://gerrit.zephyrproject.org/r/12625 : net: ipv6: Add helper to get the last extension header
- https://gerrit.zephyrproject.org/r/12626 : net: ipv6: Support fragmented IPv6 packets
- https://gerrit.zephyrproject.org/r/12720 : arm: exx32: Add Silabs EFM32WG soc files
- https://gerrit.zephyrproject.org/r/12739 : ext: Integrate Silabs Gecko SDK into Zephyr
- https://gerrit.zephyrproject.org/r/12749 : drivers: Add Atmel SAM serial (UART) driver
- https://gerrit.zephyrproject.org/r/12721 : boards: arm: Add support for Silabs EFM32WG-STK3800

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/12777 : drivers: i2c: place all I2C Kconfig options in submenu
- https://gerrit.zephyrproject.org/r/12776 : drivers: i2c: rename I2C_CLOCK_SPEED Kconfig option
- https://gerrit.zephyrproject.org/r/12765 : doc: fix path reference to shell sample
- https://gerrit.zephyrproject.org/r/12771 : doc: fix reference to include file
- https://gerrit.zephyrproject.org/r/12773 : doc: fix :file: reference to include file
- https://gerrit.zephyrproject.org/r/12772 : doc: fix :file: reference to include file
- https://gerrit.zephyrproject.org/r/12774 : doc: fix :file: references in application primer
- https://gerrit.zephyrproject.org/r/12775 : doc: fix :file: reference to include file
- https://gerrit.zephyrproject.org/r/12762 : Merge net branch into master
- https://gerrit.zephyrproject.org/r/12761 : Bluetooth: test: Add "tiny" controller configuration
- https://gerrit.zephyrproject.org/r/12760 : Bluetooth: controller: Fix warning with no dup filter
- https://gerrit.zephyrproject.org/r/12758 : ztest: Give error if user has not defined CONFIG_ZTEST
- https://gerrit.zephyrproject.org/r/12662 : doc: add substitutions for special characters
- https://gerrit.zephyrproject.org/r/12747 : doc: remove reference to deleted sample code
- https://gerrit.zephyrproject.org/r/12659 : device.h: remove deprecated device sync API
- https://gerrit.zephyrproject.org/r/12660 : kernel: remove deprecated init levels
- https://gerrit.zephyrproject.org/r/12670 : doc: subsystems: bluetooth: Update controller features
- https://gerrit.zephyrproject.org/r/12624 : net: icmpv6: Print received packet type as string
- https://gerrit.zephyrproject.org/r/12740 : drivers: pinmux: stm32l4 fix
- https://gerrit.zephyrproject.org/r/12756 : net/core: Fix wrong parameter usage for check_unknown_option()


Re: (Big) problems achieving fair scheduling of a semaphore ISR producer - thread consumer case

Paul Sokolovsky
 

Hello Andy,

On Fri, 7 Apr 2017 08:29:08 -0700
Andy Ross <andrew.j.ross@...> wrote:

Paul Sokolovsky <paul.sokolovsky@...> wrote (on Thursday,
April 06, 2017 11:04PM):
My kind request though is: please don't try to shift it all on UART
and talk about the need of DTR/RTS, etc. UART is damn slow device by
the current standards, which should "just work" with dozens-of-MHz
CPUs without any flow control on hardware side.
I'm not completely sure I buy that. If your consumer thread isn't
being scheduled due to all the UART interrupts, the CPU is clearly
*not* fast enough
Thanks for the reply. The original hunch was that there was some kind
of issue with the scheduling implementation. I explained where it came
from - because other explanations, like "fast thread can't keep up with
slow ISR" or "the problem is in UART handling" seemed to be too simple
an answer and thus unrealistic to be true. It more and more looks like
I was wrong, and the issue lies on UART handling side, and is a
relatively obvious to be looked at and ignored :-/.

to handle the bytes arriving at the line rate (maybe
that's something we should fix, though -- have you looked to see where
the cycles are going?).
Speculatively, yes - they go into busy-polling implementation of UART
TX. And as mentioned in my previous email, we always spend more cycles
to send a char (because of the overheads we do besides send), than to
receive, so with busy-polling send, we'll never get a reliable behavior.

I mean... I know you don't want to hear this but the situation you
have is precisely what buffering and hardware flow control are
designed to solve. Make the buffer big enough to handle the sudden
flood, or flag your buffer-full condition to the other side with
RTC/CTS (I know this won't work on lots of console devices which don't
wire the flow control lines).
So, either everyone does wrong, or people save on wires because they
aren't needed in prevalent number of modern usecases.

Or if you can, adjust the protocol to
include a software flow control mechanism like an ACK with a max
"packet" size (not XON/XOFF though, that never works).
Right, the last one is 2nd most popular workaround nowadays - almost
all protocols are request-response, and require response much sooner
than after sending a megabyte of data, but some do send many kilobytes
nonetheless. The 1st workaround is still just handling a UART with a
fast CPU such that flow control issues aren't hit in the realistic
scenarios. "Realistic scenarios" include being able to paste a dozen of
lines in an echoing application. That works in many systems
- why don't we target Zephyr being able to do that too?


Andy

Thanks,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Re: (Big) problems achieving fair scheduling of a semaphore ISR producer - thread consumer case

Paul Sokolovsky
 

Hello Daniel,

On Fri, 7 Apr 2017 12:38:34 +0100
Daniel Thompson <daniel.thompson@...> wrote:

[]

...
Console buffer overflow - char dropped
Console buffer overflow - char dropped
...
Did you run this on carbon? I've not been able to reproduce on this
board.
Ok, now I did. With the patch above, I can't reproduce the overflow
message. But now let's try to echo the input char, and for a
difference, set CONFIG_CONSOLE_GETCHAR_BUFSIZE=64 so we didn't
suspect too short a buffer.

I still can't reproduce overflow message,
... funny you should say that.

I've been taking a quick glance at the vendor HAL here. It implements
some kind of weird private locking scheme that looks like it doesn't
play nicely with a pre-emptive RTOS (or even with interrupt handlers).
Ack, thanks, I see it.

[]

So, probably can come to a conclusion: for reliable operation, both
UART rx *and* tx should be buffered and interrupt-driven.
I don't understand how the evidence leads to this conclusion.
Well, it's reasoning from the opposite direction, let's recount:

1. As was quoted, MicroPython has multiple implementations of that
handling for multiple environments, all "just working". Output
buffering is used at all times though.

2. Pure mathematical reasoning that if a char at a given baud rate is
received each X cycles, then busy-polling to send a char will take
these X cycles. But while hardware receives a char each X cycles on its
own, before we can spend X cycles to send it, we first all also need to
spend some other cycles to handle an interrupt, extract received char,
etc. So, the ratio is never 1:1, but instead 1:1.xx, so we sustainably
will be getting late, and lose or overflow eventually.

3. Simply due to lack of better leads to a problem ("broken UART
drivers and handling" started to sound much more convincing than the
original "scheduling is broken" guess, which couldn't be proven).

Personally I'm still rather concerned that the driver may not be
robust (although, just as you blaming the scheduler, I haven't
collected much evidence to support this).
"The driver"? It's "the drivers, and for a while". If you think that
the problem is peculiar to stm32, then there was example of
arduino_101 having had a big problem, and still having some, frdm_k64f
also had (== has) similar problems, etc.

I've done a quick review of the driver and so far I haven't seen
anything that explains the character loss (although it would good to
neutralize the private locking so we can see the output from the ISR).

I'm afraid, for me, time is up thinking about this for a while.
However, if I was looking at this further, I'd consider reinstating
the old UART driver (HAL is sufficiently complexified that it becomes
hard to reason about) and see if it behaves the same way...
Well, thanks for helping the investigation, I appreciate that, as
usual! Reinstate the old driver - for one-off testing? If so, I'd find
hack-hacking the existing one to be more practical. And anything beyond
that borders on organizational and political issues. Suffice that
others provided feedback on that (p.1 at
https://youtu.be/XUJK2htXxKw?t=1885), I don't want to go there ;-).

[]

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Re: (Big) problems achieving fair scheduling of a semaphore ISR producer - thread consumer case

Andy Ross
 

Paul Sokolovsky <paul.sokolovsky@...> wrote (on Thursday, April 06, 2017 11:04PM):
My kind request though is: please don't try to shift it all on UART
and talk about the need of DTR/RTS, etc. UART is damn slow device by
the current standards, which should "just work" with dozens-of-MHz
CPUs without any flow control on hardware side.
I'm not completely sure I buy that. If your consumer thread isn't
being scheduled due to all the UART interrupts, the CPU is clearly
*not* fast enough to handle the bytes arriving at the line rate (maybe
that's something we should fix, though -- have you looked to see where
the cycles are going?).

I mean... I know you don't want to hear this but the situation you
have is precisely what buffering and hardware flow control are
designed to solve. Make the buffer big enough to handle the sudden
flood, or flag your buffer-full condition to the other side with
RTC/CTS (I know this won't work on lots of console devices which don't
wire the flow control lines). Or if you can, adjust the protocol to
include a software flow control mechanism like an ACK with a max
"packet" size (not XON/XOFF though, that never works).

Andy


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/12760 : Bluetooth: controller: Fix warning with no dup filter
- https://gerrit.zephyrproject.org/r/12756 : net/core: Fix wrong parameter usage for check_unknown_option()
- https://gerrit.zephyrproject.org/r/12761 : Bluetooth: test: Add "tiny" controller configuration
- https://gerrit.zephyrproject.org/r/12758 : ztest: Give error if user has not defined CONFIG_ZTEST
- https://gerrit.zephyrproject.org/r/12746 : samples: ipss: Add callback parameter to ipss_advertise()
- https://gerrit.zephyrproject.org/r/12745 : kernel: tickless: Rename _Swap to allow creation of macro
- https://gerrit.zephyrproject.org/r/12741 : timer: tickless: cortex_m: Add tickless kernel support
- https://gerrit.zephyrproject.org/r/12752 : build: add MSYS dependenc to Makefile
- https://gerrit.zephyrproject.org/r/12747 : doc: remove reference to deleted sample code
- https://gerrit.zephyrproject.org/r/12749 : drivers: Add Atmel SAM serial (UART) driver
- https://gerrit.zephyrproject.org/r/12751 : tests: driver: uart: fix unchecked return value
- https://gerrit.zephyrproject.org/r/12750 : drivers: Extend Atmel SAM GPIO driver
- https://gerrit.zephyrproject.org/r/12748 : drivers: Add Atmel SAM family I2C (TWIHS) driver
- https://gerrit.zephyrproject.org/r/12744 : subsys: debug: Add AddressSanitizer support

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/12627 : net: shell: Add IPv6 fragmentation info printing
- https://gerrit.zephyrproject.org/r/12623 : net: nbuf: Add function to split a data fragment
- https://gerrit.zephyrproject.org/r/12625 : net: ipv6: Add helper to get the last extension header
- https://gerrit.zephyrproject.org/r/12626 : net: ipv6: Support fragmented IPv6 packets
- https://gerrit.zephyrproject.org/r/12624 : net: icmpv6: Print received packet type as string
- https://gerrit.zephyrproject.org/r/12731 : Bluetooth: controller: Channel Selection Algorithm #2
- https://gerrit.zephyrproject.org/r/12670 : doc: subsystems: bluetooth: Update controller features
- https://gerrit.zephyrproject.org/r/12721 : boards: arm: Add support for Silabs EFM32WG-STK3800
- https://gerrit.zephyrproject.org/r/11187 : tests: kernel: add test point k_cpu_atomic_idle
- https://gerrit.zephyrproject.org/r/11216 : tests: kernel: added clock_test
- https://gerrit.zephyrproject.org/r/12727 : lldp: Add LLDP definitions
- https://gerrit.zephyrproject.org/r/11667 : samples: tickless: Enables tickless kernel option in some apps
- https://gerrit.zephyrproject.org/r/11787 : timer: tickless: hpet: Add tickless kernel support
- https://gerrit.zephyrproject.org/r/11786 : kernel: tickless: Add tickless kernel support
- https://gerrit.zephyrproject.org/r/11839 : timer: tickless: loapic: Add tickless kernel support
- https://gerrit.zephyrproject.org/r/11785 : kernel: tickless: Add function to check if list contains multiple nodes
- https://gerrit.zephyrproject.org/r/12722 : drivers: gpio_gecko: Add gpio driver for Silabs EXX32 MCUs
- https://gerrit.zephyrproject.org/r/12739 : ext: Integrate Silabs Gecko SDK into Zephyr
- https://gerrit.zephyrproject.org/r/12720 : arm: exx32: Add Silabs EFM32WG soc files
- https://gerrit.zephyrproject.org/r/12723 : drivers: serial: Add uart driver for Silabs EXX32 MCUs
- https://gerrit.zephyrproject.org/r/12693 : [RFC] sanitycheck: support testcases in yaml instead of ini
- https://gerrit.zephyrproject.org/r/12661 : kernel: expose struct k_thread implementation to applications
- https://gerrit.zephyrproject.org/r/11965 : xtensa: add shared xtensa-config recipe
- https://gerrit.zephyrproject.org/r/12740 : drivers: pinmux: stm32l4 fix

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/12757 : net/arp: Return relevant verdict if the ARP packet was consumed
- https://gerrit.zephyrproject.org/r/12759 : net: Fix default order for NET_CONTEXT_NBUF_POOL
- https://gerrit.zephyrproject.org/r/12755 : Bluetooth: hci_ecc: Fix ECDH API usage
- https://gerrit.zephyrproject.org/r/12753 : net: ip: Increase RX stack size
- https://gerrit.zephyrproject.org/r/12754 : net: Enable context buffer pool in case TCP and 6LO are enabled
- https://gerrit.zephyrproject.org/r/12743 : subsys/logging: sys_event_logger_get: Fix k_sem_take() success check.
- https://gerrit.zephyrproject.org/r/12742 : doc: kernel_event_logger: Update constant names to the current.
- https://gerrit.zephyrproject.org/r/12736 : Bluetooth: controller: Add BT 5.0 PDU structs
- https://gerrit.zephyrproject.org/r/12639 : net: Move IPv4 packet handling from net_core.c to ipv4.c
- https://gerrit.zephyrproject.org/r/12638 : net: Move IPv6 packet handling from net_core.c to ipv6.c
- https://gerrit.zephyrproject.org/r/12671 : Bluetooth: controller: Implement event masks
- https://gerrit.zephyrproject.org/r/12637 : Bluetooth: controller: Implement scan duplicate filter
- https://gerrit.zephyrproject.org/r/12678 : net: buf: Add CONFIG_NET_BUF_WARN_ALLOC_INTERVAL
- https://gerrit.zephyrproject.org/r/12645 : doc: Enhance IP stack overview documentation
- https://gerrit.zephyrproject.org/r/12633 : x86: add a more informative page fault handler
- https://gerrit.zephyrproject.org/r/12690 : arm: dts: st: Convert STM32F3 based boards to dts
- https://gerrit.zephyrproject.org/r/12692 : arm: st: dts: remove last !HAS_DTS from stm32 SoCs
- https://gerrit.zephyrproject.org/r/12691 : serial: stm32: remove bits related to !HAS_DTS
- https://gerrit.zephyrproject.org/r/12688 : arm: dts: st: Convert STM32F1 based boards to dts
- https://gerrit.zephyrproject.org/r/12668 : subsys/console: Yield on char availability.


Re: (Big) problems achieving fair scheduling of a semaphore ISR producer - thread consumer case

Daniel Thompson <daniel.thompson@...>
 

On 07/04/17 11:21, Paul Sokolovsky wrote:
--- a/samples/subsys/console/getchar/src/main.c
+++ b/samples/subsys/console/getchar/src/main.c
@@ -9,6 +9,6 @@ void main(void)
while (1) {
uint8_t c = console_getchar();

- printk("char: [0x%x] %c\n", c, c);
+// printk("char: [0x%x] %c\n", c, c);
}
}

...
Console buffer overflow - char dropped
Console buffer overflow - char dropped
...
Did you run this on carbon? I've not been able to reproduce on this
board.
Ok, now I did. With the patch above, I can't reproduce the overflow
message. But now let's try to echo the input char, and for a
difference, set CONFIG_CONSOLE_GETCHAR_BUFSIZE=64 so we didn't suspect
too short a buffer.

I still can't reproduce overflow message,
... funny you should say that.

I've been taking a quick glance at the vendor HAL here. It implements some kind of weird private locking scheme that looks like it doesn't play nicely with a pre-emptive RTOS (or even with interrupt handlers).

I think this means that when we are transmitting a character from a task it becomes unlikely that the system will emit an error message from the ISR (including the overflow message).

That doesn't mean overflow is happening. Just that the serial driver looks broken enough to make such testing unreliable.

but now we're entering land of
obvious UART problems. So, to keep 1:1 rx/tx ratio we translate
input CR using picocom:

picocom -b115200 --omap crcrlf --emap "" /dev/ttyUSB0

Now paste the whole "Ok, now I did ..." para above. The behavior: first
subchunk being pasted, the noticeable pause, then second subchunk
appears, at which point board no longer reacts to input and appears
dead.

Blame "my" code? Well, fire up the classical samples/subsys/shell, and
paste there:

Attempt 1:
shell> Ok, now I id. With
(lockup)

Attempt 2:
shell> Ok, now Idid. With atch abov, I can't eproduce te overflo
mssage.But now le's try toecho the iput char, nd for a
dference, et CONFIG_ONSOLE_GECHAR_BUFSIE=64 so wedidn't susect

Attempt 3:
Could paste whole 5 times with wildly lost chars, before the thing
finally gave up and locked up.

All that is nothing new. See e.g.
https://jira.zephyrproject.org/browse/ZEP-467 and what patch "fixed"
it. I write "fixed" because, well, hang indeed seems to be fixed on on
arduino_101 \o/, but it all still works, umm, in expected way:

shell> Now paste the whole "Ok, now I did ..." para above. The behavor: frst
sbchun bein past, th notieablepause thensecon subcunk
apears at wich pnt bord nolonge reacs to nput nd apeaToro msan

(But again, passed "UART ship it" test of being pastes into for a
minute without hangs.)

So, probably can come to a conclusion: for reliable operation, both UART
rx *and* tx should be buffered and interrupt-driven.
I don't understand how the evidence leads to this conclusion.

Personally I'm still rather concerned that the driver may not be robust (although, just as you blaming the scheduler, I haven't collected much evidence to support this).

I've done a quick review of the driver and so far I haven't seen anything that explains the character loss (although it would good to neutralize the private locking so we can see the output from the ISR).

I'm afraid, for me, time is up thinking about this for a while. However, if I was looking at this further, I'd consider reinstating the old UART driver (HAL is sufficiently complexified that it becomes hard to reason about) and see if it behaves the same way...


It *does* reproduce on qemu_cortex_m3 but the UART simulation looks a
bit dubious. I can't directly test the input but the simulated UART
is *very* obviously producing characters way faster than the normal
baud rate... it appears to simply be running as fast as it can.
So, can come to 2nd conclusion - QEMU emulation can't be trusted much.
That's the saddest part, because I was interested first and foremost
in the local QEMU test automation. I mean, the saddest part is
it's unclear what to do about it. Do you mean that you looked at the
source of the old-old QEMU version used by Zephyr SDK and so this
simplistic UART emulation?
No. I simply noticed that is created *pages* of output really quickly (<3ms).

That "old-old" part is what deterred me from
doing the same, I guess I should try QEMU 2.8 after all. But if it's
not fixed there, I'm at loss again - should I try all the gazillion
forks around, or try to fix it myself against mainline (didn't hack on
qemu for a while)?..
Fixing qemu would be awesome (you know I like to see upstream bug fixes rather than moaning). If you can reproduce in mainline I'd start there and then request a backport...


Daniel.


Re: (Big) problems achieving fair scheduling of a semaphore ISR producer - thread consumer case

Paul Sokolovsky
 

On Fri, 7 Apr 2017 09:56:30 +0100
Daniel Thompson <daniel.thompson@...> wrote:

[]

I remember yesterday you said you had disabled all the local
echos... did you reach a point where the TX/RX ratio was less than
1:1?
Ok, master, following patch:
;-)

I've been very careful not to say you're wrong. I *only* said the
example you brought up was not a reproduction of an incorrect thread
schedule.
Well, I'd love to be pointed where I'm wrong and be shown how to do it
right. For the background, receiving a char in an interrupt or from a
callback, storing it in a buffer and then letting main application pull
chars from buffer (or block on it) is a very mundane task, with many
systems working like that. In MicroPython, we have that implemented in
bare metal (well, via STM32Cube/CC3200 HAL libs), in
Xtensa proprietary cooperative multitasking RTOS (well, backed by
bare-metal handling too), in STM32 USB-CDC, and all that "just works".
Zephyr so far the only one (of the tried) which has problems.

As UART is a pretty simple device and you can do only so much about
handling it, and I assume everything of that was already done in
Zephyr, I blame threading/sync primitives, as much more differentiating
matter. I may be very wrong (and ready to "eat my hat").



--- a/samples/subsys/console/getchar/src/main.c
+++ b/samples/subsys/console/getchar/src/main.c
@@ -9,6 +9,6 @@ void main(void)
while (1) {
uint8_t c = console_getchar();

- printk("char: [0x%x] %c\n", c, c);
+// printk("char: [0x%x] %c\n", c, c);
}
}

...
Console buffer overflow - char dropped
Console buffer overflow - char dropped
...
Did you run this on carbon? I've not been able to reproduce on this
board.
Ok, now I did. With the patch above, I can't reproduce the overflow
message. But now let's try to echo the input char, and for a
difference, set CONFIG_CONSOLE_GETCHAR_BUFSIZE=64 so we didn't suspect
too short a buffer.

I still can't reproduce overflow message, but now we're entering land of
obvious UART problems. So, to keep 1:1 rx/tx ratio we translate
input CR using picocom:

picocom -b115200 --omap crcrlf --emap "" /dev/ttyUSB0

Now paste the whole "Ok, now I did ..." para above. The behavior: first
subchunk being pasted, the noticeable pause, then second subchunk
appears, at which point board no longer reacts to input and appears
dead.

Blame "my" code? Well, fire up the classical samples/subsys/shell, and
paste there:

Attempt 1:
shell> Ok, now I id. With
(lockup)

Attempt 2:
shell> Ok, now Idid. With atch abov, I can't eproduce te overflo
mssage.But now le's try toecho the iput char, nd for a
dference, et CONFIG_ONSOLE_GECHAR_BUFSIE=64 so wedidn't susect

Attempt 3:
Could paste whole 5 times with wildly lost chars, before the thing
finally gave up and locked up.

All that is nothing new. See e.g.
https://jira.zephyrproject.org/browse/ZEP-467 and what patch "fixed"
it. I write "fixed" because, well, hang indeed seems to be fixed on on
arduino_101 \o/, but it all still works, umm, in expected way:

shell> Now paste the whole "Ok, now I did ..." para above. The behavor: frst
sbchun bein past, th notieablepause thensecon subcunk
apears at wich pnt bord nolonge reacs to nput nd apeaToro msan

(But again, passed "UART ship it" test of being pastes into for a
minute without hangs.)

So, probably can come to a conclusion: for reliable operation, both UART
rx *and* tx should be buffered and interrupt-driven.

It *does* reproduce on qemu_cortex_m3 but the UART simulation looks a
bit dubious. I can't directly test the input but the simulated UART
is *very* obviously producing characters way faster than the normal
baud rate... it appears to simply be running as fast as it can.
So, can come to 2nd conclusion - QEMU emulation can't be trusted much.
That's the saddest part, because I was interested first and foremost
in the local QEMU test automation. I mean, the saddest part is
it's unclear what to do about it. Do you mean that you looked at the
source of the old-old QEMU version used by Zephyr SDK and so this
simplistic UART emulation? That "old-old" part is what deterred me from
doing the same, I guess I should try QEMU 2.8 after all. But if it's
not fixed there, I'm at loss again - should I try all the gazillion
forks around, or try to fix it myself against mainline (didn't hack on
qemu for a while)?..



Daniel.


--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Re: (Big) problems achieving fair scheduling of a semaphore ISR producer - thread consumer case

Daniel Thompson <daniel.thompson@...>
 

On 07/04/17 09:31, Paul Sokolovsky wrote:
On Fri, 7 Apr 2017 09:06:14 +0100
Daniel Thompson <daniel.thompson@...> wrote:

[]

So, it's a typical "nothing works" type of bug each of us faced and
enjoyed. I really need 2nd (3rd, 4th) opinion on this. My kind
request though is: please don't try to shift it all on UART and
talk about the need of DTR/RTS, etc. UART is damn slow device by
the current standards, which should "just work" with dozens-of-MHz
CPUs without any flow control on hardware side.
If the UART TX side produces more characters than it receives in
input then flow control (or very large buffers) are the *only* way to
avoid losing characters when the input is running at maximum speed.

Anything with a character echo and a longer message on each '\n' will
eventually overflow unless we use flow control (or bound the input).

One possible mitigation would be to provide with an API to determin
if the pull-console is backlogging. If that happens than an
application might choose to disable its character echo to help it
catch up.

I remember yesterday you said you had disabled all the local echos...
did you reach a point where the TX/RX ratio was less than 1:1?
Ok, master, following patch:
;-)

I've been very careful not to say you're wrong. I *only* said the example you brought up was not a reproduction of an incorrect thread schedule.


--- a/samples/subsys/console/getchar/src/main.c
+++ b/samples/subsys/console/getchar/src/main.c
@@ -9,6 +9,6 @@ void main(void)
while (1) {
uint8_t c = console_getchar();

- printk("char: [0x%x] %c\n", c, c);
+// printk("char: [0x%x] %c\n", c, c);
}
}

...
Console buffer overflow - char dropped
Console buffer overflow - char dropped
...
Did you run this on carbon? I've not been able to reproduce on this board.

It *does* reproduce on qemu_cortex_m3 but the UART simulation looks a bit dubious. I can't directly test the input but the simulated UART is *very* obviously producing characters way faster than the normal baud rate... it appears to simply be running as fast as it can.


Daniel.


Re: (Big) problems achieving fair scheduling of a semaphore ISR producer - thread consumer case

Daniel Thompson <daniel.thompson@...>
 

On 07/04/17 09:21, Paul Sokolovsky wrote:
On Fri, 7 Apr 2017 09:06:14 +0100
Daniel Thompson <daniel.thompson@...> wrote:

[]

So, it's a typical "nothing works" type of bug each of us faced and
enjoyed. I really need 2nd (3rd, 4th) opinion on this. My kind
request though is: please don't try to shift it all on UART and
talk about the need of DTR/RTS, etc. UART is damn slow device by
the current standards, which should "just work" with dozens-of-MHz
CPUs without any flow control on hardware side.
If the UART TX side produces more characters than it receives in
input then flow control (or very large buffers) are the *only* way to
avoid losing characters when the input is running at maximum speed.
OMG, so do you want to say that the problem is that we use busy-polling
for UART TX??
Yes, printk() eventually boils down to uart_poll_out() and will spin the thread that calls it until the message is sent to the UART. printk() is arguably also *correct*: if you buffer printk() messages you have problems getting reliable output from interrupt handlers.

In any case, adding a push support to the console might improve the power/performance of console applications (which would spend less time spinning) but it cannot solve the console overflow problem. When the TX/RX ration is >1 since you would also exhaust the output buffer too.


Daniel.


Re: (Big) problems achieving fair scheduling of a semaphore ISR producer - thread consumer case

Paul Sokolovsky
 

On Fri, 7 Apr 2017 09:06:14 +0100
Daniel Thompson <daniel.thompson@...> wrote:

[]

So, it's a typical "nothing works" type of bug each of us faced and
enjoyed. I really need 2nd (3rd, 4th) opinion on this. My kind
request though is: please don't try to shift it all on UART and
talk about the need of DTR/RTS, etc. UART is damn slow device by
the current standards, which should "just work" with dozens-of-MHz
CPUs without any flow control on hardware side.
If the UART TX side produces more characters than it receives in
input then flow control (or very large buffers) are the *only* way to
avoid losing characters when the input is running at maximum speed.

Anything with a character echo and a longer message on each '\n' will
eventually overflow unless we use flow control (or bound the input).

One possible mitigation would be to provide with an API to determin
if the pull-console is backlogging. If that happens than an
application might choose to disable its character echo to help it
catch up.

I remember yesterday you said you had disabled all the local echos...
did you reach a point where the TX/RX ratio was less than 1:1?
Ok, master, following patch:

--- a/samples/subsys/console/getchar/src/main.c
+++ b/samples/subsys/console/getchar/src/main.c
@@ -9,6 +9,6 @@ void main(void)
while (1) {
uint8_t c = console_getchar();

- printk("char: [0x%x] %c\n", c, c);
+// printk("char: [0x%x] %c\n", c, c);
}
}

...
Console buffer overflow - char dropped
Console buffer overflow - char dropped
...

So, kindly let me keep repeating it again - the problem is not with
UART, the problem is with scheduling a thread which is woken up on a
sema signaled in ISR. (Yes, it would be nice to reproduce that with
another IRQ but UART).

The only way I was able to achieve 1:1 ration is by applying incorrect
k_yield patch to qemu_x86 build - that works flawless and perfectly
(printing "+" on k_sem_give, "-" on k_sem_take produces the expected
pattern of "+-+-+-+-+-" whereas in other cases the pattern is like
"+++++++++++++++++++++++++++++++++++-+++++++++++-++++++++++++++-").



Daniel.


--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Re: Catching on device tree development

Geoffrey LE GOURRIEREC <geoffrey.legourrierec@...>
 

Hi Kumar,

On Apr 6, 2017, at 3:39 PM, Kumar Gala <kumar.gala@...> wrote:
If this is an ARM based SoC board, than yes. New boards require DT
support as we work to convert the existing ones over. However, it can
be a pretty minimal DT at this point (flash, sram, uarts)
[...]
Maybe best to do an RFC patch on Gerrit to share what you have.
I see, then I'll stick with a basic DT patch. I did not try to write anything
really new, just wanted to check on the state of development for Device Tree
as of now.

Correct, the idea is the keep Zephyr small and thus generate code we
need. It’s probably that we need more code generation for pinmux to
be useful at this point in time.
OK, no surprise then; minimizing footprint is an essential goal after all.

Its a work in progress, but the idea is to reduce a lot of the
KConfig bits we have and make board ports simpler. However, we are
just starting off with it.
I’m not exactly sure how much pinmux has been looked at, Andy Gross
is the best person to answer that.
- k
Thanks for all the info. I'll follow Device Tree development and keep up
to pace. Right now, I decided to remove pinmux info from my .dts file and leave
the current init() code unchanged, so as to avoid duplication.

Regards,

--
Geoffrey


Re: (Big) problems achieving fair scheduling of a semaphore ISR producer - thread consumer case

Paul Sokolovsky
 

On Fri, 7 Apr 2017 09:06:14 +0100
Daniel Thompson <daniel.thompson@...> wrote:

[]

So, it's a typical "nothing works" type of bug each of us faced and
enjoyed. I really need 2nd (3rd, 4th) opinion on this. My kind
request though is: please don't try to shift it all on UART and
talk about the need of DTR/RTS, etc. UART is damn slow device by
the current standards, which should "just work" with dozens-of-MHz
CPUs without any flow control on hardware side.
If the UART TX side produces more characters than it receives in
input then flow control (or very large buffers) are the *only* way to
avoid losing characters when the input is running at maximum speed.
OMG, so do you want to say that the problem is that we use busy-polling
for UART TX??


--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Re: (Big) problems achieving fair scheduling of a semaphore ISR producer - thread consumer case

Daniel Thompson <daniel.thompson@...>
 

On 07/04/17 07:04, Paul Sokolovsky wrote:
Way to reproduce:
Go to samples/subsys/console/getchar. Build the example, deploy, run.
Can be tested with QEMU too. When started, select this paragraph from
the email (starting with "Go to ..."), copy to clipboard, paste. Behold
a big number of "Console buffer overflow - char dropped" messages
appear, all characters haven't been pasted.
I did a quick test on a carbon and I can't reproduce with the getchar example.

I *am* seeing overflows but the overflows I observe are what would be expected based on the quantity of input buffering (16) and the depth of output buffering (1).

The getchar output emits ~16 characters for each one received so we expect the overflow to occur in the second line of output (which it does). Increasing the input buffer to 32 results in the overflow occurring in the third line of output.


So, it's a typical "nothing works" type of bug each of us faced and
enjoyed. I really need 2nd (3rd, 4th) opinion on this. My kind request
though is: please don't try to shift it all on UART and talk about the
need of DTR/RTS, etc. UART is damn slow device by the current
standards, which should "just work" with dozens-of-MHz CPUs without
any flow control on hardware side.
If the UART TX side produces more characters than it receives in input then flow control (or very large buffers) are the *only* way to avoid losing characters when the input is running at maximum speed.

Anything with a character echo and a longer message on each '\n' will eventually overflow unless we use flow control (or bound the input).

One possible mitigation would be to provide with an API to determin if the pull-console is backlogging. If that happens than an application might choose to disable its character echo to help it catch up.

I remember yesterday you said you had disabled all the local echos... did you reach a point where the TX/RX ratio was less than 1:1?


Daniel.


Re: BSD Sockets like API: prototyping report #2

Paul Sokolovsky
 

On Mon, 3 Apr 2017 18:55:36 +0300
Paul Sokolovsky <Paul.Sokolovsky@...> wrote:

[]

2. send() was easy, but only superficially. At BUD17 min-summit,
Tomasz told few times that current issue of Zephyr buffer management
is that it mixes low-level data chunking (into net_buf's) with
network-level chunking of user data into MTU units. I wasn't sure I
understand that, but now I see the issue very well. Actually, I don't
see where MTU chunking happens at all. As far as I can see,
net_nbuf_append(), passed 10K of data, will happily create a network
packet with so many fragments (as long as it'll get that many
fragments), but what force will send out such a monster?
Confirmed to be a known issue, as there was no dedicated ticket, I
created https://jira.zephyrproject.org/browse/ZEP-1998


[]

4. Back to recv(), not everything is happy either. I don't see how my
socket implementation could affect TCP flow control, and that needs to
be done by sockets (and not existing push-style IP stack) to avoid
being DoSed with too much packets. I'd take lwIP's solution of
letting the application to advance TCP receive window as a proven
one, and on which MicroPython's lwIP socket module is based.
Confirmed, ticketed as https://jira.zephyrproject.org/browse/ZEP-1999.
Neither there's a send window handling, ticketed as
https://jira.zephyrproject.org/browse/ZEP-2000.

[]

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


(Big) problems achieving fair scheduling of a semaphore ISR producer - thread consumer case

Paul Sokolovsky
 

Hello,

This a continuation of a discussion started in
https://gerrit.zephyrproject.org/r/12668 and on IRC yesterday.

The problem:
Recently contributed console_getchar()'s internal buffer
easily overflows when large enough chunk of data is received via UART,
which happens e.g.: a) when sending console input programmatically
from host; b) clipboard is pasted into a terminal app from host.

Expected behavior:
A simple producer - consumer circular buffer synchronized using
semaphore is used, UART is slow (KHz), consumer thread is fast (MHz),
hence no circular buffer is expected.

Way to reproduce:
Go to samples/subsys/console/getchar. Build the example, deploy, run.
Can be tested with QEMU too. When started, select this paragraph from
the email (starting with "Go to ..."), copy to clipboard, paste. Behold
a big number of "Console buffer overflow - char dropped" messages
appear, all characters haven't been pasted.

Discussion:
Even from the reproduction steps above, if you look at what *have* been
pasted, you'll that's initial chars of content, so it looks (and later
confirmed) following happens: instead of producer and consumer working
in tandem, initially mostly producer gets run in loop, overflowing
buffer, and only then consumer kicks in. The producer is a function run
from an ISR:
https://gerrit.zephyrproject.org/r/gitweb?p=zephyr.git;a=blob;f=subsys/console/getchar.c;hb=refs/heads/master#l21 ,
consumer is a function run in the Zephyr main thread below it.

Let's do the math: UART speed is 115200 baud / (1 + 8 + 1 bits) = 11520
bytes/s, ISR runs with an average frequency 11.5 KHz. My test hardware
is e.g. BOARD=96b_carbon, running at 84MHz. For each ISR call, there're
7304 instructions of scheduler and main thread to run on average.
Should be plenty to run the simple consumer above.

We note effects of the possible UART hardware buffer. The sample above
uses rather small circular buffer, but in a real app, it's 256 bytes.
Growing it further doesn't help. Even with HW buffer, sustained char
production rate is still 11.5 KHz, and the SW buffer can't keep up with
that due to strong bias on production, with heavily throttled
consumption.

History of investigation:
1. I initially thought that maybe need to prod Zephyr to do thread
rescheduling explicitly, looked for yield, dropped it, and rejoiced by
seeing the issue to be fixed by BOARD=qemu_x86 ! Later I noticed it
still doesn't fix it for BOARD=qemu_cortex_m3. To start a discussion, I
submitted a patch as is, even though k_yield is documenting as working
on threads (not ISRs). Patch was merged, later reverted, the discussion
started hopefully either way ;-).

2. One of the initial ideas was that maybe buffer DoSing was an
artifact of QEMU. The behavior is confirmed for 96b_carbon.

3. One of the early suggestion I got on IRC was to do flow control with
disabling/enabling UART IRQs. I wasn't happy about such suggestion, as
the code above is generic console buffering, and with several thousands
of cycles to process each char, everything should "just work".

4. I did a lot of investigation yesterday (with ARM, as that's hard
case, which isn't "fixed" with the incorrect fix). There was a
suspicion that context switching, implemented with PendSV interrupt
doesn't always kick in. In the end, I had to discard my results, as I
used printk output for diagnosing it, which is slow, and makes it
normal a case that if I report recv char with printk, then afterwards
there's another char in buf, causing ISR to run immediately again, so
PendSV handler can't run. (To elaborate, behavior in the absence of
printk still resembles of PendSV not running often enough, it just
can't proven in the presence of printk's).

5. I briefly tried "kernel event logger" facility. Well, "briefly"
doesn't say it right, I spent couple of hours trying to make it useful
for my case, and hunt down issues (patches submitted and merged), so at
one point I decided to not look for more bugs and switched back to
printk. Perhaps following this path further makes sense though to
disambiguate issues in p.4.

6. In the end I tried suggestion with UART IRQ disabling. If you read
this far, you won't be surprised that it didn't work. Even after I
disable IRQ, my ISR routine still gets called one more time. This
leaves production vs consumption rate at 2:1, still leading to buffer
overflow, and it elaborates my concern with adding such code to console
routine: it leaves it at mercy of a particular hardware implementation
(IRQ disabling/enabling might be not implemented for example).

7. With some creativity, I was able to find a USB-UART adapter to try
the sample on arduino_101. So, while incorrect fix fixes the issue
completely for qemu_x86, on the real hardware, it doesn't - while
there're no buffer overflow messages, majority of chars are dropped.




So, it's a typical "nothing works" type of bug each of us faced and
enjoyed. I really need 2nd (3rd, 4th) opinion on this. My kind request
though is: please don't try to shift it all on UART and talk about the
need of DTR/RTS, etc. UART is damn slow device by the current
standards, which should "just work" with dozens-of-MHz CPUs without
any flow control on hardware side.

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/12740 : drivers: pinmux: stm32l4 fix
- https://gerrit.zephyrproject.org/r/12723 : drivers: serial: Add uart driver for Silabs EXX32 MCUs
- https://gerrit.zephyrproject.org/r/12722 : drivers: gpio_gecko: Add gpio driver for Silabs EXX32 MCUs
- https://gerrit.zephyrproject.org/r/12739 : ext: Integrate Silabs Gecko SDK into Zephyr
- https://gerrit.zephyrproject.org/r/12692 : arm: st: dts: remove last !HAS_DTS from stm32 SoCs
- https://gerrit.zephyrproject.org/r/12721 : boards: arm: Add support for Silabs EFM32WG-STK3800
- https://gerrit.zephyrproject.org/r/12720 : arm: exx32: Add Silabs EFM32WG soc files
- https://gerrit.zephyrproject.org/r/12719 : ext: gecko: Add Silabs Gecko SDK for EXX32 SoCs
- https://gerrit.zephyrproject.org/r/12691 : serial: stm32: remove bits related to !HAS_DTS
- https://gerrit.zephyrproject.org/r/12690 : arm: dts: st: Convert STM32F3 based boards to dts
- https://gerrit.zephyrproject.org/r/12688 : arm: dts: st: Convert STM32F1 based boards to dts
- https://gerrit.zephyrproject.org/r/12730 : slip: Add LLDP support
- https://gerrit.zephyrproject.org/r/12729 : lldp: Add LLDP implementation
- https://gerrit.zephyrproject.org/r/12728 : ethernet: Add net_eth_context
- https://gerrit.zephyrproject.org/r/12727 : lldp: Add LLDP definitions
- https://gerrit.zephyrproject.org/r/12736 : Bluetooth: controller: Add BT 5.0 PDU structs
- https://gerrit.zephyrproject.org/r/12726 : ethernet: Add LLDP ether type
- https://gerrit.zephyrproject.org/r/12693 : [RFC] sanitycheck: support testcases in yaml instead of ini

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/12587 : unit: Create ztest unit test for CRC16 functionality
- https://gerrit.zephyrproject.org/r/12586 : crc16: Create function for computing CRC 16
- https://gerrit.zephyrproject.org/r/12645 : doc: Enhance IP stack overview documentation
- https://gerrit.zephyrproject.org/r/12626 : net: ipv6: Support fragmented IPv6 packets
- https://gerrit.zephyrproject.org/r/12666 : Bluetooth: AVCTP: Connect and Disconnect API
- https://gerrit.zephyrproject.org/r/12678 : net: buf: Add NET_BUF_WARN_ALLOC_INTERVAL
- https://gerrit.zephyrproject.org/r/12667 : tests: net: Add mqtt testcases
- https://gerrit.zephyrproject.org/r/12495 : [RFC] arm: core: mpu: Add core support to ARM MPU
- https://gerrit.zephyrproject.org/r/12624 : net: icmpv6: Print received packet type as string
- https://gerrit.zephyrproject.org/r/12554 : Bluetooth: ATT: Start response timer only after actual transmission
- https://gerrit.zephyrproject.org/r/12546 : Bluetooth: Add support for tracking transmitted packets
- https://gerrit.zephyrproject.org/r/12553 : Bluetooth: Introduce flow control for outgoing ATT packets
- https://gerrit.zephyrproject.org/r/12547 : Bluetooth: ATT: Enforce flow for incoming requests & indications
- https://gerrit.zephyrproject.org/r/12548 : Bluetooth: SMP: Track when last key distribution PDU has been sent
- https://gerrit.zephyrproject.org/r/12549 : Bluetooth: Introduce a timeout for synchronous HCI command sending
- https://gerrit.zephyrproject.org/r/11965 : xtensa: add shared xtensa-config recipe
- https://gerrit.zephyrproject.org/r/12637 : Bluetooth: controller: Implement scan duplicate filter
- https://gerrit.zephyrproject.org/r/12622 : arm: Support for new ARM board FRDM-KL25Z
- https://gerrit.zephyrproject.org/r/12597 : arm: Support for SPI driver in NXP devices
- https://gerrit.zephyrproject.org/r/12596 : arm: GPIO driver modifications for MKL25Z soc support
- https://gerrit.zephyrproject.org/r/11956 : [RFC] boards: add board meta-data
- https://gerrit.zephyrproject.org/r/11954 : [RFC] tests: samples: convert testcase files to yaml
- https://gerrit.zephyrproject.org/r/11967 : xtensa: switch toolchain to shared overlay
- https://gerrit.zephyrproject.org/r/11831 : dts: kinetis: bluetooth: Add overlay for BT
- https://gerrit.zephyrproject.org/r/12670 : doc: subsystems: bluetooth: Update controller features
- https://gerrit.zephyrproject.org/r/12671 : Bluetooth: controller: Implement event masks

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/12738 : hexiwear_k64: Update doc with new sensors and pinmuxing
- https://gerrit.zephyrproject.org/r/12687 : arm: dts: st: Convert STM32F4 based boards to dts
- https://gerrit.zephyrproject.org/r/12686 : dts: arm: ST: Cleanup DTS bits on STM32L4 SoCs
- https://gerrit.zephyrproject.org/r/12685 : dts: arm: st: Add additional SoCs into mem.h
- https://gerrit.zephyrproject.org/r/12737 : Revert "subsys/console: Yield on char availability."
- https://gerrit.zephyrproject.org/r/12733 : net: rpl: Return valid verdict
- https://gerrit.zephyrproject.org/r/12734 : net: shell: Fix crash when retrieving remaining reachable time
- https://gerrit.zephyrproject.org/r/12732 : net: rpl: Refactor few rpl functions
- https://gerrit.zephyrproject.org/r/12684 : dts: arm: st: Make flash/sram sizes human readable
- https://gerrit.zephyrproject.org/r/12682 : drivers: display: mb_display: Make display context more compact
- https://gerrit.zephyrproject.org/r/12683 : drivers: display: mb_display: Unify image and string APIs
- https://gerrit.zephyrproject.org/r/12725 : doc: fix headings in release notes
- https://gerrit.zephyrproject.org/r/12724 : ext qmsi: Update QMSI version on README
- https://gerrit.zephyrproject.org/r/12694 : serial: mcux: remove bits related to !HAS_DTS
- https://gerrit.zephyrproject.org/r/12689 : sanitcheck: add nrf52_blenano2
- https://gerrit.zephyrproject.org/r/12668 : subsys/console: Yield on char availability.
- https://gerrit.zephyrproject.org/r/12631 : samples: Add max30101 sample application
- https://gerrit.zephyrproject.org/r/12630 : hexiwear_k64: Add support for max30101 heart rate sensor
- https://gerrit.zephyrproject.org/r/12629 : sensor: max30101: Add heart rate sensor driver
- https://gerrit.zephyrproject.org/r/12628 : sensor: Introduce red and green light sensor channels
- https://gerrit.zephyrproject.org/r/11830 : dts: Add application overlay support.
- https://gerrit.zephyrproject.org/r/12674 : drivers: display: mb_display: Add empty column to scrolling text
- https://gerrit.zephyrproject.org/r/12675 : drivers: display: mb_display: Add internal reset helper
- https://gerrit.zephyrproject.org/r/12676 : drivers: display: mb_display: Get rid of unnecessary image tracking
- https://gerrit.zephyrproject.org/r/12679 : samples: net/nats: Fix parsing of MSG messages
- https://gerrit.zephyrproject.org/r/12677 : drivers: i2c: stm32: fix i2c_2 instance config
- https://gerrit.zephyrproject.org/r/12594 : arm: Support for MKL25Z soc
- https://gerrit.zephyrproject.org/r/12680 : tests: dma: Initialise callback enable flags
- https://gerrit.zephyrproject.org/r/12681 : api: dma: Fix comments for struct dma_config
- https://gerrit.zephyrproject.org/r/11196 : arch: Atmel SAM E70: remove now redundant IRQ id defines
- https://gerrit.zephyrproject.org/r/12664 : Merge arm branch into master


Re: Catching on device tree development

Kumar Gala
 

On Apr 5, 2017, at 11:05 AM, Geoffrey LE GOURRIEREC <geoffrey.legourrierec@...> wrote:

Hi all,

I'm close to producing a basic port for TI SensorTag board, and I saw
device trees coming to Zephyr recently. I'd like to add support for it
while I'm at it, but I'm quite confused regarding how to do it.

First, is device tree support mandatory for a patch providing support
for a new board? If not, I could send the patch sooner.
If this is an ARM based SoC board, than yes. New boards require DT support as we work to convert the existing ones over. However, it can be a pretty minimal DT at this point (flash, sram, uarts)

Second, how to make use of the Device Tree regarding the pinmux?
I wrote a .dtsi file for the new SOC, a .dts for the new board,
and several YAML files, after looking at basic Device Tree support.
I took the NXP FRDM K64F files as examples, because as of now they seem to
be the most complete.

However, I'm having trouble understanding how I should use generated #defines
with the pinmux driver. As of now, for all boards, either :
* pinmux.c provides an init() function in boards/
* the pinmux driver does roughly the same job in its init() file

In both case, board information is pretty much hard-coded (or taken from
a third-party library).
Maybe best to do an RFC patch on Gerrit to share what you have.

Unlike in Linux, no specific API allows to write "generic" drivers that fetch
required information from the DT. I'd like to at least be able to write a
generic pinmux init() function for the SOC, that sets required functions on
given pins, and get rid of pinmux.c in boards/, but implementation feels
cumbersome. I'm trying to do something like:
Correct, the idea is the keep Zephyr small and thus generate code we need. It’s probably that we need more code generation for pinmux to be useful at this point in time.


#ifdef CONFIG_PIN_3_FUNCTION
pinmux_set(dev, 3, CONFIG_PIN_FUNCTION);
#endif

...but generated #defines don't suffice and I have to tweak using
the .fixup file. Is this supposed to be the way of doing things?
The .fixup file is need to map the generated code to zephyr kconfig bits.

I may lack hindsight on this, so if someone could point me to any rationale
for using Device Trees in Zephyr (and what it should be in the future),
that'd be most welcome. Thanks in advance,
Its a work in progress, but the idea is to reduce a lot of the KConfig bits we have and make board ports simpler. However, we are just starting off with it.

I’m not exactly sure how much pinmux has been looked at, Andy Gross is the best person to answer that.

- k

6001 - 6020 of 8779