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
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
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.
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
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
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
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
-----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-----
-----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-----
