All of lore.kernel.org
 help / color / mirror / Atom feed
From: Atish Patra <atish.patra@wdc.com>
To: Anup Patel <anup@brainfault.org>, Karsten Merker <merker@debian.org>
Cc: Palmer Dabbelt <palmer@sifive.com>,
	"zong@andestech.com" <zong@andestech.com>,
	"linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>,
	"aou@eecs.berkeley.edu" <aou@eecs.berkeley.edu>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] RISC-V: Add an Image header that boot loader can parse.
Date: Wed, 1 May 2019 10:32:47 -0700	[thread overview]
Message-ID: <eca0de61-885c-0ca1-d07b-870ad0c83327@wdc.com> (raw)
In-Reply-To: <CAAhSdy3kjqDahp13gQa0g9GF4gKPQeVgSakZzuP0uYwkCrvdAg@mail.gmail.com>

On 5/1/19 10:02 AM, Anup Patel wrote:
> On Wed, May 1, 2019 at 10:14 PM Karsten Merker <merker@debian.org> wrote:
>>
>> On Mon, Apr 29, 2019 at 10:42:40PM -0700, Atish Patra wrote:
>>> On 4/29/19 4:40 PM, Palmer Dabbelt wrote:
>>>> On Tue, 23 Apr 2019 16:25:06 PDT (-0700), atish.patra@wdc.com wrote:
>>>>> Currently, last stage boot loaders such as U-Boot can accept only
>>>>> uImage which is an unnecessary additional step in automating boot flows.
>>>>>
>>>>> Add a simple image header that boot loaders can parse and directly
>>>>> load kernel flat Image. The existing booting methods will continue to
>>>>> work as it is.
>>>>>
>>>>> Tested on both QEMU and HiFive Unleashed using OpenSBI + U-Boot + Linux.
>>>>>
>>>>> Signed-off-by: Atish Patra <atish.patra@wdc.com>
>>>>> ---
>>>>>    arch/riscv/include/asm/image.h | 32 ++++++++++++++++++++++++++++++++
>>>>>    arch/riscv/kernel/head.S       | 28 ++++++++++++++++++++++++++++
>>>>>    2 files changed, 60 insertions(+)
>>>>>    create mode 100644 arch/riscv/include/asm/image.h
>>>>>
>>>>> diff --git a/arch/riscv/include/asm/image.h b/arch/riscv/include/asm/image.h
>>>>> new file mode 100644
>>>>> index 000000000000..76a7e0d4068a
>>>>> --- /dev/null
>>>>> +++ b/arch/riscv/include/asm/image.h
>>>>> @@ -0,0 +1,32 @@
>>>>> +/* SPDX-License-Identifier: GPL-2.0 */
>>>>> +
>>>>> +#ifndef __ASM_IMAGE_H
>>>>> +#define __ASM_IMAGE_H
>>>>> +
>>>>> +#define RISCV_IMAGE_MAGIC        "RISCV"
>>>>> +
>>>>> +#ifndef __ASSEMBLY__
>>>>> +/*
>>>>> + * struct riscv_image_header - riscv kernel image header
>>>>> + *
>>>>> + * @code0:               Executable code
>>>>> + * @code1:               Executable code
>>>>> + * @text_offset: Image load offset
>>>>> + * @image_size:          Effective Image size
>>>>> + * @reserved:            reserved
>>>>> + * @magic:               Magic number
>>>>> + * @reserved:            reserved
>>>>> + */
>>>>> +
>>>>> +struct riscv_image_header {
>>>>> + u32 code0;
>>>>> + u32 code1;
>>>>> + u64 text_offset;
>>>>> + u64 image_size;
>>>>> + u64 res1;
>>>>> + u64 magic;
>>>>> + u32 res2;
>>>>> + u32 res3;
>>>>> +};
>>>>
>>>> I don't want to invent our own file format.  Is there a reason we can't just
>>>> use something standard?  Off the top of my head I can think of ELF files and
>>>> multiboot.
>>>
>>> Additional header is required to accommodate PE header format. Currently,
>>> this is only used for booti command but it will be reused for EFI headers as
>>> well. Linux kernel Image can pretend as an EFI application if PE/COFF header
>>> is present. This removes the need of an explicit EFI boot loader and EFI
>>> firmware can directly load Linux (obviously after EFI stub implementation
>>> for RISC-V).
>>>
>>> ARM64 follows the similar header format as well.
>>> https://www.kernel.org/doc/Documentation/arm64/booting.txt
>>
>> Hello Atish,
>>
>> the arm64 header looks a bit different (quoted from the
>> aforementioned URL):
>>
>>    u32 code0;                    /* Executable code */
>>    u32 code1;                    /* Executable code */
>>    u64 text_offset;              /* Image load offset, little endian */
>>    u64 image_size;               /* Effective Image size, little endian */
>>    u64 flags;                    /* kernel flags, little endian */
>>    u64 res2      = 0;            /* reserved */
>>    u64 res3      = 0;            /* reserved */
>>    u64 res4      = 0;            /* reserved */
>>    u32 magic     = 0x644d5241;   /* Magic number, little endian, "ARM\x64" */
>>    u32 res5;                     /* reserved (used for PE COFF offset) */
>>
>> What I am unclear about is in which ways a RISC-V PE/COFF header
>> differs from an arm64 one as the arm64 struct is longer than your
>> RISC-V header and for arm64 the PE offset field is in the last
>> field, i.e. outside of the area covered by your RISC-V structure
>> definition.  Can you perhaps explain this part in a bit more
>> detail or does anybody else have a pointer to a specification of
>> the RISC-V PE/COFF header format (I have found a lot of documents
>> about COFF in general, but nothing specific to RISC-V).
> 

