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!
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?
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.
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.
> 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
* 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
> > 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
> 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
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
> > ## 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.
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.
# 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
## 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.
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.
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
$ git grep -l mainboard_get_spd -- \
`git grep -l BRIDGE -- src/mainboard/*/*/Kconfig | xargs dirname`
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).
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?
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)
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
> 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.
> 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?