[coreboot] Re: OpenBSD won't install on an x220 Thinkpad with Coreboot

[Philipp Stanner]

I experienced problems with a non working ethernet interface on my x230.
The reason was that I accidentally touched the embedded controller
region. The EC participates in setting the ethernet interface up.

So if I were you I would check if I flashed the regions correctly.

The best way is to first only flash the BIOS region. If everything works
than you can try the ME region and so forth.
Flashrom has switches to explicitely only flash a certain region.

PS:
I got an 'undilivered mail return to sender' for the address:
Robert Milton 
Oô

Am Donnerstag, den 20.12.2018, 17:30 -0500 schrieb Robert Milton:
> I'm trying to get OpenBSD to install on an x220 Thinkpad with 
> Coreboot/SeaBIOS but I'm running into two problems: the ethernet
> device 
> doesn't work and OpenBSD doesn't detect my HDD. dmesg said em0
> wouldn't 
> load because the EEPROM had an invalid signature. I have no idea why 
> OpenBSD doesn't see my HDD though. It's strange because everything
> works 
> fine under Linux.  And I cannot seem to mount a usb drive under the 
> OpenBSD installer to attach dmesg errors.
> 
> I originally posted this as a bug report to bug report mailing list
> but 
> Theo said it would be better suited for Coreboot's and wasn't a bug
> in 
> OpenBSD.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: OpenBSD won't install on an x220 Thinkpad with Coreboot

[Philipp Stanner]

I experienced problems with a non working ethernet interface on my x230.
The reason was that I accidentally touched the embedded controller
region. The EC participates in setting the ethernet interface up.

So if I were you I would check if I flashed the regions correctly.

The best way is to first only flash the BIOS region. If everything works
than you can try the ME region and so forth.
Flashrom has switches to explicitely only flash a certain region.

Am Donnerstag, den 20.12.2018, 17:30 -0500 schrieb Robert Milton:
> I'm trying to get OpenBSD to install on an x220 Thinkpad with 
> Coreboot/SeaBIOS but I'm running into two problems: the ethernet
> device 
> doesn't work and OpenBSD doesn't detect my HDD. dmesg said em0
> wouldn't 
> load because the EEPROM had an invalid signature. I have no idea why 
> OpenBSD doesn't see my HDD though. It's strange because everything
> works 
> fine under Linux.  And I cannot seem to mount a usb drive under the 
> OpenBSD installer to attach dmesg errors.
> 
> I originally posted this as a bug report to bug report mailing list
> but 
> Theo said it would be better suited for Coreboot's and wasn't a bug
> in 
> OpenBSD.
> 
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: What are splitted / several flash ROMs about?

[Philipp Stanner]

Am Montag, den 16.09.2019, 07:20 -0700 schrieb Stefan Reinauer:
> Yes, this is often done as a cost reduction method. The habit started
> with the arrival of the ME and the firmware descriptor allowing you
> to spread your different firmware regions across one or both chips. 

Hm, surprises me. Normally, in technology one big thing is cheaper – a
large container ship instead of several small ones, one big hard drive
instead of two small ones. And in this case they need some hardware
mechanism concatenating the chips; this had to be developed first etc.
But hey, the manufacturer's ways are unpredictable ^^

> The tool ifdtool will help you analyze images for Intel firmware
> descriptors.
> Sounds like in this case ME and the other regions live in the larger
> chip, allowing the smaller chip to be fully used for system firmware.
> If that's the case, erasing the larger chip will brick your system.
> Better do some analysis first.

Ok, just to confirm:
I have to analyze which part of the firmware + ME lays where.
If the ME lays partly on the second chip (and I want to strip it), I
have to extract both images – and flash both chips again so that the
IME lays at the same offsets? I didn't fully understand how the flash
descriptors work so far.

If the ME lays on the first chip and coreboot fits into it with the
stripped ME, I could erase the second chip – but don't really have to,
because if there's no ME code on it, whatever lays there will not be
executed again after flashing?

P.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] What are splitted / several flash ROMs about?

[Philipp Stanner]

Hi folks,

Platforms like the x230 have two flash ROMs which are virtually treated
as a single one.

So:
   1. What the heck is the meaning of this? Why do vendors buy and solder
  two small chips (even worse, on the x230, one with 8M and one with
  4M) instead of a single big one? Is this cheaper? Sounds unlikely to
  me, in technics one big thing is usually cheaper than several small
  ones. Beyond that, I imagine you have some effort to concatenate the
  two chips virtually.
   2. The manual for the x230 [1] (is there a version in the new
  documentation btw?) states that you can just flash the smaller (4M)
  chip and then you're done. So I assume:
  1. the 4M chip is the one the CPU first executes code from
  2. neither coreboot nor the payload will ever jump "into" the larger
 chip, therefore code from it will not be executed.
  3. Therefore, it does not matter if you overwrite the 8M chip or
 not.

But what lays on this larger ROM? What if there are parts of the IME on
it I would like to annihilate?

The whole thing is really awkward to me. Especially, because the
predecessor x220 already has a place on the board ready to host the
second chip, but it was left empty on this device.

P.


[1] https://www.coreboot.org/Board:lenovo/x230

signature.asc
Description: This is a digitally signed message part
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Looking to hire Coreboot developer

[Philipp Stanner]

Am Donnerstag, den 27.06.2019, 11:55 +0200 schrieb Vinzenz Vietzke:
> maybe some of you have already seen it in common Linux online media.
> We are currently looking for Coreboot developers.

> More about this also at:
> https://www.tuxedocomputers.com/en/Infos/Jobs/Software-Developers-
> for-Coreboot-BIOS-m/f/d.tuxedo

Hi,

you guys work exclusively with x86-processors, am I right?

Can you give us some words about what you are trying to do with a
potential developer in the future with your Firmware? Getting (further)
rid of IME?

Philipp
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] IME: Alternatives for large companies?

[Philipp Stanner]

Recently I had an interesting discussion with a system administrator
who is responsible for several hundred PCs, Routers etc.

His argument was: Imagine it would take you 15 minutes to install a
patch on a computer (all windows machines of course...). If your
company has 1000 computers and you send one admin to install the
patches, it will take him >31 work days, working 8h a day.
That's why, he said, companies are interested in software allowing them
to install stuff on the OS / hard drive remotely through the firmware

I, not dealing with large networks, had never thought about it this
way. But it does make a lot of sense to me, it's about real money (as
usual).

So I guess that's indeed a huge reason why Intel and AMD created
Frankenstein, running below UEFI and Kernel. It probably doesn't
explain so much why it's necessary to disallow you switching IME off or
why it needs control about absolutely everything, but that's a
different story.

So I'm wondering: What would you do about this reality? Could there be
a different solution other than software in Ring -1 having its sausage
fingers on everything?
Sure, the programmers in a company could install their stuff on their
own, but the office folks, the HR and PR guys and the lawyers? Hmm.

And whether we like it or not, even awesome companies almost
exclusively supply their employees with windows machines and they just
demand solutions allowing their IT-departements to fix everything as
cheap and as easy as possible

P.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

Re: [coreboot] Matrix instead (or additionally to) IRC

[Philipp Stanner]

Am Sonntag, den 28.10.2018, 15:55 +0100 schrieb Luc Verhaegen:
> Ooh, bait, on a sunday afternoon with nothing better to do. I'll
> bite.
> 
> Matrix is not even 4 years old.
> 
> IRC has been good around for just over 3 decades. Many here have
> been 
> using it for more than 2 already. Yes, 2 decades. 20 years.
> 
> Chat/IM protocols come and go, IRC remains.
> 
> After this, someone will come along to suggest that we should all 
> switch to whatsapp.
> 
> Luc Verhaegen.
> 

