coreboot November 2018

coreboot@coreboot.org

71 participants
149 discussions

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

11 Nov '18

Am So., 11. Nov. 2018 um 00:43 Uhr schrieb Mike Banon <mikebdp2(a)gmail.com>: > But it is easier not to have any AMT/ME/PSP at all: no need to clean > anything and nothing to worry about. > At least not to your knowledge. For all we know, POWER9 (to pick the ISA where you can even edit the microcode) could have another processor in there that they "forgot" to tell you about. It just so happens to remove all protection levels when triggered by some sequence is found in the caches, eg. because it arrived over the network. Unless there's progress on projects like the sadly defunct Home CMOS[0], there's some level of trust required that the hardware isn't nefarious. So, is there really "nothing to worry about"? > Meanwhile you can't avoid the closed source Intel FSP the same way [as > AtomBIOS]. > FSP is also just software, and with no signatures. There have been successful efforts to replicate the functionality of very similar binaries (see Sandybridge/Ivybridge). 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. The AtomBIOS blob is parsed out by the OS, YABEL is long gone at that point. I'm not sure there is any equivalent for FSP. > It might be possible to run FSP inside YABEL or x86emu. Sounds like an interesting experiment. 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? There were additional factors, but release notes normally aren't novels. For the sake of completeness: 1. Not on the market for years 2. Not on the secondary market 3. No recent report (< 1 year old) on board-status at that point 4. No activity in related code that indicated that anybody would maintain it 5. Some of that code in question was getting in the way of modernization of coreboot's code base. We could have kept the code around, but it would be all but guaranteed to be broken. We considered it better to send people using those boards to 4.2 which at least had a chance of still working on them. And if they're serious about that hardware, they're more than welcome to step up as maintainers and bring the code back to master: The best way to avoid a board's deprecation is to maintain it. > The (AMD) platforms are not the problem. Maybe the problem is that their > fans got lazy and rested on AGESA, idk. > 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 > If there will be a time where keeping support for AGESA in becomes a real burden on coreboot development, and there is no maintainer for the boards based on it, expect to have to chip in the effort to keep support for those mainboards. Nico's arguments are from the coreboot developer's and maintainer's point of view, while yours represent a certain set of users' - and both are valid. However coreboot developers have no obligation to cater to the interest of any coreboot user (just like coreboot users are free to go elsewhere). Excusing yourself from working on coreboot, including cleaning up the less savory parts, pointing out "various freedom-related projects" means that you won't have a voice in coreboot's future direction. You're lucky though, the coreboot version that you're using on your AGESA based system won't go away. And if in the future there should be a reason to modify it, the source is also still there: just maybe not on the master branch. Regards, Patrick [0] http://web.archive.org/web/20150424121156/http://homecmos.drawersteak.com/w… -- 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

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

10 Nov '18

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

3 2

Re: [coreboot] Supported Motherboards
by Taiidan＠gmx.com 10 Nov '18

10 Nov '18

