Hi Ohad,
Ohad Ben-Cohen wrote:
> On Thu, Jan 26, 2012 at 12:44 PM, Michal Simek <[email protected]> wrote:
>> I have one small problem which is that physical address is 0x10000000
>> which means that firmware entry point is the same.
>
> This is what we do with the davinci DSPs, too.
>
>> In rproc_load_segments is da composed from phdr->p_paddr which is
>> 0x10000000.
>
> Ok, I don't see any issue here.
>
>> And code is designed that this load addr is offset.
>
> Not sure exactly what do you mean by that ?
>
>> Here is the code:
>> /* go through the available ELF segments */
>> for (i = 0; i < ehdr->e_phnum; i++, phdr++) {
>> u32 da = phdr->p_paddr; // OFFSET 0x10000000
>> u32 memsz = phdr->p_memsz;
>>
>> But for my case is physical address correct and it is not offset 0x10000000.
>
> Again, I'm not sure what exactly is the issue. p_paddr is the physical
> address where the image is expected, that sounds ok to me.
sorry for delay. I was working on different issue.
I have solved this issue by using ram address ranges 0x0 - 0x10000000.
I am using CONFIG_PHYS_OFFSET=0x10000000 in linux which give me free space for rtos.
Here is how it is achieve
ret = dma_declare_coherent_memory(&zynq_freertos.dev, 0,
0, 0x10000000, DMA_MEMORY_MAP);
which is fully compatible with remoteproc.
I have also got trace buffer to work - there were problem with caches on cpu with rtos.
I still have the problem to reset cpu1 but we are investigating how to do so. Maybe in future
we will add new message which jumps back to bootloader code if not possible to do it throuth any
I have looked at omap remoteproc and there is communication between cocpu through omap mbox
and IRQs. I am working on similar communication for testing
and I would like to know how vrings fit to this. Do you have any example of using it?
struct resource __resource resources[] = {
{ TYPE_CARVEOUT, 0, TEXT_BASE + 0, 0, 0, 0, SZ_1M, 0, 0,0,0,0,"IPU_MEM_TEXT"},
{ TYPE_VIRTIO_DEV,0, TEXT_BASE + 0, 0, 0, 0, SZ_1M, VIRTIO_ID_RPMSG,0,0,0,0,"vdev:rpmsg"},
{ TYPE_VRING, 0, TEXT_BASE + 0x20000, 0, 0, 0, VQ0_SIZE,0,0,0,0,0,"vring:sysm3->mpu"},
{ TYPE_VRING, 1, TEXT_BASE + 0x30000, 0, 0, 0, VQ1_SIZE,0,0,0,0,0,"vring:mpu->sysm3"},
{ TYPE_TRACE, 0, TEXT_BASE + 0x40000, 0, 0, 0, 0x8000, 0,0,0,0,0,"trace:sysm3"},
};
Below is my full bootup log.
Thanks,
Michal
Linux version 3.3.0-rc1+ ([email protected]) (gcc version 4.5.1 (Sourcery G++ Lite 2010.09-62) ) #355 PREEMPT Mon Feb 13 15:10:48 CET 2012
CPU: ARMv7 Processor [410fc090] revision 0 (ARMv7), cr=10c5387d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: Xilinx Zynq Platform, model: ZC702_jason
bootconsole [earlycon0] enabled
vmalloc_min ef800000, PAGE_OFFSET c0000000
Ignoring RAM at 00000000-0fffffff (vmalloc region overlap).
vmalloc_min ef800000, PAGE_OFFSET c0000000
dma_contiguous_reserve(limit 20000000)
dma_contiguous_reserve: total available: 256 MiB, size absolute: 1 MiB, size percentage: 0 MiB
dma_contiguous_reserve: reserving 1 MiB for global area
dma_declare_contiguous(size 100000, base 00000000, limit 20000000)
cma: CMA: reserved 8 MiB at 1f800000
Memory policy: ECC disabled, Data cache writeback
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024
Kernel command line: console=ttyPS0,115200 earlyprintk
PID hash table entries: 1024 (order: 0, 4096 bytes)
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 256MB = 256MB total
Memory: 243984k/243984k available, 18160k reserved, 0K highmem
Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
vmalloc : 0xd0800000 - 0xff000000 ( 744 MB)
lowmem : 0xc0000000 - 0xd0000000 ( 256 MB)
modules : 0xbf000000 - 0xc0000000 ( 16 MB)
.text : 0xc0008000 - 0xc0283000 (2540 kB)
.init : 0xc0283000 - 0xc0753000 (4928 kB)
.data : 0xc0754000 - 0xc076c0c0 ( 97 kB)
.bss : 0xc076c0e4 - 0xc07774c0 ( 45 kB)
NR_IRQS:246
xlnx,ps7-ttc-1.00.a #0 at 0xd0800000, irq=43
Calibrating delay loop... 2531.32 BogoMIPS (lpj=12656640)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
hw perfevents: enabled with ARMv7 Cortex-A9 PMU driver, 1 counters available
Setting up static identity map for 0x101cc918 - 0x101cc94c
devtmpfs: initialized
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
L2x0 series cache controller enabled
l2x0: 8 ways, CACHE_ID 0x00000000, AUX_CTRL 0x02060000, Cache size: 524288 B
hw-breakpoint: debug architecture 0x0 unsupported.
Switching to clocksource xttcpss_timer1
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP reno registered
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
msgmni has been set to 492
e0001000.serial: ttyPS0 at MMIO 0xe0001000 (irq = 82) is a xuartps
console [ttyPS0] enabled, bootconsole disabled
console [ttyPS0] enabled, bootconsole disabled
GEM: BASEADDRESS hw: e000b000 virt: d0806000
XEMACPS mii bus: probed
GEM: phydev ceaf7800, phydev->phy_id 0x1410cc2, phydev->addr 0x7
GEM: MAC addr 00:b0:00:e0:ff:bf
eth0, pdev->id -1, baseaddr 0xe000b000, irq 54
eth0, phy_addr 0x7, phy_id 0x01410cc2
eth0, attach [Generic PHY] phy driver
zynq-rproc zynq-rproc.1: zynq_rproc_probe
zynq-rproc zynq-rproc.1: cpu1_freertos is available
zynq-rproc zynq-rproc.1: Note: remoteproc is still under development and considered experimental.
zynq-rproc zynq-rproc.1: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.
rpmsg_init
rpmsg_probe
zynq-rproc zynq-rproc.1: powering up cpu1_freertos, firmware test
zynq-rproc zynq-rproc.1: Booting fw image test, size 203250
zynq-rproc zynq-rproc.1: iommu not found
zynq-rproc zynq-rproc.1: rsc: type 0, da 0x0, pa 0x0, len 0x100000, id 0, name IPU_MEM_TEXT, flags 0
zynq-rproc zynq-rproc.1: rsc: type 4, da 0x0, pa 0x0, len 0x100000, id 0, name vdev:rpmsg, flags 7
zynq-rproc zynq-rproc.1: rsc: type 3, da 0x20000, pa 0x0, len 0x100, id 0, name vring:sysm3->mpu, flags 0
zynq-rproc zynq-rproc.1: rsc: type 3, da 0x30000, pa 0x0, len 0x100, id 1, name vring:mpu->sysm3, flags 0
zynq-rproc zynq-rproc.1: rsc: type 2, da 0x40000, pa 0x0, len 0x8000, id 0, name trace:sysm3, flags 0
zynq-rproc zynq-rproc.1: phdr: type 1 da 0x0 memsz 0x1be80 filesz 0x1509c
zynq-rproc zynq-rproc.1: zynq_rproc_start
zynq-rproc zynq-rproc.1: zynq_device_enable Enable device - it means jump
zynq-rproc zynq-rproc.1: remote processor cpu1_freertos is now up
zynq-rproc zynq-rproc.1: zynq_rproc_kick vqid 0
zynq_mbox_msg_send 1
virtio_rpmsg_bus virtio0: rpmsg host is online
TCP cubic registered
NET: Registered protocol family 10
IPv6 over IPv4 tunneling driver
NET: Registered protocol family 17
NET: Registered protocol family 40
VFP support v0.3: implementor 41 architecture 3 part 40 variant 0 rev 0
Registering SWP/SWPB emulation handler
Freeing init memory: 4928K
Mounting proc:
Mounting var:
Populating /var:
Running local start scripts.
Mounting debugfs:
Mounting sysfs:
mdev: initialising /dev
mdev: Registering hotplug handler
/proc/mtd doesn't exist. Will not create /dev/flash/* device nodes
Mounting devpts:
Setting hostname:
Bringing up network interfaces:
GEM: lp->tx_bd cf841000 lp->tx_bd_dma 1f841000 lp->tx_skb ceb3bbc0
GEM: lp->rx_bd cf840000 lp->rx_bd_dma 1f840000 lp->rx_skb ceb3bac0
GEM: MAC 0xe000b000, 0x0000bfff, 00:b0:00:e0:ff:bf
Starting portmap:
Welcome to
_____ _ _ _
| ___ \ | | | | (_)
| |_/ / ___ | |_ __ _ | | _ _ __ _ _ __ __
| __/ / _ \| __| / _` || | | || '_ \ | | | |\ \/ /
| | | __/| |_ | (_| || |____| || | | || |_| | > <
\_| \___| \__| \__,_|\_____/|_||_| |_| \__,_|/_/\_\
on zynq-silicon
zynq-silicon login: root
Password:
--
Michal Simek, Ing. (M.Eng)
w: http://www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
On Mon, Feb 13, 2012 at 3:20 PM, Michal Simek <[email protected]> wrote:
> Here is how it is achieve
> ? ? ? ?ret = dma_declare_coherent_memory(&zynq_freertos.dev, 0,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0, 0x10000000, DMA_MEMORY_MAP);
>
> which is fully compatible with remoteproc.
Great, this is what we've been doing with davinci too.
> Do you have any example of using it?
What exactly are you looking for ? RTOS or Linux side ?
On the Linux side, you can just make the rpmsg sample work (it's part
of the rpmsg patch set). For the RTOS side, feel free to just take our
code (it's BSD licensed and hosted on github) and adapt it to your
environment.
Ohad.
Ohad Ben-Cohen wrote:
> On Mon, Feb 13, 2012 at 3:20 PM, Michal Simek <[email protected]> wrote:
>> Here is how it is achieve
>> ret = dma_declare_coherent_memory(&zynq_freertos.dev, 0,
>> 0, 0x10000000, DMA_MEMORY_MAP);
>>
>> which is fully compatible with remoteproc.
>
> Great, this is what we've been doing with davinci too.
Cool.
>
>> Do you have any example of using it?
>
> What exactly are you looking for ? RTOS or Linux side ?
Both side will be great. Rtos is freertos.
>
> On the Linux side, you can just make the rpmsg sample work (it's part
> of the rpmsg patch set). For the RTOS side, feel free to just take our
> code (it's BSD licensed and hosted on github) and adapt it to your
> environment.
You mean that server_sample and rpmsg_omx right?
I have also found rpmsg-omx demo application.
What I am missing is how to probe rpmsg bus.
Do you have any working example?
Communication between cpus is done through swirqs. I have test sending it from linux to rtos.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng)
w: http://www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
Michal Simek wrote:
> Ohad Ben-Cohen wrote:
>> On Mon, Feb 13, 2012 at 3:20 PM, Michal Simek <[email protected]> wrote:
>>> Here is how it is achieve
>>> ret = dma_declare_coherent_memory(&zynq_freertos.dev, 0,
>>> 0, 0x10000000, DMA_MEMORY_MAP);
>>>
>>> which is fully compatible with remoteproc.
>>
>> Great, this is what we've been doing with davinci too.
>
> Cool.
>
>>
>>> Do you have any example of using it?
>>
>> What exactly are you looking for ? RTOS or Linux side ?
>
> Both side will be great. Rtos is freertos.
>
>>
>> On the Linux side, you can just make the rpmsg sample work (it's part
>> of the rpmsg patch set). For the RTOS side, feel free to just take our
>> code (it's BSD licensed and hosted on github) and adapt it to your
>> environment.
>
> You mean that server_sample and rpmsg_omx right?
> I have also found rpmsg-omx demo application.
> What I am missing is how to probe rpmsg bus.
> Do you have any working example?
>
> Communication between cpus is done through swirqs. I have test sending
> it from linux to rtos.
ok. How that rpmsg channels are created? Is it based on data sent from remoteproc?
Or based on resource table?
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng)
w: http://www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
Michal Simek wrote:
> Michal Simek wrote:
>> Ohad Ben-Cohen wrote:
>>> On Mon, Feb 13, 2012 at 3:20 PM, Michal Simek <[email protected]> wrote:
>>>> Here is how it is achieve
>>>> ret = dma_declare_coherent_memory(&zynq_freertos.dev, 0,
>>>> 0, 0x10000000, DMA_MEMORY_MAP);
>>>>
>>>> which is fully compatible with remoteproc.
>>>
>>> Great, this is what we've been doing with davinci too.
>>
>> Cool.
>>
>>>
>>>> Do you have any example of using it?
>>>
>>> What exactly are you looking for ? RTOS or Linux side ?
>>
>> Both side will be great. Rtos is freertos.
>>
>>>
>>> On the Linux side, you can just make the rpmsg sample work (it's part
>>> of the rpmsg patch set). For the RTOS side, feel free to just take our
>>> code (it's BSD licensed and hosted on github) and adapt it to your
>>> environment.
>>
>> You mean that server_sample and rpmsg_omx right?
>> I have also found rpmsg-omx demo application.
>> What I am missing is how to probe rpmsg bus.
>> Do you have any working example?
>>
>> Communication between cpus is done through swirqs. I have test sending
>> it from linux to rtos.
>
> ok. How that rpmsg channels are created? Is it based on data sent from
> remoteproc?
> Or based on resource table?
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.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng)
w: http://www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
On Thu, Feb 16, 2012 at 10:12 AM, Michal Simek <[email protected]> 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).
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.
Hope this helps,
Ohad.
Ohad Ben-Cohen wrote:
> On Thu, Feb 16, 2012 at 10:12 AM, Michal Simek <[email protected]> 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.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng)
w: http://www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
Michal Simek wrote:
> Ohad Ben-Cohen wrote:
>> On Thu, Feb 16, 2012 at 10:12 AM, Michal Simek <[email protected]> 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: http://www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
On Thu, Feb 16, 2012 at 2:07 PM, Michal Simek <[email protected]> wrote:
> Above is condition "if (virtio_has_feature(vdev, VIRTIO_RPMSG_F_NS))" which
> is failing for me.
You might want to debug why.
For the dynamic channel creation to work, your rpmsg vdev should have
VIRTIO_RPMSG_F_NS. But that's part of the generic code, and you should
not bother about it - it should just work.
> How does look like that structure for vring channels? It is probably mapped
> any structure. Can you point me which one?
I'm sorry, can you please rephrase the question ? I'm not sure I'm following.
Thanks,
Ohad.
On Thu, Feb 16, 2012 at 2:22 PM, Michal Simek <[email protected]> wrote:
> 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?
I'm sorry, but can you please rephrase this question too ? I'm just not
sure I understand you correctly.
In general, you don't need to fiddle with the vring_desc structure -
that's internal to virtio, and things should just work.
Or are you asking about the rtos side ?
Thanks,
Ohad.