[coreboot] Re: problems on X220

Hi Jan, On 08.05.20 11:25, JPT wrote: > Sorry, I assumed the 11 branch was the branch for the soon to come > release. I built with master again, but there isn't much difference. but, was there a difference? I've looked at your list of problems again, at least one is expected. So maybe they are

[coreboot] Re: Hiccups bringing ACPI support to p3b-f

Hi Keith, On 06.05.20 18:50, Keith Hui wrote: > I've run into two problems with this work and hoping for insights. > > First, Linux kernel is throwing a warning. Full dmesg (from kernel > start to prompt) attached, but it's these lines in particular: > > [5.977786] ACPI Warning: SystemIO

[coreboot] Re: problems on X220

Hello Jan, On 07.05.20 17:38, JPT wrote: > I got several problems with coreboot on X220. your issues seem very random and unexpected. Three possible explanations come to mind: a) coreboot fails to properly initialize your RAM and this causes general instability. b) your coreboot build is flawed,

[coreboot] Re: beginner's despair ;) coreboot update via internal fails

Hi, On 07.05.20 18:11, Felix Held wrote: > I'd say that flashrom only verifying the section it writes by default > would be less surprising behavior than the current behavior. we'd need a distinction between reliable and unreliable programmers first. Because not verifying everything with the

[coreboot] Re: Linux kernel says "do_IRQ: 1.55 No irq handler for vector​"

Hi Zheng, On 03.05.20 17:27, Zheng Bao wrote: > I am debugging the AMD Picasso board. When Linux kernel boots, there is some > error message in dmesg. > do_IRQ: 1.55 No irq handler for vector​ > > The kernel can still boot. > What does this message mean? Can I just ignore this message? well,

[coreboot] Re: CBFS pointer problem with SeaBios and Apollo Lake platform

On 27.04.20 11:23, Nico Huber wrote: > I'm a bit confused about the 0xEBEFFC, I would expect it at 0xbbeffc > in the BIOS region (or 0xbbfffc in the coreboot.rom). Nevermind, I forgot to add the OBB offset. 0xebeffc is correct. Nico ___ co

[coreboot] Re: CBFS pointer problem with SeaBios and Apollo Lake platform

Hi, On 27.04.20 11:04, Wolfgang Kamp - datakamp wrote: > Yes it is for the UP squared board. > It seems to me that coreboot writes a pointer at the end of CBFS. > The pointer is 0xFF483038 at address 0xEBEFFC. > This pointer is wrong. > If I manually patch the value 0x48 to 0x44 everything is ok

[coreboot] Re: libgfxinit: Panel Backlight with Apollo Lake (Broxton)

Hello Wolfgang, On 21.04.20 16:50, Wolfgang Kamp - datakamp wrote: > I found out that the panel backlight enable function in libgfxinit for > Broxton platform (Intel x5-E3940) will not work for me. > The Backlight Enabling Sequence Description in the Intel document Doc Ref # > IHD-OS-BXT-Vol

[coreboot] sb/intel/bd82x6x/ remapping oddities (was Re: ThinkPad T420 and FireWire chip on Linux)

On 09.04.20 02:04, Peter Stuge wrote: > I found something that might be relevant in https://del.dog/raw/cbmemlog > however, search it for Remap: > > --8<-- https://del.dog/raw/cbmemlog#149 > PCI: 00:1c.0: Disabling device > PCI: 00:1c.0: check set enabled > PCH: Remap PCIe function 1 to 0 That's

[coreboot] Re: ThinkPad T420 and FireWire chip on Linux

On 10.04.20 08:52, Alesandar Metodiev wrote: > It would be nice if we push that change to the mainline, but I believe that > it was declared as 0x87 on a purpose. I assume bit 2 simply turns the FW function on and off. People without a FW connector would simply see a spurious FW controller. But

[coreboot] Re: ThinkPad T420 and FireWire chip on Linux

On 08.04.20 21:29, Nico Huber wrote: > On 08.04.20 20:02, Peter Stuge wrote: >> Alesandar Metodiev wrote: >>> AreYouLoco has already posted the output of `sudo lspci -vvxxx -s >>> 0d:00.3` (when he was still running with the vendor firmware). >>> Here it is

[coreboot] Re: ThinkPad T420 and FireWire chip on Linux

On 08.04.20 20:02, Peter Stuge wrote: > Alesandar Metodiev wrote: >> AreYouLoco has already posted the output of `sudo lspci -vvxxx -s >> 0d:00.3` (when he was still running with the vendor firmware). >> Here it is. https://del.dog/raw/firewire_lspci > > Comparing that with

