coreboot May 2015

coreboot@coreboot.org

46 participants
117 discussions

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

09 May '15

> 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

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

09 May '15

can u try with qemu-system-x86 Ajoy On Sat, May 9, 2015 at 4:28 PM, Saket Sinha <saket.sinha89(a)gmail.com> wrote: > HI Ajay, > > > Try giving > > -m 1g > > > > > Doesn't help. Same output. > > > saket@saket-Notebook-PC:~/coreboot$ qemu-system-x86_64 -L . -bios > build/coreboot.rom -nographic > qemu: fatal: Trying to execute code outside RAM or ROM at > 0x00000000000a0000 > > EAX=00000001 EBX=00000000 ECX=00000000 EDX=00000663 > ESI=00000000 EDI=00000000 EBP=00000000 ESP=0000fffa > EIP=0009ffd6 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=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 > DR3=0000000000000000 > DR6=00000000ffff0ff0 DR7=0000000000000400 > CCS=00000001 CCD=000000ec 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) > saket@saket-HP-Pavilion-g6-Notebook-PC:~/images/coreboot$ > > Regards, > Saket Sinha >

1 0

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

09 May '15

HI Ajay, > Try giving > -m 1g > Doesn't help. Same output. saket@saket-Notebook-PC:~/coreboot$ qemu-system-x86_64 -L . -bios build/coreboot.rom -nographic qemu: fatal: Trying to execute code outside RAM or ROM at 0x00000000000a0000 EAX=00000001 EBX=00000000 ECX=00000000 EDX=00000663 ESI=00000000 EDI=00000000 EBP=00000000 ESP=0000fffa EIP=0009ffd6 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=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 DR6=00000000ffff0ff0 DR7=0000000000000400 CCS=00000001 CCD=000000ec 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) saket@saket-HP-Pavilion-g6-Notebook-PC:~/images/coreboot$ Regards, Saket Sinha

1 0

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

09 May '15

Try giving -m 1g Ajoy On Fri, May 8, 2015 at 3:55 PM, Saket Sinha <saket.sinha89(a)gmail.com> wrote: > Hi, > > I am trying to debug coreboot with qemu-x86 with the following command - > > qemu-system-x86 -L . -bios coreboot.rom -nographic > > I am getting output something like this - http://pastebin.com/Ae2X5sPe > > (Also pasted below) > EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000633 > ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 > EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 > ES =0000 00000000 0000ffff 00009300 > CS =f000 ffff0000 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 > > I have build coreboot.rom with the following option in .config - > > Payload ---> Add a payload ---> FILO ; > Payload ---> FILO version ---> HEAD > > Kindly let me know if I am missing something here. > > Regards, > Saket Sinha > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot >

1 0

coreboot fails to build in master tree
by Timothy Pearson 08 May '15

08 May '15

All, Earlier today the master coreboot tree broke; it now fails to build: fmd_scanner.l: In function ‘parse_integer’: fmd_scanner.l:47:25: error: declaration of ‘input’ shadows a global declaration [-Werror=shadow] <stdout>:1192:16: error: shadowed declaration is here [-Werror=shadow] fmd_scanner.l: In function ‘copy_string’: fmd_scanner.l:74:29: error: declaration of ‘input’ shadows a global declaration [-Werror=shadow] <stdout>:1192:16: error: shadowed declaration is here [-Werror=shadow] cc1: all warnings being treated as errors make: *** [build/util/cbfstool/fmd_scanner.o] Error 1 I propose the faulty patches be reverted until they can be repaired, as the failure in master is currently blocking any upstreaming efforts. Thanks! -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 http://www.raptorengineeringinc.com

2 1

Questions on building a Coreboot ROM for the Dell Chromebook 11
by Marcos Scriven 08 May '15

08 May '15

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… 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). 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 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 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. 2) Which mainboard do I use for the Dell Chromebook 11? 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? 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? I also note the Google keep the coreboot config source controlled: https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/firmwar… 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: commit cef55018e4e936af9a758675353e332df4d9d1a6 Author: David Wu <David_Wu(a)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> 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

1 0

Re: [coreboot] [poll] device_t
by Aaron Durbin 08 May '15

08 May '15

