linux-riscv.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Atish Patra <Atish.Patra@wdc.com>
To: "paul.walmsley@sifive.com" <paul.walmsley@sifive.com>,
	"palmer@sifive.com" <palmer@sifive.com>
Cc: "linux-riscv@lists.infradead.org" <linux-riscv@lists.infradead.org>
Subject: Re: [PATCH 1/4] Documentation: riscv: boot: We're not compatible with arm64
Date: Sat, 14 Sep 2019 02:46:01 +0000	[thread overview]
Message-ID: <194c2f10c9806720623430dbf0cc59a965e50448.camel@wdc.com> (raw)
In-Reply-To: <alpine.DEB.2.21.9999.1909131553051.9752@viisi.sifive.com>

On Fri, 2019-09-13 at 18:13 -0700, Paul Walmsley wrote:
> On Fri, 13 Sep 2019, Palmer Dabbelt wrote:
> 
> > The documentation for our bootloader claims that it can be made
> > compatible with arm64, but that's not true.  There are some
> > differences
> > between our format and arm64:
> > 
> > * We've used the first 32 bits of their 64-bit "res2" as a version
> > number,
> >   which we're currently setting to non-zero.
> 
> During the review of this patch, I assumed -- maybe incorrectly --
> that 
> ARM64 didn't require the reserved fields to be zero.  In retrospect,
> this 
> was not a good assumption to make.  It would have been better for me
> to 
> get explicit agreement from the ARM64 folks.
> 

Any reserved field is set to zero. The idea was to modify the reserve
field for ARM to have a flag version if we ever unify both ARM64 &
RISC-V headers.

> > * We're using their "res4" field as our magic number.
> > * We're treating their magic number as our "res3" field,
> 
> This looks like the key issue.  Let's rename the 32-bit RISC-V res3
> field 
> as magic2, and just use it.  Then over time we should be able to
> deprecate 
> the original RISC-V 64-bit magic field.
> 

Originally, "RISCV" magic value was a 64-bit value. That's why I kept
in res4 field. Again, my plan was to have a arch specific ifdef only
for magic values if we ever unify both ARM64 & RISC-V headers.

We never got the ack for unification of boot header proposal from ARM
maintainers. Thus, these things never got implemented.

> >   which nominally contains a flag for big endian systems
> > already.  This 
> >   can't get set, so we should just drop it -- it's also not
> > described 
> >   what the flag means.
> 
> This one I'm not seeing.  In both headers, the flags field is in the 
> same place: towards the beginning of the headers, before the
> reserved 
> fields:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/riscv/include/asm/image.h#n56
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/include/asm/image.h#n49
> 
> The endianness bit in that field is defined the same way:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/arm64/booting.rst#n106
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/riscv/boot-image-header.txt#n46
> 
> Please let me know if I've misunderstood your point.
> 

I agree with Paul.

Regards,
Atish
> > This patch removes the claim that our header can be made compatible
> > with
> > arm64.
> > 
> > Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
> > ---
> >  Documentation/riscv/boot-image-header.txt | 5 ++---
> >  1 file changed, 2 insertions(+), 3 deletions(-)
> > 
> > diff --git a/Documentation/riscv/boot-image-header.txt
> > b/Documentation/riscv/boot-image-header.txt
> > index 1b73fea23b39..77e8e505bc41 100644
> > --- a/Documentation/riscv/boot-image-header.txt
> > +++ b/Documentation/riscv/boot-image-header.txt
> > @@ -21,9 +21,8 @@ The following 64-byte header is present in
> > decompressed Linux kernel image.
> >  	u32 res3;		  /* Reserved for additional RISC-V
> > specific header */
> >  	u32 res4;		  /* Reserved for PE COFF offset */
> >  
> > -This header format is compliant with PE/COFF header and largely
> > inspired from
> > -ARM64 header. Thus, both ARM64 & RISC-V header can be combined
> > into one common
> > -header in future.
> > +This header format is compliant with PE/COFF header and largely
> > inspired by,
> > +but not compatible with, the ARM64 header.
> >  
> >  Notes:
> >  - This header can also be reused to support EFI stub for RISC-V in
> > future. EFI
> > -- 
> > 2.21.0
> > 
> > 
> > _______________________________________________
> > linux-riscv mailing list
> > linux-riscv@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-riscv
> > 
> 
> - Paul

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

  reply	other threads:[~2019-09-14  2:46 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-13 19:24 [PATCH 0/4] Documentation: riscv: Image cleanups Palmer Dabbelt
2019-09-13 19:24 ` [PATCH 1/4] Documentation: riscv: boot: We're not compatible with arm64 Palmer Dabbelt
2019-09-14  1:13   ` Paul Walmsley
2019-09-14  2:46     ` Atish Patra [this message]
2019-09-13 19:24 ` [PATCH 2/4] Documentation: riscv: boot: Don't claim we're compliant with PE Palmer Dabbelt
2019-09-13 19:24 ` [PATCH 3/4] Documentation: riscv: boot: Whitespace fix Palmer Dabbelt
2019-09-13 19:24 ` [PATCH 4/4] Documentation: riscv: boot: Don't mention big-endian Palmer Dabbelt
2019-09-14  4:06 ` [PATCH 0/4] Documentation: riscv: Image cleanups Atish Patra

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=194c2f10c9806720623430dbf0cc59a965e50448.camel@wdc.com \
    --to=atish.patra@wdc.com \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@sifive.com \
    --cc=paul.walmsley@sifive.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).