On the December 19 call, I committed to sending the instructions I had
provided to the Linaro LITE team to build a bootable image that can be
used to develop and test OpenAMP with Linux on Xilinx QEMU.
I am using this setup to work with Paul Sokolovsky on getting CI for
OpenAMP on QEMU using LAVA.
This is a first cut. Feedback is welcome.
Regards,
Ed M
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
Hello,
We have our normal meeting tomorrow as agreed last meeting.
I have updated the wiki page[1] with Notes from Last meeting and some potrencial agenda items for this week.
If you have other agenda items please reply to this e-mail and/or edit the wiki page.
So far we have:
* 64 bit support in Resource Tables
* Discuss Ben's patches?
* Discuss chair/host for Jan 2 or cancel (Bill is on vacation)
Thanks,
Bill
[1] https://github.com/OpenAMP/open-amp/wiki/OpenAMP-remoteproc-Subgroup-Meetin…
---------------------------------------------------
William A. Mills
Chief Technologist, Open Source
Texas Instruments, Processors
20250 Century Blvd, Suit 300
Germantown MD, 20874
(work/mobile) +1-240-643-0836
Hi all,
As stated in some previous OpenAMP meeting, we encountered a
limitation with remoteproc resource table. Indeed, all resources
are encoded using 32 bits fields whereas the memory accessible
on our processor is above the 32 bits boundary.
For instance, when the physical address is 0x1_0000_0000, then
this PA can't be inserted in the resource table or it will be
truncated to 0. This can temporarily be workarounded by using
device tree dma-ranges (at least on Linux) to have a correct DA
but the PA will still be truncated. Moreover, this only work
if you can remap the 64 bits memory zone to a 32 bits one (this
almost implies to have an IOMMU in front of the device).
Since 64 bits systems are now pretty common, it seems clear that
we need to modify the resource table to support 64 bits addresses.
In the same time, it will also be necessary to use 64 bits storage
for virtio device features. Some of them already need more than
32 bits (virtio-net features for instance).
Both modifications requires to handle versionning in the resource
table.
The following suggestions are mainly a RFC ! Please feel free
to comment any of the proposed modifications.
Versionning
-----------
Currently, the supported version is "1".
I propose to increment this number (version 2 ?) which will allow
to add necessary evolutions for 64 bits support. This version
should probably support both old format and new 64 bits support
(comments are welcomed).
64 bits addresses
-----------------
Since most of the systems are now using 64bits addresses, it is
necessary to support such configuration
There are various problems which occurs when modifying these fields
- Retro compatibility (We probably must keep it)
- Fields alignment (Some architecture might not handle misalignment)
- 32 bit remote vs 64 bits master
Regarding the retrocompatibility, it appears clear that modifiying
existing resources is probably not feasible due to missing
reserved fields. It will probably be necessary to create a
secondary type of resources which are almost the same as the 32bits
one. For instance for a vdev, we will have the "classic" rsc flavor:
struct fw_rsc_carveout {
u32 da;
u32 pa;
u32 len;
u32 flags;
u32 reserved;
u8 name[32];
} __packed;
And the 64 bits one:
struct fw_rsc_carveout_64 {
u64 da;
u64 pa;
u32 len;
u32 flags;
u32 reserved;
u8 name[32];
} __packed;
This does not seems really ideal and adds a lot of duplication but
I do not have (yet) any better idea (again, comments are welcomed !).
However, what should we do with the other fields ? Let them on 32
bits or change them all to use 64 bits ? If keeping some of them on
32bits, this can lead to misaligned members (since they are packed,
the compiler will force the alignment). Since some architecture do
not support that well, it's probably better to ensure all fields
will be aligned on their natural type boundary. it also means that
all structures sizes must be a multiple of 8 bytes.
If we don't want to guarantee alignment, then I do not have yet
a clear picture of what it would involve on various drivers which
accesses the memory of the resource table (rproc, virtio for the
config space, etc) and what are their assumptions about that.
If this can be accepted, then the question of the 64 bits master
versus the 32 bits remote can be addressed. I think this is probably
orthogonal to the fact we can have 64 bits addresses in the resource
table. Indeed, if both PA and DA are stored using 64 bits, then,
there is no limitation on what can be done on theses addresses.
For instance, on Linux Kernel, the device tree can allow remapping
64 bits to 32 bits using dma-ranges.
Features
--------
In virtio, the set of features is a bitfield of 64 bits. The current
virtio-rproc implementation only allows for 32bits features. This
is already limiting since virtio-net needs more than 32 bits
(VIRTIO_NET_F_STANDBY and VIRTIO_NET_F_SPEED_DUPLEX).
So these fields (gfeatures, etc) will also need to be udated to 64
bits variants. It might also be a good idea to keep in mind that
future evolutions will probably extend the available features.
Comments are welcomed !
Regards,
Clément Léger
Add proof of concept demo showing the use of RPMsg payloads
with payload information as pointer to large buffer in a
contiguously laid out memory space between APU and RPU with RPMsg
userspace on the APU side and baremetal on the RPU side.
Ben Levinsky (6):
apps: add out of band rpmsg echo demo
apps: oob echo: change message to timestamp and fix alignment
apps: oob echo : remove unused variables and fix apu side waiting
apps: oob echo: move code common in multiple files to header
apps: oob echo: remove commented out line
apps: oob echo: change packet fields to unsigned int
All,
We have an openamp remoteproc sub group call this Thursday 12/05 in our normal timeslot.
What topics should we discuss?
I won't have time to make progress on the Staging tree or CI loop from last time so I don't see value in reviting them this time.
Suman has posted a writeup for rpmsg-proto to this list.
https://lists.openampproject.org/pipermail/openamp-rp/attachments/20191125/…
This is the socket based interface to rpmsg that TI has been using for several years.
We could discuss this on Thursday.
What else should we discuss?
Thanks,
Bill
---------------------------------------------------
William A. Mills
Chief Technologist, Open Source
Texas Instruments, Processors
20450 Century Blvd
Germantown MD, 20871
(work/mobile) +1-240-643-0836
Here is the README for the Docker Container discussed in today's call:
# Running the container:
docker run -it xilinx-qemu
This boots a Linux image (with ramdisk) and a device tree.
The image contains the OpenAMP demo firmware images and
examples.
Alternatively,
docker run -it -v <path_to_tftpboot_directory>:/tftpboot xilinx-qemu
adds <path_to_tftpboot_directory> on the host system as /tftpboot
inside the container, allowing a user to fetch arbitrary files, including
Linux executables and firmware images, from within the container.
# Running the OpenAMP echo test example
* Log in to the emulated Linux as root (password is also "root").
* Set up the R5 firmware: echo image_echo_test >/sys/class/remoteproc/remoteproc0/firmware
* Start the R5: echo start >/sys/class/remoteproc/remoteproc0/state
* Run the example: echo_test
# Random notes:
The version of QEMU that this uses is built from the xilinx-v2019.1
tag on GitHub for Debian Stretch. Debian Stretch was chosen for the base
of this container because Linaro uses it extensively and this way the
executables are compatible across the various Linaro containers.
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
Hi All,
Attached are some short notes on some of the current issues. There may be couple of different implementations floating around, so issues may vary.
Regards
Suman
-----Original Appointment-----
From: Nathalie Chan King Choy [mailto:nathalie@xilinx.com]
Sent: Sunday, November 03, 2019 9:52 AM
To: Nathalie Chan King Choy; Anna, Suman; tsc(a)lists.openampproject.org; openamp-rp(a)lists.openampproject.org
Cc: Christian Daudt; Felix Burton; Michael May; nathalie-ckc(a)kestrel-omnitech.com; Manjukumar Harthikote Matha; Joe Fabbre; Raghuraman, Arvind; Vincent Chardon; Clément Leger; Tony McDowell; Bruce Ashfield; Grosen, Mark; mathieu.poirier(a)linaro.org; Wesley Skeffington; Ed T. Mooring; Mills, William; don.harbin(a)linaro.org
Subject: FW: OpenAMP weekly slot for TSC and sub-groups
When: Monday, November 25, 2019 9:00 AM-10:00 AM (UTC-08:00) Pacific Time (US & Canada).
Where: Zoom
Suman,
Welcome back!
Are you getting these meeting requests?
This one on Monday I want to talk about patch backlog. I think you should attend.
There appears to be pretty decent interest in the socket based interface.
You told me before that is has some warts. Can you write that up?
Are the limitations due to the current kernel implementation or inherent in the rpmsg protocol?
I expect there is some of both. Either way it would be good to get down in writing.
Thanks,
Bill
-----Original Appointment-----
From: Nathalie Chan King Choy [mailto:nathalie@xilinx.com]
Sent: Sunday, November 3, 2019 10:52 AM
To: Nathalie Chan King Choy; tsc(a)lists.openampproject.org<mailto:tsc@lists.openampproject.org>; openamp-rp(a)lists.openampproject.org<mailto:openamp-rp@lists.openampproject.org>
Cc: Christian Daudt; Felix Burton; Michael May; nathalie-ckc(a)kestrel-omnitech.com<mailto:nathalie-ckc@kestrel-omnitech.com>; Manjukumar Harthikote Matha; Joe Fabbre; Raghuraman, Arvind; Vincent Chardon; Clément Leger; Tony McDowell; Bruce Ashfield; Grosen, Mark; mathieu.poirier(a)linaro.org<mailto:mathieu.poirier@linaro.org>; Wesley Skeffington; Ed T. Mooring; Mills, William; Don Harbin
Subject: OpenAMP weekly slot for TSC and sub-groups
When: Monday, November 25, 2019 9:00 AM-10:00 AM (UTC-08:00) Pacific Time (US & Canada).
Where: Zoom
https://zoom.us/j/4762224131
Hi all,
Due to travel for the OpenAMP Remoteproc discussion leads, we’re pushing this Thursday’s call out to Monday.
Notes from the meetings can be found on the GitHub wiki:
https://github.com/OpenAMP/open-amp/wiki/Meeting-Notes
Best regards,
Nathalie C. Chan King Choy
Project Manager focused on Open Source & Community
<< File: ATT00001.txt >>
Hi All,
Attached are some short notes on some of the current issues. There may
be couple of different implementations floating around, so issues may
vary.
Regards
Suman
-----Original Appointment-----
From: Nathalie Chan King Choy [[1]mailto:nathalie@xilinx.com]
Sent: Sunday, November 03, 2019 9:52 AM
To: Nathalie Chan King Choy; Anna, Suman; tsc(a)lists.openampproject.org;
openamp-rp(a)lists.openampproject.org
Cc: Christian Daudt; Felix Burton; Michael May;
nathalie-ckc(a)kestrel-omnitech.com; Manjukumar Harthikote Matha; Joe
Fabbre; Raghuraman, Arvind; Vincent Chardon; Clément Leger; Tony
McDowell; Bruce Ashfield; Grosen, Mark; mathieu.poirier(a)linaro.org;
Wesley Skeffington; Ed T. Mooring; Mills, William;
don.harbin(a)linaro.org
Subject: FW: OpenAMP weekly slot for TSC and sub-groups
When: Monday, November 25, 2019 9:00 AM-10:00 AM (UTC-08:00) Pacific
Time (US & Canada).
Where: Zoom
Suman,
Welcome back!
Are you getting these meeting requests?
This one on Monday I want to talk about patch backlog. I think you
should attend.
There appears to be pretty decent interest in the socket based
interface.
You told me before that is has some warts. Can you write that up?
Are the limitations due to the current kernel implementation or
inherent in the rpmsg protocol?
I expect there is some of both. Either way it would be good to get
down in writing.
Thanks,
Bill
-----Original Appointment-----
From: Nathalie Chan King Choy [[2]mailto:nathalie@xilinx.com]
Sent: Sunday, November 3, 2019 10:52 AM
To: Nathalie Chan King Choy; [3]tsc(a)lists.openampproject.org;
[4]openamp-rp(a)lists.openampproject.org
Cc: Christian Daudt; Felix Burton; Michael May;
[5]nathalie-ckc(a)kestrel-omnitech.com; Manjukumar Harthikote Matha; Joe
Fabbre; Raghuraman, Arvind; Vincent Chardon; Clément Leger; Tony
McDowell; Bruce Ashfield; Grosen, Mark; [6]mathieu.poirier(a)linaro.org;
Wesley Skeffington; Ed T. Mooring; Mills, William; Don Harbin
Subject: OpenAMP weekly slot for TSC and sub-groups
When: Monday, November 25, 2019 9:00 AM-10:00 AM (UTC-08:00) Pacific
Time (US & Canada).
Where: Zoom
[7]https://zoom.us/j/4762224131
Hi all,
Due to travel for the OpenAMP Remoteproc discussion leads, we’re
pushing this Thursday’s call out to Monday.
Notes from the meetings can be found on the GitHub wiki:
[8]https://github.com/OpenAMP/open-amp/wiki/Meeting-Notes
Best regards,
Nathalie C. Chan King Choy
Project Manager focused on Open Source & Community
<< File: ATT00001.txt >>
References
1. mailto:nathalie@xilinx.com
2. mailto:nathalie@xilinx.com
3. mailto:tsc@lists.openampproject.org
4. mailto:openamp-rp@lists.openampproject.org
5. mailto:nathalie-ckc@kestrel-omnitech.com
6. mailto:mathieu.poirier@linaro.org
7. https://zoom.us/j/4762224131
8. https://github.com/OpenAMP/open-amp/wiki/Meeting-Notes