If you want an owner controlled coreboot-libre firmware (coreboot isn't always foss) available board get a kcma-d8, kgpe-d16, etc. or one of the raptor computing systems OpenPOWER boards which have foss firmware (not coreboot) from the factory, documentation and are owner controlled. You can score a D16 new on fleabay for $150 ATM plus a 6328 cpu for $30 resulting in (with ram and a good amd gfx card) being able to play games in a vm at max settings - there are a lot of good native linux and or drm free games right now. It seems those new D16's sold there also have the ASMB4 chip you need for OpenBMC. the G34/C32 opterons are much faster than the G41's C2Q's and the OpenPOWER9 stuff is much faster than intel/amd's proprietary blobbed x86 offerings of comparable price I have wrote longer posts about that in the past so look 'em up :D and welcome to the community. I concur the g505s is a superior choice to a me'ed device as me can't be disabled...unlike with workstations you can't have perfect with a laptop right now here's hoping for a openpower laptop.

1 0

Re: [coreboot] T430s prop BIOS Image
by Angel Pons 10 Nov '18

10 Nov '18

On Sat, Nov 10, 2018, 17:47 Alberto Bursi <alberto.bursi(a)outlook.it wrote: > Afaik there are companies that will ship you a pre-programmed SPI chip for > most devices, for like 20 euros. > > I used this one in the past http://www.bios-chip24.com/en_US but there > are others too. > > This is of course just as secure as getting it from some random guy on the > internet (i.e. not that much). > It is as secure as downloading a BIOS image from the internet, except you're paying much more.

1 0

Re: [coreboot] T430s prop BIOS Image
by Maillist 10 Nov '18

10 Nov '18

Hi, thank you, i tried that already , but it didnt work, neither simply mounting the iso, not with 7zip under windows, neither with dd to usb nor with nero/ burning it to a cd ( i used nero because i saw in hexeditor that the iso was build with it). Therefor, i really need that image somehow. No worrys about me getting hacked, neither that image nor that board will be used (just ifd for a little test). Let me know if you have any ideas left. cheers jonathan On 11/9/18 11:47 AM, Rafael Machado wrote: > Hi > The safer solution is to get it from the Manufacturer's website (nor > relying on someone's image, you may be hacked this way). > In this case you can download this .iso and "dd" to a usbdevice. > With this you will find the .bin with the entire bios image: > > https://support.lenovo.com/br/pt/downloads/ds029725 > > Hope it can help. > > Best Regards > Rafael R. Machado > > Em qui, 8 de nov de 2018 às 18:06, Maillist <maillist(a)cryptogs.de > <mailto:maillist@cryptogs.de>> escreveu: > > Hey Guys, does anyone happen to have a t430s bios image? I kinda > had way > to much mate this morning, so i was a little bit to enthusiastically > while desoldering and ripped the WSON-8 chip from the board. I > soldered > wires to the pins, but wasnt able to recover the image, and > without ifd, > i cant build coreboot. > > > cheers > > > -- > coreboot mailing list: coreboot(a)coreboot.org > <mailto:coreboot@coreboot.org> > https://mail.coreboot.org/mailman/listinfo/coreboot >

2 1

FSP settings according to decode-dimms
by Zvi Vered 09 Nov '18

09 Nov '18

Hello, Following is a partial output of decode-dimms: ------------------------------------------------------------------------- Module Type 72b-SO-UDIMM .... Maximum module speed 1333 MHz Size 4096 MB Banks x Rows x Columns x Bits 8 x 16 x 10 x 64 Ranks 1 SDRAM Device Width 8 bits Bus Width Extension 8 bits tCL-tRCD-tRP-tRAS 9-9-9-24 Supported CAS Latencies (tCL) 10T, 9T, 8T, 7T, 6T ---=== Timing Parameters ===--- Minimum Write Recovery time (tWR) 15.000 ns Minimum Row Active to Row Active Delay (tRRD) 6.000 ns Minimum Active to Auto-Refresh Delay (tRC) 49.125 ns Minimum Recovery Delay (tRFC) 260.000 ns Minimum Write to Read CMD Delay (tWTR) 7.500 ns Minimum Read to Pre-charge CMD Delay (tRTP) 7.500 ns Minimum Four Activate Window Delay (tFAW) 30.000 ns Number of SDRAM DIMMs detected and decoded: 1 --------------------------------------------------------------------------------- Following is a partial output of dmidecode: --------------------------------------------------------------------------------- Handle 0x0011, DMI type 17, 40 bytes Memory Device Array Handle: 0x000F Error Information Handle: Not Provided Total Width: 64 bits Data Width: 64 bits Size: 2048 MB Form Factor: DIMM Set: None Locator: A1_DIMM0 Bank Locator: A1_BANK0 Type: DDR3 Type Detail: Unknown Speed: 1333 MHz Manufacturer: A1_Manufacturer0 Serial Number: A1_SerNum0 Asset Tag: A1_AssetTagNum0 Part Number: Array1_PartNumber0 Rank: Unknown Configured Clock Speed: 1066 MHz Minimum Voltage: 1.35 V Maximum Voltage: 1.5 V Configured Voltage: 1.35 V ----------------------------------------------------------------------------------------- According to the above output I set the following in BCT: Enable Memory Down: Disabled DRAM Speed: 1333 DRAM Type: DDR3 DIMM 0 Enable: Enabled DIMM 1 Enabled: Disabled DIMM_DWidth: x8 DIMM Density: 4 Gbit DIMM_BusWidth: 8 bits DIMM_Sides: 1 Ranks tCL: 9 tRP_tRCD: 9 tWR: 15 tWTR: 7 tRRD: 6 tRTP: 7 tFAW: 30 I set DIMM_Density according to DDR's datasheet (MEM4G08D3E/FABG) Can you please tell if my settings are correct ? tWTR = 7.5nsec. but BCT gets only integer value. tRTP = 7.5nsec but BCT gets only integer value. Configured Clock Speed: 1066 MHz. Is this the speed I should set ? Thank you, Zvika

