[meta-xilinx] remoteproc resource table TYPE_MMU entries

[Wendy Liang]

Hi,

About the clocking issue, you can also try passing clk_ignore_unused boot arg to kernel

> -----Original Message-----
> From: meta-xilinx-bounces at yoctoproject.org [mailto:meta-xilinx-
> bounces at yoctoproject.org] On Behalf Of Magnus Olsson
> Sent: Thursday, October 15, 2015 5:17 PM
> To: Edward Wingate <edwingate8 at gmail.com>
> Cc: meta-xilinx at lists.yoctoproject.org
> Subject: Re: [meta-xilinx] remoteproc resource table TYPE_MMU entries
>
> 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?
> --
> _______________________________________________
> meta-xilinx mailing list
> meta-xilinx at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-xilinx


This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.