linux-kernel - Re: [PATCH 1/7] remoteproc: resource table overhaul

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: <4F66DB3D.4010407@monstr.eu>
Date:	Mon, 19 Mar 2012 08:07:41 +0100
From:	Michal Simek <monstr@...str.eu>
To:	Ohad Ben-Cohen <ohad@...ery.com>
CC:	linux-omap@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	Brian Swetland <swetland@...gle.com>,
	Iliyan Malchev <malchev@...gle.com>,
	Arnd Bergmann <arnd@...db.de>,
	Grant Likely <grant.likely@...retlab.ca>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Mark Grosen <mgrosen@...com>,
	John Williams <john.williams@...alogix.com>,
	Loic PALLARDY <loic.pallardy@...ricsson.com>,
	Ludovic BARRE <ludovic.barre@...ricsson.com>,
	Omar Ramirez Luna <omar.luna@...aro.org>,
	Guzman Lugo Fernando <fernando.lugo@...com>,
	Anna Suman <s-anna@...com>, Clark Rob <rob@...com>,
	Stephen Boyd <sboyd@...eaurora.org>,
	Saravana Kannan <skannan@...eaurora.org>,
	David Brown <davidb@...eaurora.org>,
	Kieran Bingham <kieranbingham@...il.com>,
	Tony Lindgren <tony@...mide.com>
Subject: Re: [PATCH 1/7] remoteproc: resource table overhaul

Hi Ohad,

> On Fri, Mar 16, 2012 at 4:57 PM, Michal Simek <monstr@...str.eu> wrote:
>> In previous version I had carverout first which means that code was copyied
>> to physical address 0x0 and then vrigns were allocated. Current code
>> allocate vring first and then RTOS is not able to run from zero address.
> 
> In general, depending on specific allocation ordering is error prone
> and you shouldn't do it.

Yes, I agree with you. It was in v1.


> For a given device, we treat memory allocated with
> dma_alloc_coherent() as homogeneous. We care about its utilization and
> alignments of allocations rather than their specific location in the
> total region.

For zynq platform is very important to use addresses from 0 for rtos.
The main reason why it is so important is ARM reset vectors.


> If that's not the case, and there's special memory you want assigned
> with a specific purpose, than it's recommended to let the code make
> sure it happens explicitly, and not rely on implicit order of
> allocation.

Sure.


> Today there's no way to assign several memory regions with a specific
> device, but a reasonable workaround that's being used is creating
> several sub-devices with the special memory, and then looking them up
> with stuff like device_for_each_child() or device_find_child().
> 
> About your specific issue: the current allocation scheme was chosen
> for simplicity, but I do plan to change it back by postponing the
> vring dma allocation until a remote processor is really powered on.
> It's not a lot of memory, but this way we'd only allocate it when
> really needed (so if it's CMA, others could use it).
> 
> IOW: you can probably just wait a bit until this patch is ready and
> take it into your tree. It will most likely bring back the behavior you
> need :)

OK. I will use v1 where allocation is based on order in resource table.
It is not ideal but it is working.

 From my point of view will be the best to call dma_alloc_coherent only once
which will allocate the whole chunk of memory which is required for "RTOS".

My resource table is easy:
#define TEXT_BASE 0
struct resource_table __resource resources = {
	1, /* we're the first version that implements this */
	3, /* number of entries in the table */
	0, 0, /* reserved, must be zero */
	/* offsets to entries */
	{
			offsetof(struct resource_table, text_cout),
			offsetof(struct resource_table, rpmsg_vdev),
			offsetof(struct resource_table, trace),
	},
	{
		TYPE_CARVEOUT, 0, 0, SZ_1M, 0, 0, "MEM_DATA",
	},
	{
		TYPE_VDEV, VIRTIO_ID_RPMSG, 0,
		RPMSG_IPU_C0_FEATURES, 0, 0, 0, 2, { 0, 0 },
		/* no config data */
	},

	/* the two vrings */
	{ TEXT_BASE + SZ_1M, 4096, 256, 1, 0 },
	{ TEXT_BASE + SZ_1M + 0x4000, 4096, 256, 2, 0 },

	{
		TYPE_TRACE, TEXT_BASE + 0x40000, 0x8000, 0, "trace",
	},

};

But as you see I need to keep that offset structure which is
that text/data starts at address 0, vrings0 on 0x100000, vrigns1 on 0x104000
and trace buffer 0x140000.

If dma_alloc_coherent is called just once with size taken from resource table.
(For my case for example 2MB=0x200000) and offset are driven by remoteproc then
it should just work.


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/