ron minnich wrote:
> I realize there was a lot of hope in the early days that RISC-V
> implied "openness" but as we can see that is not so.
I hope that noone had that impression.
The key point (which I have to repeat every now and then) is that
RISC-V *supports* openness, in ways not possible with x86, ARM or
-yes- even POWER, at least at the moment.
> An open implementation of RISC-V will require a commitment on the
> part of a company to opening it up at all levels, not just the
> instruction set.
ron minnich wrote:
> I'm still interested in risc-v, just not hifive.
Right - I think it's important not to judge an open architecture by
any one implementation, but to remember (as you point out) the
difference between architecture and implementation.
I have a Kabylake laptop with a Sunrise Point chipset, that I want to port to coreboot using the FSP blob. I have no coding skills, but can follow the Librem build coreboot script and use code from ports using FSP 2.0 (Librem 15v3, Google Kabylake Chromebooks, Kabylake RVP8) to create mainboard directory for the laptop with proper devicetree. The EC on the laptop is an ITE with no datasheet available. Is it possible to at least get the laptop to boot using some code from these ports + the FSP and then use console log to fix issues? Can bad code alone damage the laptop?
On Mon, Jun 25, 2018 at 12:55 AM Shawn <citypw(a)gmail.com> wrote:
> Hi Ron,
> IIRC, Machine mode in RISC-V is just looking similar to SMM in x86.
> But it can do more than what SMM does.
that's in my view not good, since in many cases, M mode code is part of
firmware, not the kernel image. Kernels don't get to change or ignore it. M
mode can protect itself from the kernel, even from being read. So it can
hide its presence, what it does, and might even be able to change itself.
I had a talk with a BIG ARM SOC vendor not long ago. They said that at one
point a big x86 company proposed that their company implement SMM for ARM.
"so they asked us to implement this SMM-like thing that had unlimited
privilege. We said no, no no, there's no reason to repeat x86 mistakes on
ARM". Good call on that company's part.
I argued several years ago that M mode code should be supplied by the
kernel, not firmware, for the obvious reasons: M mode is a great place to
put a persistent threat. The various x86 experiences were well known by
that time, so the problem should have been pretty clear.
That's another point I somehow failed to communicate well, since I was
ignored. Hence, RISC-V now comes with Persistent Threat Support (TM) for
On Sun, Jun 24, 2018 at 12:55 AM, ron minnich <rminnich(a)gmail.com> wrote:
> On Wed, Jun 20, 2018 at 11:03 PM Taiidan(a)gmx.com <Taiidan(a)gmx.com> wrote:
>> Whats the deal with SMM? What a shame they thought to add it.
> It's a huge disappointment. I made some effort a few years ago to try to
> convince folks this was a bad idea and failed.
> I'm no longer as optimistic as I was about RISC-V. There seems to be a real
> push to be "just like x86".
IIRC, Machine mode in RISC-V is just looking similar to SMM in x86.
But it can do more than what SMM does. It helps to enclave-based
solution. I'm looking forward to see the open solution, e.g: Sanctum,
Keystone, etc to land into production environment.
btw: can't agree w/ you more about we need more open implementation
than Hifive unleashed.
 Secure Processors Part I: Background, Taxonomy for Secure Enclaves
and Intel SGX Architecture:
 Secure Processors Part II: Intel SGX Security Analysis and MIT
 Keystone: https://keystone-enclave.org/
