coreboot November 2018

coreboot@coreboot.org

71 participants
149 discussions

Re: [coreboot] Supported Motherboards
by ron minnich 12 Nov '18

12 Nov '18

On Sun, Nov 11, 2018 at 7:53 AM <echelon(a)free.fr> wrote: > > Anyway I think that it is stupid to get offensive and confrontational with the coreboot comunity even if it gets more and more Intel oriented.. > so is this statement based on a measurement or just your impression? I count 181 mainboard devicetree.cb files in the tree. Of these 73 have the string cpu.*intel in them. So less than half. Next we'd have to see how this changes over time. In 2012 there were 179 boards in the tree, 57 with that string in them. Not a giant change. If someone would like to correct my numbers or methodology that would be interesting but I think the claim fails. I'd also point out that starting in 2013 we re-introduced multiple architecture to the tree with arm and that has continued to grow (we had alpha, ppc and arm ca. 2005 but it got lost). as always, code wins. I think if you want truly open architecture, this is the year to stop working on obsolete hardware and get on riscv or power or even arm. We need your help! ron

1 0

Re: [coreboot] Coreboot hangs during SYS_RESET
by Antony AbeePrakash X V 12 Nov '18

12 Nov '18

Hi All, Could you please help us on the below queries: 1. How to issue soft reset from coreboot source ? 2. We issued soft reset using outb command from a sample Elf payload. The board boots to payload through coreboot, sends POST codes from 0x8 to 0x0f for two iterations and then the payload will trigger soft reset. After about 20 mins the board gets hang. Below is the code we are using for soft reset from payload. outb(RST_CPU | SYS_RST, RST_CNT); while (1) __asm__(“hlt”); Is the above method is correct way for issuing soft reset ? Please provide feedback on this. Thanks & Regards, Antony From: Naresh G. Solanki [mailto:naresh.solanki.2011@gmail.com] Sent: Wednesday, November 07, 2018 11:09 PM To: Aaron Durbin <adurbin(a)google.com> Cc: Antony AbeePrakash X V <AntonyAbee.PrakashXV(a)LntTechservices.com>; coreboot <coreboot(a)coreboot.org>; Dinesh Kumar <DINESHKUMAR.VARADARAJAN(a)LNTTECHSERVICES.COM> Subject: Re: [coreboot] Coreboot hangs during SYS_RESET 1. Can you make sure right microcode based on the CPUID is added. This is must. Based on CPUID(I guess 506cX for APL), you can locate them at 3rdparty/blobs/.. Select CBFS GENERATE and specify CPU UCODE BINARIES path. 2. Can you provide complete log and config(after adding microcode into cbfs) if you still see sys_reset issue. Regards, Naresh On Wed 7 Nov, 2018, 8:56 PM Aaron Durbin via coreboot <coreboot(a)coreboot.org<mailto:coreboot@coreboot.org> wrote: On Wed, Nov 7, 2018 at 6:47 AM Antony AbeePrakash X V <AntonyAbee.PrakashXV(a)lnttechservices.com<mailto:AntonyAbee.PrakashXV@lnttechservices.com>> wrote: > > Hi, > > > > We are developing coreboot (with Intel FSP) for apollo lake platform custom board. We are facing a hang issue during the SYS_RESET button press. > > > > Observations: > > With soft reset the board gets hang(occurs within 2 or 3 reboot) with POST code 0x38 and the coreboot log stops during the romstage relocation. (Logs attached for Ref.) > When the SYS_RESET is pressed again the board boots and hangs at same POST code 0x38. > > > > Please provide feedback and help us to resolve this issue. > I'm confused by the following logs in romstage: CBFS @ 0 size 70000 CBFS: Locating 'romstage.rel' CBFS: Found @ offset 64c0 size 480 romstage is relocated from fef40054 to 0x7abf1000 I'm not familiar where this code is coming from. Are you carrying external patches or have I forgotten what is going on here? > > > Currently our coreboot build does not include any microcode (CPU_MICROCODE_CBFS_NONE). We tried to change it as “Generate from tree” in memuconfig. > > But the build fails with fatal error saying no microcode/microcode.h file. > > > > Whether the CPU by default have microcode ? or we need to build the microcode in coreboot ? > > Please advise on this. > > > > Thanks & Regards, > > Antony > > > > L&T Technology Services Ltd > > www.LntTechservices.com<http://www.LntTechservices.com> > > This Email may contain confidential or privileged information for the intended recipient (s). If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. -- coreboot mailing list: coreboot(a)coreboot.org<mailto:coreboot@coreboot.org> https://mail.coreboot.org/mailman/listinfo/coreboot L&T Technology Services Ltd www.LntTechservices.com<http://www.lnttechservices.com/> This Email may contain confidential or privileged information for the intended recipient (s). If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system.

