Branch: refs/heads/main
Home: https://github.com/OpenAMP/open-amp
Commit: bb45852c584be0746f1eb3c62052f214606b4bac
https://github.com/OpenAMP/open-amp/commit/bb45852c584be0746f1eb3c62052f214…
Author: Sipke Vriend <sipke(a)direktembedded.com>
Date: 2026-09-09 (Wed, 09 Sep 2026)
Changed paths:
M README.md
Log Message:
-----------
README: use shell block for commands in Markdown files
Use the markdown shell block instead of prepending $ to command so that
users can copy the block, as supported in github and IDEs.
Signed-off-by: Sipke Vriend <sipke(a)direktembedded.com>
Commit: c0359e4ae5bfa71a09654c78abf0049d6b06720a
https://github.com/OpenAMP/open-amp/commit/c0359e4ae5bfa71a09654c78abf0049d…
Author: Sipke Vriend <sipke(a)direktembedded.com>
Date: 2026-09-09 (Wed, 09 Sep 2026)
Changed paths:
M .github/actions/build_ci/README.md
M README.md
Log Message:
-----------
github actions:README: use shell block for commands in Markdown files
Use the markdown shell block instead of prepending $ to command so that
users can copy the block, as supported in github and IDEs.
Signed-off-by: Sipke Vriend <sipke(a)direktembedded.com>
Commit: 2b172cef30f1563d01a7a8ba7ca0027964c78dd6
https://github.com/OpenAMP/open-amp/commit/2b172cef30f1563d01a7a8ba7ca00279…
Author: Sipke Vriend <sipke(a)direktembedded.com>
Date: 2026-09-09 (Wed, 09 Sep 2026)
Changed paths:
M .github/actions/build_ci/README.md
Log Message:
-----------
github actions:README: add some new lines and code block for clarity
Multiple lines of text are concatenated so use a code block for the
supported targets so they are on individual lines.
Signed-off-by: Sipke Vriend <sipke(a)direktembedded.com>
Compare: https://github.com/OpenAMP/open-amp/compare/2e83e405d3a0...2b172cef30f1
To unsubscribe from these emails, change your notification settings at https://github.com/OpenAMP/open-amp/settings/notifications
Branch: refs/heads/main
Home: https://github.com/OpenAMP/open-amp
Commit: c2c26fce51cd0f20719187db5640d8bf3a02bf2b
https://github.com/OpenAMP/open-amp/commit/c2c26fce51cd0f20719187db5640d8bf…
Author: Chirag Shilwant <c-shilwant(a)ti.com>
Date: 2026-09-09 (Wed, 09 Sep 2026)
Changed paths:
M lib/rpmsg/rpmsg_virtio.c
Log Message:
-----------
rpmsg: Fix RPMSG_BUF_INDEX macro to use parameter
The macro body references 'rp_hdr' instead of using the declared
parameter 'rphdr'. This causes the macro to ignore its argument and
always reference whatever 'rp_hdr' variable exists in the calling
scope. Fix by using the parameter name in the macro body.
Fixes: commit b32187e4fb89 ("openamp: change rx/tx buffer hold flag to count")
Signed-off-by: Chirag Shilwant <c-shilwant(a)ti.com>
Commit: 2e83e405d3a0c2d0ae53385e14e6332af79a6339
https://github.com/OpenAMP/open-amp/commit/2e83e405d3a0c2d0ae53385e14e6332a…
Author: Chirag Shilwant <c-shilwant(a)ti.com>
Date: 2026-09-09 (Wed, 09 Sep 2026)
Changed paths:
M lib/rpmsg/rpmsg_virtio.c
Log Message:
-----------
rpmsg: virtio: Change release_rx_buffer_nolock() return type to void
The function unconditionally returns true and neither call site
checks the return value. Remove the dead return and change the
return type to void.
Fixes: commit b32187e4fb89 ("openamp: change rx/tx buffer hold flag to count")
Signed-off-by: Chirag Shilwant <c-shilwant(a)ti.com>
Compare: https://github.com/OpenAMP/open-amp/compare/4ae383d32de3...2e83e405d3a0
To unsubscribe from these emails, change your notification settings at https://github.com/OpenAMP/open-amp/settings/notifications
TLDR: virtio-remoteproc device reset
To request a device reset (w/ acknowledgement), the driver should
val = Status field // read current status field
val |= 0x82 // set bits 7 and 1 (FAILED and DRIVER)
val &= 0xfe // clear bit 0 (ACKNOWLEDGE)
// leave other bits unchanged
Status field = val // write the new status field value
The driver should then poll the status field waiting for it to be == 0.
Note: writing the status field to 0 when it is already non-zero, should
continue to work as a device reset but the driver will not know when it is
complete.
Background:
From the virtio spec [1] with extra clarity added by me.
Status Field bits: (Spec section 2.1, html [2])
bit 0, 0x01, dec 1 ACKNOWLEDGE
bit 1, 0x02, dec 2 DRIVER
bit 2, 0x04, dec 4 DRIVER_OK
(also used in suspend protocol)
bit 3, 0x08, dec 8 FEATURES_OK
bit 4, 0x10, dec 16 SUSPEND
only used if negotiated
bit 5, 0x20, dec 32 (currently unused)
bit 6, 0x40, dec 64 DEVICE_NEEDS_RESET
bit 7, 0x80, dec 128 FAILED
All bits except DEVICE_NEEDS_RESET are set (and sometimes cleared) by the
device. DEVICE_NEEDS_RESET is set by the device and should only be cleared
by a reset.
Logically the driver sets ACKNOWLEDGE, then DRIVER, then DRIVER_OK, then
FEATURES_OK. Some of these could be set at the same time but never higher
bits before lower bits. Once these bits are set, the driver in not allowed
to clear them except by issuing a device reset. The one exception to this
is that the DRIVER_OK bit is cleared and set as part of the SUSPEND
protocol but only if it has been negotiated.
The driver sets the FAILED bit when it has given up on the device.
It is valid for FAILED with any of the following settings:
0b1xxx_0000 Fail before ack
0b1xxx_0001 Fail before driver found
0b1xxx_0011 Fail before driver OK
0b1xxx_0111 Fail before features OK
0b1xxx_1111 Fail after features OK
And if SUSPEND has been negotiated
0b1xx1_0011 Fail while suspend active before features OK
0b1xx1_1011 Fail while Suspend active after features OK
FAILED(0x80) and DRIVER (0x02) active with ACKNOWLEDGE(0x01) cleared is not
a value that is possible in the base spec. Therefore we use this setting
to request a reset w/ acknowledgement.
0b1xxx_xx10 Reset Request w/ acknowledgement
TBD:
Does/Should the driver send a notification on Status field change?
Does/Should the device send a notification on Status field change?
Sending the notice eliminates the need for a time on the other side to
poll. Do we already support this? If not, probibly not worth it just for
this protocol.
Recent virtio-mmio enhancement:
The patch in [3] is now in the virtio spec master branch but is not part of
any released version yet. The patch adds a new V3 version of virtio-mmio
where the driver can issue a non-blocking reset request and poll the status
field to know when it is done.
So we are not the only ones to notice this issue. However the solution
used for virtio-mmio still requires trap and emulate to work and wont work
if the Status field in located in normal memory of any type.
In the patch the driver still writes 0 to the status field but the device
is allowed to return from the MMR write with the status filed non-zero.
The driver then waits for the status field to become zero to know when this
operation is complete.
This solution will not work for us as we use a real memory to store the
status field and the driver writing that to 0 will take immediate effect
and the driver then polling for zero would succeed immediately.
Bill
[1] https://docs.oasis-open.org/virtio/virtio/v1.4/virtio-v1.4.html
[2] https://docs.oasis-open.org/virtio/virtio/v1.4/virtio-v1.4.html#x1-110001
[3]
https://github.com/Linaro/virtio-msg-spec/commit/a1883517ee44cc03d1b621a331…
--
Bill Mills
Principal Technical Consultant, Linaro
+1-240-643-0836
TZ: US Eastern
Work Schedule: Tues/Wed/Thur