November 2013 - coreboot - mail.coreboot.org

Re: [coreboot] BadBIOS Thoughts
by Alex Nov. 15, 2013

Nov. 15, 2013

On 11/02/2013 01:57 PM, ron minnich wrote: > [...] If you really want a system you > can trust a bit more, get a Chromebook. The amount of work done in > Chromebooks to protect it is extensive and extends beyond the 386 > firmware to the ME and the EC and even aspects of the IO devices. > I'm sorry Ron, but you're just asking me to take your word for it. I can't do that. There's more secret code running on a Chromebook's firmware than there is free code. In fact, I would argue, most code where attack vectors could hide is secret. It's a foul's paradise. Alex

5 5

Re: [coreboot] DUET freeze problem
by Scott Duplichan Nov. 15, 2013

Nov. 15, 2013

Anthony Ross wrote: ]Hello There, ] ]There has been no response to my last mentioned problem ](Seabios floppy mechanism) DUET freeze. So also could ]anyone look up the code to execute DUET as a coreboot payload. ] ]Regards................... ] ]Neo..... Hello, The attachment you sent on 11/06/2013 shows that your serial port logging is working well. If you are not seeing the debug messages from updatememorymap (), then it is possible execution is hanging before that code is able to execute. That code is part of BdsDxe.efi. That module is entered when dxemain.c executes gBds->Entry (gBds). You could put some debug prints in that area to see what is happening. The existing UEFI coreboot payload project is here: https://github.com/pgeorgi/edk2/tree/coreboot-pkg The UEFI coreboot payload project that I am working on won't be ready for a long time. Thanks, Scott

1 0

Re: [coreboot] BadBIOS Thoughts
by Alex Nov. 14, 2013

Nov. 14, 2013

On 11/04/2013 07:28 PM, ron minnich wrote: > well, there's no chromebook I can think of that will meet your needs. Then the problem is not that people don't care. Any plans for a quad-core chromebook in the near future? > You're better off doing a port, sorry. Crap! Alex

3 2

Re: [coreboot] BadBIOS Thoughts
by Denis 'GNUtoo' Carikli Nov. 14, 2013

Nov. 14, 2013

On Sun, 3 Nov 2013 21:47:13 -0800 David Hendricks <david.hendricks(a)gmail.com> wrote: > Anyway, if you can find more open Intel-based systems* I'd like to > see 'em. The lenovo X60? > > *Before anyone suggests Minnowboard, don't. The pile of > restrictively-licensed binary blobs necessary to boot those things > rules them out. Thanks a lot for the information. Denis.

2 1

Re: [coreboot] Fwd: reset vector issue
by Denis 'GNUtoo' Carikli Nov. 14, 2013

Nov. 14, 2013

Hi, ron minnich <rminnich(a)gmail.com> wrote: > I read both, all parts, from 2004 to now. > > Muting this discussion. Peter, your comments are not helpful. Sorry I > bothered you, folks. Have a nice day. I'm probably doing something wrong by continuing that discussion, but that kind of things seem really interesting. Sadly the kind of fixes mentioned before in this thread seems to be a kind of black magic: I guess that only the vendors know why they're really needed and what they really do. _start in src/cpu/x86/16bit/entry16.inc has also some interesting comments( including one on the cache invalidation). I came accross all that with my first attempts of my newer fallback mecanism work (the idea is to make "what's after the ramstage" declare that the computer booted successfuly). Denis.

1 0

Re: [coreboot] [edk2] Passing Xen memory map and resource map to OVMF
by Gerd Hoffmann Nov. 14, 2013

Nov. 14, 2013

