Re: [External Mail]RE: [EXT] Re: RPMsg FS on NuttX and Linux

[Xiang Xiao]

It is planned at the end of this quarter, since we have some features and
optimization not finished yet.

On Tue, Nov 12, 2024 at 11:12 PM Alan C. Assis  wrote:

> Hi Wang Bowen,
>
> Do you have plans to submit and integrate it on the Linux kernel?
>
> I think this way it will be easier for more people start to use RPMSG
> integrated with Linux and NuttX.
>
> BR,
>
> Alan
>
> On Tue, Nov 12, 2024 at 3:27 AM 汪博文  wrote:
>
> > Hi Andre,
> >
> > The attachment is the rpmsg_release_tx_buffer patch file.
> >
> > And thanks for sharing the solution to the rpmsgfs bug in linux 6.6, this
> > is very helpful for us.
> >
> > Kind regards,
> > Wang Bowen
> >
> >  Replied Message 
> > From Andre Heinemans 
> > Date 11/8/2024 21:30
> > To 汪博文,
> > dev@nuttx.apache.org
> > 
> > Subject [External Mail]RE: [EXT] Re: RPMsg FS on NuttX and Linux
> > [外部邮件] 此邮件来源于小米公司外部，请谨慎处理。若对邮件安全性存疑，请将邮件转发给mi...@xiaomi.com进行反馈
> >
> > Hi Wang Bowen,
> >
> > Thanks for sending me the updated files.
> >
> > I think I found the problem with the move/rename. When porting to 6.6.23
> I
> > had to adapt the assignment of 'struct renamedata rd' since the struct
> got
> > changed in commit abf0857.
> > Previously I only updated 'rd.old_mnt_userns = &init_user_ns;' to
> > 'rd.old_mnt_idmap = &nop_mnt_idmap;'. The error disappeared when I added
> > 'rd.new_mnt_idmap = &nop_mnt_idmap;' as well.
> > See below our rpmsgfs_rename_handler.
> >
> > Do you also have the file that contain the rpmsg_release_tx_buffer()
> > function? It could not be resolved. I guess rpmsg_core.c.
> >
> > Kind regards,
> > Andre Heinemans
> >
> > static int rpmsgfs_rename_handler(struct rpmsg_device *rpdev,
> > void *data, int len, void *priv, u32 src)
> > {
> > struct rpmsgfs_rename *msg = data;
> > #if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 12, 0)
> > struct renamedata rd;
> > #endif
> > struct path oldpath, newpath;
> > struct dentry *newdentry;
> > char *oldname, *newname;
> > int ret, oldlen;
> > oldname = msg->pathname;
> > oldlen  = (strlen(msg->pathname) + 1 + 0x7) & ~0x7;
> > newname = msg->pathname + oldlen;
> > ret = kern_path(oldname, 0, &oldpath);
> > if (ret < 0)
> > goto fail;
> > if (!oldpath.dentry || !oldpath.dentry->d_parent) {
> > ret = -ENOENT;
> > goto fail1;
> > }
> > newdentry = kern_path_locked(newname, &newpath);
> > if (IS_ERR(newdentry)) {
> > ret = PTR_ERR(newdentry);
> > goto fail1;
> > }
> > #if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 12, 0)
> > #if LINUX_VERSION_CODE >= KERNEL_VERSION(6, 3, 0)
> > rd.old_mnt_idmap = &nop_mnt_idmap;
> > rd.new_mnt_idmap = &nop_mnt_idmap;
> > #else
> > rd.old_mnt_userns = &init_user_ns;
> > #endif
> > rd.old_dir = oldpath.dentry->d_parent->d_inode;
> > rd.old_dentry = oldpath.dentry;
> > rd.new_dir = d_inode(newpath.dentry);
> > rd.new_dentry = newdentry;
> > rd.delegated_inode = NULL;
> > rd.flags = 0;
> > ret = vfs_rename(&rd);
> > #else
> > ret = vfs_rename(oldpath.dentry->d_parent->d_inode, oldpath.dentry,
> > d_inode(newpath.dentry), newdentry, NULL, 0);
> > #endif
> > dput(newdentry);
> > inode_unlock(d_inode(newpath.dentry));
> > path_put(&newpath);
> > fail1:
> > path_put(&oldpath);
> > fail:
> > msg->header.result = ret;
> > return rpmsg_send(rpdev->ept, msg, sizeof(*msg));
> > }
> >
> > -Original Message-
> > From: 汪博文 
> > Sent: Friday, 8 November 2024 10:11
> > To: dev@nuttx.apache.org; Andre Heinemans 
> > Subject: Re: [External Mail]RE: [EXT] Re: RPMsg FS on NuttX and Linux
> >
> > Caution: This is an external email. Please take care when clicking links
> > or opening attachments. When in doubt, report the message using the
> 'Report
> > this email' button
> >
> > Hi Andre,
> >
> > Sorry for late reply.
> > ‍
> > ‍About your questions:
> > 1. Your small fixes in Linux Rpmsg FS is right or not?
> >
> > ‍‍
> > Yes, your fix is right and we will update our internal version.
> > 2. Any updates in our internal rpmsgfs and rpmsgtty?
> >
> > Actually, only some minor updates:
> > ‍
> > - We changed the rpmsg_fs and rpmsg_tty to kernel modules, and I have
> > attached the new rpmsg_fs.c and rpmsg_tty.c in this

