Re: [coreboot] cbfs alignment
On Friday, July 17, 2015 03:32:43 PM Aaron Durbin wrote: On Fri, Jul 17, 2015 at 3:27 PM, ron minnich rminn...@gmail.com wrote: bummer. We're going to have to add marshalling code to cbfs, to copy Ya. You'd need to fix cbfs as well is my guess. Not really. It's OK to be extra careful when generating the CBFS headers, but it's also nice to have a clean simple format that can be easily parsed from assembly (haven't we seen that before?). Long term, we might want to look at the benefits of consolidating the table format. At the very least, we shouldn't care enough about how gcc aligns things, that there's a multi-line comment about it. pointers from the architecture we're on to the architecture we're on, which was compiled by gcc for the architecture we're on, compiled on the architecture we're not on, to conform to rules for an architecture we're not on. goodbye, a = b hello, memcpy(a, b, sizeof(a)); barf. Ya. And since this is C it makes for some really annoying work. Now if you write a spec that can be processed by a machine for all these serialized structs we could generate code based on the CPU's constraints. Well, similar schemes exist already (see nanopb). Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] HP Pavilion dv7-6025eo support?
On Monday, April 13, 2015 05:07:18 PM Peter Stuge wrote: pub...@autistici.org wrote: Can support be added for Hewlett-Packard's Pavilion dv7-6025eo laptop computer? Details: Probably yes, but nobody will do it for you. You're making some implicit assumptions here. Of course someone else will do it, for the right amount. Please don't assume people only come asking, and never giving. You'll need good development and debugging tools and 6-60 man-months of work depending on your background. +1 //Peter Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [GSoC] End user flash tool - GUI framework/library
On Thursday, March 26, 2015 07:44:24 PM Łukasz Dmitrowski wrote: Hello, Hi To provide easy and clear interface for end user flash tool(http://www.coreboot.org/Project_Ideas#End_user_flash_tool) I plan to implement GUI with use of Qt framework. I decided to go with Qt I think Qt is a very good choice. I tried wxWidgets once, but did not like it. Most people that I know who tried it didn't like it that much. I don't blame you. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] B point
On Thursday, March 26, 2015 07:43:26 AM Kushagra Kumar wrote: Which is the best Linux based os to be worked on with coreboot? Fedora -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot meeting this summer!
On Thursday, March 12, 2015 07:29:00 PM Peter Stuge wrote: Stefan Reinauer wrote: I would like to organize a coreboot project meeting in San Jose, California this summer. .. If you are interested in joining this summer, if you have ideas, or concerns, please contact me Chances are June will not work for me. I think many individual contributors can't afford cross continent travel. Even if funding would be available I think travel to the US is unattractive for very many. All meetings thusfar have been in Europe. Take a little give a little. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Has anyone seen RTD2132 DP2LVDS converter configuration via DPCD
So, as I was iotracing atombios execution from within linux. The hardware connection is pretty straightforward: AMD Trinity DP0 - RTD2132 - LVDS panel. I noticed a set of very interesting DPCD accesses [1], to registers marked as RESERVED for Branch device usage by the Display Port spec. Looking carefully at how those accesses are done, it seems 0x5f0/0x5f1 are a big-endian index port, and 0x5f3 is the data port. Most likely, these lead to some internal register space of the RTD2132. Whether this is the same as the I2C space or not is unknown at this time. So, for those of you who had worked with this chip before, do these accesses look familiar? I wasn't able to find any sources that mess with the RTD2132 on the DPCD level. Alex === Appendix [1]: RAW DPCD channel transactions === 0x5f0 - 0x00, 0x02 0x5f2 - 0x20 0x5f0 - 0x00, 0x03 0x5f2 - 0x31 0x5f0 - 0x00, 0x05, 0x3d 0x5f0 - 0x00, 0x1f, 0x03 0x5f0 - 0x00, 0xba, 0x00 0x5f0 - 0x00, 0xbb, 0x08 0x5f0 - 0x00, 0xb1, 0x4b 0x5f0 - 0x01, 0x73, 0x69 0x5f0 - 0x01, 0x9f, 0x24 0x5f0 - 0x00, 0x19, 0x33 0x5f0 - 0x00, 0x89, 0x39 0x5f0 - 0x00, 0xf8, 0x42 0x5f0 - 0x00, 0xf9, 0x01 0x5f0 - 0x00, 0xfa, 0x23 0x5f0 - 0x00, 0xfb, 0x45 0x5f0 - 0x00, 0xfc, 0x67 0x5f0 - 0x00, 0xfd, 0x89 0x5f0 - 0x00, 0xfe, 0xab 0x5f0 - 0x00, 0x1d, 0x25 0x5f0 - 0x01, 0xc3, 0x07 0x5f0 - 0x01, 0xc2, 0x5a 0x5f0 - 0x01, 0xc4, 0x03 0x5f0 - 0x01, 0xc0, 0x07 0x5f0 - 0x01, 0xc1, 0x5a 0x5f0 - 0x01, 0xb1, 0x03 0x5f0 - 0x01, 0xbf, 0x7d 0x5f0 - 0x01, 0xb5, 0x63 0x5f0 - 0x01, 0xcb, 0x80 0x5f0 - 0x01, 0xb3, 0x66 0x5f0 - 0x01, 0xb2, 0x9a 0x5f0 - 0x00, 0x9f, 0x00 0x5f0 - 0x01, 0x83, 0x14 0x5f0 - 0x00, 0xa7, 0xc2 0x5f0 - 0x01, 0x71, 0x12 0x5f0 - 0x01, 0x82, 0x5d 0x5f0 - 0x01, 0x89, 0x28 0x5f0 - 0x01, 0xbe, 0x01 0x5f0 - 0x00, 0x8a, 0x53 0x5f0 - 0x00, 0x0a, 0x01 0x5f0 - 0x01, 0xd4, 0x10 0x5f0 - 0x00, 0xf3, 0x00 0x5f0 - 0x00, 0xf4, 0x3c 0x5f0 - 0x01, 0xb4, 0x06 0x5f0 - 0x00, 0xdc, 0x00 0x5f0 - 0x00, 0xdd, 0x00 0x5f0 - 0x01, 0x91, 0x20 0x5f0 - 0x00, 0xd1, 0x06 0x5f0 - 0x00, 0xd6, 0x01 0x5f0 - 0x01, 0xd2, 0x08 0x5f0 - 0x01, 0xd3, 0x80 === Appendix [2]: Presumed accesses to RTD2132 internal register space === READ: 0x0002 - 0x02 READ: 0x0003 - 0x31 WRITE: 0x0005 - 3d WRITE: 0x001f - 03 WRITE: 0x00ba - 00 WRITE: 0x00bb - 08 WRITE: 0x00b1 - 4b WRITE: 0x0173 - 69 WRITE: 0x019f - 24 WRITE: 0x0019 - 33 WRITE: 0x0089 - 39 WRITE: 0x00f8 - 42 WRITE: 0x00f9 - 01 WRITE: 0x00fa - 23 WRITE: 0x00fb - 45 WRITE: 0x00fc - 67 WRITE: 0x00fd - 89 WRITE: 0x00fe - ab WRITE: 0x001d - 25 WRITE: 0x01c3 - 07 WRITE: 0x01c2 - 5a WRITE: 0x01c4 - 03 WRITE: 0x01c0 - 07 WRITE: 0x01c1 - 5a WRITE: 0x01b1 - 03 WRITE: 0x01bf - 7d WRITE: 0x01b5 - 63 WRITE: 0x01cb - 80 WRITE: 0x01b3 - 66 WRITE: 0x01b2 - 9a WRITE: 0x009f - 00 WRITE: 0x0183 - 14 WRITE: 0x00a7 - c2 WRITE: 0x0171 - 12 WRITE: 0x0182 - 5d WRITE: 0x0189 - 28 WRITE: 0x01be - 01 WRITE: 0x008a - 53 WRITE: 0x000a - 01 WRITE: 0x01d4 - 10 WRITE: 0x00f3 - 00 WRITE: 0x00f4 - 3c WRITE: 0x01b4 - 06 WRITE: 0x00dc - 00 WRITE: 0x00dd - 00 WRITE: 0x0191 - 20 WRITE: 0x00d1 - 06 WRITE: 0x00d6 - 01 WRITE: 0x01d2 - 08 WRITE: 0x01d3 - 80 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Superfluous commit messages from gerrit
So I was looking at our git log. I can fit two, maybe three commits if I'm lucky. It's terrible. We have all this redundant information. We have both Reviewed-on and Change-Id lines. Those only point to the same resource. The Tested-by is useless. It's always Jenkins who tests changes. Then you have a Reviewed-by for every person who ever bikeshed on said patch. Since Paul has to say something on every single patch, he always has his own line in almost every commit. Reviewed-by is not the same as Acked-by. I've seen acked-by used to let linux folks know that some maintainer/big guy with more credentials than the author already likes the patch. Though Acked-by is not necessary, even for linux. Come to think of it, the only piece of information needed to find a commit on our gerrit is the hash. All the other lines, except for the Signed- off-by are redundant. Reviewed-on and Change-Id will take you to the same place as the commit hash. All the crap added by gerrit is redundant. Now add a patch that comes from our Chromium friends, and you've doubled the size of said pork. Is it convenient to have all that information in the commit message? Maybe. Is it necessary? Definitely not. Those lines are useful for tracking a patch, but once it's +2'd and submitted, gerrit should strip out all that pork. We might not even use gerrit anymore a few years down the road. Adding all this crap is pointless. It's time to drop the crap. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Getting more useful patterns out of replay logs
I want to convert a replay log to something that looks more structured, and easier to parse through mentally. I've tried to use coccinelle, but I came across a couple of problems. First, the file is over 13000 (thirteen thousand) lines long, and coccinelle crashes with a stack overflow error even on the simplest patterns. Second, I couldn't figure out how to use coccinelle to extract the bits I want from those 32-bit constants. This is an example pattern. I've described the relevant information I want to extract in '//' style comments: read(0x6530); /* 0f41 */ write(0x6530, 0x0f41); read(0x6530); /* 0f41 */ write(0x6530, 0x0f41); read(0x6200); /* 21000101 */ write(0x6200, 0x21000101); // - [30:28] hpd_id (2) read(0x6200); /* 21000101 */ write(0x6200, 0x21000101); read(0x9fffbe00); /* 50400050 */ read(0x6204); /* 0003 */ write(0x6204, 0x0005); // - [20:16] tx_bytes (5) read(0x6204); /* 0005 */ write(0x6204, 0x0005); read(0x9fffbe00); /* 50400050 */ write(0x6218, 0x80004000); // - [15:8] cmd_byte read(0x9fffbe00); /* 50400050 */ write(0x6218, 0x); // - [15:8] address[15:8] read(0x9fffbe00); /* 50400050 */ write(0x6218, 0x5000); // - [15:8] address[7:0] (0x50) read(0x9fffbe00); /* 50400050 */ write(0x6218, 0x); // - [15:8] expected_rx_bytes - 1 read(0x9fffbe04); /* 0050 */ write(0x6218, 0x3000); // - [15:8] i2c_reg (0x30) read(0x9fffbe04); /* 0050 */ write(0x6218, 0x); read(0x9fffbe04); /* 0050 */ write(0x6218, 0x); read(0x9fffbe04); /* 0050 */ write(0x6218, 0x); read(0x620c); /* */ write(0x620c, 0x0002); read(0x6204); /* 0005 */ write(0x6204, 0x00050001); read(0x6210); /* c100 */ delay(0x0088c9bd - 0x0088c79b); read(0x6210); /* c100 */ delay(0x0088f0b7 - 0x0088ee9b); read(0x6210); /* 0101 */ read(0x6210); /* 0101 */ write(0x6218, 0x8001); read(0x6218); /* 0001 */ // - [15:8] reply (0) read(0x6210); /* 0101 */ // - [28:24] actual_rx_bytes (1) read(0x9fffa414); /* 22232121 */ read(0x9fffa418); /* */ read(0x9fffa52c); /* 8001 */ read(0x9fffa530); /* 0108 */ write(0x9fffbe04, 0x08800100); write(0x9fffbe00, 0x4f500050); Now assuming I have a struct called jelly_donut instantiated as 'donut', I'd like the output to look like: donut-hpd_id = 2; donut-tx_bytes = 5; donut-cmd_byte = 0x40; donut-address = 0x0050; donut-i2c_reg = 0x30; process_food(donut); /* .reply = 0; actual_rx_bytes = 1 */ or, I'll even settle for something like: regurgitate(2, 5, 0x40, 0x0050, 0x30); /* .reply = 0; actual_rx_bytes = 1 */ Any ideas how I'd get this done? Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Life hack #37: how to make a great touchpad
On Monday, April 21, 2014 09:24:57 AM ron minnich wrote: Oh, wait, what mailing list is this again? I thought it was the ~coreboot list. I thought Chromebooks were very on-topic, or did we drop them from our tree? Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Life hack #37: how to make a great touchpad
On Monday, April 21, 2014 10:05:40 AM ron minnich wrote: coreboot on chromebooks are very on topic. Track pad drivers for Linux, or the trackpad firmware, or the trackpad vendor, or the algorithms used, or the fact that you made this comment in such a way that nobody from the trackpad group will see it, or that it's pretty rude on top of that, not so much. Rude? How so? I was just pointing out that having a good touchpad on a low- cost device is possible. It would have been rude to withhold this information ;) Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Life hack #37: how to make a great touchpad
To manufacturers of Chromebooks, Sorry guys, I have a chromebook myself, and its touchpad is appalling. I've also tried the chromebooks in stores and they aren't much better. But have no fear, Alex is here, and has the perfect recipe on how to squash such hardware bugs early on. Following these steps, you are guaranteed to never make this mistake again: 1. Go to your favorite bidding site 2. Enter the following search terms: HP Pavilion M6 1035dx 3. Find a matching listing 4. Purchase full laptop 5. When you get it, observe its touchpad 6. Notice the big, easy to hit buttons 7. Notice the surface area 8. Notice the smoothness of the surface 9. Notice the ease of moving the pointer 10. Notice the tactile feedback from the buttons 11. Notice the evenness of the force needed to engage the button 12. Notice the fatigue of repeatedly pressing the buttons (hint:there is none) 13. Play with its touchpad 14. Play some more with its touchpad 15. Now play with the Unreleased(TM) Chromebook's touchpad 16. If it seems inferior, it probably is You'll be making perfect touchpads now, won't you? Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Blog post by Scott D.: Small Integers: Big Penalty
On Thursday, April 17, 2014 12:41:39 PM ron minnich wrote: Paul, very nice, thanks. It's not real surprising, actually, at least in my old scientific computing world. Since that is AMD code, maybe we can get the guys who wrote it to read that nice book written by AMD :-) OUCH! Right under the belt. ;) Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [proposal] EC-mainboard interaction at ASL level
On Tuesday, April 08, 2014 08:32:46 AM Duncan Laurie wrote:
If we do go the route of having lots of mainboard handlers I think we
should keep the method names consistent with the ACPI spec and use a
mainboard namespace to separate them. Conditional references are
already a headache in ASL and I think relying on the preprocessor
would make things worse.
Scope (\_SB.MB)
// Lid open
Method (LIDO) { ... }
// Lid closed
Method (LIDC) { ... }
// Increase brightness
Method (BRTI) { ... }
}
Duncan, this is genius. It simplifies the ASL quite a bit, even if some of
said methods are stubs. Looking at some code actual code [1][2], this method
is very clean and straightforward. I vote for this approach.
Alex
[1] http://review.coreboot.org/#/c/5515/
[2]
http://review.coreboot.org/#/c/5517/1/src/mainboard/hp/pavilion_m6_1035dx/acpi/mainboard.asl,cm
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] S3 Resume on AMD Trinity APU
For those of you with Trinity CPUs, coreboot, and working S3 resume, is it necessary to run the VGA option ROM on S3 resume to get video back? Which output are you using (VGA, DP, etc) ? Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] So, you want to try coreboot? Here are a few hints
Installing coreboot can be an either enthralling or appalling experience. If you're new to coreboot and want to give it a try, following a few simple steps can save you a ton of time and frustration. Ask around first Let the coreboot people know you want to try coreboot on board 'xyz'. You may find someone with the same board, who may be able to give you hints on flashing. This is especially useful on laptops, where a brick will most likely result in the need for disassembly to access the flash chip, and external flashing. Prebuilt images === If you're lucky enough to find someone with the same board as you, they may be able to provide a pre-built coreboot image. This eliminates issues where flashing is done correctly, but a mysterious bug prevents the system for booting. Binary coreboot distributions = Sometimes people get together and create tested binaries binaries for a subset of boards. They can give you help on flashing, and making sure your board works as expected. This is by far the best way to try coreboot. If you have a Lenovo X60, give the libreboot[1] guys a holler. That's libre- boot, not lib-reboot. You may also be able to find, for a fee, prebuilt binaries for your board from Sage Electronics' SageBios[2]. I am not sure how Sage conducts its business, so Marc, feel free to correct me on this one. [1] http://libreboot.org/ [2] http://www.se-eng.com/sage-bios.html -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [proposal] EC-mainboard interaction at ASL level
OK, I've started a page [1] where ideas can go. Once we stabilize the spec, I'll remove the warning on top, and we can consider that to be policy. [1] http://www.coreboot.org/ACPI/Board-EC_interaction -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [HELP!!!] Pavilion EC (similar to compal/ene932) and its woes
On Monday, April 07, 2014 04:55:05 PM Peter Stuge wrote: mrnuke wrote: Turns out that I needed to tell the EC to go into ACPI mode, as it boots up in APM mode. Blame MS-DOS and the 1990s. Damn you MS-DOS and the 1990s!!! Signed, A disgruntled hardware hacker -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [proposal] EC-mainboard interaction at ASL level
This is an ugly one, and we keep having to find different workarounds to make this happen. We have the preprocessor, so why not use it? Define a set of common ACPI method names which the mainboard code should define, and the EC code can always use. * MB_TOGGLE_WLAN() or MB_TOGGLE_WIRELESS() Toggle wireless LAN on and off, or wireless LAN and bluetooth (respectively). EC calls this on hotkey events. * MB_INCREASE_BRIGHTNESS() and MB_DECREASE_BRIGHTNESS() Increase or decrease screen brightness. EC calls this on hotkey events. * MB_SWITCH_DISPLAY() Switch the active display. EC calls this on hotkey events. * MB_NOTIFY_POWER_EVENT() Handle power state notifications and notify CPU device objects to re- evaluate their _PPC and _CST tables. Of course, we would have the mainboard #define these to an existing method, we wouldn't really use these long method names in ASL. Another idea would be to standardize on four letter names, but those are not as clear, and hide the MB_ which is there to indicate that the mainboard should provide those. Notice that these methods are only called on hotkey events. As such, unless the user has really fast fingers, there isn't a huge ACPI overhead as opposed to setting/clearing the needed bits directly in the caller. We then extend this to also include ACPI objects for different purposes. * MB_LID_STATE Register/GPIO bit which reads the state of the lid And we can also define a set of ACPI variables which should always be present, for the purpose of ACPI housekeeping. * LIDS Stores the lid state, so that we don't have to read it every time. (remember, reading may involve several port IO operations) * PWRS AC adapter present/not present. It seems a little convoluted, so if you didn't ACPI before, you'll WTF on this one. The end result is that it unifies the interface rather than letting each EC define its own interface. It also (hopefully) makes ACPI just a little more readable by having a standardized set of pork. If there aren't any major objections, I'll write this up on the wiki, and we'll open the gates to refactoring. I'm interested if there are cases where this *cough* API *cough* is not appropriate. It seems to be universally efficient. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] AGESA (f15tn) AmdInitReset doing nasty things
It's changing the ROM base (devfn 14.3, register 0x6c) from 0xffc0 to 0xff00. The bootblock sets it up correctly, but AmdInitReset messes it up. Any ideas? AGESA is particularly annoying to grep. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AGESA (f15tn) AmdInitReset doing nasty things
On Sunday, April 06, 2014 05:16:53 PM Scott Duplichan wrote: mrnuke [mailto:mr.nuke...@gmail.com] wrote: ]It's changing the ROM base (devfn 14.3, register 0x6c) from 0xffc0 to 0xff00. ]The bootblock sets it up correctly, but AmdInitReset messes it up. ] ]Any ideas? AGESA is particularly annoying to grep. ] ]Alex It is probably 102 of Hudson2LpcResetService.c: RwPci ((LPC_BUS_DEV_FUN 16) + FCH_LPC_REG6C, AccessWidth32, 0xFF00, 0, StdHeader); Thanks! Yeah, killing that line solves the issue. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [HELP!!!] Pavilion EC (similar to compal/ene932) and its woes
On Saturday, April 05, 2014 03:34:22 PM mrnuke wrote: My guess is that vendor BIOS handles SMI and then somehow triggers SCI in software. I'd try to route all GPE to SCI. Turns out that I needed to tell the EC to go into ACPI mode, as it boots up in APM mode. In APM mode, it causes SMIs instead of SCIs. Freaking dumb-ass ECs. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [HELP!!!] Pavilion EC (similar to compal/ene932) and its woes
So, in messing with this Pavilion m6_1935dx, I was able to get most of the EC running as expected. It seems that, at least the (ACPI) register layout is the same. We can get good battery _and_ AC indicators from it. When we query the EC (say, doing a cat /sys/class/power/AC/online), it responds properly with an SCI whenever the status register changes, and the query goes well. And that's about it. When an event happens, on the other hand, like a hotkey, or AC is removed, it does not generate an SCI that would lead to a query call (_Qxx). Instead it spits out an SMI. I know for a fact that the SCI and SMI GPEs are where we expect them to be. I see google/parrot uses the same physical EC silicon, though the EC firmware may be a different beast. However, I'd like to ask of you gurus who have worked on parrot... what's your take on this? Alex More technical details: I've made ACPI print a debug message whenever GPE23 is triggered (_L17). This is the EC SMI event. I'm also using linux supermagic to get an idea of what is going on: -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [HELP!!!] Pavilion EC (similar to compal/ene932) and its woes
So, in messing with this Pavilion m6_1935dx, I was able to get most of the EC running as expected. It seems that, at least the (ACPI) register layout is the same. We can get good battery _and_ AC indicators from it. When we query the EC (say, doing a cat /sys/class/power/AC/online), it responds properly with an SCI whenever the status register changes, and the query goes well. And that's about it. When an event happens, on the other hand, like a hotkey, or AC is removed, it does not generate an SCI that would lead to a query call (_Qxx). Instead it spits out an SMI. I know for a fact that the SCI and SMI GPEs are where we expect them to be. I see google/parrot uses the same physical EC silicon, though the EC firmware may be a different beast. However, I'd like to ask of you gurus who have worked on parrot... what's your take on this? Alex More technical details: I've made ACPI print a debug message whenever GPE23 is triggered (_L17). This is the EC SMI event. I'm also using linux supermagic to get an idea of what is going on: # echo 0x88000502 /sys/module/acpi/parameters/debug_level # echo 0x00060006 /sys/module/acpi/parameters/debug_layer # echo -n 'file ec.c +p' | tee /sys/kernel/debug/dynamic_debug/control That's how I know the GPE for SCI is correct (also same GPE in the vendor's ACPI). -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [HELP!!!] Pavilion EC (similar to compal/ene932) and its woes
On Saturday, April 05, 2014 08:21:21 PM Vladimir 'φ-coder/phcoder' Serbinenko wrote: On 05.04.2014 19:02, mrnuke wrote: When an event happens, on the other hand, like a hotkey, or AC is removed, it does not generate an SCI that would lead to a query call (_Qxx). Instead it spits out an SMI. I know for a fact that the SCI and SMI GPEs are where we expect them to be. What do you mean by expected? EC SCI is hooked to GEVENT3 pin which is routed to GPE3 EC SMI is hooked to GEVENT23 which is routed to GPE23 Same as vendor BIOS? Yep My guess is that vendor BIOS handles SMI and then somehow triggers SCI in software. I'd try to route all GPE to SCI. I can only route one GEVENT pin to a GPE, otherwise the SB craps up and no longer triggers an interrupt for that GPE. I've tracked it down to bit5 of the EC status reg (inb 0x66). Normally, on an external event, it would be set, OS finds it set and queries the SCI source, uses that to call _Qxx. That bit5 is never set by EC in my case. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD doesn't get it either in some ways (the bastards!!!)
On Friday, April 04, 2014 10:00:41 AM ron minnich wrote: I have this nice board, with a nice AMD cpu, and I get no graphics. Why? Because AMD won't release the VGA blob. So the board is headless. Are you talking about a board which originally came with IBV firmware? In that case, you may be able to extract the blob from linux while running on said firmware. Another addition to the blob matrix. sigh. How can you add a blob that you don't have? And what CPU is that? Do you think we can get native VGA init running? (fork thread if you answer this second question) It's really not that just one vendor is bad and one is good. AMD has its issues too. So, say I have this Intel southbridge. I go online, look it up, and I can get a public datasheet with register definitions and programming information. So now I have this Hudson southbridge. It's AMD, so it should be a piece of cake to get everything I need, right? Turns out the only public document on that is an erratta sheet (DING-DONG!). So, I ask around , and it turns out that that there's an AMD Embedded Developer site which should have this info. OK, so maybe I didn't know where to look. I go to said site, and it requires registration (DING-DONG!). I start the registration process, and I am asked to agree to an NDA (police siren!). I read that NDA, and it does seem to disqualify me from contributing to coreboot (police siren getting closer!), as this would not be considered using the information for internal evaluation. An NDA for a register guide? What the flunk? So, I go to AMD's email support form, where they have a nice category for Technical Documentation, and I explain why I cannot agree to said NDA, and politely request the documents I need. They tell me that's not possible without the NDA. So I ask them if I can get an NDA which explicitly allows FLOSS. I get a (sales) phone number. AMD is full of... On the other hand, nothing beneficial to them has come from coreboot. I can't blame them for losing interest. They get involved, contribute, spend time and money making their stuff upstreamable, and everyone still uses chips from competitors who are hostile towards coreboot. I bet they're pretty pissed off about this. I definitely would be if I were in their shoes. It's a wonder I have any teeth left, given all the gnashing I get to do :-) Dentistry has come a long way in the past decades. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD doesn't get it either in some ways (the bastards!!!)
On Friday, April 04, 2014 11:08:29 AM ron minnich wrote: Now, there's no need to be that mean, ok? AMD are not bad guys in my view. But they have made some seriously boneheaded decisions, and locking up the VGA bios is one of them. Not mean, disappointed. We can't get anywhere calling people names like this. That's just a reference to South Park. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Changes to the coreboot Project Structure -- one small step for bike sheds
Let's think of a few things which makes gerrit annoying: * -2 is a de-facto veto * -1 is not persistent on updates, encouraging -2 to be given The end result is that we're encouraging vetoing of patches. Proposal: * Submitability of a patch is based on overall review score ** Need at least a score of +2 for patch to be submitted ** Maybe (?) a score of +3 to require at least two sets of eyes * A review of -2 is not a veto ** Patch still submittable if overall score is +2 (or +3) * Score of -1/-2 is persistent until reviewer retracts it Requiring a review of +2 is possible, but not necessarily needed. Since only persons with +2 rights can submit a patch, their submitting a patch based on a +1/+1 review is effectively an approval. This has the effect of increasing the significance of -1/+1 scores, which, in the old scheme, were somewhat useless (an infinite number of -1 scores would not prevent a patch from being submitted). I think we should try this system, and see how well it works. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] New addendums to INTEL FSP family
On Wednesday, April 02, 2014 08:41:10 AM ron minnich wrote: This license still looks problematical to me. Couple that with the fact that the Haswell MRC is still not generally available from Intel and I'm a bit concerned. If I build a coreboot image with FSP, am I allowed to put it on dropbox for others to try out? Not clear at all! And, one backup copy? Do the people who wrote this understand how things in this world work? This is progress, and Intel gets closer every time, but they're still not there in my view. How is this progress? It's a much more terrible solution than MRC, much harder to integrate, and the only step it really leaves us with control over is resource allocation. Resource allocation is one of coreboot's strongest points. It seems to me this is just an attempt to use coreboot's resource allocator in a proprietary firmware. That is a clear attempt to circumvent the wishes of the rightsholders to this project. Nobody asked us how such binaries could best be incorporated. The currently provided solution is so hard to integrate that reverse engineering is a viable alternative. Google did a reasonable job with mrc.bin. Not ideal, but vastly superior to FSP. The last time we've had FSP support added to our tree, it was a mess. It broke things across the tree. I'd like for that to not happen again. INTEL SOFTWARE LICENSE AGREEMENT Declined, thank you! Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] New addendums to INTEL FSP family
On Wednesday, April 02, 2014 10:08:37 AM ron minnich wrote: On Wed, Apr 2, 2014 at 9:38 AM, mrnuke mr.nuke...@gmail.com wrote: That is a clear attempt to circumvent the wishes of the rightsholders to this project. That part I believe you are missing here is that this is a balancing act. The vendors are rightsholders too. They have knowledge we need. Unfortunately, most of them no longer want to release it -- it's not 1999. It's all well and good to say well sod them then but that's simply not an option on a large scale. I don't like it, you don't like it, we don't like it, ... but there it is. $ git grep -i intel |grep -i copyright |grep -v microcode Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] New addendums to INTEL FSP family
On Wednesday, April 02, 2014 12:15:35 PM mrnuke wrote: On Wednesday, April 02, 2014 10:08:37 AM ron minnich wrote: On Wed, Apr 2, 2014 at 9:38 AM, mrnuke mr.nuke...@gmail.com wrote: That is a clear attempt to circumvent the wishes of the rightsholders to this project. That part I believe you are missing here is that this is a balancing act. The vendors are rightsholders too. They have knowledge we need. Unfortunately, most of them no longer want to release it -- it's not 1999. It's all well and good to say well sod them then but that's simply not an option on a large scale. I don't like it, you don't like it, we don't like it, ... but there it is. $ git grep -i intel |grep -i copyright |grep -v microcode and: $ git log |grep -i author |grep -i intel Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] New addendums to INTEL FSP family
On Wednesday, April 02, 2014 10:17:13 AM ron minnich wrote: On Wed, Apr 2, 2014 at 10:15 AM, mrnuke mr.nuke...@gmail.com wrote: $ git grep -i intel |grep -i copyright |grep -v microcode Point being? I talk about Intel and their attempt to circumvent the wishes of the rightsholders. You talk about vendors also being rightsholders. Intel has no significant code, and zero contributions to coreboot. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] New addendums to INTEL FSP family
On Wednesday, April 02, 2014 10:25:39 AM ron minnich wrote: On Wed, Apr 2, 2014 at 10:17 AM, David Hubbard david.c.hubbard+coreb...@gmail.com wrote: Could the two interested parties negotiate a compromise? In my mind that's Google calling Intel, and they talk it over. That probably just demonstrates how little I understand about who and what is involved. Goodness, you think that has not happened, frequently, not just with Google but with many parties over the last 15 years? I'm afraid it demonstrates what you said :-( Going back to the original FSP issue here. What does it take to get Intel to consider putting FSP in a reasonably upstreamable state? Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] What commits, pushed by inexperienced people, broke the tree in the last 2-3 years? (was: coreboot for the 21st century)
Paul, please ignore my top-posting. Could you please not hijack threads as long and tedious as this one? Feel free to quote the comments you are referring to, but make sure to scrub the in-reply-to field. It's getting tedious to read this. Oh, and probably a lot of people have muted this thread already. You won't reach your intended audience. On Saturday, March 29, 2014 12:34:19 AM Paul Menzel wrote: Am Samstag, den 22.03.2014, 19:44 +0200 schrieb Kyösti Mälkki: Ron, would you be so kind and identify by commit hash some of these code merges by inexperienced guys from last 2-3 years that broke a bunch of boards. I would like to see from gerrit history how these problems were ultimately dealt with and hopefully we could all learn from the mistakes that were made. I am interested in this too, as I heard this argument very often, but according to my memory the claim is not true. Everybody makes commits which break boards. Sure, you'll be able to come up with a few hashes that caused issues and were merged by less-experienced people. If we look hard enough, we'll find the same is true of guru and god devels as well. Things break. It's a natural part of the process. (Just had a deja-vu when typing this. Did I say this before?) Clumsifying the process because things occasionally break is not going to unbreak those things, nor is it going to stop breakages in the future. We've seen this with TSA, terrorist threats, and even coreboot. No matter how much better the new process is compared to the previous, things still break. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Patch set to add support for AMD based laptop HP Pavilion m6-1035dx up for review
On Friday, March 28, 2014 10:03:28 AM Paul Menzel wrote: Dear coreboot folks, Alexandru put wood behind the arrow to get coreboot running on an AMD based laptop. He took his old HP Pavilion m6-1035dx [1] and in a day/night had coreboot running on it and he submitted the patch set for review [2]! Heh! Thanks for the enthusiasm, Paul. I was able to merge this earlier today., so people can start playing around with it. The hardware in this laptop will eat chromebooks alive performance-wise, and does not have essential, non-replaceable, persistent blobs. I think all the blobs still present could be replaced with free alternatives after some reasonable effort. I am surprised just how portable the AMD hardware is, as opposed to evil competitor. The blobs we're dealing with here are chipset-specific, as opposed to board-specific, as is the case of evil competitor. This makes them much less intrusive on the porting process, almost transparent. Congrats to being, to my knowledge, the first to get coreboot running on an AMD based laptop! Also big thanks to AMD and Sage Electronic Engineering LLC [3] for providing code and support for AMD stuff! Also thanks to Google for contributing code for the COMPAL ENE932 Embedded Controller [4]. I could not have done it if those pieces weren't in place. Having coreboot run on an AMD laptop is really exciting for me. I has been disheartening to see how AMD is helping us, but most of our bright minds defect to hardware which is more restricted and unnecessarily harder to deal with. So reviewers and help in getting the non-working stuff to work are greatly appreciated. ACPI is the bigger issue here. Suspend/resume needs work, as does the battery indicator, and some hot-keys. Bad for Alex that he now has to deal with AGESA and get for example CBMEM console working with it for romstage or to refactor the code to be more maintainable. :P There was plenty of less-than-perfect code which sneaked in along the years, albeit I am glad we have it. I will only touch fam15tn part of AGESA, as I can test the changes and avoid breaking hardware I do not own. There are some circular dependencies here and there, and a definite abuse of compiler include paths. This confuses code editors, and makes development harder, as you first have to figure out which file is included. I'll be working briefly to address these, and, as you put it, make the code to be more maintainable. My motivation for doing this is not to get coreboot to run on this laptop. The laptop itself is poorly constructed. I do, however, want to lay the groundwork for the LTS laptop everyone's been talking about. I also have some ARM laptops due to arrive, so I'll also focus on getting those up to speed. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Miniboot
On Wednesday, March 26, 2014 09:13:38 AM Björn Busse wrote: Now I did it, hijacked this thread (Hi mrnuke!). TL;DR. You're doing it wrong. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Changes to the coreboot Project Structure -- the non-aneurysmal way
Not so long ago, Stefan announced some pretty drastic changes to the project structure. While I believe he wanted to discuss the direction and find a mutually agreeable direction, his email still raised the aneurysm level to over nine thousand. So, how about we take the good ideas out of there and start putting them in practice. Today, I'll be focusing on the idea of MAINTAINERS. While it's nice to jump straight to maintainer trees, that's a long ways away, and I'm not even sure we reached consensus on it. Couple that with the changes needed to be done to _both_ gerrit configuration, _and_ gerrit workflow, this matter is better left for another day. What we can do, however, is to start assigning maintainership of different sub-directories. Two ways to do it: (i) One big MAINTARES file in top-level directory (ii) One small MAINTAINER file in each directory with an assigned maintainer Number (i) is human friendly, while (ii) is parser-friendly (I would hope). Now comes the fun part: For directories with a maintainer, gerrit implements a MMA criteria. That's short for Maintainer Must Approve. People are still welcome to do reviews, bikeshed, etc, but the maintainer has veto power. For directories without a maintainer, the old workflow applies (no MMA). This should reduce confusion from conflicting reviews, and definitely reduce number of incidents where a patch gets merged with a review from a person who is not fully qualified to, well, do the review. Masters, of Gerrit, the pleasure of training gerrit to implement this change is left entirely to you. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Changes to the coreboot Project Structure -- the non-aneurysmal way
On Wednesday, March 26, 2014 03:32:12 PM Patrick Georgi wrote: Am Mittwoch, den 26.03.2014, 09:22 -0500 schrieb mrnuke: Masters, of Gerrit, the pleasure of training gerrit to implement this change is left entirely to you. While we're specifying behaviour: what should happen to changes that affect multiple maintainer domains? Add each maintainer to the MMA list. A little clumsy? Yeah. On the other hand, it encourages splitting of patches in maintainer-domain chunks. (and before you say they shouldn't exist, refactorings regularily hit the entire tree) And that's one of the few cases where the above splitting may not be possible. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Classification of blobs and respecting your freedom
In the search for a good LTS (long term support) laptop, I've had to think hard of which blobs could be consider acceptable, and which would disqualify candidates. I've made a write-up about this classification here[1]. The idea is simple: find out which blobs would disqualify the machine from being Respects Your Freedom (RYF) certifiable. RYF capability, in my opinion, is a very important feature of any laptop which we plan to support for a long while. A machine as old as the x60 has seen a steady increase in its user base since the GluGlug has received RYF certification. Almost every week, I see a few people asking on IRC about how to flash coreboot on the X60, or how to unbrick it. A number of those people are using the pre-built images supplied by libreboot. Did I convince you RYF is essential? Maybe not. Is it definitely desireable. For an LTS candidate, it's pretty darn important. And while you may not give much importance to RYF, the X60's desirability is something we want to continue to repeat in the future. There is a niche market thirsty for this king of thing. That means we must start caring about RYF, whether you like it or not. With RYF, there are a number of elements that need to come together in harmony. I have tried to understand how we, as firmware hackers, could better accommodate the situation. There is a lot we can do to make sure that a machine can take the path to RYF certification. I will call that RYF-capable. Note that capable does not necessarily mean certifiable. What I mean by RYF capable is that it is reasonable for a group of community hackers to get together and eliminate any offending blobs. This is where the classification comes in. We need to be able to talk about blobs in terms of simple criteria. With this classification, all essential blobs must be reasonably removable. So, while the RYF-certified machine may have reduced functionality than the same RYF-capable machine, a machine will never be RYF-certified, if it is not RYF-capable. Anyhow, I wanted to ask what you guys think about the classification. Alex [1] http://www.coreboot.org/Binary_situation#Classification_of_blobs -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Classification of blobs and respecting your freedom
I should delete my reply button. Darn! It's reply to all. Sorry Ron. On Wednesday, March 26, 2014 03:05:47 PM mrnuke wrote: On Wednesday, March 26, 2014 01:01:10 PM you wrote: Ah, that's what I meant by persistent. Let's take your name and get rid of mine, and we're still at 2 axes? Three axes. non-persistent, replaceable, non-essential. I think they're orthogonal. * NP and R are relevant when looking at things from a security point of view. * R and NE are relevant from a RYF point of view. Think of RYF and security as two orthogonal planes which intersect at the R axis. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] A new, modern coreboot long-term support laptop (was: Expectations, project direction and interest of contributors)
On Monday, March 24, 2014 10:31:49 PM ron minnich wrote: On Mon, Mar 24, 2014 at 9:10 PM, mrnuke mr.nuke...@gmail.com wrote: * For example, a hardwired boot blob which has been RE'd so that we know what it does and how it does it, would be acceptable (see Allwinner). Hard for me to agree with this, but if that's ok with you, it's ok with me. If you are claiming to understand what an RE'd blob does then you've solved the halting problem, I think. I know what the Allwinner BROM does, I know it will go into a special USB mode if the boot fails, and that mode has the capability to inject and executw arbitrary code via USB OTG, and can also modify contents of NAND, MMC, SPI flash, etc. Does that kill any hopes of security? Yes. Does it maky any less free? No. * A non-ISA (a) firmware blob which controls a piece of hardware which i) can only do one thing ii) without compromising the security of the system iii) and is non-essential for the functioning of the system Interesting. From a security POV I'm a lot more worried about usb3 firmware than about the MRC. As far as I'm concerned USB 3 firmware is a persistent embedded threat, violating point ii. The ME is of course far worse. Of these I find the MRC the *least* threatening. I guess that depends on how capable the USB3 micro is. But OK, USB3 firmware is not accepted for the purpose of this conversation. * An ISA blob which is NOT essential for the bring-up of the system, and can reasonably be replaced by a free alternative. This basically includes VGA BIOSes. Makes no sense to me either. If the ISA blob is in place, then it's no different than MRC, save that it is almost certainly persistent. In fact it's more dangerous than the ME. Until it's replaced, it can at any point compromise the security of the system. The idea is that the system be RYF capable. This doesn't mean it can be RYF with such blobs. If replacing these blobs is reasonably doable by a group of non-commercial guys, then we consider this a non-issue in the context of picking a hardware candidate. Simply put, these blobs should be replaceable in the medium term, so the system can be brought to a RYF state. A VGA BIOS meets these weird criteria. (I did say my views on blobs are weird, didn't I?) a branch containing that hash is not available publicly. Baloney. Your not finding it does not mean it's not available. It means you didn't look hard enough. I call baloney on this one. I do not have to look hard enough. Section 3 defines how hard I should look. My chromebook came with no corresponding source code, and no written offer for the source code. So no, I don't have to jailbreak the device to get to a root shell, read the flash, dd the BIOS_STUB out of there, and run cbfstool to extract the .config in order to find out I'm running coreboot commit ff1f4757e4bd35a6b72018d0982b5e2bec89a1bb Did I mention the manufacturer (the one whose name was on the box) explicitly responded to my request for source code with we don't give that away? This is where I've been meaning to get to. I'm all for doing what the new title of this (hijacked) thread says: a new, modern long-term coreboot supported laptop which is Respects Your Freedom certifiable. A laptop that will become what the X60 is today. I'm wondering: what's wrong with the HP11? It goes much further today than any x86 laptop toward RYF. The MRC is source. There's no ME. The EC code is also open source. Why not start there? Sure, it's not coreboot; sure, it's not x86; who cares? It's totally RYF. And coreboot can run on it, I bet, if you care. It won't be available for purchase much longer, and it's not very practical as a day to day laptop due to its tiny screen. A lot of drawbacks, but sure, it is a valid candidate nonetheless. Carl-Daniel was flinging the idea of a laptop with long shelf life. He found something just recently IIRC. Not cheap, but supposedly sturdy and with an expected shelf like of at least 2 more years. Oh yeah, can you tell us anything about the Samsung Chromebook 2? Chose the hardware. Set up a github temporary fork. Send me the hardware. I got Pomona, I got SPI, I got USB debug, and I got the burning desire to make this happen. I think that's wonderful, and you need to find a way to make it happen. Right now, as you have seen, laptop vendors are not breaking down the doors at AMD to use their chipsets in a laptop. There are reasons. Yeah. AMD parts usually end up in cheap laptops that are not expected to stay in one piece for more than a month. Although performance-wise, I still miss my old AMD laptop. The volunteers need to lead this AMD effort, and the first step is finding the person to make it happen, and the next step is finding money. But, first, you really ought to make sure it's AMD you want, not ARM. And once you pick out a laptop, fill out the blob matrix, please, so we know what's going
Re: [coreboot] A new, modern coreboot long-term support laptop
On Monday, March 24, 2014 10:36:27 PM David Hendricks wrote: On Mon, Mar 24, 2014 at 9:10 PM, mrnuke mr.nuke...@gmail.com wrote: Chose the hardware. Set up a github temporary fork. Send me the hardware. I got Pomona, I got SPI, I got USB debug, and I got the burning desire to make this happen. I like your attitude. See if there's a laptop that looks doable in the ~$500 range, buy two of 'em, and tell me how to reimburse you. I like your attitude too. I've started developing a Candidacy page [1]. I won't start fiddling hardware or funds until a consensus is reached as to the best option. There's an interesting trend with these ProBooks. In November, when I got my chromebook, there was only one ProBook with AMD CPU available IIRC. Now there are a number of such models. That may indicate we can expect those to be on the market for a while, or I'm just remembering wrong and those have less than a year of shelf life remaining. Anyone has any experience with the AMD ProBooks? Are they built to last, or are they crap? Alex [1] http://www.coreboot.org/User_talk:MrNuke/LTS_Candidates -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] A new, modern coreboot long-term support laptop
On Tuesday, March 25, 2014 10:53:51 AM ron minnich wrote: Just one thing. Don't underestimate just how miserable the EC can make your life. I place a high premium on systems with an open EC. Just be careful there. Can you tell us more about the Samsung Chromebook 2? Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Changes to the coreboot Project Structure
On Tuesday, March 25, 2014 06:56:13 PM Stefan Reinauer wrote: * ron minnich rminn...@gmail.com [140325 06:34]: On Mon, Mar 24, 2014 at 10:20 PM, Vladimir ' -coder/phcoder' Serbinenko phco...@gmail.com wrote: I don't see how this prevents any of my propositions for the bulk of the boards. The problem you describe isn't going away with your proposition. We still want to have a top which is supposed to work on all boards. All boards? The Arima HDAMA, 12 years old now, not sold for maybe 10? All boards? Are you sure? Keeping old boards in a branch of coreboot that is not moving as fast as upstream will reduce breakage and stabilize the code base for those systems. This model works for linux with really old releases being maintained by interested people. It is doable. It is reasonable. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] A new, modern coreboot long-term support laptop
On Tuesday, March 25, 2014 07:51:33 PM Stefan Reinauer wrote: * mrnuke mr.nuke...@gmail.com [140325 08:37]: a branch containing that hash is not available publicly. Baloney. Your not finding it does not mean it's not available. It means you didn't look hard enough. I call baloney on this one. I do not have to look hard enough. Section 3 defines how hard I should look. My chromebook came with no corresponding source code, and no written offer for the source code. So no, I don't have to jailbreak the device to get to a root shell, read the flash, dd the BIOS_STUB out of there, and run cbfstool to extract the .config in order to find out I'm running coreboot commit ff1f4757e4bd35a6b72018d0982b5e2bec89a1bb https://chromium.googlesource.com/chromiumos%2Fthird_party%2Fcoreboot [mrnuke@nukelap sltest]$ git clone https://chromium.googlesource.com/chromiumos/third_party/coreboot Cloning into 'coreboot'... remote: Sending approximately 35.98 MiB ... remote: Counting objects: 13722, done remote: Finding sources: 100% (813/813) remote: Total 154664 (delta 127716), reused 154474 (delta 127716) Receiving objects: 100% (154664/154664), 34.77 MiB | 1.16 MiB/s, done. Resolving deltas: 100% (128150/128150), done. Checking connectivity... done. Checking out files: 100% (10717/10717), done. [mrnuke@nukelap sltest]$ cd coreboot/ [mrnuke@nukelap coreboot]$ git checkout ff1f4757e4bd35a6b72018d0982b5e2bec89a1bb -b found_it fatal: reference is not a tree: ff1f4757e4bd35a6b72018d0982b5e2bec89a1bb [mrnuke@nukelap coreboot]$ You didn't check the hash, did you? Exynos still has that annoyng BL0 blob, does it not? It's either a trade-off or a trade-off. Damn! Which is why this whole whining around is useless unless it results in action. There's already been more action in the last few days than in the last few years. We've rounded up a first batch of candidates, got interested people pledging coding effort, and even a pledge for financial support. We got some of the libreboot guys excited about this. As long as we don't slack and lose momentum, we're on the right track. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] A new, modern coreboot long-term support laptop
On Tuesday, March 25, 2014 12:03:28 PM David Hendricks wrote: On Tue, Mar 25, 2014 at 10:57 AM, mrnuke mr.nuke...@gmail.com wrote: On Tuesday, March 25, 2014 10:53:51 AM ron minnich wrote: Just one thing. Don't underestimate just how miserable the EC can make your life. I place a high premium on systems with an open EC. Just be careful there. Can you tell us more about the Samsung Chromebook 2? What do you want to know? It's been announced, the specs are out, the firmware code is out in the open (it ships with u-boot), and we even have some code upstream for it in coreboot that could be polished up. There's the usual masked ROM in addition to the 8KB BL0 blob, but everything else is open including the EC firmware. I'm assuming BLO is not persistent. It's a nice laptop that is probably already a good candidate for RYF. I'll leave subjective analysis as an exercise for the reader. Teardown pictures? Construction quality? Shelf life? Performance numbers? As far as RYF, it's by far the best candidate with the least amount of work involved. Bonus: no proprietary OS and/or IBV taxes. I don't know if Google charges OEMs anything for the use of its software, but if it does, that money goes to FLOSS, so it's a non-issue. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] A new, modern coreboot long-term support laptop
On Tuesday, March 25, 2014 02:14:12 PM ron minnich wrote: On Tue, Mar 25, 2014 at 1:26 PM, David Hendricks dhend...@google.comwrote: On Tue, Mar 25, 2014 at 12:17 PM, mrnuke mr.nuke...@gmail.com wrote: On Tuesday, March 25, 2014 12:03:28 PM David Hendricks wrote: On Tue, Mar 25, 2014 at 10:57 AM, mrnuke mr.nuke...@gmail.com wrote: Construction quality? Subjective. IMO it's nice. It's wonderful IMHO. This is turning interesting. Any chance a handful of non-commercial coreboot entities could get a few early samples? I understand the ARM limitations but the EC on those AMD platforms bothers me. If it's usable as a day-to-day laptop, the ARM limitations are irrelevant. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] A new, modern coreboot long-term support laptop (was: Expectations, project direction and interest of contributors)
On Monday, March 24, 2014 05:00:26 PM ron minnich wrote: I keep wanting to drop out of this discussion but there are some things I just can't let go by, Let's focus on constructicism then (if that is even a word). On Mon, Mar 24, 2014 at 4:20 PM, Paul Menzel paulepan...@users.sourceforge.net wrote: First I find wildest expectations a little exaggerated seeing the blobs (especially ME) shipped in all current Intel devices [1]. It is even worse that these blobs are not allowed to be distributed making building and flashing an image more difficult. [...] We don't like it. But if the choice is to ship on nothing, or ship with blobs, we'll ship with blobs. The X60 ports ship with blobs too, if you look at the big picture, because we still don't have EC source on those boxes. The OLPC shipped with blobs. This is not a simple problem. [slightly OT, feel free to skip] My stance on blobs is a little weird. I try to make sure I have full control of my system. If the blob cannot do any harm to my freedom, or in other words, respects it, then that blob is acceptable. * For example, a hardwired boot blob which has been RE'd so that we know what it does and how it does it, would be acceptable (see Allwinner). Even the FSF, according to RMS's own essays considers this to essentially be hardware. * A non-ISA (a) firmware blob which controls a piece of hardware which i) can only do one thing ii) without compromising the security of the system iii) and is non-essential for the functioning of the system is acceptable. Examples would be USB 3.0 firmware blobs. Examples of blobs which would NOT be are ME (violates all three points), MRC (violates point iii, and potentially ii). * An ISA blob which is NOT essential for the bring-up of the system, and can reasonably be replaced by a free alternative. This basically includes VGA BIOSes. (a) I define an ISA blob to be a blob which contains instructions for the main CPU's architecture, and executes such instructions on the main CPU. Microcode would be a non-ISA blob, as it is not a set of x86 (or ARMv7) instructions, despite it residing in the main CPU. Additionally I heard claims, that the GPLv2 license is violated as it is currently impossible to rebuild the exact same image that is shipped with the devices as it is not even clear what commit was used to build the image and to my knowledge the requests on the list and in the IRC channel were not answered. Dude, the commit is IN THE IMAGE. At least on the images I work with. As in: ro bios version | Google_Link.2695.1.133 [Again, feel free to skip ahead] I made some of the claims Paul is talking about. I have the git hash of the firmware which came with my chromebook, but a branch containing that hash is not available publicly. This is one of the reasons I proposed to allow merging branches from shipping firmware rather than forcing a rebase of all patches. For Google and the laptop vendors, I guess the goal is simply to save [Again, feel free to skip ahead]. Then why do vendors put a $130 CPU in a laptop that sells just shy of $200? the money per device that traditionally went to the BIOS/UEFI vendors. You should not impute motive where you have no knowledge [...] A very tempting point, but I'll stay out of it. In my opinion, we should get the first AMD laptop supported as soon as possible yes, well, I've been asking for help on this for some time, years in fact, but I can't do it all myself. It's part of my huge disappointment that our volunteers chose to put their time into (quite obsolete, no longer manufactured) X and T thinkpads instead of something modern and open. You can fault Google for their decision to go with Intel; but the volunteers have not done a lot better, in fact worse in my view. Frankly, it's a disappointment. This is where I've been meaning to get to. I'm all for doing what the new title of this (hijacked) thread says: a new, modern long-term coreboot supported laptop which is Respects Your Freedom certifiable. A laptop that will become what the X60 is today. I don't have the financials to do this by myself. I don't have the time to do this by myself, and most certainly not the experience to provide an A to Z turnkey solution. I'm glad you asked. Carl-Daniel asked as well. He did a few months ago, and is still in the process of choosing a good candidate. There aren't many that are both durable _and_ RYF-certifiable after our port is made. I am willing to invest whatever limited time, limited knowledge, and limited experience I have into making this project happen. One option here is to focus less on the things you currently put your time on, and focus more on getting that AMD laptop working, eh? Because it's easy to talk about what we should do. It's better to start DOING IT. And getting that AMD laptop going is a lot more important than fixing spelling errors in AGESA. Chose the
Re: [coreboot] Changes to the coreboot Project Structure
On Sunday, March 23, 2014 07:34:32 AM Vladimir 'φ-coder/phcoder' Serbinenko wrote: On 23.03.2014 04:10, Peter Stuge wrote: That isn't too different from creating a fork? Fork is better. With fork we don't have to deal with the same people who pushed the community out in the first place. Can you guys stop fucking worrying about a fork for the time being? We'll fork if we have to, but right now, we should be focused on refactoring the development process. If we do the latter rather than the former, chances are we'll find a mutually agreeable and better process. Stop pulling out rulers and unzipping your pants. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Changes to the coreboot Project Structure
On Sunday, March 23, 2014 05:37:37 PM Peter Stuge wrote: David Hubbard wrote: But Peter, what's your take on Alex's suggestion: What do we need to do to allow commercial contributors to work directly upstream? And before you discount this question for menial technical reasons, please take a moment to keep this conversation open, and let's try to find an answer. I think Alex has his heart in the right place but I also think that it is a bit naïve to believe that coreboot would be able to do anything to allow commercial contributors to work directly upstream. In the current model, where every patch needs to go through our gerrit, and be met by highly experienced shed builders, no there's nothing we can really do. However, if we're going to change the model, this remains a valid point to look at. This isn't up to coreboot, it isn't something coreboot can influence in any other way than by becoming more relevant in the firmware market. Sure it can... by adopting a development model that makes sense to said commercial entity... by eliminating some of the unnecessary hurdles in upstreaming the code. I sense your comments are under the assumption that everyone uses AMD's model -- write lots of code with NDA'd docs, then scrub it clean before upstreaming. It's still up to the vendor how closely they want to work with upstream, but they ain't gonna do it if the process ain't friendly. As an upstream, we need to provide a friendly way of doing business. And yes, we can do that. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [announce] coreboot for the 21st century
On Friday, March 21, 2014 09:18:07 PM ron minnich wrote: On Fri, Mar 21, 2014 at 6:52 PM, Alex G. mr.nuke...@gmail.com wrote: The bad-ness or good-ness of motives is relative. Note that I'm not using bad in the sense of evil. Let's look at the six gatekeeper idea: * Easier for commercial entities to upstream code, therefore faster progress for coreboot (good motive). (a) * Easier for commercial entities to upstream code, therefore we can get lazy even if code quality drops (bad motive). (b) That's not the intent. The way you are stating this has a lot of built-in assumptions, and you're mixing some things up. That's our fault; the old rule is, that if someone did not understand what you said, it's your fault, not theirs. So, speaking as one of the guys who reviewed the email, I'm sorry it was not clearer. Let's be honest. Upstreaming contributions from Google has been a long and tedious O(n^2) process. Even though we've improved a bit in terms of jenkins build time (optimizations to abuild et. cetera) so that we don't have to wait one week for a bomb to verify, the workflow of one review per patch is still sub-optimal. So, first, the intent of the six gatekeeper idea is, in part, to be sure we're being very careful about what goes in. [...] Six seems a very arbitrary, even number. [...] So it's not about Easier for commercial entities to upstream code -- it's about not having to do the full review process *twice*, given that the code has been picked to pieces by experienced long-time coreboot coders, most of whom (no offense intended) are better qualified to review the code than almost anyone else. That's why I claim what you are saying as not quite right. I think we need to restart this discussion without the implicit assumption that gerrit is a part of the workflow. We can do what Linux does. Different individuals maintain different sub-somethings of the coreboot tree. I'm not trying to establish any criteria for maintainer status. Short answer: 1* Google team (*) assigns a coreboot representative 2* Rep decides it's time to merge some good branch 3* Rep takes internal branch, and works on top of branch 4* Rep makes branch mergeable 5* Rep submits pull/merge request to maintainer (**) of touched code 6* Maintainer reviews branch as one unit and requests changes 7* Rep applies changes on top of branch 8* Repeat 6 and 7 as needed 9* Maintainer likes what he's seeing, merges branch to his tree (*) They're still welcome to hang on IRC, ML, and/or submit individual patches. (**) Maintainer and rep must be different persons, preferably not from the same team and/or not from teams working on the same thing. This process eliminates the *twice* review. Individual patches are no longer reviewed upstream; however, a review is still done, and corrections are still applied. Since a logical change is a branch rather than a patch, the overhead is reduced significantly without eliminating the community scrutiny phase. You keep all the goodies and reduce review complexity from O(n^2) to O(1). Sound good so far? But wait! There's more! As a bonus, considering that individual patches are no longer altered, we have the hashes of shipping firmware. So, why is this better than the gatekeepers idea? * We don't bottleneck patches by limiting number of submitters/maintainers * Maintainers can focus on the part of tree matching their expertise * Reduces patch bikeshedding as maintainers have the final word Take this a step further: maintainer trees are not the master tree. Maintainers still have to periodically get their branches merged with master. Finally, a simple question here: how many gatekeepers are there for the final full released version of each version of the Linux kernel? Do you want me to answer that in binary, ternary, octal, or hexadecimal? Those gatekeeprs don't deal with individual patches, do they? My $.02 anyway. Keep on sending them. A few hundred more of them, and I'll have enough for a cigar. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [announce] coreboot for the 21st century
On Friday, March 21, 2014 11:19:42 PM ron minnich wrote: If you're going to make big changes to what happens at coreboot.org, you have to get buyin from the folks who do all the work. If we're going to refactor the development model, I insist we do it right. Patrick was discussing gitlab as a possible alternative to gerrit. I think it's time to closely evaluate our options. I'm not the right person to propose this to :-) I think I CC'd the ML. Yup, I did. Put simply, it's above my pay grade. Ran out of $0.02 on this? :) Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [announce] coreboot for the 21st century
On Saturday, March 22, 2014 03:56:46 AM Andrew Wu wrote: Yes, that is right. DMP/Vortex86EX has no MTRR. So it maybe a problem if without romcc. :( Is there any way whatsoever to temporarily use the cache as SRAM? Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC-2014 Coreboot project
Hi Allen, There's less than 24 hours left to submit proposals. If you want to do this, I suggest you get your proposal up before the deadline (March 21st). While I do not know the details of your employment contract with ASUS, I find it irrelevant for the purpose of you working on coreboot. Does it prevent you from submitting a proposal? Most likely not. Come hang out with us on IRC (#coreboot @ freenode). You can brainstorm, discuss ideas with us, get a better idea of what you'll get to work on, etc... hint I cannot stress the importance of being in constant contact with the community /hint. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC-2014 Coreboot project
On Thursday, March 20, 2014 08:30:58 AM ron minnich wrote: in the proposal. We'll deal with other issues later. The guy that gave us the first real CAR implementation was an intel employee who had NDAs out the ... and it was not an issue. Let's not start putting in roadblocks. We're not lawyers. BTW, has any manufacturer been hostile in the past in any way relating to coreboot supporting hardware they would rather have kept closed/secret? Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC-2014 Coreboot project
On Thursday, March 20, 2014 09:08:18 AM ron minnich wrote: On Thu, Mar 20, 2014 at 8:36 AM, mrnuke mr.nuke...@gmail.com wrote: BTW, has any manufacturer been hostile in the past in any way relating to coreboot supporting hardware they would rather have kept closed/secret? ha ha ha ha ha ha ha ha ha ha ha haha ha ha ha ha haha ha ha ha ha haha ha ha ha ha haha ha ha ha ha haha ha ha ha ha ha you're killing me. How about, all of them at one time or another. One vendor had an internal memo stating that anyone who talked to me (my name was on it) about LinuxBIOS would be terminated. You're popular it seems. How about within this decade (last 4 years) ? Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC-2014 Coreboot project
On Thursday, March 20, 2014 09:08:18 AM ron minnich wrote: On Thu, Mar 20, 2014 at 8:36 AM, mrnuke mr.nuke...@gmail.com wrote: BTW, has any manufacturer been hostile in the past in any way relating to coreboot supporting hardware they would rather have kept closed/secret? ha ha ha ha ha ha ha ha ha ha ha haha ha ha ha ha haha ha ha ha ha haha ha ha ha ha haha ha ha ha ha haha ha ha ha ha ha you're killing me. How about, all of them at one time or another. One vendor had an internal memo stating that anyone who talked to me (my name was on it) about LinuxBIOS would be terminated. That seems like a slap on the wrist. Terminating employees rather than taking legal action against coreboot also suggests they might feel they have no legal standing against coreboot supporting more stuff. I wonder if there's any legal action hardware vendors could take against ODM/OEM vendors who distribute and/or contribute to coreboot. And I don't mean BS lawsuits hw vendors know they'll lose. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC-2014 Coreboot project
On Thursday, March 20, 2014 09:36:06 AM ron minnich wrote: How about, all of them at one time or another. One vendor had an internal memo stating that anyone who talked to me (my name was on it) about LinuxBIOS would be terminated. You're popular it seems. How about within this decade (last 4 years) ? Alex it's a continuing problem that I doubt will ever be fully resolved, since as you may have noticed there is no QPI support yet. Not sure I care much about Intel nowadays. They are already part of the fellatio_admin group in my books. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Changes to the coreboot Project Structure
On Thursday, March 20, 2014 10:55:57 PM Stefan Reinauer wrote: Changes to the coreboot Project Structure Measures to improve the coreboot Development Model * Require authors to acknowledge changes made in their name (Forge-Author) [...] Couldn't agree more. * Define owners for (sets of) mainboards and require these to act as maintainers / gatekeepers, being the controlling instance to submit these mainboard changes. [...] * Build a MAINTAINERS file for common code, and encourage people to keep subsystem maintainers in the loop for changes [...] This is somewhat what linux does, and it works well for them. Might be a little OT/irrelevant, but why not make gerrit need a maintainer must approve before making the change submittable. * Look into making gerrit automatically add reviewers based on maintainer lists [...] Can we find something better than gerrit? I think gerrit encourages too much bikeshedding. It also encourages people to filter out gerrit emails, so that any such maintainers would not get the message. * Import previous code reviews and results The tree major stakeholders in the project all own internal code review systems, some of which are public (e.g. the Google Chrome OS repository) and have code reviews that include representatives outside of Google to ensure general code quality and making sure the improvements made for products don’t negatively impact upstreamability. For those cases it would be extremely helpful to honor the code reviews already done in the upstream repository Status: TO BE INVESTIGATED I couldn't disagree more. First of all, the idea of representatives outside of company to ensure general code quality is contrary to the idea of allowing the community to scrutinize to-be-upstreamed contributions. When you combine that with the idea of [blindly] honoring code reviews already done upstream, you have effectively eliminated the scrutiny and review from the community. I've seen mostly cases of great external reviews, but have also seen a fair share of bodged, nonsensical ones where terrible patches have been accepted without much thought. If the community has to accept code reviews done under closed doors, these contributions are effectively code dumps. I do not remember this ever being beneficial to the community, and usually results in the community needing to clean up afterwards. See linux for details. What do we need to do to allow commercial contributors to work directly upstream? And before you discount this question for menial technical reasons, please take a moment to keep this conversation open, and let's try to find an answer. Will it work for 100% of commercial contributors? No. However, this should be the preferred method for upstreaming contributions. See linux for an explanation why this works best. * Significantly reduce number of submitters To ensure consistency, scalability and conformity with the general coreboot strategy, we need to define a clear committer structure that defines the original project structure of having a benevolent dictator aka project leader (Stefan Reinauer) and gatekeepers in place. The suggested structure will need to value both community interests and corporate interests equally and hence a good setup would be to have a final amount of six developers with submit rights, three community representatives and three corporate representatives (on from each major stakeholder): I am sorry to say this Stefan, but, in my opinion, you would not make a good benevolent dictator. Over the past years, I have found you to be extremely biased towards the needs of the commercial developers, whilst being less interested and attentive to the needs and wished of the non-commercial part of the community. I do not believe that someone biased towards one part or another of the community can make a great leader. You also, on some occasions, delayed good NC contributions in order to merge less-than-ideal commercial contributions, which later had to be cleaned up by the NC guys. You are a great person, but I believe that having you as the leader, we would have a benevolent dictator for the commercial contributors, where the non- commercial ones would see have a mere dictator. On the other hand, I have found Ron Minnich to be very unbiased and equally receptive to ideas from both sides of the community. While I am certain some people might come to point out mistakes Ron had done in the past, unlike you, I did not find a pattern of bias in them. I think Ron is the best candidate for the role of President and Benevolent Dictator of Coreboot. Current suggestions: Patrick Georgi (Secunet) Marc Jones (Sage) Stefan Reinauer (Google) It has been this way for years, so to speak. I also find you to be a much better candidate as the representative/maintainer for Google contributions. I think you can do much more good
[coreboot] libpayload for ARM with sprinklings of GPL and coreboot code sharing
I'll try to be short. * Usually, ARM payloands need to use SoC specific drivers to access storage devices. * Sometimes coreboot implements the same drivers. Proposal: * Share these drivers between coreboot and libpayload. * libpayload is BSD. Have a [ ] Enable GPL features config option which unlocks the GPL'd drivers from coreboot. * libpayload core remains BSD. * coreboot drivers are available to GPL users of libpayload * Both the licensing of libpayload-core and coreboot is maintained/respected * Makes maintenance easier * Makes libpayload relevant in the ARM space Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] libpayload for ARM with sprinklings of GPL and coreboot code sharing
On Friday, March 21, 2014 01:13:59 AM Peter Stuge wrote: mrnuke wrote: * Share these drivers between coreboot and libpayload. * libpayload is BSD. Have a [ ] Enable GPL features config option which unlocks the GPL'd drivers from coreboot. * libpayload core remains BSD. The other way around would also be possible. The problem is that some things on ARM we will either tale from uboot and/or linux, like I did with the MMC driver for cubieboard. So BSD is not an option in such cases. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] ARM Linux kernel payload (was: GSoC-2014 Coreboot project)
On Wednesday, March 19, 2014 09:32:44 PM Stefan Tauner wrote: On Wed, 19 Mar 2014 16:01:05 +0100 Peter Stuge pe...@stuge.se wrote: I'd like somebody to look at doing LinuxBIOS again, i.e. getting us back to the point where we can embed linux in the flash as the payload. Patrick got us a long way back toward getting that working, and it'd be nice to see it finished. I've tested it - it works well at least in QEMU. A solution is still needed for ARM though. What are the problems there/what needs to be done? You need to pass a machine ID in r0, zero in r1, and a pointer to the devicetree in r2. We don't have a trampoline in cbfstool like we do for x86. So: * find machine ID from CBFS, load it into lb_tables * find .dtb load it into RAM, add entry to lb_tables In trampoline (ARMv7 assembly): * parse lb_table for machine ID, store it in r0 * parse lb_table for .dtb, store its address in r2 * branch to kernel entry point Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC-2014 Project for Coreboot
On Saturday, March 15, 2014 05:15:12 PM Kevin O'Connor wrote: Did you mean to send this only to me? I'm only sending to you and not the list, but I'd prefer the discussion to be on list. OOPS! I blame it on KMail's shitty Reply interface. On Sat, Mar 15, 2014 at 01:54:47PM -0500, mrnuke wrote: On Saturday, March 15, 2014 01:02:22 PM you wrote: On Fri, Mar 14, 2014 at 08:58:01AM -0500, Aaron Durbin wrote: CBFS is definitely not friendly to environments that can't map() the storage area of the CBFS itself. Beyond that in-storage format with metadata tightly coupled to the data itself leads to needing to stream large amounts of data through the working set just to locate the piece that is desired. CBFS is a neat system for accessing flash that can be linearly mapped into memory. If one has a flash device that can't be mapped into memory, I don't understand why one would want to use CBFS. Last I checked, CBFS stood for CoreBoot File System. I think that might mean it's the filesystem used by coreboot, but I'll have to double check and get back to you on that. I don't think that's a great way to look at it. The CBFS system is clearly designed to delineate a linearly mapped area of memory. I wouldn't recommend using it for something else solely because it starts with CB. Trying to adapt CBFS to block devices is going to complicate the CBFS code, and it still isn't going to be a good solution for those block devices. There are a number of filesystems already developed for block devices - why not just use one of them? And how exactly is this going to complicate CBFS code? And how would adding another filesystem parser into coreboot simplify things? The code has a bunch of media-open(), -close(), -read(), etc. operations that are unnecessary for basic linear memory mapped accesses. As you've already cited, even with these media accessors the system still doesn't work well for not mapped flash chips. By moving the abstraction up a layer, I posit that the CBFS code could be simpler, and the ARM code could be more capable. The coreboot code's interaction with the filesystem after memory init Aye, there's the rub: the assumption of after memory init. Before memory init everything is different on these non-mapped flash systems anyway. In past conversations I've been told the hardware (or builtin firmware) on these systems extracts a preset block from the flash and places it into sram, and this is how the bootblock/romstage is done on these systems. Thus the execute in place nature of bootblock/romstage in CBFS has no added value for these platforms. (should) largely boil down to load_file(char *name, void *address, int maxsize). Why not just end the abstraction there (ie, on these arm devices, implement a completely different load_file function). Did you have a look at our CBFS backending, by any chance? Yes. I'm sorry to be dismissive of your comments, Kevin, but it seems to me you do not fully understand the issue and its implications. I suggest you fully read this thread and CBFS bullfart (forked from GSoC-2014 Project for Coreboot) to get an idea of the problem and its subtleties. I have read the thread. I concur that I do not understand. -Kevin -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] CBFS bullfart (forked from GSoC-2014 Project for Coreboot)
Fucking Kmail is broken. How many times did it reply to the original sender instead of the list? On Friday, March 14, 2014 11:51:54 AM you wrote: On Friday, March 14, 2014 08:58:01 AM you wrote: CBFS is definitely not friendly to environments that can't map() the storage area of the CBFS itself. Beyond that in-storage format with metadata tightly coupled to the data itself leads to needing to stream large amounts of data through the working set just to locate the piece that is desired. On top of that the CBFS API doesn't allow for freeing up of used resources. Yes, there is the construct of map() and unmap(), but the used API in the code base returns pointers from map() and that means there is no way to free up the internal cache. I found out that keeping track of the last map() pointer allows you to free the cache during unmap(), as currently, operations come in map/unap pairs. Sadly, this is just an accident of how CBFS core works. This design also places the burden of cache management on the backend, which also has to deal with whatever device it deals with. A pretty bad abstraction model. However, read() doesn't solve the map() problem. read() and map() both need memory so in a constrained environment w/o memory-mapped access to the CBFS storage. The CBFS core doing map() + memcpy() doubles the resource requirements with no real gain. Lastly, the big reason for large map() requests is because we don't have a pipelined lzma path. Compression is don't care for the CBFS core until the stage is decompressed. By the time you realize you don't need to decompress, you've already map()ed the whole of romstage, which you now need to memcpy() to its destination. For the non-lzma files read() will work exactly as you described. Not for non-lzma stages, which is the relevant bit for the bootblock, before you get to romstage, where supposedly, you'll have RAM later on. I don't care that much anymore about this problem. I found a workaround for it, but someone else will drop the soap when doing the next little SoC. I noticed in your code [1] you just read in all of the CBFS in-core. Or did I misread that? And your init_default_cbfs_media() always re-initializes and reads the CBFS again? I take it that function only gets called once? Most likely because that is the bootblock. I only initialize the CBFS mirror once. If the code finds a valid CBFS signature in RAM, it skips the whole re-read-this step. [1] https://github.com/mrnuke/coreboot/blob/369998920685852246dcae4c3e88b268 c1 c9f2dc/src/cpu/allwinner/a10/bootblock_media.c -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] CBFS bullfart (forked from GSoC-2014 Project for Coreboot)
On Friday, March 14, 2014 12:23:03 PM Aaron Durbin wrote:
I found out that keeping track of the last map() pointer allows you to free
the cache during unmap(), as currently, operations come in map/unap pairs.
Sadly, this is just an accident of how CBFS core works. This design also
places the burden of cache management on the backend, which also has to
deal with whatever device it deals with. A pretty bad abstraction model.
Those map/unmap pairs are only when walking. The following functions
offer no ability to free the used resources in the common case usage
of CBFS_DEFAULT_MEDIA:
struct cbfs_file *cbfs_get_file(struct cbfs_media *media, const char *name);
void *cbfs_get_file_content(struct cbfs_media *media, const char
*name, int type, size_t *sz);
const struct cbfs_header *cbfs_get_header(struct cbfs_media *media);
If one is using cbfs with those functions resources are leaked.
So CBFS design is really b0rk3d then. I don't think the excuse that coreboot
runs only very briefly is valid in this case.
I don't think the cache management is a bad abstraction. It allows for
the backing store to optimize, but I can see the downsides as well.
All this talk is very cbfs-centric, but if something is needing
multiple pieces of data at once from that then those buffers need to
be managed. Either that is done explicitly by the caller or internally
to the storage supplier. The issue is finding a solution that targets
the least common denominator: not everything has a large amount of
memory to play with at the time of cbfs accesses.
map(...)
{
void *buf = buffer_gen(size);
read (offset, buf);
return buf
}
unmap(void * trilulilu)
{
buffer_free(trilulilu);
}
And no, you can't use the simple_buffer concept to do this elegantly.
Another idea is to abstract this into a buffered_cbfs_reader class, which
provides the CBFS backend with buffer management, then calls read(), and only
read() on the backend media.
static blablabla buffered_reader_memory_map(blablabla)
{
void *buf = chuck_norris_buffer_create(size);
media-context-read(offset, buf);
return buf;
}
static blablabla buffered_reader_unmap(void *blablabla)
{
chuck_norris_buffer_release(blablabla);
}
int init_default_cbfs_media(struct cbfs_media *media)
{
static struct non_mmapped_backed default_backend;
default_mmapped_backed_init(default_backend);
media-open = default_backend.open;
media-close = default_backend.close;
media-map = buffered_reader_memory_map;
media-unmap = buffered_reader_unmap;
media-read = default_backend.read;
media-context = default_backend;
}
This is of course just a shim which connects CBFS, Chuck Norris buffer
management, and a non-mmapped media backend. The buffer management is not
necessarily an easy task, but this is as simple as it gets, given the current
CBFS API. But, the difficulty now lies in making chuck_norris_buffer
efficient, which is a smaller problem than the initial.
OK, this doesn't solve the issue of resource leakage. Here, the CBFS core
needs to release its resources. It's a cleanup problem, however, not a trivial
one.
The CBFS core doing map() + memcpy() doubles the resource requirements with
no real gain.
I agree, but depending on where those memcpy()'s are happening it is
somewhat minor (which I think is the current reality). I will point
out that cbfs_meda has a read() function. You could have addressed
that with a patch, no?
No. The design of the CBFS core generally assumes mmapped storage is used.
That's the same reason you guys had a hard time refactoring the CBFS core back
in 2011 for ARM. It's the same reason you guys didn't do the best job at it
(no bashing/disrespect meant). It's the same reason we have this awkward
caching need, and the same reason I can't fix this with just a simple patch. I
estimate more than a dozen patches to do get romstage from CBFS with only one
read() The Right Way.
I actually looked at reducing usage of map(). It's nowhere near as
straightforward as it seems. You either break/create inefficient usage on MM,
or non-MM media. This is an apple and orange problem,
Lastly, the big reason for large map() requests is because we don't
have a pipelined lzma path.
Compression is don't care for the CBFS core until the stage is
decompressed. By the time you realize you don't need to decompress, you've
already map()ed the whole of romstage, which you now need to memcpy() to
its destination.
Agreed, but see my list of functions above which are the cause of
that. e.g. cbfs_load_stage() calls cbfs_get_file_content(). That's
your big mapping. However, the compression case I brought up is still
not possible to pipeline because of the lzma infrastructure we have.
That still needs to be addressed.
Remember that coreboot runs only very briefly? Once you have RAM up, this
excuse becomes valid. So
Re: [coreboot] GSoC-2014 Project for Coreboot
On Friday, March 14, 2014 09:46:53 AM ron minnich wrote: In other words, you can design a special case that makes doing a good design of the general case almost impossible. That's been done too; see UEFI. :) -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] CBFS bullfart (forked from GSoC-2014 Project for Coreboot)
On Friday, March 14, 2014 12:03:01 PM you wrote: Just to step back here. The flash is 8M. The system has 4G. What do I care if I leak memory? What's the issue you are solving? Thank you! You have pointed out the number one issue with this bullfart: that CBFS design is x86-centric. When you're in the bootblock on ARM, before ram is up, and you're leaking 20+ KiB of SRAM, when you only have 40 KiB left for stack + CBFS cache + romstage destination... See where, I'm going? Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] CBFS bullfart (forked from GSoC-2014 Project for Coreboot)
On Friday, March 14, 2014 02:07:59 PM Aaron Durbin wrote: I don't recall the coreboot runs only very briefly. However, once you do have ram the question is where does one get the ram? I think you are trivializing the problem -- not impossible, but it's definitely not just malloc(). I think we have a malloc() that just increments a free_ram_pointer. Whether this design is appropriate is beyond the scope of the CBFS problem. The malloc question belongs in coreboot core. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC-2014 Project for Coreboot
On Thursday, March 13, 2014 04:29:06 PM David Hendricks wrote: On Tue, Mar 11, 2014 at 7:55 AM, Naman Govil naman...@gmail.com wrote: Hi! Hi! Hi! a generic interface for accessing block devices on ARM SoCs so that coreboot could launch its stages from the block devices (an MMC for example). Seems interesting, but I am a little bit worried that the project is too narrow. We updated CBFS about a year ago to allow CBFS content to come from any media. This was required for the earlier ARM-based platforms which use SPI ROM since the content was not memory mapped as it is on x86 platforms. It should be reasonably easy to follow that model using MMC as a backing media. The problem is not that CBFS is not easily extendable to incorporate MMC; that's a 100 liner [1]. The problem is creating yet another API for accessing stuff, besides which we'll add an MTD and NAND API, etc. etc. etc. This would make us EFI-ish. IIRC Alexandru ran into issues with adapting the A10's MMC driver from u-boot to coreboot and making it fit into the bootblock, which was constrained by the amount of SRAM available on the A10. I am worried that you will end up fighting implementation-specific problems on the platform you choose instead of doing more interesting infrastructure work. I'm glad you brought that up. I ran into several problems, most of which were a result of CBFS's x86-centric design rather than the shortage of SRAM. A lot of CBFS callers love to generate map() calls, which means we as the backend need to provide the cache where to map that. When I get a map() call to map 20+ KiB of romstage into an area of SRAM I must provide, which must not overlap the final destination of romstage, I am wasting SRAM. If I only got a call to read(), with the destination being the resting place of romstage, that would eliminate the SRAM pressure a bit. My first solution was to make the CBFS cache and the romstage destination overlap. That needed a trivial change in CBFS, but that patch dropped the soap for various reasons. The alternate_cbfs implementation for that was also clumsy and difficult to read. Another problem I almost had was caused by problem #1. Since I needed a ton of RAM for the CBFS cache, I had to initialize RAM in the bootblock. Adding that code almost caused overgrowing the maximum bootblock size. I was getting close to the 24KiB limit with the MMC driver in there as well. I moved a bunch of non-essential stuff to romstage, and optimized the code layout a bit to not compile big bloat in bootblock. If I nuke the MMC debug messages, the bootblock goes under 13KiB, with MMC and raminit. Seems like there's also room for an MTD/NAND driver. So, I hope I killed any worries about fighting implementation-specific problems on the platform, which brings me back to the awkward design of CBFS. If we go the way of separate API for every possible bootblock media, you can have a Kconfig to select which to boot from. If, on the other hand, you have a well designed, unified block dev API, you can select your block device based on some some heuristic to decide which media to boot from. Make it a GPIO. Why is this better? You don't need two implementations of alternate_cbfs, which are extra code size, extra code, and generally look ugly and complicate the code. I hope I convinced both of you that this is not an easy, trivial problem, and will take a big chunk of GSoC time, as well as tons of dedication to get done right. The purpose is not to hack something together to boot. I already did that in my github branch [2]. The purpose is to Do It Right (TM). Naman, that means that if you pull this off, you'll need to be completely involved with the community for the twelve or so weeks of coding. You'll need to have patches up on gerrit early, take feedback, and involve in lots of discussion about the design. You will often be rewriting patches in the afternoon, in order to conform to the new design ideologies you discussed in the morning. You will repeat this process many times. You'll have to get intimate with the coding standards and ideologies of coreboot. I suggest you demonstrate a profound understanding of the foundation of our coding standards in your application, by correctly formatting any example code included therein. Your goal must be to have your work merged in coreboot master, and your board booting from MMC/SD with that code, by the pencils down date. Alex [1] https://github.com/mrnuke/coreboot/blob/369998920685852246dcae4c3e88b268c1c9f2dc/src/cpu/allwinner/a10/bootblock_media.c [2] https://github.com/mrnuke/coreboot/commits/cubie_mmc -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] I've turned on paging as a test
On Wednesday, March 12, 2014 08:03:04 AM ron minnich wrote: On Wed, Mar 12, 2014 at 6:33 AM, Peter Stuge pe...@stuge.se wrote: Do we want ACPI? We've had it for years. Do we want UEFI runtime services? They're required for ARM V8 ;-( Are you telling me something like linux will have to rely on said runtime services, or are those only required in order for your firmware to be certified? There goes the elegance of ARM down Crapper's hole. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] I've turned on paging as a test
On Wednesday, March 12, 2014 05:07:33 PM Peter Stuge wrote: Oh, and since we don't have a project-wide habit of distinguishing between virtual and physical it seems that any use of paging currently in coreboot can only be a big ugly hack. :\ It would break microcode updates on VIA Nano, assuming the NDA docs I have are correct. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] I've turned on paging as a test
On Wednesday, March 12, 2014 07:08:16 PM Peter Stuge wrote: A 1:1 mapping is (obviously, I hope) equivalent to not having paging at all for the purpose of this discussion. Not for Via NANO micrococde updates. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Friendly reminder: Please just send plain text messages to the list
Why don't we just configure the mail server to reject messages containing HTML? Most instances of HTML I've seen have been accidental anyway. It's not like there was ever an instance of html being useful here. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Friendly reminder: Please just send plain text messages to the list
On Monday, March 10, 2014 08:54:12 AM ron minnich wrote: I think what we need to do is make this thread continue until it has consumed more space then one month's worth of HTML. I think we're still in the bikeshedding of original request stage. First off, whining about usage of HTML because of one's mobile data plan: I don't care what data plan you have. When you come to a public list, you should be prepared to adapt to the needs of the community using that list, not the other way around. If enough people in said community had 30 MB data plans, and everybody only used mobile phones for emailing, then your request might sound half-reasonable. But seriously? 30 MB data plan? I didn't know they sell those anymore. I heard those were common in the bronze age. I have to really shop around to get anything less than 1GB. I admit, I just happen to have unlimited data (remember, we're in the space age now). I don't usually use a mobile connection to check my email, but when I do, it's because I'm bored. Seriously, don't use your mobile plan for reading html email if it's such a big issue for you. Remember, most people weren't even born when the bronze age ended. All in all, this request seems selfish, although based on a reasonable premise. Sure, HTML email sucks, and if what one really wants to do is convey information, then plaintext is the way to go. :-) [evil face] So, while I agree we don't really need HTML email for this list, it's a nice way to piss off people every once in a while. It's fun. And it's fun to sidetrack a thread whenever someone accidentally sends some HTML bits. ron I'd normally take this out of my emails, but it's more bits of data. Yay! On Mon, Mar 10, 2014 at 8:48 AM, Sam Kuper sam.ku...@uclmail.net wrote: On Mar 10, 2014 3:32 PM, Björn Busse m...@baerlin.eu wrote: On Mon, Mar 10, 2014 at 04:21:00PM +0100, Peter Stuge wrote: Corey Osgood wrote: Can you please point me to when this became policy on the coreboot mailing list? I think it's pretty much a common sense policy on every mailing list. +1, Also my understanding. The trouble with invoking common sense is that what constitutes it isn't universally agreed. I measure common sense compliance as the inverse of the number of people I piss off. It's always a relative measure, but a damn fine one. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot More signatures [sidetrack] I've seen some really stupid signatures used on this list. My all-time favorite is something along the lines of To think outside the box you really need to be intel inside. I have no idea how the guy using this thought this might even remotely be an intelligent thing to say (notice I spelled intelligent correctly, not intel which is a misspelling). Second on the list are people leaving their contact information in their signatures. Really? I have that in the From: field if I need to contact you. Truth be told, I haven't not contacted you because I didn't know how to reach you. You just aren't that likable. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] protect flashing
On Monday, March 10, 2014 06:11:41 PM Marcus Moeller wrote: Hi all. Is there a way to protect against re-flashing, e.g. by using a password or an encryption key? Don't believe everything you read in whitepapers and sales brochures. Passwords and/or encryption have nothing to do with protecting flash contents. Chances are you'll want to work with the write-protect pin on the chip, and its write-protect registers. Have a look at what google did for the chromebooks. That's a pretty solid mechanism Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] qemu
This was supposed to go to the list, not Ron alone. On Sunday, March 09, 2014 08:26:05 PM you wrote: On Sunday, March 09, 2014 05:14:51 PM you wrote: Story so far: 1. pick q35 chipset 2. qemu -M q35 etc. etc. $ qemu-system-i386 -M q35 --bios build/coreboot.rom -ENOREPRODUCE 1. pick i440fx chipset. 2. qemu -M pc etc. etc. qemu-system-i386 --bios build/coreboot.rom -ENOREPRODUCE Endless repetitions of qemu: unsupported keyboard cmd cmd=0x00 or 0x80 -ENOREPRODUCE Same with qemu-kvm. This is with crossgcc. I'm disappointed it's this fragile. I'm worried that feature push has gotten ahead of reliability push. Or your qemu installation is b0rk3d. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] qemu
On Saturday, March 08, 2014 10:30:51 PM ron minnich wrote: snip q35 chipset. That's the only change I make. qemu-system-x86_64 --bios build/coreboot.rom -cdrom tinycore.iso -boot d + -M q35 There, I fixed it for you! Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Set Top Boxes and Linux?
On Monday, March 03, 2014 06:05:49 PM ron minnich wrote: The new chromeboxes are pretty compelling and modern, so it's hard to see the case for those very old boxes. Blobs? -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] #202: Error building coreboot for Samsung Exynos5 Google Snow
On Wednesday, February 26, 2014 11:03:25 PM coreboot wrote: #202: Error building coreboot for Samsung Exynos5 Google Snow +-- Reporter: bluestore.logmein@… | Owner: stepan@… Type: defect |Status: new Priority: major| Milestone: Component: coreboot | Keywords: Dependencies: | Patch Status: there is no patch +-- We still have trac? How do people still find that old site? build/ec/google/chromeec/ec.romstage.o: In function `google_chromeec_early_init': /home/suporte/coreboot/src/ec/google/chromeec/ec.c:117: undefined reference to `recovery_mode_enabled' PEBKAC. Or PEIKconfig. Sounds like a build without CONFIG_CHROMEOS. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] how to model the Quark architecture
On Tuesday, February 25, 2014 07:46:50 AM ron minnich wrote: I plan to use the intel code as as guide, but not pull it in directly. We have source, we should do it right. I am going to take Aaron's suggestion and structure it as baytrail is structured. I was thinking we could put the existing code in vendorcode/, and call that from our stages. No need to make a complete rewrite, and no need to maintain a fork. Of course, this is probably easier said than done, but then we do the same for AGESA. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] how to model the Quark architecture
On Tuesday, February 25, 2014 07:28:04 PM Peter Stuge wrote: Stojsavljevic, Zoran wrote: This what I have proposed binds to current Coreboot FSP support/framework Even though seamless integration of FSP with upstream coreboot is probably what Intel would want that approach is not neccessarily a satisfactory solutoin for the greater coreboot community. It's the worst solution, and a lot of persons in the community, myself included, are very opposed to anything of the nature. If one wants to use coreboot, then one should be prepared to provide coreboot-quality source. If providing source is not something that person/company wants to do, then coreboot is not for them. There are other options in the market. As a rights holder in the coreboot project, I am of the opinion that distributing coreboot with FSP binaries whose source is not also provided is a violation of the coreboot license and an infringement of my copyright. We've allowed libpayload to be BSD-licensed in order to allow proprietary blobs. The payload and onward is where blobs can appear without source, but not any earlier. The intention is, in my view, that anything doing with essential hardware initialization --the stuff needed to load a payload and boot the OS-- must come with a GPLv2 compatible license. Anything else is up for grabs in the payload. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] `DEBUG_INTEL_ME` (incorrectly) only selected for Intel BD82x6x
On Wednesday, February 19, 2014 11:06:40 PM Paul Menzel wrote: looking through `src/console/Kconfig` I noticed You mean 'src/Kconfig' ? if SOUTHBRIDGE_INTEL_BD82X6X DEFAULT_CONSOLE_LOGLEVEL_8 This is a layering violation. We shouldn't have hardware-specific options in top-level Kconfig. This should be moved to southbridge Kconfig, and not depend on LOGLEVEL. Maybe we need to move ME handling to a common dir and handle the Kconfigs there. which seems odd as currently other chipsets needing the Intel Management Engine were submitted. $ git grep DEBUG_INTEL_ME [...] Smells like copypasta. Yet another reason to consider unifying ME handling across southbridges. I am unable to test this, so it would be great if somebody else could fix this. I don't blame you for not owning and/or not wanting to own intel hardware. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFC] board_status: Add serial log to `serial_console.txt`
On Thursday, February 20, 2014 12:11:58 AM Paul Menzel wrote: Until this is done, such data is lost and it is not nice to ask users to rerun stuff again with such a patch. So please, could we just decide on a name for the serial/USB debug log file and be done with this? Not a lot of people are going to do this anyway. Paul! It's been decided! It's dead! Drop it! Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] how to model the Quark architecture
On Tuesday, February 18, 2014 07:33:43 PM Peter Stuge wrote: I'm sorry I said anything, I was silly to think that design discussion would be possible. I've been following this thread for the last couple of days, and I still have no idea what you're talking about. I bet mostly everyone else feels that way. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] A Growing Concern
On Tuesday, February 18, 2014 12:21:38 AM amlo...@tfwno.gf wrote: As a privacy and freedom oriented PC/Linux user, it scares me how modern day devices are becoming extremely proprietary. Companies are beginning to ship their laptops/tablets with proprietary EFI systems which have some nasty things in them. I recently purchased a Dell Venue 8 Pro(one of many upcoming 8 windows 8.1(x86) tablets) and while i was searching through its BIOS, i noticed that it had the computrace option activated Well, it's your fault that this concern is growing. You bought a windows device. You paid microsoft to develop proprietary software, and you paid an IVB to develop proprietary firmware, instead of paying someone to develop free software and firmware for your device. The market is rich enough to allow you to make that choice. All I ask of you is to try and make EFI alternatives to all these upcoming devices. So, you paid someone to write firmware, which you neither trust nor like, but want me to do it for free? If software/firmware freedom is important to you, then I suggest you return the device to the store -- assuming you have this option -- and purchase a device which offers you what you want. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] has intel been hacked?
On Monday, February 17, 2014 08:24:12 AM ron minnich wrote: downloadcenter.intel.com gets the following error, and has for some time: Cannot connect to the real downloadcenter.intel.com Something is currently interfering with your secure connection to downloadcenter.intel.com. *Try to reload this page in a few minutes or after switching to a new network.* If you have recently connected to a new Wi-Fi network, finish logging in before reloading. If you were to visit downloadcenter.intel.com right now, you might share private information with an attacker. To protect your privacy, Chrome will not load the page until it can establish a secure connection to the real downloadcenter.intel.com. so, I wonder what it all means? That's just Chromium/Chrome bleeping up. Any other browser connects just fine. The SSL cert is valid. Alec -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Alias motherboard?
On Sunday, February 16, 2014 08:40:43 AM Oskar Enoksson wrote: Ok, but when I look inside my DL145G1 the text AMD Serenade is printed on the motherboard. In fact, HP DL145 G1 is not a motherboard, it's a server which uses the AMD Serenade motherboard. Does the vendor BIOS say HP DL145 G1 or AMD Serenade ? -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SeaVGABIOS with native vga init (Need testers)
On Sunday, February 16, 2014 11:42:57 PM Peter Stuge wrote: Denis 'GNUtoo' Carikli wrote: [...] The commits from your branch which you pushed with me as author and which four other developers reviewed and finally submitted, without spotting bugs present in some commits and with talking to me, will be reverted because they're nowhere near ready for inclusion in the repository. Well, the patches to revert those commits have been up on gerrit for over a month. Why you chose to not merge them is beyond me. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Alias motherboard?
On Monday, February 17, 2014 06:27:34 AM Oskar Enoksson wrote: On 02/16/2014 09:08 AM, mrnuke wrote: On Sunday, February 16, 2014 08:40:43 AM Oskar Enoksson wrote: Ok, but when I look inside my DL145G1 the text AMD Serenade is printed on the motherboard. In fact, HP DL145 G1 is not a motherboard, it's a server which uses the AMD Serenade motherboard. Does the vendor BIOS say HP DL145 G1 or AMD Serenade ? I think the vendor BIOS said HP DL145, not AMD Serenade. Then the board is HP DL145, not AMD Serenade. Don't mistake the bare hardware for the motherboard. Firmware plays a very big role. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Alias motherboard?
On Monday, February 17, 2014 08:21:55 AM Oskar Enoksson wrote: On Monday, February 17, 2014 06:27:34 AM Oskar Enoksson wrote: On 02/16/2014 09:08 AM, mrnuke wrote: On Sunday, February 16, 2014 08:40:43 AM Oskar Enoksson wrote: Ok, but when I look inside my DL145G1 the text AMD Serenade is printed on the motherboard. In fact, HP DL145 G1 is not a motherboard, it's a server which uses the AMD Serenade motherboard. Does the vendor BIOS say HP DL145 G1 or AMD Serenade ? I think the vendor BIOS said HP DL145, not AMD Serenade. Then the board is HP DL145, not AMD Serenade. Don't mistake the bare hardware for the motherboard. Firmware plays a very big role. Ok. Although my guess is that very big is probably incorrect in this case. My guess is that they are identical. Guess, eh? And that's exactly why we now mandate a board-status report. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] licensing text
On Wednesday, February 12, 2014 03:16:43 PM ron minnich wrote: let's do it this way. Why doesn't one of you just propose the wording. Let's try this again: * LICENSE_TAG: GPLv2+ (See README in top-level directory for explanation) * LICENSE_TAG: GPLv2 (See README in top-level directory for explanation) * LICENSE_TAG: BSD3c (See README in top-level directory for explanation) * LICENSE_TAG: BSD2c (See README in top-level directory for explanation) * Public domain (See README in top-level directory for explanation) Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Ram Init: Intel i945: Timing parameters
On Friday, February 14, 2014 12:38:58 AM Vladimir 'φ-coder/phcoder' Serbinenko wrote: Sure: 1) Locate intel offices 2) Locate their top-secret safes 3) Observe security 4) Buy military gear 5) Recruit and train a company (~200 people) for a year 6) Launch assault on the office 7) Break into the safe 8) Get out of Intel building 9) Read the documentation Don't do that. As a member of the US Armed Forces, I will stop you. Instead, why not get enough cash, buy Intel, then you can make executive decisions. It's legal. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] licensing text
On Tuesday, February 11, 2014 11:30:04 PM ron minnich wrote: This note is motivated by mr.nuke.me's recent CLs with a short-form GPL notice in them. I like that notice but I think it needs a tweak, then we can just use it everywhere. Which was motivated by some of your gerrit comments. This file is part of Coreboot Project. It is subject to the license terms in the LICENSE file found in the top-level directory of this distribution and at http://www.coreboot.org/license.html. No part of the Coreboot Project, including this file, may be copied, modified, propagated, or distributed except according to the terms contained in the LICENSE file. OK, I admit, I painted it because I'm sure the shed will end up with a different color :-) Yes, yes, no html formatting in emails etc. etc. but sometimes rules must be broken. I had to turn on html in Kmail to see the paint. Now that I can see the paint... 1. One has to consider that every line this text takes is one less line of code that is visible when opening a file. So, is that the absolute minimum we can get to. I've seen a few projects which use a license identifier tag, along with an explanation in the README as to what that tag means and how to interpret it. 2. There's no longer a place to license under GPLv2 or GPLv2+. It's always a nice touch, and a fun step, to decide whether a certain file you wrote should go under v2 or v2+. 3. Re-licensing everything under v2 will piss a lot of people who like the +. Some of those v2+ contributions are heavily copied from other v2+ projects (read: allwinner from uboot), and I'm not sure that you can simply strip the + from the license of such files, as you're potentially misrepresenting the intent of the author(s). I regret that it contains a URL, but in these dark times, one must make concessions. Old text contained both a URL and address. I think this is a step forward. So, does this work or do people have objections? I need to keep my reputation as the most annoying guy. Of course I have objections :p. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] The fallacy of the CONFIG_* plague
=== START_TLDR /* Skip to END_TLDR if you're short on time */ ===
It seems that we're using #if CONFIG_ like free coffee and cookies in a
conference. Without thinking too much of it. And we're using very much of this
in generic code, which is, as I will point out why shortly, a very bad idea.
It wouldn't matter as much if we only used CONFIGs to control the build
process, or some mundane board-specific options. One problem is, that we've
started using them excessively in generic code. Generic code should be just
that, generic. If we need it to behave one way or another, we should do so by
the vales we pass it not by board-specific Kconfigs.
Take lib/ for example. We should be able to compile, the entire directory into
a set of static libraries:
* libcorebootlib_rom.i386.a
* libcorebootlib_ram.i386.a
* libcorebootlib_bootblock.armv7.a
* libcorebootlib_rom.armv7.a
* libcorebootlib_ram.armv7.a
And use those libraries as-are, in every single board and component, without
their behavior depending on Kconfigs. I am allowing for stage-specific
versioning here due to the joys early init may throw at us.
The same reasoning applies to chip-generic code -- basically most things _not_
under src/mainboard/.
Case in point: http://review.coreboot.org/#/c/5199/
The intent is to use CONFIG_, not for the purpose of solving a practical
problem, but just for the sake of fixing a build failure. It feels like a if
it compiles, let's ship it mindset.
Who cares, really? There is a very practical aspect to lib-izing generic code,
and that is the abuild step. We can speed that up tremendously by being smart.
ccache helps a bit, but only so much.
Another practical aspect is eliminating confusion relating to what does the
code do now, whith _this_ option instead of _that_ option?.
=== END_TLDR ===
So, instead of having a generic function doing
void function(void)
{
#if IS_ENABLED(CONFIG_HAVE_LOLLIPOP)
printk(BIOS_YUMMY, Sucking on a lollipop\n);
#else
printk(BIOS_SUCKY, Meanie!!\n);
#endif
}
We make it dynamically polymorphic:
void function(bool has_lollipop)
{
if (has_lollipop)
printk(BIOS_YUMMY, Sucking on a lollipop\n);
else
printk(BIOS_INFO, Mister stole my lollipop\n);
}
Let the mainboard pass the lollipop option instead of Kconfig-izing it. The
only place where code flow/values should depend on anything CONFIG_* should be
in (tentative list warning):
* board-specific code
* enabling debug options not used in production code (irrelevant for abuild)
* linker scripts
* very early init (assembly part of the bootblock)
And of course, we use the linker to garbage-collect unused functions for the
sake of space.
Q.E.D.
Thoughts, comments, concerns, paint ideas?
Alex
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] licensing text
I meant to send this to the list, not Ron alone. Sorry Ron. On Wednesday, February 12, 2014 10:18:33 AM you wrote: Note that if a file ALREADY has notice in it, then we don't change anything. So, in the limit, we can start using this new notice for (e.g.) your stuff and only apply it as we wish. That said, would you like to take a pass at the wording? Green, maybe :-) Black and/or white!! * LICENSE_TAG: GPLv2+ (See README in top-level directory for explanation) * LICENSE_TAG: GPLv2 (See README in top-level directory for explanation) * LICENSE_TAG: BSD3c (See README in top-level directory for explanation) * LICENSE_TAG: BSD2c (See README in top-level directory for explanation) * Public domain (See README in top-level directory for explanation) Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] The fallacy of the CONFIG_* plague
On Wednesday, February 12, 2014 07:40:58 PM Peter Stuge wrote: But there is generic and there is generic. If something is known already at build-time then I think it's a bad idea to push the decision to run-time. And yet, we have many places where we take decisions which belong at runtime, and make them at compile-time. One such example is limiting the SATA speed on butterfly. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] The fallacy of the CONFIG_* plague
On Wednesday, February 12, 2014 07:44:42 PM Patrick Georgi wrote: I like solving things at compile time that can be solved at compile time (and in fact even earlier, if possible). No need to store Mister stole my lollipop if the board is guaranteed to ship with one. That's something we can fix by smart design and linker garbage-collecting. I made my example as simple as possible for the sake of argument. The smart way to approach the problem will of course depend on the specific problem. I can also turn that around and say why store all debug strings if a production system will never run above BIOS_SPEW ? Quite frankly, I like the way we reduced this problem for the console. Coming back to the lollipop example, it makes sense to store Mister stole my lollipop even if the board is guaranteed to come with one. If the lollipop malfunctions for whatever reason, then the board can indicate so in has_lollipop. It's much more elegant that a silent crash or silent somethin' ain't workin'. I've been doing exactly this for the PMU on the cubieboard. If for some obscure reason, it doesn't identify itself properly, we handle this case elegantly, and still boot, albeit at a reduced cock speed. Turquoise, please. Dark shade or a lighter shade? Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] The fallacy of the CONFIG_* plague
On Wednesday, February 12, 2014 01:00:59 PM you wrote: I can also turn that around and say why store all debug strings if a production system will never run above BIOS_SPEW ? I meant BIOS_INFO here. elegantly, and still boot, albeit at a reduced cock speed. Please read that as clock. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] The fallacy of the CONFIG_* plague
On Thursday, February 13, 2014 02:21:14 AM Peter Stuge wrote: Don't confuse the product that ships with coreboot for what it becomes after you've modified it. Are we bikeshedding the example here? Do you expect Intel to give you support after you've overclocked their CPU way out of the spec of the shipped product? And this is relevant how? Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFC] board_status: Add serial log to `serial_console.txt`
On Tuesday, February 11, 2014 12:04:33 AM Vladimir 'φ-coder/phcoder' Serbinenko wrote: If we let user supply files at all, it should be added to report, not replace files, and it should have some prefix to clearly indicate that user was involved in creating them. E.g. user_serial_log.txt There is a point at which the information becomes too much. What is really relevant, in my opinion, are the following three points: 1. Is it an unmodified commit in master (AKA, not -dirty). 2. Does it boot? 3. What does not work, if any ? Point 1 and 2 are answered by cbmem -c | head. It answers point 1 with the first line of output, and point 2 by the fact that getting anything from cbmem means you've already booted your system. Point 3 is more complicated, and it seems it is because of this point that we want to collect any and all information we can possibly get our hands on. Other than cbmem -c | head and .config, a majority of people just don't care about all the pesky details. They're only useful when debugging problems some poor guy or gal is having. In that case, we can ask them for this info manually. It's not of any use in tracking down which revision + config works on _this_ board. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] HP Chromebook 14 (Falco)
On Saturday, February 08, 2014 05:30:38 PM Peter Stuge wrote: If the project could change to work somehow differently and that would help contributors then I think that's something we should consider identifying and doing. Allow git merging. Forced cherry-picking is a PITA for almost everybody. The patches would still go through the same review process, but once the branch is go, the entire branch gets merged at once. Objections? It's a natural consequence of the fact that companies can't always immediately push all their work upstream. What's the difference from Linux kernel development again? See @above. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
