[meta-xilinx] remoteproc resource table TYPE_MMU entries

[Magnus Olsson]

Hi,


If you exclude peripherals from the devicetree, Linux will conclude that said peripheral is not in use. Since no driver will be loaded, it should not access the peripheral memory but I doubt the MMU will be setup to forcefully prohibit it. This means that if you have a rogue module in your kernel, you can probably still screw up the baremetal app. I suppose you could have the Linux-side do the inverse-setup of RSC_MMU-entries in the resource-table, but unless you have a lot of custom kernel code I don't think you need to.

Keep in mind: If you disable peripherals from the Devicetree, Linux will think it's unused. Therefore it will most likely turn off any clocks to it. I've seen this happen when I dedicate UART1 for CPU1 and removed it from the Linux deviectree. It is problematic since clocks are controlled from a single IP block, which means that unless either Linux or your app owns it, both will need to access it. I solved it by letting Linux own the clocks (e.g UART1 is still in my devicetree, but I never open /dev/ttyPS1).



> -----Original Message-----
> From: Edward Wingate [mailto:edwingate8 at gmail.com]
> Sent: den 15 oktober 2015 09:01
> To: Magnus Olsson
> Cc: meta-xilinx at lists.yoctoproject.org
> Subject: Re: [meta-xilinx] remoteproc resource table TYPE_MMU entries
> 
> On Wed, Oct 14, 2015 at 11:53 PM, Magnus Olsson <Mago at hms.se> wrote:
> > It is the responsibility of the remoteproc app to iterate through its own
> resource table, and for
> > each RSC_MMU entry, configure the MMU of CPU #1 accordingly. It is
> recommended that you
> > lock down the address space in such way that the application cannot access
> peripherals other
> > than those explicitly unlocked by RSC_MMU. This will provide a type of
> safety-net for the entire
> > system, and to some degree ensure mutual exclusion for peripherals
> between Linux and your
> > app.
> 
> Magnus, Thanks for the clear explanation.  In my case, most
> peripherals will actually be used by the remote processor (CPU1).  Is
> it possible to do the equivalent lockdown for Linux on CPU0?  Would
> simply excluding the peripheral from the DTB or declaring it "invalid"
> do the trick?