-----BEGIN PGP SIGNED MESSAGE-----
Hi @ all,
is there a Coroboot for the Lenovo T410 Laptop?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
-----END PGP SIGNATURE-----
welcome to coreboot!
Am Donnerstag, den 26.03.2015, 09:33 +0800 schrieb Iru Cai:
> I tried to use GRUB2 as a payload when building coreboot for ThinkPad X201,
> but it's too big to fit into the rom. The GRUB2 coreboot image without
> modules is 2.8M and >800K after compressing, it's still too big.
building GRUB directly, I get a different result.
$ git describe
$ ./configure --with-platform=coreboot --enable-boot-time --enable-cache-stats
$ edit Makefile
Now adapt the rule `default_payload.elf`.
default_payload.elf: grub-mkstandalone grub-mkimage
pkgdatadir=. ./grub-mkstandalone --grub-mkimage=./grub-mkimage -O i386-coreboot -o $@ --modules='ahci pata ehci uhci ohci usb_keyboard usbms part_msdos xfs ext2 fat at_keyboard part_gpt usbserial_usbdebug cbfs' --install-modules='ls linux search configfile normal cbtime cbls memrw iorw minicmd lsmmap lspci halt reboot hexdump pcidump regexp setpci lsacpi chain test serial multiboot cbmemc linux16 gzio echo help' --fonts= --themes= --locales= -d grub-core/ /boot/grub/grub.cfg=$(srcdir)/coreboot.cfg
Remove the modules you don’t need. With *my* ASRock E350M1 setup, I
don’t need `pata`, `usbms`, `xfs`, `fat`, `at_keyboard`, `part_gpt` and
`usbserial_usbdebug`. I then add `boottime` and `cacheinfo`.
$ make default_payload.elf
The file is now 578K big and in CBFS the compressed size is a little
over 200 KB.
$ build/cbfstool build/coreboot.rom print
fallback/payload 0x5c400 payload
PS: I’d be great if you could just send plain text messages with no HTML
parts to mailing lists.
On 3/26/2015 9:49 AM, Duncan Laurie wrote:
> On Wed, Mar 25, 2015 at 11:35 PM, Matt DeVillier <matt.devillier(a)gmail.com <mailto:firstname.lastname@example.org>> wrote:
> Greetings all!
> I was wondering if it's possible to have Panther (Asus ChromeBox - Haswell/Lynxpoint) power on when AC power connected regardless of the previous power state. Currently, the box will power on if AC power is lost and the device was powered on, but not if powered off. I have a use case where it would be convenient to be able to power on the boxes by toggling AC power (eg, the boxes are not within physical reach). I modified the CMOS default setting for 'power_on_after_fail' to be enabled and verified its status with nvramtool. I also tried modifying lpc.c/smihandler.c in the southbridge code to force MAINBOARD_POWER_ON (rather than MAINBOARD_POWER_KEEP) in all cases, to no avail.
> Am I approaching this from the wrong angle, or is it perhaps not possible with these boxes?
> This might be due to the SuperIO instead of the Southbridge. Panther does call it8772f_ac_resume_southbridge() which *should* be making the southbridge the one responsible for the power behavior when AC is applied, but as a first test you could try removing that call to see if the default SuperIO behavior is closer to what you want.
Hi Duncan, I tried removing the call as suggested, but it didn't change the behavior at all. Any thoughts as to where to look next?
I have a board here that loads memtest86 but won't actually test memory.
This is the output:
AMD K10 CPU @ 2312 MHz
L1 Cache: 64K 35028 MB/s
L2 Cache: 512K 6963 MB/s
L3 Cache: 2048K 6052 MB/s
Memory : 0K
I'm guessing memtest86 doesn't understand coreboot's memory
tables/structure, but I have no idea why that would be. The e820 map is
e820: BIOS-provided physical RAM map:
BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
BIOS-e820: [mem 0x0000000000100000-0x000000003ffacfff] usable
BIOS-e820: [mem 0x000000003ffad000-0x000000003fffffff] reserved
BIOS-e820: [mem 0x00000000e0000000-0x00000000efffffff] reserved
Any ideas? Other than this one irritating glitch coreboot is working
perfectly on this board.
+1 (415) 727-8645
I tried not to include any VBIOS file in coreboot ROM much earlier, in
my first tests. With 'Run VGA Option ROMs' option checked the board just
And as I mentioned in my previous email VGA works fine with vendor's
BIOS. So the card itself should be fine.
Sadly, I don't have another card to try. Even if I had, I still would
need to make this one work somehow as Mohon Peak is just a reference
board and the target board will have a similar VGA controller.
So please, let me know if there are some other things I could try or if
I am mistaken somewhere.
On 03/19/2015 09:20 PM, Marc Jones wrote:
> Hi Viktor,
> On Thu, Mar 19, 2015 at 4:23 AM Kuzmichev Viktor
> <kuzmichevviktorv(a)gmail.com <mailto:email@example.com>> wrote:
> I'm using coreboot + SeaBIOS on Mohon Peak CRB. And I've tried to make
> VGA work for a while now. I used this article as a guide:
> Since it is an add-in card, you don't need to extract the VBIOS and
> put it into cbfs. The VBIOS on the card will run during the PCI card
> enumeration. It seems that there is a problem with that specific
> aspeed card and/or VBIOS. You may want to try a different card to
> avoid the issue. Please let us know the results if you debug that card
> Extracting VGA BIOS from vendor BIOS image did not work:
> $ ./bios_extract EDVLCRB1.86B.0043.R00.1408290947_MPK.bin
> Using file "EDVLCRB1.86B.0043.R00.1408290947_MPK.bin" (8192kB)
> Error: Unable to detect BIOS Image type.
> Then, I've downloaded VGA BIOS from here:
> Mohon Peak uses Aspeed VGA controller AST1300.
> And also, I've extracted Video ROM from /dev/mem:
> # dd if=/dev/mem of=vgabios.bin bs=1k count=32 skip=768
> Neither of them worked. Here's what I've tried. I've tried to add them
> via coreboot's menuconfig (' Add VGA BIOS image' option). I've
> tried to
> add them manually via cbfstool as an optionrom and as a raw file. I've
> tried to put them in CBFS under vgaroms/ directory. Here's my latest
> ROM-file layout:
> $ ./build/cbfstool build/coreboot.rom print
> coreboot.rom: 8192 kB, bootblocksize 1024, romsize 8388608, offset
> alignment: 64 bytes, architecture: x86
> Name Offset Type Size
> cmos_layout.bin 0x600000 cmos_layout 1352
> pci1a03,2000.rom 0x600580 optionrom 32768
> fallback/romstage 0x6085c0 stage 26616
> fallback/ramstage 0x60ee00 stage 59904
> fallback/payload 0x61d840 payload 56100
> config 0x62b3c0 raw 4532
> revision 0x62c5c0 raw 708
> pci8086,1f41.rom 0x62c8c0 raw 61952
> vgaroms/pci1a03,2000.rom 0x63bb00 raw 32768
> img/Memtest86+(5.01) 0x643b40 payload 159492
> (empty) 0x66aa80 null 939288
> mrc.cache 0x74ffc0 (unknown) 65536
> cpu_microcode_blob.bin 0x760000 microcode 83968
> (empty) 0x774840 null 46936
> fsp.bin 0x77ffc0 (unknown) 372736
> (empty) 0x7db000 null 150424
> The entries pci1a03,2000.rom are the VGA ROMs there. I also tried to
> remove either of them. I've tested with coreboot option 'Run VGA
> ROMs' checked and unchecked without any difference. In SeaBIOS I set
> 'VGA Hardware Type (coreboot linear framebuffer)' as the other options
> are None, GeodeGX2 and GeodeLX, so coreboot linear framebuffer seemed
> more logical.
> I saw this mailing list:
> but found no solution there and it seems not to be my case as my board
> does not hang.
> I put coreboot and SeaBIOS output in the attachment. Debug levels
> set to
> 7 for both. In coreboot only 'Output verbose CBFS debug messages'
> checked in 'Debugging' submenu.
> Is there anything I'm doing wrong or simply missing?
> coreboot mailing list: coreboot(a)coreboot.org
TP X220 suppose to have a UEFI compatible BIOS, is it possible it has a
UEFI DXE VGA driver (not sure what's the proper name of it) except a legacy
Maybe you should boot up system with original BIOS and check the content in
0xC000 segment, is it a legacy VBIOS or it's empty...
On Mon, Mar 30, 2015 at 7:10 PM, Charles Devereaux <coreboot(a)guylhem.net>
> Likewise on thinkpad tablets the name of the digitizer (WACF004) can be
> changed by the ACPI DSDT depending on things detected by the BIOS or not.
> You may want to check the DSDT
> On Mon, Mar 30, 2015 at 12:29 PM, Timothy Pearson <
> tpearson(a)raptorengineeringinc.com> wrote:
>> On 03/30/2015 11:24 AM, Iru Cai wrote:
>>> I'm trying to build Coreboot for ThinkPad X220. I first backup the
>>> vendor BIOS, then use UEFITool to extract a VBIOS. The romheader program
>>> detects the ROM's PCI data structure and reports the device id is
>>> 8086:0106, but the VGA controller's device id is 8086:0126. I extracted
>>> the video ROM from a running X220 memory and use romheader to test it,
>>> the result is still 8086:0106. How could this happen?
>> Some PCI devices can change their device ID based on a configuration
>> register or two (I know the XGI Volari can do this for instance). It is
>> possible that the proprietary BIOS changes the ID for some reason.
>> Timothy Pearson
>> Raptor Engineering
>> +1 (415) 727-8645
>> coreboot mailing list: coreboot(a)coreboot.org
> coreboot mailing list: coreboot(a)coreboot.org
On 03/30/2015 11:24 AM, Iru Cai wrote:
> I'm trying to build Coreboot for ThinkPad X220. I first backup the
> vendor BIOS, then use UEFITool to extract a VBIOS. The romheader program
> detects the ROM's PCI data structure and reports the device id is
> 8086:0106, but the VGA controller's device id is 8086:0126. I extracted
> the video ROM from a running X220 memory and use romheader to test it,
> the result is still 8086:0106. How could this happen?
Some PCI devices can change their device ID based on a configuration
register or two (I know the XGI Volari can do this for instance). It is
possible that the proprietary BIOS changes the ID for some reason.
+1 (415) 727-8645
I'm trying to build Coreboot for ThinkPad X220. I first backup the vendor
BIOS, then use UEFITool to extract a VBIOS. The romheader program detects
the ROM's PCI data structure and reports the device id is 8086:0106, but
the VGA controller's device id is 8086:0126. I extracted the video ROM from
a running X220 memory and use romheader to test it, the result is still
8086:0106. How could this happen?