Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Tue, 21 Nov 2017 16:36:22 -0800 (PST)
Subject:     Re: [patches] Re: [PATCH] dt-bindings: Add a RISC-V SBI firmware node
In-Reply-To: <20171121200832.d55khzcufo2owcff@latitude>
CC:     robh@kernel.org, j.neuschaefer@gmx.net, mark.rutland@arm.com,
        devicetree@vger.kernel.org, patches@groups.riscv.org,
        linux-kernel@vger.kernel.org
From:   Palmer Dabbelt <palmer@sifive.com>
To:     j.neuschaefer@gmx.net
Message-ID: <mhng-40a689c5-fa7b-4cff-9739-555b7c65981f@palmer-si-x1c4>
Mime-Version: 1.0 (MHng)
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, 21 Nov 2017 12:08:32 PST (-0800), j.neuschaefer@gmx.net wrote:
> 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.

OK, sounds good!

From 1584707636940516454@xxx Tue Nov 21 20:09:32 +0000 2017
X-GM-THRID: 1584615981624343565
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread