coreboot December 2016

coreboot@coreboot.org

57 participants
121 discussions

TALOS project short of funding goals - where to now?

by Taiidan＠gmx.com

I am incredibly sad that TALOS has not gotten the required cash flow, short of a miracle in the next few days. The coreboot project is pretty much dead in the water without it, the only real choices for further development are either super low power crappy ARM devices or always going to be expensive IBM/TYAN POWER servers, so what do we do? I am wondering, how come they didn't bark up some government or corporate trees for TALOS funding? AFIAK there are various government agencies interested in secure hardware and assured computing; I have always wondered what the NSA uses for their own computing needs, maybe they paid intel for firmware source code and a system that doesn't need ME to run. The way things are going: +10 years - Microsoft and Intel have announced the "PrivaSec" initiative, aimed at producing a secure vertically intergrated computing platform where firmware agents prohibit the execution of unapproved programs - protecting your data from unauthorized access. +20 years - We're sorry, but the GlobeX Trade Agreement and the Secure Communities act of 2035 prohibit the viewing, copying or transmission of this file - Further violations may result in fine, arrest and or the revocation of your work permit and internet operators license. Thoughts: It seems that so many linux people just don't really care about libre anything, considering that the average linux sysadmin makes over $100K per year the community could have easily funded the project. These days there are a lot more people with skills, but without the computer enthusiast/hacker culture of the 90's, the kind of hypocritical people who use a macbook, facebook, etc but who chide me for saying that working for the government is not at all immoral. If I wasn't unemployed I would happily pay $5K for a high performance libre computer, but not everyone is me. People went nuts for the faux libre purism laptop but talos gets hardly any comparative publicity/hype - why? - "We'll get intel to open up ME one day, we promise!"

4 years, 1 month

Re: [coreboot] Disassembly of coreboot binaries

by Igor Skochinsky

4 years, 1 month

Re: [coreboot] Disassembly of coreboot binaries

by Chauhan, Himanshu

Hi Aaron, Yes, I am mapping the memory where coreboot.rom is loaded to upper 4GiB. I create a fixed shadow page table entry for reset vector. Coreboot doesn't have a linked address of RIP that I shared. I think with the increase in size of coreboot (from the previous tag I was using) the load address (guest physical) has changed. I used to calculate the load address manually. I will check this and get back. Thanks. On Wed, Dec 14, 2016 at 8:17 PM, Aaron Durbin <adurbin(a)google.com> wrote: > On Wed, Dec 14, 2016 at 3:11 AM, Chauhan, Himanshu > <hschauhan(a)nulltrace.org> wrote: > > Hi, > > > > I am working on a hypvervisor and am using coreboot + FILO as guest BIOS. > > While things were fine a while back, it has stopped working. I see that > my > > hypervisor can't handle address 0xFFFFFC while coreboot's RIP is at > > 0xfff81e41. > > > How are you loading up coreboot.rom in the VM? Are you just memory > mapping it at the top of 4GiB address space? If so, what does > 'cbfstool coreboot.rom print' show? > > > > > The exact register dump of guest is as follow: > > > > [guest0/uart0] (__handle_vm_exception:558) ERROR: No region mapped to > guest > > physical: 0xfffffc > > > > GUEST guest0/vcpu0 dump state: > > > > RAX: 0x9fe80 RBX: 0xfffff8 RCX: 0x1b RDX: 0x53a11439 > > R08: 0x0 R09: 0x0 R10: 0x0 R11: 0x0 > > R12: 0x0 R13: 0x0 R14: 0x0 R15: 0x0 > > RSP: 0x9fe54 RBP: 0xa0000 RDI: 0xfff801e4 RSI: 0x9fe80 > > RIP: 0xfff81e41 > > > > CR0: 0xe0000011 CR2: 0x0 CR3: 0xa23000 CR4: 0x0 > > CS : Sel: 0x00000008 Limit: 0xffffffff Base: 0x00000000 (G: 1 DB: 1 > L: > > 0 AVL: 0 P: 1 DPL: 0 S: 1 Type: 11) > > DS : Sel: 0x00000010 Limit: 0xffffffff Base: 0x00000000 (G: 1 DB: 1 > L: > > 0 AVL: 0 P: 1 DPL: 0 S: 1 Type: 3) > > ES : Sel: 0x00000010 Limit: 0xffffffff Base: 0x00000000 (G: 1 DB: 1 > L: > > 0 AVL: 0 P: 1 DPL: 0 S: 1 Type: 3) > > SS : Sel: 0x00000010 Limit: 0xffffffff Base: 0x00000000 (G: 1 DB: 1 > L: > > 0 AVL: 0 P: 1 DPL: 0 S: 1 Type: 3) > > FS : Sel: 0x00000010 Limit: 0xffffffff Base: 0x00000000 (G: 1 DB: 1 > L: > > 0 AVL: 0 P: 1 DPL: 0 S: 1 Type: 3) > > GS : Sel: 0x00000010 Limit: 0xffffffff Base: 0x00000000 (G: 1 DB: 1 > L: > > 0 AVL: 0 P: 1 DPL: 0 S: 1 Type: 3) > > GDT : Sel: 0x00000000 Limit: 0x0000001f Base: 0xfff80200 (G: 0 DB: 0 > L: > > 0 AVL: 0 P: 0 DPL: 0 S: 0 Type: 0) > > LDT : Sel: 0x00000000 Limit: 0x0000ffff Base: 0x00000000 (G: 0 DB: 0 > L: > > 0 AVL: 0 P: 0 DPL: 0 S: 0 Type: 0) > > IDT : Sel: 0x00000000 Limit: 0x00000000 Base: 0x00000000 (G: 0 DB: 0 > L: > > 0 AVL: 0 P: 0 DPL: 0 S: 0 Type: 0) > > TR : Sel: 0x00000000 Limit: 0x0000ffff Base: 0x00000000 (G: 1 DB: 0 > L: > > 1 AVL: 1 P: 0 DPL: 0 S: 0 Type: 0) > > RFLAGS: 0xa [ ] > > > > I want to know which binary file (.o) should I disassemble to look at the > > RIP? > > > > I was looking at > > objdump -D -mi386 -Maddr16,data16 generated/ramstage.o > > > > but this is prior to linking and thus only has offsets. > > > > -- > > > > Regards > > [Himanshu Chauhan] > > > > > > -- > > coreboot mailing list: coreboot(a)coreboot.org > > https://www.coreboot.org/mailman/listinfo/coreboot > -- Regards [Himanshu Chauhan]

