On Thu, 5 Sep 2019 14:26:41 +0200
Marek Vasut wrote:
Hi,
> On 9/5/19 2:54 AM, André Przywara wrote:
> > On 04/09/2019 18:56, Marek Vasut wrote:
> >> On 9/4/19 7:32 PM, Andre Przywara wrote:
> I have been avoiding this thread but today I attended a talk on ATF
> and ARM's approach
On 9/5/19 2:54 AM, André Przywara wrote:
> On 04/09/2019 18:56, Marek Vasut wrote:
>> On 9/4/19 7:32 PM, Andre Przywara wrote:
>
> Hi Marek,
Hi,
I have been avoiding this thread but today I attended a talk on ATF
and ARM's approach in general. ARM seems to be moving towards an
Hi Simon and all,
> I have been avoiding this thread but today I attended a talk on ATF and
> ARM's approach in general.
For the benefits of others, that was me talking at the OSFC conference (video
and slides should appear soon here:
On 04/09/2019 18:56, Marek Vasut wrote:
> On 9/4/19 7:32 PM, Andre Przywara wrote:
Hi Marek,
>>> I have been avoiding this thread but today I attended a talk on ATF
>>> and ARM's approach in general. ARM seems to be moving towards an
>>> approach of providing increasingly complex source code to
On Wed, Sep 04, 2019 at 11:51:41AM +0900, Masahiro Yamada wrote:
> On Sun, Jun 30, 2019 at 11:20 PM Marek Vasut wrote:
> >
> > On 6/30/19 4:17 PM, Tom Rini wrote:
> > > On Sun, Jun 30, 2019 at 04:03:52PM +0200, Marek Vasut wrote:
> > >> On 6/30/19 3:57 PM, Tom Rini wrote:
> > >>> On Sat, Jun 29,
On 9/4/19 7:32 PM, Andre Przywara wrote:
[...]
>> I have been avoiding this thread but today I attended a talk on ATF
>> and ARM's approach in general. ARM seems to be moving towards an
>> approach of providing increasingly complex source code to add more
>> layers of security software to fully
On Tue, 3 Sep 2019 19:17:14 -0700
Simon Glass wrote:
Hi Simon,
> On Tue, 2 Jul 2019 at 11:42, Marek Vasut wrote:
> >
> > On 6/30/19 3:38 AM, André Przywara wrote:
> > > On 30/06/2019 00:03, Marek Vasut wrote:
> > >
> > > Marek,
> > >
> > > you seem to be quite defensive in your answer
> >
On Sun, Jun 30, 2019 at 11:20 PM Marek Vasut wrote:
>
> On 6/30/19 4:17 PM, Tom Rini wrote:
> > On Sun, Jun 30, 2019 at 04:03:52PM +0200, Marek Vasut wrote:
> >> On 6/30/19 3:57 PM, Tom Rini wrote:
> >>> On Sat, Jun 29, 2019 at 08:32:00PM +0530, Jagan Teki wrote:
> >>>
> In terms of code
Hi,
On Tue, 2 Jul 2019 at 11:42, Marek Vasut wrote:
>
> On 6/30/19 3:38 AM, André Przywara wrote:
> > On 30/06/2019 00:03, Marek Vasut wrote:
> >
> > Marek,
> >
> > you seem to be quite defensive in your answer
>
> I am just correcting the mistakes I perceive in the previous email.
>
> >, but I
On 6/30/19 3:38 AM, André Przywara wrote:
> On 30/06/2019 00:03, Marek Vasut wrote:
>
> Marek,
>
> you seem to be quite defensive in your answer
I am just correcting the mistakes I perceive in the previous email.
>, but I was just talking
> against merging ATF into U-Boot, not against U-Boot -
On 6/30/19 4:29 PM, Tom Rini wrote:
> On Sun, Jun 30, 2019 at 04:20:41PM +0200, Marek Vasut wrote:
>> On 6/30/19 4:17 PM, Tom Rini wrote:
>>> On Sun, Jun 30, 2019 at 04:03:52PM +0200, Marek Vasut wrote:
On 6/30/19 3:57 PM, Tom Rini wrote:
> On Sat, Jun 29, 2019 at 08:32:00PM +0530, Jagan
On Sun, Jun 30, 2019 at 04:20:41PM +0200, Marek Vasut wrote:
> On 6/30/19 4:17 PM, Tom Rini wrote:
> > On Sun, Jun 30, 2019 at 04:03:52PM +0200, Marek Vasut wrote:
> >> On 6/30/19 3:57 PM, Tom Rini wrote:
> >>> On Sat, Jun 29, 2019 at 08:32:00PM +0530, Jagan Teki wrote:
> >>>
> In terms of
On 6/30/19 4:17 PM, Tom Rini wrote:
> On Sun, Jun 30, 2019 at 04:03:52PM +0200, Marek Vasut wrote:
>> On 6/30/19 3:57 PM, Tom Rini wrote:
>>> On Sat, Jun 29, 2019 at 08:32:00PM +0530, Jagan Teki wrote:
>>>
In terms of code maintenance and development feasibility it is always
a better
On Sun, Jun 30, 2019 at 04:03:52PM +0200, Marek Vasut wrote:
> On 6/30/19 3:57 PM, Tom Rini wrote:
> > On Sat, Jun 29, 2019 at 08:32:00PM +0530, Jagan Teki wrote:
> >
> >> In terms of code maintenance and development feasibility it is always
> >> a better approach to have out-of-tree code or
On Sun, Jun 30, 2019 at 4:03 PM Marek Vasut wrote:
>
> On 6/30/19 3:57 PM, Tom Rini wrote:
> > On Sat, Jun 29, 2019 at 08:32:00PM +0530, Jagan Teki wrote:
> >
> >> In terms of code maintenance and development feasibility it is always
> >> a better approach to have out-of-tree code or binary to be
On 6/30/19 3:57 PM, Tom Rini wrote:
> On Sat, Jun 29, 2019 at 08:32:00PM +0530, Jagan Teki wrote:
>
>> In terms of code maintenance and development feasibility it is always
>> a better approach to have out-of-tree code or binary to be part of
>> in-house source tree.
>>
>> This is what exactly it
On Sat, Jun 29, 2019 at 08:32:00PM +0530, Jagan Teki wrote:
> In terms of code maintenance and development feasibility it is always
> a better approach to have out-of-tree code or binary to be part of
> in-house source tree.
>
> This is what exactly it was done for SPL, if I'm not wrong. So can
Dear Jagan,
In message
you wrote:
> In terms of code maintenance and development feasibility it is always
> a better approach to have out-of-tree code or binary to be part of
> in-house source tree.
>
> This is what exactly it was done for SPL, if I'm not wrong. So can we
> do the same thing
On 30/06/2019 00:03, Marek Vasut wrote:
Marek,
you seem to be quite defensive in your answer, but I was just talking
against merging ATF into U-Boot, not against U-Boot - I think we agree
on this. I don't think there is much of a point in comparing ATF and
U-Boot, as the two do not compete
On 6/29/19 8:49 PM, André Przywara wrote:
> On 29/06/2019 16:02, Jagan Teki wrote:
>> In terms of code maintenance and development feasibility it is always
>> a better approach to have out-of-tree code or binary to be part of
>> in-house source tree.
>
> I am not sure this is really true. If I
On 29/06/2019 16:02, Jagan Teki wrote:
> In terms of code maintenance and development feasibility it is always
> a better approach to have out-of-tree code or binary to be part of
> in-house source tree.
I am not sure this is really true. If I get you right, you want to
mirror and sync the ATF
On 6/29/19 5:02 PM, Jagan Teki wrote:
> In terms of code maintenance and development feasibility it is always
> a better approach to have out-of-tree code or binary to be part of
> in-house source tree.
You are free to do so locally, but following this train of thought would
possibly lead to
> From: Jagan Teki
> Date: Sat, 29 Jun 2019 20:32:00 +0530
>
> In terms of code maintenance and development feasibility it is always
> a better approach to have out-of-tree code or binary to be part of
> in-house source tree.
I disagree. This strategy often leads to diverging codebases where
In terms of code maintenance and development feasibility it is always
a better approach to have out-of-tree code or binary to be part of
in-house source tree.
This is what exactly it was done for SPL, if I'm not wrong. So can we
do the same thing for ATF on ARM64 SoCs?
We are using ATF (on
24 matches
Mail list logo
