coreboot November 2013

coreboot@coreboot.org

53 participants
117 discussions

Booted IVB with FSP -> Coreboot -> SeaBIOS (1.7.3 with CSM mode set) -> Win 8.1 bootloader -> Win8.1
by Stojsavljevic, Zoran 11 Nov '13

11 Nov '13

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

lint-stable-002-build-dir-handling problem while git commit -s
by Gelip 10 Nov '13

10 Nov '13

Hi. I try commit support for new motherboard Abit BF6 but while git commit -s have error lint-stable: Problem resolved with this help: http://comments.gmane.org/gmane.linux.bios/72840. After change name: util/lint/lint-stable-002-build-dir-handlingtoutil/lint/lint-002-build-dir-handlingno errors but not tested with git push. Is the result of this operation can be done git push?

1 0

Re: [coreboot] Help required to boot DUET (Seabios floppy mechanism)
by Scott Duplichan 09 Nov '13

09 Nov '13

Anthony Ross wrote: ]Hello Coreboot Folks, ] ]Well Thanks for the suggestions. It seems that DUET boots but now a major problem has ]cropped up. It freezes at the main DUET-BIOS page not allowing to perform any further ]operations, like booting a HDD image or fingering around the EFI BIOS options. Similarly ]If I had the .lzma to the cbfs file name I face the same problem like earlier so having ]it as myfloppy.img makes it take effect. ] ] ]Any further Ideas about these problems..... ] ] ]Regards.. ] ] ]Neo For your freeze problem, how are you debugging? The usual way is to enable and capture debug messages written to a serial port. I believe the standard Duet settings make it write debugging messages to a serial port at 3F8 (115200,8,N,1). Because halt for assert is enabled by default on Duet, an assert is the most likely reason for a freeze. The assert will log details to the serial port. If your hardware doesn't have a serial port, you can use an emulator such as simnow or qemu. A good thing about Duet is that it is generic and in theory can run on different systems without porting. If I remember correctly, the current Duet project can boot to the UEFI shell and menu system on AMD simnow using the Solo board model. I am working on a project to allow Duet to run as a coreboot payload, and to fix the major Duet problems. It will also continue to support bootable image form. It may take me a few weeks to reach the goal of booting operating systems in UEFI mode on real hardware though. Thanks, Scott On Sat, Oct 26, 2013 at 8:01 PM, Kevin O'Connor <kevin(a)koconnor.net> wrote: On Thu, Oct 24, 2013 at 12:17:33AM -0500, Scott Duplichan wrote: > Scott Duplichan wrote: > > <..snip..> > > ]I have no experience with making SeaBIOS boot an embedded floppy > ]image. I may be able to give this a try, but I would have to first overcome > ]Windows build problems that have crept into both SeaBIOS and coreboot. > > I tested the SeaBIOS virtual floppy boot with EDK2 Duet and it worked > for me. I tested with the ASRock e350M1 project. Here is the cbfstool > output: Thanks for confirming. > scott@p67-2600k /D/coreboot/win-build-env-011/coreboot/build > $ cbfstool.exe coreboot.rom print > coreboot.rom: zd kB, bootblocksize 4096, romsize 1008, offset 0x400000 > alignment: 0 bytes > > Name Offset Type Size > cmos_layout.bin 0x0 cmos_layout 1776 > pci1002,9802.rom 0x740 optionrom 57856 > fallback/romstage 0xe980 stage 345432 > fallback/coreboot_ram 0x62f40 stage 203312 > fallback/payload 0x949c0 payload 53738 > config 0xa1c00 raw 3831 > (empty) 0xa2b40 null 3526744 > > scott@p67-2600k /D/coreboot/win-build-env-011/coreboot/build > $ cbfstool.exe coreboot.rom add -f /d/duetfloppy.img -n floppyimg/duetfloppy.img -t raw FYI, it's also possible to add an lzma compressed image (make sure the cbfs filename ends in ".lzma" then). -Kevin

3 6

Re: [coreboot] ASSERTION FAILED: file 'src/mainboard/amd/parmer/agesawrapper.c', line 431
by WANG Siyuan 09 Nov '13