Karsten,

> The only difference compared to ARM64 is the values of code0, code1
> and res5 fields.
> 
> As-per PE/COFF, the 32bit value at offset 0x3c tells us offset of PE/COFF
> header in image.
> 
> For more details refer,
> https://en.wikipedia.org/wiki/Portable_Executable
> https://en.wikipedia.org/wiki/Portable_Executable#/media/File:Portable_Executable_32_bit_Structure_in_SVG_fixed.svg
> 
> For both ARM64 header and RISC-V image header, is actually the
> "DOS header" part of PE/COFF format.
> 
> This patch only adds "DOS header" part of PE/COFF format. Rest of
> the PE/COFF header will be added when add EFI support to Linux
> RISC-V kernel.
> I think Anup answered your question. The original plan was to add EFI 
specific stuff in EFI support patch. That includes adjusting the PE/COFF 
offset at 0x3c and adding the "MZ" value for code0 if EFI is enabled.

In hindsight, I think it created more confusion. I will update the 
"riscv_image_header" structure to put PE/COFF offset(0x3c) at right 
place in v2 patch to avoid further confusion.

"MZ" value part should be added once EFI is enabled.

I will update the comments on riscv/include/asm/image.h as well to 
clarify more.

Regards,
Atish
> Regards,
> Anup
> 


WARNING: multiple messages have this Message-ID (diff)
From: Atish Patra <atish.patra@wdc.com>
To: Anup Patel <anup@brainfault.org>, Karsten Merker <merker@debian.org>
Cc: "zong@andestech.com" <zong@andestech.com>,
	"linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>,
	Palmer Dabbelt <palmer@sifive.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"aou@eecs.berkeley.edu" <aou@eecs.berkeley.edu>
Subject: Re: [PATCH] RISC-V: Add an Image header that boot loader can parse.
Date: Wed, 1 May 2019 10:32:47 -0700	[thread overview]
Message-ID: <eca0de61-885c-0ca1-d07b-870ad0c83327@wdc.com> (raw)
In-Reply-To: <CAAhSdy3kjqDahp13gQa0g9GF4gKPQeVgSakZzuP0uYwkCrvdAg@mail.gmail.com>

