coreboot February 2016

coreboot@coreboot.org

31 participants
69 discussions

Re: [coreboot] Can not have IRQ from ethernet device connected to the PCIe #4 in legacy mode
by benoit 23 Feb '16

23 Feb '16

Hi Ben, I confirm that the workaround is working well. Tested it today. My ethernet controller is working right now. Thanks for your help Benoit On 11/02/2016 00:42, Ben Gardner wrote: > Hi Benoit, > > There was a bit of a discussion about interrupt routing a while back > (Dec 2015) on FSP Baytrail. > Apparently the IRQs were not swizzled correctly. > > https://review.coreboot.org/#/c/12684/ > > If you are not using a recent version of coreboot, you may need to > back-port that change. > > Ben > > On Wed, Feb 10, 2016 at 3:00 PM, benoit <benoit.sansoni(a)gmail.com> wrote: >> Hi all, >> >> I am facing a legacy IRQ under OS. >> I am currently using Coreboot + FSP on baytrail. >> My OS is running with IRQ in legacy using PIRQ described in >> coreboot/src/mainboard/intel/bayleybay_fsp/irqroute.h . >> Under the OS USB, SATA, SMBus are working well using legacy interrupt. >> Nevertheless I have an ethernet device connected on the PCIe root #4 and >> no IRQs are received. >> >> I tried to change the IRQ in the interrupt line register without success. >> >> I can compare also with a Phoenix BIOS, and with the same OS binary the >> ethernet is working. >> >> I check out also the ilb registers + 0x4d0 and 0x4d1 registers (ECL). >> Everything is correctly initalized. >> >> Do I need to activate/deactivate something in the PCIe root #4 to >> forward legacy interrupt to the 8259 PIC ? >> >> Many thanks in advance >> Benoit >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> http://www.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] Coreboot X230 step-by-step
by NOQ2 Webmaster 23 Feb '16

23 Feb '16

Am 23.02.2016 um 17:33 schrieb Vadim Bendebury: > That was quite a fun project :) Absolutely :) > I have not read the page in full detail, just curious: was it > necessary to unsolder the chip, was it not possible to program it > using flashrom from Linux command line instead? > > Maybe the ME section is write protected - still, writing the rest of > the image could have worked just fine. As lynxis wrote, currently it does not seem possible to flash it without at least physical access to the chip´s pins :-/ greetings noq2

1 0

ThinkPoint under coreboot
by keboler＠cock.li 23 Feb '16

23 Feb '16

How does the ThinkPoint work under coreboot (specifically the ThinkPad X60s). I ask as I am unable to get it working in the 9front operating system after asking in their IRC channel. It was stipulated in said IRC channel that the ThinkPoint may be emulated in the SMM (system management mode) or that it could do something strange with regards to PS/2 commands, and that special code may be required. -kebolio I'm not subscribed to the list so please cc me

3 2

Re: [coreboot] Coreboot X230 step-by-step
by Alexander Couzens 23 Feb '16

23 Feb '16

On Tue, 23 Feb 2016 08:33:16 -0800 Vadim Bendebury <vbendeb(a)chromium.org> wrote: > I have not read the page in full detail, just curious: was it > necessary to unsolder the chip, was it not possible to program it > using flashrom from Linux command line instead? It may be possible. the main problem is the lenovo bios update. It's still unknown how it's updating the rom. But the lenovo protects the bios region from writing. AFAIK there is a *scratch* region writeable possible for bios updates. best, lynxis -- Alexander Couzens mail: lynxis(a)fe80.eu jabber: lynxis(a)fe80.eu mobile: +4915123277221 gpg: 390D CF78 8BF9 AA50 4F8F F1E2 C29E 9DA6 A0DF 8604

2 1

Coreboot X230 step-by-step
by NOQ2 Webmaster 23 Feb '16

23 Feb '16

I did a writeup for getting coreboot onto a Thinkpad X230, if anyone is interested. It´s intended to help others find their way through, so please don´t hesitate to contact me if you have suggestions for improvements: https://blog.noq2.net/corebooting-thinkpad-x230.html greetings noq2

2 1

Re: [coreboot] Coreboot boot process
by Marcos Scriven 23 Feb '16

23 Feb '16

