add Readme #1
Closed
add Readme #1
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Anas Nashif <[email protected]>
Signed-off-by: Anas Nashif <[email protected]>
Signed-off-by: Anas Nashif <[email protected]>
Signed-off-by: Anas Nashif <[email protected]>
Signed-off-by: Anas Nashif <[email protected]>
Signed-off-by: Anas Nashif <[email protected]>
Signed-off-by: Anas Nashif <[email protected]>
Signed-off-by: Anas Nashif <[email protected]>
Signed-off-by: Anas Nashif <[email protected]>
Signed-off-by: Anas Nashif <[email protected]>
nashif
force-pushed
the
master
branch
2 times, most recently
from
df894ad to
f65c06e
Compare
galak
pushed a commit
that referenced
this pull request
Jun 22, 2020
This makes the gatt metrics also available for gatt write-without-rsp-cb so it now prints the rate of each write: uart:~$ gatt write-without-response-cb 1e ff 10 10 Write #1: 16 bytes (0 bps) Write #2: 32 bytes (3445948416 bps) Write #3: 48 bytes (2596929536 bps) Write #4: 64 bytes (6400 bps) Write #5: 80 bytes (8533 bps) Write #6: 96 bytes (10666 bps) Write #7: 112 bytes (8533 bps) Write #8: 128 bytes (9955 bps) Write #9: 144 bytes (11377 bps) Write #10: 160 bytes (7680 bps) Write #11: 176 bytes (8533 bps) Write #12: 192 bytes (9386 bps) Write Complete (err 0) Write #13: 208 bytes (8533 bps) Write #14: 224 bytes (9244 bps) Write #15: 240 bytes (9955 bps) Write #16: 256 bytes (8000 bps) Signed-off-by: Luiz Augusto von Dentz <[email protected]>
nashif
pushed a commit
that referenced
this pull request
Apr 21, 2021
The fatal log now contains - Trap type in human readable representation - Integer registers visible to the program when trap was taken - Special register values such as PC and PSR - Backtrace with PC and SP If CONFIG_EXTRA_EXCEPTION_INFO is enabled, then all the above is logged. If not, only the special registers are logged. The format is inspired by the GRMON debug monitor and TSIM simulator. A quick guide on how to use the values is in fatal.c. It now looks like this: E: tt = 0x02, illegal_instruction E: E: INS LOCALS OUTS GLOBALS E: 0: 00000000 f3900fc0 40007c50 00000000 E: 1: 00000000 40004bf0 40008d30 40008c00 E: 2: 00000000 40004bf4 40008000 00000003 E: 3: 40009158 00000000 40009000 00000002 E: 4: 40008fa8 40003c00 40008fa8 00000008 E: 5: 40009000 f3400fc0 00000000 00000080 E: 6: 4000a1f8 40000050 4000a190 00000000 E: 7: 40002308 00000000 40001fb8 000000c1 E: E: psr: f30000c7 wim: 00000008 tbr: 40000020 y: 00000000 E: pc: 4000a1f4 npc: 4000a1f8 E: E: pc sp E: #0 4000a1f4 4000a190 E: #1 40002308 4000a1f8 E: #2 40003b24 4000a258 Signed-off-by: Martin Åberg <[email protected]>
nashif
pushed a commit
that referenced
this pull request
Jan 5, 2023
This patch reworks how fragments are handled in the net_buf infrastructure. In particular, it removes the union around the node and frags members in the main net_buf structure. This is done so that both can be used at the same time, at a cost of 4 bytes per net_buf instance. This implies that the layout of net_buf instances changes whenever being inserted into a queue (fifo or lifo) or a linked list (slist). Until now, this is what happened when enqueueing a net_buf with frags in a queue or linked list: 1.1 Before enqueueing: +--------+ +--------+ +--------+ |#1 node|\ |#2 node|\ |#3 node|\ | | \ | | \ | | \ | frags |------| frags |------| frags |------NULL +--------+ +--------+ +--------+ net_buf #1 has 2 fragments, net_bufs #2 and #3. Both the node and frags pointers (they are the same, since they are unioned) point to the next fragment. 1.2 After enqueueing: +--------+ +--------+ +--------+ +--------+ +--------+ |q/slist |------|#1 node|------|#2 node|------|#3 node|------|q/slist | |node | | *flag | / | *flag | / | | / |node | | | | frags |/ | frags |/ | frags |/ | | +--------+ +--------+ +--------+ +--------+ +--------+ When enqueing a net_buf (in this case #1) that contains fragments, the current net_buf implementation actually enqueues all the fragments (in this case #2 and #3) as actual queue/slist items, since node and frags are one and the same in memory. This makes the enqueuing operation expensive and it makes it impossible to atomically dequeue. The `*flag` notation here means that the `flags` member has been set to `NET_BUF_FRAGS` in order to be able to reconstruct the frags pointers when dequeuing. After this patch, the layout changes considerably: 2.1 Before enqueueing: +--------+ +--------+ +--------+ |#1 node|--NULL |#2 node|--NULL |#3 node|--NULL | | | | | | | frags |-------| frags |-------| frags |------NULL +--------+ +--------+ +--------+ This is very similar to 1.1, except that now node and frags are different pointers, so node is just set to NULL. 2.2 After enqueueing: +--------+ +--------+ +--------+ |q/slist |-------|#1 node|-------|q/slist | |node | | | |node | | | | frags | | | +--------+ +--------+ +--------+ | +--------+ +--------+ | |#2 node|--NULL |#3 node|--NULL | | | | | +------------| frags |-------| frags |------NULL +--------+ +--------+ When enqueuing net_buf #1, now we only enqueue that very item, instead of enqueing the frags as well, since now node and frags are separate pointers. This simplifies the operation and makes it atomic. Resolves #52718. Signed-off-by: Carles Cufi <[email protected]>
fabiobaltieri
added a commit
that referenced
this pull request
Oct 25, 2023
Add a step to the #1 twister shard to upload the list of Python packages used with the build. Signed-off-by: Fabio Baltieri <[email protected]>
fabiobaltieri
added a commit
that referenced
this pull request
Oct 25, 2023
Add a step to the #1 twister shard to upload the list of Python packages used with the build. Signed-off-by: Fabio Baltieri <[email protected]>
fabiobaltieri
pushed a commit
that referenced
this pull request
Oct 25, 2023
This patch reworks how fragments are handled in the net_buf infrastructure. In particular, it removes the union around the node and frags members in the main net_buf structure. This is done so that both can be used at the same time, at a cost of 4 bytes per net_buf instance. This implies that the layout of net_buf instances changes whenever being inserted into a queue (fifo or lifo) or a linked list (slist). Until now, this is what happened when enqueueing a net_buf with frags in a queue or linked list: 1.1 Before enqueueing: +--------+ +--------+ +--------+ |#1 node|\ |#2 node|\ |#3 node|\ | | \ | | \ | | \ | frags |------| frags |------| frags |------NULL +--------+ +--------+ +--------+ net_buf #1 has 2 fragments, net_bufs #2 and #3. Both the node and frags pointers (they are the same, since they are unioned) point to the next fragment. 1.2 After enqueueing: +--------+ +--------+ +--------+ +--------+ +--------+ |q/slist |-----|#1 node|-----|#2 node|-----|#3 node|-----|q/slist | |node | | *flag | / | *flag | / | | / |node | | | | frags |/ | frags |/ | frags |/ | | +--------+ +--------+ +--------+ +--------+ +--------+ When enqueing a net_buf (in this case #1) that contains fragments, the current net_buf implementation actually enqueues all the fragments (in this case #2 and #3) as actual queue/slist items, since node and frags are one and the same in memory. This makes the enqueuing operation expensive and it makes it impossible to atomically dequeue. The `*flag` notation here means that the `flags` member has been set to `NET_BUF_FRAGS` in order to be able to reconstruct the frags pointers when dequeuing. After this patch, the layout changes considerably: 2.1 Before enqueueing: +--------+ +--------+ +--------+ |#1 node|--NULL |#2 node|--NULL |#3 node|--NULL | | | | | | | frags |-------| frags |-------| frags |------NULL +--------+ +--------+ +--------+ This is very similar to 1.1, except that now node and frags are different pointers, so node is just set to NULL. 2.2 After enqueueing: +--------+ +--------+ +--------+ |q/slist |------|#1 node|------|q/slist | |node | | | |node | | | | frags | | | +--------+ +--------+ +--------+ | +--------+ +--------+ | |#2 node|--NULL |#3 node|--NULL | | | | | +-----------| frags |-------| frags |------NULL +--------+ +--------+ When enqueuing net_buf #1, now we only enqueue that very item, instead of enqueing the frags as well, since now node and frags are separate pointers. This simplifies the operation and makes it atomic. Resolves #52718. Signed-off-by: Carles Cufi <[email protected]> (cherry picked from commit 3d306c1)
fabiobaltieri
added a commit
that referenced
this pull request
Oct 25, 2023
Add a step to the #1 twister shard to upload the list of Python packages used with the build. Signed-off-by: Fabio Baltieri <[email protected]>
fabiobaltieri
added a commit
that referenced
this pull request
Oct 25, 2023
Add a step to the #1 twister shard to upload the list of Python packages used with the build. Signed-off-by: Fabio Baltieri <[email protected]>
fabiobaltieri
pushed a commit
that referenced
this pull request
Jan 26, 2024
Previously the sample was using some headers that aren't
available to the host, now we can add a `Makefile.host` to
compile the example on a POSIX OS like Linux:
```
# Go to the sample dir
cd ${ZEPHYR_BASE}/samples/posix/uname
# Compile the sample
make -f Makefile.host
# Run the binary
./build/uname
sysname[65]: Linux
nodename[65]: LAPTOP-YC
release[65]: 5.10.16.3-microsoft-standard-WSL2
version[65]: #1 SMP Fri Apr 2 22:23:49 UTC 2021
machine[65]: x86_64
```
Signed-off-by: Yong Cong Sin <[email protected]>
carlescufi
pushed a commit
that referenced
this pull request
Oct 26, 2024
hci_packet_complete(buf, buf_size) should check whether buf_size is
enough.
For instance, hci_packet_complete can receive buf with buf_size 1,
leading to the buffer overflow in cmd->param_len, which is buf[3].
This can happen when rx_thread() receives two frames in 512 bytes
and the first frame size is 511. Then, rx_thread() will call
hci_packet_complete() with 1.
==5==ERROR: AddressSanitizer: global-buffer-overflow on address
0x000000ad81c2 at pc 0x0000005279b3 bp 0x7fffe74f5b70 sp 0x7fffe74f5b68
READ of size 2 at 0x000000ad81c2 thread T6
#0 0x5279b2 (/root/zephyr.exe+0x5279b2)
#1 0x4d697d (/root/zephyr.exe+0x4d697d)
#2 0x7ffff60e5daa (/lib/x86_64-linux-gnu/libc.so.6+0x89daa)
(BuildId: 2e01923fea4ad9f7fa50fe24e0f3385a45a6cd1c)
0x000000ad81c2 is located 2 bytes to the right of global variable
'rx_thread.frame' defined in 'zephyr/drivers/bluetooth/hci/userchan.c'
(0xad7fc0) of size 512
SUMMARY: AddressSanitizer: global-buffer-overflow
(/root/zephyr.exe+0x5279b2)
Thread T6 created by T2 here:
#0 0x48c17c (/root/zephyr.exe+0x48c17c)
#1 0x530192 (/root/zephyr.exe+0x530192)
#2 0x4dcc22 (/root/zephyr.exe+0x4dcc22)
Thread T2 created by T1 here:
#0 0x48c17c (/root/zephyr.exe+0x48c17c)
#1 0x530192 (/root/zephyr.exe+0x530192)
#2 0x4dcc22 (/root/zephyr.exe+0x4dcc22)
Thread T1 created by T0 here:
#0 0x48c17c (/root/zephyr.exe+0x48c17c)
#1 0x52f36c (/root/zephyr.exe+0x52f36c)
#2 0x5371dc (/root/zephyr.exe+0x5371dc)
#3 0x5312a6 (/root/zephyr.exe+0x5312a6)
#4 0x52ed7b (/root/zephyr.exe+0x52ed7b)
#5 0x52eddd (/root/zephyr.exe+0x52eddd)
#6 0x7ffff6083c89 (/lib/x86_64-linux-gnu/libc.so.6+0x27c89)
(BuildId: 2e01923fea4ad9f7fa50fe24e0f3385a45a6cd1c)
==5==ABORTING
Signed-off-by: Sungwoo Kim <[email protected]>
nashif
pushed a commit
that referenced
this pull request
Nov 7, 2024
With introduction of Raw modes, nRF70 driver now advertises get_c
onfig OP, but doesn't implement all types.
This causes problems two-fold with checksum calculations:
1. The "config" isn't uninitialized, so, every call returns differnet
values. So, for UDP header checksum would be done and
pkt->chksumdone would be set. But for IPv4 header checksum might be
skipped.
2. Even if we initialize to zero, then network stack gets all zeros
and calculates checksum by itself rendering offload moot.
There is another problem in #1, as there is only single flag for pkt for
all checksum, nRF70 driver sees this and tells UMAC to skip checksum for
the entire packet. The design isn't coherent, and should be converted to
communicate per-type checksum status (some are filled by network stack
and some HW).
But as nRF70 support all checksum offloads, advertise all types for both
RX and TX.
Upstream PR #: 80882
Signed-off-by: Chaitanya Tata <[email protected]>
nashif
pushed a commit
that referenced
this pull request
May 21, 2025
Current code does not build on Cortex-M0, seems like it does not like subs: Error: instruction not supported in Thumb16 mode -- `subs r3,#1' Adding a unified assembler language declaration in the snippet seems to fix the problem, also add an M0+ board so this is tested in CI. Signed-off-by: Fabio Baltieri <[email protected]>
stephanosio
pushed a commit
that referenced
this pull request
Sep 13, 2025
Add support for NV12/NV21, NV16/NV61 and YUV420/YVU420 (semi)planar formats which can be output by the main #1 pipe. Signed-off-by: Alain Volmat <[email protected]>
kartben
pushed a commit
that referenced
this pull request
Nov 27, 2025
Map all pins of RT685's Flexcomm #1 peripheral. Needed for opration of Flexcomm #1 in I2S mode or Flexcomm #3 in I2S mode with shared signals. Signed-off-by: Vit Stanicek <[email protected]>
kartben
pushed a commit
that referenced
this pull request
Nov 27, 2025
Add SCK and WS signals to a shared signal set between Flexcomm #1 and Flexcomm #3 for the mimxrt685_evk/mimxrt685s/cm33. This enables the board to both transmit and receive audio, as the BCK and WS signals produced by the WM8904 codec are only connected to the Flexcomm #1 peripheral. Signed-off-by: Vit Stanicek <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Signed-off-by: Anas Nashif [email protected]