Re: [coreboot] AMD IMC open source firmware replacement
by Rudolf Marek
Dne 30.5.2018 v 16:06 Mike Banon napsal(a):
> Hi Rudolf,
>
> Regarding this part:
> " To check if IMC is active check if PCI 0:14.3 0x40 bit7 set. "
> what command do I need to use to check this?
Try:
sudo setpci -s 14.3 40.b
Despite command name, it will print the value.
Thanks
Rudolf
1 week, 2 days
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, 1 week
Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
by Jonathan Neuschäfer
On Fri, Jun 22, 2018 at 03:04:06PM +0800, Shawn wrote:
> Hi Jonathan,
>
> On Thu, Jun 21, 2018 at 7:48 PM, Jonathan Neuschäfer
[...]
> > With the unfinished coreboot port, I want it to look like this (although
> > *a lot* of work has to be done on coreboot first, and I'm currently not
> > actively working on that, for a few months):
> >
> > MSEL (ROM0) -> ZSBL (ROM1) -> coreboot (+bbl?) -> Linux, or
> > MSEL (ROM0) -> coreboot (+bbl?) -> Linux
> >
> > ZSBL can be skipped, so you don't need to run closed source ROM code, at
> > least as far as the hardware is concerned.
> >
> Is ZSBL really can be skipped? I thought it was part of internal ROM
> inside the chip.
Yes. If you set the MSEL switches to 0001, the code in the MSEL ROM
(aka. ROM0) jumps directly into the memory-mapped SPI flash, instead of
into the big ROM1, where ZSBL is.
Coreboot doesn't yet support this mode, but the hardware allows it.
> > (And note that this is just the situation on this particular SoC. Other
> > SoCs from SiFive or other vendors may boot differently.)
> >
> Well, if FSBL is the place where coreboot comes into play, we might
> only have two options: 1, Reversing the FSBL which is ~9k assembly LOC
> 2, SiFive make the FSBL open source( I don't see any reason why they
> don't do it if they intend to build an open eco-system for RISC-V).
A high-level list of tasks that FSBL performs is in the manual[1]:
• Switch core frequency to 1 GHz (or 500 MHz if TLCLKSEL =1) by
configuring and running off the on-chip PLL
• Configure DDR PLL, PHY, and controller
• Set GEM GXL TX PLL to 125 MHz and reset it
• If there is an external PHY, reset it
• Download BBL from a partition with GUID type
2E54B353-1271-4842-806F-E436D6AF69851
• Scan the OTP for the chip serial number
• Copy the embedded DTB to DDR, filling in FSBL version, memory
size, and MAC address
• Enable 15 of the 16 L2 ways (this removes almost all of the L2
LIM memory)
• Jump to DDR memory (0x8000_0000)
Initializing the PLLs and reading the OTP ROM should be easy enough
because both are documented in, I think, sufficient detail.
Section 20.3 describes the initialization sequence for the DRAM
controller, but leaves out the values for the register for "memory
timing settings, PAD mode configuration, initialization, and training."
It says: "Please contact SiFive directly to determine the complete
register settings for your application."
I will ask on the forum.
Assuming that SiFive will tell us the values of the missing
configuration registers, I don't think we need to reverse-engineer FSBL.
Greetings,
Jonathan Neuschäfer
[1]: https://www.sifive.com/documentation/chips/freedom-u540-c000-manual/
4 months
x86 SMM handler Local APIC assumptions
by Andrew Cooper
Hello,
While looking at some code, I noticed that twice (once in asm, and again
later in C), the SMM handler assumes that 0xfee00020 is the APIC_ID
reigster in the xAPIC MMIO window.
This isn't true if the OS has moved the MMIO window, or switched to
x2apic mode (on supporting hardware).
As a result, it looks like its rather easy to feed a kernel-controlled
value into Coreboot's idea of its Local APIC id, which can either be the
same on all cores (reuse of the same stack) or wildly out of range
(albeit, at least bounded to 255).
To fix, I'd expect Coreboot to read MSR_APIC_BASE, and either cope with
x2apic mode (which is surely easier than switching APIC mode, as you've
got to cycle through off to switch back to xAPIC mode), or
save/remap/restore the APIC MMIO window.
Without paging, you can't address an APIC MMIO window above the 4G boundary.
Is this something you care about?
Thanks,
~Andrew
4 months, 3 weeks
Re: [coreboot] POWER9 / Talos II coreboot support?
by Timothy Pearson
As of late last week:
W have the processor user guide, full register documentation, and a
smattering of other resources released publicly [1]. The PHB
documentation is still in process and still moving forward, along with
the electrical datasheet.
If you are interested in documentation that isn't already available and
isn't on the to-do list, please let me know. My understanding is that
the list above should be pretty much everything needed for firmware work.
[1] https://wiki.raptorcs.com/wiki/Category:Documentation
On 06/07/2018 08:05 PM, ron minnich wrote:
> where are we on the docs at this point
>
>
> On Thu, Jun 7, 2018 at 5:59 PM Timothy Pearson
> <tpearson(a)raptorengineering.com <mailto:tpearson@raptorengineering.com>>
> wrote:
>
> For anyone wanting a more affordable development platform for POWER9,
> check out the Talos II Lite:
>
> https://raptorcs.com/TALOSIILITE/
>
> Hopefully we're getting down to a price point where coreboot development
> becomes more practical (if still a bit painful)?
>
> Looking forward to seeing coreboot on ppc64el systems!
>
> On 05/29/2018 03:45 PM, Timothy Pearson wrote:
>> Sorry, can't add today....it's a little over 6,000 pages of new
>> documentation. Still, hardly light reading!
>
>> On 05/29/2018 03:39 PM, Timothy Pearson wrote:
>>> Register documentation was published today. Links to the three
> volumes
>>> (over 7000 pages of documentation!)
>
>>>
> https://wiki.raptorcs.com/wiki/File:POWER9_Registers_vol1_version1.1_pub.pdf
>
>>>
> https://wiki.raptorcs.com/wiki/File:POWER9_Registers_vol2_version1.2_pub.pdf
>
>>>
> https://wiki.raptorcs.com/wiki/File:POWER9_Registers_vol3_version1.2_pub.pdf
>
>>> That leaves only the PHB documentation in process at this point.
> Almost
>>> there....
>
>>> On 05/12/2018 02:34 AM, Timothy Pearson wrote:
>>>> On 05/03/2018 06:02 PM, ron minnich wrote:
>
>
>>>>> On Thu, May 3, 2018 at 1:20 PM Timothy Pearson
>>>>> <tpearson(a)raptorengineering.com
> <mailto:tpearson@raptorengineering.com>
> <mailto:tpearson@raptorengineering.com
> <mailto:tpearson@raptorengineering.com>>>
>>>>> wrote:
>
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA256
>
>>>>> I think I was being a bit pessimistic / too careful here.
> We're close
>>>>> to getting the docs publicly released, but that doesn't
> help anyone
>>>>> wanting access right now, which is why I mentioned the
> other route.
>>>>> IBM's committed to getting the documentation released,
> they're just
>>>>> making sure that what they release is actually correct for
> the products
>>>>> it covers.
>
>>>>> It might make sense to get our "working group" together
> over the next
>>>>> few weeks, by which time the documentation should be
> available in public
>>>>> form.
>
>>>>> Are you interested in joining? :-)
>
>
>>>>> of course, but not until those docs are freed up.
>
>
>>>> We're getting there. First manual to be released is the
> processor user
>>>> guide. More to follow, including register documentation, in
> around a week.
>
>>>> Users guide:
>
>>>>
> https://wiki.raptorcs.com/wiki/File:POWER9_um_OpenPOWER_v20GA_09APR2018_p...
>
>>>>> Context: I've been trying for 2 years now to get OPAL released
> under
>>>>> dual gpl2 licensing with the current apache2 license, apache2
> and gpl2
>>>>> are not compatible, so we'd be in a bit of a mess should we use
> OPAL
>>>>> code in coreboot, and it would be easiest if we were able to
> use some of
>>>>> that code.
>
>>>>> The first response from IBM was "why do you think you need
> coreboot?" I
>>>>> worked through that, and there was agreement in the end it ought to
>>>>> happen, said agreement reached about 2 years ago. Stuff Would
> Happen, I
>>>>> was told. After that, silence.
>
>>>> We've reignited this. It's underway. :-)
>
>>>>> This is pretty much par for the course with Power. In 1990 I
> spent two
>>>>> years getting an agreement that would allow me to .... get more
> agreements.
>
>>>> We've plowed through this already and are at the action point.
> For the
>>>> most part, just let me know what you need and I'll see if we can
> get it
>>>> published.
>
>>>>> So close doesn't count. Once I see the kind of docs I need to
> see, not
>>>>> requiring a clickwrap, and covering all aspects of every chip
> on your
>>>>> board, I'm in: I'll order a board. Until then, I can't really
> do much.
>
>>>> Is the NIC an issue? There are several people working on REing the
>>>> hardware with some great progress [1][2], but there's really no
> way to
>>>> get Broadcom to ever release official documentation. Everything
> else on
>>>> the libre-friendly non-SAS version either has docs available or
> we are
>>>> close to getting them published.
>
>>>>> Thanks for your efforts on Power!
>
>>>> No problem! We still consider Power the best path forward for
> powerful
>>>> libre systems at this point, getting really tired of the other
> vendors
>>>> actively working against efforts to create open firmware (this
> includes
>>>> SiFive at this point).
>
>>>> Will keep you posted as we get more docs published online, but
> thought
>>>> you and the others here might at least be interested in the
> users guide.
>
>>>>> ron
>
>
>
>>>> [1] https://wiki.raptorcs.com/wiki/BCM5719
>>>> [2] IRC discussions on #talos-workstation
>
>
>
>
--
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
5 months, 2 weeks
Re: [coreboot] USB to Serial Converters
by David Hendricks
[re-adding the list while we're at it]
On Tue, Jul 31, 2018 at 2:34 PM, David Hendricks
<david.hendricks(a)gmail.com> wrote:
> Hi Zahra,
> That header may be out of date
> (https://mail.coreboot.org/pipermail/coreboot/2017-August/084800.html).
>
> I had to manually download the microcode file corresponding to my
> processor SKU from Intel. Use the link I sent you earlier to download
> Baytrail_FSP_Gold4.tgz and see if the microcode headers included in
> that tarball match your processor. The Atom on my Minnowboard Turbot
> has a CPUID of 30679, so I needed to use M0130679901.h.
>
> (note that the Minnowboard Max uses an Atom E3825, while the Turbot
> uses an E3826 dual-core SoC or E3845 quad-core SoC)
>
> On Mon, Jul 30, 2018 at 2:36 AM, zahra rahimkhani
> <zrahimkhani2014(a)gmail.com> wrote:
>>
>> Dear David
>>
>> for Microcode file I just it from coreboot source from this path
>> coreboot/3rdparty/blobs/soc/intel/baytrail/microcode_blob.h
>>
>> Is that good ?
>>
>> Thanks ,
>>
>>
>> On Sun, Jul 29, 2018 at 1:18 PM zahra rahimkhani <zrahimkhani2014(a)gmail.com>
>> wrote:
>>>
>>> Hi David,
>>>
>>> Thank you very much for your guide.
>>>
>>> I got this comments on my config and changes it based on your config.
>>> But I can not see any thing on output.
>>> Could you tell me which Uart pins do you use on Minnowboard max
>>>
>>> I used it 6 pin that are separately on board .
>>>
>>> I would be grateful if you guide me .
>>> I got my new config here .
>>> https://paste.flashrom.org/view.php?id=3097
>>>
>>> Also , Could you tell me what is this parameter
>>> CONFIG_UART_FOR_CONSOLE=0
>>> and
>>> CONFIG_DRIVERS_UART_8250IO
>>>
>>> Cheers!
>>> Zahra
>>>
>>>
>>>
>>> On Fri, Jul 27, 2018 at 11:06 AM David Hendricks
>>> <david.hendricks(a)gmail.com> wrote:
>>>>
>>>> Hi Zahra,
>>>>
>>>>> I got my config file here
>>>>> https://paste.flashrom.org/view.php?id=3096
>>>>
>>>>
>>>> Thanks, that helps a lot!
>>>>
>>>> The last config that I tested is
>>>> https://review.coreboot.org/cgit/board-status.git/plain/intel/minnowmax/4...
>>>>
>>>> If you diff my config and yours, it seems you have several options
>>>> disabled which I think you should try enabling:
>>>> CONFIG_HAVE_IFD_BIN
>>>> CONFIG_HAVE_ME_BIN
>>>> CONFIG_TTYS0_LCS
>>>> CONFIG_DRIVERS_UART_8250IO
>>>> CONFIG_IFD_BIN_PATH
>>>> CONFIG_ME_BIN_PATH
>>>> CONFIG_LOCK_MANAGEMENT_ENGINE
>>>> CONFIG_DRIVERS_UART
>>>> CONFIG_CONSOLE_SERIAL
>>>> CONFIG_CONSOLE_SERIAL_115200
>>>>
>>>> You can find these by using the search function in `make menuconfig`.
>>>> Press '/' and type a Kconfig option.
>>>>
>>>>> I would be grateful if you check my config and tell me what is ifdtool
>>>>> in Coreboot and how
>>>>> I use it.
>>>>> and How I find Intel ME file for my board and GBE for a network on my
>>>>> board.
>>>>
>>>>
>>>> ifdtool is a tool for viewing and manipulating an Intel Flash Descriptor
>>>> binary. The flash descriptor is a 4KB data structure at the start of the
>>>> ROM's address space (offset 0x000000-0x000fff).
>>>>
>>>> To build it: `make -C util/ifdtool`
>>>> To run it: `util/ifdtool/ifdtool`
>>>>
>>>> You'll probably want to use the '-x' option to extract the individual
>>>> modules from an existing Minnowboard Max firmware image (e.g. the UEFI image
>>>> that comes with the board). That will give you the ME and GBE files.
>>>>
>>
5 months, 2 weeks
Cold boot issue on Lenovo X201i with libgfxinit
by Matthias Gazzari
Hi Arthur,
commit "4c2f26c9fc37c65b23bf10fbe6d8389e50d04483 nb/intel/nehalem:
Remove the C native graphic init" introduced the following issue on the
Lenovo X201i:
Seabios does not find any hard drives when cold booting (it times out).
I have to press Ctr+Alt+Del to reboot Seabios in order to be able to
boot from the hard drive. Rebooting does not trigger this bug. Maybe
this is a libgfxinit issue?
Cheers,
Matthias
5 months, 2 weeks
Re: [coreboot] More ACPI errors on Lenovo X201i
by Patrick Rudolph
Hi Matthias,
On 2018-07-23 03:32 PM, Matthias Gazzari wrote:
> Hi Patrick,
>
> I found new ACPI errors on my Lenovo X201i:
>
> commit "60eca531df ec/lenovo/h8/acpi: Add WWAN ACPI methods" introduces
> the following error just before shutdown:
>
> thinkpad_acpi_ acpi_evalf(\WGSV, vd, ...) failed: AE_NOT_FOUND
>
Is expected, as the method doesn't exists in coreboot.
I'm working on a cmos acpi driver, allowing easy integration of that
method.
If you want you can implement a stub driver (emtpy function) in the
meantime.
> and commit "31fb846c59 ec/lenovo/h8/acpi: Apply state on wake"
> introduces the following errors on boot:
>
> ACPI Error: No handler for Region [ERAM] ( (ptrval))
> [EmbeddedControl] (20180313/evregion-132)
> ACPI Error: Region EmbeddedControl (ID=3) has no handler
I've no idea what the problem is.
Is there an ACPI expert here ?
> (20180313/exfldio-265)
> ACPI Error: Method parse/execution failed \_SB.PCI0.LPCB.EC.HKEY._INI,
> AE_NOT_EXIST (20180313/psparse-516)
> ACPI Error: AE_NOT_EXIST, during \_SB.PCI0.LPCB.EC.HKEY._INI execution
> (20180313/nsinit-670)
>
> Cheers,
> Matthias
Regards,
Patrick
5 months, 2 weeks
Re : restrict SMI
by echelon＠free.fr
Thank you Ron,
Just curious, about who could be the originator of this "future OS requirement", but I guess that anyone can guess his identity.. ;-)
Anyway is good to see that common sense prevails (SMM dies) .. finally .. but I fear that the "clients" that until now were dependent of this kind of service will "migrate" to another "service provider".. (give me a "M", give me a "E", .. oh nevermind.. sorry just jocking .. lets not start another flame war.. ;-))
Florentin
----- Mail d'origine -----
De: ron minnich <rminnich(a)gmail.com>
À: coreboot <coreboot(a)coreboot.org>
Envoyé: Sun, 29 Jul 2018 23:54:19 +0200 (CEST)
Objet: [coreboot] restrict SMI
Florentin wrote this:
I just peeked inside the pdf and tumbled upon the following statement
(page4):
"The latest reasoning for replacement of SMI is driven by a future OS
requirement that
restricts the use of SMI as a means to communicate with the system
firmware."
Can someone enlighten me what this "future OS requirement" means?..
Thanks in advance,
Florentin
OK, the future OS requirement is not complicated in my view. Nobody trusts
SMM, or should ever have trusted SMM from the beginning, and many companies
have reached the decision that SMM is a monstrous security hole and must
die. SMI being the way one gets into SMM, both SMI and SMM are, we hope,
soon to be a thing of the past. Not soon enough for me ...
ron
5 months, 2 weeks
