Lenovo T410 Coreboot
by A. Veek
-----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-----
1 month
FOSDEM Hardware Enablement Devroom
by Paul Kocialkowski
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/
1 month, 2 weeks
Re: [coreboot] Asus AM1I-A
by Elisenda Cuadros
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
>>
>>
>>
>
>
>
>
9 months
Re: [coreboot] When does AMD release the fam15 spectre microcode updates?
by Rudolf Marek
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
>
9 months, 1 week
Re: [coreboot] Out of MTRRs
by Jay Talbott
Hi Nico,
What's the status for getting the patches merged that Aaron referenced below?
Do you think they will resolve the issue that I am seeing?
Also, just a note that the three ”No more variable MTRRs: 10" messages that occur during postcar are in the log regardless of how much memory I have in the system.
Thanks,
- Jay
Jay Talbott
Principal Consulting Engineer
SysPro Consulting, LLC
3057 E. Muirfield St.
Gilbert, AZ 85298
(480) 704-8045
(480) 445-9895 (FAX)
JayTalbott(a)sysproconsulting.com
http://www.sysproconsulting.com
> -----Original Message-----
> From: Aaron Durbin [mailto:adurbin@google.com]
> Sent: Monday, March 19, 2018 10:22 AM
> To: Jay Talbott
> Cc: Coreboot
> Subject: Re: [coreboot] Out of MTRRs
>
> On Mon, Mar 19, 2018 at 10:55 AM, Jay Talbott
> <JayTalbott(a)sysproconsulting.com> wrote:
> > See below…
> > - Jay
> >
>
> [Mon Mar 19 09:41:59.840 2018] MTRR Range: Start=79fff000 End=7a000000
> (Size 1000)
> [Mon Mar 19 09:41:59.840 2018] MTRR Range: Start=7a000000 End=7a800000
> (Size 800000)
> [Mon Mar 19 09:41:59.840 2018] MTRR Range: Start=7a800000 End=7ac00000
> (Size 400000)
> [Mon Mar 19 09:41:59.840 2018] MTRR Range: Start=7ac00000 End=7ae00000
> (Size 200000)
> [Mon Mar 19 09:41:59.840 2018] MTRR Range: Start=7ae00000 End=7af00000
> (Size 100000)
> [Mon Mar 19 09:41:59.840 2018] MTRR Range: Start=7af00000 End=7af80000
> (Size 80000)
> [Mon Mar 19 09:41:59.840 2018] MTRR Range: Start=7af80000 End=7afc0000
> (Size 40000)
> [Mon Mar 19 09:41:59.840 2018] MTRR Range: Start=7afc0000 End=7afe0000
> (Size 20000)
> [Mon Mar 19 09:41:59.840 2018] MTRR Range: Start=7afe0000 End=7aff0000
> (Size 10000)
> [Mon Mar 19 09:41:59.840 2018] MTRR Range: Start=7aff0000 End=7aff8000
> (Size 8000)
> [Mon Mar 19 09:41:59.840 2018] No more variable MTRRs: 10
> [Mon Mar 19 09:41:59.840 2018] No more variable MTRRs: 10
> [Mon Mar 19 09:41:59.840 2018] No more variable MTRRs: 10
>
> This is from postcar loading. I don't understand why the code is is
> adding that many MTRR entries during postcar loading. The only that
> should be added is the ranges needed to load and run ramstage. The
> postcar MTRR code *does not* combine entries. It just determines the
> number of MTRRs to meet what is sent in. It seems 0x79fff000--7aff8000
> is being requested. That's a pretty bad request given the current
> constraints. Do you know why that was requested? And why it can't be
> more naturally aligned?
>
> Below is the final MTRR calculation in ramstage:
>
> [Mon Mar 19 09:42:04.473 2018] MTRR: Physical address space:
> [Mon Mar 19 09:42:04.473 2018] 0x0000000000000000 - 0x00000000000a0000
> size 0x000a0000 type 6
> [Mon Mar 19 09:42:04.473 2018] 0x00000000000a0000 - 0x00000000000c0000
> size 0x00020000 type 0
> [Mon Mar 19 09:42:04.473 2018] 0x00000000000c0000 - 0x000000007b800000
> size 0x7b740000 type 6
> [Mon Mar 19 09:42:04.473 2018] 0x000000007b800000 - 0x00000000c0000000
> size 0x44800000 type 0
> [Mon Mar 19 09:42:04.473 2018] 0x00000000c0000000 - 0x00000000d0000000
> size 0x10000000 type 1
> [Mon Mar 19 09:42:04.473 2018] 0x00000000d0000000 - 0x0000000100000000
> size 0x30000000 type 0
> [Mon Mar 19 09:42:04.473 2018] 0x0000000100000000 - 0x000000047f000000
> size 0x37f000000 type 6
> [Mon Mar 19 09:42:04.473 2018] MTRR: Fixed MSR 0x250 0x0606060606060606
> [Mon Mar 19 09:42:04.473 2018] MTRR: Fixed MSR 0x258 0x0606060606060606
> [Mon Mar 19 09:42:04.473 2018] MTRR: Fixed MSR 0x259 0x0000000000000000
> [Mon Mar 19 09:42:04.473 2018] MTRR: Fixed MSR 0x268 0x0606060606060606
> [Mon Mar 19 09:42:04.473 2018] MTRR: Fixed MSR 0x269 0x0606060606060606
> [Mon Mar 19 09:42:04.473 2018] MTRR: Fixed MSR 0x26a 0x0606060606060606
> [Mon Mar 19 09:42:04.473 2018] MTRR: Fixed MSR 0x26b
> 0x0606060606060606
> [Mon Mar 19 09:42:04.480 2018] MTRR: Fixed MSR 0x26c 0x0606060606060606
> [Mon Mar 19 09:42:04.480 2018] MTRR: Fixed MSR 0x26d
> 0x0606060606060606
> [Mon Mar 19 09:42:04.480 2018] MTRR: Fixed MSR 0x26e
> 0x0606060606060606
> [Mon Mar 19 09:42:04.480 2018] MTRR: Fixed MSR 0x26f 0x0606060606060606
> [Mon Mar 19 09:42:04.480 2018] call enable_fixed_mtrr()
> [Mon Mar 19 09:42:04.480 2018] CPU physical address size: 39 bits
> [Mon Mar 19 09:42:04.480 2018] MTRR: default type WB/UC MTRR counts:
> 6/11.
> [Mon Mar 19 09:42:04.480 2018] MTRR: WB selected as default type.
> [Mon Mar 19 09:42:04.480 2018] MTRR: 0 base 0x000000007b800000 mask
> 0x0000007fff800000 type 0
> [Mon Mar 19 09:42:04.480 2018] MTRR: 1 base 0x000000007c000000 mask
> 0x0000007ffc000000 type 0
> [Mon Mar 19 09:42:04.480 2018] MTRR: 2 base 0x0000000080000000 mask
> 0x0000007fc0000000 type 0
> [Mon Mar 19 09:42:04.480 2018] MTRR: 3 base 0x00000000c0000000 mask
> 0x0000007ff0000000 type 1
> [Mon Mar 19 09:42:04.480 2018] MTRR: 4 base 0x00000000d0000000 mask
> 0x0000007ff0000000 type 0
> [Mon Mar 19 09:42:04.480 2018] MTRR: 5 base 0x00000000e0000000 mask
> 0x0000007fe0000000 type 0
> [Mon Mar 19 09:42:04.480 2018] MTRR: Fixed MSR 0x250 0x0606060606060606
> [Mon Mar 19 09:42:04.480 2018] MTRR: Fixed MSR 0x258 0x0606060606060606
> [Mon Mar 19 09:42:04.480 2018] MTRR: Fixed MSR 0x259 0x0000000000000000
> [Mon Mar 19 09:42:04.480 2018] MTRR: Fixed MSR 0x268 0x0606060606060606
> [Mon Mar 19 09:42:04.480 2018] MTRR: Fixed MSR 0x269 0x0606060606060606
> [Mon Mar 19 09:42:04.480 2018] MTRR: Fixed MSR 0x26a 0x0606060606060606
> [Mon Mar 19 09:42:04.480 2018] MTRR: Fixed MSR 0x26b
> 0x0606060606060606
> [Mon Mar 19 09:42:04.486 2018] MTRR: Fixed MSR 0x26c 0x0606060606060606
> [Mon Mar 19 09:42:04.486 2018] MTRR: Fixed MSR 0x26d
> 0x0606060606060606
> [Mon Mar 19 09:42:04.486 2018] MTRR: Fixed MSR 0x26e
> 0x0606060606060606
> [Mon Mar 19 09:42:04.486 2018] MTRR: Fixed MSR 0x26f 0x0606060606060606
> [Mon Mar 19 09:42:04.486 2018] MTRR: TEMPORARY Physical address space:
> [Mon Mar 19 09:42:04.486 2018] call enable_fixed_mtrr()
> [Mon Mar 19 09:42:04.486 2018] 0x0000000000000000 - 0x00000000000a0000
> size 0x000a0000 type 6
> [Mon Mar 19 09:42:04.486 2018] 0x00000000000a0000 - 0x00000000000c0000
> size 0x00020000 type 0
> [Mon Mar 19 09:42:04.486 2018] 0x00000000000c0000 - 0x000000007b800000
> size 0x7b740000 type 6
> [Mon Mar 19 09:42:04.486 2018] 0x000000007b800000 - 0x00000000ffe00000
> size 0x84600000 type 0
> [Mon Mar 19 09:42:04.486 2018] 0x00000000ffe00000 - 0x0000000100000000
> size 0x00200000 type 5
> [Mon Mar 19 09:42:04.486 2018] 0x0000000100000000 - 0x000000047f000000
> size 0x37f000000 type 6
> [Mon Mar 19 09:42:04.486 2018] CPU physical address size: 39 bits
> [Mon Mar 19 09:42:04.486 2018] MTRR: Removing WRCOMB type. WB/UC
> MTRR
> counts: 13/11 > 8.
> [Mon Mar 19 09:42:04.486 2018] MTRR: Fixed MSR 0x250 0x0606060606060606
> [Mon Mar 19 09:42:04.486 2018] MTRR: Fixed MSR 0x250 0x0606060606060606
> [Mon Mar 19 09:42:04.486 2018] MTRR: Fixed MSR 0x258 0x0606060606060606
> [Mon Mar 19 09:42:04.486 2018] MTRR: Fixed MSR 0x259 0x0000000000000000
> [Mon Mar 19 09:42:04.486 2018] MTRR: Fixed MSR 0x268 0x0606060606060606
> [Mon Mar 19 09:42:04.859 2018] MTRR: Fixed MSR 0x269 0x0606060606060606
> [Mon Mar 19 09:42:04.859 2018] MTRR: Fixed MSR 0x26a 0x0606060606060606
> [Mon Mar 19 09:42:04.859 2018] MTRR: Fixed MSR 0x26b
> 0x0606060606060606
> [Mon Mar 19 09:42:04.859 2018] MTRR: Fixed MSR 0x26c 0x0606060606060606
> [Mon Mar 19 09:42:04.859 2018] MTRR: Fixed MSR 0x26d
> 0x0606060606060606
> [Mon Mar 19 09:42:04.859 2018] MTRR: Fixed MSR 0x26e
> 0x0606060606060606
> [Mon Mar 19 09:42:04.859 2018] MTRR: Fixed MSR 0x26f 0x0606060606060606
> [Mon Mar 19 09:42:04.859 2018] MTRR: Fixed MSR 0x258 0x0606060606060606
> [Mon Mar 19 09:42:04.859 2018] call enable_fixed_mtrr()
> [Mon Mar 19 09:42:04.859 2018] MTRR: Fixed MSR 0x259 0x0000000000000000
> [Mon Mar 19 09:42:04.859 2018] MTRR: Fixed MSR 0x268 0x0606060606060606
> [Mon Mar 19 09:42:04.859 2018] MTRR: Fixed MSR 0x269 0x0606060606060606
> [Mon Mar 19 09:42:04.859 2018] MTRR: Fixed MSR 0x26a 0x0606060606060606
> [Mon Mar 19 09:42:04.859 2018] MTRR: Fixed MSR 0x26b
> 0x0606060606060606
> [Mon Mar 19 09:42:04.859 2018] MTRR: Fixed MSR 0x26c 0x0606060606060606
> [Mon Mar 19 09:42:04.859 2018] MTRR: Fixed MSR 0x26d
> 0x0606060606060606
> [Mon Mar 19 09:42:04.859 2018] MTRR: Fixed MSR 0x26e
> 0x0606060606060606
> [Mon Mar 19 09:42:04.859 2018] MTRR: Fixed MSR 0x26f 0x0606060606060606
> [Mon Mar 19 09:42:04.859 2018] CPU physical address size: 39 bits
> [Mon Mar 19 09:42:04.859 2018] call enable_fixed_mtrr()
> [Mon Mar 19 09:42:04.859 2018] MTRR: default type WB/UC MTRR counts:
> 13/11.
> [Mon Mar 19 09:42:04.859 2018] MTRR: UC selected as default type.
> [Mon Mar 19 09:42:04.859 2018] CPU physical address size: 39 bits
> [Mon Mar 19 09:42:04.859 2018] MTRR: 0 base 0x0000000000000000 mask
> 0x0000007fc0000000 type 6
> [Mon Mar 19 09:42:04.859 2018] MTRR: 1 base 0x0000000040000000 mask
> 0x0000007fe0000000 type 6
> [Mon Mar 19 09:42:04.865 2018] MTRR: 2 base 0x0000000060000000 mask
> 0x0000007ff0000000 type 6
> [Mon Mar 19 09:42:04.865 2018] MTRR: 3 base 0x0000000070000000 mask
> 0x0000007ff8000000 type 6
> [Mon Mar 19 09:42:04.865 2018] MTRR: 4 base 0x0000000078000000 mask
> 0x0000007ffc000000 type 6
> [Mon Mar 19 09:42:04.865 2018] MTRR: 5 base 0x000000007b800000 mask
> 0x0000007fff800000 type 0
> [Mon Mar 19 09:42:04.865 2018] MTRR: 6 base 0x00000000ffe00000 mask
> 0x0000007fffe00000 type 5
> [Mon Mar 19 09:42:04.865 2018] MTRR: 7 base 0x0000000100000000 mask
> 0x0000007f00000000 type 6
> [Mon Mar 19 09:42:04.865 2018] Taking a reserved OS MTRR.
> [Mon Mar 19 09:42:04.865 2018] MTRR: 8 base 0x0000000200000000 mask
> 0x0000007e00000000 type 6
> [Mon Mar 19 09:42:04.865 2018] Taking a reserved OS MTRR.
> [Mon Mar 19 09:42:04.865 2018] MTRR: 9 base 0x0000000400000000 mask
> 0x0000007f80000000 type 6
> [Mon Mar 19 09:42:04.865 2018] Taking a reserved OS MTRR.
> [Mon Mar 19 09:42:04.865 2018] ERROR: Not enough MTRRs available! MTRR
> indexis 10 with 10 MTTRs in total.
> [Mon Mar 19 09:42:04.865 2018] Not enough MTRRs: 11 vs 10
> [Mon Mar 19 09:42:04.865 2018] Unable to insert temporary MTRR range:
> 0x00000000ffe00000 - 0x0000000100000000 size 0x00200000 type 5
> [Mon Mar 19 09:42:04.865 2018]
> [Mon Mar 19 09:42:04.865 2018] MTRR check
> [Mon Mar 19 09:42:04.865 2018] Fixed MTRRs : Enabled
> [Mon Mar 19 09:42:04.865 2018] Variable MTRRs: Enabled
>
> Looks like the temporary mapping is causing all the spam. You could do
> a couple fo things: don't try calling mtrr_use_temp_range().
> Additionally you could set your settings differently such that it
> reduces the MTRR pressure; something like requesting different io hole
> sizes, etc.
>
> 0x0000000100000000 - 0x000000047f000000 size 0x37f000000 type 6
>
> That one hurts a lot. Count the bits set in the size. That's 9 entries
> right there.
>
> Nico has some patches outstanding that could possibly better optimize
> this condition. https://review.coreboot.org/#/c/coreboot/+/21915/ and
> 2 more on top.
9 months, 3 weeks
Assigning PCI resources clobbers console with io-mapped / memory-mapped UART
by Jay Talbott
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
9 months, 3 weeks
Re: [coreboot] shrdw question
by Nico Huber
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
9 months, 3 weeks
Re: [coreboot] shrdw question
by Nico Huber
On 29.03.2018 20:25, ron minnich wrote:
> I have the following code:
>
> movl $0x12345678, %eax
> movl $0xaaaabbbb, %ebx
> movb $0x10, %cl
> shrdw %ebx, %eax
If I had to assemble it, I would have refuse it... *w with 32-bit
registers? how should that work?
Though, after reading a little about AT&T, I found this:
"In AT&T syntax, the size of memory operands is determined from
the last character of the opcode name." [1]
Memory operands, heh, no memory operands here... but the GNU as
manual talks about operands in general and that it may infer the
suffix from register operands, hmmm, no word about what happens
if register operands don't match the suffix.
I've also tried to find a quote about the third operand. Is it
%cl implicitly? I would think so, but is it written anywhere?
Could also be implicitly $0, ok that would never make sense.
> quiz: what's the value of %ax after this instruction?
I guess it depends on the assembler you use. non-zero?
TIL, you can't shift by 32 bits this way.
Nico
[1]
https://web.archive.org/web/20131003180256/http://www.ibm.com/developerwo...
9 months, 3 weeks
