On 06/10/2013 03:14 AM, Russell King - ARM Linux wrote:
> On Mon, Jun 10, 2013 at 05:11:15PM +0900, Alexandre Courbot wrote:
>> On Sat, Jun 8, 2013 at 1:33 AM, Stephen Warren wrote:
> I think we need to separate the concept of support for *a* secure
> monitor, from support for a
On Mon, Jun 10, 2013 at 05:05:04PM +0900, Alexandre Courbot wrote:
> On Sat, Jun 8, 2013 at 3:13 AM, Dave Martin wrote:
> > One way to make the backend generic would be to have something like
> > one of the following (some syntax omitted due to laziness):
> >
> > u32 __naked
On Mon, Jun 10, 2013 at 05:11:15PM +0900, Alexandre Courbot wrote:
> On Sat, Jun 8, 2013 at 1:33 AM, Stephen Warren wrote:
> >>> I think we need to separate the concept of support for *a* secure
> >>> monitor, from support for a *particular* secure monitor.
> >>
> >> Agreed. In this case, can we
On Mon, Jun 10, 2013 at 05:11:15PM +0900, Alexandre Courbot wrote:
> On Sat, Jun 8, 2013 at 1:33 AM, Stephen Warren wrote:
> >>> I think we need to separate the concept of support for *a* secure
> >>> monitor, from support for a *particular* secure monitor.
> >>
> >> Agreed. In this case, can we
On Mon, Jun 10, 2013 at 04:47:22PM +0900, Alexandre Courbot wrote:
> One could remove the naked attribute and put there registers into the
> clobber list, but then the function will be inlined and we will have
> to ensure the parameters end up in the right register (and having a
> function that
On Sat, Jun 8, 2013 at 1:33 AM, Stephen Warren wrote:
>>> I think we need to separate the concept of support for *a* secure
>>> monitor, from support for a *particular* secure monitor.
>>
>> Agreed. In this case, can we assume that support for a specific secure
>> monitor is not arch-specific,
On Sat, Jun 8, 2013 at 3:13 AM, Dave Martin wrote:
> One way to make the backend generic would be to have something like
> one of the following (some syntax omitted due to laziness):
>
> u32 __naked __call_smc(u32 r0, ...)
> {
> asm volatile (
>
On Sat, Jun 8, 2013 at 2:30 AM, Dave Martin wrote:
> Most likely it's either unnecessary, or insufficient.
>
> Just for entering call SMC properly, it's not needed. If the Secure
> World has its MMU on and maps Normal World memory using the same memory
> types as Linux, then the Normal World and
On Sat, Jun 8, 2013 at 2:30 AM, Dave Martin dave.mar...@arm.com wrote:
Most likely it's either unnecessary, or insufficient.
Just for entering call SMC properly, it's not needed. If the Secure
World has its MMU on and maps Normal World memory using the same memory
types as Linux, then the
On Sat, Jun 8, 2013 at 3:13 AM, Dave Martin dave.mar...@arm.com wrote:
One way to make the backend generic would be to have something like
one of the following (some syntax omitted due to laziness):
u32 __naked __call_smc(u32 r0, ...)
{
asm volatile (
On Sat, Jun 8, 2013 at 1:33 AM, Stephen Warren swar...@wwwdotorg.org wrote:
I think we need to separate the concept of support for *a* secure
monitor, from support for a *particular* secure monitor.
Agreed. In this case, can we assume that support for a specific secure
monitor is not
On Mon, Jun 10, 2013 at 04:47:22PM +0900, Alexandre Courbot wrote:
One could remove the naked attribute and put there registers into the
clobber list, but then the function will be inlined and we will have
to ensure the parameters end up in the right register (and having a
function that cannot
On Mon, Jun 10, 2013 at 05:11:15PM +0900, Alexandre Courbot wrote:
On Sat, Jun 8, 2013 at 1:33 AM, Stephen Warren swar...@wwwdotorg.org wrote:
I think we need to separate the concept of support for *a* secure
monitor, from support for a *particular* secure monitor.
Agreed. In this case,
On Mon, Jun 10, 2013 at 05:11:15PM +0900, Alexandre Courbot wrote:
On Sat, Jun 8, 2013 at 1:33 AM, Stephen Warren swar...@wwwdotorg.org wrote:
I think we need to separate the concept of support for *a* secure
monitor, from support for a *particular* secure monitor.
Agreed. In this case,
On Mon, Jun 10, 2013 at 05:05:04PM +0900, Alexandre Courbot wrote:
On Sat, Jun 8, 2013 at 3:13 AM, Dave Martin dave.mar...@arm.com wrote:
One way to make the backend generic would be to have something like
one of the following (some syntax omitted due to laziness):
u32 __naked
On 06/10/2013 03:14 AM, Russell King - ARM Linux wrote:
On Mon, Jun 10, 2013 at 05:11:15PM +0900, Alexandre Courbot wrote:
On Sat, Jun 8, 2013 at 1:33 AM, Stephen Warren swar...@wwwdotorg.org wrote:
I think we need to separate the concept of support for *a* secure
monitor, from support for a
On Fri, Jun 07, 2013 at 06:03:54PM +0900, Alexandre Courbot wrote:
> On Fri, Jun 7, 2013 at 3:08 AM, Dave Martin wrote:
> >> I think we need to separate the concept of support for *a* secure
> >> monitor, from support for a *particular* secure monitor.
> >
> > There is no fixed set of
On Thu, Jun 06, 2013 at 12:29:14PM -0600, Stephen Warren wrote:
> On 06/06/2013 12:08 PM, Dave Martin wrote:
> > On Thu, Jun 06, 2013 at 10:44:48AM -0600, Stephen Warren wrote:
> >> On 06/06/2013 01:28 AM, Alexandre Courbot wrote:
> >>> Boot loaders on some Tegra devices can be unlocked but do not
On Fri, Jun 07, 2013 at 04:25:07PM +0900, Alexandre Courbot wrote:
> On Thu, Jun 6, 2013 at 8:02 PM, Dave Martin wrote:
>
> >> +static int __attribute__((used)) __tegra_smc_stack[10];
> >
> > Use __used instead of using GCC attributes directly.
> >
> >> +
> >> +/*
> >> + * With EABI, subtype and
On 06/07/2013 02:11 AM, Alexandre Courbot wrote:
> On Fri, Jun 7, 2013 at 1:44 AM, Stephen Warren wrote:
>> On 06/06/2013 01:28 AM, Alexandre Courbot wrote:
>>> Boot loaders on some Tegra devices can be unlocked but do not let the
>>> system operate without SecureOS. SecureOS prevents access to
On Fri, Jun 7, 2013 at 3:08 AM, Dave Martin wrote:
>> I think we need to separate the concept of support for *a* secure
>> monitor, from support for a *particular* secure monitor.
>
> There is no fixed set of functionality implemented by these interfaces,
> so it might be better to think in terms
On Fri, Jun 7, 2013 at 12:43 PM, Alexandre Courbot wrote:
> On Thu, Jun 6, 2013 at 9:26 PM, Jassi Brar wrote:
>> On Thu, Jun 6, 2013 at 12:58 PM, Alexandre Courbot
>> wrote:
>>> Boot loaders on some Tegra devices can be unlocked but do not let the
>>> system operate without SecureOS. SecureOS
On Fri, Jun 7, 2013 at 1:44 AM, Stephen Warren wrote:
> On 06/06/2013 01:28 AM, Alexandre Courbot wrote:
>> Boot loaders on some Tegra devices can be unlocked but do not let the
>> system operate without SecureOS. SecureOS prevents access to some
>> registers and requires the operating system to
On Thu, Jun 6, 2013 at 8:02 PM, Dave Martin wrote:
>> +static int __attribute__((used)) __tegra_smc_stack[10];
>
> Use __used instead of using GCC attributes directly.
>
>> +
>> +/*
>> + * With EABI, subtype and arg already end up in r0, r1 and r2 as they are
>> + * function arguments, but we
On Thu, Jun 6, 2013 at 9:26 PM, Jassi Brar wrote:
> On Thu, Jun 6, 2013 at 12:58 PM, Alexandre Courbot
> wrote:
>> Boot loaders on some Tegra devices can be unlocked but do not let the
>> system operate without SecureOS. SecureOS prevents access to some
>> registers and requires the operating
On 06/07/2013 02:11 AM, Alexandre Courbot wrote:
On Fri, Jun 7, 2013 at 1:44 AM, Stephen Warren swar...@wwwdotorg.org wrote:
On 06/06/2013 01:28 AM, Alexandre Courbot wrote:
Boot loaders on some Tegra devices can be unlocked but do not let the
system operate without SecureOS. SecureOS prevents
On Fri, Jun 07, 2013 at 04:25:07PM +0900, Alexandre Courbot wrote:
On Thu, Jun 6, 2013 at 8:02 PM, Dave Martin dave.mar...@arm.com wrote:
+static int __attribute__((used)) __tegra_smc_stack[10];
Use __used instead of using GCC attributes directly.
+
+/*
+ * With EABI, subtype and
On Thu, Jun 06, 2013 at 12:29:14PM -0600, Stephen Warren wrote:
On 06/06/2013 12:08 PM, Dave Martin wrote:
On Thu, Jun 06, 2013 at 10:44:48AM -0600, Stephen Warren wrote:
On 06/06/2013 01:28 AM, Alexandre Courbot wrote:
Boot loaders on some Tegra devices can be unlocked but do not let the
On Fri, Jun 07, 2013 at 06:03:54PM +0900, Alexandre Courbot wrote:
On Fri, Jun 7, 2013 at 3:08 AM, Dave Martin dave.mar...@arm.com wrote:
I think we need to separate the concept of support for *a* secure
monitor, from support for a *particular* secure monitor.
There is no fixed set of
On Thu, Jun 6, 2013 at 9:26 PM, Jassi Brar jassisinghb...@gmail.com wrote:
On Thu, Jun 6, 2013 at 12:58 PM, Alexandre Courbot acour...@nvidia.com
wrote:
Boot loaders on some Tegra devices can be unlocked but do not let the
system operate without SecureOS. SecureOS prevents access to some
On Thu, Jun 6, 2013 at 8:02 PM, Dave Martin dave.mar...@arm.com wrote:
+static int __attribute__((used)) __tegra_smc_stack[10];
Use __used instead of using GCC attributes directly.
+
+/*
+ * With EABI, subtype and arg already end up in r0, r1 and r2 as they are
+ * function arguments, but
On Fri, Jun 7, 2013 at 1:44 AM, Stephen Warren swar...@wwwdotorg.org wrote:
On 06/06/2013 01:28 AM, Alexandre Courbot wrote:
Boot loaders on some Tegra devices can be unlocked but do not let the
system operate without SecureOS. SecureOS prevents access to some
registers and requires the
On Fri, Jun 7, 2013 at 12:43 PM, Alexandre Courbot gnu...@gmail.com wrote:
On Thu, Jun 6, 2013 at 9:26 PM, Jassi Brar jassisinghb...@gmail.com wrote:
On Thu, Jun 6, 2013 at 12:58 PM, Alexandre Courbot acour...@nvidia.com
wrote:
Boot loaders on some Tegra devices can be unlocked but do not let
On Fri, Jun 7, 2013 at 3:08 AM, Dave Martin dave.mar...@arm.com wrote:
I think we need to separate the concept of support for *a* secure
monitor, from support for a *particular* secure monitor.
There is no fixed set of functionality implemented by these interfaces,
so it might be better to
On 06/06/2013 12:08 PM, Dave Martin wrote:
> On Thu, Jun 06, 2013 at 10:44:48AM -0600, Stephen Warren wrote:
>> On 06/06/2013 01:28 AM, Alexandre Courbot wrote:
>>> Boot loaders on some Tegra devices can be unlocked but do not let the
>>> system operate without SecureOS. SecureOS prevents access
On Thu, Jun 06, 2013 at 10:44:48AM -0600, Stephen Warren wrote:
> On 06/06/2013 01:28 AM, Alexandre Courbot wrote:
> > Boot loaders on some Tegra devices can be unlocked but do not let the
> > system operate without SecureOS. SecureOS prevents access to some
> > registers and requires the
On 06/06/2013 01:28 AM, Alexandre Courbot wrote:
> Boot loaders on some Tegra devices can be unlocked but do not let the
> system operate without SecureOS. SecureOS prevents access to some
> registers and requires the operating system to perform certain
> operations through Secure Monitor Calls
On 06/06/2013 04:37 AM, Alex Courbot wrote:
> Hi Tomasz,
>
> On 06/06/2013 07:17 PM, Tomasz Figa wrote:
...
>> I think this patch could be split into several patches:
>> - add support for firmware
>> - split reset function
>> - add reset support using firmware.
>
> Mmm possibly yes, but I
On Thu, Jun 6, 2013 at 12:58 PM, Alexandre Courbot wrote:
> Boot loaders on some Tegra devices can be unlocked but do not let the
> system operate without SecureOS. SecureOS prevents access to some
> registers and requires the operating system to perform certain
> operations through Secure
On Thu, Jun 06, 2013 at 12:17:02PM +0200, Tomasz Figa wrote:
> Hi Alex,
>
> On Thursday 06 of June 2013 16:28:07 Alexandre Courbot wrote:
> > Boot loaders on some Tegra devices can be unlocked but do not let the
> > system operate without SecureOS. SecureOS prevents access to some
> > registers
On Thu, Jun 06, 2013 at 04:28:07PM +0900, Alexandre Courbot wrote:
> Boot loaders on some Tegra devices can be unlocked but do not let the
> system operate without SecureOS. SecureOS prevents access to some
> registers and requires the operating system to perform certain
> operations through
Hi Tomasz,
On 06/06/2013 07:17 PM, Tomasz Figa wrote:
+Global properties
+---
+
+The following properties can be specified into the "chosen" root
+node:
+
+ nvidia,secure-os: enable SecureOS.
Hmm, on Exynos we had something like
On 06/06/2013 06:35 PM, Russell King - ARM Linux wrote:
On Thu, Jun 06, 2013 at 04:28:07PM +0900, Alexandre Courbot wrote:
+static int __attribute__((used)) __tegra_smc_stack[10];
+
+/*
+ * With EABI, subtype and arg already end up in r0, r1 and r2 as they are
+ * function arguments, but we
Hi Alex,
On Thursday 06 of June 2013 16:28:07 Alexandre Courbot wrote:
> Boot loaders on some Tegra devices can be unlocked but do not let the
> system operate without SecureOS. SecureOS prevents access to some
> registers and requires the operating system to perform certain
> operations through
On Thu, Jun 06, 2013 at 04:28:07PM +0900, Alexandre Courbot wrote:
> +static int __attribute__((used)) __tegra_smc_stack[10];
> +
> +/*
> + * With EABI, subtype and arg already end up in r0, r1 and r2 as they are
> + * function arguments, but we prefer to play safe here and explicitly move
> + *
On Thu, Jun 06, 2013 at 04:28:07PM +0900, Alexandre Courbot wrote:
+static int __attribute__((used)) __tegra_smc_stack[10];
+
+/*
+ * With EABI, subtype and arg already end up in r0, r1 and r2 as they are
+ * function arguments, but we prefer to play safe here and explicitly move
+ * these
Hi Alex,
On Thursday 06 of June 2013 16:28:07 Alexandre Courbot wrote:
Boot loaders on some Tegra devices can be unlocked but do not let the
system operate without SecureOS. SecureOS prevents access to some
registers and requires the operating system to perform certain
operations through
On 06/06/2013 06:35 PM, Russell King - ARM Linux wrote:
On Thu, Jun 06, 2013 at 04:28:07PM +0900, Alexandre Courbot wrote:
+static int __attribute__((used)) __tegra_smc_stack[10];
+
+/*
+ * With EABI, subtype and arg already end up in r0, r1 and r2 as they are
+ * function arguments, but we
Hi Tomasz,
On 06/06/2013 07:17 PM, Tomasz Figa wrote:
+Global properties
+---
+
+The following properties can be specified into the chosen root
+node:
+
+ nvidia,secure-os: enable SecureOS.
Hmm, on Exynos we had something like
On Thu, Jun 06, 2013 at 04:28:07PM +0900, Alexandre Courbot wrote:
Boot loaders on some Tegra devices can be unlocked but do not let the
system operate without SecureOS. SecureOS prevents access to some
registers and requires the operating system to perform certain
operations through Secure
On Thu, Jun 06, 2013 at 12:17:02PM +0200, Tomasz Figa wrote:
Hi Alex,
On Thursday 06 of June 2013 16:28:07 Alexandre Courbot wrote:
Boot loaders on some Tegra devices can be unlocked but do not let the
system operate without SecureOS. SecureOS prevents access to some
registers and
On Thu, Jun 6, 2013 at 12:58 PM, Alexandre Courbot acour...@nvidia.com wrote:
Boot loaders on some Tegra devices can be unlocked but do not let the
system operate without SecureOS. SecureOS prevents access to some
registers and requires the operating system to perform certain
operations
On 06/06/2013 04:37 AM, Alex Courbot wrote:
Hi Tomasz,
On 06/06/2013 07:17 PM, Tomasz Figa wrote:
...
I think this patch could be split into several patches:
- add support for firmware
- split reset function
- add reset support using firmware.
Mmm possibly yes, but I wonder if
On 06/06/2013 01:28 AM, Alexandre Courbot wrote:
Boot loaders on some Tegra devices can be unlocked but do not let the
system operate without SecureOS. SecureOS prevents access to some
registers and requires the operating system to perform certain
operations through Secure Monitor Calls
On Thu, Jun 06, 2013 at 10:44:48AM -0600, Stephen Warren wrote:
On 06/06/2013 01:28 AM, Alexandre Courbot wrote:
Boot loaders on some Tegra devices can be unlocked but do not let the
system operate without SecureOS. SecureOS prevents access to some
registers and requires the operating
On 06/06/2013 12:08 PM, Dave Martin wrote:
On Thu, Jun 06, 2013 at 10:44:48AM -0600, Stephen Warren wrote:
On 06/06/2013 01:28 AM, Alexandre Courbot wrote:
Boot loaders on some Tegra devices can be unlocked but do not let the
system operate without SecureOS. SecureOS prevents access to some
56 matches
Mail list logo