On 2017-02-20 02:33, Bryan O'Donoghue wrote:
>
>
> On 19/02/17 13:33, Jan Kiszka wrote:
>>> I would not object strongly to having conditionally compiled code in
>>> mainline that adds support for this, but bodging the default code path
>>> like this for a Quark quirk is out of the question imo.
>
On Wed, Mar 1, 2017 at 4:02 PM, Bryan O'Donoghue
wrote:
>>> So, summarize, you state that
>>> 1. CONFIG_SMP=y and
>>> 2. CONFIG_M686=y and
>>> 3. Kernel works on Quark
>>>
>>> Is it correct?
>> Logically yes. It's a very long time since I looked in detail. No harm
>> in checking it out though.
>
On 28/02/17 17:42, Bryan O'Donoghue wrote:
On 28/02/17 17:18, Andy Shevchenko wrote:
On Tue, Feb 28, 2017 at 6:52 PM, Bryan O'Donoghue
A kernel compiled like this
make menuconfig ARCH=i386
I hope you care that it is equivalent to
make menuconfig ARCH=i686
make bzImage -j 8
will run jus
On 28/02/17 17:18, Andy Shevchenko wrote:
> On Tue, Feb 28, 2017 at 6:52 PM, Bryan O'Donoghue
>> A kernel compiled like this
>>
>> make menuconfig ARCH=i386
>
> I hope you care that it is equivalent to
>
> make menuconfig ARCH=i686
>
>> make bzImage -j 8
>>
>> will run just fine on Quark x1000 I
On 28/02/17 15:27, Andy Shevchenko wrote:
> On Tue, Feb 28, 2017 at 5:07 PM, Bryan O'Donoghue
> wrote:
>> On 28/02/17 13:36, Andy Shevchenko wrote:
>>> On Tue, Feb 28, 2017 at 3:35 PM, Andy Shevchenko
>>> wrote:
On Tue, Feb 28, 2017 at 3:25 PM, Ard Biesheuvel
wrote:
> On 28 Februar
On Tue, Feb 28, 2017 at 6:52 PM, Bryan O'Donoghue
wrote:
> On 28/02/17 15:27, Andy Shevchenko wrote:
>> On Tue, Feb 28, 2017 at 5:07 PM, Bryan O'Donoghue
>> wrote:
>>> On 28/02/17 13:36, Andy Shevchenko wrote:
On Tue, Feb 28, 2017 at 3:35 PM, Andy Shevchenko
wrote:
> On Tue, Feb 28
On Tue, Feb 28, 2017 at 5:07 PM, Bryan O'Donoghue
wrote:
> On 28/02/17 13:36, Andy Shevchenko wrote:
>> On Tue, Feb 28, 2017 at 3:35 PM, Andy Shevchenko
>> wrote:
>>> On Tue, Feb 28, 2017 at 3:25 PM, Ard Biesheuvel
>>> wrote:
On 28 February 2017 at 12:29, Matt Fleming
wrote:
> On
On 28/02/17 13:36, Andy Shevchenko wrote:
> On Tue, Feb 28, 2017 at 3:35 PM, Andy Shevchenko
> wrote:
>> On Tue, Feb 28, 2017 at 3:25 PM, Ard Biesheuvel
>> wrote:
>>> On 28 February 2017 at 12:29, Matt Fleming wrote:
On Tue, 28 Feb, at 01:20:25PM, Jan Kiszka wrote:
>>
>>> As I said before,
On 28/02/17 15:07, Bryan O'Donoghue wrote:
> a big fat ia32
*allow a full fat..
--
bod
On Tue, Feb 28, 2017 at 3:35 PM, Andy Shevchenko
wrote:
> On Tue, Feb 28, 2017 at 3:25 PM, Ard Biesheuvel
> wrote:
>> On 28 February 2017 at 12:29, Matt Fleming wrote:
>>> On Tue, 28 Feb, at 01:20:25PM, Jan Kiszka wrote:
>
>> As I said before, I'd be ok with it if we select it compile time,
>> i
On Tue, Feb 28, 2017 at 3:25 PM, Ard Biesheuvel
wrote:
> On 28 February 2017 at 12:29, Matt Fleming wrote:
>> On Tue, 28 Feb, at 01:20:25PM, Jan Kiszka wrote:
> As I said before, I'd be ok with it if we select it compile time,
> i.e., no runtime logic that infers whether we are running on such a
On 28 February 2017 at 12:29, Matt Fleming wrote:
> On Tue, 28 Feb, at 01:20:25PM, Jan Kiszka wrote:
>>
>> From you POV, does this exclude upstream quirk support for already
>> shipped devices?
>
> It would need to be an extremely small, well-contained change, that
> had no chance of disrupting ot
On Tue, 28 Feb, at 01:20:25PM, Jan Kiszka wrote:
>
> From you POV, does this exclude upstream quirk support for already
> shipped devices?
It would need to be an extremely small, well-contained change, that
had no chance of disrupting other users of the capsule interface and
where I had a good fe
On 2017-02-28 13:12, Matt Fleming wrote:
> On Fri, 17 Feb, at 10:24:41AM, Jan Kiszka wrote:
>>
>> I just can re-express my frustration that this essential step hasn't
>> been started years ago by whoever designed the extension. Then I bet
>> there would have been constructive feedback on the interf
On Fri, 17 Feb, at 10:24:41AM, Jan Kiszka wrote:
>
> I just can re-express my frustration that this essential step hasn't
> been started years ago by whoever designed the extension. Then I bet
> there would have been constructive feedback on the interface BEFORE its
> ugliness spread to broader us
On 2017-02-19 17:33, Bryan O'Donoghue wrote:
>
>
> On 19/02/17 13:33, Jan Kiszka wrote:
>>> I would not object strongly to having conditionally compiled code in
>>> mainline that adds support for this, but bodging the default code path
>>> like this for a Quark quirk is out of the question imo.
>
On 19/02/17 13:33, Jan Kiszka wrote:
I would not object strongly to having conditionally compiled code in
mainline that adds support for this, but bodging the default code path
like this for a Quark quirk is out of the question imo.
I'm open for any consensus that avoids bending mainline too m
sday, February 16, 2017 3:00 AM
>>>> To: Andy Shevchenko
>>>> Cc: Matt Fleming ; Ard Biesheuvel
>>>> ; linux-...@vger.kernel.org; Linux Kernel
>>>> Mailing
>>>> List ; Borislav Petkov ;
>>>> Kweh,
>>>> Hock Leong ; Bryan
>>> Cc: Matt Fleming ; Ard Biesheuvel
>>> ; linux-...@vger.kernel.org; Linux Kernel Mailing
>>> List ; Borislav Petkov ; Kweh,
>>> Hock Leong ; Bryan O'Donoghue
>>>
>>> Subject: Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark
&
On 17/02/17 10:14, Jan Kiszka wrote:
> On 2017-02-17 10:51, Bryan O'Donoghue wrote:
>> On 17/02/17 08:23, Kweh, Hock Leong wrote:
>>> And to have UEFI expand
>>> it capsule support and take in signed binary would be a more secured way.
>>> So, influencing UEFI community to have such support would b
On 2017-02-17 10:51, Bryan O'Donoghue wrote:
> On 17/02/17 08:23, Kweh, Hock Leong wrote:
>> And to have UEFI expand
>> it capsule support and take in signed binary would be a more secured way.
>> So, influencing UEFI community to have such support would be the right
>> move throughout the discussi
On 17/02/17 08:23, Kweh, Hock Leong wrote:
> And to have UEFI expand
> it capsule support and take in signed binary would be a more secured way.
> So, influencing UEFI community to have such support would be the right
> move throughout the discussion. That is my summary.
CSH stands for "Clanton Se
Matt Fleming ; Ard Biesheuvel
>> ; linux-...@vger.kernel.org; Linux Kernel Mailing
>> List ; Borislav Petkov
>> Subject: Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark
>> images
>>
>>
>>
>> On 16/02/17 03:00, Kweh, Hock Leong wrote:
>&g
Mailing
> List ; Borislav Petkov
> Subject: Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark
> images
>
>
>
> On 16/02/17 03:00, Kweh, Hock Leong wrote:
> >> -Original Message-
> >> From: Jan Kiszka [mailto:jan.kis...@siemens.
; Kweh,
Hock Leong ; Bryan O'Donoghue
Subject: Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark
images
On 2017-02-15 19:50, Jan Kiszka wrote:
On 2017-02-15 19:46, Andy Shevchenko wrote:
On Wed, Feb 15, 2017 at 8:14 PM, Jan Kiszka
wrote:
See patch 2 for the background.
S
el.org; Linux Kernel Mailing
>> List ; Borislav Petkov ; Kweh,
>> Hock Leong ; Bryan O'Donoghue
>>
>> Subject: Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark
>> images
>>
>> On 2017-02-15 19:50, Jan Kiszka wrote:
>>> On 2017-02
> Hock Leong ; Bryan O'Donoghue
>
> Subject: Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark
> images
>
> On 2017-02-15 19:50, Jan Kiszka wrote:
> > On 2017-02-15 19:46, Andy Shevchenko wrote:
> >> On Wed, Feb 15, 2017 at 8:14 PM, Jan Kiszka
> w
On 2017-02-15 19:50, Jan Kiszka wrote:
> On 2017-02-15 19:46, Andy Shevchenko wrote:
>> On Wed, Feb 15, 2017 at 8:14 PM, Jan Kiszka wrote:
>>> See patch 2 for the background.
>>>
>>> Series has been tested on the Galileo Gen2, to exclude regressions, with
>>> a firmware.cap without security header
On 2017-02-15 19:46, Andy Shevchenko wrote:
> On Wed, Feb 15, 2017 at 8:14 PM, Jan Kiszka wrote:
>> See patch 2 for the background.
>>
>> Series has been tested on the Galileo Gen2, to exclude regressions, with
>> a firmware.cap without security header and the SIMATIC IOT2040 which
>> requires the
On 2017-02-15 19:17, Ard Biesheuvel wrote:
> On 15 February 2017 at 18:14, Jan Kiszka wrote:
>> See patch 2 for the background.
>>
>> Series has been tested on the Galileo Gen2, to exclude regressions, with
>> a firmware.cap without security header and the SIMATIC IOT2040 which
>> requires the hea
On Wed, Feb 15, 2017 at 8:14 PM, Jan Kiszka wrote:
> See patch 2 for the background.
>
> Series has been tested on the Galileo Gen2, to exclude regressions, with
> a firmware.cap without security header and the SIMATIC IOT2040 which
> requires the header because of its mandatory secure boot.
Brie
On Wed, Feb 15, 2017 at 8:14 PM, Jan Kiszka wrote:
> See patch 2 for the background.
>
> Series has been tested on the Galileo Gen2, to exclude regressions, with
> a firmware.cap without security header and the SIMATIC IOT2040 which
> requires the header because of its mandatory secure boot.
>
> J
On 15 February 2017 at 18:14, Jan Kiszka wrote:
> See patch 2 for the background.
>
> Series has been tested on the Galileo Gen2, to exclude regressions, with
> a firmware.cap without security header and the SIMATIC IOT2040 which
> requires the header because of its mandatory secure boot.
>
Hello
See patch 2 for the background.
Series has been tested on the Galileo Gen2, to exclude regressions, with
a firmware.cap without security header and the SIMATIC IOT2040 which
requires the header because of its mandatory secure boot.
Jan
Jan Kiszka (2):
efi/capsule: Prepare for loading images wi
34 matches
Mail list logo