GNU powered it...
GPL protect it...
God blessing it...
On 06/24/2018 02:59 PM, ron minnich wrote:
> On Sun, Jun 24, 2018 at 11:47 AM Jonathan Neuschäfer <j.neuschaefer(a)gmx.net>
>> "While we’d love to provide you with this information, we believe we
>> cannot. However, we can’t prevent anyone from disassembling the fsbl and
>> copying the values sent to the blackbox DDR register map."
> and ... there ends my interest in the hifive. A shame.
I can't understand what their target audience is? who would buy such a
thing? who do they intend to sell these to? I mean the open source
people can buy the now very affordable Talos 2L and the cheap-soc people
can buy one of the many of ARM boards that litter the marketplace...I
don't get it.
Dne 24.6.2018 v 20:59 ron minnich napsal(a):
> and ... there ends my interest in the hifive. A shame.
Well perhaps because the DDR controller is third party IP, see  FAQ or here:
> The Freedom U540 SoC is based on the Freedom Unleashed Platform, which has been open sourced. The Freedom Platform is available at https://github.com/sifive/freedom and is maintained by SiFive. In the Freedom Platform, you will find:
> RISC-V Rocket CPU
> TileLink, a free and open coherent SoC interconnect
> Low-speed Peripherals: SPI, UART, PWM, GPIO, I2C
> High-speed Xilinx FPGA Peripheral Wrappers: DDR, PCIe blocks
> The Freedom U540 contains many 3rd-party IP: cells, pads, PLL, OTP, DDR, GbE, ROM, which are not open-sourced
On Sun, Jun 24, 2018 at 11:47 AM Jonathan Neuschäfer <j.neuschaefer(a)gmx.net> wrote
> "While we’d love to provide you with this information, we believe we
> cannot. However, we can’t prevent anyone from disassembling the fsbl and
> copying the values sent to the blackbox DDR register map."
I think they are even asking to actually make some open version of FSBL
On 06/23/2018 01:58 AM, Jorge Fernandez Monteagudo wrote:
> Hi Nico, thanks for the feedback!
>> I guess it's used, but you need an acpi name for all devices along the
>> path. "LIBR" is the name for the LPC device, there should also be one
>> for the PCI bus/domain. I would try `src/northbridge/amd/pi/00660F01/
> Could you point me to an example to know what I have to look for, p.e, to a good supported board or something related. I'm still introducing me in the coreboot world :)
The KGPE-D16 and KCMA-D8 are I would say the best examples of coreboot
boards, they have the most features such as IOMMU-GFX and OpenBMC and
their code base is 100% open source/libre. They also of course support
TPM via a removable TPM header module.
The various sandybridge and ivybridge thinkpad T/X/W series laptops are
the most widely used coreboot devices that support TPM and can be
obtained for not much money if you want to have a working example.
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!)
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?
Are there absolutely no binary blobs? Not even for the NIC? 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.
Whats the deal with SMM? What a shame they thought to add it.
I really hope this succeeds and that they eventually add an IOMMU.
All this said, note that the HiFive is no more open, today, than your
average ARM SOC; and it is much less open than, e.g., Power. I realize
there was a lot of hope in the early days that RISC-V implied "openness"
but as we can see that is not so. There's blobs in HiFive.
Open instruction sets do not necessarily result in open implementations. An
open implementation of RISC-V will require a commitment on the part of a
company to opening it up at all levels, not just the instruction set.
On Fri, Jun 22, 2018 at 6:12 AM Shawn <citypw(a)gmail.com> wrote:
> On Fri, Jun 22, 2018 at 7:01 PM, Jonathan Neuschäfer
> <j.neuschaefer(a)gmx.net> wrote:
> > On Fri, Jun 22, 2018 at 03:04:06PM +0800, Shawn wrote:
> >> Hi Jonathan,
> >> On Thu, Jun 21, 2018 at 7:48 PM, Jonathan Neuschäfer
> > [...]
> >> > With the unfinished coreboot port, I want it to look like this
> >> > *a lot* of work has to be done on coreboot first, and I'm currently
> >> > 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,
> >> > 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.
> > Yes. If you set the MSEL switches to 0001, the code in the MSEL ROM
> > (aka. ROM0) jumps directly into the memory-mapped SPI flash, instead of
> > into the big ROM1, where ZSBL is.
> > Coreboot doesn't yet support this mode, but the hardware allows it.
> >> > (And note that this is just the situation on this particular SoC.
> >> > 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).
> > A high-level list of tasks that FSBL performs is in the manual:
> > • Switch core frequency to 1 GHz (or 500 MHz if TLCLKSEL =1) by
> > configuring and running off the on-chip PLL
> > • Configure DDR PLL, PHY, and controller
> > • Set GEM GXL TX PLL to 125 MHz and reset it
> > • If there is an external PHY, reset it
> > • Download BBL from a partition with GUID type
> > 2E54B353-1271-4842-806F-E436D6AF69851
> > • Scan the OTP for the chip serial number
> > • Copy the embedded DTB to DDR, filling in FSBL version, memory
> > size, and MAC address
> > • Enable 15 of the 16 L2 ways (this removes almost all of the L2
> > LIM memory)
> > • Jump to DDR memory (0x8000_0000)
> > Initializing the PLLs and reading the OTP ROM should be easy enough
> > because both are documented in, I think, sufficient detail.
> > Section 20.3 describes the initialization sequence for the DRAM
> > controller, but leaves out the values for the register for "memory
> > timing settings, PAD mode configuration, initialization, and training."
> > It says: "Please contact SiFive directly to determine the complete
> > register settings for your application."
> > I will ask on the forum.
> > Assuming that SiFive will tell us the values of the missing
> > configuration registers, I don't think we need to reverse-engineer FSBL.
> That's good to know and it's very helpful. We've been studying how to
> make coreboot work on Hifve Unleashed. If the reversing is not
> necessary, that'd be save a lot of time especially the decompiler for
> RISC-V doesn't exist yet. Thanks for the info.
> GNU powered it...
> GPL protect it...
> God blessing it...
> coreboot mailing list: coreboot(a)coreboot.org
On 22.06.2018 12:52, Jorge Fernandez Monteagudo wrote:
> I've found the src/southbridge/amd/pi/hudson/lpc.c, the related to the AMD Bettong demoboard, and
> 'lpc_acpi_name' and 'lpc_ops' are already defined... Maybe they are not enabled or used?
I guess it's used, but you need an acpi name for all devices along the
path. "LIBR" is the name for the LPC device, there should also be one
for the PCI bus/domain. I would try `src/northbridge/amd/pi/00660F01/