From: monstr@monstr.eu (Michal Simek)
To: linux-arm-kernel@lists.infradead.org
Subject: remoteproc: Load coprocessor code to the specific main memory location
Date: Thu, 26 Jan 2012 11:44:46 +0100 [thread overview]
Message-ID: <4F212E9E.9060807@monstr.eu> (raw)
In-Reply-To: <CAK=WgbZDADRf1OF=uWbbsF+t2dx36tqj=kRftn5nd4RA7DtEnA@mail.gmail.com>
Ohad Ben-Cohen wrote:
> On Wed, Jan 25, 2012 at 4:19 PM, Michal Simek <monstr@monstr.eu> wrote:
>> I started with pur vanilla kernel and patches from your tree
>> git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git
>> for-next branch
>> but then I had to moved to for-next-acked-merged because in the origin
>> one were some problems.
>
> Unlike for-next-acked-merged, the other branches aren't rebased and
> therefore have merge conflicts with 3.3 material; that's intentional.
>
>> Do you have any kernel tree with CMA just for sure?
>
> Not a 3.3-based one, so I recommend you to just merge Marek's branch directly.
>
> I'll soon create a full-fledged 3.3 branch though, so you may want to
> wait a bit until I get to it.
I have done it and tested. It works as expected. Thanks.
I have created region at phys addr 0x10000000 with selected size.
I had to move carveout in resource table to be first in this area.
Also removed that copying from kick function.
I have one small problem which is that physical address is 0x10000000
which means that firmware entry point is the same.
In rproc_load_segments is da composed from phdr->p_paddr which is 0x10000000.
And code is designed that this load addr is offset.
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.
I have created temporary fix which substract virtual address to get correct da.
u32 da = phdr->p_paddr - phdr->p_vaddr;
What should be correct solution?
>
>> What do you use for firmware replacing?
>> Just remove kernel module and load different one?
>
> If your driver boots the remote core on its ->probe() handler, then
> yes, you need to unbind and bind the device.
>
> One way is to unload and load the driver, but you can also use the
> bind/unbind sysfs files of your driver (echo -n device-name >
> /sys/..../{un}bind).
ok. It also works.
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
WARNING: multiple messages have this Message-ID (diff)
From: Michal Simek <monstr@monstr.eu>
To: Ohad Ben-Cohen <ohad@wizery.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
John Williams <john.williams@petalogix.com>,
linux-arm <linux-arm-kernel@lists.infradead.org>,
"Grosen, Mark" <mgrosen@ti.com>, Arnd Bergmann <arnd@arndb.de>,
Grant Likely <grant.likely@secretlab.ca>,
devicetree-discuss@lists.ozlabs.org
Subject: Re: remoteproc: Load coprocessor code to the specific main memory location
Date: Thu, 26 Jan 2012 11:44:46 +0100 [thread overview]
Message-ID: <4F212E9E.9060807@monstr.eu> (raw)
In-Reply-To: <CAK=WgbZDADRf1OF=uWbbsF+t2dx36tqj=kRftn5nd4RA7DtEnA@mail.gmail.com>
Ohad Ben-Cohen wrote:
> On Wed, Jan 25, 2012 at 4:19 PM, Michal Simek <monstr@monstr.eu> wrote:
>> I started with pur vanilla kernel and patches from your tree
>> git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git
>> for-next branch
>> but then I had to moved to for-next-acked-merged because in the origin
>> one were some problems.
>
> Unlike for-next-acked-merged, the other branches aren't rebased and
> therefore have merge conflicts with 3.3 material; that's intentional.
>
>> Do you have any kernel tree with CMA just for sure?
>
> Not a 3.3-based one, so I recommend you to just merge Marek's branch directly.
>
> I'll soon create a full-fledged 3.3 branch though, so you may want to
> wait a bit until I get to it.
I have done it and tested. It works as expected. Thanks.
I have created region at phys addr 0x10000000 with selected size.
I had to move carveout in resource table to be first in this area.
Also removed that copying from kick function.
I have one small problem which is that physical address is 0x10000000
which means that firmware entry point is the same.
In rproc_load_segments is da composed from phdr->p_paddr which is 0x10000000.
And code is designed that this load addr is offset.
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.
I have created temporary fix which substract virtual address to get correct da.
u32 da = phdr->p_paddr - phdr->p_vaddr;
What should be correct solution?
>
>> What do you use for firmware replacing?
>> Just remove kernel module and load different one?
>
> If your driver boots the remote core on its ->probe() handler, then
> yes, you need to unbind and bind the device.
>
> One way is to unload and load the driver, but you can also use the
> bind/unbind sysfs files of your driver (echo -n device-name >
> /sys/..../{un}bind).
ok. It also works.
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
next prev parent reply other threads:[~2012-01-26 10:44 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-24 17:20 remoteproc: Load coprocessor code to the specific main memory location Michal Simek
2012-01-25 11:42 ` Ohad Ben-Cohen
2012-01-25 11:42 ` Ohad Ben-Cohen
2012-01-25 12:41 ` Michal Simek
2012-01-25 12:41 ` Michal Simek
2012-01-25 13:45 ` Ohad Ben-Cohen
2012-01-25 13:45 ` Ohad Ben-Cohen
2012-01-25 14:19 ` Michal Simek
2012-01-25 14:19 ` Michal Simek
2012-01-25 16:24 ` Ohad Ben-Cohen
2012-01-25 16:24 ` Ohad Ben-Cohen
2012-01-25 16:24 ` Ohad Ben-Cohen
2012-01-26 10:44 ` Michal Simek [this message]
2012-01-26 10:44 ` Michal Simek
2012-01-27 10:06 ` Michal Simek
2012-01-27 10:06 ` Michal Simek
2012-01-27 10:06 ` Michal Simek
2012-01-27 11:38 ` Ohad Ben-Cohen
2012-01-27 11:38 ` Ohad Ben-Cohen
2012-01-27 11:38 ` Ohad Ben-Cohen
2012-02-13 14:20 ` Michal Simek
2012-02-13 14:20 ` Michal Simek
2012-02-14 16:28 ` Ohad Ben-Cohen
2012-02-14 16:28 ` Ohad Ben-Cohen
2012-02-15 12:47 ` Michal Simek
2012-02-15 12:47 ` Michal Simek
2012-02-15 14:36 ` Michal Simek
2012-02-15 14:36 ` Michal Simek
2012-02-15 14:36 ` Michal Simek
2012-02-16 9:12 ` Michal Simek
2012-02-16 9:12 ` Michal Simek
2012-02-16 9:12 ` Michal Simek
2012-02-16 11:28 ` Ohad Ben-Cohen
2012-02-16 11:28 ` Ohad Ben-Cohen
2012-02-16 13:07 ` Michal Simek
2012-02-16 13:07 ` Michal Simek
2012-02-16 13:07 ` Michal Simek
2012-02-16 13:22 ` Michal Simek
2012-02-16 13:22 ` Michal Simek
2012-02-16 17:34 ` Ohad Ben-Cohen
2012-02-16 17:34 ` Ohad Ben-Cohen
[not found] ` <CAK=WgbZ3oXc+NQscdShqmu2wkzv=M-qBDCH2-k=5qSRX9W=z3Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-02-16 20:21 ` Michal Simek
2012-02-17 1:55 ` Ohad Ben-Cohen
2012-02-17 1:55 ` Ohad Ben-Cohen
2012-02-20 14:22 ` Michal Simek
2012-02-20 14:22 ` Michal Simek
2012-02-20 14:22 ` Michal Simek
2012-02-20 20:11 ` Ohad Ben-Cohen
2012-02-20 20:11 ` Ohad Ben-Cohen
2012-02-22 12:10 ` Michal Simek
2012-02-22 12:10 ` Michal Simek
2012-02-22 12:10 ` Michal Simek
2012-02-22 12:59 ` Ohad Ben-Cohen
2012-02-22 12:59 ` Ohad Ben-Cohen
2012-03-06 15:22 ` Michal Simek
2012-03-06 15:22 ` Michal Simek
2012-03-06 15:22 ` Michal Simek
2012-03-06 16:26 ` Ohad Ben-Cohen
2012-03-06 16:26 ` Ohad Ben-Cohen
2012-02-16 17:27 ` Ohad Ben-Cohen
2012-02-16 17:27 ` Ohad Ben-Cohen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F212E9E.9060807@monstr.eu \
--to=monstr@monstr.eu \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.