Dear Michal,
I am sorry for the late reply but on Friday something went wrong with my coreboot installation and was unable to boot and I have to reinstall it again and I just resumed this morning on this issue.
(you) don't think loading the watchdog module will help in any way, actually the opposite.
(Me) I did the modprobe of the watchdog module just to ask linux to give me the base address of the runtime registers "0xa00" of the original bios.
(you) I recommend using https://github.com/adurbin/iotools
(you) Superiotool will simply dump all registers and may alternatively dump IO too.
(Me) Thank you for your great advice I will go by the Superiotool route (patching it) but so far I am dumping using "ioports" in the following way:
on root:
for i in $(seq 0xa00 0xa7f); do echo -n "$i: "; inb $i; done; $i = $((++i))
(you) I assume you have configured runtime registers IOBASE right?
(Me) I found out (because of your advise) that the runtime registers base address was wrong on my devicetree (0xe00 instead 0xa00) I set it correctly then linux was able to "see" this range and dumped the registers with the string shown above.
Now I can compare both dumps and I can see the pins for the UART ports 2-4 are all GPIO inputs (1).
(Me) I set manually the GPIOs from linux using ioport's function outb and all the 4 ports work correctly.
Now I am trying to set from coreboot but I am still unsuccessful.
Looking at you dell Optiplex 9010 you set the following runtime registers under romstage.c -> mainboard_early_init
/* Disable SMIs and clear SMI status */
outb(0, SCH5545_RUNTIME_REG_BASE + SCH5545_RR_SMI_EN);
outb(SCH5545_SMI_GLOBAL_STS, SCH5545_RUNTIME_REG_BASE + SCH5545_RR_SMI_STS);
and I do similar to you under romstage.c -> mainboard_early_init:
outb(0x55, 0x2e);
outb(0x05, 0x0a3f); /* GP50= RI_2 : in */
outb(0x05, 0x0a40); /* GP51= DCD_2 : in */
outb(0x05, 0x0a41); /* GP52= RXD_2 : in */
outb(0x04, 0x0a42); /* GP53= TXD_2 : out */
outb(0x05, 0x0a43); /* GP54= DSR_2 : in */
outb(0x04, 0x0a44); /* GP55= RTS_2 : out */
outb(0x05, 0x0a45); /* GP56= CTS_2 : in */
outb(0x04, 0x0a46); /* GP57= DTR_2 : out */
outb(0xaa, 0x2e);
but It doesn't work.
Also I set the same code under mainboard.c -> mainboard_init but neither work.
Any advice on this? because I cannot find any information on the datasheet on how to set those registers and I suppose I just have to set to the 0xa00 base address + register.
Thank you,
Jose Trujillo.
Hello,
I have an Asus KGPE-D16 motherboard, is it possible, as far as you know, to flash coreboot with the internal method, i.e. using flashrom on Ubuntu/Debian?
Moreover I would like to know if is possible to download the coreboot.rom from anywhere (maybe with seabios included)
Thank you very much!
Best regards
Alessio
Hello everyone,
I came across an old T410 that I'd like to install coreboot on to swap the wifi-adapter, remove the IME and overall "upgrade" the laptop a bit.
Now, though many other Thinkpads from that era are well supported, the T410 was still unsupported until it was added recently in 4.11 and I've read conflicting reports on how well it works with coreboot.
The official documentation (https://doc.coreboot.org/mainboard/lenovo/t410.html) only mentions issues with the dock and vboot, which is fine by me. Also, this patch looks quite promising - https://review.coreboot.org/c/coreboot/+/11791
Is that already part of the main repository as of 4.12 or do I have to add it somehow?
Also, the documentation links to a tutorial for flashing a powered chip, yet I have read that people have used guides for other laptops using USB programmers and (more or less successfully) flashed the laptop. Is it possible to use a ch431a programmer at 3.3v while the laptop is powered down or could that seriously damage the hardware?
Is there anything else I should be cautious of with this board?
Has somebody maybe even got experience with flashing the T410?
Kind regards,
Steph
Hi,
Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan.
1 new defect(s) introduced to coreboot found with Coverity Scan.
2 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan.
New defect(s) Reported-by: Coverity Scan
Showing 1 of 1 defect(s)
** CID 1431994: Error handling issues (CHECKED_RETURN)
/src/vendorcode/google/chromeos/cse_board_reset.c: 18 in cse_board_reset()
________________________________________________________________________________________________________
*** CID 1431994: Error handling issues (CHECKED_RETURN)
/src/vendorcode/google/chromeos/cse_board_reset.c: 18 in cse_board_reset()
12
13 void cse_board_reset(void)
14 {
15 struct cr50_firmware_version version;
16
17 /* Initialize TPM and get the cr50 firmware version. */
>>> CID 1431994: Error handling issues (CHECKED_RETURN)
>>> Calling "tlcl_lib_init" without checking return value (as is done elsewhere 9 out of 10 times).
18 tlcl_lib_init();
19 cr50_get_firmware_version(&version);
20 /*
21 * Cr50 firmware versions 0.[3|4].20 or newer support strap config 0xe where PLTRST from
22 * AP is connected to cr50's PLTRST# signal. So return immediately and trigger a
23 * global reset.
________________________________________________________________________________________________________
To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…
Hi,
I have been following the typical approach of compiling Coreboot integrated
with Inte FSP; SeaBIOS as payload, for my Minnowboard MAX dual ethernet
board. On flashing, I couldn't reach at SeaBIOS shell.
I noticed that SPD EEPROM(U33) is not mounted in order to configure the DDR.
I could flash and reach UEFI shell using below firmware images
https://software.intel.com/content/www/us/en/develop/articles/minnowboard-m…
but couldn't succeed flashing coreboot with FSP.
How to configure DDR following such a configuration?
Regards,
Derryl Tauro
Dear coreboot engineers & enthusiasts:
Doing dmesg:
[X@localhost ~]$ dmesg | grep "tty"
[ 0.336779] printk: console [tty0] enabled
[ 1.521090] 00:04: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
[ 1.542192] 00:05: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A
[ 1.563264] 00:08: ttyS2 at I/O 0x3e8 (irq = 5, base_baud = 115200) is a 16550A
[ 1.584268] 00:09: ttyS4 at I/O 0x2e0 (irq = 6, base_baud = 115200) is a 16550A
The problem I have is that only ttyS0 works (the communication with other PC).
Attached files:
superio.c Slightly modified to initialize 2 more serial ports from 2 to 4.
devicetree.cb Shows the forwarding of the I/O ranges for ttyS2 and ttyS4 also the smscsuperio tree with addresses and IRQs.
superio.asl The ACPI code.
I suspect is an IRQ issue.
Using minicom trying to send a byte out there is no signal shown on the oscilloscope.
I asked (on #coreboot) if is required to route IRQs for the serial ports but nico answered "no but you need to tell the OS if the interrupt is level or edge" but I don't know how to do that.
Anybody had experience making this kind of superio to work please give me a hint on how to resolve this.
What additional work do I need to do?
Thank you,
Jose Trujillo
To anyone who has corebooted a t440p:
I followed the instructions here
https://doc.coreboot.org/northbridge/intel/haswell/mrc.bin.html to
obtain an mrc.bin for the t440p, but it seems like these instructions
are generalized and are meant for chromebooks, and not thinkpads. I
gave it a try anyways and my t440p beeps and flashes LED's (as
configured in .config, to do so on fatal error). Months of searching,
and I can't find any documentation or archived emails from this
mailing list for obtaining an mrc.bin specifically for the t440p.
There exists this tutorial https://0xcb.dev/lenovo-t440p-coreboot/ but
it tells me to use a forked version of coreboot which seems really
fishy. I browsed the commits from that fork and I couldn't find anything
that "automates obtaining mrc.bin" as it promises.
What is the proper way to obtain the mrc.bin and configure for t440p?
CONFIG_DCACHE_RAM_MRC_VAR_SIZE=0x30000 <-- also what should this value
be if the mrc.bin is 186K?
Could be temporarily fixed by changing uintptr_t to unsigned int * :
...
GEN build.h
CC bootblock/arch/x86/id.o
CC bootblock/arch/x86/memcpy.o
In file included from src/arch/x86/memcpy.c:5:
src/include/asan.h:63:1: error: unknown type name 'uintptr_t'; did you
mean 'wint_t'?
uintptr_t __asan_shadow_offset(uintptr_t addr);
^~~~~~~~~
wint_t
src/include/asan.h:63:32: error: unknown type name 'uintptr_t'; did
you mean 'wint_t'?
uintptr_t __asan_shadow_offset(uintptr_t addr);
^~~~~~~~~
wint_t
cc1: error: unrecognized command line option
'-Wno-address-of-packed-member' [-Werror]
cc1: all warnings being treated as errors
make: *** [Makefile:362: build/bootblock/arch/x86/memcpy.o] Error 1