linux-kernel - Re: [patches] Re: [PATCH] dt-bindings: Add a RISC-V SBI firmware node

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20171121200832.d55khzcufo2owcff@latitude>
Date:   Tue, 21 Nov 2017 21:08:32 +0100
From:   Jonathan Neuschäfer <j.neuschaefer@....net>
To:     Palmer Dabbelt <palmer@...ive.com>
Cc:     robh@...nel.org, j.neuschaefer@....net, mark.rutland@....com,
        devicetree@...r.kernel.org, patches@...ups.riscv.org,
        linux-kernel@...r.kernel.org
Subject: Re: [patches] Re: [PATCH] dt-bindings: Add a RISC-V SBI firmware node

On Tue, Nov 21, 2017 at 09:37:02AM -0800, Palmer Dabbelt wrote:
[...]
> This isn't really a big deal to me, as I'm only interested in RISC-V
> systems, but there's been some pushback on the concept of an SBI so it
> seemed like a simple way to allow people to build non-SBI (and there for not
> really RISC-V) systems.

For those reading along: I suggested the /firmware/sbi node to Palmer,
because I'm interested in such "not really RISC-V" systems, (because it
makes the firmware's job easier to not implement the SBI — speaking with
my coreboot hat, here.)

> One option that wouldn't require a device tree node
> would be to have Linux boot in machine mode [...] and then provide its
> own SBI implementation.

I think this can work.


Thanks,
Jonathan Neuschäfer

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)