4 years, 1 month

Re: [coreboot] coreboot solidpc

by Peter Stuge

sebastien basset wrote: > For flashing board solidpc, > 1/ plug power supply (without pressing the power button) > 2/ connect dediprog on j8 connector( with good cable) > 3/ ./flashrom -p dediprog:voltage=1.8V -w solidrun.rom Why 1.8V? Is there a schematic available for this board? //Peter

4 years, 1 month

Re: [coreboot] Disassembly of coreboot binaries

by Aaron Durbin

On Wed, Dec 14, 2016 at 3:11 AM, Chauhan, Himanshu <hschauhan(a)nulltrace.org> wrote: > Hi, > > I am working on a hypvervisor and am using coreboot + FILO as guest BIOS. > While things were fine a while back, it has stopped working. I see that my > hypervisor can't handle address 0xFFFFFC while coreboot's RIP is at > 0xfff81e41. How are you loading up coreboot.rom in the VM? Are you just memory mapping it at the top of 4GiB address space? If so, what does 'cbfstool coreboot.rom print' show? > > The exact register dump of guest is as follow: > > [guest0/uart0] (__handle_vm_exception:558) ERROR: No region mapped to guest > physical: 0xfffffc > > GUEST guest0/vcpu0 dump state: > > RAX: 0x9fe80 RBX: 0xfffff8 RCX: 0x1b RDX: 0x53a11439 > R08: 0x0 R09: 0x0 R10: 0x0 R11: 0x0 > R12: 0x0 R13: 0x0 R14: 0x0 R15: 0x0 > RSP: 0x9fe54 RBP: 0xa0000 RDI: 0xfff801e4 RSI: 0x9fe80 > RIP: 0xfff81e41 > > CR0: 0xe0000011 CR2: 0x0 CR3: 0xa23000 CR4: 0x0 > CS : Sel: 0x00000008 Limit: 0xffffffff Base: 0x00000000 (G: 1 DB: 1 L: > 0 AVL: 0 P: 1 DPL: 0 S: 1 Type: 11) > DS : Sel: 0x00000010 Limit: 0xffffffff Base: 0x00000000 (G: 1 DB: 1 L: > 0 AVL: 0 P: 1 DPL: 0 S: 1 Type: 3) > ES : Sel: 0x00000010 Limit: 0xffffffff Base: 0x00000000 (G: 1 DB: 1 L: > 0 AVL: 0 P: 1 DPL: 0 S: 1 Type: 3) > SS : Sel: 0x00000010 Limit: 0xffffffff Base: 0x00000000 (G: 1 DB: 1 L: > 0 AVL: 0 P: 1 DPL: 0 S: 1 Type: 3) > FS : Sel: 0x00000010 Limit: 0xffffffff Base: 0x00000000 (G: 1 DB: 1 L: > 0 AVL: 0 P: 1 DPL: 0 S: 1 Type: 3) > GS : Sel: 0x00000010 Limit: 0xffffffff Base: 0x00000000 (G: 1 DB: 1 L: > 0 AVL: 0 P: 1 DPL: 0 S: 1 Type: 3) > GDT : Sel: 0x00000000 Limit: 0x0000001f Base: 0xfff80200 (G: 0 DB: 0 L: > 0 AVL: 0 P: 0 DPL: 0 S: 0 Type: 0) > LDT : Sel: 0x00000000 Limit: 0x0000ffff Base: 0x00000000 (G: 0 DB: 0 L: > 0 AVL: 0 P: 0 DPL: 0 S: 0 Type: 0) > IDT : Sel: 0x00000000 Limit: 0x00000000 Base: 0x00000000 (G: 0 DB: 0 L: > 0 AVL: 0 P: 0 DPL: 0 S: 0 Type: 0) > TR : Sel: 0x00000000 Limit: 0x0000ffff Base: 0x00000000 (G: 1 DB: 0 L: > 1 AVL: 1 P: 0 DPL: 0 S: 0 Type: 0) > RFLAGS: 0xa [ ] > > I want to know which binary file (.o) should I disassemble to look at the > RIP? > > I was looking at > objdump -D -mi386 -Maddr16,data16 generated/ramstage.o > > but this is prior to linking and thus only has offsets. > > -- > > Regards > [Himanshu Chauhan] > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot

4 years, 1 month

Re: [coreboot] coreboot solidpc

by sebastien basset

i have a post-code when call FspMemoryInit of FSP, do you know post-code FSP, how to retrieve post-code generated by FSP intel ? 2016-12-14 14:15 GMT+01:00 sebastien basset <sbhome1(a)gmail.com>: > Hi, > > For flashing board solidpc, > 1/ plug power supply (without pressing the power button) > 2/ connect dediprog on j8 connector( with good cable) > 3/ ./flashrom -p dediprog:voltage=1.8V -w solidrun.rom > > i'am working on tag 4.5 coreboot. > > Sébastien > > > Le 14 déc. 2016 12:39, "Piotr Król" <piotr.krol(a)3mdeb.com> a écrit : > >> On Wed, Dec 14, 2016 at 10:24:10AM +0100, sebastien basset wrote: >> > Hello, >> >> Hi Sebastien, >> >> > >> > i ve began porting coreboot to solidpc. Have you coreboot working for >> solidPC, >> > today ? >> >> I would be glad to help you with that. I have SolidPC 1.2. Unfortunately >> had problem with setting up with DediProg SF100 and flashrom. What is >> you flashing method ? >> >> > For now, i am stuck in the init of the ram, in call FspMemoryInit: >> > >> > coreboot-4.5-4-gca220c0-dirty Wed Nov 30 13:43:19 UTC 2016 romstage >> starting... >> > FSP TempRamInit successful bist: 0x00000000 tsc: 0x0000000000031628 >> POST: 0x30 >> > CBFS: 'Master Header Locator' located CBFS at [700100:7fffc0) CBFS: >> Locating >> > 'cpu_microcode_blob.bin' CBFS: Found @ offset 4be80 size 10c00 >> microcode: sig= >> > 0x406c4 pf=0x1 revision=0x403 CONFIG_MMCONF_BASE_ADDRESS: 0xe0000000 >> Using FSP >> > 1.1 FSP_INFO_HEADER: fff6e094 FSP Signature: $BSWFSP$ FSP Header >> Version: 2 FSP >> > Revision: 1.1.2.0 pm1_sts: 8900 pm1_en: 0000 pm1_cnt: 00000000 gpe0_sts: >> > 00000000 gpe0_en: 00000000 tco_sts: 00000000 prsts: 00330910 gen_pmcon1: >> > 00245209 gen_pmcon2: 00000000 prev_sleep_state 5 CBFS: 'Master Header >> Locator' >> > located CBFS at [700100:7fffc0) CBFS: Locating 'spd.bin' CBFS: Found @ >> offset >> > 1e0c0 size 400 ram_id=10, total_spds: 4 POST: 0x32 POST: 0x33 FMAP: >> Found >> > "FLASH" version 1.1 at 700000. FMAP: base = ff800000 size = 800000 >> #areas = 3 >> > No MRC cache found. POST: 0x34 VPD Data: 0xfff9839c UPD Data: 0xfff983b0 >> > Updating UPD values for MemoryInit POST: 0x36 Calling FspMemoryInit: >> 0xfffb580f >> > 0x00000000: NvsBufferPtr 0xfef03e2c: RtBufferPtr 0xfef03dd4: HobListPtr >> POST: >> > 0x92 >> >> Can I assume this is recent master ? >> >> Best Regards, >> -- >> Piotr Król >> Embedded Systems Consultant >> http://3mdeb.com | @3mdeb_com >> > -- Sébastien Basset

