coreboot March 2015

coreboot@coreboot.org

62 participants
166 discussions

by A. Veek

2 years, 9 months

Re: [coreboot] No VGA output on e350m1 after flashing. what to do?

by Reiner Luett

Hi! On 30.06.2013 19:28, Christian Weinz wrote: > Maybe I didn't include the VGA option in the make menuconfig process. > How can I solve this problem? You need to add the VGA Option ROM (VGA BIOS -> Add VGA BIOS image). I've extracted it from the UEFI, but you also could use these: http://www.coreboot.org/index.php?title=ASRock_E350M1&oldid=11114 at the end of the page or you also may be able to use the default AMD fam14 (Persimmon) vbios. You will need to agree to the click through: http://wwwd.amd.com/support/vbioslic.nsf/userverify?openform http://www.coreboot.org/AMD_DB-FT1_PERSIMMON It's a pity, that bios_extract didn't work for now. You could use the AMI Aptio EFI MMTool with wine: http://win-lite.de/benutzer/fernando/BIOS-Tools/AMI_Aptio_EFI_MMTool_v4.50.… You need to extract OntarioEFIVbios with PCI ID 1002,9802 as Option ROM. Regards, Reiner --

4 years

Re: [coreboot] GRUB2 is too big as a payload in ThinkPad X201

by Paul Menzel

Dear Iru, 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 grub-2.02-beta2-372-g5974d4b $ ./autogen.sh $ ./configure --with-platform=coreboot --enable-boot-time --enable-cache-stats $ make $ 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 205851 […] […] Thanks, Paul PS: I’d be great if you could just send plain text messages with no HTML parts to mailing lists.

6 years, 5 months

Re: [coreboot] 'power on after fail' on Panther (Haswell/Lynxpoint)

by Matt DeVillier

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:matt.devillier@gmail.com>> 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? thanks! -Matt > > -duncan >

6 years, 5 months

memtest86 reading 0k memory

by Timothy Pearson

All, I have a board here that loads memtest86 but won't actually test memory. This is the output: Memtest86+ v2.11 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 |------------------------------------------------- Chipset : 0K LinuxBIOS 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 valid: 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. Thanks! -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 http://www.raptorengineeringinc.com

6 years, 5 months

Re: [coreboot] Coreboot reproducible builds

by Alexander Couzens

Hi Emilian, I chatted today with Holger from reproducible.debian.net and couldn't resist doing reproducible builds ;). These patches need additonal work, but they are working when the git tree is clean. You can test coreboot reproducible when building without payload. Or a more advanced way integrate my seabios git-tree into coreboot's payload target. coreboot needs 2 patches (one is very dirty ;) to build reproducible. http://review.coreboot.org/#/c/8611/ http://review.coreboot.org/#/c/8612/ SeaBIOS requires one patch. https://github.com/lynxis/seabios/commit/487ef74fc6cb1b1020fb25c9bb3f166602… Best, lynxis

6 years, 5 months

Re: [coreboot] VGA doesn't work on Mohon Peak

by Kuzmichev Viktor

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 hung. 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. -Viktor 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:kuzmichevviktorv@gmail.com>> wrote: > > Hello, > > 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: > http://www.coreboot.org/VGA_support > > > 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 > further. > > Regards, > Marc > > 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: > http://www.aspeedtech.com/support.php > 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 > 0x600000 > 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 > Option > 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: > http://www.seabios.org/pipermail/seabios/2015-January/008588.html > 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? > > Viktor > -- > coreboot mailing list: coreboot(a)coreboot.org > <mailto:coreboot@coreboot.org> > http://www.coreboot.org/mailman/listinfo/coreboot >

6 years, 6 months

Re: [coreboot] Question on VGA BIOS extraction

by WANG FEI

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 video? 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> wrote: > 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: >> >>> Hi, >>> >>> 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? >>> >>> Iru >>> >>> >> 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 >> http://www.raptorengineeringinc.com >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> http://www.coreboot.org/mailman/listinfo/coreboot >> > > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot >

6 years, 6 months

Re: [coreboot] Question on VGA BIOS extraction

by Timothy Pearson

On 03/30/2015 11:24 AM, Iru Cai wrote: > Hi, > > 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? > > Iru > 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 http://www.raptorengineeringinc.com

6 years, 6 months

Question on VGA BIOS extraction

by Iru Cai

Hi, 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? Iru

6 years, 6 months

Jump to page:

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot March 2015