This is a new project, forked from coreboot, which deblobs coreboot but by hardforking the coreboot git repository (unlike libreboot, which maintains deblob scripts instead and rebases constantly on coreboot master)
I decided against this model when founding the libreboot project, but they seem to be doing a good job. I think we should consider using librecore as an upstream project, instead of coreboot.
Paul, what do you think?
https://librecore.info/
This is a new project, forked from coreboot, which deblobs coreboot but by hardforking the coreboot git repository (unlike libreboot, which maintains deblob scripts instead and rebases constantly on coreboot master)
I decided against this model when founding the libreboot project, but they seem to be doing a good job. I think we should consider using librecore as an upstream project, instead of coreboot.
Paul, what do you think?
The coreboot revision that librecore forks from is 94f8699d447ef94df339d318b836b664273e89ff
and their git repo is https://github.com/librecore-org/librecore.git
2017-01-07 23:20:12 @swiftgeek i guess i should test forceful undocking
2017-01-07 23:21:12 @swiftgeek nope, it breaks my USB, but doesn't break DP
2017-01-07 23:26:05 --> nom_de_plume (~yoda@anon-40-248.vpn.ipredator.se) has joined #libreboot
2017-01-07 23:26:23 <-- nom_de_plume (~yoda@anon-40-248.vpn.ipredator.se) has quit (Client Quit)
2017-01-07 23:27:53 <-- zyliwax (~zyliwax@unaffiliated/zyliwax) has quit (Quit: leaving)
2017-01-07 23:32:16 <-- Ferix (~Ferix@77.172.180.189) has quit (Quit: Goodbye)
2017-01-07 23:32:44 @_4of7 swiftgeek: adopting librecore as upstream means basically outsourcing maintenance of feature patches / rebases on top of coreboot upstream
2017-01-07 23:33:12 @_4of7 it's also a big f*ck you to damo22 and avph, who is the leader of the project
2017-01-07 23:33:26 @_4of7 it means that they'd still essentially be working for us, despite having left the libreboot project
2017-01-07 23:35:41 @_4of7 * maintains features in its tree, that coreboot does not have. this includes board fixes - this includes all board fixes currently in libreboot, most of which are not merged upstream in coreboot
2017-01-07 23:35:55 @_4of7 * is less beauacratic than coreboot about merging patches
2017-01-07 23:36:16 @_4of7 I considered librecore's module, when founding the libreboot project 3 years ago.
2017-01-07 23:36:40 @_4of7 It was considered unnecessary back then, because libreboot only supported 1 board, and at the time, coreboot contained a lot of blobs, so it made a ton of sense
2017-01-07 23:36:56 @swiftgeek well we will see what librecore is going to be
2017-01-07 23:36:58 @_4of7 nowadays, coreboot does a better job separating blobs to 3rdparty, so the work to maintain a deblobbed coreboot is very little
2017-01-07 23:37:08 @swiftgeek if it's going to be just yet another libreboot, it would be quite boring
2017-01-07 23:37:10 @_4of7 I mean damo22 and avph are basically doing our work for us
2017-01-07 23:37:15 @_4of7 to an even greater extent than before
2017-01-07 23:37:16 @swiftgeek and wasteful on human resources
2017-01-07 23:37:26 @_4of7 even though they've left the libreboot project
2017-01-07 23:37:32 @_4of7 We can assimilate librecore
2017-01-07 23:37:58 @_4of7 If they don't like us using it (since it means their work benefits us, when they intended to leave us), then their only choice is to stop developing librecore
2017-01-07 23:38:11 @_4of7 I once said that forks are a wonderful thing.
2017-01-07 23:38:20 @_4of7 In this case, librecore is not a libreboot fork - it's a better coreboot.
2017-01-07 23:38:28 --> arielenter (~ariel@200.92.71.95) has joined #libreboot
2017-01-07 23:38:29 -- Mode #libreboot [+v arielenter] by ChanServ
2017-01-07 23:38:33 @_4of7 It's even more than we would have considered feasible.
2017-01-07 23:39:20 @_4of7 The priority is to ditch coreboot as upstream, and integrate librecore instead, once we merge the new build system
2017-01-07 23:39:28 @_4of7 Paul is currently working on it, with my supervision
2017-01-07 23:43:37 @_4of7 * Uses libreboot's current concept of maintaining deblob scripts on top of upstream coreboot, with patches (but not coreboot) provided in tree
2017-01-07 23:43:44 @_4of7 We can have the best of both worlds:
2017-01-07 23:43:50 @_4of7 * Paper (name of the new build system)
2017-01-07 23:49:37 @_4of7 They are also, from what I've been told, working to integrate petitboot more closely than coreboot
2017-01-07 23:49:54 @_4of7 Which is also a boon to the libreboot project, which seeks to make petitboot an official payload option on all suitable systems
2017-01-07 23:50:20 @swiftgeek well that would remove BSD support
2017-01-07 23:50:35 @_4of7 Of course, but that does not mean we would drop GRUB and/or SeaBIOS
2017-01-07 23:50:49 @_4of7 We would maintain SeaGRUB as always, but with petitboot as an extra option
2017-01-07 23:51:00 @_4of7 BSD users would choose SeaGRUB or SeaBIOS
2017-01-07 23:51:06 <-- Niall_ (~Niall@cpc95050-newt40-2-0-cust147.19-3.cable.virginm.net) has quit (Client Quit)
2017-01-07 23:51:23 <-- CharlieBrown (~calher@72-95-86-186.dsl.dynamic.casstel.net) has quit (Remote host closed the connection)
2017-01-07 23:51:31 @_4of7 We would maintain SeaBIOS alongside petitboot, like we do with GRUB.
2017-01-07 23:51:32 @swiftgeek TianoCore with SeaBIOS as CSM would be nice
2017-01-07 23:52:13 @_4of7 However, as I understand it, Heads is a Linux kernel payload for coreboot
2017-01-07 23:52:23 * swiftgeek ← it's past midnight here
2017-01-07 23:52:28 @_4of7 Heads is not based on coreboot
2017-01-07 23:52:34 +dunx yes, it's more than that though
2017-01-07 23:52:38 @_4of7 (this might be wrong, someone please correct if so)
2017-01-07 23:52:50 +dunx ofc not, it's a payload
2017-01-07 23:53:05 @_4of7 swiftgeek: leaving GNU was indeed an excellent choice, as you said so earlier
2017-01-07 23:53:16 +dunx its main attraction is it verifies the boot process
2017-01-07 23:53:26 @_4of7 it prompted damo22 and avph to create librecore, which greatly benefits the libreboot project, for all of the reasons mentioned above
2017-01-07 23:53:31 +dunx that nothing nasty has happenes
2017-01-07 23:53:51 @_4of7 They are attracting developers too
2017-01-07 23:54:01 @_4of7 This means that libreboot is attracting developers, when they become our upstream
2017-01-07 23:54:14 @_4of7 Their free software philosophy is also very close to ours
2017-01-07 23:54:32 @_4of7 Even if they dislike leah, there would start to be crossover between libreboot/librecore
2017-01-07 23:55:10 @_4of7 And there is no reason why they would not accept patches from us
2017-01-07 23:55:18 @_4of7 (if not, we would fork it)
2017-01-07 23:55:23 <-- arielenter (~ariel@200.92.71.95) has quit (Quit: Leaving.)
2017-01-07 23:55:30 @swiftgeek being outside of GNU attracts developers? :D
2017-01-07 23:55:54 @swiftgeek i guess it will be easier to get GSoC
2017-01-07 23:56:02 @_4of7 in this case, it scared away 2 developers, who then went on to create a project that is very much like our own, except it is coreboot-only
2017-01-07 23:56:11 @_4of7 and thus, their work is directly possible to integrate in libreboot
2017-01-07 23:56:27 @_4of7 The original plan was to continue to monitor their upstream patches in coreboot, but they seem to be doing our work for us at the moment.
2017-01-07 23:57:08 @_4of7 and now that its official, that means the noise will also quieten down
2017-01-07 23:57:15 @_4of7 we attracted developers before, aswell
2017-01-08 00:00:44 @_4of7 I'm creating a log of this discussion, for reference.
2017-01-08 00:01:05 nebul8 a 'monolog'
2017-01-07 23:05:03 @_4of7 swiftgeek: librecore looks really good
2017-01-07 23:05:33 @_4of7 It might become libreboot's upstream, instead of coreboot, after the new build system is merged.
2017-01-07 23:06:03 @swiftgeek https://github.com/LibreCat/LibreCore ? :D
2017-01-07 23:06:04 @swiftgeek xD
2017-01-07 23:06:14 @swiftgeek i sure found something wrong xD
2017-01-07 23:08:20 <-- Anja (~Anja@49.50.252.82) has quit (Ping timeout: 248 seconds)
2017-01-07 23:08:53 @swiftgeek oh this one has something that i tested recently
2017-01-07 23:08:55 @swiftgeek https://github.com/librecore-org/librecore/issues/24
2017-01-07 23:10:08 @swiftgeek my guess will be forceful undocking which is breaking things
2017-01-07 23:10:24 @swiftgeek Undock is on Fn-F9
2017-01-07 23:20:12 @swiftgeek i guess i should test forceful undocking
2017-01-07 23:21:12 @swiftgeek nope, it breaks my USB, but doesn't break DP
2017-01-07 23:26:05 --> nom_de_plume (~yoda@anon-40-248.vpn.ipredator.se) has joined #libreboot
2017-01-07 23:26:23 <-- nom_de_plume (~yoda@anon-40-248.vpn.ipredator.se) has quit (Client Quit)
2017-01-07 23:27:53 <-- zyliwax (~zyliwax@unaffiliated/zyliwax) has quit (Quit: leaving)
2017-01-07 23:32:16 <-- Ferix (~Ferix@77.172.180.189) has quit (Quit: Goodbye)
2017-01-07 23:32:44 @_4of7 swiftgeek: adopting librecore as upstream means basically outsourcing maintenance of feature patches / rebases on top of coreboot upstream
2017-01-07 23:33:12 @_4of7 it's also a big f*ck you to damo22 and avph, who is the leader of the project
2017-01-07 23:33:26 @_4of7 it means that they'd still essentially be working for us, despite having left the libreboot project
2017-01-07 23:33:29 @_4of7 seems win-win to me
2017-01-07 23:33:41 @_4of7 and we can still add patches on top
2017-01-07 23:33:43 specing evil
2017-01-07 23:33:45 @_4of7 what libreboot does is:
2017-01-07 23:33:53 @_4of7 * maintains coreboot deblob scripts
2017-01-07 23:33:57 @_4of7 * maintains patches in tree
2017-01-07 23:34:02 @_4of7 * uses coreboot upstream
2017-01-07 23:34:04 @_4of7 * deblobs
2017-01-07 23:34:06 @_4of7 * applies patches
2017-01-07 23:34:11 @_4of7 it also uses multiple revisions
2017-01-07 23:34:23 specing _4of7: when have you joined the Borg?
2017-01-07 23:34:26 @_4of7 what librecore does (for all libre-compatible systems, including libreboot systems):
2017-01-07 23:34:41 @_4of7 * maintains 1 coreboot fork
2017-01-07 23:34:52 @_4of7 * deblobs that fork in tree, instead of with external blob lists and deblob scripts
2017-01-07 23:35:08 @_4of7 * rebases new patches from upstream, but only ones that are useful, for libre-compatible boards
2017-01-07 23:35:14 @_4of7 * deletes non-libre boards
2017-01-07 23:35:41 @_4of7 * maintains features in its tree, that coreboot does not have. this includes board fixes - this includes all board fixes currently in libreboot, most of which are not merged upstream in coreboot
2017-01-07 23:35:55 @_4of7 * is less beauacratic than coreboot about merging patches
2017-01-07 23:36:00 @_4of7 etc
2017-01-07 23:36:16 @_4of7 I considered librecore's module, when founding the libreboot project 3 years ago.
2017-01-07 23:36:40 @_4of7 It was considered unnecessary back then, because libreboot only supported 1 board, and at the time, coreboot contained a lot of blobs, so it made a ton of sense
2017-01-07 23:36:56 @swiftgeek well we will see what librecore is going to be
2017-01-07 23:36:58 @_4of7 nowadays, coreboot does a better job separating blobs to 3rdparty, so the work to maintain a deblobbed coreboot is very little
2017-01-07 23:37:08 @swiftgeek if it's going to be just yet another libreboot, it would be quite boring
2017-01-07 23:37:10 @_4of7 I mean damo22 and avph are basically doing our work for us
2017-01-07 23:37:15 @_4of7 to an even greater extent than before
2017-01-07 23:37:16 @swiftgeek and wasteful on human resources
2017-01-07 23:37:26 @_4of7 even though they've left the libreboot project
2017-01-07 23:37:32 @_4of7 We can assimilate librecore
2017-01-07 23:37:58 @_4of7 If they don't like us using it (since it means their work benefits us, when they intended to leave us), then their only choice is to stop developing librecore
2017-01-07 23:38:11 @_4of7 I once said that forks are a wonderful thing.
2017-01-07 23:38:20 @_4of7 In this case, librecore is not a libreboot fork - it's a better coreboot.
2017-01-07 23:38:28 --> arielenter (~ariel@200.92.71.95) has joined #libreboot
2017-01-07 23:38:29 -- Mode #libreboot [+v arielenter] by ChanServ
2017-01-07 23:38:33 @_4of7 It's even more than we would have considered feasible.
2017-01-07 23:39:20 @_4of7 The priority is to ditch coreboot as upstream, and integrate librecore instead, once we merge the new build system
2017-01-07 23:39:28 @_4of7 Paul is currently working on it, with my supervision
2017-01-07 23:40:07 @_4of7 It's this repository:
2017-01-07 23:40:08 @_4of7 git://git.code.paulk.fr/libreboot.git
2017-01-07 23:40:12 @_4of7 branch: paper-integration
2017-01-07 23:40:18 @_4of7 This is the new build system that we're working on
2017-01-07 23:40:31 @_4of7 It has many benefits over libreboot's current build system:
2017-01-07 23:40:35 @swiftgeek good thing that i focus on lower lever so i'm out of this discussion ^^
2017-01-07 23:40:37 @_4of7 * cleaner / more maintainable
2017-01-07 23:40:40 @swiftgeek *level
2017-01-07 23:40:59 @swiftgeek (just hardware)
2017-01-07 23:41:01 @_4of7 * support for building linux kernel, using the build system, with a provided config
2017-01-07 23:41:10 @_4of7 * support for building chromebook EC firmware from source
2017-01-07 23:41:27 * specing grabs popcorn
2017-01-07 23:41:30 @_4of7 * more standards compliant with other commonly used build environments
2017-01-07 23:41:36 * jxself grabs specing
2017-01-07 23:41:52 * _4of7 assimilates jxself and specing
2017-01-07 23:42:01 @swiftgeek 4of9
2017-01-07 23:42:41 @swiftgeek ahhhhh wasted
2017-01-07 23:42:44 @_4of7 * has various useful utilities related to development on ARM chromebooks, which libreboot supports
2017-01-07 23:42:45 @swiftgeek 7 of 9... dammit
2017-01-07 23:43:06 @_4of7 * integrates standard upstream flashrom, in addition to google's customised flashrom required for chromebooks
2017-01-07 23:43:10 @_4of7 * many many features
2017-01-07 23:43:14 @_4of7 However:
2017-01-07 23:43:37 @_4of7 * Uses libreboot's current concept of maintaining deblob scripts on top of upstream coreboot, with patches (but not coreboot) provided in tree
2017-01-07 23:43:44 @_4of7 We can have the best of both worlds:
2017-01-07 23:43:50 @_4of7 * Paper (name of the new build system)
2017-01-07 23:44:01 @_4of7 But we will:
2017-01-07 23:44:04 @_4of7 * ditch coreboot
2017-01-07 23:44:10 @_4of7 * delete the deblob scripts
2017-01-07 23:44:17 --> zyliwax (~zyliwax@unaffiliated/zyliwax) has joined #libreboot
2017-01-07 23:44:17 -- Mode #libreboot [+v zyliwax] by ChanServ
2017-01-07 23:44:18 @_4of7 * delete all patches for coreboot
2017-01-07 23:44:35 @_4of7 * switch to librecore as upstream, for boot firmware
2017-01-07 23:44:52 @_4of7 * librecore already deblobs in-tree, and provides all of the features mentioned above
2017-01-07 23:45:13 @_4of7 This is how we will move forward.
2017-01-07 23:45:36 @_4of7 It will greatly ease maintainance of libreboot, and allow us to focus on more important tasks besides patch integration
2017-01-07 23:45:55 @_4of7 The priority then, is to link to the librecore project, and encourage people to join that project.
2017-01-07 23:46:09 @_4of7 It might be a good idea to link to librecore from the libreboot website.
2017-01-07 23:46:09 <-- Amigatari (~Amigatari@217-210-111-240-no55.tbcn.telia.com) has quit (Quit: Leaving)
2017-01-07 23:47:52 @_4of7 The beauty of librecore is that it works as closely as possible to upstream.
2017-01-07 23:48:10 @_4of7 They developers of that project are also closely involved in upstream development, within coreboot itself
2017-01-07 23:48:19 @_4of7 they upstream their patches in coreboot upstream, in addition to librecore
2017-01-07 23:48:28 @_4of7 librecore is a 2-person project
2017-01-07 23:48:42 @_4of7 If it stalled one day, or disappeared, we'd still have a reference codebase from coreboot upstream
2017-01-07 23:49:09 @_4of7 Objectively, there are only benefits, and no disadvantages, to using librecore as upstream instead of coreboot.
2017-01-07 23:49:11 --> Niall_ (~Niall@cpc95050-newt40-2-0-cust147.19-3.cable.virginm.net) has joined #libreboot
2017-01-07 23:49:12 @_4of7 It's a no-brainer
2017-01-07 23:49:37 @_4of7 They are also, from what I've been told, working to integrate petitboot more closely than coreboot
2017-01-07 23:49:54 @_4of7 Which is also a boon to the libreboot project, which seeks to make petitboot an official payload option on all suitable systems
2017-01-07 23:50:20 @swiftgeek well that would remove BSD support
2017-01-07 23:50:35 @_4of7 Of course, but that does not mean we would drop GRUB and/or SeaBIOS
2017-01-07 23:50:49 @_4of7 We would maintain SeaGRUB as always, but with petitboot as an extra option
2017-01-07 23:51:00 @_4of7 BSD users would choose SeaGRUB or SeaBIOS
2017-01-07 23:51:06 <-- Niall_ (~Niall@cpc95050-newt40-2-0-cust147.19-3.cable.virginm.net) has quit (Client Quit)
2017-01-07 23:51:23 <-- CharlieBrown (~calher@72-95-86-186.dsl.dynamic.casstel.net) has quit (Remote host closed the connection)
2017-01-07 23:51:31 @_4of7 We would maintain SeaBIOS alongside petitboot, like we do with GRUB.
2017-01-07 23:51:32 @swiftgeek TianoCore with SeaBIOS as CSM would be nice
2017-01-07 23:51:39 @_4of7 SeaPetitBoot
2017-01-07 23:51:47 * dunx wants heads
2017-01-07 23:51:59 @_4of7 Yes, that is another interesting project
2017-01-07 23:52:00 @swiftgeek dunx: i'm not givinging you one
2017-01-07 23:52:06 @swiftgeek xD
2017-01-07 23:52:13 @_4of7 However, as I understand it, Heads is a Linux kernel payload for coreboot
2017-01-07 23:52:23 * swiftgeek ← it's past midnight here
2017-01-07 23:52:28 @_4of7 Heads is not based on coreboot
2017-01-07 23:52:34 +dunx yes, it's more than that though
2017-01-07 23:52:38 @_4of7 (this might be wrong, someone please correct if so)
2017-01-07 23:52:50 +dunx ofc not, it's a payload
2017-01-07 23:53:05 @_4of7 swiftgeek: leaving GNU was indeed an excellent choice, as you said so earlier
2017-01-07 23:53:16 +dunx its main attraction is it verifies the boot process
2017-01-07 23:53:26 @_4of7 it prompted damo22 and avph to create librecore, which greatly benefits the libreboot project, for all of the reasons mentioned above
2017-01-07 23:53:31 +dunx that nothing nasty has happenes
2017-01-07 23:53:51 @_4of7 They are attracting developers too
2017-01-07 23:54:01 @_4of7 This means that libreboot is attracting developers, when they become our upstream
2017-01-07 23:54:14 @_4of7 Their free software philosophy is also very close to ours
2017-01-07 23:54:32 @_4of7 Even if they dislike leah, there would start to be crossover between libreboot/librecore
2017-01-07 23:55:10 @_4of7 And there is no reason why they would not accept patches from us
2017-01-07 23:55:18 @_4of7 (if not, we would fork it)
2017-01-07 23:55:23 <-- arielenter (~ariel@200.92.71.95) has quit (Quit: Leaving.)
2017-01-07 23:55:30 @swiftgeek being outside of GNU attracts developers? :D
2017-01-07 23:55:54 @swiftgeek i guess it will be easier to get GSoC
2017-01-07 23:56:02 @_4of7 in this case, it scared away 2 developers, who then went on to create a project that is very much like our own, except it is coreboot-only
2017-01-07 23:56:11 @_4of7 and thus, their work is directly possible to integrate in libreboot
2017-01-07 23:56:27 @_4of7 The original plan was to continue to monitor their upstream patches in coreboot, but they seem to be doing our work for us at the moment.
2017-01-07 23:57:08 @_4of7 and now that its official, that means the noise will also quieten down
2017-01-07 23:57:15 @_4of7 we attracted developers before, aswell
2017-01-08 00:00:44 @_4of7 I'm creating a log of this discussion, for reference.
2017-01-08 00:01:05 nebul8 a 'monolog'
It may be necessary to keep coreboot, for the ARM chromebooks (rk3288 chipset).
Libreboot is a coreboot distribution, which integrates payloads, utilities,
documentation, additional patches/fixes and integrates everything together.
You can think of it like a GNU+Linux distribution, but it's a distribution of
the boot firmware, not the operating system. Libreboot incorporates coreboot,
deblobbing it with deblob scripts.
Librecore is a whole new fork of coreboot, and it is its own upstream, with
many coreboot developers working on it. It deblobs coreboot in-tree, without
deblob scripts. The only blobs that Librecore distributes is CPU microcode
updates, and we can simply exclude those in Libreboot, just as the current
build system deletes them after it downloads coreboot.
Librecore generally has a much more focused team, and their priority is libre
hardware. It is a very suitable upstream for Libreboot, much more so than the
coreboot project. Librecore is a very new project (formed in December 2016).
Its main developers are damo22, avph, funfunctor and others from the #coreboot
IRC channel. Of interest: damo22 and avph used to work for Libreboot, before
forming the Librecore project.
Current board fixes in Libreboot's git repository, not in the current stable
release of Libreboot:
gm45: use correct vbt string (needed for external monitors)
i945: add fake vbt (needed for external screens)
ga-g41m-es2l: enable use of PCIe x16 port
i945: add support for external monitors in grub
add vesafb mode to ga-g41m-es2l
gm45: add support for external monitors in grub
Fix low-res screens on T60
add hda verb to t60 (fixes mic)
gm45: fix IOMMU
There may be others. The above patches are most likely already merged in
Librecore's main Git repository. This should be investigated. If so, then they
can be deleted from Libreboot since they would already be merged upstream.
From the website:
It may be necessary to keep coreboot, for the ARM chromebooks (rk3288 chipset).
Libreboot is a coreboot distribution, which integrates payloads, utilities,
documentation, additional patches/fixes and integrates everything together.
You can think of it like a GNU+Linux distribution, but it's a distribution of
the boot firmware, not the operating system. Libreboot incorporates coreboot,
deblobbing it with deblob scripts.
Librecore is a whole new fork of coreboot, and it is its own upstream, with
many coreboot developers working on it. It deblobs coreboot in-tree, without
deblob scripts. The only blobs that Librecore distributes is CPU microcode
updates, and we can simply exclude those in Libreboot, just as the current
build system deletes them after it downloads coreboot.
Librecore generally has a much more focused team, and their priority is libre
hardware. It is a very suitable upstream for Libreboot, much more so than the
coreboot project. Librecore is a very new project (formed in December 2016).
See: <http://librecore.info/>
IRC channel (on freenode): #librecore
Its main developers are damo22, avph, funfunctor and others from the #coreboot
IRC channel. Of interest: damo22 and avph used to work for Libreboot, before
forming the Librecore project.
Current board fixes in Libreboot's git repository, not in the current stable
release of Libreboot:
- gm45: use correct vbt string (needed for external monitors)
- i945: add fake vbt (needed for external screens)
- ga-g41m-es2l: enable use of PCIe x16 port
- i945: add support for external monitors in grub
- add vesafb mode to ga-g41m-es2l
- gm45: add support for external monitors in grub
- Fix low-res screens on T60
- add hda verb to t60 (fixes mic)
- gm45: fix IOMMU
There may be others. The above patches are most likely already merged in
Librecore's main Git repository. This should be investigated. If so, then they
can be deleted from Libreboot since they would already be merged upstream.
https://librecore.info/
This is a new project, forked from coreboot, which deblobs coreboot but by hardforking the coreboot git repository (unlike libreboot, which maintains deblob scripts instead and rebases constantly on coreboot master)
I decided against this model when founding the libreboot project, but they seem to be doing a good job. I think we should consider using librecore as an upstream project, instead of coreboot.
Paul, what do you think?
The coreboot revision that librecore forks from is
94f8699d44and their git repo is https://github.com/librecore-org/librecore.git
2017-01-07 23:05:03 @_4of7 swiftgeek: librecore looks really good
2017-01-07 23:05:33 @_4of7 It might become libreboot's upstream, instead of coreboot, after the new build system is merged.
2017-01-07 23:06:03 @swiftgeek https://github.com/LibreCat/LibreCore ? :D
2017-01-07 23:06:04 @swiftgeek xD
2017-01-07 23:06:14 @swiftgeek i sure found something wrong xD
2017-01-07 23:08:20 <-- Anja (~Anja@49.50.252.82) has quit (Ping timeout: 248 seconds)
2017-01-07 23:08:53 @swiftgeek oh this one has something that i tested recently
2017-01-07 23:08:55 @swiftgeek https://github.com/librecore-org/librecore/issues/24
2017-01-07 23:10:08 @swiftgeek my guess will be forceful undocking which is breaking things
2017-01-07 23:10:24 @swiftgeek Undock is on Fn-F9
2017-01-07 23:20:12 @swiftgeek i guess i should test forceful undocking
2017-01-07 23:21:12 @swiftgeek nope, it breaks my USB, but doesn't break DP
2017-01-07 23:26:05 --> nom_de_plume (~yoda@anon-40-248.vpn.ipredator.se) has joined #libreboot
2017-01-07 23:26:23 <-- nom_de_plume (~yoda@anon-40-248.vpn.ipredator.se) has quit (Client Quit)
2017-01-07 23:27:53 <-- zyliwax (~zyliwax@unaffiliated/zyliwax) has quit (Quit: leaving)
2017-01-07 23:32:16 <-- Ferix (~Ferix@77.172.180.189) has quit (Quit: Goodbye)
2017-01-07 23:32:44 @_4of7 swiftgeek: adopting librecore as upstream means basically outsourcing maintenance of feature patches / rebases on top of coreboot upstream
2017-01-07 23:33:12 @_4of7 it's also a big f*ck you to damo22 and avph, who is the leader of the project
2017-01-07 23:33:26 @_4of7 it means that they'd still essentially be working for us, despite having left the libreboot project
2017-01-07 23:33:29 @_4of7 seems win-win to me
2017-01-07 23:33:41 @_4of7 and we can still add patches on top
2017-01-07 23:33:43 specing evil
2017-01-07 23:33:45 @_4of7 what libreboot does is:
2017-01-07 23:33:53 @_4of7 * maintains coreboot deblob scripts
2017-01-07 23:33:57 @_4of7 * maintains patches in tree
2017-01-07 23:34:02 @_4of7 * uses coreboot upstream
2017-01-07 23:34:04 @_4of7 * deblobs
2017-01-07 23:34:06 @_4of7 * applies patches
2017-01-07 23:34:11 @_4of7 it also uses multiple revisions
2017-01-07 23:34:23 specing _4of7: when have you joined the Borg?
2017-01-07 23:34:26 @_4of7 what librecore does (for all libre-compatible systems, including libreboot systems):
2017-01-07 23:34:41 @_4of7 * maintains 1 coreboot fork
2017-01-07 23:34:52 @_4of7 * deblobs that fork in tree, instead of with external blob lists and deblob scripts
2017-01-07 23:35:08 @_4of7 * rebases new patches from upstream, but only ones that are useful, for libre-compatible boards
2017-01-07 23:35:14 @_4of7 * deletes non-libre boards
2017-01-07 23:35:41 @_4of7 * maintains features in its tree, that coreboot does not have. this includes board fixes - this includes all board fixes currently in libreboot, most of which are not merged upstream in coreboot
2017-01-07 23:35:55 @_4of7 * is less beauacratic than coreboot about merging patches
2017-01-07 23:36:00 @_4of7 etc
2017-01-07 23:36:16 @_4of7 I considered librecore's module, when founding the libreboot project 3 years ago.
2017-01-07 23:36:40 @_4of7 It was considered unnecessary back then, because libreboot only supported 1 board, and at the time, coreboot contained a lot of blobs, so it made a ton of sense
2017-01-07 23:36:56 @swiftgeek well we will see what librecore is going to be
2017-01-07 23:36:58 @_4of7 nowadays, coreboot does a better job separating blobs to 3rdparty, so the work to maintain a deblobbed coreboot is very little
2017-01-07 23:37:08 @swiftgeek if it's going to be just yet another libreboot, it would be quite boring
2017-01-07 23:37:10 @_4of7 I mean damo22 and avph are basically doing our work for us
2017-01-07 23:37:15 @_4of7 to an even greater extent than before
2017-01-07 23:37:16 @swiftgeek and wasteful on human resources
2017-01-07 23:37:26 @_4of7 even though they've left the libreboot project
2017-01-07 23:37:32 @_4of7 We can assimilate librecore
2017-01-07 23:37:58 @_4of7 If they don't like us using it (since it means their work benefits us, when they intended to leave us), then their only choice is to stop developing librecore
2017-01-07 23:38:11 @_4of7 I once said that forks are a wonderful thing.
2017-01-07 23:38:20 @_4of7 In this case, librecore is not a libreboot fork - it's a better coreboot.
2017-01-07 23:38:28 --> arielenter (~ariel@200.92.71.95) has joined #libreboot
2017-01-07 23:38:29 -- Mode #libreboot [+v arielenter] by ChanServ
2017-01-07 23:38:33 @_4of7 It's even more than we would have considered feasible.
2017-01-07 23:39:20 @_4of7 The priority is to ditch coreboot as upstream, and integrate librecore instead, once we merge the new build system
2017-01-07 23:39:28 @_4of7 Paul is currently working on it, with my supervision
2017-01-07 23:40:07 @_4of7 It's this repository:
2017-01-07 23:40:08 @_4of7 git://git.code.paulk.fr/libreboot.git
2017-01-07 23:40:12 @_4of7 branch: paper-integration
2017-01-07 23:40:18 @_4of7 This is the new build system that we're working on
2017-01-07 23:40:31 @_4of7 It has many benefits over libreboot's current build system:
2017-01-07 23:40:35 @swiftgeek good thing that i focus on lower lever so i'm out of this discussion ^^
2017-01-07 23:40:37 @_4of7 * cleaner / more maintainable
2017-01-07 23:40:40 @swiftgeek *level
2017-01-07 23:40:59 @swiftgeek (just hardware)
2017-01-07 23:41:01 @_4of7 * support for building linux kernel, using the build system, with a provided config
2017-01-07 23:41:10 @_4of7 * support for building chromebook EC firmware from source
2017-01-07 23:41:27 * specing grabs popcorn
2017-01-07 23:41:30 @_4of7 * more standards compliant with other commonly used build environments
2017-01-07 23:41:36 * jxself grabs specing
2017-01-07 23:41:52 * _4of7 assimilates jxself and specing
2017-01-07 23:42:01 @swiftgeek 4of9
2017-01-07 23:42:41 @swiftgeek ahhhhh wasted
2017-01-07 23:42:44 @_4of7 * has various useful utilities related to development on ARM chromebooks, which libreboot supports
2017-01-07 23:42:45 @swiftgeek 7 of 9... dammit
2017-01-07 23:43:06 @_4of7 * integrates standard upstream flashrom, in addition to google's customised flashrom required for chromebooks
2017-01-07 23:43:10 @_4of7 * many many features
2017-01-07 23:43:14 @_4of7 However:
2017-01-07 23:43:37 @_4of7 * Uses libreboot's current concept of maintaining deblob scripts on top of upstream coreboot, with patches (but not coreboot) provided in tree
2017-01-07 23:43:44 @_4of7 We can have the best of both worlds:
2017-01-07 23:43:50 @_4of7 * Paper (name of the new build system)
2017-01-07 23:44:01 @_4of7 But we will:
2017-01-07 23:44:04 @_4of7 * ditch coreboot
2017-01-07 23:44:10 @_4of7 * delete the deblob scripts
2017-01-07 23:44:17 --> zyliwax (~zyliwax@unaffiliated/zyliwax) has joined #libreboot
2017-01-07 23:44:17 -- Mode #libreboot [+v zyliwax] by ChanServ
2017-01-07 23:44:18 @_4of7 * delete all patches for coreboot
2017-01-07 23:44:35 @_4of7 * switch to librecore as upstream, for boot firmware
2017-01-07 23:44:52 @_4of7 * librecore already deblobs in-tree, and provides all of the features mentioned above
2017-01-07 23:45:13 @_4of7 This is how we will move forward.
2017-01-07 23:45:36 @_4of7 It will greatly ease maintainance of libreboot, and allow us to focus on more important tasks besides patch integration
2017-01-07 23:45:55 @_4of7 The priority then, is to link to the librecore project, and encourage people to join that project.
2017-01-07 23:46:09 @_4of7 It might be a good idea to link to librecore from the libreboot website.
2017-01-07 23:46:09 <-- Amigatari (~Amigatari@217-210-111-240-no55.tbcn.telia.com) has quit (Quit: Leaving)
2017-01-07 23:47:52 @_4of7 The beauty of librecore is that it works as closely as possible to upstream.
2017-01-07 23:48:10 @_4of7 They developers of that project are also closely involved in upstream development, within coreboot itself
2017-01-07 23:48:19 @_4of7 they upstream their patches in coreboot upstream, in addition to librecore
2017-01-07 23:48:28 @_4of7 librecore is a 2-person project
2017-01-07 23:48:42 @_4of7 If it stalled one day, or disappeared, we'd still have a reference codebase from coreboot upstream
2017-01-07 23:49:09 @_4of7 Objectively, there are only benefits, and no disadvantages, to using librecore as upstream instead of coreboot.
2017-01-07 23:49:11 --> Niall_ (~Niall@cpc95050-newt40-2-0-cust147.19-3.cable.virginm.net) has joined #libreboot
2017-01-07 23:49:12 @_4of7 It's a no-brainer
2017-01-07 23:49:37 @_4of7 They are also, from what I've been told, working to integrate petitboot more closely than coreboot
2017-01-07 23:49:54 @_4of7 Which is also a boon to the libreboot project, which seeks to make petitboot an official payload option on all suitable systems
2017-01-07 23:50:20 @swiftgeek well that would remove BSD support
2017-01-07 23:50:35 @_4of7 Of course, but that does not mean we would drop GRUB and/or SeaBIOS
2017-01-07 23:50:49 @_4of7 We would maintain SeaGRUB as always, but with petitboot as an extra option
2017-01-07 23:51:00 @_4of7 BSD users would choose SeaGRUB or SeaBIOS
2017-01-07 23:51:06 <-- Niall_ (~Niall@cpc95050-newt40-2-0-cust147.19-3.cable.virginm.net) has quit (Client Quit)
2017-01-07 23:51:23 <-- CharlieBrown (~calher@72-95-86-186.dsl.dynamic.casstel.net) has quit (Remote host closed the connection)
2017-01-07 23:51:31 @_4of7 We would maintain SeaBIOS alongside petitboot, like we do with GRUB.
2017-01-07 23:51:32 @swiftgeek TianoCore with SeaBIOS as CSM would be nice
2017-01-07 23:51:39 @_4of7 SeaPetitBoot
2017-01-07 23:51:47 * dunx wants heads
2017-01-07 23:51:59 @_4of7 Yes, that is another interesting project
2017-01-07 23:52:00 @swiftgeek dunx: i'm not givinging you one
2017-01-07 23:52:06 @swiftgeek xD
2017-01-07 23:52:13 @_4of7 However, as I understand it, Heads is a Linux kernel payload for coreboot
2017-01-07 23:52:23 * swiftgeek ← it's past midnight here
2017-01-07 23:52:28 @_4of7 Heads is not based on coreboot
2017-01-07 23:52:34 +dunx yes, it's more than that though
2017-01-07 23:52:38 @_4of7 (this might be wrong, someone please correct if so)
2017-01-07 23:52:50 +dunx ofc not, it's a payload
2017-01-07 23:53:05 @_4of7 swiftgeek: leaving GNU was indeed an excellent choice, as you said so earlier
2017-01-07 23:53:16 +dunx its main attraction is it verifies the boot process
2017-01-07 23:53:26 @_4of7 it prompted damo22 and avph to create librecore, which greatly benefits the libreboot project, for all of the reasons mentioned above
2017-01-07 23:53:31 +dunx that nothing nasty has happenes
2017-01-07 23:53:51 @_4of7 They are attracting developers too
2017-01-07 23:54:01 @_4of7 This means that libreboot is attracting developers, when they become our upstream
2017-01-07 23:54:14 @_4of7 Their free software philosophy is also very close to ours
2017-01-07 23:54:32 @_4of7 Even if they dislike leah, there would start to be crossover between libreboot/librecore
2017-01-07 23:55:10 @_4of7 And there is no reason why they would not accept patches from us
2017-01-07 23:55:18 @_4of7 (if not, we would fork it)
2017-01-07 23:55:23 <-- arielenter (~ariel@200.92.71.95) has quit (Quit: Leaving.)
2017-01-07 23:55:30 @swiftgeek being outside of GNU attracts developers? :D
2017-01-07 23:55:54 @swiftgeek i guess it will be easier to get GSoC
2017-01-07 23:56:02 @_4of7 in this case, it scared away 2 developers, who then went on to create a project that is very much like our own, except it is coreboot-only
2017-01-07 23:56:11 @_4of7 and thus, their work is directly possible to integrate in libreboot
2017-01-07 23:56:27 @_4of7 The original plan was to continue to monitor their upstream patches in coreboot, but they seem to be doing our work for us at the moment.
2017-01-07 23:57:08 @_4of7 and now that its official, that means the noise will also quieten down
2017-01-07 23:57:15 @_4of7 we attracted developers before, aswell
2017-01-08 00:00:44 @_4of7 I'm creating a log of this discussion, for reference.
2017-01-08 00:01:05 nebul8 a 'monolog'
From the website:
It may be necessary to keep coreboot, for the ARM chromebooks (rk3288 chipset).
Libreboot is a coreboot distribution, which integrates payloads, utilities, documentation, additional patches/fixes and integrates everything together. You can think of it like a GNU+Linux distribution, but it's a distribution of the boot firmware, not the operating system. Libreboot incorporates coreboot, deblobbing it with deblob scripts.
Librecore is a whole new fork of coreboot, and it is its own upstream, with many coreboot developers working on it. It deblobs coreboot in-tree, without deblob scripts. The only blobs that Librecore distributes is CPU microcode updates, and we can simply exclude those in Libreboot, just as the current build system deletes them after it downloads coreboot.
Librecore generally has a much more focused team, and their priority is libre hardware. It is a very suitable upstream for Libreboot, much more so than the coreboot project. Librecore is a very new project (formed in December 2016).
See: http://librecore.info/ IRC channel (on freenode): #librecore
Its main developers are damo22, avph, funfunctor and others from the #coreboot IRC channel. Of interest: damo22 and avph used to work for Libreboot, before forming the Librecore project.
Current board fixes in Libreboot's git repository, not in the current stable release of Libreboot:
There may be others. The above patches are most likely already merged in Librecore's main Git repository. This should be investigated. If so, then they can be deleted from Libreboot since they would already be merged upstream.
Librecore development seems to have stalled. Closing for now. Reopen this issue if/when it is relevant.