coreboot October 2018

coreboot@coreboot.org

53 participants
145 discussions

Revisiting an old project from the FreeBIOS days

by Gregg Levine

Hello! I decided to revisit an old project from those days, and found that it built almost correctly, after making a number of changes. For example it looked as if our friend Eric was the originator behind it. I needed to change his work directory settings to match the one I set up for this interpretation of the process to build for an oldy but a goody. It's the build process for the Intel 440GX, and the script file I'm putting on this message shows what is happening towards the ending. But it wasn't a normal ending, and I believe it could be easily explained by a missing utility. I can supply the original blob the things below came from. And I remember a discussion as to what the target would have been found in, I myself find it interesting that it's the original target that was used for the Bochs project that's still running after about as many years as I've known about our project. ----- Gregg C Levine gregg.drwho8(a)gmail.com "This signature fought the Time Wars, time and again."

2 years, 4 months

Re: [coreboot] Matrix instead (or additionally to) IRC

by Iru Cai

Previously it works, but now #coreboot needs registered nicks. On Mon, Oct 29, 2018 at 3:43 AM Patrick Georgi via coreboot < coreboot(a)coreboot.org> wrote: > Not sure if that is still working but > https://matrix.org/blog/2015/06/22/the-matrix-org-irc-bridge-now-bridges-al… > should help connect to IRC via matrix. > > Choose your own protocol ;-) > > Am So., 28. Okt. 2018, 15:11 hat Philipp Stanner <stanner(a)posteo.de> > geschrieben: > >> Hey, >> >> have you guys already heard of Matrix? >> https://matrix.org/blog/home/ >> >> It's some sort of modern IRC, using JSON to format messages. It's more >> modern than IRC. Features are: >> * Source code formatting and highlighting in messages >> * multiple devices >> * history + history synchronization between multiple devices >> * possible E2C encryption >> >> and many more. >> In theory it will be a decentralized protocol, but there aren't that >> many servers yet and actually only one working server-software >> >> Many projects, especially tech-based ones like the Rust programming >> language already use the service. >> >> Personally I think it's an enormous progress to IRC. I would give it a >> chance if I were you :) >> >> P. >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot >> > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot > -- My website: https://vimacs.lcpu.club Please do not send me Microsoft Office/Apple iWork documents. Send OpenDocument instead! http://fsf.org/campaigns/opendocument/

2 years, 4 months

Re: [coreboot] [AMD family16h] What need to be done in coreboot to support the Virtual Wire mode

by Rudolf Marek

Hi, Dne 25. 10. 18 v 9:17 Zheng Bao napsal(a): > Any more ideas? Thanks. Maybe the bus topology is different in coreboot. It would explain why SATA works, because it is on bus 0. Thanks, Rudolf

2 years, 4 months

Re: [coreboot] Hardware diagnostic

by Naresh G. Solanki

I suggest you better check 1. power on sequence, 2. every power/ voltage rail stability during boot process. 3. Over/undershoot. 4. all crystal osc frequency stability during boot process. 5. Try to print the DID early during bootblock and romstage. Provide your observations. Regards, Naresh G Solanki

2 years, 4 months

New Defects reported by Coverity Scan for coreboot

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 2 new defect(s) introduced to coreboot found with Coverity Scan. 3 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 2 of 2 defect(s) ** CID 1396443: Error handling issues (CHECKED_RETURN) /src/soc/intel/skylake/romstage/romstage.c: 266 in fill_power_state() ________________________________________________________________________________________________________ *** CID 1396443: Error handling issues (CHECKED_RETURN) /src/soc/intel/skylake/romstage/romstage.c: 266 in fill_power_state() 260 261 struct chipset_power_state *fill_power_state(void) 262 { 263 struct chipset_power_state *ps; 264 265 ps = pmc_get_power_state(); >>> CID 1396443: Error handling issues (CHECKED_RETURN) >>> Calling "pmc_fill_power_state" without checking return value (as is done elsewhere 4 out of 5 times). 266 pmc_fill_power_state(ps); 267 268 return ps; ** CID 1396442: Memory - corruptions (ARRAY_VS_SINGLETON) ________________________________________________________________________________________________________ *** CID 1396442: Memory - corruptions (ARRAY_VS_SINGLETON) /src/lib/selfboot.c: 263 in _selfload() 257 258 cbfssegs = &((struct cbfs_payload *)data)->segments; 259 260 if (f && f(cbfssegs)) 261 goto out; 262 >>> CID 1396442: Memory - corruptions (ARRAY_VS_SINGLETON) >>> Passing "cbfssegs" to function "load_payload_segments" which uses it as an array. This might corrupt or misinterpret adjacent memory locations. 263 if (load_payload_segments(cbfssegs, &entry)) 264 goto out; 265 266 printk(BIOS_SPEW, "Loaded segments\n"); 267 268 rdev_munmap(prog_rdev(payload), data); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

2 years, 4 months

Reducing FSP performance time

by Antony AbeePrakash X V

Hi, We are building a FSP integrated coreboot image. We are using Intel FSP 2.0. While booting the coreboot image we get the following FSP performance data logs. Coreboot FSP Performance Data ID: 950 - 951: 2347842343 - 2126500026 --> 170ms ID: 952 - 953: #^!1175958314 - 3141289776 --> 1792ms ID: 954 - 955: #^!1702555243 - #^!1465185826 --> 182ms ID: 956 - 957: #^!1094328449 - #^!1091128442 --> 2ms ID:952 - 953 is FSP_TEMP_RAM_EXIT which takes around 1.7 sec. Below are the queries: 1. What is happening in FSP_TEMP_RAM_EXIT phase ? 2. Can we reduce this time further ? Please provide your feedback. 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.

2 years, 4 months

uefi rootkit (lojax)

by szbnwer＠gmail.com

hi all! :) ive just found this, and thought that it can be valuable info for the people around: https://www.welivesecurity.com/2018/09/27/lojax-first-uefi-rootkit-found-wi… (i hope it wont disturb anyone here, as its near to be offtopic) all the bests for all of you! :)

2 years, 4 months

Re: [coreboot] [AMD family16h] What need to be done in coreboot to support the Virtual Wire mode

by Rudolf Marek

Hi, Dne 23. 10. 18 v 1:57 Marc Jones napsal(a): > Does VxWorks use the ACPI tables for IRQ routing? You might need that. Yes good question. Usually OS uses ACPI, or MPTable or what BIOS provided in the PCI device itself. It seems because you are asking for the virtual wire mode IOAPIC is not supported and legacy PIC mode maybe needed? Does this OS configure LINT0 for ExtINT on at least one CPU? (this is how virtual wire can be implemented) Or second way to do that, is to program IO-APIC 0 or 2 depending on chipset to ExtInt. This will cause PIC interrupts to be delivered to the CPU. Please note that for PCI devices you also need to program PCI IRQ router and ELCR register if you are going to use the PIC mode, Thanks Rudolf

2 years, 4 months

Basic bios info

by mad.scientist.at.large＠tutanota.com

Can any one recommend a source for basic pc bios info? There's a lot to learn and some good links would be greatly appreciated. I'm a geek but I don't know much about bios code, data structures relevant to bioses, etc.

2 years, 4 months

cbfstool issue

by Wim Vervoorn

Hello, In the latest cbfstool I am missing the capability to control the location of a XIP stage. A XIP stage is always located on the first available position. So far I haven't found a way to either define the position (the base parameter conflicts with the XIP one) and I also haven't been able to make it fill downwards which is sufficient as well. Am I overlooking something or have these possibilities been removed? Best regards, Wim Vervoorn

2 years, 4 months

Jump to page:

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot October 2018