1 0

Re: [coreboot] Supported Motherboards
by Nico Huber 11 Nov '18

11 Nov '18

On 11/11/18 2:52 PM, echelon(a)free.fr wrote: > So by force of circumstances, unfortunately, we can expect that the > g505s (of other agesa based boards) will indeed be dropped from the > coreboot master in the near future.. That's not what I said or intended to say (we might know if ppl. wouldn't top post). I meant things may always be removed if not pro- perly maintained, and that the AGESA code is one of these areas. It wouldn't even be the first thing I'd drop, if I ever start to drop things. > We (the owners of agesa based boards) need to prepare for this > eventuality, and maybe if we want to keep coreboot alive (and evolving) > on our platforms we should consider a fork... Please don't insult me > for this for this reasoning (it is not even a proposal..), but we must > face the reality.. Hmmm... I remember when these discussions around "board removals" from the master branch started, we tried to make clear that development of these boards could continue on other branches. These boards wouldn't get the latest and greatest features any more but instead would not be broken trying to add the latest features ;) That seems much better and easier to handle than a port but was mostly rejected. > One problem I notice is that almost all the experts in the coreboot > comunity are focusing on Intel platforms nowadays (for professional > reasons I suppose..). That's not what I see. There are a lot of young non-professionals (or at least not employed for coreboot work) who start to work on coreboot. They mostly end up working with Intel hardware too. Code quality might be an issue. Compared to the better maintained open-source Intel code, AGESA is much harder to read, some AMD code barely readable. The diver- gence of AMD code might also be an issue. The Intel code all looks the same and is easy to get into; if you read and understood one platform, you understand the half of all Intel platforms in coreboot. For AMD there are sometimes different implementations even for a single chip. > So when "the push come to shove", it will be hard > for us newbs (yes Im an eternal newb in coreboot.. ;-)) to get advice > and support in our maintaining efforts.. AMD might be harder to configure than Intel, I'm not sure. But! there is public documentation for a lot of the older platforms. It's likely not complete but should be good enough to design the code. With some luck you'd only need to look into AGESA to fill the gaps. Nico

2 1

Re: [coreboot] Supported Motherboards
by kinky_nekoboi 11 Nov '18

11 Nov '18