[coreboot] Re: ThinkPad T420 and FireWire chip on Linux

Hi, On 08.04.20 13:45, AreYouLoco? wrote: > I can confirm that my Firewire controller with coreboot is detected as > MMC/SD Controller. The same situation as yours so seems like a bug. > > I tried Debian and Ubuntu Studio both detect it as SD/MMC Controller. > It gets detected correctly on stock

[coreboot] Re: Debug MRC.BIN, how to make ramstage CBMEM persistant across reboot ?

Hi, On 03.04.20 21:30, None via coreboot wrote: > However the logs seems truncated, just like if the log buffer is not flushed > on the console until it is full ? > > For instance the last output showed on the console is : > > [...] > BS: BS_PAYLOAD_LOAD times (ms): entry 0 run 22 exit 0 >

[coreboot] Re: Could anyone successfully using T440p to boot Windows share your config or build output image?

Hi Dalao, On 30.03.20 03:08, Dalao via coreboot wrote: >> This might be easy to fix. What are the required IDs and what are the >> current ones with coreboot? > > The normal id on vendor bios is: PCI\VEN_10EC_5227_220E17AA but on > coreboot it becomes PCI\VEN_10EC_5227_522710EC . It seems wired

[coreboot] Re: libgfxinit quick starter guide

On 28.03.20 11:43, Michal Zygowski wrote: > I used the same picture laoding code and the same image. The only thing > that changed was the graphics initialization: VGA ROM vs libgfxinit. If you want to change the encoding (I never tried this) PLANE_CTL bit 20 seems to do the trick. For older

[coreboot] Re: libgfxinit quick starter guide

Hi Michal, On 27.03.20 15:49, Michal Zygowski wrote: > Another question about libgfxinit. > > Up till Skylake the libgfxinit worked great for me, however after > enabling it on a Kaby Lake platform I noticed the colors are flipped. > I.e. when using VGA ROM the bootsplash image is correctly

[coreboot] Re: Need PCI(e) vs PNP resource allocation help

Hi Keith, On 18.03.20 23:55, Keith Hui wrote: > These are the devicetree.cb entries: > > device pnp 2e.b on # HWM, LED > io 0x60 = 0x290 # HWM address > drq 0xe4 = 0xf9 # GP50,52,55 > drq 0xf0 = 0x3e # Enable all fan input debouncer > end it looks like this 2e.b LDN has another i/o

[coreboot] Re: Trying to debug T440p's display problem, compared it with T420.

Hi Dalao, On 16.03.20 13:05, Dalao wrote: >> this combination is flawed. It will run the VGA BIOS twice, once in coreboot >> and once in SeaBIOS. Generally, this only works by chance. > > Oh thank you! I have changed to none now. BTW, could the source set it to > none automatically if add the

[coreboot] Re: libgfxinit quick starter guide

Hi, On 16.03.20 13:01, Michal Zygowski wrote: > Regarding the registers description, maybe EDS or other documents have > better situation? I have Braswell EDS so i can check it, but if you have > any documents that describe display registers for Braswell, let me know > which ID it is so I can get

[coreboot] Re: Trying to debug T440p's display problem, compared it with T420.

Hello Dalao, On 16.03.20 09:23, Dalao via coreboot wrote: > 1, Run VGA Option ROMs+Legacy VGA text mode+VGA BIOS+SeaBIOS: this combination is flawed. It will run the VGA BIOS twice, once in coreboot and once in SeaBIOS. Generally, this only works by chance. > T420: Everything works fine > Can

[coreboot] Re: libgfxinit quick starter guide

On 15.03.20 20:37, Nico Huber wrote: >> On Wed, Mar 11, 2020 at 9:45 AM Michal Zygowski >> wrote: >> I see the programming manuals from Intel >>> are in place: >>> https://01.org/linuxgraphics/documentation/hardware-specification-prms > > Alas, thi

[coreboot] Re: libgfxinit quick starter guide

Hi Michal, hi Matt, On 15.03.20 06:41, Matt B wrote: > You probably want to speak with Nico. He's a libgfxinit expert afaik. thanks for the heads up :) > On Wed, Mar 11, 2020 at 9:45 AM Michal Zygowski > wrote: > >> Particularly I would like to implement Braswell support for native >> graphics

[coreboot] Re: Installing Core Boot on a Lenovo X230 with a script.