On Fri, May 8, 2015 at 12:16 PM, Patrick Georgi <pgeorgi(a)google.com> wrote: > 2015-05-08 17:31 GMT+02:00 Aaron Durbin <adurbin(a)google.com>: >> In romstage *both* struct device and device_t are present but are >> completely different types. It's the romstage, ramstage, and smm >> overlap that is large and extremely annoying to deal with. > History time: > Until not too long ago, bootblock and romstage used u32 device_t, > ramstage used struct device, smm didn't really matter and nothing else > existed. > This was further enforced by struct device being available in ramstage > _only_. We now have a read-only view of the device tree available in > romstage that makes things look more complicated. > > One of the ideas that led to the devicetree in romstage was to make > struct device the default interface where possible, together with the > aforementioned isolation of romcc based code. Essentially: for romcc, > use u32. For everything else, struct device. > > We may want to determine first what data structure we want to use in > each stage. This could be 'u32 for all hardware accesses, with some > struct device -> u32 conversion to move from devicetree to hardware', > which sounds like what you propose (and is completely contrary to that > other idea). No. I was suggesting doing a struct device lookup from a u32 one. Anyway, I think it's constructive to look at use cases. The struct device code assumes that one has a reference to the struct device in ramstage by way the state machine acting on each device. But then we have to add lookup routines because that's not always the valid use case. Even though struct device is there in romstage it's not used at all for IO (as you mentioned the plan was never realized). A lot of the juggling of types comes from the fact that there are statically known pci devices, and one wants to talk to them outside of the ramstage boot state machine. romstage has no concept nor a way to get at each device w/o doing the tree walk. That coupled with IO routines only operating on u32 devices makes one do the necessary back bends. Can at least a short term goal be to remove the crufty handling found in the examples I provided? Those are not the only 2, I'm sure. Does that mean we bring in static.c for all stages? What about the dynamic ops handling currently available in ramstage? Does that apply to all stages? I also wouldn't frame the discussion around the 'fate of device_t'. It's really more about defining the semantics for the IO routines on devices for each stage: how does one get a reference to said device? how does one do that IO? Can the same code be compiled in all stages w/o having to put per-compilation unit c preprocessor switches? -Aaron

1 0

Re: [coreboot] [poll] device_t
by Patrick Georgi 08 May '15

08 May '15

2015-05-08 17:31 GMT+02:00 Aaron Durbin <adurbin(a)google.com>: > In romstage *both* struct device and device_t are present but are > completely different types. It's the romstage, ramstage, and smm > overlap that is large and extremely annoying to deal with. History time: Until not too long ago, bootblock and romstage used u32 device_t, ramstage used struct device, smm didn't really matter and nothing else existed. This was further enforced by struct device being available in ramstage _only_. We now have a read-only view of the device tree available in romstage that makes things look more complicated. One of the ideas that led to the devicetree in romstage was to make struct device the default interface where possible, together with the aforementioned isolation of romcc based code. Essentially: for romcc, use u32. For everything else, struct device. We may want to determine first what data structure we want to use in each stage. This could be 'u32 for all hardware accesses, with some struct device -> u32 conversion to move from devicetree to hardware', which sounds like what you propose (and is completely contrary to that other idea). But until there's a consensus on that, I guess it's too early to discuss the fate of device_t. Patrick -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores

1 0

Re: [coreboot] [poll] device_t
by ron minnich 08 May '15

08 May '15

On Fri, May 8, 2015 at 8:31 AM Aaron Durbin <adurbin(a)google.com> wrote: > > I personally feel that changing device_t type based on stage makes the > code non-obvious and hard to follow. > > I'd rather we *always* provide simple u32 device_t functions in all > stages while allowing struct device IO functions for use in ramstage. > > that's pretty much the approach I tried to take in v3. While the device_t stuff is cool it's too hard for my brain. BUT, it's there, been in use for a long time, not sure this is the best time to change it. But The Will of the People will decide. ron

1 0

Re: [coreboot] [poll] device_t
by Aaron Durbin 08 May '15

08 May '15

On Thu, May 7, 2015 at 3:42 PM, Patrick Georgi via coreboot <coreboot(a)coreboot.org> wrote: > 2015-05-07 22:00 GMT+02:00 Stefan Reinauer <stefan.reinauer(a)coreboot.org>: >> With our current bootblock concept, it is never going away on x86 (for >> bootblock usage) > Which isn't that much of a problem once we provide separate headers > for x86 bootblock code. There's really very tiny overlap. > That could then be reused to deal with raminit on romcc-boards, too: > from coreboot's point of view, raminit is just an overly large > piece of cache-as-ram code, followed by a raminit noop. > This is simplified by the lack of the need for development tools (eg > printk) to develop new non-car x86 raminits. > > I think bootblock code overlap is tiny. However, device_t is more complicated than just bootblock and !bootblock. The io routines differ by stage: romstage and bootblock use the simple u32 device_t ramstage uses the sturct device device_t And lest we not forget SMM on x86 which only has simple u32 device_t. In romstage *both* struct device and device_t are present but are completely different types. It's the romstage, ramstage, and smm overlap that is large and extremely annoying to deal with. A few examples on boiler plate one needs to deal with for code sharing: src/soc/intel/baytrail/pmutil.c -- all the get_pcu_dev() src/soc/intel/baytrail/spi.c So basically while the function names are the same for the IO routines the parameter types change. So every caller of a compilation unit of these IO routines that wants to be shared needs to deal w/ the current type changes. I personally feel that changing device_t type based on stage makes the code non-obvious and hard to follow. I'd rather we *always* provide simple u32 device_t functions in all stages while allowing struct device IO functions for use in ramstage. The simple ones in ramstage can just be a struct device lookup then call appropriate IO function. -Aaron

1 0

← Newer
1
...
4
5
6
7
8
9
10
11
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