Is there any chance to get this trivial commit merged?
I've added description of missing payloads and links to
Low priority, but would be nice to have.
Hi coreboot folks,
I've just pushed a small RFC commit for our coding style:
From the commit message:
It seems since the increase of the code line length to 96 chars, many
developers felt encouraged to increase the line length of running text
as well. However, text blocks wider than 72 chars are generally harder
to read. Let's try to add a sane rule about it.
+This does not apply to running text, e.g. block comments. For text
+blocks, the usual limit of 72 chars is strongly encouraged to increase
+readability. This may be counted additionally to any indentation, but
+the overall line length should not exceed 96 chars.
So, that's what it's about. I'd like to see all sorts of opinions on the
matter. Maybe there is a reason to deviate from common typesetting rules
that I just don't see yet. Generally, I'd prefer to not treat all text
I'm currently trying to get EC to host memory mapping (H2RAM-HLPC) working on a
Clevo L141CU. This will be used by ACPI for the EC ram OpRegion. The EC is an
ITE IT5570E. If you don't have access to the datasheet, look for IT8528 or
similiar, which is mostly identical irt. memory mapping registers (and many
On vendor firmware, I can access the two EC ram regions at addresses 0xfe700100,
0xfe700380 via /dev/mem (using dd or memtool md 0xfe700100+0x100 for example).
The PCH LGMR register has the value 0xfe700001. The address is within the PCH
reserved range (0xfc800000-0xfe7fffff).
Possible addresses are 0xf[ef]XX_X000, according to the datasheet. Free/unused
ranges on CNP should be 0xFE036000-0xFE0AFFFF, 0xFE0D0000-0xFE0FFFFF,
0xFE400000-0xFE5FFFFF and 0xFE600000-0xFE7FFFFF (temp address range for FSP), so
there shouldn't be any conflict.
EC/superio registers are set as follows:
HCTRL2R (0x1036) = 0x80 -> HBREN = 1 -> "1: The host memory cycle is decoded"
HRAMWC (0x105A) = 0x03 -> H2RAM memory cycles, H2RAM window 0 and 1 enabled
HRAMW0BA (0x105B) = 0x10 -> window 0 starts at 0x100
HRAMW0BA (0x105C) = 0x38 -> window 1 starts at 0x380
HRAMW0AAS (0x105D) = 0x04 -> window 0: no read/write lock, size = 256 bytes
HRAMW1AAS (0x105E) = 0x03 -> window 1: no read/write lock, size = 128 bytes
SIO LDN 0x0f:
0xF5 = 0x00 -> HLPCRAMBA[15:12] = 0x00
0xF6 = 0x70 -> HLPCRAMBA[23:16] = 0x70
0xFC = 0x00 -> HLPCRAMBA[32:24] = 0xFE
-> LGMR address is 0xfe700000
The EC registers are initialized by the EC firmware. No change was needed. The
superio registers hand to be configured after enabling the logical device.
Unfortunately, mapping doesn't work with coreboot for unknown reasons. Dumping
the region only returns 0xff's.
I tested both, reading in coreboot and on Linux, just to be sure there's no OS
ressource issue. I also tried to change the mapping address. While I
successfully tested changing the address to various values on vendor fw by
changing LGMR and the SIO registers (0xfe0b0000, 0xfe701000, 0xfe701000,
0xfE600000, ...), I had no success with coreboot.
I was able to dump the EC ram windows through the I2EC data/index programming on
both vendor fw and coreboot, so I am sure, the ram windows are initialized and
filled with sensible data.
Any ideas, what could be wrong here?
Michael / c0d3z3r0
when announcing today's leadership meeting on IRC I got some replies to the
tune of "oh no, Google!" as the meeting minutes are recorded on Google Docs
and the meeting itself is held using Google Meet.
Note that both are set up to be usable without a Google account, so the
impact on users should be limited.
That said, if that's a real concern that prevents people from participating
who otherwise would like to chime in, we need a solution. To avoid spending
too much time on something that may not actually be a problem, I'm asking
1. To consider if you care about the leadership meeting (otherwise, please
don't create extra work to prove a point about "big tech", software
licenses or whatever)
2. If using these two tools for this specific purpose is a problem for you
3. What your ideal alternative solution would look like
4. How your solution would be implemented
5. Present the result of 4 to the list :-)
Note that this project, its developers, contributors and maintainers aren't
in the business of managing servers or communication suites (although we
spend a fair amount of time and money on running coreboot.org to ensure
people can contribute with little restrictions: apart from that meeting,
everything we do is self-hosted!) so a proposal should be low maintenance
This means: running the meeting must not be a hassle (we tried a fair
amount of open tools for running the calls: jitsi, mumble and several
others, and they fell flat, for example because they sent video streams
from everybody to everybody. n^2 traffic growth isn't great), available for
the long term (if you offer to run the necessary services for us that's
nice, but we'd prefer not to have to change routines again 3 months down
the road because your priorities shifted, so any such offer should give us
the impression that it's available for the foreseeable future) and not just
exchanging one "troublesome" vendor for another (I guess we'll see what
"troublesome" means to people in the community.)
As for capacity: The meetings take one hour every 14 days. Today's meeting
had 17 participants and I think some meetings had a few more folks joining.
Those are discussions not presentations, so high-latency streaming options
(such as PeerTube's new live stream feature) won't work.
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
I read on Coreboot webpage that this board is in almost full working state https://doc.coreboot.org/mainboard/asrock/h110m-dvs.html .
The CPU supported by this board is Kaby Lake which is quite fast for applications. I have a question about the flash chip. The documentation says the flash chip is Macronix MX25L6473E, but is putting in w25q64fvaig flash chip will work too? What about other similar chips, such as GD25B64BPIG?
Also, for this board, there are a few variants Asrock Intel H110M-DGS, -DVS, and -HDV. Can I use -DGS for this board?
In the documentation, integrated graphics init with libgfxinit (see Known issues) , and VGA is not working. In summary integrated graphics not working, but if I put on a PCIe graphic card, coreboot will work?
Also, for this line: I should fill in the actual macaddress
./util/scripts/config --set-str REALTEK_8168_MACADDRESS "xx:xx:xx:xx:xx:xx"
For this line, what does this line do? make olddefconfig
Thank you so much,
I search on the internet about coreboot and Qubes os.
I use a Lenovo ThinkPadT460P i7 16 gb and i have install Qubes OS.
Is there a compatible version of Coreboor for a Lenovo ThinkPadT460P i7. I
found the X220 and X230.
I previously wanted to port coreboot to my machine. But due to the lack of
FSPs, specially the MRC.bin for Cedar trail platforms, I couldn't do it.
But, I have recently found the source code for an Intel Cedar trail bios.
It is actually an AMI bios source code. It has a huge amount of very
useful information like Memory Init, Power management etc. And has almost
everything open source except the EC. I want to ask how can I use it to add
support for coreboot to Cedar trail? Is it possible to use at least the
memory init and the FSP alternatives from the source code? I can share the
code archive if you need to have a look at them
I'm writing this email because there's one thing I always forget
about. Now that I am sure about it, I would like to write it down
somewhere so that I can't forget about it anymore. Anyway, that one
On Intel memory controllers, one QCLK (Quadrature Clock) equals one
half of a full clock cycle, i.e. tCK / 2.
Angel, the tormentor of memory controllers