4 years, 1 month

Re: [coreboot] coreboot solidpc

by Piotr Król

On Wed, Dec 14, 2016 at 10:24:10AM +0100, sebastien basset wrote: > Hello, Hi Sebastien, > > i ve began porting coreboot to solidpc. Have you coreboot working for solidPC, > today ? I would be glad to help you with that. I have SolidPC 1.2. Unfortunately had problem with setting up with DediProg SF100 and flashrom. What is you flashing method ? > For now, i am stuck in the init of the ram, in call FspMemoryInit: > > coreboot-4.5-4-gca220c0-dirty Wed Nov 30 13:43:19 UTC 2016 romstage starting... > FSP TempRamInit successful bist: 0x00000000 tsc: 0x0000000000031628 POST: 0x30 > CBFS: 'Master Header Locator' located CBFS at [700100:7fffc0) CBFS: Locating > 'cpu_microcode_blob.bin' CBFS: Found @ offset 4be80 size 10c00 microcode: sig= > 0x406c4 pf=0x1 revision=0x403 CONFIG_MMCONF_BASE_ADDRESS: 0xe0000000 Using FSP > 1.1 FSP_INFO_HEADER: fff6e094 FSP Signature: $BSWFSP$ FSP Header Version: 2 FSP > Revision: 1.1.2.0 pm1_sts: 8900 pm1_en: 0000 pm1_cnt: 00000000 gpe0_sts: > 00000000 gpe0_en: 00000000 tco_sts: 00000000 prsts: 00330910 gen_pmcon1: > 00245209 gen_pmcon2: 00000000 prev_sleep_state 5 CBFS: 'Master Header Locator' > located CBFS at [700100:7fffc0) CBFS: Locating 'spd.bin' CBFS: Found @ offset > 1e0c0 size 400 ram_id=10, total_spds: 4 POST: 0x32 POST: 0x33 FMAP: Found > "FLASH" version 1.1 at 700000. FMAP: base = ff800000 size = 800000 #areas = 3 > No MRC cache found. POST: 0x34 VPD Data: 0xfff9839c UPD Data: 0xfff983b0 > Updating UPD values for MemoryInit POST: 0x36 Calling FspMemoryInit: 0xfffb580f > 0x00000000: NvsBufferPtr 0xfef03e2c: RtBufferPtr 0xfef03dd4: HobListPtr POST: > 0x92 Can I assume this is recent master ? Best Regards, -- Piotr Król Embedded Systems Consultant http://3mdeb.com | @3mdeb_com

4 years, 1 month

coreboot solidpc

by sebastien basset

Hello, i ve began porting coreboot to solidpc. Have you coreboot working for solidPC, today ? For now, i am stuck in the init of the ram, in call FspMemoryInit: coreboot-4.5-4-gca220c0-dirty Wed Nov 30 13:43:19 UTC 2016 romstage starting... FSP TempRamInit successful bist: 0x00000000 tsc: 0x0000000000031628 POST: 0x30 CBFS: 'Master Header Locator' located CBFS at [700100:7fffc0) CBFS: Locating 'cpu_microcode_blob.bin' CBFS: Found @ offset 4be80 size 10c00 microcode: sig=0x406c4 pf=0x1 revision=0x403 CONFIG_MMCONF_BASE_ADDRESS: 0xe0000000 Using FSP 1.1 FSP_INFO_HEADER: fff6e094 FSP Signature: $BSWFSP$ FSP Header Version: 2 FSP Revision: 1.1.2.0 pm1_sts: 8900 pm1_en: 0000 pm1_cnt: 00000000 gpe0_sts: 00000000 gpe0_en: 00000000 tco_sts: 00000000 prsts: 00330910 gen_pmcon1: 00245209 gen_pmcon2: 00000000 prev_sleep_state 5 CBFS: 'Master Header Locator' located CBFS at [700100:7fffc0) CBFS: Locating 'spd.bin' CBFS: Found @ offset 1e0c0 size 400 ram_id=10, total_spds: 4 POST: 0x32 POST: 0x33 FMAP: Found "FLASH" version 1.1 at 700000. FMAP: base = ff800000 size = 800000 #areas = 3 No MRC cache found. POST: 0x34 VPD Data: 0xfff9839c UPD Data: 0xfff983b0 Updating UPD values for MemoryInit POST: 0x36 Calling FspMemoryInit: 0xfffb580f 0x00000000: NvsBufferPtr 0xfef03e2c: RtBufferPtr 0xfef03dd4: HobListPtr POST: 0x92 -- Sébastien Basset

