In this thread https://firstname.lastname@example.org/thread/FT... we found a bug in seabios. Its choosing the wrong option rom in the case when for example on a Intel G41 board you have the internal Intel GPU and have added a external PCIe GPU. Then coreboot switches over to the external GPU for the graphical output but seabios use the option rom for the Intel G41 GPU. In case of x4x/G41 this results in no ability to have a graphical boot mode and thus its not possible to boot some linux live images.
In the linked thread a workaround is been found: "In the "Devices" menu of coreboot, set "Graphics initialization" to "None" ".
This breaks the functionality to have coreboot output with the internal GPU when you pull out the PCIe GPU. The switch should happen automaticly and without the need to recompile/reconfigure coreboot. Changes like https://review.coreboot.org/c/coreboot/+/18504 was made to make this happen.
Would be great if this seabios issue could be fixes.
Recently I had an interesting discussion with a system administrator
who is responsible for several hundred PCs, Routers etc.
His argument was: Imagine it would take you 15 minutes to install a
patch on a computer (all windows machines of course...). If your
company has 1000 computers and you send one admin to install the
patches, it will take him >31 work days, working 8h a day.
That's why, he said, companies are interested in software allowing them
to install stuff on the OS / hard drive remotely through the firmware
I, not dealing with large networks, had never thought about it this
way. But it does make a lot of sense to me, it's about real money (as
So I guess that's indeed a huge reason why Intel and AMD created
Frankenstein, running below UEFI and Kernel. It probably doesn't
explain so much why it's necessary to disallow you switching IME off or
why it needs control about absolutely everything, but that's a
So I'm wondering: What would you do about this reality? Could there be
a different solution other than software in Ring -1 having its sausage
fingers on everything?
Sure, the programmers in a company could install their stuff on their
own, but the office folks, the HR and PR guys and the lawyers? Hmm.
And whether we like it or not, even awesome companies almost
exclusively supply their employees with windows machines and they just
demand solutions allowing their IT-departements to fix everything as
cheap and as easy as possible
I am Shubhendra Pal Singhal, currently third year in Computer Science at
NIT Trichy, India. I wish to apply for Google Summer of Code. I looked into
the profile of coreboot 4.9 and found out the project idea "*Port payloads
to ARM, AArch64, MIPS or RISC-V*" to be very interesting.
I have worked in the similar field on *RISCV architecture at IIT Madras
where I helped in porting real time OS eChronos*, on RISCV architecture. I
will be undergoing a *project in Embedded systems offered by USC Los
Angeles in solving the SAT Solvers using OS and Digital Logic*.
Furthermore, I am currently working on a *long term project with under
Prof. N.Ramasubramanium on the AI chip* where we are trying to solve the
processing speeds by efficiently reducing the number of writes in the cache
for faster access. I am also *undergoing Microcontrollers and
Microprocessors* as my core subject in my current semester and have
OS, Real time Systems* in my B.Tech IV semester.
I have included my further details in my Linkedin : *
I want to contribute to the open source community in the field of Operating
Systems and this can prove to be an excellent platform for gaining
experience in field of systems. This opportunity can pave my career,
towards applied research in the field of Systems.
*While browsing through the link, I saw the mailing list assigned for the
project. It would be very useful if you could guide me as to what is
expected in the project proposal and how can I serve the open source
community in the best possible way. *Any guidance would be very useful and
I hope to receive a reply soon. Thanking you for your time and
Shubhendra Pal Singhal
National Institute Of Technology, Trichy, India
Phone number : +91 9787888015
Email-id : shubhendrapalsinghal(a)gmail.com
Linkedin : <https://www.linkedin.com/in/shubhendra-singhal-7378a9131/>
I am wondering what is the format of CPU-DRAM DQ byte map for FSP-M
configuration. Typically there are 64 DQ lanes per non-ECC SODIMM/DIMM
(correct me if I'm wrong) for DDR4 for example. But the DQ map is an
2x12 array, so I assume 12 bytes for each channel (why not 8 bytes?). My
1. Why there are more bytes in array than DQ lanes?
2. How should I define the DQ map? Does 0xFF or 0x00 mean 1 to 1 mapping?
3. Some FSP2.0 mainboards have values like 0x0F and 0xF0 in their
mappings which looks like 1 byte swap, but there are also 0xCC and 0x33.
What is the difference?
The DQS mapping is clear to me (rather obvious as there are only 8 DQS
which matches the 2x8 array).
I know about 3 Rcomp resistors of the chipset and what they are for, but
what RcompTarget is?
In the code I can see function `mainboard_fill_rcomp_strength_data` and
begin to wonder what rcomp strength is (not Rcomp Target?). How to
correctly fill RcompTarget FSP-M configuration?
Any tips and pointers appreciated.
http://3mdeb.com | @3mdeb_com
I am a student interested in contributing to coreboot as part of GSoC 2019.
I have seen the ideas list on the documentation page, and I am considering
working on fixing issues reported by Coverity Scan, and maybe additional
work on firmware RE tools. However, I would like to know if ports to new
mainboards/systems would be an acceptable project. I have an Ivy Bridge
desktop (Gigabyte GA-Z77X-UD5H) as well as a Arrandale laptop (HP Pavilion
dv7), and I am interested in porting coreboot to these platforms. I do have
some experience with UEFI programming in C (as well as x86(_64) ASM).
I'm new to coreboot, and I'm trying to port it to the Dell Latitude E6400. It is fairly similar to the Thinkpad T400, so I thought this would be a relatively easy first project. I currently have all code copied from the T400. Right now I'm working on the devicetree.cb, but I can't seem to figure out exactly what everything means and what to set it to. Some things, like device, chip, and subsystemid are fairly obvious, but other things, such as register and ioapic_irq are less so.
I understand what register does, I just don't know where to get the values I should set them to, such as for gfx.did and pirqa_routing.
I have no idea where to find what values go into ioapic_irq
Can someone point me in the right direction?
If I theoretically had a flash chip that was larger than 128Mb, it requires
3-4 byte addressing.
Does / could coreboot support such large memory, or would the limitation
live somewhere else in the system?
I am Daniel, a computer engineering student at the National University
I am interested in extending Ghidra to support the analysis of
firmware images. However, I am unsure whether this would be a
sufficiently big project for GSoC, and whether I should have an
additional one. If that's the case, I would like to also work on
porting the GRUB2 payload to the RISC-V architecture.
Apart from that, to familiarize myself with the code review process of
coreboot, I have made a simple change to cpu/ti/am335x, fixing
warnings from checkpatch. May I know who can I add to review it? The
patch can be found at https://review.coreboot.org/c/coreboot/+/32119 .
Last but not least, may I ask for the scope of GSoC, should I ask
questions more on the mailing list or IRC?
I am looking forward to learning from you all. Thanks.
I overeagerly reviewed and submitted a change lately, that set the
column limit for our C code to 96. My reasoning was that we already
live a "soft" limit of 80 chars and that tools shouldn't complain about
every single 8x-chars line (personally, I find this quite annoying
during review). What I missed is that people use the limit to format
code automatically, resulting in less line breaks, even if they'd make
sense for readability.
I don't want to start a discussion about line length here! If we are
going to use tools for automatic formatting, we will be limited by the
tool's capabilities. So it doesn't make any sense to discuss rules
before we know if our tools will allow us to follow them.
So what we should discuss first: if we want to let tools format our
code for us. I'll just note some questions/ideas for now. Will try to
have an opinion on them later. They are not all mutually exclusive.
Do we want to enforce a single editor / IDE + configuration for coreboot
contributions? For instance, Vim is quite configurable and helpful when
writing code. This could make all tools for later processing unneces-
Do we want to enforce a single tool, e.g. clang-format, that does the
job for us after editing a source file?
The above, even if that implies a new coding style that we might not
be used to?
Do we want a combination of such a tool and check-patch? For instance,
clang-format has a feature to ignore broken lines. This could then be
handled by check-patch, to allow more complex rules.
Do we just want to keep check-patch and let authors / their editors
format the code?
Do we want to rely (solely) on reviewers for format checking?
Do we want to encourage reviewers to educate their fellows on code
style (for instance, wrt. line length, less indentation levels, shorter,
more meaningful identifiers, etc.)?
trying to figure out in which ways clang-format is (supposed to be)
hooked up in our git-hooks. And what role it plays, yet.
There is a lint test, that so far never did something for me because
it relies on a `.clang-format-scope` file (that is not in the tree?).
Still, this check seems to be actively maintained.
And also a `util/lint/check-style` that is only hooked up if you run
`make git-config` recently (I didn't, so I'm a little surprised). This
one doesn't have a scope file, it seems?
What does each of these checks do?
Did anybody ever use the scope file? Is it used downstream somewhere?
Same as with `check-patch`, I believe we need either a white or black
listing. Imagine you'd try to work on superiotool and clang-format
(with its coreboot config) is run on that.