Hi Daoud This might be a good start: https://docs.google.com/presentation/d/1eGPMu03vCxIO0a3oNX8Hmij_Qwwz6R6ViFC… Marcos On Tue, Feb 23, 2016 at 1:17 PM, daoud yessine <yessine.daoud.92(a)gmail.com> wrote: > Hello > > I am searching a document describing the boot process of coreboot with > details ( modules , functions , ... ) > who can help me ? > > thanks > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] Issues building a ROM for Toshiba Chromebook 2 (aka Swanky)
by Marcos Scriven 23 Feb '16

23 Feb '16

Sorry to follow up so soon - but just noticed an error in my post. I meant *fallback/refcode *not *fallback/romstage, *which although still slightly different in size was at least built rather than extracted and re-inserted, and is at the same offset as the original. On Tue, Feb 23, 2016 at 3:41 PM, Marcos Scriven <marcos(a)scriven.org> wrote: > Hi all > > I've built a ROM for swanky which just results in a brick, and wondering > if anyone else has had success with this (or any Bay Trail Chromebook), or > could otherwise provide guidance please. > > I've been able to reprogram the ROM directly, and am working with a > patched boot stub region for now. I'm happy to experiment with ROM builds > that will brick the machine (though annoyingly on the Toshiba Chromebook 2 > the Winbond chip is just a little too close to the shielding/heatsink, so I > have to take that off too (sadpanda)). > > Some links for context: > > ROM build artifact: > https://github.com/marcosscriven/chromebook-coreboot/releases/download/rele… > > Config: > https://github.com/marcosscriven/chromebook-coreboot/blob/release-145623835… > > Build script: > https://github.com/marcosscriven/chromebook-coreboot/blob/release-145623835… > > Build log: > https://travis-ci.org/marcosscriven/chromebook-coreboot/builds/111222889#L2… > > > (NB The build log is for multiple boards, and includes other full and boot > stub builds, so use the log link above to the line where the full swanky > rom build starts.) > > Here's the layout for the custom build: > > > *vagrant@vagrant-ubuntu-trusty-64:~$ cbfstool swanky.rom print* > *swanky.rom: 8192 kB, bootblocksize 1184, romsize 8388608, offset 0x700000* > *alignment: 64 bytes, architecture: x86* > > *Name Offset Type Size* > *cmos_layout.bin 0x700000 cmos_layout 1164* > *pci8086,0f31.rom 0x7004c0 optionrom 65536* > *cpu_microcode_blob.bin 0x710500 microcode 104448* > *config 0x729d80 raw 4555* > *fallback/refcode 0x72af80 stage 4171* > *etc/boot-menu-key 0x72c040 raw 1* > *etc/boot-menu-message 0x72c0c0 raw 27* > *(empty) 0x72c140 null 15896* > *fallback/romstage 0x72ff80 stage 35475* > *fallback/coreboot_ram 0x738a80 stage 74547* > *fallback/payload 0x74ae00 payload 103192* > *(empty) 0x764180 null 245272* > *mrc.bin 0x79ffc0 spd 70168* > *(empty) 0x7b1240 null 240984* > *spd.bin 0x7ebfc0 spd 1024**(empty) > 0x7ec400 null 79576* > > > And here's the layout for a backup made via SPI directly on the chip > (Implied *0x700000 *offset): > > *vagrant@vagrant-ubuntu-trusty-64:~$ cbfstool swanky-by-spi.bin print -r > BOOT_STUB* > *Performing operation on 'BOOT_STUB' region...* > *Name Offset Type Size* > *cmos_layout.bin 0x0 cmos_layout 1164* > *pci8086,0f31.rom 0x4c0 optionrom 65536* > *cpu_microcode_blob.bin 0x10500 microcode 104448* > *config 0x29d80 raw 5259* > *fallback/vboot 0x2b240 stage 15518* > *(empty) 0x2ef40 null 4120* > *fallback/romstage 0x2ff80 stage 36458* > *fallback/coreboot_ram 0x38e80 stage 82415* > *fallback/refcode 0x4d0c0 stage 4296* > *fallback/payload 0x4e1c0 payload 67396* > *u-boot.dtb 0x5e940 mrc_cache 4842* > *(empty) 0x5fc80 null 258840* > *mrc.bin 0x9efc0 spd 70168* > *(empty) 0xb0240 null 245080* > *spd.bin 0xebfc0 spd 1024* > *(empty) 0xec400 null 78360* > > > The labels, offsets, types, and sizes of all the various blobs looks fine > *except fallback/romstage**.* (vboot and u-boot are gone as I don't need > verification, which worked fine for my wolf build.) > > I'm not sure why my build (from the same commit hash of Google's coreboot > fork as in the config extracted from original rom) is placing that blob at > a different offset? I can't see anything in the config that would affect > that. > > The more troubling thing is my refcode is a little smaller! I've extracted > it from the shellball with this method here: > https://github.com/marcosscriven/chromebook-coreboot/blob/release-145623835… > > So far as I can tell *fallback/refcode *is a (U)EFI blob, the failure of > which I'd imagine would result in not booting from disk, but not entirely > sure it's the reason I seeing nothing at all. > > I guess the thing I'd find most helpful is guidance on *how to debug this* > myself? Only two things I could find: > > 1) A mention of 'USB to USB' in a 2013 Coreboot presentation: > https://docs.google.com/presentation/d/1eGPMu03vCxIO0a3oNX8Hmij_Qwwz6R6ViFC… > > It's not entirely clear how this works - so far as I can tell it's > essentially USB OTG, where the Chromebook USB port could act as a client. I > don't see though how the CPU sets that up before the ROM code even runs, > unless it's some microcode in the processor itself? > > > 2) I've also seen mention of Servo, but I don't seen any such header on my > board. Looking at a photo of the Acer C720 here, it does look like there's > an oblong space with pads there, but that would be a hell of a surface > mounting job: > https://www.chromium.org/chromium-os/developer-information-for-chrome-os-de… > > > I hope I've provided sufficient background info, but if anyone's willing > or able to help, I'd of course be happy to add more detail. > > Thanks > > Marcos >

