coreboot May 2017

coreboot@coreboot.org

70 participants
202 discussions

Re: [coreboot] 2017 North American coreboot Conference
by David Hendricks 30 May '17

30 May '17

On Thu, May 25, 2017 at 7:43 PM, Martin Roth <gaumless(a)gmail.com> wrote: > We're working with the SFC on billing. We'll be sending out emails to > all registered attendees next week with billing information. I received my invoice via e-mail earlier today, others should check their e-mail and contact Martin if they haven't received one yet. Thanks for getting this taken care of!

1 0

Re: [coreboot] DediProg EM100Pro with Apollo Lake
by Andrey Petrov 30 May '17

30 May '17

Hi, On 05/29/2017 06:29 AM, Urs Ritzmann wrote: > Are there any known quirks required to use the DediProg EM100-Pro flash emulator with Apollo Lake? The only quirk I know is that the emulated part must support SFDP. ROM boot code is very sensitive to SFDP and will halt if there no response to SFDP commands. Just adding --em100 worked for me. What does em100 in trace mode show? Andrey

2 1

DediProg EM100Pro with Apollo Lake
by Urs Ritzmann 29 May '17

29 May '17

Hi everyone Are there any known quirks required to use the DediProg EM100-Pro flash emulator with Apollo Lake? I'm trying to emulate a serial flash with the em100 for an Apollo Lake based SoC (Celeron J3355). It seems that Quad IO Reads (0xEB) do not properly work. I see too many bytes returned in the trace, somehow causing an offset. I used the ifdtool option --em100 to set the lowest possible bus frequency and disable Dual Output Fast Read. Is there a known bit in the firmware descriptor to disable Quad IO and Quad Output? Any available documentation about Intel's firmware descriptor? I used the original BIOS/UEFI firmware which works fine when flashed to a real N25Q128A11. Emulation of the same flash and firmware doesn't. Many thanks, Urs

1 0

Re: [coreboot] Some qustion about riscv implement
by Jonathan Neuschäfer 28 May '17

28 May '17

Hi, On Sat, May 27, 2017 at 06:06:33PM +0000, ron minnich wrote: > Thanks for your questions and for looking at the code. And welcome to coreboot! :-) > It's a new summer and I guess it's time for the riscv privilege model to > change again, as it has for the last two summers :-), which means coreboot > gets to change too. Indeed. > On Sat, May 27, 2017 at 2:42 AM 王翔 <merle(a)tya.email> wrote: > > > # Some qustion about riscv implement > > > > ## 1. SMP > > > > Coreboot for riscv does not support SMP, now. > > why does the secondary hart not halt in **src/arch/riscv/bootblock.S**? > > Now, secondary hart halts in **src/arch/riscv/trap_util.S**. > > This may affect playload implementation. I never tested the code on an SMP system or properly thought through supporting SMP, but I remember the following problem: I wanted to give each hart its own stack (IOW its own initial stack pointer value) to avoid race conditions, but I didn't have enough free registers to calculate it. So I gave up and only allowed hart 0 to do SBI calls. What I didn't think about is that I could *probably* use all registers that are defined as caller-saved by the user-level spec. ("probably" because I don't know if that's a valid thing to do. The Privileged Spec should specify which registers are saved by the M-mode code across SBI calls, and which aren't.) I guess it would make sense to catch those "other" harts in the bootblock, so even less unexpected stuff can happen, but eventually, this code needs to be reworked to deal with SMP in a more meaningful way: * Reject calls on non-first harts by returning an error, or * Use locks (ewww, firmware-induced jitter!), or * Reserve one stack per hart, calculate sp upon entry, run SBI calls in parallel and only lock what's necessary. The whole SBI call handling code needs to be updated to conform to the newest spec, of course. I briefly skimmed over the Privileged Spec 1.10 and it seem to have a clear definition of the SBI, though :( > To be honest, I don't know, Jonathan, do you? I have not looked at that > code in some time. I haven't, either, but until ECC2017 I plan to get up to speed with coreboot development again. > > ## 2. Privilege level for hypervisor > > > > Privilege level2 is Reserved In newest **rescv-privileged-v1.10.pdf**. > > According to the latest **rescv-privileged-v1.10.pdf**, the privilege > > level 2 is > > reserved. However, it appears in the source code. > > > > yes, this is a recent change with the removal of hypervisor mode. > > > > > > > > ## 3. Exception > > > > Both **supervisor_trap_entry** and **trap_entry** in > > **src/arch/riscv/trap_util.S** have similar functionality. The only > > difference > > is the latter halts the secondary hart. **supervisor_trap_entry** is > > unused The trap handling code needs to be cleaned up. As you noticed, it's currently not easy to understand. > > currently, what's the purpose of that? To be honest, I don't know what the exact purpose of supervisor_trap_entry was, because I haven't looked at the code in a while. > > The two restore context handlers **supervisor_call_return** > > **machine_call_return** in **src/arch/riscv/trap_util.S** are the same and > > they're in another section. Why not put these codes right after > > **supervisor_trap_entry**/**trap_entry** so there's no need to insert > > assembly > > codes in **src/arch/riscv/trap_handler.c**. I agree. I'd like to let the functions in trap_handler.c simply return and let the caller handle the details of switching back to lower privilege levels, etc. > We would welcome a patch so we could see what you'd like to change. > > > > > > > > > ## 4. CSR(mtime mtimecmp) > > > > Hart-local storage records the address of mtime/mtimecmp. However, I could > > not > > find information regarding CSR mapped to memory space in the latest > > document > > **rescv-privileged-v1.10.pdf**. > > > > That's weird, but this may be because mtime/mtimecmp are not really CSRs > any more, and hence are optional? That's right. Since the Privileged Spec 1.9 (I think), mtime and mtimecmp are not CSRs anymore, but confusingly they are still named like CSRs. > You used to use the config string to find these resources, but that is > possibly deprecated too. I don't know how to locate these resources at > present. There seems to be a move to the FDT, which is regrettable, but at > least it's not ACPI like ARM V8 :-) Honestly, with all these details that are still in motion, I'd like to have a SoC/board that implements *something* (and documents how it works). If we had such a board, we could at least port coreboot without having to guess the correct interpretation of half-written specs. :-\ Luckily riscv-linux is now being upstreamed so they will have to define a boot protocol (like https://www.kernel.org/doc/Documentation/arm/Booting: What goes into which register before the bootloader jumps into the kernel, etc). Back on topic: I wonder if we should just import libfdt when we need to parse or modify devicetree blobs. A quick check on the libfdt.a on my system (x86_64) shows that the set of .o files takes about 15kB, so it's not huge. > > ## 5. S/M Privilege level use same stack > > > > Function **riscvpayload** in **src/arch/riscv/payload.S** does not create > > a new > > stack for S privilege level. This may destroy the stack of M privilege > > level. > > > > > > > > > The M privilege level is not really a level in any normal sense, or at > least it was not. Supervisor level can examine and rewrite all of M memory. From what I've heard, M-mode code is supposed to be able to protect itself from rogue S-mode code, on processors that implement PMP ("Physical Memory Protection", see Priv Spec 1.10, chapter 3.6). > Also, we assume the payload will create its own stack if needed, as it > should. Finally, it makes no sense for M level to create a stack for S > level; this would imply the M level has knowledge of the S level activities > and that's just plain wrong. S level should always set up its own stack. > > Overall the M level / S level interactions had some real problems in the > earlier spec, and I'll have to look at the new spec to see what's changed. I'm not sure how SBI calls are supposed to work now (in 1.10 and later), but I *heard* they use plain ECALLs now, instead of the trampoline page. > Thank you for looking at this code and if you have changes to make we'd be > interested in seeing them. > > ron BTW, Ron, I think we should consider splitting the memory-resident part of coreboot on RISC-V into its own stage, similar to the SMM code on x86. That makes it easier to see what and how much of coreboot is actually available and active after boot. Jonathan