4 years, 1 month

Disassembly of coreboot binaries

by Chauhan, Himanshu

Hi, I am working on a hypvervisor and am using coreboot + FILO as guest BIOS. While things were fine a while back, it has stopped working. I see that my hypervisor can't handle address 0xFFFFFC while coreboot's RIP is at 0xfff81e41. The exact register dump of guest is as follow: [guest0/uart0] (__handle_vm_exception:558) ERROR: No region mapped to guest physical: 0xfffffc GUEST guest0/vcpu0 dump state: RAX: 0x9fe80 RBX: 0xfffff8 RCX: 0x1b RDX: 0x53a11439 R08: 0x0 R09: 0x0 R10: 0x0 R11: 0x0 R12: 0x0 R13: 0x0 R14: 0x0 R15: 0x0 RSP: 0x9fe54 RBP: 0xa0000 RDI: 0xfff801e4 RSI: 0x9fe80 RIP: 0xfff81e41 CR0: 0xe0000011 CR2: 0x0 CR3: 0xa23000 CR4: 0x0 CS : Sel: 0x00000008 Limit: 0xffffffff Base: 0x00000000 (G: 1 DB: 1 L: 0 AVL: 0 P: 1 DPL: 0 S: 1 Type: 11) DS : Sel: 0x00000010 Limit: 0xffffffff Base: 0x00000000 (G: 1 DB: 1 L: 0 AVL: 0 P: 1 DPL: 0 S: 1 Type: 3) ES : Sel: 0x00000010 Limit: 0xffffffff Base: 0x00000000 (G: 1 DB: 1 L: 0 AVL: 0 P: 1 DPL: 0 S: 1 Type: 3) SS : Sel: 0x00000010 Limit: 0xffffffff Base: 0x00000000 (G: 1 DB: 1 L: 0 AVL: 0 P: 1 DPL: 0 S: 1 Type: 3) FS : Sel: 0x00000010 Limit: 0xffffffff Base: 0x00000000 (G: 1 DB: 1 L: 0 AVL: 0 P: 1 DPL: 0 S: 1 Type: 3) GS : Sel: 0x00000010 Limit: 0xffffffff Base: 0x00000000 (G: 1 DB: 1 L: 0 AVL: 0 P: 1 DPL: 0 S: 1 Type: 3) GDT : Sel: 0x00000000 Limit: 0x0000001f Base: 0xfff80200 (G: 0 DB: 0 L: 0 AVL: 0 P: 0 DPL: 0 S: 0 Type: 0) LDT : Sel: 0x00000000 Limit: 0x0000ffff Base: 0x00000000 (G: 0 DB: 0 L: 0 AVL: 0 P: 0 DPL: 0 S: 0 Type: 0) IDT : Sel: 0x00000000 Limit: 0x00000000 Base: 0x00000000 (G: 0 DB: 0 L: 0 AVL: 0 P: 0 DPL: 0 S: 0 Type: 0) TR : Sel: 0x00000000 Limit: 0x0000ffff Base: 0x00000000 (G: 1 DB: 0 L: 1 AVL: 1 P: 0 DPL: 0 S: 0 Type: 0) RFLAGS: 0xa [ ] I want to know which binary file (.o) should I disassemble to look at the RIP? I was looking at objdump -D -mi386 -Maddr16,data16 generated/ramstage.o but this is prior to linking and thus only has offsets. -- Regards [Himanshu Chauhan]

4 years, 1 month

LGA775 board donation

by Kyösti Mälkki

Hi Cleaning out shelves, and before I trash these two LGA-775 boards I am offering them for price of shipping if someone wants to start poking on coreboot: Commell LV-672 - boots OS - i915, local tree from 2013 has raminit (for the pair of DIMMs installed) - ICH6, FWH flash on PLCC32 socket Asus P5KPL-VM - gets into romstage with serial console - i946, we have no raminit - ICH7, SPI on DIP8 socket - board schematic available for later rev of board Got IO-backplates, CPUs and some DDR2 too. Kyösti

4 years, 1 month

← Newer
1
...
4
5
6
7
8
9
10
...
13
Older →

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot December 2016