Re: [coreboot] T450S + Coreboot

[Youness Alaoui]

On Sat, Sep 8, 2018 at 2:31 PM Peter Stuge  wrote:
>
> Youness Alaoui wrote:
> > So, back to the ME, we know exactly what it does, it's all extremely
> > well documented and explained
>
> I disagree with this.
>
> It is absolutely true that *some* of what the ME does is extremely well
> documented and explained by the vendor, web services APIs and all, but
> I would argue that in fact *most* of what the ME does is *not* documented
> by the vendor, nor by independent research.
>
I mostly agree, I was referring to Mike's talk about the remote
control features, so yes, I should have said "AMT is well documented",
but yes, there are huge portions of what the ME itself does (such as
the power on sequence, or what/how it sets some registers) which are
totally undocumented.
So yes, even if we don't know exactly what the ME does during the
power sequence (among other things), we still know that "it
initializes hardware", we just don't know how it achieves that task.
So we know "what it does", but we don't know "exactly what it does"
and we don't know "how it does it", which is where I was wrong in my
previous statement.

However, we need to differentiate between "this ME is something
obscure that we have no idea what it's for" versus "we know what this
ME thing is supposed to be for or what it's supposed to be doing, we
just have no way to be sure that it doesn't do anything else or that
it does what it's supposed to".
I disagree with the idea that the ME is this black box, this sort of
"hidden spy device" that gives full remote capabilities to some
unknown entity in the same way that I would disagree that because MS
Windows is closed source that any Windows machine is fully
remote-controlled by M$ employees at any time or that the OS is
commissioned by the CIA or whatever. I do agree that because it's
closed source, we can't know whether it is or not, but it's just not a
guarantee that it is.


> Since the ME is colocated with the x86 VM host, has access to all x86 VM
> memory *and* is a proprietary machine or subsystem I actually don't
> believe that we will ever "know exactly what it does".
>
Well, we could know, if we reverse engineer its code from the maskrom
to the BUP, but yes, it would be very hard to fully know for certain.
Besides, I'd assume that anything malicious would probably be written
in silicon rather than in reverse-engineerable code. So I'd apply the
same idea to the whole PCH/CPU. The major problem with the ME when
compared to my previous comparison with MS Windows is that we can
chose Linux instead of Windows, but we can't choose to disable or to
use a custom ME firmware (i.e: the not-user-controlled issue).

>
> > Now the problem is that it's closed source, and not user controlled
>
> Right.
>
>
> //Peter
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Questions about using coreboot riscv with qemu

[Jonathan Neuschäfer]

On Mon, Sep 10, 2018 at 10:03:14AM -0400, Liam Naddell wrote:
> This is my first time using a mailing list btw, sorry.

Hi and welcome,

> 
> I was wondering how I could test the images I have built with `make
> riscv-crossgcc && make` using qemu.
> 
> 
> I tried running qemu-system-riscv64(the one gotten from the riscv-linux
> port), with the name of the image produced(coreboot.rom), and it did
> nothing.
> 
> qemu-system-riscv64 ./build/coreboot.rom
> 
> qemu-system-riscv64: Trying to execute code outside RAM or ROM at
> 0x

coreboot's support for qemu-system-riscv* is quite outdated, it would
probably need some work before it functions again.

Spike has seen more recent work, but SiFive's devboard (the HiFive
Unleashed) has seen the most recent work.

> I also tried this using the -bios flag, and by using the make-spike-elf
> script with the -bios flag, and I still got nothing.

Hmm, I'm not sure how QEMU is supposed to be invoked for RISC-V.



Jonathan Neuschäfer


signature.asc
Description: PGP signature
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] MRC saving for apollolake

[Antony AbeePrakash X V]

Hi,

We are developing coreboot for Apollo lake custom board.

We would like to reduce the boot time. For this,

  *   Enabled "MRC training data save" in FSP2_0 using Binary configuration 
tool.

But we are receiving the following logs:
NVM Write Failed. Update is lost. If repeatedly encountered, clear GPP4 and try 
again
Saved MRC training data with status (0x8007)

We would like to get clarification for the following:

  1.  Can we cache and save MRC training data for Apollo lake platform ?
  2.  Will it be done through CSE using HECI interface or through the SPI 
