Re: [sw-dev] SBI extension proposal v2

[ron minnich <rminnich@gmail.com>]

On Mon, Jan 28, 2019 at 11:55 AM Alexander Graf <agraf@suse.de> wrote:

> You're mixing up 2 things (which is a pretty common fallacy I've come
> across people who worked too much with x86 firmware): Design and
> implementation.

uhm, alex, I worked on or started the coreboot ports to
arm
arm64
ppc
riscv
alpha

I've been working on various non-x86 firmware for over 40 years,
starting in 8 bit days.

You should probably not assume too much about people.

> The conclusion that runtime firmware is a bad idea IMHO is wrong though.

We can agree to disagree. But please don't start by stating things
about my background; you don't know me and you're wrong.

Runtime firmware is acceptable *if and only if* the kernel can measure
it, disable it all or in part, or replace it.
That's a different statement than what you just said. I don't like
runtime firmware, but of course on RISCV there are few options
for some registers. But it is a very rare runtime firmware that is
implemented correctly or even well.

There is one company that is so concerned about M mode they are
implementing a RISCV CPU without it.

> Now, if the firmware development model is so broken but at the same time
> such firmware gives us the ability to abstract interfaces better, what
> is the solution?

you give me the information I need to write a driver. Done. That's
known to work. And for linuxboot systems, that's the only way it
works.That way, we have one driver to deal with, not two. Server
systems that work this way are being deployed today.

> You obviously need to apply the same standards as you do for the OS to
> firmware. It's why open firmware is so important.

Sure. It'd be nice if that worked, but it's essential to ensure it's
the only thing that works. It's important not to enable architecture
features that can be used to make open source firmware
difficult or impossible. PMP is one such feature, since it allows
firmware to lock down regions of memory and make them inaccessible to
the kernel.

In general, however, vendor firmware is extremely poorly written, and
I don't expect that to change.

> But putting everything into Linux instead really is not the answer. The
> only thing it does is break forward compatibility and bloat code size.

I am, today, fitting a linux kernel and full Go userland into about 3M
in SPI. For reference, this is smaller than the audio codec firmware
on some chipsets.

I don't agree with your claim.

That said, RISCV will have the SBI, and there is no getting around it
for certain purposes, but there's no reason to encourage growth.

ron

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