https://review.coreboot.org/21774
In case anyone else didn't notice - It is a sandy/ivy system with IOMMU.
This is great and should help get coreboot in to the corporate user world.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi @ all,
is there a Coroboot for the Lenovo T410 Laptop?
Greetings
Alex Veek
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iF4EAREIAAYFAlNxKzsACgkQ53cWmi2XuzOOXAD8CNLPoycJNftQzeHnMQbl8ZG9
4y2SPIHwLota1/Gsfm0BAJzhG2M+MKXDBJgazHjt/HM2DyAeHi6S24sGcwd1W2GN
=sFKM
-----END PGP SIGNATURE-----
A Hardware Enablement devroom will be taking place at FOSDEM this year,
on Sunday 10 December 2017. This newly-created devroom is the result of
3 proposals that were merged together. It is co-organized by several
individuals.
The devroom covers all aspects related to hardware enablement and
support with free software, including aspects related to boot software,
firmwares, drivers and userspace tools and adaptation.
Proposals for talks related to these topics are welcome and can be
submitted until Sunday 26 November 2017 via the pentabarf interface.
Short talks are encouraged over longer ones in order to cover a wide
range of topics.
The announcement for the devroom, that contains all the useful
information, was published at:
https://lists.fosdem.org/pipermail/fosdem/2017-October/002649.html
Cheers and see you at FOSDEM!
--
Paul Kocialkowski, developer of free digital technology and hardware
support
Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/https://git.code.paulk.fr/
They said they would be releasing opteron microcode updates in a few
weeks but it has been over a month and I am wondering when this is going
to happen or if it already has and I should re-compile coreboot?
https://www.amd.com/en/corporate/speculative-execution
"We expect to make updates available for our previous generation
products over the coming weeks."
Thanks!
Hi Gergely,
Thank you for your config. Now I have coreboot + SeaBIOS perfectly working.
Console speed is now "normal" :-)
These are the changes between the two configs:
-------------
diff config_original.txt config_Gergely.txt
23c23
< # CONFIG_USE_BLOBS is not set
---
> CONFIG_USE_BLOBS=y
101c101
< CONFIG_UART_FOR_CONSOLE=0
---
> CONFIG_UART_FOR_CONSOLE=1
150c150
< CONFIG_POST_DEVICE=y
---
> # CONFIG_POST_DEVICE is not set
210c210
< CONFIG_TTYS0_BASE=0x3f8
---
> CONFIG_TTYS0_BASE=0x2f8
428,429d427
< # CONFIG_PCI_OPTION_ROM_RUN_REALMODE is not set
< # CONFIG_PCI_OPTION_ROM_RUN_YABEL is not set
431d428
< # CONFIG_VGA_TEXT_FRAMEBUFFER is not set
556c553
< # Serial port base address = 0x3f8
---
> # Serial port base address = 0x2f8
581,583d577
< CONFIG_POST_DEVICE_NONE=y
< # CONFIG_POST_DEVICE_LPC is not set
< # CONFIG_POST_DEVICE_PCI_PCIE is not set
--------------
I made some tweaks to the configuration, added VGA output before
payload, a nice bootsplash, etc..
Other considerations:
VGA Device PCI IDs are 1002,9830 (The default 1002,9836 does not get
output).
Memory has to be located firstly on second slot (yellow DIMM_A2). If not
you get AGESA_FATAL_ERROR. I only have one module.
Please, find attached a working config.txt and console.log. Coreboot
revision is 4.7-294-g2db6fbc47b.
If you verify these changes are working for you is it possible to change
the defaults in Kconfig?
Thank you very much.
Best regards,
-- Eli
On 11/02/18 00:07, Gergely Kiss wrote:
> Strange, the log you shared looked less verbose to me than expected
> but seems like I was wrong. Anyway, you might find an example on a
> full debug log here [1].
>
> I have a small build script I use to build coreboot for my board,
> please find it attached.
>
> The version currently running on my box is 4.6-2554-ga1b4c94.
>
> [1] https://www.coreboot.org/Board:asus/am1i-a#Bootlog
>
> On 10 February 2018 at 23:18, Elisenda Cuadros <lists(a)e4l.es
> <mailto:lists@e4l.es>> wrote:
>
> Thank you for your kind reply Gergely.
>
> I think the cable is not the problem, I have been using it for
> years and it's intact.
>
> I am using a usb dongle but not a cheap one. Tomorrow I will try
> with another cable and a real COM port. Just to be 100% sure.
>
> Console is fast at the very first time (just the "normal") but
> after two seconds it becomes extremely slow.
>
> Please, can you say me which is the git revision you are using?
>
> The console log I attached is from a SPEW debug level, not
> corresponding with the config.. I tried several configs today :-) .
>
> Is it possible to share your config with me?
>
> Best regards,
>
> Eli
>
>
> On 10/02/18 21:44, Gergely Kiss wrote:
>> Hi Eli,
>>
>> I've been using Coreboot on my board for several weeks, it is
>> serving as an HTPC running 24/7 and it's working perfectly stable
>> which suggests the firmware should be free of bugs. It is likely
>> that you are facing some configuration or hardware issue here.
>>
>> I didn't see any issues with the serial output while working with
>> the board once the SuperIO chip started to work. Make sure the
>> cable you use is intact and try to attach it to another machine.
>> At the time I was working with my board, I used a Dell Port
>> Replicator with a native COM port so I could use a standard
>> null-modem cable and it was working flawlessly. In case you use a
>> USB serial adapter, try replacing it or attach the serial cable
>> directly to a COM port if you have one available.
>>
>> Also, please enable debug_level=Spew as it seems the console log
>> you attached comes from a less verbose setting and therefore it's
>> not as useful as it should be.
>>
>> Note that the VBIOS image is executed by SeaBIOS which means you
>> won't see anything on your display until the payload is executed.
>>
>> If all else fails, you can still attach a POST debug module to
>> the LPC header of the board [1] which can help a lot to find out
>> where the boot process hangs.
>>
>> Feel free to contact me if you need some more help or
>> information, I'm happy to assist!
>>
>> Regards,
>> Gergely
>>
>> [1] https://www.youtube.com/watch?v=aGGqsWx3-1c
>> <https://www.youtube.com/watch?v=aGGqsWx3-1c>
>>
>> On 10 February 2018 at 18:17, Elisenda Cuadros <lists(a)e4l.es
>> <mailto:lists@e4l.es>> wrote:
>>
>> Hello,
>>
>> I'm trying to use Coreboot in an Asus AM1I-A board recently
>> ported by Gergely Kiss (thank you!).
>>
>> I am using the default config settings and added vga rom
>> extracted with UEFITool from the vendor bios.
>>
>> After flashing and booting I get no output from vga.
>>
>> Serial console is extremely slow too (30 minutes to write the
>> log)
>>
>> I attach the coreboot console log, config and cbfs.txt.
>>
>> Any hints?
>>
>> Thanks in advance.
>>
>> Best regards,
>>
>> -- Eli
>>
>>
>>
>
>
>
>
Hi,
What do you want to protect? If you want to protect the kernel, retpolines are OK on AMD.
And you don't need any microcode update. Your CPU needs to have SMEP, otherwise
you would need to clear RSB on CPL change (the paper on mentined page says that you need to do that
always, but at least on Ryzen, the attack using RSB is not working (we tried that out, maybe it works
only on some circumstances).
If you want to protect userspace, the RSB will be clear by IBPB (which you would need if you don't have userspace compiled
with retpolines). I don't know if intel clears RSB on IBPB... probably not
To sum it up on AMD:
kernel:
retpolines, RSB clear on CPL change on CPU without SMEP (see above)
userspace:
retpolines, RSB clear on context switch necessary or IBPB (needs microcode update).
Plus make sure you enable "LFENCE is dispatch serializing" - perhaps coreboot can do that :) it is simple
MSR write on fam 10h 12h+ the fam 11h and 0fh dont have this MSR but LFENCE is dispatch serilizing.
Besides that, you don't need any microcode update.
Plus of course there is a spectre variant 1, which is more difficult to mitigate, basically you need to check all the software
and look for any pattern like array_x[array_z[untrusted_index] * any transformation].
The first access would leak just address (ASLR defated), second will leak data.
The variant 1 works on user/user attack and as well as user/kernel.
As far I know there are no automated tools to check for this.
Thanks
Rudolf
Dne 18.2.2018 v 12:48 Mike Banon napsal(a):
> Maybe its' a good idea to write to AMD support regarding this question
> - please share a reply if you would get an answer. I'm curious about
> other fam15 CPUs as well, e.g. A10-5750M microcode update would be
> nice, maybe a request could be more general, e.g. : what is the
> estimated release date for the microcode updates for fam15 AMD CPUs
> (so a request is not about "opterons only")
>
> On Sun, Feb 18, 2018 at 2:47 PM, Mike Banon <mikebdp2(a)gmail.com> wrote:
>> Maybe its' a good idea to write to AMD support regarding this question
>> - please share a reply if you would get an answer. I'm curious about
>> other fam15 CPUs as well, e.g. A10-5750M microcode update would be
>> nice, maybe a request could be more general, e.g. : what is the
>> estimated release date for the microcode updates for fam15 AMD CPUs
>> (so a request is not about "opterons only")
>>
>> On Sun, Feb 18, 2018 at 4:30 AM, Taiidan(a)gmx.com <Taiidan(a)gmx.com> wrote:
>>> They said they would be releasing opteron microcode updates in a few weeks
>>> but it has been over a month and I am wondering when this is going to happen
>>> or if it already has and I should re-compile coreboot?
>>>
>>> https://www.amd.com/en/corporate/speculative-execution
>>> "We expect to make updates available for our previous generation products
>>> over the coming weeks."
>>>
>>> Thanks!
>>>
>>>
>>> --
>>> coreboot mailing list: coreboot(a)coreboot.org
>>> https://mail.coreboot.org/mailman/listinfo/coreboot
>
We ran into an issue where we were not getting a full coreboot log on
Denverton with the Harcuvar CRB, where it just abruptly stops the serial
console output during the assignment of the PCI resources.
Root Device assign_resources, bus 0 link: 0
DOMAIN: 0000 assign_resources, bus 0 link: 0
PCI: 00:09.0 1c <- [0x000000ffff - 0x000000fffe] size 0x00000000 gran 0x0c
bus 01 io
PCI: 00:09.0 24 <- [0x00dfffffff - 0x00dffffffe] size 0x00000000 gran 0x14
bus 01 prefmem
PCI: 00:09.0 20 <- [0x00dfffffff - 0x00dffffffe] size 0x00000000 gran 0x14
bus 01 mem
PCI: 00:09.0 10 <- [0x00df700000 - 0x00df71ffff] size 0x00020000 gran 0x11
mem64
PCI: 00:0e.0 1c <- [0x000000ffff - 0x000000fffe] size 0x00000000 gran 0x0c
bus 02 io
PCI: 00:0e.0 24 <- [0x00dfffffff - 0x00dffffffe] size 0x00000000 gran 0x14
bus 02 prefmem
PCI: 00:0e.0 20 <- [0x00dfffffff - 0x00dffffffe] size 0x00000000 gran 0x14
bus 02 mem
PCI: 00:0e.0 10 <- [0x00df720000 - 0x00df73ffff] size 0x00020000 gran 0x11
mem64
PCI: 00:10.0 1c <- [0x000000ffff - 0x000000fffe] size 0x00000000 gran 0x0c
bus 03 io
PCI: 00:10.0 24 <- [0x00dc000000 - 0x00ddffffff] size 0x02000000 gran 0x14
bus 03 prefmem
PCI: 00:10.0 20 <- [0x00de000000 - 0x00de8fffff] size 0x00900000 gran 0x14
bus 03 mem
PCI: 00:10.0 10 <- [0x00df740000 - 0x00df75ffff] size 0x00020000 gran 0x11
mem64
PCI: 00:10.0 assign_resources, bus 3 link: 0
PCI: 03:00.0 1c <- [0x000000ffff - 0x000000fffe] size 0x00000000 gran 0x0c
bus 04 io
PCI: 03:00.0 24 <- [0x00dc000000 - 0x00ddffffff] size 0x02000000 gran 0x14
bus 04 prefmem
PCI: 03:00.0 20 <- [0x00de000000 - 0x00de8fffff] size 0x00900000 gran 0x14
bus 04 mem
PCI: 03:00.0 assign_resources, bus 4 link: 0
PCI: 04:00.0 10 <- [0x00dc000000 - 0x00ddffffff] size 0x02000000 gran 0x19
prefmem
PCI: 04:00.0 14 <- [0x00de820000 - 0x00de823fff] size 0x00004000 gran 0x0e
mem
PCI: 04:00.0 18 <- [0x00de000000 - 0x00de7fffff] size 0x00800000 gran 0x17
mem
PCI: 04:00.0 30 <- [0x00de800000 - 0x00de81ffff] size 0x00020000 gran 0x11
romem
PCI: 03:00.0 assign_resources, bus 4 link: 0
PCI: 00:10.0 assign_resources, bus 3 link: 0
PCI: 00:12.0 10 <- [0x00df77b000 - 0x00df77b3ff] size 0x00000400 gran 0x0a
mem64
PCI: 00:14.0 10 <- [0x00df774000 - 0x00df775fff] size 0x00002000 gran 0x0d
mem
PCI: 00:14.0 14 <- [0x00df77c000 - 0x00df77c0ff] size 0x00000100 gran 0x08
mem
PCI: 00:14.0 18 <- [0x0000001c40 - 0x0000001c47] size 0x00000008 gran 0x03
io
PCI: 00:14.0 1c <- [0x0000001c60 - 0x0000001c63] size 0x00000004 gran 0x02
io
PCI: 00:14.0 20 <- [0x0000001c00 - 0x0000001c1f] size 0x00000020 gran 0x05
io
PCI: 00:14.0 24 <- [0x00df77a000 - 0x00df77a7ff] size 0x00000800 gran 0x0b
mem
PCI: 00:15.0 10 <- [0x00df760000 - 0x00df76ffff] size 0x00010000 gran 0x10
mem64
PCI: 00:16.0 1c <- [0x000000ffff - 0x000000fffe] size 0x00000000 gran 0x0c
bus 05 io
PCI: 00:16.0 24 <- [0x00dea00000 - 0x00deefffff] size 0x00500000 gran 0x14
bus 05 prefmem
PCI: 00:16.0 20 <- [0x00df500000 - 0x00df5fffff] size 0x00100000 gran 0x14
bus 05 mem
PCI: 00:16.0 assign_resources, bus 5 link: 0
PCI: 05:00.0 10 <- [0x00dea00000 - 0x00debfffff] size 0x00200000 gran 0x15
prefmem64
PCI: 05:00.0 20 <- [0x00dee00000 - 0x00dee03fff] size 0x00004000 gran 0x0e
prefmem64
PCI: 05:00.0 30 <- [0x00df500000 - 0x00df57ffff] size 0x00080000 gran 0x13
romem
PCI: 05:00.1 10 <- [0x00dec00000 - 0x00dedfffff] size 0x00200000 gran 0x15
prefmem64
PCI: 05:00.1 20 <- [0x00dee04000 - 0x00dee07fff] size 0x00004000 gran 0x0e
prefmem64
PCI: 05:00.1 30 <- [0x00df580000 - 0x00df5fffff] size 0x00080000 gran 0x13
romem
PCI: 00:16.0 assign_resources, bus 5 link: 0
PCI: 00:17.0 1c <- [0x000000ffff - 0x000000fffe] size 0x00000000 gran 0x0c
bus 06 io
PCI: 00:17.0 24 <- [0x00df000000 - 0x00df4fffff] size 0x00500000 gran 0x14
bus 06 prefmem
PCI: 00:17.0 20 <- [0x00df600000 - 0x00df6fffff] size 0x00100000 gran 0x14
bus 06 mem
PCI: 00:17.0 assign_resources, bus 6 link: 0
PCI: 06:00.0 10 <- [0x00df000000 - 0x00df1fffff] size 0x00200000 gran 0x15
prefmem64
PCI: 06:00.0 20 <- [0x00df400000 - 0x00df403fff] size 0x00004000 gran 0x0e
prefmem64
PCI: 06:00.0 30 <- [0x00df600000 - 0x00df67ffff] size 0x00080000 gran 0x13
romem
PCI: 06:00.1 10 <- [0x00df200000 - 0x00df3fffff] size 0x00200000 gran 0x15
prefmem64
PCI: 06:00.1 20 <- [0x00df404000 - 0x00df407fff] size 0x00004000 gran 0x0e
prefmem64
PCI: 06:00.1 30 <- [0x00df680000 - 0x00df6fffff] size 0x00080000 gran 0x13
romem
PCI: 00:17.0 assign_resources, bus 6 link: 0
PCI: 00:18.0 10 <- [0x00df776000 - 0x00df776fff] size 0x00001000 gran 0x0c
mem64
The boot continues, there's just no more console output from coreboot past
this point. The payload launches fine after coreboot is finished. If we use
a Linux kernel payload, it still successfully sends all of its kernel
console output to the serial console beginning immediately after where the
coreboot console output stopped.
The last device that has its resources assigned that is displayed in the log
is D24, F0 (PCI 00:18.0). The next device in the list to have its resources
assigned is D26, F0 (PCI 00:1a.0), which is UART 0, which is the UART used
for the serial console. So this is starting to make some sense.
Since the BARs are assigned in order, and the first BAR of the UART device
is the I/O BAR at offset 0x10, it's pretty clear that changing the I/O space
resource assigned to the UART is what's clobbering the console. I haven't
looked at it yet, but I'm assuming that the UART driver just caches the base
address early on and doesn't know that the base address changed during PCI
resource assignment later in the boot cycle.
Of course, not only do we lose the console output, but also the UART driver
is still writing the rest of the log to an I/O address that is no longer
associated with the UART, but now potentially assigned to some other PCI
device.
Fortunately, with Denverton, the UART mode can be changed from the default
Non Legacy Mode to Legacy Mode, which appears to have resolved the issue in
this particular case.
However, I can see this as being a general problem on any/all platforms that
don't have a legacy UART (or a UART that can be put in legacy mode). Any
platform with UARTs that strictly use I/O and/or memory mapped registers
that are accessed via PCI BARs have the potential of having the BARs
programmed with different addresses during PCI resource assignment, thus
terminating the console output and otherwise potentially causing other bad
things to happen.
I thought it best to bring this up to the coreboot community, since this
could easily be a problem on any/all platforms that don't have a legacy UART
(or a UART that can be put into legacy mode). Has anybody else run into this
and/or thought about a general solution to this potential problem?
- Jay
Jay Talbott
Principal Consulting Engineer
SysPro Consulting, LLC
3057 E. Muirfield St.
Gilbert, AZ 85298
(480) 704-8045
(480) 445-9895 (FAX)
<mailto:JayTalbott@sysproconsulting.com> JayTalbott(a)sysproconsulting.com
<http://www.sysproconsulting.com/> http://www.sysproconsulting.com
I have a KGPE-D16 that runs coreboot as of commit
64294eb5e241afe9d93b37b31d8a6310ec8d9279, with the three BMC related patches
from https://review.coreboot.org/#/c/coreboot/+/19820/1 applied on top.
On cold boot (no power to the machine), the BMC doesn't power up
automatically. The host starts without problem. I can make the BMC boot by
reading out its rom with the patched version of flashrom linked from
https://www.raptorengineering.com/coreboot/kgpe-d16-bmc-port-status.php. I
assume that is because flashrom resets the BMC cpu at the end of the read
(the cpu=reset option).
Is this a known issue?
Thanks,
Ward.
--
Ward Vandewege
GPG Key: 25F774AB
Do you use free software? Donate to join the FSF and support freedom at
http://www.fsf.org/register_form?referrer=859
On 29.03.2018 23:58, ron minnich wrote:
> believe it or not that code runs on coreboot simulator, hardware, and qemu,
What is `coreboot simulator`?
> and gets a different answer on each.
Same binary and same processor (e.g. 32-bit protected) mode?
Without knowing what your assembler translated it to, anything seems
possible.
Nico