coreboot May 2015

coreboot@coreboot.org

46 participants
117 discussions

ASUS KFSN4-DRE Automated Test Failure
by Raptor Engineering Automated Coreboot Test Stand 13 May '15

13 May '15

The ASUS KFSN4-DRE fails verification as of commit 1f04e94b7915ce599e49a71fd38cb72523c9c887 The following tests failed: CBMEM_OBJECT_TABLE_TRUNCATED Commits since last successful test: 1f04e94 x86: expose tsc's timer_monotonic_get() in SMM 797ca1b baytrail: broadwell: correct refcode loading 09560fa vboot: handle RELOCATABLE_RAMSTAGE 3dad489 FSP 1.1 Comparison Base 3961834 kconfig: properly build parser when LKC_GENPARSER=1 <83 commits skipped> 2436bda cpu: get rid of socket source code 99cc1aa Mediawiki editing warning e9b7e25 util/xcompile/xcompile: Allow to override `HOSTCC` variable 939dc84 crossgcc: Re-download the archive if it is incomplete 6548ae9 cbfstool/Makefile*: Use `LDFLAGS` instead of `LINKFLAGS` See attached log for details This message was automatically generated from Raptor Engineering's ASUS KFSN4-DRE test stand Raptor Engineering offers coreboot consulting services! Please visit https://www.raptorengineeringinc.com for more information Please contact Timothy Pearson at Raptor Engineering <tpearson(a)raptorengineeringinc.com> regarding any issues stemming from this notification

1 0

New post published at blog.coreboot.org on May 11, 2015 at 8:58 pm
by WordPress 11 May '15

11 May '15

1 0

Re: [coreboot] Questions on building a Coreboot ROM for the Dell Chromebook 11
by Julius Werner 11 May '15

11 May '15

>> To my knowledge, upstreaming boards during the Haswell days wasn't a >> priority, and was often done by non-Google devs (like me) who happened to >> have a particular device. Within the last ~6 mos this has changed >> significantly, and there's been a large push to keep the two in sync. I don't know if we have an official policy regarding upstreaming on this, but in our own master at https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/master we often intentionally only add a few boards for every generation (keeping the others in the respective release firmware branches like https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/firmwar… ). The reason for that is simply to reduce clutter, since we often have a lot of different boards using the same chipset and very similar board layouts, which essentially just gives us dozens of directories with 99% copied code (e.g. see all the veyron_* boards in https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/firmwar… for some of the worst offenders, which are 100% identical except for different board ID numbers). We've been talking in the past about ways to more effectively share code between boards but didn't really have time to tackle it yet. Until then, I don't expect we'll upstream any more boards than we're keeping in our own master (which is sometimes a quite arbitrary distinction based on how early we started working on that board). The best way to build upstream firmware for one of those derivative boards (like Wolf) is probably to find the corresponding "lead" board (in this case Falco), diff the respective two boards in the Chromium firmware branch(es), and apply that (hopefully very small) diff to the current upstream version of that lead board. > 5) Despite attempting to set the boot menu key to ESC rather than F12 (and verifying the boot-menu-key and boot menu-message appeared with csfbtool), it still came up with F12 when I booted. Fortunately I have a USB keyboard handy, and was still able to boot a Lubuntu install. Did you use SeaBIOS directly as a payload, or did you build an image the Chromium way (with the "depthcharge" payload that chainloads SeaBIOS when you press CTRL+L)? In the latter case SeaBIOS is wrapped into its own little CBFS in a different FMAP section, and you cannot directly access it with cbfstool without extracting it first (you would instead write your files to the main coreboot CBFS where nothing is reading them from).

1 0

ASUS KFSN4-DRE Automated Test Failure
by Raptor Engineering Automated Coreboot Test Stand 11 May '15

11 May '15

