coreboot November 2015

coreboot@coreboot.org

38 participants
97 discussions

Re: [coreboot] sgabios ans grub2 payload (without SeaBIOS)
by maxime de Roucy 05 Nov '15

05 Nov '15

2015-11-05 5:39 GMT+01:00 Martin Roth <gaumless(a)gmail.com>: > The problem with this approach is that coreboot will only run the roms > actually associated with hardware. I don't believe that there's > currently any way to have it run an option rom that isn't tied to a > pci hardware device ID the way that SeaBIOS does with the vgaroms > 'directory'. I tried to bind sgabios with some PCI device. As I don't have VGA card I attached it to the first PCI device but it doesn't work. Attached : lspci, config and coreboot spew output. -- Regards Maxime

1 0

Re: [coreboot] sgabios ans grub2 payload (without SeaBIOS)
by Gerd Hoffmann 05 Nov '15

05 Nov '15

On Do, 2015-11-05 at 01:02 +0100, maxime de Roucy wrote: > 2015-11-04 20:39 GMT+01:00 Gerd Hoffmann <kraxel(a)redhat.com>: > > I'd suggest to just have grub2 drive the serial line directly, IIRC the > > magic words are "terminal_input serial; terminal_output serial". > > I know this solution but I prefere sgabios myself as it allow me to > chainload non serial compatible elements. That isn't going to work I think. sgabios works by hijaking vgabios, and when loaded as coreboot payload grub2 probably will not try to use vgabios in the first place ... cheers, Gerd

1 0

New on blogs.coreboot.org: coreboot changelog
by WordPress 05 Nov '15

05 Nov '15

1 0

Re: [coreboot] Asus M2N-E no boot, post codes A5 80 73
by Balázs Vinarz 05 Nov '15

05 Nov '15

Hi, the first postlog is the same, so A5-80 in an endless loop, there was one time when its end with 79 then shuts down itself, thistime the memory is in the B1 slot. I was made a video at 60fps, and its more accurate, so the sequence is FF-88-80-88-78-72-28-29-24-29-25-55-89-73 than a shutdown, this time the memory is in the A1 slot. Im using a single-core Athlon64 3000+. I will have a try with the 2012 source, if i found one. Sadly im working on ramdisk, and the toolchain compile takes a while even if 4 cores :) Im also considering to build a parmanents toolchain, but thats my own problem at the moment. Best regards.

1 0

Re: [coreboot] sgabios ans grub2 payload (without SeaBIOS)
by Gerd Hoffmann 05 Nov '15

05 Nov '15

On Mi, 2015-11-04 at 11:02 +0100, maxime de Roucy wrote: > Hello, > > I would like to know if it's possible to load and use sgabios with > grub2 as coreboot payload (no SeaBIOS in the rom). > I didn't test it yet but maybe you can tel me if it's possible or not. > And even better : how to do it. :) I'd suggest to just have grub2 drive the serial line directly, IIRC the magic words are "terminal_input serial; terminal_output serial". cheers, Gerd

2 1

Re: [coreboot] A case for branching AGESA
by Martin Roth 05 Nov '15

05 Nov '15

Hi Alex, Sorry, I should have said 'removal from the coreboot master branch'. That's what we're discussing in both contexts. All 'removed' chips and platforms will still be accessible in one of the version branches if desired. Nico demonstrated this today by cherry-picking patches over to the 4.2 branch. Martin On Wed, Nov 4, 2015 at 3:02 PM, Alex Gagniuc <mr.nuke.me(a)gmail.com> wrote: > On Wed, Nov 4, 2015 at 8:09 AM, Martin Roth <gaumless(a)gmail.com> wrote: >> Let's table the discussion of agesa (and other) platform removal for >> now. > > I didn't talk about removal. I don't understand why people think > "removal" in the context of the discussion I _attempted_ to start. > Let's also table the discussion about agesa (and other) platform > branching. > > I'm looking forward to seeing the draft of the removal plans. Maybe > removal is even better than branching. > > Alex

1 0

Re: [coreboot] A case for branching AGESA
by Alex Gagniuc 04 Nov '15

04 Nov '15

On Wed, Nov 4, 2015 at 8:09 AM, Martin Roth <gaumless(a)gmail.com> wrote: > Let's table the discussion of agesa (and other) platform removal for > now. I didn't talk about removal. I don't understand why people think "removal" in the context of the discussion I _attempted_ to start. Let's also table the discussion about agesa (and other) platform branching. I'm looking forward to seeing the draft of the removal plans. Maybe removal is even better than branching. Alex

1 0

Is it possible to flash coreboot with proprietary vendor tools?
by Iru Cai 04 Nov '15

04 Nov '15

Hi, Can I use proprietary vendor tools like winflash or a vendor BIOS update disk to flash coreboot? I don't think it possible but I can't find a reason to explain, or it may be possible if I modify the ROM format to fit those tools. Iru Cai

3 2

Re: [coreboot] [RFC] Time until patches should be submitted
by Timothy Pearson 04 Nov '15

