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.
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.
I have a KCMA-D8 motherboard with two Opteron 4226s, and 6x4GB (24GB) Hynix HMT151R7BFR4C-H9 RAM sticks. All my attempts of getting Coreboot to POST with this board so far haven't worked. I'm compiling Coreboot from Git (master branch), and can build it without issue. A pre-built Libreboot ROM (20160907) POSTs and boots fine.
For Coreboot's config, I've tried including/excluding CPU microcode updates, along with some less important-sounding options. For hardware, I've tried unplugging everything external (KB/mouse), my GPU (RX 580), and only had a single RAM stick in (slot A1). I've also tried a single CPU being powered (kept the 2nd CPU in but only had a single 4-pin CPU going to the 1st CPU).
Can anyone else confirm Git builds of Coreboot booting on this board, or provide any tips as to anything I could be missing?
I see this issue https://ticket.coreboot.org/issues/151 but there's a board status months after that that looks like it boots: https://review.coreboot.org/cgit/board-status.git/tree/asus/kcma-d8/4.7-789…
On the motherboard developed by our company (intel atom denverton 3538), there is a low performance of the processor and memory. When trying to monitor the exchange of the SVID bus lines with the oscilloscope (SVID_CLK, SVID_DATA and SVID_ALERT), no activity was noticed. Circuit design is correct (passed Intel review).
Could this be the reason for the slow speed of the processor and memory? Do I need to activate this technology in coreboot or FSP? Is there any way to check the operation of the sVID controller from Linux?
Interesting discovery about the AtomBIOS files at " g505s-atombios "
repository - https://github.com/g505s-opensource-researcher/g505s-atombios
:
While there was the same "clean" proprietary UEFI image flashed both
to "G505S with HD 8570M" and to "G505S with R5 M230" before the
AtomBIOS extraction, their AtomBIOSes for _ integrated HD 8650G _
turned out as slightly different! (see sha256)
So I made their full disassembly with this AtomDis tool -
https://cgit.freedesktop.org/~mhopf/AtomDis/ , and compared, diff
results here - https://pastebin.com/eewzswnD . As you could see from
these diff results, for some reason "G505S R5 version" sets a slightly
higher voltages for its' integrated GPU :
compared to "G505S HD version" it is 1.8% - 3.2% higher if these 0x3e
/ 0x40 / 0x6e / 0x70 values are linear and 0x0 = 0 volts.
(usNBP0Voltage / usNBP1Voltage / usVoltageID )
What do you think: would it be okay to use the integrated VGA BIOS
obtained from "G505S R5 version" for "G505S HD version" ?
This voltage difference seems small enough and the integrated GPU is
the same part after all ---> I think that it should be fine.
Dear Coreboot developers,
I installed Coreboot with ThinkPad X60s and Debian 9 and they run
successfully, but I observe a weird behavior.
Even though I had enabled blob for microcode update, the system seems
to run without it. I saw the following message in dmesg:
(I think this is not fatal since this is related to temperature
monitoring, though.)
> coretemp: Errata AE18 not fixed, update BIOS or microcode of the CPU!
For comparison, I had installed `intel-microcode` package to the
system and then the message disappeared.
Is this intended behavior, misconfiguration, or a real bug?
For reference, I uploaded the content of /proc/cpuinfo before and
after the installation of `intel-microcode` package:
https://gist.github.com/omasanori/4a1316bd78d95069f287431f5bd3a176
Also, I uploaded a report to board-status:
https://review.coreboot.org/cgit/board-status.git/commit/?id=af91ae4946fec9…
(I had also tried to install FreeBSD 12.0 and OpenBSD 6.4 but both of
their installers failed to boot just after the kernel is loaded and
located. I am not sure if this is related to this or not.)
Best regards,
Masanori
--
Masanori Ogino
Hi,
I'm working on Intel Braswell implementation and uploaded several patches.
It seems that the maintainer of the Intel Braswell is not active for review/merge/reply of the uploads.
Is the maintainer in MAINTAINERS document correct and still active?
Met vriendelijke groet / Best regards,
Frans Hendriks
Eltan B.V.
Hi coreboot folks,
in order to support TEE like Intel TXT it is necessary to be able to
clear all DRAM at boot on request.
As all of the x86 coreboot code is x86_32, it is necessary to make use
of PAE to clear memory.
Please find the attached patch series which proposes an architecure
independed API, PAE enabled memset on x86, and helper functions to
clear all DRAM on Broadwell DE:
https://review.coreboot.org/#/q/project:coreboot+branch:master+topic:securi…
The code can be easily extended to other platforms.
Please comment, test and improve the patchset.
Regards,
--
Patrick Rudolph
9elements Agency GmbH, Kortumstraße 19-21, 44787 Bochum, Germany
Email: patrick.rudolph(a)9elements.com
Phone: +49 234 68 94 188
Sitz der Gesellschaft: Bochum
Handelsregister: Amtsgericht Bochum, HRB 17519
Geschäftsführung: Sebastian Deutsch, Daniel Hoelzgen
