coreboot June 2018

coreboot@coreboot.org

40 participants
105 discussions

Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
by Peter Stuge 25 Jun '18

25 Jun '18

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. //Peter

3 2

Porting Kabylake laptop
by chrisglowaki＠tutanota.com 25 Jun '18

25 Jun '18

Hi 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? Chris

2 1

Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
by ron minnich 25 Jun '18

25 Jun '18

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 free :-( ron

1 0

Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
by Shawn 25 Jun '18

25 Jun '18

Hi Ron, 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. [1] Secure Processors Part I: Background, Taxonomy for Secure Enclaves and Intel SGX Architecture: https://people.csail.mit.edu/devadas/pubs/part_1.pdf [2] Secure Processors Part II: Intel SGX Security Analysis and MIT Sanctum Architecture: https://people.csail.mit.edu/devadas/pubs/part_2.pdf [3] Keystone: https://keystone-enclave.org/ -- GNU powered it... GPL protect it... God blessing it... regards Shawn

1 0

Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
by Taiidan＠gmx.com 25 Jun '18

25 Jun '18

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> > 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." >> >> > > 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.

4 9

Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
by Rudolf Marek 24 Jun '18

24 Jun '18

Hi Ron, 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 [1] 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 And, 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 Thanks Rudolf [1] https://www.sifive.com/products/hifive-unleashed/

1 0

Re: [coreboot] RV: Error booting with TPM enabled.
by Taiidan＠gmx.com 24 Jun '18

24 Jun '18

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/ >> northbridge.c`. > > > 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.

1 0

RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
by Taiidan＠gmx.com 23 Jun '18

23 Jun '18

https://www.phoronix.com/forums/forum/hardware/motherboards-chipsets/102117… 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!) 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? 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.

5 5

Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
by ron minnich 23 Jun '18

23 Jun '18

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 > (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. > > > > 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. > 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). > > > > A high-level list of tasks that FSBL performs is in the manual[1]: > > > > • 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... > > regards > Shawn > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] RV: Error booting with TPM enabled.
by Nico Huber 23 Jun '18

23 Jun '18

Hello Jorge, 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/ northbridge.c`. Nico

2 1

← Newer
1
2
3
4
5
6
7
...
11
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot June 2018