Hey Luc,
just send me your number and I'm more than happy to open a Whatsapp
group – though IRC is a bit better than WA is ;D

Chat protocols come and go, alright, but the times change. 
Do you use Telnet to access your servers? Or is it SSH? IRC is not
encrypted. It does not support message formatting. It doesn't even
specify the text-encoding in the protocol. It may exist for 30 years,
but there is *a lot* to improve.

I think one should be open for new stuff without following every new
upcoming trend. And the choosing of a new system is a evolutionary
process, people try it and if they like it they stay.
Hey, why don't you try Matrix for a few days or weeks? Install a client
of your choice, join the Linux or another channel and look how it
works. You can even follow discussions on your smartphone while
standing in the subway for example. 

P.

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

Re: [coreboot] Matrix instead (or additionally to) IRC

[Philipp Stanner]

Am Sonntag, den 28.10.2018, 16:45 -0500 schrieb Timothy Pearson:
> More importantly, choose your own application.  There are so many
> good
> choices for desktop-side IRC clients at this point that almost
> certainly
> any older developers have already settled on one.  Forcing us to
> switch
> clients, or keep a browser tab open, will just shut down the real
> time
> channel and make Email seem like the most attractive option. ;-)

Well, which client would you especially recommend?

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

[coreboot] Matrix instead (or additionally to) IRC

[Philipp Stanner]

Hey,

have you guys already heard of Matrix?
https://matrix.org/blog/home/

It's some sort of modern IRC, using JSON to format messages. It's more
modern than IRC. Features are:
 * Source code formatting and highlighting in messages
 * multiple devices
 * history + history synchronization between multiple devices
 * possible E2C encryption

and many more.
In theory it will be a decentralized protocol, but there aren't that
many servers yet and actually only one working server-software

Many projects, especially tech-based ones like the Rust programming
language already use the service. 

Personally I think it's an enormous progress to IRC. I would give it a
chance if I were you :)

P.

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

Re: [coreboot] Source code for "Intel Firmware"

[Philipp Stanner]

Am Samstag, den 13.10.2018, 10:27 -0700 schrieb ron minnich:
> good summary. 
> 
> The most security critical code gets the least attention and no
> external security review. 
> 
> If this sounds crazy, well ... it is.

I honestly don't think that matters at all. Worrying about crappy BIOS
code while a real time surveilance tool like the IME is on the system
is like complaining about missing sweets on a sinking ocean liner.

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

Re: [coreboot] Source code for "Intel Firmware"

[Philipp Stanner]

Am Mittwoch, den 10.10.2018, 11:01 + schrieb Peter Stuge:
> We do however know what consequences said (firmware) architecture
> have
> for coreboot, both the good and the bad.

What's the good?

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

Re: [coreboot] Source code for "Intel Firmware"

[Philipp Stanner]

Hey Nico,

Am Sonntag, den 07.10.2018, 22:56 +0200 schrieb Nico Huber:
> At least since I'm working on the project it was always like this.
> And,
> IMHO, it is a good thing. The only decent x86 coreboot code I know
> was
> written when Intel didn't have their fingers in the pie.

Do the Intel engineers write bad code in your opinion? One would
believe that those who know their platform best and get paid to work on
it 8 hours a day produce nothing of bad quality… :|

> Minix runs on the Management Engine (ME). It's completely separate
> from
> the "BIOS".

My bad, I knew that actually. Some more madness. Sometimes it confuses
you when you find out that hell has several levels and hierarchies.

P.

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

Re: [coreboot] Source code for "Intel Firmware"

[Philipp Stanner]

Am Samstag, den 06.10.2018, 07:50 +0300 schrieb Zvi Vered:
> Currently, in order to replace vendor's BIOS we must take binary
> parts
> of the original bin file and then stitch it to coreboot.rom built
> with
> the coreboot project.

Well, exactly. Why do you think that is? Intel won't give you or anyone
that code. Their policy seems to be to hide as much source code as
possible.
I don't know why they contribute so much to the Linux Kernel, though…

> I want to depend only on Intel.

?
You do depend on Intel. You depend on them not doing awkward stuff on
their machines (what they clearly do, running Minix within the whole
"BIOS").

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

Re: [coreboot] Intel ME what is it? And when did this dangerous thing get installed?

[Philipp Stanner]

Am Mittwoch, den 29.08.2018, 04:09 -0400 schrieb Youness Alaoui:
> If there are more specific questions that you have, ask them and I
> might be able to answer them!

I might have one: What does stop a motherboard-vendor from just buying
a CPU and implementing it? Which chips, beside the CPU, do you need
from Intel in any case to make the machine work?
I always thought of the CPU just as a machine executing code, and
assumed it's possible to use it just as any microcontroller: You can
add the ME-Chipset, but you don't have to.

Philipp


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

Re: [coreboot] Seabios support in Coreboot

[Philipp Stanner]

You should include some more details:
 * Used Hardware
 * Configfile
 * Does anything happen when pressing ESC?
 * What does "is not installing OS" mean exactly?

Am Montag, den 09.07.2018, 20:06 +0530 schrieb Dhanasekar Jaganathan:
> Hi All,
> 
> After including Seabios as a primary bootloader in coreboot,  what
> are the
> other option, I suppose to set / enable in core boot menuconfig.
> 
> Because, Seabios is not installing OS from USB and I am unable to
> enter
> into seabios Boot menu (after pressing ESC).
> 
> Please help me on this.
> 
> 
> Thanks,
> Dhanasekar

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

Re: [coreboot] Atom c3000 Harcuvar and Intel ME

[Philipp Stanner]

Am Montag, den 26.02.2018, 17:14 -0300 schrieb Sumo:
> Hi,
> 
> In the coreboot build menu there is no option regarding the Intel ME
> integration.
> The 'coreboot.rom' file is the full SPI flash image or this file is
> suitable to
> replace the BIOS region of the SPI flash (0x0080--0x00ff)?
> (i.e. in the SPI flash we already have a region for Intel ME
> firmware)

I'm not sure what the question is. 

When configuring CB with menuconfig you have to select your platform
and type in the path to your ME-binary-blob. The later has to be
provided by you; meaning you have to extract the BIOS from the flash,
extract the ME-binary using coreboot/utils, clean it with ME-cleaner
(optional) and then build coreboot with your blob.

The toolchain takes care automatically about the correct placement of
the ME in the right address-ranges.

I hope this was helpful.

> Thanks,
> Sumo

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

Re: [coreboot] Coreboot Purism BIOS is free? open?

[Philipp Stanner]

I don't get it, too. ME has nothing to do with what you can do with your 
machine and what it can perform.

Even if 90% of users use their machine for multimedia purposes...


Am 24. Dezember 2017 14:02:41 MEZ schrieb eche...@free.fr:
>Yes Peter
>But what has Netflix (or Sony, or the entertainment industry in
>general...) to LEGALLY gain by strongarming Intel/AMD to keep ME/PSP
>activated on all x86 platforms (not only consumer ones!..)?
>(I can see other motivations.. but I keep the hypothesis that the
>entertainment industry has only morally acceptable principles in
>dealing with the cpu manufacturers..)
>No matter if the "user" (can we anymore speak about "owner"?..) intends
>to "watch Netflix in high resolution" or not al all?
>Excuse me but I insist : REALLY for >50% of the PC users nowadays the
>primary usage of their PC is to whatch Netflix (or play (legally..)
>acquired games)?.. I'm waiting for the stats..
> Florentin
>
>
>- Mail d'origine -
>De: Peter Stuge 
>À: coreboot@coreboot.org
>Envoyé: Sun, 24 Dec 2017 00:00:03 +0100 (CET)
>Objet: Re: [coreboot] Coreboot Purism BIOS is free? open?
>
>Ivan Ivanov wrote:
>> Could it be the requirement of US Government - for all the consumer
>> CPU to have backdoors ?
>
>I guess that the private sector is a much stronger force...
>
>
>Nico Huber wrote:
>> watch Netflix in high resolution
>
>
>//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

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] anyone know what happened here?

[Philipp Stanner]

Am Freitag, den 22.12.2017, 15:31 +0100 schrieb Nico Huber:
> Hi Zoran,
> 
> please stop sending HTML emails. Your mails are often very hard to
> view. Especially the quotations are completely messed up by your MUA
> when you play with the font settings.

Afaik it's possible to configure mail-servers so they automatically
reject HTML-Mails or transcode them to txt.
Beside that you often can configure it so it doesn't send E-Mails to
people who're subscribed to the list, if they're also in CC.

Maybe reconfiguring coreboot's mailserver would be a good idea :)
My 2 ct.

Philipp

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

Re: [coreboot] Disabling Intel ME 11 via undocumented mode

[Philipp Stanner]

Thanks.

They didn't seriously include a Java Runtime Environment into the IME??
I can't believe what's going on with this company.

Am Freitag, den 08.12.2017, 16:16 +0100 schrieb Thomas Heijligen:
> For those who are interested in the Intel ME, the slides and white 
> papers
> from the Black Hat Europe are public.
> 
> https://www.blackhat.com/docs/eu-17/materials/eu-17-Goryachy-How-To-H
> ack-A-Turned-Off-Computer-Or-Running-Unsigned-Code-In-Intel-
> Management-Engine.pdf
> https://www.blackhat.com/docs/eu-17/materials/eu-17-Goryachy-How-To-H
> ack-A-Turned-Off-Computer-Or-Running-Unsigned-Code-In-Intel-
> Management-Engine-wp.pdf
> https://www.blackhat.com/docs/eu-17/materials/eu-17-Sklyarov-Intel-ME
> -Flash-File-System-Explained.pdf
> https://www.blackhat.com/docs/eu-17/materials/eu-17-Sklyarov-Intel-ME
> -Flash-File-System-Explained-wp.pdf
> 
> In the conclusion they say "[...]. Such a vulnerability has  the  
> potential  to
> jeopardize a number  of  technologies,  including [...] Intel Boot
> Guard 
> [...].
> 
> Maybe it's possible to deactivate Boot Guard permanently or inject 
> custom
> keys to run own firmware.
> 
> 
> On 08.12.2017 15:40, Alberto Bursi wrote:
> > On 12/08/2017 02:59 PM, Timothy Pearson wrote:
> > > 
> > > That's just the HAP bit.  The ME is limited but NOT disabled, and
> > > the
> > > remaining stubs are still hackable [1].
> > > 
> > > Neither the ME or the PSP can ever be removed from their
> > > respective
> > > systems.  They can both be limited to some extent, but to call
> > > either 
> > > of
> > > them "disabled" is rather far from the truth.
> > > 
> > > 
> > 
> > Hacking them requires being able to write in the SPI flash, or to
> > have
> > buggy UEFI firmware. Which means most systems are still vulnerable.
> > 
> > But it is also true that if someone can hack UEFI he pwns you
> > anyway,
> > even without ME.
> > 
> > So imho ME with the HAP bit can be called "disabled", although the 
> > fight
> > isn't over as ME isn't the only thing that was a threat anyway.
> > 
> > There is still need to secure the UEFI firmware (which is needed
> > even 
> > if
> > ME didn't exist), and doing a hardware mod to have a hardware
> > switch to
> > turn the SPI chip read-only at the hardware level (also needed
> > regardless of ME).
> > 
> > I think many SPI chips only need some pin pulled high/low to go in
> > read-only mode, and I frankly trust a dumb switch many orders of
> > magnitude more than Boot Guard or anything software-based.
> > 
> > -Alberto
> 
> 

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

Re: [coreboot] Where do we stand for Thinkpad X230 Tablet?

[Philipp Stanner]

> So, where do we stand on support for UEFI (Tianocore?)

Hmm, what does UEFI have to do with it?

> Can I use the same build for both X230 and X230T? What else
> would I miss?

AFAIK the Tablet doesn't need firmware-initialization. At least Vitali
Serbinenko mentioned [1] that the builds for X220 und X220T are
identical. I highly presume that it's the same with 230.

> Except the wifi whitelist, my X230T has been better than all my
> previous laptops.

I know how you feel. These machines are great. Have you tried flashing
cb before? There are lots of suitable machines on ebay.

Philipp

[1] https://www.youtube.com/watch?v=HQtjXgNLl7k

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

Re: [coreboot] Random Shutdown on Thinkpad X220

[Philipp Stanner]

Am Sonntag, den 29.10.2017, 23:28 +0800 schrieb Tom Li via coreboot:
> Do you ever encountered a problem like this? What is your suggestion
> for me
> to try before replacing the motherboard?
> 
> Cheers,
> Tom Li


Just to be absolutely sure:
Did you make sure the Intel ME is in place and undamaged? It is known
that modern computers shut down when the ME is touched.
This should happen after a certain time, though (30 min ?), and it
shouldn't occur randomely like in your case.

Still, if you changed the IME I'd try reflashing an image with an
untouched ME and test the machine.

P.

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Coreboot+SeaBios Boot speed: ~12sec till Grub Boot Screen

[Philipp Stanner]

Am Montag, den 25.09.2017, 09:17 +0200 schrieb Paul Menzel:
> First, please just sent plain text messages to mailing lists.

Afaik list-servers can be configured to filter HTML. Doesn't the cb-
Server implement this on purpose?

P.

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [kernel-hardening] ME and PSP

[Philipp Stanner]

Am Donnerstag, den 07.09.2017, 04:30 + schrieb ron minnich:
> 
> very closed system with RISCV very easily. RISCV doesn't magically
> take
> away ME- and PSP-like problems.

But it will magically take away microcode and maybe compatibility-modes 
– what will already be a progress. Both in slimming down the
architecture and getting rid of security and privacy threats. The
Usenix this year presented an interesting exploit [1].

P.

[1] http://syssec.rub.de/media/emma/veroeffentlichungen/2017/08/16/usen
ix17-microcode.pdf


signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] About Paging, Realmode and what is going on

[Philipp Stanner]

Am Montag, den 04.09.2017, 20:15 + schrieb Peter Stuge:
>  legacy
> tables such as ACPI

ACPI is a open standard, isn't it?

> 
> The payload directly reads the filesystem from disk, no boot sector
> is used.

Indeed. So a payload built for cb won't try to call BIOS. And if
something after it tries it said payload should have implemented the
calls.

> coreboot with its payloads offers significant advantages over legacy
> BIOS and stillborn UEFI architectures.

C and open source is great. Though it frustrates me a bit that people
did all this work – and here we are again, still implementing BIOS-
Interrupts and all this old stuff. If it would compile on my machine I
would prefer a tiny loader like FILO.
The awkward thing about BIOS is that it was a second OS from the first
day on – while the reasonable philosophy behind firmware should be:
Start the board, load the OS and go back into your flash until reboot.

P.

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

Re: [coreboot] About Paging, Realmode and what is going on

[Philipp Stanner]

Thanks so far. Very interesting.