Re: [External Mail]RE: [EXT] Re: RPMsg FS on NuttX and Linux

[Alan C. Assis]

Hi Wang Bowen,

Do you have plans to submit and integrate it on the Linux kernel?

I think this way it will be easier for more people start to use RPMSG
integrated with Linux and NuttX.

BR,

Alan

On Tue, Nov 12, 2024 at 3:27 AM 汪博文  wrote:

> Hi Andre,
>
> The attachment is the rpmsg_release_tx_buffer patch file.
>
> And thanks for sharing the solution to the rpmsgfs bug in linux 6.6, this
> is very helpful for us.
>
> Kind regards,
> Wang Bowen
>
>  Replied Message 
> From Andre Heinemans 
> Date 11/8/2024 21:30
> To 汪博文,
> dev@nuttx.apache.org
> 
> Subject [External Mail]RE: [EXT] Re: RPMsg FS on NuttX and Linux
> [外部邮件] 此邮件来源于小米公司外部，请谨慎处理。若对邮件安全性存疑，请将邮件转发给mi...@xiaomi.com进行反馈
>
> Hi Wang Bowen,
>
> Thanks for sending me the updated files.
>
> I think I found the problem with the move/rename. When porting to 6.6.23 I
> had to adapt the assignment of 'struct renamedata rd' since the struct got
> changed in commit abf0857.
> Previously I only updated 'rd.old_mnt_userns = &init_user_ns;' to
> 'rd.old_mnt_idmap = &nop_mnt_idmap;'. The error disappeared when I added
> 'rd.new_mnt_idmap = &nop_mnt_idmap;' as well.
> See below our rpmsgfs_rename_handler.
>
> Do you also have the file that contain the rpmsg_release_tx_buffer()
> function? It could not be resolved. I guess rpmsg_core.c.
>
> Kind regards,
> Andre Heinemans
>
> static int rpmsgfs_rename_handler(struct rpmsg_device *rpdev,
> void *data, int len, void *priv, u32 src)
> {
> struct rpmsgfs_rename *msg = data;
> #if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 12, 0)
> struct renamedata rd;
> #endif
> struct path oldpath, newpath;
> struct dentry *newdentry;
> char *oldname, *newname;
> int ret, oldlen;
> oldname = msg->pathname;
> oldlen  = (strlen(msg->pathname) + 1 + 0x7) & ~0x7;
> newname = msg->pathname + oldlen;
> ret = kern_path(oldname, 0, &oldpath);
> if (ret < 0)
> goto fail;
> if (!oldpath.dentry || !oldpath.dentry->d_parent) {
> ret = -ENOENT;
> goto fail1;
> }
> newdentry = kern_path_locked(newname, &newpath);
> if (IS_ERR(newdentry)) {
> ret = PTR_ERR(newdentry);
> goto fail1;
> }
> #if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 12, 0)
> #if LINUX_VERSION_CODE >= KERNEL_VERSION(6, 3, 0)
> rd.old_mnt_idmap = &nop_mnt_idmap;
> rd.new_mnt_idmap = &nop_mnt_idmap;
> #else
> rd.old_mnt_userns = &init_user_ns;
> #endif
> rd.old_dir = oldpath.dentry->d_parent->d_inode;
> rd.old_dentry = oldpath.dentry;
> rd.new_dir = d_inode(newpath.dentry);
> rd.new_dentry = newdentry;
> rd.delegated_inode = NULL;
> rd.flags = 0;
> ret = vfs_rename(&rd);
> #else
> ret = vfs_rename(oldpath.dentry->d_parent->d_inode, oldpath.dentry,
> d_inode(newpath.dentry), newdentry, NULL, 0);
> #endif
> dput(newdentry);
> inode_unlock(d_inode(newpath.dentry));
> path_put(&newpath);
> fail1:
> path_put(&oldpath);
> fail:
> msg->header.result = ret;
> return rpmsg_send(rpdev->ept, msg, sizeof(*msg));
> }
>
> -Original Message-
> From: 汪博文 
> Sent: Friday, 8 November 2024 10:11
> To: dev@nuttx.apache.org; Andre Heinemans 
> Subject: Re: [External Mail]RE: [EXT] Re: RPMsg FS on NuttX and Linux
>
> Caution: This is an external email. Please take care when clicking links
> or opening attachments. When in doubt, report the message using the 'Report
> this email' button
>
> Hi Andre,
>
> Sorry for late reply.
> ‍
> ‍About your questions:
> 1. Your small fixes in Linux Rpmsg FS is right or not?
>
> ‍‍
> Yes, your fix is right and we will update our internal version.
> 2. Any updates in our internal rpmsgfs and rpmsgtty?
>
> Actually, only some minor updates:
> ‍
> - We changed the rpmsg_fs and rpmsg_tty to kernel modules, and I have
> attached the new rpmsg_fs.c and rpmsg_tty.c in this email, you can check
> them;
> -  We also add some kernel version checks in rpmsg_fs and rpmsg_tty to make
> them can work with both kernel v5.10 and v5.15 And no other updates in
> rpmsg_fs and rpmsg_tty But we are planing to implement the rpmsg_fs client
> in linux (linux mount nuttx file system) and also port these rpmsg
> services to
> the linux kernel v6.6.
> 3. The panic in linux caused by move or rename operation We haven't
> encountered this problem before, but we can try this case in v6.6 when we
> porting rpmsg services to the new kernel version.
>
> Kind regards,
> Wang Bowen
>
>  Replied Message 
> From   Andre Heinemans <mailto:undefined>
>
> Date   11/8/2024 00:33
> To dev@nuttx.apache.org,
> <mailto:dev@nuttx.apache.

Re: [External Mail]RE: [EXT] Re: RPMsg FS on NuttX and Linux

[汪博文]

Hi Andre,

The attachment is the rpmsg_release_tx_buffer patch file.

And thanks for sharing the solution to the rpmsgfs bug in linux 6.6, this is 
very helpful for us.

Kind regards,
Wang Bowen

 Replied Message 
FromAndre Heinemans<mailto:undefined>
Date11/8/2024 21:30
To  汪博文,
<mailto:wangbow...@xiaomi.com>dev@nuttx.apache.org<mailto:dev@nuttx.apache.org>
Subject [External Mail]RE: [EXT] Re: RPMsg FS on NuttX and Linux
[外部邮件] 此邮件来源于小米公司外部，请谨慎处理。若对邮件安全性存疑，请将邮件转发给mi...@xiaomi.com进行反馈

Hi Wang Bowen,

Thanks for sending me the updated files.

I think I found the problem with the move/rename. When porting to 6.6.23 I had 
to adapt the assignment of 'struct renamedata rd' since the struct got changed 
in commit abf0857.
Previously I only updated 'rd.old_mnt_userns = &init_user_ns;' to 
'rd.old_mnt_idmap = &nop_mnt_idmap;'. The error disappeared when I added 
'rd.new_mnt_idmap = &nop_mnt_idmap;' as well.
See below our rpmsgfs_rename_handler.