On 21.02.20 19:16, Matt DeVillier wrote: > The x230 requires exploiting a vulnerability in an older UEFI version > in order to be flashed without external hardware (and even so, is > limited to flashing the 4MB BIOS region only; if you want to disable > the ME and use more space for the BIOS

[coreboot] Re: Coreboot on the Lenovo X220

Hi Richard, On 20.02.20 17:33, Richard Hughes wrote: > I've tried many different .configs, and most of the data in the wiki > and various blog posts is very old (multiple years) and as yet I > haven't manage to build anything that boots, or even turns on the > display for that matter. there is

[coreboot] Re: X220 and coreboot?

Hi Eero, to switch from vendor firmware to coreboot, on an X220, you need either an external flash programmer or a slight hardware modification (connect a certain pin to disable flash protections). The latter requires a very fragile software procedure. Otherwise, you won't be able to write to

[coreboot] Re: Discussing Controversial Upstreaming

On 26.01.20 20:15, David Hendricks wrote: > On Sat, Jan 25, 2020 at 4:44 PM Nico Huber wrote: >> we've recently seen the deprecation of Intel/Broadwell-DE support >> because it turned out to be too proprietary to be maintained in the >> long run. > > To be fair, the F

[coreboot] Re: Discussing Controversial Upstreaming

Hi Marshall, On 28.01.20 02:12, Marshall Dawson wrote: >> That's why I always encourage people to ask for documentation instead >> of code. Opening code that was developed in private is a pain for both >> sides. However, I guess it could be taken as a good omen; that a silicon >> vendor won't

[coreboot] Re: Discussing Controversial Upstreaming

Hi Jonathan, On 27.01.20 23:01, Jonathan Zhang (Infra) wrote: > On 1/27/20, 10:56 AM, "Nico Huber" wrote: >> We had this before: Something that nobody really cared about was >> upstreamed. And then later, it was copied for newer platforms and >> peopl

[coreboot] Re: Discussing Controversial Upstreaming

Hi Marshall, thank you very much for your huge elaboration. I had already given up all hope to see public communication from AMD. That's really great to see things change. It's a lot to digest, I'll try to just briefly comment on my main concern, why I called it controversial: the unclear blob

[coreboot] Re: Discussing Controversial Upstreaming

Hi Jonathan, thanks for your email. It's become very rare that developers take part in mailing-list discussions when they are asked to. So it's really appreciated. On 27.01.20 17:21, Jonathan Zhang (Infra) wrote: > On 1/26/20, 11:32 AM, "Nico Huber" wrote: >> >> H

[coreboot] Re: Do we have a rule that code should be build tested?

Hi David, I'm not so sure what we argue about here. The hypothetical case that it's hard to hook things up for build testing early, right? I've haven't seen that yet. On 26.01.20 23:49, David Hendricks wrote: >> On 26.01.20 19:46, David Hendricks wrote: >> Of course, there'll always be a gap

[coreboot] Re: Discussing Controversial Upstreaming

Hey Martin, On 26.01.20 21:21, Martin Roth wrote: > The picasso platforms are being worked on in a private repo because > it's not bootable at coreboot.org. It's not bootable because the > patches that would make it bootable were delayed and rejected. I'm sorry that you had trouble with your

[coreboot] Re: Discussing Controversial Upstreaming

On 26.01.20 20:36, Martin Roth wrote: > While it's not my preference, I'm fine with pulling picasso out of the > tree and doing the development in private if that's the community > desire. When we're done, it can go in, or not, as the coreboot > community chooses. Because we can't boot what's in

[coreboot] Re: Discussing Controversial Upstreaming

On 26.01.20 21:09, Nico Huber wrote: > Hi Martin, > > On 26.01.20 20:36, Martin Roth wrote: >> While it's not my preference, I'm fine with pulling picasso out of the >> tree and doing the development in private if that's the community >> desire.

[coreboot] Re: Discussing Controversial Upstreaming

Hi Martin, On 26.01.20 20:36, Martin Roth wrote: > While it's not my preference, I'm fine with pulling picasso out of the > tree and doing the development in private if that's the community > desire. When we're done, it can go in, or not, as the coreboot > community chooses. Because we can't

[coreboot] Re: Do we have a rule that code should be build tested?

Hi David, I'm a bit confused by some of your arguments, it just seems weird. So my apologies in advance if I misinterpreted you. On 26.01.20 19:46, David Hendricks wrote: Of course, there'll always be a gap when a new platform is added. We could make it a rule, though, that no commit

[coreboot] Re: Discussing Controversial Upstreaming

Hi David, On 26.01.20 20:15, David Hendricks wrote: > On Sat, Jan 25, 2020 at 4:44 PM Nico Huber wrote: >> There are currently two new platforms in development that seem to >> have trouble with public binaries (which would be necessary to make >> the code useful to t

[coreboot] Re: Do we have a rule that code should be build tested?

Hi Patrick, On 26.01.20 10:48, Patrick Georgi wrote: > Nico Huber via coreboot schrieb am So., 26. Jan. > 2020, 02:07: >> I've recently seen how much trouble it can cause when a whole new >> platform directory isn't hooked up for build tests. One has to double >> ch

[coreboot] Re: Mainboard porting assistance

Hi Bemjamin, On 26.01.20 07:51, Benjamin Doron wrote: > I'm using some code > (https://review.coreboot.org/c/coreboot/+/35523/55/src/mainboard/acer/aspire_vn7_572g/ramstage.c) > to set the GPIO pins. can you elaborate on that. How did you figure out the GPIO pins? why are you using this

[coreboot] Do we have a rule that code should be build tested?

Hello again, so, we have Jenkins that runs build tests on our master branch. That makes working together on a huge project much easier. However, do we have a rule that all the code should be build tested? and if not, should we establish one? I've recently seen how much trouble it can cause when

[coreboot] Discussing Controversial Upstreaming

Hello coreboot fellows, we've recently seen the deprecation of Intel/Broadwell-DE support because it turned out to be too proprietary to be maintained in the long run. With that in mind, shouldn't additions to coreboot that have high chances to suffer the same fate be discussed in advance? It

[coreboot] Re: No video output?

Hello Mogens, On 23.01.20 10:41, Mogens Jensen via coreboot wrote: > The guide is two years old, maybe something has changed in coreboot since > then, so more steps are required to get the video working? or maybe less steps are required. coreboot has an open-source graphics- init option for

[coreboot] Re: Increasing chip size - check my modifications please?

Hi Rafael, On 14.01.20 02:18, Rafael Send wrote: > *2)* Modify fmap - currently looks like this: > > ... > and it should become: > > FLASH@0xff80 0x100 {<- new chip size you should also lower the offset to 0xff00. The flash is (assumed) to be mapped right below 4GiB. So it should

[coreboot] Re: Mainboard porting assistance

On 06.01.20 00:34, Benjamin Doron wrote: >> well, you can boot with the vendor firmware, enable the discrete GPU >> and check in your OS (xrandr, for instance, I guess) where the display >> is connected. > > eDP? That's probably not very helpful to you, I'm sorry. Doesn't that just > say that

[coreboot] Re: Mainboard porting assistance

On 06.01.20 06:18, Benjamin Doron wrote: >> A couple of GPIOs do change when the dGPU is enabled or disabled. > > I'm astonished, but the GPIOs that I had saved seem to correspond to the dGPU > being disabled. I'll go through them again. I also saw one appear before and > two others disappear

[coreboot] Re: Mainboard porting assistance

On 05.01.20 20:26, Benjamin Doron wrote: > Alternatively, is https://review.coreboot.org/c/coreboot/+/31448 > (CONFIG_MULTIPLE_VGA_ADAPTERS) relevant? No, better ignore this option. It has very weird semantics (allows to overwrite one Option ROM with others, AFAICS) and was only ever used with

[coreboot] Re: Mainboard porting assistance

Hi Benjamin, On 05.01.20 19:30, Benjamin Doron wrote: >> Is this laptop using Nvidia Optimus? If so, the displays are only connected >> to the integrated GPU. > > I'm not sure, but the datasheet seems to suggest so, displaying exactly what > your conclusion was, that the display is connected

[coreboot] Re: libgxfinit + latest master gives "static noise" bootscreen (Windows)

ts in touch with is the framebuffer configuration, which is merely the resolution, stride and a pointer into gfx memory. It doesn't care how the hardware was set up to get there. Nico R On Sat, Dec 28, 2019 at 5:00 AM Nico Huber wrote: Hi Rafael, On 26.12.19 21:43, Rafael Send wrote: For the past m

[coreboot] Re: libgxfinit + latest master gives "static noise" bootscreen (Windows)

Hi Rafael, On 26.12.19 21:43, Rafael Send wrote: For the past month or two (I'm not actually sure WHEN it stopped working) I haven't been able to successfully boot (any) Windows installations using libgfxinit. libgfxinit just sets up a framebuffer, all the software compatibility depends on

[coreboot] Re: AMD AGESA board removals

Hi Denis, On 10.12.19 00:10, Denis 'GNUtoo' Carikli wrote: > On Mon, 9 Dec 2019 18:54:18 +0200 > Kyösti Mälkki wrote: > > [f2a85m-pro broken on master] >> Weird. Seems like I let the devicetree in a bit of a bad shape back >> in 2015. Try if this makes any difference: >>

[coreboot] Re: Enable non-NVME devices in M.2 slot?

Hi Rafael, On 07.12.19 07:40, Rafael Send wrote: > However, so far nothing I've done lets me detect the Sunix card if I try to > put it in the NVME slot using this adapter > . I would think it should just show > up under "lspci" like it does in the WiFi

[coreboot] Re: Sandybridge-M help request in setting up LVDS panel.

Hi Jose (sorry for the name mixup earlier), On 04.12.19 15:01, Jose Trujillo wrote: > The libgfxinit solution works! Nice! > What to do next? > I have a rough idea for an upstream solution: 1. Extend libgfxinit's API: Scan_Ports() could get an optional parameter with predefined configs,

[coreboot] Re: Build seems to have broken for asus/p2b-*

Hi Keith, On 04.12.19 01:19, Keith Hui wrote: > CREATE build/mainboard/asus/p2b-ls/cbfs-file.kMfK0Y.out (from > /usr/src/coreboot/.config) > make: *** [src/cpu/Makefile.inc:44: build/cpu_microcode_blob.bin] Error 1 > > That makefile line seems to indicate that some CPU microcode file is

[coreboot] Re: Sandybridge-M help request in setting up LVDS panel.

Hi Jorge, On 03.12.19 15:13, Jose Trujillo wrote: >>> This is my first try in booting coreboot on a LVDS panel. >>> This is a Sandybridge-M system using video option ROM and VBT extracted >>> from the original FW. >> >> if you ever want to get open-source gfx init running instead, let me know.

[coreboot] Re: Sandybridge-M help request in setting up LVDS panel.

Hello Jorge, On 02.12.19 18:02, Jose Trujillo via coreboot wrote: > Hello All! > This is my first try in booting coreboot on a LVDS panel. > This is a Sandybridge-M system using video option ROM and VBT extracted from > the original FW. if you ever want to get open-source gfx init running

[coreboot] Re: No framebuffer available until amdgpu driver is loaded

Hi Jorge, Am 12.11.19 um 15:12 schrieb Jorge Fernandez Monteagudo: > I have a little problem trying to get a vesa framebuffer when booting my > system. > I have the system with the original bios and the vesa fb working. These are > the > relevant dmesg traces: > > ... > > With the sytem and

[coreboot] Re: Copy-first platform additions (was: Re: Re: Proposal to add teeth to our Gerrit guidelines)

On 07.11.19 12:05, Nico Huber wrote: > 1. Few people seem to take the might of Git into account. We have a >tool that can significantly increase the efficiency of development >and can help to preempt bugs. But many people would accept a process >that breaks Git benefits

[coreboot] Re: Copy-first platform additions (was: Re: Re: Proposal to add teeth to our Gerrit guidelines)

Hi Patrick, thank you for your response. I really appreciate that somebody helps to clear things up. On 07.11.19 15:58, Patrick Georgi wrote: > On Thu, Nov 07, 2019 at 12:05:44PM +0100, Nico Huber wrote: >> 1. Few people seem to take the might of Git into account. We have a > G

[coreboot] Re: Copy-first platform additions (was: Re: Re: Proposal to add teeth to our Gerrit guidelines)

100, Nico Huber wrote: >>> Some of the mega patches are copies of a predecessor chip (with the >>> minimum amount of changes to integrate it in the build), that are >>> then modified to fit the new chip. >> >> Ack. I think that is a problem. If this procedure is

[coreboot] Copy-first platform additions (was: Re: Re: Proposal to add teeth to our Gerrit guidelines)

Am 05.11.19 um 20:23 schrieb Patrick Georgi: > On Tue, Nov 05, 2019 at 06:37:02PM +0100, Nico Huber wrote: >> I mean "rubber-stamping of *huge* commits". That huge that it is >> obvious that no review happened, e.g. 1k+ LOC copy-pasta. Also, the >> guidelines s

[coreboot] Re: Proposal to add teeth to our Gerrit guidelines

Tue, Nov 05, 2019 at 02:26:25PM +0100, Nico Huber wrote: >> So, we already have Gerrit guidelines [1]. While they are most often >> not worth a look (common sense usually is enough), some people like >> to be reminded of them regularly. The latter is pretty annoying and >> d

[coreboot] Proposal to add teeth to our Gerrit guidelines

you think? Of course, there are many other kinds of violations; feel free to bring more up. I just want to start the discussion. Nico [1] https://doc.coreboot.org/getting_started/gerrit_guidelines.html -- M. Sc. Nico Huber Senior Consultant SINA Software Development and Verification Divisi

[coreboot] Re: Any live usb for recovery flash coreboot?

Hi, On 31.10.19 09:48, da...@tutanota.com wrote: > After I press the power button, the screen is black, untill 30 seconds or > maybe even longer I can see the screen light up. (I guess it's waiting at the > grub menu but I can't see it) if Tianocore doesn't show anything, it's the Linux

[coreboot] Re: Coreboot FSP fails to initialize RAM - "Configuration not in POR table"

Hello Naveen, On 27.10.19 05:02, Naveen Chaudhary wrote: > Does this mean that there is a way in FSP to define custom settings(configs) > for DIMMs? In the FSP integration guide for BroadwellDE > (https://github.com/IntelFsp/FSP/tree/master/BroadwellDEFspBinPkg/Docs) I > don't see any relevant

[coreboot] Re: How to use crossgcc-i386 during make?

Hello Naveen, On 17.10.19 07:26, Naveen Chaudhary wrote: > As per the Wiki : https://www.coreboot.org/Build_HOWTO I did "make > crossgcc-i386". Now when I do make, I get compilation errors because my host > gcc verion is 4.3. In case I update the host gcc version is updated to some > later

[coreboot] Re: DIY debug Dongle

On 13.10.19 16:40, Tom Hiller wrote: > The wiki briefly mentions "usb_debug_io.c" with a link to an old trac > ticket.  Could a second device connected via usb only read the logs?  I > am curious on the feasibility of attaching an Android phone/tablet with > an app that could easily read coreboot

[coreboot] Re: Microcode update in coreboot on Intel HT enabled CPUs

On 08.10.19 09:50, Patrick Rudolph wrote: > 4. The "Bios Writers Guide" (Document Number 504790 / 550049) states > that microcode must be done on all threads, but synchronized between > sibling threads to only update one at a time. A minor correction: BWGs from Ivy Bridge on (including 550049)

[coreboot] Re: Mainboard porting assistance

Hi Benjamin, On 25.09.19 18:19, Benjamin Doron wrote: > Alternatively, how would I get the display working? > You should try libgfxinit [1], it's usually much easier to get running than the GOP or VBIOS. At least you can tell from the log what it is doing. With CONFIG_DEBUG_ADA_CODE it gets very

[coreboot] Re: Fixing Hidden PCI devices on Intel common SoCs

On 26.09.19 18:45, Aaron Durbin via coreboot wrote: > Here's some of the requirements/issues we should resolve that come to mind: > > 1. Easy way to directly retrieve a device's chip config object w/o > traversing the device hierarchy. Which leads to... > 2. Symbol alias for accessing struct

[coreboot] Re: Fixing Hidden PCI devices on Intel common SoCs

On 27.09.19 15:42, Kyösti Mälkki wrote: > On Thu, Sep 26, 2019 at 7:45 PM Aaron Durbin wrote: >> >> On Thu, Sep 26, 2019 at 10:06 AM Kyösti Mälkki >> wrote: >>> Should be easy enough to implement >>> platform hook telling to not remove PCI device node from topology >>> links (based on BDF),

[coreboot] Re: Abandoned add asus p2-99 board patches

Hi Branden, On 21.09.19 21:28, Branden Waldner wrote: > I meant to retest and comment on the change sets on gerrit (22977 and > 22965) before they got abandoned, but got around to it too late. looks like the code was actually accepted but somebody didn't like the commits (I somewhat agree,

[coreboot] Re: AMD AGESA maintenance and/or deprecation

On 12.09.19 18:42, Patrick Georgi wrote: > On Thu, Sep 12, 2019 at 07:20:49PM +0300, Kyösti Mälkki wrote: >> Would "some people" or these "advocates" be willing to elaborate? > I CC'd Nico and Martin because I seem to remember that we talked > about AGESA (and its quality and/or life cycle). Nico,

[coreboot] Re: What are splitted / several flash ROMs about?

Hi Philipp, there is some documentation you might have missed [1] (can't blame you, the index is broken [2]). On 18.09.19 23:23, Philipp Stanner wrote: > Am Montag, den 16.09.2019, 07:20 -0700 schrieb Stefan Reinauer: >> Yes, this is often done as a cost reduction method. The habit started >>

[coreboot] Re: RAM init failing with some DIMMs on GM45 with "Timing overflow during read training."

On 17.09.19 17:28, Denis 'GNUtoo' Carikli wrote: > On Tue, 17 Sep 2019 10:21:38 +0200 Raw card type:D > Is there more information on such "card type" somewhere? JEDEC specifies these reference cards. Sometimes you can get their specification for free (need to register to their webpage,

[coreboot] Re: Boot loop on Thinkpad X200/GM45 with master.

Hi Denis, > I've a reboot loop on master on the Thinkpad X200. did you try it yet without the EHCI debug? if the reset happens after 4~5s, it might be the watchdog (which seems to be enabled for ICH9). Nico ___ coreboot mailing list --

[coreboot] Re: RAM init failing with some DIMMs on GM45 with "Timing overflow during read training."

Hi Denis, >> Raw card type:D last time we encountered problems with type D DIMMs, we concluded that it's not supposed to work [1]. Can you confirm if your DIMMs are stable with the vendor BIOS? We should probably issue a warning when type D is installed. Nico [1]

[coreboot] Re: New to coreboot. Need pointer to startup sequence

Hello Edward, On 01.08.19 18:32, edward.l.william...@boeing.com wrote: > I have a need to insert some experimental code (never to be checked in) just > before the ECC RAM is initialized. The customer wants a specific test to be > done before the ram is zeroed out. when you say "just before",

[coreboot] Re: Question how to write protect flash

Hi, for the X220, there should be related options in the "Chipset" menu of the coreboot configuration: "Lock down chipset in coreboot" "Flash locking during chipset lockdown" On 14.07.19 23:21, Public Email Account via coreboot wrote: > It seems that flashrom is able to flash the bios

[coreboot] Re: Suggestion Computer-On-Module implementations

On 09.07.19 08:57, Frans Hendriks wrote: > Variants can be used for mainboards. The variants are used for boards within > the same mainboard manufacturer directory. > Computer-On-Module (COM) can be used on different carriers which do not have > same manufacturer. > > Proposal is creating a COM

[coreboot] Re: Suggestion Computer-On-Module implementations

On 09.07.19 12:41, Patrick Rudolph wrote: > Hi Frans and Felix, > > On 2019-07-09 11:56 AM, Felix Held wrote: >> Hi Frans! >> >>> Proposal is creating a COM directory ‘src/com’ where the module >>> manufacturer and module name are used. (Similar to mainboard). >>> In this src/com directory common

[coreboot] Re: Does NSA contribute to Coreboot?

On 24.06.19 17:17, ron minnich wrote: We're reviewing the STM code, of course. If you're going to worry about something, worry about FSP 2.0 still being closed source. FSP is not optional and we have no idea of all the things it does/can do. You are saying this as if it would be magically

[coreboot] Re: Does NSA contribute to Coreboot?

On 23.06.19 12:04, Hubert Ruch wrote: On 6/23/19 12:00 PM, Stefan Reinauer via coreboot wrote: Remember that the project was started by Los Alamos National Labs (LANL), the guys that also brought you the Manhattan Project. Contributions have also been made by the BSI (German version of the NSA)

[coreboot] Re: More coding style change proposals

On 20.06.19 17:26, ron minnich wrote: > clang-format is not a textual preprocessor. It is basically the ast > builder of followed by output. > > So in your case, I just tried it > main() { > > if (foo) > bar(); > baz(); > } > > and got the right thing, i.e. braces around bar but not baz.

[coreboot] Re: More coding style change proposals

On 20.06.19 18:12, Jacob Garber wrote: > What Ron said, plus if I recall Coverity has a lint for misleading > indentation, so > I don't think there are any current instances of this in the code base. In > fact, > GCC even has -Wmisleading-indentation that was added to -Wall in GCC 6, so we >

[coreboot] Re: More coding style change proposals

On 20.06.19 06:01, Jacob Garber wrote: > On Wed, Jun 19, 2019 at 08:38:14PM -0700, ron minnich wrote: >> Given the number of serious problems that lack of braces causes, I >> like this proposal. It's indicative that both Rust and Go require the >> {}, for reasons of safety. > > There was a famous

[coreboot] Re: BUG: Seabios choose the wrong option rom when two are available

Hello akjuxr3, as you seem to have a SeaBIOS issue, did you try the SeaBIOS mailing list? Might be easier to get an answer there. I don't use SeaBIOS, but have a guess: The integration of SeaBIOS into the coreboot build system is not meant for anything but the simplest configuration. In your

[coreboot] Re: Chainloading Windows from a Linux Payload

On 09.06.19 20:53, Matt B wrote: > It is possible through u-root support for multiboot images [1] to chainload > grub? Yes, I would think so. But in case we are still on topic: It won't help you to boot Windows (unless you also implement UEFI services in your LinuxBoot and use a UEFI GRUB). To

[coreboot] Re: MRC cache save/readback failure (SKL/KBL)

On 07.06.19 16:24, Alex Feinman wrote: Indeed this was it. I had a mismatch between the IFD and FMD. As a result my MRC cache was in the IFD ME region. Obviously the mapper masks ME region. I think I also have a problem with ME being too large for 16 MB chip (it's 10 MB alone). I might have to

[coreboot] Re: MRC cache save/readback failure (SKL/KBL)

Hi Alex, On 07.06.19 08:56, Alex Feinman wrote: I've checked the upper 16 MB - simply dumped the block at 0xff9f (0xff00 is the last 16 MB + MRC cache region offset 0x9f from the layout file ) where in my image the MRC cache region resides (I can confirm it's there by dumping the

[coreboot] Re: MRC cache save/readback failure (SKL/KBL)

Hi Alex, On 06.06.19 18:43, Alex Feinman wrote: If the boot_device_ro from mmap_boot.c is being used, I don't see how the flash content gets mapped into top of the 4GB space. In case of Apollo Lake, there is a special implementation. But for the rest of x86 there is nothing. Is there

[coreboot] Re: libpayload/i8042/keyboard: ERROR Keyboard reset failed when selecting Secondary Payload in SeaBIOS

Hi, I've send a revert for review: https://review.coreboot.org/c/coreboot/+/33244 It seems to me that the added reset isn't following the protocol (i.e. ignores another returned byte). I'm not familiar with these controllers and lack the time to look into it right now. So that's the best I can

[coreboot] Re: How would an open source vgabios work?

Hi Matt, TL;DR you can simply compile a VGA BIOS with GCC/Clang. You don't have to make the same mistakes as AMD and compile/interpret some byte code. Which, IMHO, would only make it harder to implement an open-source version. On 05.06.19 02:38, Matt B wrote: I'm not talking about replacing a

[coreboot] Re: MRC cache save/readback failure (SKL/KBL)

Hi Alex, On 04.06.19 22:27, Alex Feinman wrote: In my Coreboot build (derived from kblrvp configuration) based on 4.9 label I am seeing that MRC test is run on every boot. From what I can tell, what happens is: 1) On first boot the MRC cache is not found (correct). MRC test is done and the MRC

[coreboot] Re: How would an open source vgabios work?

Hello Matt, On 04.06.19 22:21, Matt B wrote: Pretty much all AMD GPUs (both integrated and otherwise, including PCIe cards) rely on vgabios blobs for init and to support the driver(s) > From what I've heard, the people writing open source drivers for these GPUs really don't want to deal with

[coreboot] Re: Starting the coreboot 4.10 release process

On 03.06.19 16:13, Mike Banon wrote: Just noticed that someone included i.e. some Purism Librem devices to a " Recently tested mainboards: " section - but, when I check https://review.coreboot.org/cgit/board-status.git/log/purism , the latest board status for Purism happened even before 4.9 !

[coreboot] Re: Bring Microcode updates in CBFS .bin format

Hi, Am 17.05.19 um 10:45 schrieb Kinky Nekoboi: > can somebody explain to me howto how the scripts in > 3rdparty/blobs/cpu/intel/microcode/ alter the microcode. the current scripts assume that the updates are shipped in some ASCII hex form. This changed long ago. Have a look at this patch that

[coreboot] Re: Are AMD CPUs as researched as Intel ones (was Re: New Intel microcode release for migiating ZOMBIELOAD FALLOUT AND OTHERS)

On 15.05.19 17:59, Ivan Ivanov wrote: > Yes, the people are checking AMD as well, and discovered the > AMD-specific vulnerabilities at their PSP Platform (IN)Security > Processor. Unless I missed something about the PSP, I fear, we are talking past each other. Not only is the PSP a completely

[coreboot] Re: Are AMD CPUs as researched as Intel ones (was Re: New Intel microcode release for migiating ZOMBIELOAD FALLOUT AND OTHERS)

On 15.05.19 17:37, Ivan Ivanov wrote: > Hi Nico, when someone finds a vulnerability at Intel, people do a good > digging for a similar vulnerability at AMD. I don't doubt it. But did somebody try to find AMD-specific vulnera- bilities? Checking if somebody else did the same errors is not the same

[coreboot] Are AMD CPUs as researched as Intel ones (was Re: New Intel microcode release for migiating ZOMBIELOAD FALLOUT AND OTHERS)

Hi Ivan, On 15.05.19 17:11, Ivan Ivanov wrote: Funny vuln names! Luckily AMD (as usual?) is not affected... As someone wrote at the forums, a hidden price for Intel higher performance is a holey pants, just for 120 fps in games instead of 110 :P Neglecting security for the purpose of performing

<    1   2   3   4   5   6   7   8   9   >