Am Montag, den 04.09.2017, 07:28 + schrieb Peter Stuge:
> 
> coreboot itself can only start one payload, but SeaBIOS allows the
> user to choose which of those payloads to start, in which case a
> payload *does* have interrupt services available.
> 
> Just to let you know that this is possible.
> 

> There is no "32-bit instruction set". The instruction set is the
> same,
> there is no difference in what opcodes could be used (well except
> maybe
> gdt and idt stuff) but *addressing* is obviously different in 32-bit
> mode,
> and using 32-bit addressing makes everything a lot easier.
> 

If there is no difference according the instruction set and as coreboot
itself doesn't provide BIOS-services: Why don't we just switch the CPU
to flat protected mode, do our duty and jump into the payload (SeaBIOS
mainly) which then switches back to real mode if necessary, change the
GDT or do whatever it needs to do?
Switching back to Real Mode, using 32-Bit-addresses (what sounds like a
hack to me. I can't imagine Intel intended this) is much more
complicated than staying in PM, isn't it?

x86 is pain. Sometimes I wonder why it even works at all. Let's hope
there will be RISC-V-Boards one day.

P.

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

Re: [coreboot] About Paging, Realmode and what is going on

[Philipp Stanner]

Am Samstag, den 02.09.2017, 12:36 + schrieb Peter Stuge:
> 
> Sure, but a payload can. SeaBIOS aims to provide a complete BIOS with
> all neccessary interrupt services for legacy compatibility.

Once coreboot jumped into SeaBIOS-code the latter is responsible for
providing the right interface for interrupt services.

I guess it doesn't matter very much in the end who switches the CPU to
Real Mode. My point is that coreboot's bios calls can't be called
because they don't exist ^^



> 
> That depends. A *payload* can not assume interrupt services, but a
> bootloader (e.g. in MBR) can very well assume interrupt services, 
> especially since MBR is a BIOS paradigm.

Every payload built for and with coreboot won't try to call interrupts.

> 
> > And you can't use the 32-Bit-Instructionset anymore, can you?
> 
> That's orthogonal. You can use 32-bit instructions in 16-bit mode and
> vice versa. The 0x66 and 0x67 opcode prefixes can be used to set an
> instruction mode for a single instruction.

But in the beginning of this thread on 02 Aug Ron Minnich wrote that
coreboot switches to PM, because: 

"And we want the 32-bit instruction set."

P.

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

Re: [coreboot] INT 13, real mode, block write commands and coreboot

[Philipp Stanner]

Hi,

Don't worry, x86 is hard to understand IMO. I often feel like an
archaeologist when trying to understand it.

Am Sonntag, den 03.09.2017, 00:32 +0200 schrieb
ingegneriafore...@alice.it:
> is there a way to disable this BIOS function? More precisely,
> coreboot can be set to avoid receiving commands from GRUB and Ubuntu
> KERNEL?

cb itself can't receive commands from the OS. The payload, especially
SeaBIOS can through interrupts. Choosing a payload which only starts
the Kernel (FILO) should make it impossible for the OS to call BIOS-
code.

Of course modern boards still have the Management-engine which can do
anything behind the OS.

P.

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

Re: [coreboot] About Paging, Realmode and what is going on

[Philipp Stanner]

Am Donnerstag, den 03.08.2017, 12:48 + schrieb Peter Stuge:
> Philipp Stanner wrote:
> > Why would I want to address memory in RM with 32 Bits? I don't see
> > any difference to using PM without Paging enabled.
> 
> In a bootloader (after coreboot) you often want to call BIOS
> interrupt services which assume real mode, because that was the
> only mode, when the interrupt services were created.
> 
> For coreboot itself, I think there is little if any advantage to big
> real mode.
> 
> 
> //Peter

Wait. Coreboot doesn't implement BIOS-Interrupt-Services.
So no payload started by cb should ever try to call BIOS, should it?

And you can't use the 32-Bit-Instructionset anymore, can you?

P.

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

Re: [coreboot] REPLY: INT 13H

[Philipp Stanner]

On 30.08.2017 14:54, Peter Stuge wrote:

Compatibility is the only actual value of x86.

Hi,
I was often wondering why they don't at least try to get rid of the 
*very* old stuff when it's not possible to get rid of the middle-old stuff.


It's understandable that it's necessary to provide a 
32-bit-compatibility mode on 64-bit systems. It *was* understandable 
that it  was necessary to provide a 16-bit-compatbility-mode then the 
first 32-bit-CPUs appeared. As far as I understood the Intel 
Programmer's Manual the CPUs provide a 16-bit compatibility-mode in 
64-bit-long-mode...


I don't see a reason why it should be impossible to abolish Real Mode, 
Segmentation and basically everything beside Long-Mode and virtual 32 
Bit-mode.
The Operating-System-Manufactures would need a bit of time to change 
their operating systems to be able to start without BIOS calls and 
remove the procedures to set up the flat segmentation.


Intel is powerful enough to make this change I believe. The question is 
if they benefit from changing x86, making it more modern.


By the way we shouldn't forget that behind the 
legacy-compatibility-stuff and the microcode a very strong, efficient 
and modern RISC-machine is alive.


P.

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

Re: [coreboot] Disabling Intel ME 11 via undocumented mode

[Philipp Stanner]

Am 29.08.2017 um 20:15 schrieb Timothy Pearson:
> On 08/29/2017 06:10 AM, Rene Shuster wrote:
> > Wow.
>
> My favorite part is where the NSA itself basically admits that the ME
> can't be trusted!  I wonder if they are looking at other architectures
> or if this HAP bit was enough for their needs?
>

By the way: Do AMD-boards have a similar mechanism of evil?



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

Re: [coreboot] Making coreboot more accessible to end-users - ideas?

[Philipp Stanner]

Am 07.08.2017 um 23:50 schrieb taii...@gmx.com:


How can the end-user documentation be improved?


Hey. Great that you're interested in this special task.

For me as a non-contributing user much trouble occurs when trying to 
build anything beside SeaBIOS (Grub and FILO especially). Maybe a little 
tutorial about building these payloads would be cool. Especially the 
FILO docu is a bit thin. How do you configure it? What would be the main 
advantages over GRUB? etc.


What advantages are you looking for in a system that has open source 
(including init) firmware?
(Me - freedom, repair-ability and semi-obscure features like IOMMU 
that actually work and can be easily fixed if they don't)


Personally I'm a great fan of technological efficiency in all my 
devices. I hate unnecessary crap laying around. When learning about x86 
I always hated the fact that there's so much useless old stuff, that 
there's a BIOS and therefore some kind of second OS on a system while 
you actually only need one. That's why I like coreboot: Start the main 
board, give control to the OS and then be a nice firmware and go back to 
your flash-rom ;)
I'm not as concerned about security and freedom as most of the other 
people probably. Unnecessary madness like the Intel Management Engine 
creeps me out a little bit, though.


P.

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

Re: [coreboot] Lenovo X220t variants with SMD-Flash-ROMs

[Philipp Stanner]

Do we have any idea what exactly they do to update the firmware internally?

The wiki says once coreboot is flashed you can flash it internally. I
suppose this means the blockade protecting the flash can be switched of
somehow, as the vendor's have to do it to install firmware-updates.


Am 05.08.2017 um 21:12 schrieb Igor Skochinsky via coreboot:
> Hello Philipp,
>
> Saturday, August 5, 2017, 8:41:42 PM, you wrote:
>
> PS> Yes, you're probably right.
>
> PS> Though I wonder when and how they programmed the firmware. Before or
> PS> after soldering?
>
> Most likely before, unless they have some debug header exposed. From
> [1]:
>
>> When the hardware and software nears production readiness, it is
>> common practice to preprogram flash memory devices prior to
>> starting high-volume PCB manufacturing flows for two principal
>> reasons. First, firmware loaded onto the device can be used to
>> perform basic booting and testing of the PCB during manufacturing
>> to check system/module functionality. Second, loading the final
>> firmware, operating system (OS), and application code on the flash
>> device prior to manufacturing maintains a high-volume
>> manufacturing beat rate. To support these usage models, multiple
>> vendors provide systems for loading firmware and data into flash
>> memory devices prior to the PCB solder flow process.
> Modern flash chips don't have issues retaining programmed bits during reflow
> soldering as long as the correct temperature profile is observed [2].
>
> [1]: 
> http://www.electronicdesign.com/memory/understanding-onboard-flash-programming
> [2]: http://dataioinfo.com/LiveImages/26/20/DocumentURL.pdf
>
>
>


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

Re: [coreboot] Lenovo X220t variants with SMD-Flash-ROMs

[Philipp Stanner]

Yes, you're probably right.

Though I wonder when and how they programmed the firmware. Before or
after soldering?


Am 05.08.2017 um 19:41 schrieb Igor Skochinsky via coreboot:
> Hello Philipp,
>
> Saturday, August 5, 2017, 6:01:04 PM, you wrote:
> PS> PS: Rantmode: Why the hell don't they just solder a socket? It's not
> PS> that unrealistic that someone bricks the BIOS while updating the
> PS> firmware from time to time. Being able to replace the ROM with a fresh
> PS> one is a huge plus.
>
> A socket would add some cost; not just of the part itself but
> also cost of the assembly process since flash chip could not be soldered
> together with the rest of the components now, and possibly other
> logistical issues (e.g. they would have to order DIP chips
> specifically for this model instead of SMD parts like for everything
> else).
> It would also increase the height of the board, and you know how
> everyone is obsessed with thin laptops nowadays. 
>
> Just because it would be convenient for maybe ten people in the world
> doesn't make it an incentive for the manufacturers. 
>
> Besides, 99.9% users are not expected to ever open their device, let alone 
> mess
> with the chips. If they get a brick (which is a pretty rare thing
> nowadays AFAIK), they send it off for repairs.
>


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

Re: [coreboot] About Paging, Realmode and what is going on

[Philipp Stanner]

Dear Patrick, dear Zoran & List,

thank you, this was *very* helpful. I had some misunderstandings
regarding function and features of the CPU-modes.

Let me sum it up again and feel free to correct further mistakes.

  * 16-Bit-Real Mode: No virtual memory, no segmentation. 2^20 addresses
of memory.
  * Protected Mode (flat mode?): CPU is in Protected Mode, Paging is
off. The primary difference to Real Mode is that 2^32 Bytes of
memory are available. Coreboot + Payloads use this mode, because
they need >1MiB of memory due to various reasons
  * Virtual Mode: Paging is on, the MMU is on. Memory can only be
accessed by using virtual addresses. Details are specified in the GDT.
  * Long Mode: Paged virtual 64-Bit mode. Standard mode of modern
operating systems (while I presume Protected Virtual Mode is the
Standard for any OS on i386)


Am 02.08.2017 um 18:20 schrieb Zoran Stojsavljevic:
>
>
> [4] Once the OS boot loader takes over (Like GRUB), it'll start OS,
> which will switch from the Protected to the Virtual Mode (using MMU),
> Then paging will take places, and each process will have its own set
> of tables, and its own initial value for CR3 (when process context
> switches). I warmly suggest to you to inspect (bit by bit) CR1
> register, since this one is crucial/essential for introducing these modes.
Thanks, I will do that. I intend to play around with QEMU and maybe have
a closer look to Intel's Programmer Manuals.

But I hope at least one assumption is right: Once coreboot jumped into
the payload no coreboot-code will be executed anymore. And once the
payload jumped into Linux no payload-code will be executed anymore?
Meaning the payload takes complete control over RAM and CPU.

Traditional BIOS (so I very much expect SeaBIOS to do the same) stays
somewhere within the 16-bit-address-space, even when Windows or Linux
are running, with it's Interrupt Service Rutines ready to do stuff.

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

Re: [coreboot] About Paging, Realmode and what is going on

[Philipp Stanner]

On 01.08.2017 16:49, Peter Stuge wrote:


Note that PM != paging. Neither coreboot nor proprietary BIOS
products used paging traditionally. Ron pushed for paging, there was
a bit of support. I don't know the current situation though.

Also note that PM != "flat real mode" or "32-bit real mode", it's not
really documented as a feature, so I don't know if it has an official
name.

What you do is prepare a GDT with most or all entries having base 0
size 4GB, then enable PM in CR0, ldgdt, set at least cs and ds
(usually more) to the 4GB GDT selectors, then disable PM in CR0 -
*and do not reload cs, ds and other selectors/segment registers*
once back in RM. This then allows 32-bit memory access in RM on 386 up.

Why would I want to address memory in RM with 32 Bits? I don't see any 
difference to using PM without Paging enabled.


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

Re: [coreboot] About Paging, Realmode and what is going on

[Philipp Stanner]

Well, many thanks.

I didn't expect it to work that way. Would be interesting to know what 
Windows 7 needs BIOS calls for.


Any idea of traditional IBM-PC-Bios-calls are still available in 
UEFI-Firmware?



On 31.07.2017 11:43, Patrick Georgi via coreboot wrote:

2017-07-31 10:52 GMT+02:00 Philipp Stanner <stan...@posteo.de>:

1. cb switches the CPU immediately to Protected Mode, yet Payloads like seaBIOS 
work in Real Mode. Does coreboot switch the CPU always back to RM before 
jumping to the payload?

No, payloads are started in pmode.


2. When CB switches to PM - who generates and administrates the Page Tables and 
where?

We use flat mode: 4gb segments starting at 0, for code and data.
Virtual address == logical address == physical address


3. Gustavo Duarte writes that GRUB switches from protected mode to real mode and 
vice versa all the time to address >1MiB of RAM and also use the BIOS-calls. If 
this is true using GRUB as payload would not work, as GRUB needs to call the 
non-existent BIOS, right?

It uses BIOS calls, except when built for coreboot.


4. Once CB is in PM it can't access physical addresses anymore? It doesn't need 
to, too?

We use flat mode, see above.


5. PM means RAM-access is only possible through virtual addresses which are 
translated by the MMU using the Page Tables. This question is similar to [2.]: 
If coreboot generates the Page Tables and the payload would start in PM as well 
(is this even possible? At least the Linux-Kernel has entry points for RM and 
PM) this would mean the payload needs to use the Page Tables generated by CB. 
That wouldn't be a problem as they're linked in the register CR3 anyways?

As stated above, payloads start in pmode. As stated above, we use a
flat representation which comes with no surprises. The payload can
then reconfigure the system to setup its own configuration.


Why does every modern CPU still start in RM? I do get the compatibility 
problem, but on the other hand: Do you need it for anything beside booting 
MS-DOS on your Ryzen? Is it really impossible for AMD and Intel to create a new 
CPU-generation with the x86-instruction set without RM, 16-bit-registers and 
20-bit-mode registers like CS, SS etc. No modern OS uses bios calls. No CPU is 
ever switched to RM again after booting up. They should get rid of this old 
stuff.

"Every modern x86 CPU". In the end, that's something to ask the CPU
vendors (but don't expect any answers). Some guesses:

1. Windows 7 uses BIOS calls (although they stopped switching back to
real mode for that, they use x86 16bit emulation. still, BIOS services
need to be there)
2. CPUs might not be switched back to real mode today, but from 32bit
modes it's a pretty short route to vm86 modes, which are effectively
identical to real mode and still in use.
3. Why change a working system and risk compatibility issues? x86's
biggest selling point is compatibility, and if you forfeit that, users
may move off your architecture entirely.


Regards,
Patrick



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

[coreboot] About Paging, Realmode and what is going on

[Philipp Stanner]

Dear folks and techpriests,

the more I want to contribute and learn about low-level-code the less I 
understand, it seems.


1. cb switches the CPU immediately to Protected Mode, yet Payloads like
   seaBIOS work in Real Mode. Does coreboot switch the CPU always back
   to RM before jumping to the payload?
2. When CB switches to PM - who generates and administrates the Page
   Tables and where?
3. Gustavo Duarte writes
    that
   GRUB switches from protected mode to real mode and vice versa all
   the time to address >1MiB of RAM and also use the BIOS-calls. If
   this is true using GRUB as payload would not work, as GRUB needs to
   call the non-existent BIOS, right?
4. Once CB is in PM it can't access physical addresses anymore? It
   doesn't need to, too?
5. PM means RAM-access is only possible through virtual addresses which
   are translated by the MMU using the Page Tables. This question is
   similar to [2.]: If coreboot generates the Page Tables and the
   payload would start in PM as well (is this even possible? At least
   the Linux-Kernel has entry points for RM and PM) this would mean the
   payload needs to use the Page Tables generated by CB. That wouldn't
   be a problem as they're linked in the register CR3 anyways?

And an unimportant bonus question:

 * Why does every modern CPU still start in RM? I do get the
   compatibility problem, but on the other hand: Do you need it for
   anything beside booting MS-DOS on your Ryzen? Is it really
   impossible for AMD and Intel to create a new CPU-generation with the
   x86-instruction set without RM, 16-bit-registers and 20-bit-mode
   registers like CS, SS etc. No modern OS uses bios calls. No CPU is
   ever switched to RM again after booting up. They should get rid of
   this old stuff.

Would be cool if someone could put this in its true light.

Thanks,

Philipp

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

Re: [coreboot] Is Coreboot architecture dipendent ?

[Philipp Stanner]

Dear Vincenco,

coreboot is extremely architecture dependent. It's hardcore low-level
code, maybe lower than the Operating System (or Windows) itself.

You can configure the makefile for your platform using menuconfig or
kconfig. De facto Lenovo's thinkpads are the only customer-IT-devices
which are supported very well.

Regards,

Philipp


Am 23.07.2017 um 18:01 schrieb ingegneriafore...@alice.it:
> Hello everybody,
>
> It's the time for me to install Coreboot on one of my machine. It
> seems a very big design !
>
> Please, can you tell me if Coreboot is motherboard architecture
> dependent or simply I can download it, compile and flash the .rom file
> in the Bios chip ?
>
> I will do the first test on a PC with motherboard: MSI MS-7168 ver. 1C
> mounting an AMD Athlon 64 Processor.
>
> Is it necessary I compile Coreboot on the PC where I want to install it ?
>
> Is Coreboot RAM dependent ? That is, can I start-up the PC with only
> the Processor and the BIOS chip, without RAM and hard-disk ?
>
> Thanks in advance.
>
> I hope to hear you soon.
>
> Best Regards.
>
> Vincenzo.
>
> Forensic Consultant
> Tribunale di Lecce
>
> Studio: Strada di Garibaldi - Contrada Paradisi
> 73010 Lequile (LE)
>
> cell: 339.7968555
> skype: vincenzo.di_salvo
>
>



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

[coreboot] Can't build cb+grub2

[Philipp Stanner]

hi,

I can build cb+FILO and cb+seaBIOS, but I can't build it with grub (what 
would be my favorite payload as I don't need bios calls and don't want 
to flash an entire kernel).


I'll attach the build-protocol. Any ideas what the problem is?

Philipp

CC bootblock/arch/x86/bootblock_romcc.o
FMAP   build/util/cbfstool/fmaptool -h build/fmap_config.h 
build/fmap.fmd build/fmap.fmap
COREBOOT
CC ramstage/superio/common/conf_mode.o
CC romstage/southbridge/intel/common/gpio.o
CC ramstage/southbridge/intel/common/gpio.o
CC ramstage/southbridge/intel/common/pciehp.o
CC ramstage/southbridge/intel/common/spi.o
CC ramstage/southbridge/intel/bd82x6x/azalia.o
CC ramstage/southbridge/intel/bd82x6x/lpc.o
CC ramstage/southbridge/intel/bd82x6x/madt.o
CC ramstage/southbridge/intel/bd82x6x/me.o
CC ramstage/southbridge/intel/bd82x6x/me_8.x.o
CC ramstage/southbridge/intel/bd82x6x/me_status.o
CC ramstage/southbridge/intel/bd82x6x/pch.o
CC ramstage/southbridge/intel/bd82x6x/pci.o
CC ramstage/southbridge/intel/bd82x6x/pcie.o
CC ramstage/southbridge/intel/bd82x6x/reset.o
CC ramstage/southbridge/intel/bd82x6x/sata.o
CC ramstage/southbridge/intel/bd82x6x/smbus.o
CC ramstage/southbridge/intel/bd82x6x/smi.o
CC ramstage/southbridge/intel/bd82x6x/usb_ehci.o
CC ramstage/southbridge/intel/bd82x6x/usb_xhci.o
CC ramstage/southbridge/intel/bd82x6x/watchdog.o
CC ramstage/northbridge/intel/sandybridge/acpi.o
CC ramstage/northbridge/intel/sandybridge/gma.o
CC ramstage/northbridge/intel/sandybridge/gma_sandybridge_lvds.o
CC ramstage/northbridge/intel/sandybridge/gma_ivybridge_lvds.o
CC ramstage/northbridge/intel/sandybridge/northbridge.o
CC ramstage/northbridge/intel/sandybridge/ram_calc.o
CC ramstage/northbridge/intel/common/mrc_cache.o
CC ramstage/mainboard/lenovo/x220/acpi_tables.o
CC ramstage/mainboard/lenovo/x220/hda_verb.o
CC ramstage/mainboard/lenovo/x220/mainboard.o
CC ramstage/lib/b64_decode.o
CC ramstage/lib/boot_device.o
CC ramstage/lib/bootmem.o
CC ramstage/lib/bootmode.o
CC ramstage/lib/cbmem_common.o
CC ramstage/lib/cbmem_console.o
CC ramstage/lib/cbmem_stage_cache.o
CC ramstage/lib/compute_ip_checksum.o
CC ramstage/lib/coreboot_table.o
CC ramstage/lib/delay.o
CC ramstage/lib/edid.o
CC ramstage/lib/fallback_boot.o
CC ramstage/lib/gcc.o
CC ramstage/lib/halt.o
CC ramstage/lib/hardwaremain.o
CC ramstage/lib/hexdump.o
CC ramstage/lib/hexstrtobin.o
CC ramstage/lib/imd.o
CC ramstage/lib/imd_cbmem.o
CC ramstage/lib/lzma.o
CC ramstage/lib/lzmadecode.o
CC ramstage/lib/malloc.o
CC ramstage/lib/memchr.o
CC ramstage/lib/memcmp.o
CC ramstage/lib/memrange.o
CC ramstage/lib/prog_loaders.o
CC ramstage/lib/prog_ops.o
CC ramstage/lib/region_file.o
CC ramstage/lib/rmodule.o
CC ramstage/lib/romstage_handoff.o
CC ramstage/lib/romstage_stack.o
CC ramstage/lib/rtc.o
CC ramstage/lib/selfboot.o
CC ramstage/lib/stack.o
CC ramstage/lib/version.o
CC ramstage/lib/wrdd.o
CC ramstage/ec/lenovo/pmh7/pmh7.o
CC ramstage/ec/lenovo/h8/h8.o
CC ramstage/ec/acpi/ec.o
CC ramstage/drivers/uart/uart8250io.o
CC ramstage/drivers/uart/util.o
CC ramstage/drivers/spi/adesto.o
CC ramstage/drivers/spi/amic.o
CC ramstage/drivers/spi/atmel.o
CC ramstage/drivers/spi/boot_device_rw_nommap.o
CC ramstage/drivers/spi/eon.o
CC ramstage/drivers/spi/gigadevice.o
CC ramstage/drivers/spi/spansion.o
CC ramstage/drivers/spi/macronix.o
CC ramstage/drivers/spi/spi-generic.o
CC ramstage/drivers/spi/spi_flash.o
CC ramstage/drivers/spi/sst.o
CC ramstage/drivers/spi/stmicro.o
CC ramstage/drivers/spi/winbond.o
CC ramstage/drivers/ricoh/rce822/rce822.o
CC ramstage/drivers/pc80/vga/vga.o
CC ramstage/drivers/pc80/vga/vga_font_8x16.o
CC ramstage/drivers/pc80/vga/vga_io.o
CC ramstage/drivers/pc80/vga/vga_palette.o
CC ramstage/drivers/pc80/rtc/mc146818rtc.o
CC ramstage/drivers/pc80/rtc/mc146818rtc_early.o
CC ramstage/drivers/pc80/pc/i8254.o
CC ramstage/drivers/pc80/pc/i8259.o
 

Re: [coreboot] Rowhammer DRAM Refresh

[Philipp Stanner]

K, thank you so far! I hoped there was an easier solution like a #define 
in a header somewhere.


However it's the code I've gone through so far is already interesting as 
coreboot often seems to use a refresh rate of ~16ms what's 4x of the 
rate some vendors use.


// P.


On 20.03.2017 13:34, Arthur Heymans wrote:

Philipp Stanner <stan...@posteo.de> writes:


Hi,

where (which code file) does coreboot set the DRAM-refresh-rate and
how easy is it for me to change it?

That would be in raminit, which is platform specific. So it depends on
readability of that code whether it's easy to find or not.

Not sure of this is possible with raminits like FSP or MRC.bin provided
in binary only.


A higher refresh rate will decrease the performance but increase the
protection against Rowhammer.

// Philipp


Some example of how to achieve this on Intel 945 northbridge:

diff --git a/src/northbridge/intel/i945/raminit.c 
b/src/northbridge/intel/i945/raminit.c
index b5cce9c429..36dd601fb2 100644
--- a/src/northbridge/intel/i945/raminit.c
+++ b/src/northbridge/intel/i945/raminit.c
@@ -811,32 +811,8 @@ static void sdram_detect_smallest_refresh(struct sys_info 
* sysinfo)
  {
int i;
  
-	sysinfo->refresh = 0;

+   sysinfo->refresh = 1;
  
-	for (i = 0; i < 2*DIMM_SOCKETS; i++) {

-   int refresh;
-
-   if (sysinfo->dimm[i] == SYSINFO_DIMM_NOT_POPULATED)
-   continue;
-
-   refresh = spd_read_byte(get_dimm_spd_address(sysinfo, i),
-   SPD_REFRESH) & ~(1 << 7);
-
-   /* 15.6us */
-   if (!refresh)
-   continue;
-
-   /* Refresh is slower than 15.6us, use 15.6us */
-   if (refresh > 2)
-   continue;
-
-   if (refresh == 2) {
-   sysinfo->refresh = 1;
-   break;
-   }
-
-   die("DDR-II module has unsupported refresh value\n");
-   }
printk(BIOS_DEBUG, "Refresh: %s\n", sysinfo->refresh?"7.8us":"15.6us");
  }
  
  




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

[coreboot] Rowhammer DRAM Refresh

[Philipp Stanner]

Hi,

where (which code file) does coreboot set the DRAM-refresh-rate and how 
easy is it for me to change it?


A higher refresh rate will decrease the performance but increase the 
protection against Rowhammer.


// Philipp


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

Re: [coreboot] Best supported modern laptop?

[Philipp Stanner]

> Coreboot on brand new laptops isn't actually coreboot like it used to
> be, it has been reduced to a pathetic vestige of its former self -
> simply a shim loader layer that does next to nothing besides get the
> purism phonies all excited for a "free" firmware laptop.

Could I get some details on this please?

I presume the following: "old" coreboot (in the X60 for example) used
self-written code for hardware initalization (RAM setup, PCI config)
while modern coreboot uses the vendor code for this, embedded in a
coreboot frame?

If this doesn't speed up boot time (like someone mentioned before) at
least you would get rid of features like Intel AMT - and you still could
get a little speed advantage by starting the boot-loader or even Linux
directly out of the flash?

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

Re: [coreboot] Best supported modern laptop?

[Philipp Stanner]

Well, these are sad news.
I'm surprised that the amount of blobs is so high in modern hardware.
Without desiring to criticize or judge the project: What's the goal for
the future, when even you admit that there's no great difference in
technical aspects to vendor firmware?
The sole purpose of free hardware may be honorable, but my personal
believe is that efficiency is more important to people.

Am 30.01.2017 um 23:09 schrieb Timothy Pearson:
> On 01/30/2017 02:12 PM, Philipp Stanner wrote:
> > I'm primary interested in it because of faster booting speed and in
> > general getting rid off the stone-age functions vendor bios contains
> > which are completely unnecessary to boot a modern x86-computer.
>
> > I don't mind if coreboot contains cpu microcode etc.
>
> > As far as I know the only total free computer is the X60.
>
> > But isn't this whole privacy issue more a topic for libreboot?
>
> No, not really -- people have many reasons for wanting to use coreboot
> over a vendor firmware, and these reasons influence our recommendations.
>
> Furthermore, I was specifically referring to the ME|PSP and
> FSP|binaryPI, not microcode.  On many modern systems coreboot is a
> simple shim around vendor firmware, and in such cases you may or not
> gain anything by using coreboot versus the vendor firmware, depending of
> course on how the vendor implemented their firmware.  This includes boot
> time; on platforms with large amounts of RAM where most of the time is
> spent in memory initialization, you will effectively be running the same
> MRC binary as the vendor firmware, so you won't really see a decrease in
> boot time.
>
>




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Best supported modern laptop?

[Philipp Stanner]

I'm primary interested in it because of faster booting speed and in
general getting rid off the stone-age functions vendor bios contains
which are completely unnecessary to boot a modern x86-computer.

I don't mind if coreboot contains cpu microcode etc.

As far as I know the only total free computer is the X60.

But isn't this whole privacy issue more a topic for libreboot?

Am 30.01.2017 um 19:18 schrieb Timothy Pearson:
> On 01/30/2017 10:53 AM, Philipp Stanner wrote:
> > I'm going to buy a new laptop soon (has to have a touchscreen) and am
> > considering buying one which supports coreboot.
>
> > Which model would that be?
>
> > From what the wiki tells me The X220 is supported best, thanks to
> > Vladimir, but also the X201 is listed in the green area.
>
> > The wiki lists some noticeable issues for the X201, though. Still it's
> > green. Are those issues (especially "The X201 immedeatly powers off
> > after resuming from suspend resulting a completely lost session
> > sometimes (Race condition)" still unsolved?
>
> > thx
>
>
>
> The answer to this question also hinges on whether you would like a
> blob-free / owner controlled machine or are OK with most of the "heavy
> lifting" coming from non-libre vendor provided firmware binaries.
>
> I ask because if you're wanting to use coreboot purely for libre
> reasons, then you're going to be stuck with much older technology.
>
> Thanks!
>




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Best supported modern laptop?

[Philipp Stanner]

I'm going to buy a new laptop soon (has to have a touchscreen) and am
considering buying one which supports coreboot.

Which model would that be?

>From what the wiki tells me The X220 is supported best, thanks to
Vladimir, but also the X201 is listed in the green area.

The wiki lists some noticeable issues for the X201, though. Still it's
green. Are those issues (especially "The X201 immedeatly powers off
after resuming from suspend resulting a completely lost session
sometimes (Race condition)" still unsolved?

thx


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

[coreboot] C++

[Philipp Stanner]

Could coreboot (or parts of it) be written in C++?

What would be the advantages and disadvantages?


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

Re: [coreboot] chat.coreboot.org is on

[Philipp Stanner]

That's a wise decision.

If you'd ask me I would also think about creating a coreboot-forum. It
would make certain diskussions more clear than the mailing list,
especially if they last longer than a few days.

Am 07.01.2017 um 08:42 schrieb Patrick Georgi:
> Hi all,
>
> we've set up a mattermost instance on https://chat.coreboot.org/ in
> the hope to lower the barriers to entry into our community.
>
> It comes with a bridge to IRC, history (but not web-indexable, which
> was a major concern with IRC logs so far) and the ability to start
> topic channels that are discoverable yet separate from the main
> discussion.
>
>
> See you there,
> Patrick
>



0x992EA6A9.asc
Description: application/pgp-keys
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] latest greatest thinkpad with coreboot

[Philipp Stanner]

By the way:

Is it true that coreboot consumes more power ( = shorter battery life)
than vendor bios?


Am 01.12.2016 um 18:04 schrieb ron minnich:
> what's the latest best one? What's the battery life like (can't be
> worse than this mac pro  that's always hot and now seems to have a
> life of 90 minutes, always). How much dram/ssd can I jam in it?
>
> thanks
>
>

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

Re: [coreboot] grub as payload: Where to put the grub.cfg?

[Philipp Stanner]

Hi Nico,

thanks so far.

Using your own pointer to the HDD serves to purpose of being able to
change the cfg-file without flashing the ROM, I presume?

Anyhow using grub you'd have to use the Shell to start an OS from an
external drive - in an emergency for example, correct?

Am 09.11.2016 um 10:19 schrieb Nico Huber:
> Hi Philipp,
>
> On 09.11.2016 09:46, Philipp Stanner wrote:
>> Hi,
>>
>> I'm currently busy making cb+grub running. While I can boot successfully
>> (qemu) using the grub-shell I of course want to automatize this process.
>>
>> But how and where do I have to put the grub.cfg file? The wiki doesn't
>> include much informations about this.
>>
>> I would appreciate if someone could help me :)
> it's indeed not very obvious. There should be a grub.cfg in the grub
> image, that just points to the next in cbfs at "/etc/grub.cfg". That's
> where you should put yours, like that:
>
>   build/cbfstool build/coreboot.rom add -t raw -n etc/grub.cfg -f
> your-grub.cfg
>
> Nico
>
> PS. My (cbfs)/etc/grub.cfg contains just another pointer:
>
> configfile (ahci0,1)/grub/grub.cfg
>


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

[coreboot] grub as payload: Where to put the grub.cfg?

[Philipp Stanner]

Hi,

I'm currently busy making cb+grub running. While I can boot successfully
(qemu) using the grub-shell I of course want to automatize this process.

But how and where do I have to put the grub.cfg file? The wiki doesn't
include much informations about this.

I would appreciate if someone could help me :)


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