04 Nov '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/04/2015 10:07 AM, Martin Roth wrote: > As others have stated, my concern is the tradeoff between long and > short times. Too short a time, and people don't getting the chance to > review patches. Too long a time and it delays development, frustrates > developers, and requires rebasing the patch, maybe requiring MORE > review. > > Alternate thoughts or proposals: > - "Note that some contributors prefer to work on coreboot during > business hours, so consider leaving patches up longer than 24 hours > during weekends and holidays" > This of course presents other issues of dealing with holidays in > various countries, time zones, etc. > > - Trivial patches (Whitespace, spelling, and the like) can be > submitted with no delay. Non-trivial commits touching fewer than 20 > lines of code should be submitted no sooner than 24 hours after the > last major change. Changes larger than that 20 lines should wait at > least 48? 72? hours after the last major change. > > Paul also mentioned that a method of getting non-trivial patches in > quickly should be addressed as well. This should not be a regular > occurrence, but sometimes we need or desire to push a patch quickly. > He suggested 2 +2s and a statement to the mailing list. To me, this > defeats the purpose of quick. > > Yesterday tpearson requested on IRC that we get a patch in quickly. > It was, in my opinion significant, although just a single line change, > which made it easy to understand and review. We got 3 +2s on it in > just a few minutes. I thought that was a good barrier and would like > to propose that as the rule: If you can get 3 +2s, knowing that it's > going to be submitted immediately, it can be submitted. If this gets > abused, it can be reviewed and changed at some point in the future. > > Martin Yes, this is a good compromise. There isn't very much we can do about latency on non-emergency patches; however due to the increased delays per-patch, patch trains will become the dominant method of submitting large changes (I am expecting a variant of Little's Law to hold here). As a result, the improved patch train handling set out in the CL becomes critical. I assume all reviewers are on board with the idea of not rebasing unless something is broken, and handling formatting or other non-functional changes at the end of a series? 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/ iQEcBAEBAgAGBQJWOjtbAAoJEK+E3vEXDOFbTCoH/1d2B+2xZSpo+IdV+FWQaUrE XmkJzUDBZMGX0EcnIj5+sEArMHsRZdNeG86ovmx+mFhj5LLJ8i84QG6Ayhduwxm5 Anv8ccDCvyB8QpJ1Ju6NOv2esfLYhi8d4EBdhv4fj6w4eJzZPoLI3p6FIDYSwaFp jJy1K190oQYnQ1ff2gFdBK6zFm1V30cxyz9ogVJgUQJPvFe1KHa1QbwzDPYhguoH cMcdyYaWJLihy0T3W+jQSbw06K39D2MnA7D/InCgseQRkHdfVqcuLggie98DuEXg LrzjnwRp0d+cwBoRDCEfvfwF5UX6JjAOu0Q8rMGRShAk8rqXnXeWsNv4wO/cwyE= =Bbai -----END PGP SIGNATURE-----

1 0

Re: [coreboot] A case for branching AGESA
by Timothy Pearson 04 Nov '15

04 Nov '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/03/2015 03:41 AM, Vladimir wrote: > I strongly disagree with this branching "solution". Why? > Because - if building all the targets is slow - then just don't build > all the targets at once! If you need a fast build and you are not > concerned about AMD boards - just because you don't have any - it is > always possible to skip AGESA build without moving it to a branch and > separating from the rest of the coreboot code . So this is seen as a > really bad excuse > > Best regards, > Vladimir Shipovalov I do agree technically with this, however there's no policy in place for what happens when an AGESA build finally does fire and it's found the related source broke some time ago. I think that's the main reason for wanting to stuff AGESA in a branch; separation of maintainaince. One one hand, having recently been the victim of having some of my native init patches fail Jenkins builds due to AGESA breakage, I'd almost like to see this happen. On the other hand, I know exactly how painful sync across branches can be, so I can't recommend it. - -- 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/ iQEcBAEBAgAGBQJWORHbAAoJEK+E3vEXDOFbfbgH/i5wk3vQrqtlAuCY0Jhdx2ML ez0ugczbnHaRiQZAuf62oQn1A2oPWg25LFssokztv9MyaJ1p1JbYkt1sLLJL5Eoi hHwm3Lr61oM4NWkHYIy8s1TiK2nIAWnw2gepulNePe9vlul0CiMFlqMon8FMoYCC 6cONRC/09ElLElPRazp5JkoOJnqWTxWotKJqYUJwoxQ7ed2f0L6WB45KWFZSpz3W PsO/WEX5TmsxiXLoV8q2W9NYizfNoDV/TIs89aKskcylxSCdj3DYWKYMudLAvglK wpsfJWuy7WRw01Lp+Av6aPeF0rzU+pP/z9JhzewZWTBryjl9KJ2mQEI1MbjJwtE= =3wXn -----END PGP SIGNATURE-----

2 1

← Newer
1
2
3
4
5
6
7
8
9
10
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 2015