1 0

Issues building a ROM for Toshiba Chromebook 2 (aka Swanky)
by Marcos Scriven 23 Feb '16

23 Feb '16

Hi all I've built a ROM for swanky which just results in a brick, and wondering if anyone else has had success with this (or any Bay Trail Chromebook), or could otherwise provide guidance please. I've been able to reprogram the ROM directly, and am working with a patched boot stub region for now. I'm happy to experiment with ROM builds that will brick the machine (though annoyingly on the Toshiba Chromebook 2 the Winbond chip is just a little too close to the shielding/heatsink, so I have to take that off too (sadpanda)). Some links for context: ROM build artifact: https://github.com/marcosscriven/chromebook-coreboot/releases/download/rele… Config: https://github.com/marcosscriven/chromebook-coreboot/blob/release-145623835… Build script: https://github.com/marcosscriven/chromebook-coreboot/blob/release-145623835… Build log: https://travis-ci.org/marcosscriven/chromebook-coreboot/builds/111222889#L2… (NB The build log is for multiple boards, and includes other full and boot stub builds, so use the log link above to the line where the full swanky rom build starts.) Here's the layout for the custom build: *vagrant@vagrant-ubuntu-trusty-64:~$ cbfstool swanky.rom print* *swanky.rom: 8192 kB, bootblocksize 1184, romsize 8388608, offset 0x700000* *alignment: 64 bytes, architecture: x86* *Name Offset Type Size* *cmos_layout.bin 0x700000 cmos_layout 1164* *pci8086,0f31.rom 0x7004c0 optionrom 65536* *cpu_microcode_blob.bin 0x710500 microcode 104448* *config 0x729d80 raw 4555* *fallback/refcode 0x72af80 stage 4171* *etc/boot-menu-key 0x72c040 raw 1* *etc/boot-menu-message 0x72c0c0 raw 27* *(empty) 0x72c140 null 15896* *fallback/romstage 0x72ff80 stage 35475* *fallback/coreboot_ram 0x738a80 stage 74547* *fallback/payload 0x74ae00 payload 103192* *(empty) 0x764180 null 245272* *mrc.bin 0x79ffc0 spd 70168* *(empty) 0x7b1240 null 240984* *spd.bin 0x7ebfc0 spd 1024**(empty) 0x7ec400 null 79576* And here's the layout for a backup made via SPI directly on the chip (Implied *0x700000 *offset): *vagrant@vagrant-ubuntu-trusty-64:~$ cbfstool swanky-by-spi.bin print -r BOOT_STUB* *Performing operation on 'BOOT_STUB' region...* *Name Offset Type Size* *cmos_layout.bin 0x0 cmos_layout 1164* *pci8086,0f31.rom 0x4c0 optionrom 65536* *cpu_microcode_blob.bin 0x10500 microcode 104448* *config 0x29d80 raw 5259* *fallback/vboot 0x2b240 stage 15518* *(empty) 0x2ef40 null 4120* *fallback/romstage 0x2ff80 stage 36458* *fallback/coreboot_ram 0x38e80 stage 82415* *fallback/refcode 0x4d0c0 stage 4296* *fallback/payload 0x4e1c0 payload 67396* *u-boot.dtb 0x5e940 mrc_cache 4842* *(empty) 0x5fc80 null 258840* *mrc.bin 0x9efc0 spd 70168* *(empty) 0xb0240 null 245080* *spd.bin 0xebfc0 spd 1024* *(empty) 0xec400 null 78360* The labels, offsets, types, and sizes of all the various blobs looks fine *except fallback/romstage**.* (vboot and u-boot are gone as I don't need verification, which worked fine for my wolf build.) I'm not sure why my build (from the same commit hash of Google's coreboot fork as in the config extracted from original rom) is placing that blob at a different offset? I can't see anything in the config that would affect that. The more troubling thing is my refcode is a little smaller! I've extracted it from the shellball with this method here: https://github.com/marcosscriven/chromebook-coreboot/blob/release-145623835… So far as I can tell *fallback/refcode *is a (U)EFI blob, the failure of which I'd imagine would result in not booting from disk, but not entirely sure it's the reason I seeing nothing at all. I guess the thing I'd find most helpful is guidance on *how to debug this* myself? Only two things I could find: 1) A mention of 'USB to USB' in a 2013 Coreboot presentation: https://docs.google.com/presentation/d/1eGPMu03vCxIO0a3oNX8Hmij_Qwwz6R6ViFC… It's not entirely clear how this works - so far as I can tell it's essentially USB OTG, where the Chromebook USB port could act as a client. I don't see though how the CPU sets that up before the ROM code even runs, unless it's some microcode in the processor itself? 2) I've also seen mention of Servo, but I don't seen any such header on my board. Looking at a photo of the Acer C720 here, it does look like there's an oblong space with pads there, but that would be a hell of a surface mounting job: https://www.chromium.org/chromium-os/developer-information-for-chrome-os-de… I hope I've provided sufficient background info, but if anyone's willing or able to help, I'd of course be happy to add more detail. Thanks Marcos

