lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4F3D032B.6090700@monstr.eu>
Date:	Thu, 16 Feb 2012 14:22:51 +0100
From:	Michal Simek <monstr@...str.eu>
To:	monstr@...str.eu
CC:	Ohad Ben-Cohen <ohad@...ery.com>,
	LKML <linux-kernel@...r.kernel.org>,
	John Williams <john.williams@...alogix.com>,
	linux-arm <linux-arm-kernel@...ts.infradead.org>,
	"Grosen, Mark" <mgrosen@...com>, Arnd Bergmann <arnd@...db.de>,
	Grant Likely <grant.likely@...retlab.ca>,
	devicetree-discuss@...ts.ozlabs.org
Subject: Re: remoteproc: Load coprocessor code to the specific main memory
 location

Michal Simek wrote:
> Ohad Ben-Cohen wrote:
>> On Thu, Feb 16, 2012 at 10:12 AM, Michal Simek <monstr@...str.eu> wrote:
>>> I should be more specific. Can you point me to remoteproc code which 
>>> publish
>>> remote service based on them Linux rpmsg driver will be probed? It is 
>>> rtos
>>> part of code.
>>> In your ELCE presentation is called rpmsg-client-sample service.
>>
>> Sorry for the late response (I'm in ELC).
>>
>> Yes, use the client sample (which is part of the submitted patch set)
>> and not the omx/server samples (which are public, but were never
>> submitted nor cleaned up).
> 
> Client sample is clear because it is probed when services are published.
> 
>>
>> The channels are created dynamically: the rpmsg bus designates address
>> 53 for a name service, which listens to channel creation/removal
>> announcements coming from the remote processor. Take a look in
>> virtio_rpmsg_bus.c and you'll immediately see it.
> 
> I see that values but I can't see how rtos should send that messages.
> 
> Have checked both vrings - one for rx and one for tx. They are
> initialized correctly on addresses I like.
> 
> (gdb) x /80x 0xe1100000
> 0xe1100000:     0x31140000      0x00000000      0x00000200      0x00010002
> 0xe1100010:     0x31140200      0x00000000      0x00000200      0x00020002
> 0xe1100020:     0x31140400      0x00000000      0x00000200      0x00030002
> 0xe1100030:     0x31140600      0x00000000      0x00000200      0x00040002
> 0xe1100040:     0x31140800      0x00000000      0x00000200      0x00050002
> 
> (gdb) x /80x 0xe1104000
> 0xe1104000:     0x00000000      0x00000000      0x00000000      0x00010000
> 0xe1104010:     0x00000000      0x00000000      0x00000000      0x00020000
> 0xe1104020:     0x00000000      0x00000000      0x00000000      0x00030000
> 0xe1104030:     0x00000000      0x00000000      0x00000000      0x00040000
> 0xe1104040:     0x00000000      0x00000000      0x00000000      0x00050000
> 0xe1104050:     0x00000000      0x00000000      0x00000000      0x00060000
> 0xe1104060:     0x00000000      0x00000000      0x00000000      0x00070000
> 
> 
> 
> rtos can handle kick from Linux
> Linux is able to catch kick from freertos and run rproc_vg_interrupt
> 
>  From code I see that in rpmsg_probe function is virtqueue_kick which 
> means sending
> kick to rtos. Then rtos can send the message.
> 
> 
> Above is condition "if (virtio_has_feature(vdev, VIRTIO_RPMSG_F_NS))" 
> which is failing for me.
> Not sure if is correct.
> 
> I am still not sure how to propagate that messages from rtos side.
> In TI software it is in NameMap.c file which calls MessageQCopy_send 
> function with address 53(which fits).
> If I look at that function you copy data to msg->payload, setup data 
> length, dstAddr is 53, srcAddr is don't know yet,
> flag is 0, reserverd is 0 then you call VirtQueue_addUsedBuf and kick.
> 
> How does look like that structure for vring channels? It is probably 
> mapped any structure. Can you point me which one?
> Channel description is rpmsg_channel_info struct.

ok on that addresses above is mapped vring_desc structure. I expect that
addr is address to any memory location when data are places. Next is filled
by init because of ring buffer. What flags should be used? And what is data structure?

struct vring_desc {
	/* Address (guest-physical). */
	__u64 addr;
	/* Length. */
	__u32 len;
	/* The flags as indicated above. */
	__u16 flags;
	/* We chain unused descriptors via this, too */
	__u16 next;
};

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