[coreboot] Are there any updates according thinkpad-X201-support?

[Philipp Stanner]

The wiki-article lists several issues, primary:

  * Most times after suspend an EC IRQ hangs in the queue and all
functions keys stopped working until cold boot.
  * *Commit 456f495d broke USB and PCI-E* (unable to boot from live ISO
on USB), a hard reset to commit a3e41c08 fixed the boot issue

Is this still up to date or has it been fixed?

greetings

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

Re: [coreboot] ISOLINUX gfx problems under qemu/coreboot/SeaBIOS

[Philipp Stanner]

Sure: Do the following:

 1. qemu-img create test.img 10G
 2. qemu-system-x86_64 -enable-kvm -hda test.img -cdrom ubuntu.iso -boot
d -m 512
 3. Install ubuntu on test.img

After installing, boot the new virtual machine with your self-build bios:

  * qemu-system-x86_64 -enable-kvm -hda test.img -m 512 -bios
build/coreboot.rom

See how the machine starts successfully, using the 'broken' seabios.
Ubuntu boots successfully. Even starting my Windows7-machine nearly
works, but while "Windows is loading files" is written the virtual
screen / text becomes yellow and booting stops.

But Ubuntu can successfully be booted and used absolutely normaly with
cb+seabios - only installing seems impossible and the errors you
(Jonatahan) described, appear.