1 0

Coreboot boot process
by daoud yessine 23 Feb '16

23 Feb '16

Hello I am searching a document describing the boot process of coreboot with details ( modules , functions , ... ) who can help me ? thanks

1 0

Re: [coreboot] [RFC] board-status.git growth
by Timothy Pearson 18 Feb '16

18 Feb '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/17/2016 04:28 PM, Martin Roth wrote: > It's definitely an issue, and it's actually something that is > currently being looked into. As always, we just need someone to do > the work. :) > > There's a project listed on the project ideas wiki page about this, so > maybe we'll get an enterprising person to work on it. If not, we'll > probably continue with git for now, but put a web front-end on it so > that the project doesn't need to be downloaded to add to the database. > Here's a link to it in the wiki: > https://www.coreboot.org/Project_Ideas#coreboot_mainboard_test_suite_report… > > I think we all agree that git isn't the right way to do this, but it > was infrastructure we had in place, so it was an easy way to add what > was needed at the time. We're reaching a pain point on that, so it's > definitely time to do SOMETHING about it. > > Martin I remember bringing this issue up quite a while back, good to see progress is still being made. I'd like to request that the new system allow upload of status reports from branches, not just master. Thanks! - -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) http://www.raptorengineeringinc.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJWxixZAAoJEK+E3vEXDOFbGGYH/3X611o6I3Yakxbj7rq+QdcE WBApWj12yup+sXZ9Y2tNcwEQ/jd77g2yX/9mTI72N4yYF5rhZ6aMN2EsotgMORnP fHeDoPww0NwLVC8epvLVLcHt1pgXm18109jDyhzIsIBmtZiT8mLTQfaGU6ExQzl8 m9wcBNNCuc0RdJO1dtcG1KzVzyd0s8PDNJOsRrvOvKCB4USMKA3+jV7wdzY6ggnJ /7Mo8EmzTt8zaSc6W3R5HSl5T5JBjv/knTM2oZ3/oKqdFIy90L9J2vXSEUxOJBE3 K5ryRPEttIFOG8NC9C5TbykoiEdMYw4fErdJXCPg6GJechPr+Ptc9rChhSb2nSo= =hWyV -----END PGP SIGNATURE-----

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot February 2016