linux-kernel - Re: remoteproc: Load coprocessor code to the specific main memory location

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]

Date:	Fri, 27 Jan 2012 11:06:19 +0100
From:	Michal Simek <monstr@...str.eu>
To:	LKML <linux-kernel@...r.kernel.org>
CC:	Ohad Ben-Cohen <ohad@...ery.com>,
	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 Wed, Jan 25, 2012 at 4:19 PM, Michal Simek <monstr@...str.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?

Just follow up. I have find out that moving to 0x10000000 offset will be problematic
because there must be vector table at 0x0. IIUC Linux remaps reset vectors to 0xffff0000 offset
through cp15 reg in bootup code.

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/