Do you also have the file that contain the rpmsg_release_tx_buffer() function? 
It could not be resolved. I guess rpmsg_core.c.

Kind regards,
Andre Heinemans

static int rpmsgfs_rename_handler(struct rpmsg_device *rpdev,
void *data, int len, void *priv, u32 src)
{
struct rpmsgfs_rename *msg = data;
#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 12, 0)
struct renamedata rd;
#endif
struct path oldpath, newpath;
struct dentry *newdentry;
char *oldname, *newname;
int ret, oldlen;
oldname = msg->pathname;
oldlen  = (strlen(msg->pathname) + 1 + 0x7) & ~0x7;
newname = msg->pathname + oldlen;
ret = kern_path(oldname, 0, &oldpath);
if (ret < 0)
goto fail;
if (!oldpath.dentry || !oldpath.dentry->d_parent) {
ret = -ENOENT;
goto fail1;
}
newdentry = kern_path_locked(newname, &newpath);
if (IS_ERR(newdentry)) {
ret = PTR_ERR(newdentry);
goto fail1;
}
#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 12, 0)
#if LINUX_VERSION_CODE >= KERNEL_VERSION(6, 3, 0)
rd.old_mnt_idmap = &nop_mnt_idmap;
rd.new_mnt_idmap = &nop_mnt_idmap;
#else
rd.old_mnt_userns = &init_user_ns;
#endif
rd.old_dir = oldpath.dentry->d_parent->d_inode;
rd.old_dentry = oldpath.dentry;
rd.new_dir = d_inode(newpath.dentry);
rd.new_dentry = newdentry;
rd.delegated_inode = NULL;
rd.flags = 0;
ret = vfs_rename(&rd);
#else
ret = vfs_rename(oldpath.dentry->d_parent->d_inode, oldpath.dentry,
d_inode(newpath.dentry), newdentry, NULL, 0);
#endif
dput(newdentry);
inode_unlock(d_inode(newpath.dentry));
path_put(&newpath);
fail1:
path_put(&oldpath);
fail:
msg->header.result = ret;
return rpmsg_send(rpdev->ept, msg, sizeof(*msg));
}

-----Original Message-----
From: 汪博文 
Sent: Friday, 8 November 2024 10:11
To: dev@nuttx.apache.org; Andre Heinemans 
Subject: Re: [External Mail]RE: [EXT] Re: RPMsg FS on NuttX and Linux

Caution: This is an external email. Please take care when clicking links
or opening attachments. When in doubt, report the message using the 'Report
this email' button

Hi Andre,

Sorry for late reply.
‍
‍About your questions:
1. Your small fixes in Linux Rpmsg FS is right or not?

‍‍
Yes, your fix is right and we will update our internal version.
2. Any updates in our internal rpmsgfs and rpmsgtty?

Actually, only some minor updates:
‍
- We changed the rpmsg_fs and rpmsg_tty to kernel modules, and I have
attached the new rpmsg_fs.c and rpmsg_tty.c in this email, you can check
them;
-  We also add some kernel version checks in rpmsg_fs and rpmsg_tty to make
them can work with both kernel v5.10 and v5.15 And no other updates in
rpmsg_fs and rpmsg_tty But we are planing to implement the rpmsg_fs client
in linux (linux mount nuttx file system) and also port these rpmsg services to
the linux kernel v6.6.
3. The panic in linux caused by move or rename operation We haven't
encountered this problem before, but we can try this case in v6.6 when we
porting rpmsg services to the new kernel version.