Greetings


Am 25.10.2016 um 01:10 schrieb Jonathan Neuschäfer:
>> If I build a new virtual harddrive, install Ubuntu there (using qemu's
>> default bios) then I'm able to start the new image using my self-build bios.
> I'm not sure what you mean here. Can you explain it in more detail?
>


signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Building of payloads fails, SeaBIOS fails in qemu

[Philipp Stanner]

Hi,

according the first problem I've already created a ticket. I (and others
in IRC) failed building rom-images using nconfig+make with other
payloads than seabios. See the txt-files in the ticket system; make
reports something like: "Rule for filo unkown".

The second problem is that a self-build seabios doesn't boot in qemu
(again for me and people in IRC). While the default-qemu-bios boots any
diskimage just fine, -boot build/coreboot.rom causes seabios to start
fine (at first), too. But when it actually tries to boot from an image,
the errors: "Graphic initalization failed. Error setting up gfxboot.
boot: Could not allocate memory."

If I build a new virtual harddrive, install Ubuntu there (using qemu's
default bios) then I'm able to start the new image using my self-build bios.


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

[coreboot] Virtualization Support X220

[Philipp Stanner]

Is it possible to activate virtualization in the CPU somewhere?

greetings


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

[coreboot] Noob-questions

[Philipp Stanner]

Hi cb-community,

as everyone who owns a computer can subscribe to the list and there is
no coreboot-forum, I presume that I'm allowed to ask a few primitive
questions about the topic :)

 1. Coreboot+Payload are only used to initialize the hardware and then
give the complete control over the system to the OS, right? So once
the OS booted no Coreboot or Payload-code is executed anymore?
 2. Bios calls were used decades ago (so the OS hadn't to bring all the
drivers) but aren't used by modern OS anymore, right? So why does
Windows need seaBIOS to work?
 3. If [1] is true, does that mean it's not important (for the user) if
coreboot supports 100% of the boards hardware? Example: If I install
coreboot on a machine and the wiki says "VGA not supported" this
means that the monitor won't show anything - until the OS boots
which uses it's own driver to address the monitor. Right? To be
sure: As long as the OS boots successfully I don't really have to
care if all system components work during the boot process?
 4. In the traditional BIOS I can adjust lots of settings - overclock my
CPU for example or enable Virtualization for KVM. How do I do this
in coreboot?

Beside of that: Great work guys, take care.

Greetings

Philipp

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