I strongly agree to what Mike said. thats maybe the "i want a cheap but yet powerfull and as Free as possible" point of view. Also with the recent AMDGPU driver for linux. amd hardware is a good option to have a somewhat powerful and free graphics solution. And i am personaly much less worried about some vgabios or gpu microcode than an backdoor processor on my main cpu. If i will hopeful get mad C-skillz and better unterstanding about lowlevel hardware processes in the future, i really would like to contribute to those amd 15th gen Ports of coreboot. Am 11. November 2018 00:41:37 MEZ schrieb Mike Banon <mikebdp2(a)gmail.com>: >> There is no evidence that there is such a thing for Intel systems >with AMT disabled, either. > >But it is easier not to have any AMT/ME/PSP at all: no need to clean >anything and nothing to worry about. > >> I could secure it with a hyper-visor, I guess, but what if I just >want to run Linux? > >Possible to run Linux under a hypervisor as well, by using something >like QubesOS (which contains Xen). > >> > >> > 2) AtomDis of AtomBIOS is clear enough to make sure there aren't >any >> > backdoors ( https://pastebin.com/xKW9FV58 ), >> >> You have made (up?) that claim before. If it is clear to you and you >> have the knowledge to implement a free graphics driver for the G505s, >> please do it > >I could be a car mechanic without being able to build a new car from >scratch. When I looked under this car's hood (AtomDis) I saw just a >bunch of command tables like SetMemoryClock / AdjustDisplayPll / >EnableVGA_Render and data tables like LVDS_Info / >VRAM_UsageByFirmware. Haven't seen anything suspicious that could have >indicated some potential backdoors there. But if you don't want to run >this blob even under a hypervisor like Xen in QubesOS, there's always >an option to avoid this blob entirely by running your PC in a headless >mode. Meanwhile you can't avoid the closed source Intel FSP the same >way. > >In addition, there is YABEL option in coreboot to prevent the >undocumented access of OptionROMs to other PCI devices - which also >helps to reduce the concerns regarding this AtomBIOS blob. I'm not >sure there is any equivalent for FSP. > >> The support for pre-ME/FSP Intel boards shows that maintaining >> 10y+ old platforms can be fun and works out very well. > >But they could still be removed from coreboot just because of "EOL and >old"/"no-one is using them". From coreboot 4.3 release notes: " 20 >mainboards were removed that aren't on the market for years (and even >hard to get on Ebay) ". Stuff like this could happen to any board that >is old, or am I wrong here? > >> The (AMD) platforms are not the problem. Maybe the problem is that >their fans got lazy and rested on AGESA, idk. > >Its understandable that it could look like we are lazy and resting on >AGESA. But maybe we are busy using our coreboot'ed AMD computers for >various freedom-related projects - as the tools to create something >great? And having to rewrite AGESA would mean we're suddenly working >much more on the tools than on the stuff we're creating with them - >without any obvious benefit to the >not-hardcore-programmers-but-security-conscious people who see that >AGESA is open source already > >Best regards, >Mike Banon > > > >On Fri, Nov 9, 2018 at 9:27 PM Nico Huber <nico.h(a)gmx.de> wrote: >> >> On 11/9/18 2:22 PM, Mike Banon wrote: >> >> There might be neither ME nor PSP, but that just means the >controllers >> >> that are known and researched are absent (it doesn't tell you >anything >> >> about less researched ones). >> > >> > There is no evidence that AMD processors contained any "remote >> > management" controllers before late 16h family (Puma). Even the >early >> > 16h (Jaguar) is okay in this relation, and G505S CPU is 15h >(Richland) - >> > so, unlike the recent Intels, it does not contain any "remote >> > management" controllers that might be exploited as a hardware >backdoor> via some vulnerability. >> >> There is no evidence that there is such a thing for Intel systems >with >> AMT disabled, either. >> >> AMD graphics driver developers force you to put a usually >proprietary >> >> AtomBIOS into your firmware. >> > >> > 1) You can move AtomBIOS from the firmware to GRUB/Linux kernel >stage. >> > Putting it into your firmware is more convenient - but it's not the >only >> > solution and could be avoided (e.g. by following some of these >> > instructions - https://bugs.freedesktop.org/show_bug.cgi?id=26891 ) >> >> So you can shift the problem? Point is? I could secure it with a >> hyper-visor, I guess, but what if I just want to run Linux? >> >> > >> > 2) AtomDis of AtomBIOS is clear enough to make sure there aren't >any >> > backdoors ( https://pastebin.com/xKW9FV58 ), >> >> You have made (up?) that claim before. If it is clear to you and you >> have the knowledge to implement a free graphics driver for the G505s, >> please do it! If not, I suppose you lie deliberately. >> >> This list is about open-source firmware, if you want to make random >> claims about proprietary firmware, please do it somewhere else. >> >> >> The G505s still uses AGESA (a hard to maintain AMD reference >code). >> >> This (and actually the native coreboot AMD code too) might get >moved >> >> away from our master branch after any release. >> > >> > You are correct, it could be that one day coreboot will go full >Intel. >> >> That's not what I said. Actually, there is actively maintained AMD >code >> in our repo. I was talking about unmaintained code. >> >> > But that is more likely to happen simply because the corporations >> > participating in the development of coreboot aren't interested at >any >> > AMD boards. >> >> Nope, it's because the unmaintained code is no fun at all to work >with. >> If I (as a non-corporate contributor) want to clean something up >across >> the whole tree, there are sub-trees where I instantly see what I have >> to do, see how beautiful things turn out... there are also sub-trees >> that give me a bad time, delay a few hour job for days and as such >> lower the potential of non-corporate contributors. The code that runs >> on G505s lives in the latter sub-trees. >> >> > So the future coreboot indeed might support only some >> > Google/Purism computers together with Intel/Facebook/etc. in-house >> > proprietary boards, and there will not be any coreboot-supported >boards >> > without Intel ME + full complex set of their blobs (FSP etc.) >> >> That's unlikely. The support for pre-ME/FSP Intel boards shows that >> maintaining 10y+ old platforms can be fun and works out very well. >The >> (AMD) platforms are not the problem. Maybe the problem is that their >> fans got lazy and rested on AGESA, idk. >> >> >> The last time I worked on a bigger patch set in my spare time, I >nearly >> >> gave up after some nights of work because of the unmaintainable >mess >> >> around {cpu,nb,sb}/amd/ >> > >> > If its difficult to write the crossplatform code in some cases or >if you >> > aren't interested at AMD boards (understandable if you don't have >any), >> > you could use something like "ifdef INTEL_BOARD then >Enable_Feature_X >> > else Dont_Enable". Better to live without some not-essential >features >> > than removing the boards, especially since there really aren't a >lot of >> > coreboot-supported motherboards. >> >> That makes no sense at all. Either you want to have new features, up >to >> date support etc., then we have to maintain it on the master branch. >If >> we "ifdef" things out, it's the same as having it on a separate >branch. >> >> >> I believe it's only a question of time until coreboot maintainers >are >> >> finally fed up with it. >> > >> > The majority of platform-specific problems discussed at the mailing >> > lists are directly related to Intel. Sometimes I'm seeing so many >of >> > them flooding my inbox, I'm wondering how the coreboot maintainers >> > aren't fed up with Intel mess. >> >> Your statistics are biased by the fact that almost nobody uses >coreboot >> for AMD (in production) compared to Intel. But to be honest, Intel >does >> a mess indeed, but it's not half as bad as the unmaintained (even the >> native) AMD code. >> >> > Here are some long thread examples: >> > >> > *) "How to get correct memory params for FSP" *) "[skylake] Can not >turn >> > monitor on" *) "Kabylake unable to boot with post code 0x71" + >could dig >> > out much more if required. >> > >> > Even from a bystander's point of view it is quite obvious that many >of >> > these Intel-specific problems have been caused by the improper >software >> > design and insufficient source code quality. Luckily you seem to >> > recognize these problems, as I could see from some of your messages >like >> > this one - >> > >https://mail.coreboot.org/pipermail/coreboot/2018-November/087722.html >. >> > Whether this has been caused by Intel outsourcing to developing >> > countries, or "quantity-over-quality" approach, I don't know. >However: >> > despite the Intel source code being as messy as AMD (if not more >messy) >> > you don't see any serious discussions regarding the removal/rewrite >of >> > Intel, and we all know why. >> >> Nope, as said above, the unmaintained AMD is a hell a lot messier. >> >> >> A good solution would be to write native coreboot code for this >> >> platform from scratch. Something at least of the quality of >intel/x4x >> >> (and the compatible southbridges) would be much appreciated and >would >> >> likely maintain itself for some years. >> > >> > But that will not protect AMD code from removal. When someone will >want >> > to remove it, in any case they will find a reason: either "EOL and >old" >> > (could happen to intel/x4x regardless of its' source code quality) >or >> > "no feature/property X we've introduced and absolutely require" >> > (something like "late vs early init") or simply "why should we care >> > about AMD boards if we work with/at Intel". Maybe then the coreboot >> > project will be forked and there will be two coreboots: one for the >> > people, and another for corporations. >> >> Well, I'm with the people. And if I would fork coreboot for the >people, >> the unmaintained AMD code would be high up on the list of what to >drop >> to be able to support the rest better. You seem to be absolutely con- >> fused about coreboot development. There are a lot active >non-corporate >> developers in the community. You are asking them to maintain the >crappy >> code too, for less fun and no money. How should that ever work out? >> >> > Sorry, but it seemed more like "Please avoid AMD if possible, its' >going >> > to be removed". Problem that its hard to avoid AMD without going >Intel, >> > and there are a lot more reasons to avoid Intel than AMD: in >addition to >> > the earlier introduction of remote management controllers and being >a >> > monopoly, there are serious Intel-only security vulnerabilities >like >> > Meltdown which requires a 5%-30% performance degrading patch and >Intel >> > hyperthreading will be disabled soon ( >> > >https://www.theregister.co.uk/2018/11/02/portsmash_intel_security_attack/). >> > Perhaps it makes more sense to say >> > >> > " Please avoid Intel if possible " >> > >> > but I don't want to start "Intel vs AMD" holy war there, especially >> > since it seems we are greatly outnumbered by >> > Intel-employed/partnered/sympathetic folks (how could one be >sincerely >> > sympathetic to Intel is a big question though). >> >> Yeah, it's weird. I'm absolutely not on the Intel side. I just can't >> stand your biased bullshit. So I'm looking for arguments against AMD >> when I see your unfounded arguments against Intel. Not because I >don't >> like AMD but because I don't like this list to look dubious, i.e. >that >> we would accept biased arguments without correcting them. >> >> Nico > >-- >coreboot mailing list: coreboot(a)coreboot.org >https://mail.coreboot.org/mailman/listinfo/coreboot

3 2

Re: [coreboot] Supported Motherboards
by Nico Huber 11 Nov '18

11 Nov '18

On 11/11/18 12:41 AM, Mike Banon wrote: >> There is no evidence that there is such a thing for Intel systems with AMT disabled, either. > > But it is easier not to have any AMT/ME/PSP at all: no need to clean > anything and nothing to worry about. > >> I could secure it with a hyper-visor, I guess, but what if I just want to run Linux? > > Possible to run Linux under a hypervisor as well, by using something > like QubesOS (which contains Xen). When I said `just want to run Linux` I meant exactly the opposite of what you propose: just/only Linux. Doesn't matter. >>> 2) AtomDis of AtomBIOS is clear enough to make sure there aren't any >>> backdoors ( https://pastebin.com/xKW9FV58 ), >> >> You have made (up?) that claim before. If it is clear to you and you >> have the knowledge to implement a free graphics driver for the G505s, >> please do it > > I could be a car mechanic without being able to build a new car from > scratch. When I looked under this car's hood (AtomDis) I saw just a > bunch of command tables like SetMemoryClock / AdjustDisplayPll / > EnableVGA_Render and data tables like LVDS_Info / > VRAM_UsageByFirmware. Haven't seen anything suspicious that could have > indicated some potential backdoors there. Well, I wouldn't expect AtomDis to output something like EvilFunction. What would you expect is suspicious? For me, VRAM_UsageByFirmware is definitely something I'd look into before I could tell. VRAM in the integrated graphics case, might be your system RAM. Maybe this could be used to give accidental access to some RAM that isn't supposed to be used as VRAM? > But if you don't want to run > this blob even under a hypervisor like Xen in QubesOS, there's always > an option to avoid this blob entirely by running your PC in a headless > mode. We were talking about the G505s, right? > Meanwhile you can't avoid the closed source Intel FSP the same > way. There's no board in coreboot that uses FSP and would compare to the G505s. >> The support for pre-ME/FSP Intel boards shows that maintaining >> 10y+ old platforms can be fun and works out very well. > > But they could still be removed from coreboot just because of "EOL and > old"/"no-one is using them". From coreboot 4.3 release notes: " 20 > mainboards were removed that aren't on the market for years (and even > hard to get on Ebay) ". Stuff like this could happen to any board that > is old, or am I wrong here? I don't think so. Maybe nobody even asked to keep these boards. > >> The (AMD) platforms are not the problem. Maybe the problem is that their fans got lazy and rested on AGESA, idk. > > Its understandable that it could look like we are lazy and resting on > AGESA. But maybe we are busy using our coreboot'ed AMD computers for > various freedom-related projects - as the tools to create something > great? And having to rewrite AGESA would mean we're suddenly working > much more on the tools than on the stuff we're creating with them - > without any obvious benefit to the > not-hardcore-programmers-but-security-conscious people who see that > AGESA is open source already I'm not sure what to say. Do you imply that open source makes anything more secure? There are some benefits in open-source development that seem to result in rather secure code. For instance, reviewing processes, that you get more people look at the code etc. But I don't see that for AGESA (maybe because I didn't try to read it). I don't know if it has ever been audited with security in mind or even reviewed. Most of the AGESA related work in coreboot is about wrapping it, so nobody has to look into it. For me, using open-source AGESA is no more secure than using FSP (until I read its code). That's also why I never ask silicon vendors for code but for documen- tation instead. If the code isn't written/reviewed/maintained by an open-source community, what's the point of open source? (I know I know, freedom to adapt it, but that doesn't make it secure per se.) Nico

1 0

Re: [coreboot] romstage prints from qemu-440bx emualtor
by ron minnich 11 Nov '18

11 Nov '18

I can confirm this fixes it. On Sun, Nov 11, 2018 at 3:27 PM ron minnich <rminnich(a)gmail.com> wrote: > > ok, and because I was not thinking I hit submit on > https://review.coreboot.org/#/c/coreboot/+/29574/2 > > apologies in advance, it seems to cause no harm however. > > > On Sun, Nov 11, 2018 at 3:08 PM Patrick Rudolph <siro(a)das-labor.org> wrote: > > > > Hi Ron, > > There's a patch on Gerrit that (indirectly) fixes the issue: https://review.coreboot.org/c/coreboot/+/29578 > > Regards > > > > On November 11, 2018 9:36:00 PM GMT+01:00, ron minnich <rminnich(a)gmail.com> wrote: > >> > >> So, with latest tip of tree, I still get no romstage prints. I'm told > >> that's fixed, can someone here test and let me know? > >> > >> I can work around it but it would be nice if we could get this fixed.

1 0

Re: [coreboot] romstage prints from qemu-440bx emualtor
by Patrick Rudolph 11 Nov '18

11 Nov '18

Hi Ron, There's a patch on Gerrit that (indirectly) fixes the issue: https://review.coreboot.org/c/coreboot/+/29578 Regards On November 11, 2018 9:36:00 PM GMT+01:00, ron minnich <rminnich(a)gmail.com> wrote: >So, with latest tip of tree, I still get no romstage prints. I'm told >that's fixed, can someone here test and let me know? > >I can work around it but it would be nice if we could get this fixed. > >-- >coreboot mailing list: coreboot(a)coreboot.org >https://mail.coreboot.org/mailman/listinfo/coreboot

2 1

Re: [coreboot] FSP settings according to decode-dimms
by Nico Huber 11 Nov '18

11 Nov '18

Hi Zvi, I assume you still ask for the BayTrail FSP, correct? You didn't mention it in your last mails. On 11/10/18 8:47 AM, Zvi Vered wrote: > Module Type 72b-SO-UDIMM This suggests that you have a DIMM? i.e. a module, not soldered down DRAM, is that correct? > Enable Memory Down: Disabled > DRAM Speed: 1333 > ... These settings all live in a struct called MEMORY_DOWN_DATA. I don't know for sure, but I assume with "EnableMemoryDown Disabled" you disable the whole struct. I can also not find a single board in coreboot that sets `EnableMemoryDown` explicitly to 0. Maybe one of the FSP BayTrail maintainers can clarify? or even provide some documentation? Also, please use coreboot's infrastructure to set these things from your mainboard's `romstage.c` or `devicetree.cb`. If you want help with BCT, better ask Intel. If you have a real DIMM module with an SPD that can be read from SMBus, I would try setting `PcdMrcInitSPDAddr1`. Be aware that it expects the SMBus address shifted left by 1 (e.g. the 7-bit address 0x50 would be 0xa0 for FSP). You can set it from the devicetree, for examples check the source, e.g.: git grep '"PcdMrcInitSPDAddr1"' If you don't have a module but soldered down memory, here's an example how to map the values from your SPD to FSP: `mainboard/siemens/mc_tcu3/ romstage.c`. I'm not sure if this works though, as this board also sets `PcdMrcInitSPDAddr*` in the devicetree, which confuses me (same for intel/minnowmax, Intel maintainers?). Hope that helps, Nico

2 1

romstage prints from qemu-440bx emualtor
by ron minnich 11 Nov '18

11 Nov '18

So, with latest tip of tree, I still get no romstage prints. I'm told that's fixed, can someone here test and let me know? I can work around it but it would be nice if we could get this fixed.

1 0

Re: [coreboot] Supported Motherboards
by Patrick Georgi 11 Nov '18

11 Nov '18

Am So., 11. Nov. 2018 um 14:54 Uhr schrieb <echelon(a)free.fr>: > We (the owners of agesa based boards) need to prepare for this > eventuality, and maybe if we want to keep coreboot alive (and evolving) on > our platforms we should consider a fork... Please don't insult me for this > for this reasoning (it is not even a proposal..), but we must face the > reality.. > You're free to contribute to improve the code quality of AGESA based boards in coreboot. Practically all Lenovo mainboards in the coreboot tree are maintained by volunteers, back to the i945 based x/t60. > to get advice and support in our maintaining efforts.. I don't think advice and support are the issue here, but the question who would be doing the maintaining. The interesting part about "clean up AGESA" is that you don't need to be an expert in firmware to do that: There are so many simple things to do (for example, align the coding style to be more coreboot-like, given that AMD gave up on the coreboot-AGESA integration). We have a couple of contributors who probably aren't experts in firmware but do great work like that (although not on AGESA, they seem to be interested in other parts of the tree), and slowly ramp up to more complex projects. Regular board-status updates would also demonstrate that the code is still being actively used in current trees, and help identify commits that broke coreboot on these boards. I wouldn't know if any random supermicro mainboard still boots with coreboot from today's master branch. Do you? But what definitely won't work, neither in coreboot nor in any fork, is to expect others to cater to your needs: For maintaining, you need maintainers. Patrick -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

1 0

← Newer
1
...
5
6
7
8
9
10
11
...
15
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 November 2018