Hi, > > So why ovmf should be different? IMHO it should operate like seabios > > and NOT do pci ressource allocation when running on xen. Ressources are > > already handled already by hvmloader. Doing it again is (a) pointless > > and (b) creates problems like the one we are discussion right now. > > > > Agreed. But the protocol to allocate PCI resources seems to be mandatory > according to UEFI spec [0]. > > --- page 16 > The following protocols are mandatory if the system supports PCI devices > or slots: > • EFI_PCI_HOST_BRIDGE_RESOURCE_ALLOCATION_PROTOCOL > • EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL > -- > > I'm more than happy to disable that allocation protocol if there's a way. Disabling isn't going to fly I suspect. But maybe it is possible to add a read-only mode to these protocols, so they just enumerate the pci bus(es), read the pci bar registers and create whatever data structures ovmf needs to drive the pci devices. But don't try to manage the pci ressources. That would also be useful when running tianocore as coreboot payload, which is a simliar situation: coreboot already did the pci enumeration and tianocore doesn't need to do it again (Cc'ing coreboot list). cheers, Gerd

1 0

Re: [coreboot] ASSERTION FAILED: file 'src/mainboard/amd/parmer/agesawrapper.c', line 431
by Prop 395 Nov. 13, 2013

Nov. 13, 2013

On 11/08/2013 05:54 PM, WANG Siyuan wrote: > Hi, Prop > Would you provide the board version? > > On Thu, Nov 7, 2013 at 8:42 AM, Prop 395 <prop395(a)gmail.com> wrote: >> I am getting this AGESA error when booting Parmer with SeaBIOS. >> >> Contents of log: >> http://pastebin.com/xjANhWts >> >> Any help appreciated. > > Hello Wang, I have a Rev C motherboard.

1 0

fam15tn hudson PCIe GPP ports off after resume
by Rudolf Marek Nov. 13, 2013

Nov. 13, 2013

Hi all, I fixed the memory voltage cut-off problem on Asus F2A85-M [1], but I have now other problem. The GPP ports of hudson SB are gone after resume from S3. The devices 15.0 and 15.1 are disabled (decodes as ffff), therefore anything behind them too. I tried to debug that for some hours but so far no luck. It looks like there is something wrong with PortPresent in GPP structure, but I'm not sure. I also noticed that CMOS_RAM is used for this part of AGESA. Zheng, please do you know what this could be? I tried with your recent (and now merged) change for s3 handling but it did not help. Idwer and Zheng also reported that USB does not work after suspend (this seems to be generic fam15tn problem). So far the board resumes even back to X, (although I dont use USB) but ethernet controller is dead (it is behind the SB GPP). [1] http://review.coreboot.org/#/c/4041/ Thanks Rudolf

1 0

DUET freeze problem
by Anthony Ross Nov. 12, 2013

Nov. 12, 2013

Hello There, There has been no response to my last mentioned problem (Seabios floppy mechanism) DUET freeze. So also could anyone look up the code to execute DUET as a coreboot payload. Regards................... Neo.....

1 0

Re: [coreboot] Booted IVB with FSP -> Coreboot -> SeaBIOS (1.7.3 with CSM mode set) -> Win 8.1 bootloader -> Win8.1
by Marc Jones Nov. 11, 2013

Nov. 11, 2013

Hi Zoran, Yes, that is our expectation. We should be landing these patches soon... Thanks for the report. Regards, Marc On Mon, Nov 11, 2013 at 8:35 AM, Stojsavljevic, Zoran <zoran.stojsavljevic(a)intel.com> wrote: > Hello Patrick, Marc, > > > > Half an hour ago I was able to make it on IVB Emerald Lake 2 CRB, using > sequence: FSP -> Coreboot -> SeaBIOS (1.7.3 with CSM mode set) -> Win 8.1 > bootloader -> Win8.1! > > > > I used the real, a week old SeaBIOS image from git repo: SeaBIOS version > 1.7.3-88-gf08e847. > > > > In other words, this does mean that Marc’s Jones patches will work after new > Coreboot release. Please, note that just initial testing is done to this > load! > > > > Best Regards, > > Zoran > > _______ > > Most of The Time you should be “intel inside” to be capable to think “out of > the box”. > > > > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen, Deutschland > Sitz der Gesellschaft: Feldkirchen bei Muenchen > Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk > Registergericht: Muenchen HRB 47456 > Ust.-IdNr./VAT Registration No.: DE129385895 > Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052

1 0