1 0

Re: [coreboot] Use VBIOS from vendor's original bin file
by Zvi Vered 09 Nov '18

09 Nov '18

Hi Mike, Thank you very much ! Best regards, Zvika On Wed, Nov 7, 2018 at 12:43 AM Mike Banon <mikebdp2(a)gmail.com> wrote: > Hello Zvika, > > > How can it find [VBIOS] in the vendor's bin file ? > > It really depends on the type of vendor's BIOS because they could be > packed differently. For example, if your vendor's BIOS is Inside then > you can use Inside H2OEZE utility (sadly its' Windows-only and not > available officially, but you could find it if really want). But > please keep in mind that your vendor's BIOS might be patching that > VBIOS during booting, if that is indeed so - then a "clean" unpatched > VBIOS extracted with this method, either will not work at all or work > with errors. So it is always recommended to extract VBIOS from a > running system, just in case. Usually these instructions are working - > https://www.coreboot.org/VGA_support#How_to_retrieve_a_good_video_bios > , see "Retrieval via Linux kernel" part. But if that's not working at > your system and you've tried everything else, here is a great > alternative method - > https://mail.coreboot.org/pipermail/coreboot/2017-July/084660.html > > Best regards, > Mike Banon > On Tue, Nov 6, 2018 at 10:18 PM Zvi Vered <veredz72(a)gmail.com> wrote: > > > > Hello, > > > > Currently I'm replacing the BIOS in the vendor's bin file with > coreboot.bin > > Can coreboot use Vendor's VBIOS instead of the serial console ? > > How can it find it in the vendor's bin file ? > > > > Thank you, > > Zvika > > -- > > coreboot mailing list: coreboot(a)coreboot.org > > https://mail.coreboot.org/mailman/listinfo/coreboot >

1 0

Baytrail: FspInitApi causing unknown post code
by Zvi Vered 09 Nov '18

09 Nov '18

Hello, In fsp_util.c I added 2 lines after FspInitApi: ... post_code(POST_FSP_MEMORY_INIT); FspInitApi(&FspInitParams); post_code (0x66); while (1); /* Should never return. Control will continue from ContinuationFunc */ die("Uh Oh! FspInitApi returned"); After booting I *** did not *** get 0x66 which is good. But I got post code 0x1E. It is not from coreboot source. How can I debug it ? Can wrong FSP settings cause this ? Thank you, Zvika

1 0

FSP - Momory configuration
by Zvi Vered 09 Nov '18

09 Nov '18

Hello, The memory configuration contains (also) the following fields: tCL tRP_tRCD tWR tWTR tRRD tRTP tFAW According to the datasheet of the DDR: tCL(avg): 0.47(Min) to 0.53(Max) The value in the BCT can be from: 1..255 How should I translate the values from datasheet to Intel's BCT ? Should we take the min or max value ? Thank you, Zvika

1 0

Motherboards supporting DDR4
by emanuele 09 Nov '18

09 Nov '18

Hi all, I'm new to coreboot and I'm looking for a motherboard supporting DDR4. It would be perfect if it supported both Intel and AMD processors. I checked at the coreboot board-status page [1]. However, it seems to me that all the motherboards support just DDR3 or previous. Does anyone know if there are compatible motherboards supporting DDR4? [1] https://coreboot.org/status/board-status.html Thank you all

1 0

← Newer
1
...
6
7
8
9
10
11
12
...
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