I have tested coreboot on both the asus/p2b and asus/p2-99 and it
seems to work fine. I had previously commented on the mailing list
instead of these patches and then never really followed up on it.
I meant to retest and comment on the change sets on gerrit (22977 and
22965) before they got abandoned, but got around to it too late. I
wasn't sure what to do about it now, I commented on one of the
patches, but it doesn't seem to send out emails with an abandoned
status. I should have received a copy if it did, right?
I originally only brought up that it worked since Keith Hui was
working on updating Intel 440BX support. I haven't actually done
anything to help with supporting coreboot though.
Enabling X86EMU_DEBUG_TIMINGS config option will cause the compilation to fail with:
In file included from src/device/oprom/yabel/debug.h:48,
src/device/oprom/yabel/biosemu.c: In function 'biosemu':
src/device/oprom/yabel/debug.h:103:66: error: implicit declaration of function 'current_time_from' [-Werror=implicit-function-declaration]
103 | #define DEBUG_PRINTF_CS_IP(_x...) DEBUG_PRINTF("[%08lx]%x:%x ", (current_time_from(&zero)).microseconds, M.x86.R_CS, M.x86.R_IP); DEBUG_PRINTF(_x);
It seems there isn't current_time_from() defined anywhere.
From: Petr Cvek <petrcvekcz(a)gmail.com>
PCIe port 4 is used for miniPCIe slot (wifi). Should be enabled.
Signed-off-by: Petr Cvek <petrcvekcz(a)gmail.com>
src/mainboard/kontron/986lcd-m/devicetree.cb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mainboard/kontron/986lcd-m/devicetree.cb b/src/mainboard/kontron/986lcd-m/devicetree.cb
index 5db7551d12..9f3655c7e0 100644
@@ -43,7 +43,7 @@ chip northbridge/intel/i945
device pci 1c.0 on end # PCIe
device pci 1c.1 on end # PCIe
device pci 1c.2 on end # PCIe
- device pci 1c.3 off end # PCIe port 4
+ device pci 1c.3 on end # PCIe port 4, miniPCIe
device pci 1c.4 off end # PCIe port 5
device pci 1c.5 off end # PCIe port 6
device pci 1d.0 on end # USB UHCI
Platforms like the x230 have two flash ROMs which are virtually treated
as a single one.
1. What the heck is the meaning of this? Why do vendors buy and solder
two small chips (even worse, on the x230, one with 8M and one with
4M) instead of a single big one? Is this cheaper? Sounds unlikely to
me, in technics one big thing is usually cheaper than several small
ones. Beyond that, I imagine you have some effort to concatenate the
two chips virtually.
2. The manual for the x230  (is there a version in the new
documentation btw?) states that you can just flash the smaller (4M)
chip and then you're done. So I assume:
1. the 4M chip is the one the CPU first executes code from
2. neither coreboot nor the payload will ever jump "into" the larger
chip, therefore code from it will not be executed.
3. Therefore, it does not matter if you overwrite the 8M chip or
But what lays on this larger ROM? What if there are parts of the IME on
it I would like to annihilate?
The whole thing is really awkward to me. Especially, because the
predecessor x220 already has a place on the board ready to host the
second chip, but it was left empty on this device.
First of all thank you for your great work, I mean coreboot, it's really
I have mainboad Supermicro X11SSM-F rev 1.01, which almost the same as
supported X11SSH-TF. Any chance that it will work fine with ROM for
I am using "GRUB-2" as a direct payload for a Denverton based implementation.
Is it possible to invoke a payload which is programmed as a separate Image (not as a part of cbfs coreboot image) within a BOOT flash ?
If not, then what are the areas do we need to modify in a state-machine to implement the same ?
Thanks in advance,