coreboot October 2015

coreboot@coreboot.org

44 participants
137 discussions

Re: [coreboot] Proposal: Removing obsolete & EOL boards and chipsets for 4.2 release
by Vladimir 27 Oct '15

27 Oct '15

It would be really wrong to remove the whole AGESA code: there are AMD-based products which are still very alive and actively sold (at the developing markets) Moving the support for these products to a separate coreboot branch, could create many inconveniences for those AMD product owners who would like to test & use the latest and greatest coreboot build: they will have to backport all the commits of code that's used by all the boards, to that separate abandoned branch - which would cause a lot of hassle and would basically cut them off from the development I agree that removing could be done to some 2009 VIA-based EOL boards that nobody cares about, but it would be a mistake to do that to all the AMD products, some of which are still produced to this date and used together with coreboot by lots of people from this mailing list Also, that action will send a bad signal to AMD. AMD is actively supporting the coreboot project and is much more friendly to open source community than Intel with it's ME and creepy lock-it-all desires. Removing AGESA code would be an equivalent of telling "we don't need your code" to AMD, one of the largest coreboot supporters, and that could lead to a terrible consequences On 27 October 2015 at 22:40, Aaron Durbin <adurbin(a)google.com> wrote: > On Tue, Oct 27, 2015 at 2:35 PM, David Hendricks <dhendrix(a)google.com> > wrote: > > This all sounds fine from a developer's perspective, but what about AMD's > > customers? I honestly have no clue if the decision to use an AMD product > > with coreboot hinges on whether AMD's supplied AGESA code is used or not. > > But I can imagine ripping out the AMD-supplied code might make it > difficult > > for AMD to support customers who use coreboot. > > > > I'm sure there are people on this list who _have actually supported > > customers_ using AMD products and coreboot, so I'd like to hear their > > perspective. > > > > /my $0.02. > > The code lives on a branch. People are more than happy to work within > that branch. That's exactly what branches are for. > > I'll one up the recommendation and suggest all non-romcc code that > #includes C files gets removed after the branch point. Or do such a > thing in the next release. I'm sick of having to deal with and > fighting against these development constructs. > > > > > On Tue, Oct 27, 2015 at 12:20 PM, ron minnich <rminnich(a)gmail.com> > wrote: > >> > >> The AGESA code was always an awkward fit into coreboot. It was more > like a > >> badly designed artificial limb than a real part of the code base. I > >> understand the idea of encouraging vendors to commit source but, at this > >> point, the AMD ship has sailed off to Port Binary Blob. AGESA was > helpful in > >> its time but I think I'm with tpearson on this point. > >> > >> I believe we should drop AGESA on any boards that have native support, > and > >> the sooner the better. > >> > >> ron > >> > >> -- > >> coreboot mailing list: coreboot(a)coreboot.org > >> http://www.coreboot.org/mailman/listinfo/coreboot > > > > > > > > > > -- > > David Hendricks (dhendrix) > > Systems Software Engineer, Google Inc. > > > > -- > > coreboot mailing list: coreboot(a)coreboot.org > > http://www.coreboot.org/mailman/listinfo/coreboot > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] Proposal: Removing obsolete & EOL boards and chipsets for 4.2 release
by Aaron Durbin 27 Oct '15

27 Oct '15

On Tue, Oct 27, 2015 at 2:35 PM, David Hendricks <dhendrix(a)google.com> wrote: > This all sounds fine from a developer's perspective, but what about AMD's > customers? I honestly have no clue if the decision to use an AMD product > with coreboot hinges on whether AMD's supplied AGESA code is used or not. > But I can imagine ripping out the AMD-supplied code might make it difficult > for AMD to support customers who use coreboot. > > I'm sure there are people on this list who _have actually supported > customers_ using AMD products and coreboot, so I'd like to hear their > perspective. > > /my $0.02. The code lives on a branch. People are more than happy to work within that branch. That's exactly what branches are for. I'll one up the recommendation and suggest all non-romcc code that #includes C files gets removed after the branch point. Or do such a thing in the next release. I'm sick of having to deal with and fighting against these development constructs. > > On Tue, Oct 27, 2015 at 12:20 PM, ron minnich <rminnich(a)gmail.com> wrote: >> >> The AGESA code was always an awkward fit into coreboot. It was more like a >> badly designed artificial limb than a real part of the code base. I >> understand the idea of encouraging vendors to commit source but, at this >> point, the AMD ship has sailed off to Port Binary Blob. AGESA was helpful in >> its time but I think I'm with tpearson on this point. >> >> I believe we should drop AGESA on any boards that have native support, and >> the sooner the better. >> >> ron >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> http://www.coreboot.org/mailman/listinfo/coreboot > > > > > -- > David Hendricks (dhendrix) > Systems Software Engineer, Google Inc. > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] Proposal: Removing obsolete & EOL boards and chipsets for 4.2 release
by David Hendricks 27 Oct '15

