yes it does. The PI interface is in terms of encapsulation somewhat
cleaner then the FSP integration.
I think that was Ron concern using PI instead of FSP.
If we talking about full customization up to the bootblock and vboot2
I would recommend to use coreboot in combination with LinuxBoot payload.
If we talk less effort to get your firmware running maybe LinuxBoot is
the better approach depending
on your platform.
Best Regards, Philipp
On 27.06.2018 13:37, chrisglowaki(a)tutanota.com wrote:
> 26. Jun 2018 20:02 by rminnich(a)gmail.com <mailto:email@example.com>:
>> For a case like this, where your choice is between two binary blobs (FSP or UEFI) I would argue that linuxboot is a better way to go.
>> See > github.com/osresearch/heads <http://github.com/osresearch/heads>> or > linuxboot.org <http://linuxboot.org>> for more info.
> Doesn't linuxbootalso require the FSP blob for memory and silicon initialization on any Intel board after Ivy Bridge?
How can I know what is the right flashrom programmer I should use ?
under DOS\EFI I have a vendor's utility that enables flash programming.
But it can flash to a specified address.
The vendor's programmer works without any external hardware.
When I tried: flashrom --programmer internal, I got:
flashrom v0.9.9-rc1-r1942 on Linux 4.13.0-36-generic (x86_64)
flashrom is free software, get the source code at https://flashrom.org
Calibrating delay loop... OK.
WARNING: No chipset found. Flash detection will most likely fail.
No EEPROM/flash device found.
Note: flashrom can never write if the flash chip isn't found automatically.
Dear Jose & Nico,
Thank you very much for your help !
On Thu, Jun 21, 2018 at 11:28 AM Jose Trujillo <ce.autom(a)protonmail.com>
> Hello Zvika,
> Look for the list of Linux commands to dump many of the information from
> your original BIOS running, maybe there you will find this information.
> Also, some configuration can be seen from your original BIOS running Intel
> FIT for Baytrail in Windows.
> About configuring those settings in coreboot look for other examples in
> the coreboot tree about configuring PCI devices in devicetree.cb and other
> I Am new to coreboot too and please correct me if I Am wrong.
> Good Luck!
> J. Trujillo
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On June 21, 2018 3:34 AM, Zvi Vered <veredz72(a)gmail.com> wrote:
> Thank you very much for the detailed reply.
> Vendor's BIOS contains few peripherals initialization.
> For example: PCIe enumeration, SATA controller, USB etc.
> In case of PCIe enumeration, the generation of PCIe (1,2,3) can be set.
> Should vendor supply code for this ? or any other information ?
> How can I write it from scratch ? Can Intel provide information on how to
> implement this initialization ?
> Thank you,
> On Mon, Jun 18, 2018 at 11:22 AM Jose Trujillo via coreboot <
> coreboot(a)coreboot.org> wrote:
>> Hello Zvika:
>> 1.- Usually it is not necessary to change the CBFS size unless the
>> compiler complain of lack of space.
>> 2.- You should not worry about this setting to make your system to work.
>> 3.- You should not use FSP_PACKAGE_DEFAULT if your plan is to use SIO
>> because it will enable SOC internal COM1, instead (if your plan is to use
>> FSP) enable FSP and add a VGA bios bin manually.... (The use of FSP is
>> optional but I never tried without FSP).
>> 4.- You need to add them yourself, there are examples to follow in this
>> mail list.
>> Good luck!
>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>> On June 18, 2018 6:24 AM, Zvi Vered <veredz72(a)gmail.com> wrote:
>> I inspected the "Bayley Baay FSP-based CRB" sample in coreboot. after
>> make distclean I chose:
>> Mainboard vendor: Intel
>> Mainboard model: Bayley Bay FSP-based CRB
>> 1. The size of CBFS is: 0x200000. Is it a fix size or should I change it
>> according to my board (which is also bay trail) ?
>> 2. According to "dmidecode" I ran on my target, "Address: 0xE0000"
>> Should I set this address in coreboot configuration ? How ?
>> 3. In this board default configuration, "Configure defaults for the Intel
>> FSP package" is not selected. Is it possible that this board does not use
>> Intel FSP at all ?
>> Under "Generic Drivers", "Use Intel firmware Support Package' is also not
>> 4. Under "chipset", there is no option to set "Super I/O". Can you please
>> tell why ?
>> 5. I noticed that the minimum ROM size is 2MB. If I set 4MB, the size of
>> coreboot.rom is also 4MB.
>> Thank you in advance,
>> coreboot mailing list: coreboot(a)coreboot.org
On 26. Jun 2018 12:56 nico.huber(a)secunet.com <mailto:coreboot%40coreboot.org?Subject=Re%3A%20%5Bcoreboot%5D%20Porting%20Kabylake%20laptop&In-Reply-To=%3C7bc3873d-a7f3-1981-3b3b-fa6abc86bf8b%40secunet.com%3E> wrote:
> If you use the exact same processor SKU as the reference board: yes.
> Otherwise: no. Both the people who implemented FSP and who integrated
> it into coreboot were lazy: They could have provided defaults for all
> SKUs but didn't. If in doubt (and in case you don't have an NDA with
> Intel) better ask here what the right defaults are for your processor.
I have a i5-7200U. Intel has some datasheets available for Kabylake-U. Can they be used to get VR values?
> 2. Can the laptop work properly without GPIO? I don't know if there is
>> a way to dump the GPIO config in vendor firmware on Kabylake.
> What works with the reset default configuration and what not depends on
> each board. It is likely to boot in my experience. Have a look at `util/
> inteltool/` in our source tree. It can dump the GPIO registers for Sun-
> rise Point (the 100-series PCH that comes with Skylake). The 200-series
> PCH should be the same, but if you have an SoC version of Kaby Lake
> (known as Kabylake-U / -Y / -R) things are different. I'll add Youness
> in CC who might have a patch for that.
Unfortunately inteltool doesn't support my PCH yet, probably because I have a Kabylake-U processor.
>> 3. Are there other settings that could damage the hardware?
> I can't tell if that is the case for your board without knowing your
> board. Is it generally possible? yes. Though, it is unlikely that core-
> boot contains code that would harm your board. When you copy code for
> a reference board, you should also check the C code. It's not much and
> if there is something you don't understand, better ask. All the board-
> agnostic code should be safe (but there is no guarantee).
Do evaluation boards like KBL RVP8 have only board-agnostic code or do they also have some board-specific code?
> And, as you need an FSP binary by Intel for Kaby Lake, it also has a
> huge amount of settings (over 700 if you count them individually (but
> they are actually grouped)). Some of these settings are overridden by
> coreboot (devicetree settings or static platform code). And their code
> quality is generally worse than coreboot's (maybe not over all but com-
> pared to coreboot). So I can't say if FSP doesn't do any harm (though
> unlikely, as it works for most everybody else so far). The binaries
> on Github likely have defaults for the non-SoC version btw. Alas, FSP
> is basically undocumented.
The FSP package from GitHub comes with config files for FSP. Do they need to be used or do only the settings in devicetree matter?
Thanks a lot for your help, it is very helpful.
On 25. Jun 2018 18:18 nico.h(a)gmx.de <mailto:firstname.lastname@example.org> wrote:
> you can generally boot without a complete port. But you can also damage
> the hardware if you are not careful. Beside the devicetree settings (pay
> attention when it comes to the voltage regulator settings!), the GPIO
> configuration should also match your board. You can try to boot without
> GPIO configuration (it should be safe because the hardware has to expect
> the reset defaults for the GPIOs). But *never* try to boot with a copied
> GPIO configuration from another board.
Thank you Nico for the warnings! A few questions:
1. Is it safe to leave default VR settings from Kabylake Reference Board?
2. Can the laptop work properly without GPIO? I don't know if there is a way to dump the GPIO config in vendor firmware on Kabylake.
3. Are there other settings that could damage the hardware?
> Regarding the EC, you can learn a lot about its interface from the ven-
> dor's ACPI implementation. Unless the board uses a lot of PnP interfaces
> of the EC (unlikely for a modern laptop), the datasheet is usually not
> helpful. What you really would need is documentation about the EC firm-
> ware and its OS interface. And you'll likely not get that.
Can the laptop boot to Linux without EC support in coreboot?
Regarding the ACPI implementation, can that be dumped using acpidump and then used in the ec.asl file?
On Mon, Jun 25, 2018 at 11:39 PM, ron minnich <rminnich(a)gmail.com> wrote:
> On Mon, Jun 25, 2018 at 12:55 AM Shawn <citypw(a)gmail.com> wrote:
>> Hi Ron,
>> IIRC, Machine mode in RISC-V is just looking similar to SMM in x86.
>> But it can do more than what SMM does.
> that's in my view not good, since in many cases, M mode code is part of
> firmware, not the kernel image. Kernels don't get to change or ignore it. M
> mode can protect itself from the kernel, even from being read. So it can
> hide its presence, what it does, and might even be able to change itself.
> I had a talk with a BIG ARM SOC vendor not long ago. They said that at one
> point a big x86 company proposed that their company implement SMM for ARM.
> "so they asked us to implement this SMM-like thing that had unlimited
> privilege. We said no, no no, there's no reason to repeat x86 mistakes on
> ARM". Good call on that company's part.
> I argued several years ago that M mode code should be supplied by the
> kernel, not firmware, for the obvious reasons: M mode is a great place to
> put a persistent threat. The various x86 experiences were well known by that
> time, so the problem should have been pretty clear.
Well, from that perspective I'm totally agree w/ SMM is a big threat
especially when the machine was compromised and then attacker implant
a rootkit running in SMM. If that happened in x86, it's pretty much
fuc*ed up. Cu'z it's unlikely detect the smm rootkit at runtime, while
the static analysis of forensics cost more time/money. Maybe we
should've taken mitigation( SMRAM?) into this case in the 1st place.
GNU powered it...
GPL protect it...
God blessing it...
On 25.06.2018 09:55, Shawn wrote:> Hi Ron,
> On Sun, Jun 24, 2018 at 12:55 AM, ron minnich <rminnich(a)gmail.com> wrote:
>> On Wed, Jun 20, 2018 at 11:03 PM Taiidan(a)gmx.com <Taiidan(a)gmx.com> wrote:
>>> Whats the deal with SMM? What a shame they thought to add it.
>> It's a huge disappointment. I made some effort a few years ago to try to
>> convince folks this was a bad idea and failed.
>> I'm no longer as optimistic as I was about RISC-V. There seems to be a real
>> push to be "just like x86".
> IIRC, Machine mode in RISC-V is just looking similar to SMM in x86.
> But it can do more than what SMM does. It helps to enclave-based
> solution. I'm looking forward to see the open solution, e.g: Sanctum,
> Keystone, etc to land into production environment.
IMO, putting enclaves on the same silicon as the code you want to
protect them from is a failed concept. And more, it's bullshit, it
means two separate entities have to own the same physical chip. And
SGX proves that it doesn't work (they can't protect the OS from being
spied upon from the enclave (see Spectre), how can they ever hope to
protect the enclave from the much more powerful OS?).
IMHO, not RISC-V but the whole industry is at least 20 years away from
getting that going (software separation in one piece of silicon, with-
out help from the software).
So, no, no marketing false-security tech* that doesn't provide what it
promises can justify to pollute an architecture like RISC-V.
* I know there is a lot of honest research around enclaves, but they
all seem to ignore the reality of today's processors.