[coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board

[Shawn]

Hi Jonathan,

On Thu, Jun 21, 2018 at 7:48 PM, Jonathan Neuschäfer
<j.neuschaefer at gmx.net> wrote:
> Hello Taiidan and Timothy,
>
> On Thu, Jun 21, 2018 at 01:14:05AM -0500, Timothy Pearson wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> On 06/20/2018 09:13 PM, Taiidan at gmx.com wrote:
>> > https://www.phoronix.com/forums/forum/hardware/motherboards-chipsets/1021175-risc-v-sifive-freedom-unleahsed-540-soc-hifive-unleashed-board-added-to-coreboot
>> >
>> > The board costs almost as much as a significantly faster and with much
>> > more features (IOMMU!) TALOS 2 Lite so I think it is not really worth
>> > buying right now for someone like me but I am still very curious about it.
>> >
>> > - Unlike the usual crappy SOC products like this there is an available
>> > sexy expansion board which contains not one but two PCI-e slots and
>> > various other expansion options including SATA...which all really should
>> > have came standard. But unfortunately once you buy all the extras that
>> > make it usable you could have bought a very nice T2 setup so this is
>> > only for the die-hard hero developers and early adopters. (But I wish I
>> > had the cash for both!)
>
> Fully agreed. It's a devboard and the purpose is to help spread RISC-V,
> whereas the Talos 2 (Lite) is a usable machine with all the bells and
> whistles that you'd expect.
>
> Note that the expansion board[1] is designed around a Microsemi FPGA,
> however that influences your freedom rating.
>
> (It should be possible though to implement an expansion board with a
> free bitstream: SiFive has published an implementation of ChipLink[2],
> and the FMC connector[3] is an industry standard.)
>
>> >
>> >
>> > My questions:
>> >
>> > Is it possible to do normal stuff like browse the internet and watch a
>> > film via video acceleration if you pop in a decent graphics card?
>
> Yes. The FOSDEM presentation was held on a HiFive Unleashed with an
> external graphics card.
>
>> > Are there absolutely no binary blobs? Not even for the NIC?
>
> It's a Cadence GEMGXL (aka. MACB) integrated into the SoC, plus an
> external PHY. No idea.
>
>> > It is difficult to find NIC ASIC's that don't have blobs and with RISCV's
>> > unfortunate lack of an IOMMU this is a very big security issue for
>> > RISCV. At least with the TALOS 2 there is POWER-IOMMU to isolate it from
>> > doing anything evil and various people are working on a libre
>> > replacement which will benefit the entire libre community and anyone
>> > that likes cheap+good nics.
>
> I'm sure IOMMUs will come to RISC-V as well.
>
>> >
>> > Whats the deal with SMM? What a shame they thought to add it.
>
> Yes, unfortunately runtime-resident code in a mode similar to SMM is a
> platform requirement, and Linux relies on it. (The interface that Linux
> expects is called the SBI / Supervisor Binary Interface.)
>
>> >
>> >
>> > I really hope this succeeds and that they eventually add an IOMMU.
>> >
>>
>> Their bootloader is a blob in ROM, for what it's worth.  They also will
>> not release source for it [1].  I haven't looked further since that
>> alone is a dealbreaker for an "open" / auditable chip.
>
> Let me add a bit of detail here:
>
> The original boot chain on the SiFive FU540 looks like this:
>
>   MSEL (ROM0) -> ZSBL (ROM1) -> FSBL (SPI) -> bbl (SPI/SD) -> Linux
>
> Where the individual pieces mean this:
>
> MSEL: The "Mode select" ROM, consisting of a register that represents
>       the state of four pins on the chip, and six instructions, which
>       jump to the selected boot device or ZSBL.
>       Fully documented (with an instruction listing) in the manual.
>
> ZSBL: The "Zeroth stage bootloader", several kilobytes of code in ROM,
>       which parses a GPT header on SPI flash or an SD card and loads the
>       next stage.
>       Short, high-level documentation in the manual; I haven't seen the
>       source code.
>
> FSBL: The "First stage bootloader", where interesting things like RAM
>       init happen.
>       High-level documentation in the manual; I haven't seen the source
>       code.
>
> BBL:  The "Berkeley bootloader". Its most important role, as far as I
>       understand it, is to implement the SBI.
>       The source code is public.
>
> See also chapter 6 (Boot process) of the FU540-C000 Manual[4].
>
> With the unfinished coreboot port, I want it to look like this (although
> *a lot* of work has to be done on coreboot first, and I'm currently not
> actively working on that, for a few months):
>
>   MSEL (ROM0) -> ZSBL (ROM1) -> coreboot (+bbl?) -> Linux,  or
>   MSEL (ROM0) -> coreboot (+bbl?) -> Linux
>
> ZSBL can be skipped, so you don't need to run closed source ROM code, at
> least as far as the hardware is concerned.
>
Is ZSBL really can be skipped? I thought it was part of internal ROM
inside the chip.

> (And note that this is just the situation on this particular SoC. Other
> SoCs from SiFive or other vendors may boot differently.)
>
Well, if FSBL is the place where coreboot comes into play, we might
only have two options: 1, Reversing the FSBL which is ~9k assembly LOC
2, SiFive make the FSBL open source( I don't see any reason why they
don't do it if they intend to build an open eco-system for RISC-V).



-- 
GNU powered it...
GPL protect it...
God blessing it...

regards
Shawn