Kind regards,
Wang Bowen

 Replied Message 
From   Andre Heinemans <mailto:undefined>

Date   11/8/2024 00:33
To dev@nuttx.apache.org,
<mailto:dev@nuttx.apache.org> Xiang Xiao,
<mailto:xiaoxiang781...@gmail.com> Bowen
Wang <mailto:bowenwa...@gmail.com>
Subject[External Mail]RE: [EXT] Re: RPMsg FS on NuttX and Linux
[外部邮件]
此邮件来源于小米公司外部，请谨慎处理。若对邮件安全性存疑，请将
邮件转发给mi...@xiaomi.com进行反馈

Hi Wang Bowen, Xiang Xiao,

When I want to move a file through rpmsgfs from within nuttx on a filesystem
hosted on linux, then I get this linux kernel oops below.
I used the rpmsgfs linux implementation provided on this mail thread but
ported it to 6.6.23.

It looks like every move or rename gives the error. Do you know what could
cause the problem?

Are there maybe any updates of the linux rpmsgfs driver which I could try?

Kind regards,
Andre

[  121.160624] Unable to handle kernel paging request at virtual address
8003848c38dc [  

Re: [External Mail]RE: [EXT] Re: RPMsg FS on NuttX and Linux

[汪博文]

Hi Andre,

Sorry for late reply.
‍
‍About your questions:
1. Your small fixes in Linux Rpmsg FS is right or not?
‍‍
 Yes, your fix is right and we will update our internal version.
2. Any updates in our internal rpmsgfs and rpmsgtty?
Actually, only some minor updates:
‍
- We changed the rpmsg_fs and rpmsg_tty to kernel modules, and I have attached 
the
new rpmsg_fs.c and rpmsg_tty.c in this email, you can check them;
-  We also add some kernel version checks in rpmsg_fs and rpmsg_tty to make 
them can
work with both kernel v5.10 and v5.15
And no other updates in rpmsg_fs and rpmsg_tty
But we are planing to implement the rpmsg_fs client in linux (linux mount nuttx 
file system) and also
port these rpmsg services to the linux kernel v6.6.
3. The panic in linux caused by move or rename operation
We haven't encountered this problem before, but we can try this case in v6.6 
when we porting rpmsg
services to the new kernel version.

Kind regards,
Wang Bowen
 Replied Message 
FromAndre Heinemans
Date11/8/2024 00:33
To  dev@nuttx.apache.org,
Xiang Xiao,
Bowen 
Wang
Subject [External Mail]RE: [EXT] Re: RPMsg FS on NuttX and Linux
[外部邮件] 此邮件来源于小米公司外部，请谨慎处理。若对邮件安全性存疑，请将邮件转发给mi...@xiaomi.com进行反馈

Hi Wang Bowen, Xiang Xiao,

When I want to move a file through rpmsgfs from within nuttx on a filesystem 
hosted on linux, then I get this linux kernel oops below.
I used the rpmsgfs linux implementation provided on this mail thread but ported 
it to 6.6.23.

It looks like every move or rename gives the error. Do you know what could 
cause the problem?

Are there maybe any updates of the linux rpmsgfs driver which I could try?

Kind regards,
Andre

[  121.160624] Unable to handle kernel paging request at virtual address 
8003848c38dc
[  121.168612] Mem abort info:
[  121.171464]   ESR = 0x9605
[  121.175216]   EC = 0x25: DABT (current EL), IL = 32 bits
[  121.180568]   SET = 0, FnV = 0
[  121.183660]   EA = 0, S1PTW = 0
[  121.186801]   FSC = 0x05: level 1 translation fault
[  121.191709] Data abort info:
[  121.194592]   ISV = 0, ISS = 0x0005, ISS2 = 0x
[  121.200094]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[  121.205172]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[  121.210511] swapper pgtable: 4k pages, 48-bit VAs, pgdp=9216d000
[  121.217236] [8003848c38dc] pgd=10047003, p4d=10047003, 
pud=
[  121.225975] Internal error: Oops: 9605 [#1] PREEMPT SMP
[  121.232241] Modules linked in:
[  121.235320] CPU: 0 PID: 8 Comm: kworker/0:0 Not tainted 6.6.23-g32082bae40f6 
#55
[  121.242735] Hardware name: NXP i.MX95 19X19 board (DT)
[  121.247885] Workqueue: imx95-cm7 imx_rproc_vq_work
[  121.252703] pstate: a049 (NzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[  121.259678] pc : cmp_map_id+0x4/0x64
[  121.263266] lr : bsearch+0x50/0xb8
[  121.266698] sp : 8000825d39e0
[  121.270026] x29: 8000825d39e0 x28: 812c7600 x27: 824f8900
[  121.277176] x26: 8000825d3bd8 x25: 800080158ae0 x24: 8000825d3a5c
[  121.284326] x23: 800080fffe1c x22: 000c x21: 404baf90
[  121.291476] x20: 8003848c38dc x19: 80975f1f x18: 800082e7be28
[  121.298626] x17: 672cba83 x16: 0fdc x15: 1000
[  121.305793] x14:  x13: 8086e029 x12: 8000825d3a74
[  121.312943] x11: 00075b7a4da2 x10: 0002 x9 : 0007
[  121.320102] x8 : 8874affc x7 : 000c x6 : 0001
[  121.327243] x5 : 0001 x4 : 0001 x3 : 000c
[  121.334385] x2 : 80975f20 x1 : 8003848c38dc x0 : 8000825d3a5c
[  121.341536] Call trace:
[  121.343997]  cmp_map_id+0x4/0x64
[  121.347238]  map_id_up+0xe4/0xec
[  121.350479]  from_kuid+0x10/0x1c
[  121.353712]  from_vfsuid+0x48/0x7c
[  121.357135]  vfs_rename+0x43c/0xa14
[  121.360627]  rpmsgfs_rename_handler+0xcc/0x148
[  121.365091]  rpmsgfs_callback+0x34/0x88
[  121.368930]  rpmsg_recv_done+0x114/0x368
[  121.372874]  vring_interrupt+0x74/0x110
[  121.376721]  rproc_vq_interrupt+0x3c/0x90
[  121.380751]  imx_rproc_notified_idr_cb+0x18/0x28
[  121.385397]  idr_for_each+0x68/0xf4
[  121.388907]  imx_rproc_vq_work+0x24/0x30
[  121.392850]  process_one_work+0x138/0x260
[  121.396880]  worker_thread+0x32c/0x438
[  121.400633]  kthread+0x118/0x11c
[  121.403883]  ret_from_fork+0x10/0x20
[  121.407506] Code: 1280 17dd  3944 (29400823)
[  121.413609] ---[ end trace  ]---

-Original Message-
From: Andre Heinemans 
Sent: Friday, 1 November 2024 12:14
To: dev@nuttx.apache.org
Subject: RE: [EXT] Re: RPMsg FS on NuttX and Linux

Caution: This is an external email. Please take care when clicking links or 
opening
attachments. When in doubt, report the message using the 'Report th

Re: [External Mail]RE: [EXT] Re: RPMsg FS on NuttX and Linux

[汪博文]

Hi Andre,

I changed my email account and sent again.

Kind regards,
Wang Bowen


Bowen Wang, wangbow...@xiaomi.com

From: Andre Heinemans
Date: 2024-06-27 18:02
To: dev@nuttx.apache.org
Subject: [External Mail]RE: [EXT] Re: RPMsg FS on NuttX and Linux
[外部邮件] 此邮件来源于小米公司外部，请谨慎处理。若对邮件安全性存疑，请将邮件转发给mi...@xiaomi.com进行反馈

Hi Bowen,

It seems that the attachment didn’t come through. Could you send them again?

For us it is sufficient that Linux can host the server side. The goal is to 
supply some storage space to Nuttx and our system (i.MX95) does not have any 
physical storage attached to the NuttX core.

Kind regards,
Andre

From: Bowen Wang 
Sent: Thursday, 27 June 2024 11:26
To: dev@nuttx.apache.org
Subject: Re: [EXT] Re: RPMsg FS on NuttX and Linux

Caution: This is an external email. Please take care when clicking links or 
opening attachments. When in doubt, report the message using the 'Report this 
email' button

Hi Andre,

The attachment is the patch for rpmsgfs, we only implement the rpmsgfs server 
side in linux for now, rpmsgfs client side in linux is still under development.
So we can access the  Linux‘s file system in
NuttX, but in Linux, we can't mount the Vela's
file system.


Kind regards,
Wang Bowen

Andre Heinemans mailto:andre.heinem...@nxp.com>> 
于2024年6月27日周四 17:12写道：
Hi Bowen,

I am using 6.6.3. But it would be okay for me if I receive the patches for 
version 5.15. I will try to adapt them.

Thanks in advance!

Kind regards,
Andre

-Original Message-
From: Bowen Wang mailto:bowenwa...@gmail.com>>
Sent: Thursday, 27 June 2024 03:46
To: dev@nuttx.apache.org
Subject: [EXT] Re: RPMsg FS on NuttX and Linux

Caution: This is an external email. Please take care when clicking links or 
opening attachments. When in doubt, report the message using the 'Report this 
email' button


Hi, Andre

Which Linux version are you using?
We have adapted RPMSGFS on 5.4 and 5.15. We are not sure if it meets your 
requirements.

Kind regards,
Wang Bowen

Xiang Xiao mailto:xiaoxiang781...@gmail.com>> 
于2024年6月25日周二 22:47写道：

> rpmsg_fs isn't upstreamed to the Linux community yet. Bowen could give
> you a patch to try.
>
> On Tue, Jun 25, 2024 at 8:44 PM Andre Heinemans
> mailto:andre.heinem...@nxp.com>>
> wrote:
>
> > Hi,
> >
> > I am searching for a solution to share a disk or directory on a
> > Linux
> host
> > and make it accessible in NuttX through RPMsg. It looks like
> > CONFIG_FS_RPMSGFS is the feature I need. According to this NuttX
> > channel video
> > (https://www.youtube.com/watch?v=-YLAQlJR1vA)  various RPMsg services in 
> > Nuttx are supported in Linux including RPMsg FS.
> >
> > So, I tried setting this up but couldn’t find the correct linux
> > module that is able to interact with this service.
> >
> > When I try to mount a directory with
> > nsh> mount -t rpmsgfs -o cpu=netcore,fs=/mnt /mnt
> >
> > Some interaction happens. See linux dmesg log:
> > [   61.086471] virtio_rpmsg_bus virtio0: creating channel
> > rpmsgfs-0x2000c1c8 addr 0x401
> >
> > But it seems no linux driver is listening to that channel. When I
> > try to access the mounted directory in NuttX then nsh freezes.
> >
> > What do I need to do on Linux to support this service? Do I maybe
> > need a patch or a different fork?
> >
> > Kind regards,
> > Andre
> >
>
#/**本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
 This e-mail and its attachments contain confidential information from XIAOMI, 
which is intended only for the person or entity whose address is listed above. 
Any use of the information contained herein in any way (including, but not 
limited to, total or partial disclosure, reproduction, or dissemination) by 
persons other than the intended recipient(s) is prohibited. If you receive this 
e-mail in error, please notify the sender by phone or email immediately and 
delete it!**/#