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-7...
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
> 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:
Also, I uploaded a report to board-status:
(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.)
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,
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:
The code can be easily extended to other platforms.
Please comment, test and improve the patchset.
9elements Agency GmbH, Kortumstraße 19-21, 44787 Bochum, Germany
Phone: +49 234 68 94 188
Sitz der Gesellschaft: Bochum
Handelsregister: Amtsgericht Bochum, HRB 17519
Geschäftsführung: Sebastian Deutsch, Daniel Hoelzgen
Thank you for your reply.
On Mon, Feb 25, 2019 at 4:27 AM Lance Zhao <lance.zhao(a)gmail.com> wrote:
> Current coreboot should have same level of microcode compare to intel-microcode for Linux.
Indeed. I saw a commit updating Intel microcode in last December, so I
am sure the microcode is not so ancient that it does not contain the
fix for a known errata.
A change  has been approved that applys a minimum loglevel of BIOS_DEBUG
for CBMEM console. There should be miminal performance impact as it is
nothing but writes to cacheable memory.
For some platform this could cause that pre-ram console buffer runs out of
space. My opinion is that those are too verbose and some logging should be
moved to BIOS_SPEW. If you are debugging raminit you cannot rely on
readable CBMEM console anyways so I suggest against increasing the pre-ram