The ASUS KFSN4-DRE fails verification as of commit d2ab4e420ddfb0b14325b63b5443a0d6250076d8 The following tests failed: CBMEM_OBJECT_TABLE_TRUNCATED Commits since last successful test: d2ab4e4 vboot: allow options to be selected from .config d1cf44c vboot: fix vboot_reference compilation e385b37 chromeos: add missing vboot functions bc40933 arm64: update verstage linking 52a530d arm: update verstage linking <70 commits skipped> 2436bda cpu: get rid of socket source code 99cc1aa Mediawiki editing warning e9b7e25 util/xcompile/xcompile: Allow to override `HOSTCC` variable 939dc84 crossgcc: Re-download the archive if it is incomplete 6548ae9 cbfstool/Makefile*: Use `LDFLAGS` instead of `LINKFLAGS` See attached log for details This message was automatically generated from Raptor Engineering's ASUS KFSN4-DRE test stand Raptor Engineering offers coreboot consulting services! Please visit https://www.raptorengineeringinc.com for more information Please contact Timothy Pearson at Raptor Engineering <tpearson(a)raptorengineeringinc.com> regarding any issues stemming from this notification

1 0

lenovo/g505s EC kb9012 - possible to falsh EC bios?
by Harry Hedaya 11 May '15

11 May '15

Hi Coreboot team i came across this article Board:lenovo/g505s - coreboot. Is there a way to reflash the bios of KB9012 of this board using coreboot? (it is EC bios and inbuilt) This EC chip has become corrupt and I was wondering if at all coreboot had a solution for this . I was planning to go for the RT809F serial isp programmer, thought i might ask you guys first. Great job,thanks,Harry

1 0

ASUS KFSN4-DRE Automated Test Failure
by Raptor Engineering Automated Coreboot Test Stand 10 May '15

10 May '15

The ASUS KFSN4-DRE fails verification as of commit 6be1a8bf084be82b19a561d475c5ad52d5fc987c The following tests failed: CBMEM_OBJECT_TABLE_TRUNCATED Commits since last successful test: 6be1a8b AGESA: Drop unused AGESA_MEM_TABLE c7a8c38 cbfstool: fix 32bit host issue 94383da fmap: request libc compatibility level that includes memccpy ef33db0 cpu/amd/model_10xxx: Add missing ACPI _PSD object 61942de northbridge/intel/gm45/gma: Minor cleanup <61 commits skipped> 2436bda cpu: get rid of socket source code 99cc1aa Mediawiki editing warning e9b7e25 util/xcompile/xcompile: Allow to override `HOSTCC` variable 939dc84 crossgcc: Re-download the archive if it is incomplete 6548ae9 cbfstool/Makefile*: Use `LDFLAGS` instead of `LINKFLAGS` See attached log for details This message was automatically generated from Raptor Engineering's ASUS KFSN4-DRE test stand Raptor Engineering offers coreboot consulting services! Please visit https://www.raptorengineeringinc.com for more information Please contact Timothy Pearson at Raptor Engineering <tpearson(a)raptorengineeringinc.com> regarding any issues stemming from this notification

1 0

Re: [coreboot] Questions on building a Coreboot ROM for the Dell Chromebook 11
by Matt DeVillier 10 May '15

10 May '15