On 5/1/19 10:02 AM, Anup Patel wrote:
> On Wed, May 1, 2019 at 10:14 PM Karsten Merker <merker@debian.org> wrote:
>>
>> On Mon, Apr 29, 2019 at 10:42:40PM -0700, Atish Patra wrote:
>>> On 4/29/19 4:40 PM, Palmer Dabbelt wrote:
>>>> On Tue, 23 Apr 2019 16:25:06 PDT (-0700), atish.patra@wdc.com wrote:
>>>>> Currently, last stage boot loaders such as U-Boot can accept only
>>>>> uImage which is an unnecessary additional step in automating boot flows.
>>>>>
>>>>> Add a simple image header that boot loaders can parse and directly
>>>>> load kernel flat Image. The existing booting methods will continue to
>>>>> work as it is.
>>>>>
>>>>> Tested on both QEMU and HiFive Unleashed using OpenSBI + U-Boot + Linux.
>>>>>
>>>>> Signed-off-by: Atish Patra <atish.patra@wdc.com>
>>>>> ---
>>>>>    arch/riscv/include/asm/image.h | 32 ++++++++++++++++++++++++++++++++
>>>>>    arch/riscv/kernel/head.S       | 28 ++++++++++++++++++++++++++++
>>>>>    2 files changed, 60 insertions(+)
>>>>>    create mode 100644 arch/riscv/include/asm/image.h
>>>>>
>>>>> diff --git a/arch/riscv/include/asm/image.h b/arch/riscv/include/asm/image.h
>>>>> new file mode 100644
>>>>> index 000000000000..76a7e0d4068a
>>>>> --- /dev/null
>>>>> +++ b/arch/riscv/include/asm/image.h
>>>>> @@ -0,0 +1,32 @@
>>>>> +/* SPDX-License-Identifier: GPL-2.0 */
>>>>> +
>>>>> +#ifndef __ASM_IMAGE_H
>>>>> +#define __ASM_IMAGE_H
>>>>> +
>>>>> +#define RISCV_IMAGE_MAGIC        "RISCV"
>>>>> +
>>>>> +#ifndef __ASSEMBLY__
>>>>> +/*
>>>>> + * struct riscv_image_header - riscv kernel image header
>>>>> + *
>>>>> + * @code0:               Executable code
>>>>> + * @code1:               Executable code
>>>>> + * @text_offset: Image load offset
>>>>> + * @image_size:          Effective Image size
>>>>> + * @reserved:            reserved
>>>>> + * @magic:               Magic number
>>>>> + * @reserved:            reserved
>>>>> + */
>>>>> +
>>>>> +struct riscv_image_header {
>>>>> + u32 code0;
>>>>> + u32 code1;
>>>>> + u64 text_offset;
>>>>> + u64 image_size;
>>>>> + u64 res1;
>>>>> + u64 magic;
>>>>> + u32 res2;
>>>>> + u32 res3;
>>>>> +};
>>>>
>>>> I don't want to invent our own file format.  Is there a reason we can't just
>>>> use something standard?  Off the top of my head I can think of ELF files and
>>>> multiboot.
>>>
>>> Additional header is required to accommodate PE header format. Currently,
>>> this is only used for booti command but it will be reused for EFI headers as
>>> well. Linux kernel Image can pretend as an EFI application if PE/COFF header
>>> is present. This removes the need of an explicit EFI boot loader and EFI
>>> firmware can directly load Linux (obviously after EFI stub implementation
>>> for RISC-V).
>>>
>>> ARM64 follows the similar header format as well.
>>> https://www.kernel.org/doc/Documentation/arm64/booting.txt
>>
>> Hello Atish,
>>
>> the arm64 header looks a bit different (quoted from the
>> aforementioned URL):
>>
>>    u32 code0;                    /* Executable code */
>>    u32 code1;                    /* Executable code */
>>    u64 text_offset;              /* Image load offset, little endian */
>>    u64 image_size;               /* Effective Image size, little endian */
>>    u64 flags;                    /* kernel flags, little endian */
>>    u64 res2      = 0;            /* reserved */
>>    u64 res3      = 0;            /* reserved */
>>    u64 res4      = 0;            /* reserved */
>>    u32 magic     = 0x644d5241;   /* Magic number, little endian, "ARM\x64" */
>>    u32 res5;                     /* reserved (used for PE COFF offset) */
>>
>> What I am unclear about is in which ways a RISC-V PE/COFF header
>> differs from an arm64 one as the arm64 struct is longer than your
>> RISC-V header and for arm64 the PE offset field is in the last
>> field, i.e. outside of the area covered by your RISC-V structure
>> definition.  Can you perhaps explain this part in a bit more
>> detail or does anybody else have a pointer to a specification of
>> the RISC-V PE/COFF header format (I have found a lot of documents
>> about COFF in general, but nothing specific to RISC-V).
> 