3 3

Some qustion about riscv implement
by 王翔 27 May '17

27 May '17

# Some qustion about riscv implement ## 1. SMP Coreboot for riscv does not support SMP, now. why does the secondary hart not halt in **src/arch/riscv/bootblock.S**? Now, secondary hart halts in **src/arch/riscv/trap_util.S**. This may affect playload implementation. ## 2. Privilege level for hypervisor Privilege level2 is Reserved In newest **rescv-privileged-v1.10.pdf**. According to the latest **rescv-privileged-v1.10.pdf**, the privilege level 2 is reserved. However, it appears in the source code. ## 3. Exception Both **supervisor_trap_entry** and **trap_entry** in **src/arch/riscv/trap_util.S** have similar functionality. The only difference is the latter halts the secondary hart. **supervisor_trap_entry** is unused currently, what's the purpose of that? The two restore context handlers **supervisor_call_return** **machine_call_return** in **src/arch/riscv/trap_util.S** are the same and they're in another section. Why not put these codes right after **supervisor_trap_entry**/**trap_entry** so there's no need to insert assembly codes in **src/arch/riscv/trap_handler.c**. ## 4. CSR(mtime mtimecmp) Hart-local storage records the address of mtime/mtimecmp. However, I could not find information regarding CSR mapped to memory space in the latest document **rescv-privileged-v1.10.pdf**. ## 5. S/M Privilege level use same stack Function **riscvpayload** in **src/arch/riscv/payload.S** does not create a new stack for S privilege level. This may destroy the stack of M privilege level. ------------------ 王翔安全研究员广州市腾御安信息科技有限公司广州市天河区珠江新城华穗路406号保利克洛维二期中景A座1020-1024

2 1

Lenovo G505S blob status?
by Taiidan＠gmx.com 27 May '17

27 May '17

Is it possible to init the graphics device without the radeon bios blob? such as with openradeonbios or with linux (you could do a petietboot solution to get graphics pre-OS) It has no PSP (or obvs ME) and its performance is about equal to a sandy bridge, so it seems like a great choice if you don't need the dock connector on a pro series thinkpad like the t430. AFAIK that version agesa is open source, at least I looked at it and didn't see anything weird but I am not an expert on this. - Thanks

2 1