09 Nov '13

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. -- Yours sincerely, WANG Siyuan

1 0

Re: [coreboot] ASSERTION FAILED: file 'src/mainboard/amd/parmer/agesawrapper.c', line 431
by Bruce Griffith 08 Nov '13

08 Nov '13

No one has taken the time to debug this error because it doesn’t seem to break anything. So it is only a nuisance. The fact that AGESA reports it at all indicates that AGESA thinks something is wrong or inconsistent. It is probably the wrong approach to just disable the message. Investigating the cause is on the “to-do list”. If you have the time, it would be helpful to the AGESA coreboot wrapper developers to trace the failure from where it is reported in the AGESA wrapper back to where the error is discovered. For now, it is safe to ignore the message. *From:* Prop 395 [mailto:prop395@gmail.com] *Sent:* 06 November 2013 5:42 PM *To:* coreboot(a)coreboot.org; kyosti.malkki(a)gmail.com; paulepanter(a)users.sourceforge.net; kimarie.hoot(a)se-eng.com; steve.goodrich(a)se-eng.com; reinauer(a)chromium.org; dave.frodin(a)se-eng.com; Bruce.Griffith(a)se-eng.com; wangsiyuanbuaa(a)gmail.com; fishbaozi(a)gmail.com *Subject:* ASSERTION FAILED: file 'src/mainboard/amd/parmer/agesawrapper.c', line 431 I am getting this AGESA error when booting Parmer with SeaBIOS. Contents of log: http://pastebin.com/xjANhWts Any help appreciated.

1 0

Re: [coreboot] BadBIOS Thoughts
by ron minnich 08 Nov '13

08 Nov '13

On Fri, Nov 8, 2013 at 12:32 AM, Stojsavljevic, Zoran <zoran.stojsavljevic(a)intel.com> wrote: > Very soon HSW based (mother)boards will be able to run with INTEL HSW FSP -> Coreboot -> SeaBIOS very interesting! Keep us informed! ron

1 0

Re: [coreboot] BadBIOS Thoughts
by Stojsavljevic, Zoran 08 Nov '13

08 Nov '13

-----Original Message----- > I really like the haswell chromebooks. The acer is small, light, cool, long battery. The HP is bigger, still cool, long battery. > > You have to pop into dev mode and run a chroot. Very soon HSW based (mother)boards will be able to run with INTEL HSW FSP -> Coreboot -> SeaBIOS 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

Re: [coreboot] Fwd: reset vector issue
by Stefan Reinauer 07 Nov '13

07 Nov '13

* ron minnich <rminnich(a)gmail.com> [131107 16:09]: > Very interesting note. We've never seen this before. Comments? We did see this before.. We actually had a wbinvd there for a while, at least in the ChromeOS tree. And removed it because it broke some hardware. Stefan

1 0

Re: [coreboot] Fwd: reset vector issue
by Peter Stuge 07 Nov '13

07 Nov '13

ron minnich wrote: > restoring it post-jump would not help Ron, please do read the commit messages. Or please do read the code. For convenience I'm attaching both log and code as a text file. //Peter

2 1

Re: [coreboot] Fwd: reset vector issue
by Kyösti Mälkki 07 Nov '13

07 Nov '13

On 07.11.2013 17:59, ron minnich wrote: > On Thu, Nov 7, 2013 at 7:34 AM, Kyösti Mälkki <kyosti.malkki(a)gmail.com> wrote: > >> So we had it, then we no longer had it. Looks like there was not enough >> interest to determine the cases when it is needed. > > its presence hurt on the p4 (which is when that happened) and its > absence never hurt. But from this note, restoring it post-jump would > not help; the author is specifically stating that we need it BEFORE > the power-on-reset jump. > > hmm. > > ron > Patch merged into coreboot/master: c35c461 Invalidate cache before first jump And the discussion that ended up with reverting the commit: http://www.coreboot.org/pipermail/coreboot/2012-April/069430.html Kyösti

2 1

← Newer
1
...
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 November 2013