Karsten,

> The only difference compared to ARM64 is the values of code0, code1
> and res5 fields.
> 
> As-per PE/COFF, the 32bit value at offset 0x3c tells us offset of PE/COFF
> header in image.
> 
> For more details refer,
> https://en.wikipedia.org/wiki/Portable_Executable
> https://en.wikipedia.org/wiki/Portable_Executable#/media/File:Portable_Executable_32_bit_Structure_in_SVG_fixed.svg
> 
> For both ARM64 header and RISC-V image header, is actually the
> "DOS header" part of PE/COFF format.
> 
> This patch only adds "DOS header" part of PE/COFF format. Rest of
> the PE/COFF header will be added when add EFI support to Linux
> RISC-V kernel.
> I think Anup answered your question. The original plan was to add EFI 
specific stuff in EFI support patch. That includes adjusting the PE/COFF 
offset at 0x3c and adding the "MZ" value for code0 if EFI is enabled.

In hindsight, I think it created more confusion. I will update the 
"riscv_image_header" structure to put PE/COFF offset(0x3c) at right 
place in v2 patch to avoid further confusion.

"MZ" value part should be added once EFI is enabled.

I will update the comments on riscv/include/asm/image.h as well to 
clarify more.

Regards,
Atish
> Regards,
> Anup
> 


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2019-05-01 17:32 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-23 23:25 [PATCH] RISC-V: Add an Image header that boot loader can parse Atish Patra
2019-04-23 23:25 ` Atish Patra
2019-04-29 23:40 ` Palmer Dabbelt
2019-04-29 23:40   ` Palmer Dabbelt
2019-04-30  5:42   ` Atish Patra
2019-04-30  5:42     ` Atish Patra
2019-05-01 16:43     ` Karsten Merker
2019-05-01 16:43       ` Karsten Merker
2019-05-01 17:02       ` Anup Patel
2019-05-01 17:02         ` Anup Patel
2019-05-01 17:32         ` Atish Patra [this message]
2019-05-01 17:32           ` Atish Patra
2019-05-01 17:00     ` Mark Rutland
2019-05-01 17:00       ` Mark Rutland
2019-05-01 17:11       ` Anup Patel
2019-05-01 17:11         ` Anup Patel
2019-05-01 17:35         ` Mark Rutland
2019-05-01 17:35           ` Mark Rutland
2019-05-01 19:54         ` Karsten Merker
2019-05-01 19:54           ` Karsten Merker
2019-05-01 20:32           ` Karsten Merker
2019-05-01 20:32             ` Karsten Merker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=eca0de61-885c-0ca1-d07b-870ad0c83327@wdc.com \
    --to=atish.patra@wdc.com \
    --cc=anup@brainfault.org \
    --cc=aou@eecs.berkeley.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=merker@debian.org \
    --cc=palmer@sifive.com \
    --cc=zong@andestech.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.