Re: [coreboot] Blobless coreboot on Sandy Bridge and Ivy Bridge?
by Nico Huber 27 May '17

27 May '17

On 26.05.2017 22:34, Thomasheidler wrote: > Is it possible to find out which Sandy/Ivy board supports native > ram/graphics init before buying one of them? For example, is there some > list that shows compatibility? No list that I know about. But it can be seen from the source (e.g. to support the native raminit the board has to implement the functions in src/northbridge/intel/sandybridge/native_raminit.h). $ git grep -l mainboard_get_spd -- \ `git grep -l BRIDGE -- src/mainboard/*/*/Kconfig | xargs dirname` src/mainboard/apple/macbookair4_2/early_southbridge.c src/mainboard/gigabyte/ga-b75m-d3h/romstage.c src/mainboard/gigabyte/ga-b75m-d3v/romstage.c src/mainboard/google/butterfly/romstage.c src/mainboard/google/link/romstage.c src/mainboard/google/parrot/romstage.c src/mainboard/google/stout/romstage.c src/mainboard/intel/emeraldlake2/romstage.c src/mainboard/kontron/ktqm77/romstage.c src/mainboard/lenovo/l520/romstage.c src/mainboard/lenovo/s230u/romstage.c src/mainboard/lenovo/t420/romstage.c src/mainboard/lenovo/t420s/romstage.c src/mainboard/lenovo/t430/romstage.c src/mainboard/lenovo/t430s/romstage.c src/mainboard/lenovo/t520/romstage.c src/mainboard/lenovo/t530/romstage.c src/mainboard/lenovo/x1_carbon_gen1/romstage.c src/mainboard/lenovo/x220/romstage.c src/mainboard/lenovo/x230/romstage.c src/mainboard/roda/rv11/variants/rv11/romstage.c src/mainboard/roda/rv11/variants/rw11/romstage.c src/mainboard/samsung/lumpy/romstage.c src/mainboard/samsung/stumpy/romstage.c src/mainboard/sapphire/pureplatinumh61/romstage.c Native graphics init is supported for LVDS on all of these that have it through native C code. Libgfxinit, that's written in Ada, can initialize all ports. Though you might have to add a list of the ports and some configuration options (that's not done yet for all boards; if you want to try it, make sure you have `gnat` or `gcc-ada` matching your GCC installed before you build the coreboot toolchain). Nico

1 0

Re: [coreboot] Blobless coreboot on Sandy Bridge and Ivy Bridge?
by Taiidan＠gmx.com 26 May '17

26 May '17

On 05/26/2017 04:34 PM, Thomasheidler via coreboot wrote: > Is it possible to find out which Sandy/Ivy board supports native ram/graphics init before buying one of them? For example, is there some list that shows compatibility? > > Thomas AFAIK it is only the thinkpad series 2 (ala x220, t420 etc) and series 3 "ivy bridge" (ala x230, t430) etc. I believe you would be better off getting a lenovo G505S as it is newer and has no ME/PSP, its agesa is open source and you can probably init the gfx device with linux or openradeonbios (I don't think it supports native yet) The only reason not to is it lacks a dock connector - but it has way more I/O (ports) than a chromebook (I would never buy a CB as it lacks real I/O - it has no ethernet no expresscard and no dock connector) On 05/26/2017 03:35 PM, Thomasheidler via coreboot wrote: > If the FSP blob is needed, would that be the only blob required? An FSP version of coreboot is only a wrapper layer where coreboot doesn't init any hardware so I doubt one with that would be what you desire as everything important would be done via FSP/MRC, it isn't really better than a vendor bios all it does is move trust form the vendor to intel which is kind of a lateral move. Also keep in mind that a "cleaned" ME is not at all disabled or 100% safe in terms of security, we have no idea what the real technical capabilities of ME are as intel is incredibly evasive about this - even if you could somehow not include the ME blob and bypass the 30 minute shutdown defect it could still be loading mask rom etc and you'd have no real way to be sure short of physically removing it from the motherboard (they really should have made ME/PSP a removable module like a TPM)

1 0

Re: [coreboot] Blobless coreboot on Sandy Bridge and Ivy Bridge?
by Thomasheidler 26 May '17

26 May '17

Is it possible to find out which Sandy/Ivy board supports native ram/graphics init before buying one of them? For example, is there some list that shows compatibility? Thomas

1 0

Re: [coreboot] Blobless coreboot on Sandy Bridge and Ivy Bridge?
by Nico Huber 26 May '17

26 May '17

Hi, On 26.05.2017 21:35, Thomasheidler via coreboot wrote: > If one excludes any microcode and the VGA BIOS, is it possible to build if you use the integrated graphics, you don't need a VGA BIOS, there are replacement options. > a functioning, blobless coreboot for any Sandy Bridge or Ivy Bridge > device supported? It depends on each board. We have three versions of Sandy/Ivy Bridge: 1. the original with mrc.bin blob by Google, 2. a reverse engineered open source version and 3. one with FSP. Some boards support the former two, some only one of the three. Nico > I'm referring here only to the BIOS region on the > flash, not the ME region, IFD and GbE. If the FSP blob is needed, would > that be the only blob required? > > Thanks

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot May 2017