Dear coreboot folks,
I pushed change set I379e4b1e1b1725648c6231bc6954ac3cc655a596
(mainboard: Remove empty mainboard.c files) [1] for review.
```
mainboard: Remove empty mainboard.c files
All the deleted mainboard files contain no code besides some print
statements denoting, that the init is executed.
If such statements are desired, this should be done in common code so it
does not have to be added to each mainboard.
Therefore, also delete files with just print statements.
```
Please voice any objections.
Thanks,
Paul
[1] http://review.coreboot.org/#/c/12355/
* Martin Roth <gaumless(a)gmail.com> [151026 22:51]:
> 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.
Since 2009 is really only 6ys ago, I'm a bit hesitant about the VX800
stuff (while leaving the older CN700 / CX700 in the tree)
It also seems VIA gave up on coreboot at this point, so it might not
matter, unless we want to work on bringing them back?
Is anybody in contact with VIA at this point?
> What other directories should be removed from the tree after the next release?
I want to add the following boards (and their chipsets and super ios)
that have been in the tree and basically unmaintained for 10+ys:
* arima/hdama
* digitallogic/adl855pc
* ibm/e325
* ibm/e326
* iwill/dk8s2
* iwill/dk8x
* newisys/khepri
* tyan/s2735
* tyan/s2850
* tyan/s2875
* tyan/s2880
* tyan/s2881
* tyan/s2882
* tyan/s2885
* tyan/s2891
* tyan/s2892
* tyan/s2895
* tyan/s4880
* tyan/s4882
> 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.
I think this is a hard problem. Churn on a board's or chipset's code
does not necessarily coincide with a board being used or the other way
around. A target might just be stable and working well.
We need to get to the point where 100% of the boards in the tree are
boot tested 100% of the time.
Stefan
The coreboot leadership is making a number of changes to be more open
than they have been in the past. Releasing the minutes of the
discussions that are being held regularly is another step towards this
goal. The first couple sets of minutes are delayed a bit while
figuring out the process, but going forward, the plan is to release
the minutes by the Monday following the meeting.
Please feel free to make comments and ask questions.
Attendance:
-----------
Ron, Stefan, Patrick, Martin, Marc, Furquan
Discussion:
-------
* Blobs policy document:
- Paul was the main commenter so far
- Q: What's the point of contact? A: Use the mailing list
- Marcj to post pointer to the doc in gerrit to the mailing list
* Document: Gerrit policies and expectations
- Document was reviewed.
- Martin will post it on gerrit and to the mailing list for wider review.
* Document: Things the coreboot community can improve
- What are our priorities?
- Martin would love to see more documentation (and form a doc team)
- Discussed promoting John Lewis, libreboot, and autoboot on the
coreboot.org landing page.
- This list of things the community can improve can be seen on page 8
of Marcj's community involvement presentation from Bonn:
https://goo.gl/XYLHja
* Discuss next coreboot meetings (Paris, Americas, Bonn 2016)
- Paris in April 2016, US meeting in October 2016, Bonn in April 2017?
- requires more lead time for travel scheduling at orgs
- e.g. Some USG orgs need to know foreign travel on Dec. 31 of previous year
- Need some kind of conference org team
- Need a strategy to reuse planning docs for future events
- Martin will make a shared GDrive folder.
* Deleting mainboards / code
- ibm e325/e326 should go. (says the guy who put them there originally)
- newisys khepri should go.
- Stefan contacted Via to see if they want to keep some old stuff alive.
* Branch strategy - Do we need a plan for branching off a portion of
the existing code and mainboards to reduce maintenance and make it
easier to go forward? 5.0 branch?
- short-term proposal: boards that aren’t in board-status are deleted
after release 4.4. This gives 6 months to get boards into
board-status.
- long-term proposal: in 3 years (eg. 2019-01-01), boards need to be
testable for every commit (eg. REACTS). Ideally, vendors should be
able to run board-testing on their own.
* coreboot 4.2 release
- Finish it this week
- Need to do some testing across hardware
* Tool for dealing with subsystem maintainers
- Stefan will send out more information on what needs to be done
* Releasing meeting notes
- Martin to format and release meeting notes.
update : this pool will be closed next Sunday october 15 at 23 PM
----- Mail d'origine -----
De: echelon(a)free.fr
À: coreboot <coreboot(a)coreboot.org>
Envoyé: Sun, 08 Nov 2015 15:57:34 +0100 (CET)
Objet: Re: [coreboot] Coreboot hackaton 2016 (proposal in Paris)
Hello,
I would like to remind everybody that there is a doodle about the organisation of the next coreboot meeting (hackaton) ->
http://doodle.com/poll/6udccyrsqtqy2ndt
I kindly ask you to answer this pool, because it will help me to determine the optimal time frame for this event. Even if you aren't sure 100%, answer please, this is only an indicative pool for me..
It is very import to know how many people are (even remotely..) interested, especially if the event has to be organized at an early date (say just after the FOSDEM 2016..).
By the way, I would like to make a suggestion : if the pool results finally converge to some kind of "bipolar distribution" ( ;-) ), i.o.w. there is a group of people who favor a spring meeting and another group who favor a fall meeting, maybe we should "split" the coreboot hackaton and make 2 "sub-hackatons".. ;-) But in this case, someone else should pick up the task to organise the other meeting, because I cannot manage alone two coreboot meetings in one year..
What do you think?
Florentin
----- Mail d'origine -----
De: ron minnich <rminnich(a)gmail.com>
À: Stefan Reinauer <stefan.reinauer(a)coreboot.org>, David Hendricks <dhendrix(a)google.com>
Cc: coreboot <coreboot(a)coreboot.org>, echelon(a)free.fr
Envoyé: Tue, 03 Nov 2015 01:43:25 +0100 (CET)
Objet: Re: [coreboot] Coreboot hackaton 2016 (proposal in Paris)
So, I think in the next day, we should pick the location and date for the
"spring" meeting. I'd also suggest it be a 6 month interval between
meetings, which is the other reason I thought end of january was a bit too
soon.
Sound OK?
What Stefan says is very true. I have friends here in the US who must have
2016 travel approved by dec. 31 2015.
ron
On Mon, Nov 2, 2015 at 4:32 PM Stefan Reinauer <stefan.reinauer(a)coreboot.org>
wrote:
> * David Hendricks <dhendrix(a)google.com> [151102 21:00]:
> > Piggybacking on other conferences can certainly help overseas
> travellers. Are
> > there other major conferences later in the year?
> >
> > Hosting after FOSDEM 2016 actually seems ideal and it will be in
> Brussels (<2
> > hours away by train, or <1 hour by flight). It is a bit soon after the
> Bonn
> > conference, though but maybe that won't matter? This isn't intended to
> be a big
> > formal event anyway. If you get enough community members in the Doodle
> poll I
> > think you should go for it :-)
>
> I also want to double stress the importance of getting an official
> invitation out early is crucial. People from overseas might need to go
> through a visa application process to attend, which might take several
> months (and is not seldomly tied to an official invitation)
>
> Stefan
>
>
>
> --
> 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
Oh, another thing : I just realized that I haven't selected the three choice configuration for this pool (yes, maybe yes, not), so I will interpret all the positive results as a "weak" yes (yes if needed..)
----- Mail d'origine -----
De: echelon(a)free.fr
À: coreboot <coreboot(a)coreboot.org>
Envoyé: Sun, 08 Nov 2015 15:57:34 +0100 (CET)
Objet: Re: [coreboot] Coreboot hackaton 2016 (proposal in Paris)
Hello,
I would like to remind everybody that there is a doodle about the organisation of the next coreboot meeting (hackaton) ->
http://doodle.com/poll/6udccyrsqtqy2ndt
I kindly ask you to answer this pool, because it will help me to determine the optimal time frame for this event. Even if you aren't sure 100%, answer please, this is only an indicative pool for me..
It is very import to know how many people are (even remotely..) interested, especially if the event has to be organized at an early date (say just after the FOSDEM 2016..).
By the way, I would like to make a suggestion : if the pool results finally converge to some kind of "bipolar distribution" ( ;-) ), i.o.w. there is a group of people who favor a spring meeting and another group who favor a fall meeting, maybe we should "split" the coreboot hackaton and make 2 "sub-hackatons".. ;-) But in this case, someone else should pick up the task to organise the other meeting, because I cannot manage alone two coreboot meetings in one year..
What do you think?
Florentin
----- Mail d'origine -----
De: ron minnich <rminnich(a)gmail.com>
À: Stefan Reinauer <stefan.reinauer(a)coreboot.org>, David Hendricks <dhendrix(a)google.com>
Cc: coreboot <coreboot(a)coreboot.org>, echelon(a)free.fr
Envoyé: Tue, 03 Nov 2015 01:43:25 +0100 (CET)
Objet: Re: [coreboot] Coreboot hackaton 2016 (proposal in Paris)
So, I think in the next day, we should pick the location and date for the
"spring" meeting. I'd also suggest it be a 6 month interval between
meetings, which is the other reason I thought end of january was a bit too
soon.
Sound OK?
What Stefan says is very true. I have friends here in the US who must have
2016 travel approved by dec. 31 2015.
ron
On Mon, Nov 2, 2015 at 4:32 PM Stefan Reinauer <stefan.reinauer(a)coreboot.org>
wrote:
> * David Hendricks <dhendrix(a)google.com> [151102 21:00]:
> > Piggybacking on other conferences can certainly help overseas
> travellers. Are
> > there other major conferences later in the year?
> >
> > Hosting after FOSDEM 2016 actually seems ideal and it will be in
> Brussels (<2
> > hours away by train, or <1 hour by flight). It is a bit soon after the
> Bonn
> > conference, though but maybe that won't matter? This isn't intended to
> be a big
> > formal event anyway. If you get enough community members in the Doodle
> poll I
> > think you should go for it :-)
>
> I also want to double stress the importance of getting an official
> invitation out early is crucial. People from overseas might need to go
> through a visa application process to attend, which might take several
> months (and is not seldomly tied to an official invitation)
>
> Stefan
>
>
>
> --
> 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
Hello,
I would like to remind everybody that there is a doodle about the organisation of the next coreboot meeting (hackaton) ->
http://doodle.com/poll/6udccyrsqtqy2ndt
I kindly ask you to answer this pool, because it will help me to determine the optimal time frame for this event. Even if you aren't sure 100%, answer please, this is only an indicative pool for me..
It is very import to know how many people are (even remotely..) interested, especially if the event has to be organized at an early date (say just after the FOSDEM 2016..).
By the way, I would like to make a suggestion : if the pool results finally converge to some kind of "bipolar distribution" ( ;-) ), i.o.w. there is a group of people who favor a spring meeting and another group who favor a fall meeting, maybe we should "split" the coreboot hackaton and make 2 "sub-hackatons".. ;-) But in this case, someone else should pick up the task to organise the other meeting, because I cannot manage alone two coreboot meetings in one year..
What do you think?
Florentin
----- Mail d'origine -----
De: ron minnich <rminnich(a)gmail.com>
À: Stefan Reinauer <stefan.reinauer(a)coreboot.org>, David Hendricks <dhendrix(a)google.com>
Cc: coreboot <coreboot(a)coreboot.org>, echelon(a)free.fr
Envoyé: Tue, 03 Nov 2015 01:43:25 +0100 (CET)
Objet: Re: [coreboot] Coreboot hackaton 2016 (proposal in Paris)
So, I think in the next day, we should pick the location and date for the
"spring" meeting. I'd also suggest it be a 6 month interval between
meetings, which is the other reason I thought end of january was a bit too
soon.
Sound OK?
What Stefan says is very true. I have friends here in the US who must have
2016 travel approved by dec. 31 2015.
ron
On Mon, Nov 2, 2015 at 4:32 PM Stefan Reinauer <stefan.reinauer(a)coreboot.org>
wrote:
> * David Hendricks <dhendrix(a)google.com> [151102 21:00]:
> > Piggybacking on other conferences can certainly help overseas
> travellers. Are
> > there other major conferences later in the year?
> >
> > Hosting after FOSDEM 2016 actually seems ideal and it will be in
> Brussels (<2
> > hours away by train, or <1 hour by flight). It is a bit soon after the
> Bonn
> > conference, though but maybe that won't matter? This isn't intended to
> be a big
> > formal event anyway. If you get enough community members in the Doodle
> poll I
> > think you should go for it :-)
>
> I also want to double stress the importance of getting an official
> invitation out early is crucial. People from overseas might need to go
> through a visa application process to attend, which might take several
> months (and is not seldomly tied to an official invitation)
>
> Stefan
>
>
>
> --
> coreboot mailing list: coreboot(a)coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>
Hi Florentin!
> -3) The USB3 does NOT work : the 3rdparty xhci blob (${COREBOOT}/3rdparty/blobs/southbridge/amd/hudson/xhci.bin) is not correct!..
> PLEASE HELP : can someone give me a tip or advice, how to extract this blob (from uefi image or/sys/<whatever..>)?
You have to use the Bolton USB3 blob if you want to get USB3 somewhere
near working; it's in the blobs repo. The laptop uses a Bolton and not a
Hudson FCH, which have a newer version of the XHCI controller component
(I've verified that they have different boot-ROMs; my
fch_xhci_rom_dumper can extract both ).
I wrote some patch selecting the right blob (still somewhere in gerrit),
but you need to patch the vendorcode to get USB3 working (at least at
some place in the code it matches onto the PCI ID of the XHCI
controller, which is different). I stopped my efforts to add support for
Bolton to source AGESA, since doing stuff right would at least imply
refactoring and unifying the FCH code if not rewriting it and I'm not
really motivated to do that in my spare time.
Regards
Felix
Hello all,
I would like to present here a brief report of my first tests with coreboot on the G505s laptop.
First of all I would like to thank Zaolin for his enormous help (which went even to hw hacking.. ;-)) and Paul Kocialkowski for his advices.
In a nutshell : it MOSTLY works with a recent release of coreboot => linux (ubuntu 14.04) correctly boots in graphical mode and with networking support.
Test setup :
- Coreboot release : commit 439a527014fa0cb3e4ef60ba59e5c57c737b4444 (head of 4.2 branch ?)
- Install method : external programmer (flashrom on beagleboard);
- OS : Ubuntu Trusty Tahr 14.04LTS
Problems:
-1) On the HW side : like with (almost) every laptop it is better to have an interface for external flashing. But it is difficult to access the winbond flash on the MB to solder wires for the flashing connecter : practically the laptop has to be (almost) completely disassembled and the MB extracted;
-2) The video bios binary blob has to be extracted from the original bios and added to the coreboot image. The method based on the unpacking of the original uefi bios doesn't work (and also the id of the video device doesn't match!!..) so the VBIOS image has to be dumped from /sys/devices/<path_to_vga_device>/rom;
-3) The USB3 does NOT work : the 3rdparty xhci blob (${COREBOOT}/3rdparty/blobs/southbridge/amd/hudson/xhci.bin) is not correct!..
PLEASE HELP : can someone give me a tip or advice, how to extract this blob (from uefi image or /sys/<whatever..>)?
-4) The "internal" flashing method does NOT work : even after booting with coreboot and "requesting a brick", flashrom says something like "read/write methods not implemented" even after detencting the flash chip. (I was using the "flashrom" of the ubuntu distrib..)
I will fix the wiki page for this laptop after doing some additional tests.
Best regards,
Florentin
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 06/11/15 10:11, Vladimir wrote:
> * Did you know that Lenovo G505S is still widely available at some
> parts of the world? (e.g. in Russia, 50+ online shops are still
> selling it) * Did you know that Francis Rowe, head Libreboot
> developer, has proposed the addition of G505S to Coreboot LTS
> Candidates list of laptops?
Hey, please don't make it look like I endorse this hardware. I don't.
There are several blobs (SMU firmware, Video BIOS, XHCI firmware and
others) that make this laptop a non-option for libreboot at present. I
only mentioned it as a future candidate, to be added once these issues
are resolved.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJWPrf3AAoJEP9Ft0z50c+Um3QH/1PT7yQCof6Lnsfi0kdP+tH0
xDUADsLk/R5AkZdAxPeSaNJZbkEfoep9AHThyay6H5wGTScTJqaqrj6rK5TLqrxo
hDf/onjhklSKisvlTTKTOROOWcWaYmQgrLb2MZd16XzuOa+WfdnE2Ypt3CP8cn4e
CeWgpCYhwEyaErtApd73+l5yjZpw+m/pbh/Y3frhrkFqg+1jJxq6/BMKUr4t6to9
a8vlKWYutonlOYMiY2xmLrclsotoXALw9rrJy8/ka7PEqTgRvGyVT4q9vF/8kSME
f42yBRlFZkpaRIaFctpcDHgLCvX+7MxwBtBLLMlZXlGyyBBy7n+hnc2iiSe2gTw=
=xbvM
-----END PGP SIGNATURE-----