hi Marcos, I'm not a Google dev, just a hobbyist, but I've spent a lot of time over the past year working with coreboot for the Haswell ChromeOS devices (mostly the ChromeBoxes) and can offer some answers, inline below. On 5/8/2015 2:38 PM, Marcos Scriven wrote: > I have a Dell Chromebook 11 (Google codename 'Wolf') which I'd like to install a custom coreboot ROM on. Although John Lewis provides ROMs here https://johnlewis.ie/custom-chromebook-firmware/rom-download/, I'd rather not use them for a few reasons: > > 1) It's replacing one 'closed' ROM with another, in the sense it's from a 3rd party with no public repo or build scripts. Although it's possible to extract the coreboot config used to build them, it's not possible to reproduce and modify the payloads. > 2) I don't need his closed 'Jeltka' payload. > 3) I'd like to experiment with other payloads, custom splash screens etc. > 4) I wouldn't learn anything, and I'm interested! > > With that in mind, this guide here looked ideal (although there's no date on it): https://www.chromium.org/chromium-os/developer-information-for-chrome-os-de… that's what I started with, and a good overview for what you need to build your own firmware. I'd suggest however that you first build coreboot using the same tree/branch as the shipped firmware (which you linked below) before trying to get upstream coreboot working, particularly since Wolf hasn't been upstreamed yet. Payload wise, SeaBIOS is fine to build from upstream; I build off the 1.8.1 tag currently. You're welcome to use my configs and build scripts for reference: https://github.com/MattDevo/coreboot and https://github.com/MattDevo/SeaBIOS > > However, that prompted some questions, which I'm hoping someone here might be able to help with. (I did ask in the #chromimum-os IRC channel, but they suggested Google coreboot developers would be more likely to help here). also try #coreboot. I loiter in there and am happy to help if I'm around (I'm MattDevo on IRC). > > 1) What blobs do I use? > > Although the guide sensibly says to backup the existing bios with 'flashrom -r', it also says to extract a bios.bin from /usr/sbin/chromeos-firwmwareupdate (I've posted details of both at the end). From the latter, it goes on to get you to extract four blobs: > > - SPI Descriptor > - Management Engine > - MRC > - VBIOS that list is correct. > > The first discrepancy is that the guide says the 'Management Engine firmware' is only in the latter, but I was able to use ifdtool on both images to extract the same set of three files. The flashregion_0_flashdescriptor.bin files were identical, though the other two were different despite being the same size. The ME firmware isn't always reliably read from a running system, so using the blob extracted from the shell-ball firmware image is preferred. > > The other thing is there's no reason given as to why one would use the MRC and VBIOS blobs from the extract, rather than the backup. Curiously, they are slightly different sizes (again details below). Looking at the config it seems the extracted bios image was built with from a Google coreboot fork four months older than the one backed up from the machine. these should be identical between the backup image and shell-ball extract. > > > 2) Which mainboard do I use for the Dell Chromebook 11? Wolf > > Assuming I have the correct four proprietary blobs, the next thing is choosing the right mainboard. The guide I link to mentions suggests 'Falco', but I don't see how, without knowing the target, such a suggestion could be meaningful? Falco is used as an example because it was already upstreamed. Since Wolf isn't, you would need to do so yourself, which is why I suggested starting with the stock firmware tree/branch. I upstreamed Panther, which was somewhat easier since it doesn't have a built-in display or EC to worry about, but you can use Falco as a guide, comparing the upstream Falco branch to the shipped firmware tree/branch, and make similar adjustments for Wolf. > > Looking here https://www.chromium.org/chromium-os/developer-information-for-chrome-os-de… Falco appears to be unique to the HP Chromebook 14. The mainboard codename for my Chromebook is 'Wolf', and that's not in coreboot upstream. > > Comparing 'src/mainboard/google' in Google's fork, and coreboot upstream: > > http://review.coreboot.org/gitweb?p=coreboot.git;a=tree;f=src/mainboard/goo… > https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/firmwar… > > > It seems there is at least some attempt to merge upstream, and yet wolf isn't there. Is there a particular reason some mainboards are missing? Did Google stop doing so for some reason? To my knowledge, upstreaming boards during the Haswell days wasn't a priority, and was often done by non-Google devs (like me) who happened to have a particular device. Within the last ~6 mos this has changed significantly, and there's been a large push to keep the two in sync. > > I also note the Google keep the coreboot config source controlled: https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/firmwar… as per above, use that config to build from that branch. > > > Thanks > > Marcos > > > --- Some further ROM details --- > > bios extracted with 'flashrom -r' from my Dell Chromebook 11: > > chromebook11.rom: 8192 kB, bootblocksize 3144, romsize 8388608, offset 0x700000 > alignment: 64 bytes, architecture: x86 > > Name Offset Type Size > cmos_layout.bin 0x700000 cmos_layout 1164 > pci8086,0406.rom 0x7004c0 optionrom 65536 > cpu_microcode_blob.bin 0x710500 microcode 41024 > config 0x71a5c0 raw 5536 > fallback/vboot 0x71bbc0 stage 15083 > (empty) 0x71f700 null 2136 > fallback/romstage 0x71ff80 stage 42497 > fallback/coreboot_ram 0x72a600 stage 91450 > fallback/payload 0x740b80 payload 54898 > u-boot.dtb 0x74e240 mrc_cache 7919 > (empty) 0x750180 null 327192 > mrc.bin 0x79ffc0 spd 190180 > (empty) 0x7ce700 null 120984 > spd.bin 0x7ebfc0 spd 1536 > (empty) 0x7ec600 null 77144 > > Extracting config shows "# This image was built using git revision 52034fc1537d4a38e792e700cbc8e9dd1fc36a9c", which is a commit hash from Google's fork: I'd start with this one, or whatever the latest commit is for that branch. > > commit cef55018e4e936af9a758675353e332df4d9d1a6 > Author: David Wu <David_Wu(a)quantatw.com <mailto:David_Wu@quantatw.com>> > Date: Tue Apr 29 12:59:04 2014 -0700 > > > bios extracted from the chromeos-firwmwareupdate utility (which on my machine is a 7.7M binary built on 27th Apr this year): > > bios.bin: 8192 kB, bootblocksize 3144, romsize 8388608, offset 0x700000 > alignment: 64 bytes, architecture: x86 > > Name Offset Type Size > cmos_layout.bin 0x700000 cmos_layout 1164 > pci8086,0406.rom 0x7004c0 optionrom 65536 > cpu_microcode_blob.bin 0x710500 microcode 43072 > config 0x71adc0 raw 5536 > fallback/vboot 0x71c3c0 stage 15083 > (empty) 0x71ff00 null 88 > fallback/romstage 0x71ff80 stage 42497 > fallback/coreboot_ram 0x72a600 stage 91491 > fallback/payload 0x740bc0 payload 54898 > u-boot.dtb 0x74e280 mrc_cache 7919 > (empty) 0x7501c0 null 327128 > mrc.bin 0x79ffc0 spd 191020 > (empty) 0x7cea40 null 120152 > spd.bin 0x7ebfc0 spd 1536 > (empty) 0x7ec600 null 77144 > > Extracting config shows "# This image was built using git revision 52034fc1537d4a38e792e700cbc8e9dd1fc36a9c", which is also a commit hash from Google's fork, but older: > > commit 52034fc1537d4a38e792e700cbc8e9dd1fc36a9c > Author: Marc Jones <marc.jones(a)se-eng.com <mailto:marc.jones@se-eng.com>> > Date: Thu Dec 12 13:13:30 2013 -0700 > > > Differences in SPI/ME from backed up ROM and the one extracted from firmwareupdate tool: > > marcosscriven@ubuntuvm:~/coreboot/util/ifdtool$ ls -altr frombackup/ > total 8200 > -rw-r--r-- 1 marcosscriven marcosscriven 6291456 May 8 19:20 flashregion_1_bios.bin > -rw-r--r-- 1 marcosscriven marcosscriven 4096 May 8 19:20 flashregion_0_flashdescriptor.bin > -rw-r--r-- 1 marcosscriven marcosscriven 2093056 May 8 19:20 flashregion_2_intel_me.bin > drwxrwxr-x 2 marcosscriven marcosscriven 4096 May 8 19:20 . > drwxrwxr-x 4 marcosscriven marcosscriven 4096 May 8 19:21 .. > > marcosscriven@ubuntuvm:~/coreboot/util/ifdtool$ ls -altr fromextract/ > total 8200 > -rw-r--r-- 1 marcosscriven marcosscriven 6291456 May 8 19:20 flashregion_1_bios.bin > -rw-r--r-- 1 marcosscriven marcosscriven 4096 May 8 19:20 flashregion_0_flashdescriptor.bin > -rw-r--r-- 1 marcosscriven marcosscriven 2093056 May 8 19:20 flashregion_2_intel_me.bin > drwxrwxr-x 4 marcosscriven marcosscriven 4096 May 8 19:21 .. > drwxrwxr-x 2 marcosscriven marcosscriven 4096 May 8 19:21 . > > marcosscriven@ubuntuvm:~/coreboot/util/ifdtool$ diff frombackup/ fromextract/ > Binary files frombackup/flashregion_1_bios.bin and fromextract/flashregion_1_bios.bin differ > Binary files frombackup/flashregion_2_intel_me.bin and fromextract/flashregion_2_intel_me.bin differ the bios.bin isn't applicable (just the firmware descriptor and ME); as I noted above, the ME extracted from a running system will differ slightly. Good luck! cheers, Matt > > >

2 1

ASUS KFSN4-DRE Automated Test Failure
by Raptor Engineering Automated Coreboot Test Stand 09 May '15

09 May '15

The ASUS KFSN4-DRE fails verification as of commit c7a8c3835d095405cf875d6952e348c023c7c5a0 The following tests failed: CBMEM_OBJECT_TABLE_TRUNCATED Commits since last successful test: c7a8c38 cbfstool: fix 32bit host issue 94383da fmap: request libc compatibility level that includes memccpy ef33db0 cpu/amd/model_10xxx: Add missing ACPI _PSD object 61942de northbridge/intel/gm45/gma: Minor cleanup f88b932 southbridge/i82801gx: Add x_EN defines for LPC_EN <60 commits skipped> 2436bda cpu: get rid of socket source code 99cc1aa Mediawiki editing warning e9b7e25 util/xcompile/xcompile: Allow to override `HOSTCC` variable 939dc84 crossgcc: Re-download the archive if it is incomplete 6548ae9 cbfstool/Makefile*: Use `LDFLAGS` instead of `LINKFLAGS` See attached log for details This message was automatically generated from Raptor Engineering's ASUS KFSN4-DRE test stand Raptor Engineering offers coreboot consulting services! Please visit https://www.raptorengineeringinc.com for more information Please contact Timothy Pearson at Raptor Engineering <tpearson(a)raptorengineeringinc.com> regarding any issues stemming from this notification

1 0

Re: [coreboot] coreboot debugging with qemu-x86
by Saket Sinha 09 May '15

09 May '15

> Didi u try using qemu-system-i386 ? > saket@saket-Notebook-PC:~/coreboot$ qemu-system-i386 -L . -bios build/coreboot.rom -nographic qemu: fatal: Trying to execute code outside RAM or ROM at 0x000a0000 EAX=00000001 EBX=00000000 ECX=00000000 EDX=00000663 ESI=00000000 EDI=00000000 EBP=00000000 ESP=0000fffa EIP=0009fff4 EFL=00000082 [--S----] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0000 00000000 0000ffff 00009300 CS =0000 00000000 0000ffff 00009b00 SS =0000 00000000 0000ffff 00009300 DS =0000 00000000 0000ffff 00009300 FS =0000 00000000 0000ffff 00009300 GS =0000 00000000 0000ffff 00009300 LDT=0000 00000000 0000ffff 00008200 TR =0000 00000000 0000ffff 00008b00 GDT= 00000000 0000ffff IDT= 00000000 0000ffff CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000 DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000 DR6=ffff0ff0 DR7=00000400 CCS=00000001 CCD=000000fb CCO=ADDB EFER=0000000000000000 FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80 FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000 XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000 XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 Aborted (core dumped) Regards, Saket Sinha

1 0

Re: [coreboot] coreboot debugging with qemu-x86
by Ajoy Das 09 May '15

09 May '15

Didi u try using qemu-system-i386 ? Thanks Ajoy On Sat, May 9, 2015 at 4:52 PM, Saket Sinha <saket.sinha89(a)gmail.com> wrote: > > can u try with qemu-system-x86 > > > > I do not have qemu-system-x86 on my machine. I either have > qemu-system-x86_64 or qemu-system-i386 to the closest. > > My machine configuration - > > saket@saket-Notebook-PC:~/coreboot$ uname -a > Linux saket-HP-Pavilion-g6-Notebook-PC 3.19.0-16-generic #16-Ubuntu > SMP Thu Apr 30 16:09:58 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >

1 0

← Newer
1
2
3
4
5
6
7
8
9
...
12
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot May 2015