27 Oct '15

This all sounds fine from a developer's perspective, but what about AMD's customers? I honestly have no clue if the decision to use an AMD product with coreboot hinges on whether AMD's supplied AGESA code is used or not. But I can imagine ripping out the AMD-supplied code might make it difficult for AMD to support customers who use coreboot. I'm sure there are people on this list who _have actually supported customers_ using AMD products and coreboot, so I'd like to hear their perspective. /my $0.02. On Tue, Oct 27, 2015 at 12:20 PM, ron minnich <rminnich(a)gmail.com> wrote: > The AGESA code was always an awkward fit into coreboot. It was more like a > badly designed artificial limb than a real part of the code base. I > understand the idea of encouraging vendors to commit source but, at this > point, the AMD ship has sailed off to Port Binary Blob. AGESA was helpful > in its time but I think I'm with tpearson on this point. > > I believe we should drop AGESA on any boards that have native support, and > the sooner the better. > > ron > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc.

1 0

Re: [coreboot] Proposal: Removing obsolete & EOL boards and chipsets for 4.2 release
by Timothy Pearson 27 Oct '15

27 Oct '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/27/2015 11:14 AM, Martin Roth wrote: > The current thought is to create a new branch for 4.2, *THEN* remove > the decided upon code from the master branch. > > This removes the maintenance work on master going forward while > providing a known point if someone wants to pick up the boards going > forward. > > I don't understand the question about creating a branch for other > boards as well. The branch would contain all current boards. > > The question is really about what boards/code are inactive. The code > that's being updated right now for the ASUS/KGPE-D16 board looked > inactive for a significant time. > > > Personally, I think it's a bad plan to remove the AGESA code. > Throwing away the code that AMD has given us is telling them that they > were right, and they shouldn't bother opening the source. This is a > total contradiction of what we ACTUALLY want, which is the source code > for the binary PI releases. > > If it's still decided to remove the AGESA family 10/15 codebases, my > thought would be to wait for at least the 4.3 release. That's going > to be 3 months from now, giving us some time to finish getting in the > code that's supposed to replace it and giving it time to stabilize. > > Martin If I may add to this discussion, much of the rationale for dropping AGESA has to do with the largely incompatible design (and coding style) of AGESA versus the rest of coreboot. By encouraging the use of AGESA over native intialization, not only does the native initialization code receive less attention, but development of new features (such as timestamping and early CBMEM) is also hampered. - From what I understand, what coreboot actually wants is access the source code, but not necessarily to just use the source code as-is. Would it make more sense to keep the vendorcode available, but put a large warning on it that boards using said vendorcode are not supported (and remove them from Jenkins builds, etc.)? Maybe even moving those boards to a different subdirectory (vendor_shim_mainboards) would help reinforce this idea. - -- 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/ iQEcBAEBAgAGBQJWL8fwAAoJEK+E3vEXDOFbaq8IAJM1L/hOMN5u1uitpqtNQVWW s6iAWYmmemH/1vIzMCk1GBp6RRLpd1Na7fNFIIoCY8hBV2VQY+oLge7AQ2BMqhGQ exzCKgDLaR9b1icktnho2kDXVShUkv+WMCQPetKXV4VPHZ4sudqjRS1GWqqVtXx2 fKPnopESqreOdBP+dg1fCygN1MeKtZM1Sort2+j0Uxfvog1VNHzZ18AMrZXNQNMr armK/JwwxAq7Ku5MbxkH0+zV6G+VxrVYfkOV7bEtgcHtnpRRPA32dLGLIwcoM7Ea xcqrsehZSN+5K8+dskRFGVVWekpb0i7cX+UBg1GiIC7nJXpfIAreRckmtcVkXOY= =MdqC -----END PGP SIGNATURE-----

2 1

Re: [coreboot] VGA cleanup advice
by Timothy Pearson 27 Oct '15

27 Oct '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/27/2015 12:59 PM, ron minnich wrote: > > > On Tue, Oct 27, 2015 at 10:52 AM Nicky Sielicki <sielicki(a)nicky.io > <mailto:sielicki@nicky.io>> wrote: > > Hello list, > > I'm interested in cleaning up some of the VGA programming in coreboot. > > > Good :-) > > > > I was trying to figure out why GM45 "native" textmode isn't working. I > noticed the following bit of code > > > northbridge/intel/gm45/gma.c:144 > > > > const u8 cr[] = { 0x5f, 0x4f, 0x50, 0x82, 0x55, 0x81, 0xbf, > 0x1f, > > 0x00, 0x4f, 0x0d, 0x0e, 0x00, 0x00, 0x00, 0x00, > > 0x9c, 0x8e, 0x8f, 0x28, 0x1f, 0x96, 0xb9, 0xa3, > > 0xff > > }; > > vga_cr_write(0x11, 0); > > for (i = 0; i <= 0x18; i++) > > vga_cr_write(i, cr[i]); > > > > <...> > > vga_textmode_init(); > > > Next question: why isn't that 0x18 a sizeof(cr)? You might fix that too :-) > > > > That for-loop generates the following statement: > > > 'vga_cr_write(0x11, 0x8e)' > > Looking at some VGA documentation, and noticing that 0x8e has a MSB of > 1, I realized that this statement just locked CRTC registers 00h-07h! > (http://www.osdever.net/FreeVGA/vga/crtcreg.htm#11) > > > Here is something I don't know. Once locked, can they be unlocked, or is > it a one way trip? They can be unlocked again by simply clearing the lock bit. The CRTC registers are mainly locked to prevent badly behaved (old DOS mode) programs from accidentally altering the video timing configuration. I'm also glad to hear you are working on the GM45 text mode; this is something I've been wanting to see for many months. 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/ iQEcBAEBAgAGBQJWL8n7AAoJEK+E3vEXDOFbhEUH/RblquUKIqly3cWjvc8jxUEZ sOhovvUgkKxzw1yOXx+m0NpHW8hYaeq/+hSDD/q3FhUeVEP/SvkUvISOU3D/wCsj Jm6Hhm5qqlotF56pOZhiBzyswJI7O7KNeWGkzQoVWAjC1Ym97C/rK3N2P/OSmGXL 3mkdpKNVgGrs3ovg4Z9Fo0fStO2PbGldnUA7P/b9XJUGUiRz2Ix1BUKy0CqsaL5A tjBQYqicr4/2pW+M9o9lwIaanVvbUkVhcY6s1upbnZYHSThn1DGimPBC4ioP17Qz U8oWP6Zirwf2lMOcn6+vN4xIZJKlpzEA0LzeZuIrm/+SyG5FldS3y50Liah4BHQ= =SppD -----END PGP SIGNATURE-----

1 0

VGA cleanup advice
by Nicky Sielicki 27 Oct '15

27 Oct '15

Hello list, I'm interested in cleaning up some of the VGA programming in coreboot. I was trying to figure out why GM45 "native" textmode isn't working. I noticed the following bit of code > northbridge/intel/gm45/gma.c:144 > > const u8 cr[] = { 0x5f, 0x4f, 0x50, 0x82, 0x55, 0x81, 0xbf, 0x1f, > 0x00, 0x4f, 0x0d, 0x0e, 0x00, 0x00, 0x00, 0x00, > 0x9c, 0x8e, 0x8f, 0x28, 0x1f, 0x96, 0xb9, 0xa3, > 0xff > }; > vga_cr_write(0x11, 0); > for (i = 0; i <= 0x18; i++) > vga_cr_write(i, cr[i]); > > <...> > vga_textmode_init(); That for-loop generates the following statement: > 'vga_cr_write(0x11, 0x8e)' Looking at some VGA documentation, and noticing that 0x8e has a MSB of 1, I realized that this statement just locked CRTC registers 00h-07h! (http://www.osdever.net/FreeVGA/vga/crtcreg.htm#11) That's no good, because the subsequent call to vga_textmode_init() tries to write to some of those CRTC registers, and it's not checking if they're locked. It assumes that no one else is working with VGA registers. It's worth noting that GM45 isn't the only platform where this CRTC locking is occuring. A couple others follow this same practice of loading the CR registers into an array, writing them, and then calling vga_textmode_init(). That's probably not what we want, and I'm looking for advice on cleaning this up. I think what we want to do is avoid having the VGA registers touched from outside drivers/pc80/vga/. That means that we need to add or extend functions to it in order to disincentivize writing them directly-- but is it possible to accomodate every use case? What functions aren't being provided currently, and why is it necessary/easiest to write them directly? On the other hand, an easier fix is to just have vga_textmode_init() check that the registers it writes to are unlocked. Thanks, Nicky Sielicki

2 1

Re: [coreboot] Proposal: Removing obsolete & EOL boards and chipsets for 4.2 release
by Alex G. 27 Oct '15

27 Oct '15

On 10/26/2015 02:51 PM, Martin Roth wrote: > I'd like to start a discussion about boards, chipsets, drivers, or > other code that can be removed from the tree. > > What other directories should be removed from the tree after the next release? > All of AGESA fam10 and fam15. With Raptop Engineering upstreaming native support, I don't think we want to haul around the AGESA implementations, which have been troublesome in the past. Actually, branch off those boards, keep them alive in their little branch, but remove them from master. Gerrit is knows how to handle branches, so we already have the infrastructure in place to support this. Alex

4 3

Linux kernel hangs
by Iru Cai 27 Oct '15

27 Oct '15

Hi, I'm testing the Lenovo T420 port[1]. After I saw some commits on Sandy/Ivy RAM init and native graphics init code, I asked Nicolas Reinecke to rebase and update the code. After I flashed the new firmware, coreboot runs fine and boot to GRUB payload. However, Linux kernel hanged and could not boot. I think there must be something wrong with some of the upstream commits. [1] http://review.coreboot.org/#/c/11765/ Iru Cai

1 0

Proposal: Removing obsolete & EOL boards and chipsets for 4.2 release
by Martin Roth 26 Oct '15

26 Oct '15

I'd like to start a discussion about boards, chipsets, drivers, or other code that can be removed from the tree. At the coreboot conference in Bonn, we discussed this some. I believe that we decided to wait until the next release/branch of the coreboot tree before removing anything. By planning ahead and deleting the components immediately after the release, we can list the things that have been end-of-lifed in the branch release notes. By discussing this on the mailing list instead of just pushing commits to the tree, we can get better buy in from all interested parties. I'd request that these be boards & chips that are no longer being produced, and haven't been updated in a few years. These seem like good candidates to start the discussion: mainboard/via/epia-m700 - http://review.coreboot.org/#/c/7470 northbridge/via/vx800 - http://review.coreboot.org/#/c/7471 As far as I can tell, the last real contributions to these came in 2009 - all the changes since then have been cleanup and modifications for other changes across the coreboot tree. What other directories should be removed from the tree after the next release? Eventually it would be nice to be able to use submissions to board-status repo to determine what's being used. We're just not at that point yet.

1 0

Berlin Usergroup Meeting October 28.10.2015 20:30 cccb
by Alexander Couzens 25 Oct '15

25 Oct '15

tldr; 28.10.2015 20:30 cccb Hi, The Berlin Usergroup Meeting in October will taken place on 28.10.2015 in the rooms of the chaos computer club berlin (cccb). Chaos Computer Club Berlin e.V. Marienstraße 11 10117 Berlin https://berlin.ccc.de/wiki/Club_Discordia best, lynxis PS. It looks like the date for the november is the 18.11.2015 20:30. -- 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

1 0

← Newer
1
2
3
4
5
6
7
8
...
14
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot October 2015