read/write operation in the NVRAM ?
  3.  Do we need to add Mrc.bin file with coreboot?  If yes, where can we get 
the same ?

Thanks & Regards,
Antony


L Technology Services Ltd

www.LntTechservices.com

This Email may contain confidential or privileged information for the intended 
recipient (s). If you are not the intended recipient, please do not use or 
disseminate the information, notify the sender and delete it from your system.
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] Questions about using coreboot riscv with qemu

[Liam Naddell]

This is my first time using a mailing list btw, sorry.


I was wondering how I could test the images I have built with `make 
riscv-crossgcc && make` using qemu.



I tried running qemu-system-riscv64(the one gotten from the riscv-linux 
port), with the name of the image produced(coreboot.rom), and it did 
nothing.


qemu-system-riscv64 ./build/coreboot.rom

qemu-system-riscv64: Trying to execute code outside RAM or ROM at 
0x

This usually means one of the following happened:
(1) You told QEMU to execute a kernel for the wrong machine type, and it 
crashed on startup (eg trying to run a raspberry pi kernel on a 
versatilepb QEMU machine)
(2) You didn't give QEMU a kernel or BIOS filename at all, and QEMU 
executed a ROM full of no-op instructions until it fell off the end

(3) Your guest kernel has a bug and crashed by jumping off into nowhere
This is almost always one of the first two, so check your command line 
and that you are using the right type of kernel for this machine.
If you think option (3) is likely then you can try debugging your guest 
with the -d debug options; in particular -d guest_errors will cause the 
log to include a dump of the guest register state at this point.

Execution cannot continue; stopping here.


I also tried this using the -bios flag, and by using the make-spike-elf 
script with the -bios flag, and I still got nothing.



It would be really nice if somebody could help me :).


--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Intel G41 - Asrock G41M-GS: no coreboot screen output from Intel GPU on VGA

[Angel Pons]

Hello h42,

I am porting a G41M-S3, which is pretty much the same thing but with DDR3
(heck, the component layout is pretty much the same too). I have the same
issue (libgfxinit fails) but I have not done anything about it yet.

Best regards,

Angel Pons
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Intel G41 - Asrock G41M-GS: no coreboot screen output from Intel GPU on VGA

[h42]

Would be great if someone could help to get libgfxinit working.

On 2018-09-01 21:13, h...@memeware.net wrote:

Cherry picking did not worked for me. I cloned coreboot today on an
new linux installation.
So i did additional:
$ cd 3rdparty/libgfxinit/
$ git checkout master
$ cd -
$ git add 3rdparty/libgfxinit/

Then i build the buildroot and the coreboot image.
I think i should have the patch (and some other things that was merged
in between) now inside the image. But i still dont have any seabios
output on the screen. I am using seabios master.

Then i tried out linear (high resolution) framebuffer.
I got that when building:
...
CC ramstage/drivers/intel/wifi/wifi.o
GCCramstage/drivers/intel/gma/hires_fb/gma.o
gma.adb:78:59: expected type "Interfaces.Integer_16"
gma.adb:78:59: found type "Interfaces.Integer_32"
gma.adb:79:59: expected type "Interfaces.Integer_16"
gma.adb:79:59: found type "Interfaces.Integer_32"
Makefile:338: recipe for target
'build/ramstage/drivers/intel/gma/hires_fb/gma.o' failed
make: *** [build/ramstage/drivers/intel/gma/hires_fb/gma.o] Error 1


On 2018-08-23 18:11, Nico Huber wrote:

Hello H42,

there is an issue with upscaling VGA text mode on G4x that is about to
be fixed [1]. Looking at your logs again, you are likely also affected
(scaling 640x400 to 1920x1080). The fix is already merged to the lib-
gfxinit repository, but the submodule pointer in coreboot is not 
updated

yet. You can try the fix as follows:

  $ cd 3rdparty/libgfxinit/
  $ git fetch https://review.coreboot.org/libgfxinit 
refs/changes/55/28255/3

  $ git cherry-pick FETCH_HEAD
  $ cd -
  $ git add 3rdparty/libgfxinit/

Then rebuild your coreboot.

Hope that fixes your issue. Another workaround would be to use a 
linear

framebuffer instead of text mode (CONFIG_GENERIC_LINEAR_FRAMEBUFFER).

Nico

[1] https://review.coreboot.org/28255


--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot