[coreboot] Re: Recent disciplinary action taken
Hello list, On Wed, Oct 2, 2024 at 7:40 AM David Hendricks via coreboot < coreboot@coreboot.org> wrote: > Dear coreboot community members, > > Recently there was some unpleasant activity on Gerrit which violated our > community’s guidelines regarding respectful conduct. In this case the > coreboot leadership team determined that the behavior in question fit a > long pattern about which the individual had been previously warned. As a > result we have decided to remove Nico from our community for a period of 1 > year. We hope this will be a sufficient cooling off period and that we will > not need to take more drastic steps in the future. > David, I see you are one of the three members of the leadership team [1]. Could you please provide the following, privately if necessary? - the minutes for the meeting in which the decision was made (which might contain references to the documents below; if the meeting minutes are not available, I would like to know why) - links to the aforementioned "unpleasant activity on Gerrit" - the guidelines from [2] or [3] (I could not find a document called "community guidelines") that were violated Not knowing what happened nor why makes me afraid to contribute, lest the same fate befall me as well. Especially considering that Nico has been a role model for me as I was learning the ropes of firmware development, so most of the things about coreboot as well as authoring and reviewing changes I have learned from him. > As we've said in the past, we trust that developers in our community are > acting in good faith and can generally resolve issues on their own. In > cases where two sides cannot reach an agreement, for example in a code > review, we expect all engagement to be respectful and to help drive toward > a solution. For technical matters this often means starting a mailing list > discussion, bringing an issue up during the coreboot leadership meeting, > starting a task force to tackle a large problem, or other means of > gathering input and collaborating. > > Personal matters should be brought to the leadership team directly. We'll > listen to any complaints or frustrations, but cannot tolerate personal > attacks made on Gerrit, the mailing list, or other forums. It is always > required that we treat others in a professional manner and communicate with > respect, regardless of how strongly we may feel about a particular issue. > A tiny remark about professional manner: when interacting with others I know, I like sprinkling a bit of humour in my messages, but without being disrespectful towards anyone (no dark humour and no making fun of others) or compromising my knowledge/abilities (do not overdo it and consider that not everyone might get it). I believe this does not make me unprofessional, but I am happy to listen in case anyone disagrees. Other than that, I agree with the above, but I also believe it is important to be aware that misunderstandings can and will happen, especially considering that people from all over the world can contribute, each with their own culture and tradition. Not everyone is a native English speaker (even if it does not seem like it, I am not). Not everyone is capable of noticing when a discussion is getting too heated/tense, let alone do something to end it before it is too late (I am trying to get better at this). Not everyone communicates the same way, e.g. autistic people tend to communicate in direct and literal ways that can be misinterpreted by non-autistic people [4] (I am autistic, I have had this happen before), whereas other autistic people have no issues with this communication style. I believe that the information in [4] (especially the list of 12 rules) is valuable and I would appreciate having them integrated into our own guidelines, although I agree they should be guidelines rather than strictly-enforced rules: misunderstandings are *still* inevitable and will happen. In case of a misunderstanding, I think the most sensible way to proceed is for someone (preferably one of the participants) to notice that "something feels wrong" and remain calm, disengaging from the discussion if needed (e.g. wait before replying to an email or review comment). If possible, try to bring it up without pointing fingers, e.g. "I feel this discussion is heating up: is there anything I can do to help, or am I reading into things?" or (quoting a response) "This sounded quite rude to me, was it intentional?". This requires being able to recognise that tension is building up and restraining one's impulses; I understand this is not trivial to accomplish, especially if one is susceptible to getting angry (e.g. me). > If anybody feels that a discussion has become too heated, or that somebody > is not being treated respectfully, or are simply unsure of how to proceed > in a difficult situation, please reach out to the coreboot leadership and > we will chart a path forward together. > ___ > coreboot mailin
[coreboot] Re: links for "board-status" not found
Hi lödur, Gitiles is disabled (I forget the reason, but it was severe enough to require disabling Gitiles in the meantime). So you would have to clone the relevant repository or use a mirror. For the first Gitiles link, you can look at the GitHub mirror instead: https://github.com/coreboot/coreboot/tree/main/util/board_status On Mon, Sep 23, 2024 at 6:31 PM lödur via coreboot wrote: > Hello, > > on page: > https://coreboot.org/status/board-status.html > the both links for > "a tool in the coreboot repository" > > https://review.coreboot.org/plugins/gitiles/coreboot/+/HEAD/util/board_status/ > "board status repository" > https://review.coreboot.org/plugins/gitiles/board-status/ > point to > "Not Found" > > Could you repair these links, please. > > Thanks, > > loedur > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Enforcing coreboot as lowercase
Hi, On Thu, Jul 4, 2024 at 3:48 PM Arthur Heymans wrote: > > Hi > > The coreboot trademark is registered as lowercase. > We enforce this in for instance commits, even when normal grammar would > dictate uppercase at the start of a sentence. > > This makes sense for very well known brands, companies and products like > "eBay", "iPhone", "AMD". They are all very well known trademarks and they > have some uppercase letter in them in atypical places. For these words > grammar exceptions seems reasonable. > > Coreboot is a reasonably well known as a project, but little people know > about the specificity of the trademark. This often causes confusion on people > either reading "coreboot" at the start of a sense, where it looks > grammatically wrong, making it even look unprofessional in the eyes of some. > This is because there is no other uppercase letter inside coreboot that would > make it a typical exception to regular grammar rules. > > People getting into the project making the mistake at the start of a > sentence, might get the wrong impression of too many idiosyncrasies. On top > of that it takes a non zero amount of effort on people in the project to > educate others on this trademark thing. > > Also trademark are typically a bit more broad than exactly how they are > registered. I cannot start a company called iNTel or aMD that makes chips. I > cannot put a product on the market called "IPHoNE". I think the same applies > to "coreboot". > > So my question is: can we relax the trademark in lowercase enforcement? I > would suggest to simply allow both ways. I am not sure if I understood you correctly. Are you proposing to give up trying to defend the spelling of the project's name because too many people write it wrong and educating them is too much effort? If so, I think this is a self-defeating attitude and I completely disagree with it. Or is it that the trademark only covers the all-lowercase "coreboot" spelling, so one can use a name like "CoReboot" (e.g. for something unrelated) without infringing the "coreboot" trademark? In that case, making the trademark case-insensitive makes sense. Or is it something else? Then... *confused noises* > Arthur Heymans > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: 2024-06-26 - coreboot Leadership Meeting Minutes
Hi list, On Thu, Jun 27, 2024 at 2:00 PM mina--- via coreboot wrote: > > # 2024-06-26 - coreboot Leadership Meeting *snip* > ### [Martin] Merge SLOs > * Can we define objectives for timeframes to get patches merged to > different areas in the codebase? > An individual mainboard that doesn’t affect the rest of the codebase doesn’t > need as much scrutiny > as core code that affects every platform. > > * Mainboard: 1 week? > * FelixH: So what do we do if we get past this timeframe? Just merging > anything because it’s passed > the SLO period seems like a bad idea. > * David: This is designed to help people who are new to the project. We > don’t just want to merge > stuff, but for isolated code, maybe we can look the other way at > imperfections. > * FelixH: Frequently add comments and mark as resolved. > * David: SoC code still needs to be held to higher standards. > * David: We still expect authors to be responsive to feedback. > * FelixH: We still need reasonable patches as well - one logical change > per patch. > * Martin: Do we want any areas besides Mainboards? What about SIOs? > * Werner: Maybe drivers? > * Max: Everything other than mainboards can be used by multiple vendors? > * Martin: It doesn’t seem unreasonable to try to get things merged in a > month. > * FelixH: It would be good to have a list of things to look at. > * Martin: Send out an email with a list of patches which will be looked at > in the next meeting? > (Yes) > * Add a month SLO for drivers & SIOs initially. Would it make more sense to aim for timely replies, i.e. avoid patches sitting unreviewed for an indefinite amount of time? IMHO, aiming to submit mainboard ports after 1 week sounds unrealistic: authors won't necessarily be active on Gerrit every day, and some mainboard ports (e.g. laptops) may take more time to review; mainly because EC support, but if possible one could do an initial port and add EC support in a follow-up (and hope said follow-up also gets through). About helping newcomers, I think what would help the most is to streamline the review process. For example, be less nitpicky about style. I know, I myself am guilty of that. Also, instead of asking everyone to manually change stuff that autoport or intelp2m generated, fix the tool in question. It took me too long to gather the resolve to make https://review.coreboot.org/82401 (good thing it's submitted). Yes, that comment is likely wrong on most of the boards in the tree. And yes, I remember seeing a relatively new mainboard port with an unreasonably low DSDT revision number, with that bloody comment... In addition, having an up-to-date mainboard porting guide (tutorial, part 4) that helps guide people through the process would be fantastic, as there have been a few times where pointing others to such a guide would've been very useful. Plus, I've seen many people make less-than-ideal decisions in the past, e.g. edit existing boards instead of adding a new one (even if it's a copy of an existing board), "cross-flash" a coreboot build for a different board (oh no, the GPIOs), or using Intel RVPs (Reference and Validation Platforms) as a reference. Clarification regarding RVPs: the code for newer RVPs is quite convoluted for a beginner because variants, ChromeOS support and EC firmware SKU selection; older RVPs (CML and earlier) are mostly untested and unmaintained these days, so they're not great to use as a reference. Plus, most newcomers are retrofitting coreboot onto commercially available devices: they do not always have access to board documentation (schematics and/or boardviews), which makes configuring things like PCIe clock source/request mapping substantially harder; some boards don't even have a proper console (and having to rely on flashconsole for porting is last-resort misery). Because of this, the porting process differs from that used for the RVPs, where board documentation is available, there's at least one (if not more) UARTs to get coreboot logs out of, and one may even have access to blobs' source code. > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Feature #461] (In Progress) Replacing Haswell mrc.bin blob with free software
Issue #461 has been updated by Angel Pons. Category changed from board support to chipset configuration Status changed from New to In Progress Start date changed from 02/16/2023 to 04/01/2020 % Done changed from 0 to 30 Related links updated Affected hardware changed from T440p and other to All Haswell mainboards # Current state of the meme magic (Haswell NRI) ## Done - Native non-raminit stuff (already submitted): needed for 9-series boards with Broadwell MRC.bin e.g. https://review.coreboot.org/68188 - Bare minimum memory initialisation (just enough meme magic to be able to boot): patch train up until https://review.coreboot.org/64198 - S3 suspend/resume and fast boot support: https://review.coreboot.org/81897 - Sense amplifier offset training: https://review.coreboot.org/81948 ## Implemented internally in the giant bowl of spaghetti, but in need to clean up the code before publishing - 1D margin centering algorithms (used for various training steps) - Setting non-training command rate (to 1N or 2N, we currently remain at 3T) and LCT (Late Command Training) - 2D margin centering algorithms (used for various training steps) - Power training (optimisation meme magic to reduce power consumption) - TAT (Turnaround Training, a performance improvement) - The raminit console (a half-arsed thing that allows playing around with settings over UART/usbdebug) ## Not implemented or not working yet - Broadwell support (I once got a Broadwell ULT system to boot without MRC, but I had to commit unspeakable horrors to the already messy codebase) - Properly programming some registers about DIMM energy (doesn't seem to be required, but the logic to program these is horribly convoluted and I haven't felt like figuring out how it works) - Automatic overclocking support (will require redesigning how the MPLL handling works, because it currently stinks) # TL;DR - With what's currently submitted, choosing Haswell NRI in menuconfig **WILL NOT BOOT**. It says "NOT WORKING" in the prompt. - Current top of tree (what you should use if you want to try Haswell NRI) is https://review.coreboot.org/81948 - With the aforementioned changes from Gerrit, booting should work. S3 resume should also work, but please test in advance. - **BACK UP YOUR STUFF!** I will NOT be held responsible by any data losses arising from the use of the current state of Haswell NRI. - Because not all training steps are ready yet, performance and power consumption are not optimal. Fix is to finish upstreaming them. - Also, do NOT try to overclock the RAM under any circumstances. You will only make your system much more unstable for no reason. Feature #461: Replacing Haswell mrc.bin blob with free software https://ticket.coreboot.org/issues/461#change-1854 * Author: akjuxr3 akjuxr3 * Status: In Progress * Priority: Normal * Assignee: Angel Pons * Category: chipset configuration * Target version: none * Start date: 2020-04-01 * Related links: https://review.coreboot.org/q/topic:haswell-nri * Affected hardware: All Haswell mainboards Currently in case of the ability to run as less amount of closed source software as possible and still have Microcode updates the reduced Intel ME with disabled bit in IFD and the lga1155 or the mobile versions of those cpus are the only option for x86_64 out there. The next cpu generation (Haswell) inside for example T440p and W541 require the binary blob mrc.bin Are there any plans of replacing the Haswell mrc.bin with free software? Or have the x86_64 platform be given up when the goal is to run just free software and the people should move to aarch64 or risc-v? -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Feature #540] Support for Lenovo ThinkPad X250 - the competitor to the shortly added HP EliteBook 820 G2
Issue #540 has been updated by Angel Pons. Even though bypassing Boot Guard is possible on Skylake, the ME on Broadwell uses a completely different ISA for its CPU core (Skylake uses a mini-x86 core, Broadwell and earlier use some ARCompact thing?). So backporting the bootguard bypass thing is significantly more complicated because of that. Feature #540: Support for Lenovo ThinkPad X250 - the competitor to the shortly added HP EliteBook 820 G2 https://ticket.coreboot.org/issues/540#change-1853 * Author: akjuxr3 akjuxr3 * Status: New * Priority: Normal * Category: board support * Target version: none * Start date: 2024-05-22 * Affected hardware: Lenovo Thinkpad X250 Coreboot now have support for the HP EliteBook 820 G2. This is great, but sadly the keyboard is for a person using Thinkpad keyboards forever not usable. The Thinkpad X250 is the competitor to the HP EliteBook 820 G2. https://www.notebookcheck.net/Face-Off-HP-EliteBook-820-G2-vs-Lenovo-ThinkPad-X250-vs-Dell-Latitude-12-E7250.144831.0.html The X250 also have a Full-HD IPS screen. This would also fix the problems many people have with the X230 and spend much time and effort to get a Full-HD IPS screen running in the X230. Nico Huber have(had?) such a X250: https://review.coreboot.org/c/coreboot/+/23820/7#message-04cf9f804c1292f457c61c71e63eaddaff083202 Other coreboot developer also seem to have a X250: https://review.coreboot.org/c/coreboot/+/51179 Have someone taken a deeper look into the Thinkpad X250? Is there something special why suddenly the HP EliteBook 820 G2 got supported instead of a typical Thinkpad like it was the case for years at coreboot? -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Found how to work some LEDs on P8Z77-M. Looking for implementation guidance.
Hi Keith, On Mon, Apr 15, 2024 at 12:49 AM Keith Hui wrote: > > What an eye opener. > > Yesterday I stumbled upon some boardviews for my board, and the pro > variant. That could also let me sort out the pro's serial port without > one actually on hand, but that's for another time. Nice! Serial console is always nice to have. > The power button have never blinked while in S3 like it's supposed to. > I found that it is connected to GPIO27 on the PCH. I could adjust the > PCH GPIO config to make it blink. What is the best approach if I want > it to blink before entering S3, and stop it blinking after coming out > of? IIRC, the first 32 GPIOs of the PCH natively support a "blink" mode by setting a bit in a register. You can easily test this by enabling blink for GPIO27 in your board's `gpio.c` (this should make the power LED blink all the time). In order to make it blink only in sleep mode, you should set that "blink bit" when the board goes to sleep. In order of preference, this can be done in the DSDT (`_PTS` method; check if southbridge ACPI already has definitions for the GPIO registers) or in the SMI handler. > Thanks > Keith > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: How to best handle new Intel Saphire Rapids server boards based on Intel Archer City?
Hi Paul, list, On Thu, Jun 8, 2023, 16:16 Paul Menzel wrote: > [Annie, Yiwei, I only added you to Cc. It’d be great if you made sure > that all involved people are subscribed to the coreboot mailing list.] > > Dear coreboot folks, > > > Two server boards based on Intel Archer City board, commit 30e743e7cc7f > (mb/ibm: Add 4 SPR sockets server board IBM SBP1) [1], were pushed to > Gerrit for review: > > 1. mb/inventec: Add Intel SPR server board Inventec Transformers [2] > Change-Id: Ic9d99c3aadaa9f69e6d14d4b1a6c5157f5590684 > 2. bytedance/bd_egs (Eaglestream) [3] > Change-Id: I091bc78e39cd76b3c6b9a10a1fcf58e9d671ef5d > > Some code seems to be copied – like bootblock.c [4] – and almost > identical to the reference platform. To avoid future maintenance burden, > could more knowledgeable people comment, if server boards differ > drastically so separate boards are justified or if they should be made > variants. > A variant setup with boards from different vendors sounds like a maintenance nightmare. We still have a common place to put the redundant code, though: in chipset (SoC) code. The bootblock LPC decode can definitely be factored out. That being said, it may be easier to factor things out after these three board ports have been submitted. The boot I also noticed `mainboard_config_iio()`. Should that be moved to the > devicetree? > If the settings are only used in ramstage (where the devicetree is R/W), they could be moved to the devicetree. However, if these settings are used in romstage, the devicetree would negatively impact runtime-dependent configuration (e.g. when using straps to control IIO bifurcation depending on slot occupancy), as the devicetree cannot be updated at runtime in romstage (or earlier). Kind regards, > > Paul > > > [1]: https://review.coreboot.org/c/coreboot/+/73392 > "mb/ibm: Add 4 SPR sockets server board IBM SBP1" > [2]: https://review.coreboot.org/c/coreboot/+/75598 > "mb/inventec: Add Intel SPR server board Inventec Transformers" > [3]: https://review.coreboot.org/c/coreboot/+/75722 > "mb/bytedance: Add 2 SPR sockets server board bd_egs" > [4]: > > https://review.coreboot.org/c/coreboot/+/75598/5/src/mainboard/inventec/transformers/bootblock.c#18 > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Refactoring #460] Make mainboards using the variant concept
Issue #460 has been updated by Angel Pons. akjuxr3 akjuxr3 wrote in #note-5: > > The xNx naming scheme also doesn't work in the general case. > > I know. In x4x the best example is the Intel X48 chipset. Its not supported > by coreboot. Reason for not supporting it is that its completely different > generation. Its x3x-generation (X38) renamed and tuned by intel. But still > collide into the x4x coreboot naming. > But my point is, that naming x4x like its named is better, then if it were > named for example c2d (for core 2 duo) or c2q (for core 2 quad). You can > stick your socket 771 hardwaremodded intel xeon (the CPU) in this boards > without any modification to the x4x board. Also different generations of cpu > codenames work with the x4x codebase. The most precise name for the set of northbridges supported by `northbridge/intel/x4x` is "eaglelake", the codename. Even "4-series" can be confusing, because there's X48 (codename "bearlake", which includes 3-series desktop northbridges) as well as the mobile northbridges (`northbridge/intel/gm45`, officially known as "Mobile 4-series" and codename "cantiga") which are different beasts. That being said, we don't usually rename chipsets. We did rename "nehalem" to "ironlake", however, as the original name was incorrect. The code does not support any 45nm Nehalem CPUs, but rather Arrandale mobile processors consisting of a 32nm Westmere dual-core CPU die and a 45nm integrated northbridge die (we've tested the code on a desktop Clarkdale processor, raminit isn't happy about it). See https://en.wikipedia.org/wiki/Westmere_(microarchitecture) https://en.wikipedia.org/wiki/Arrandale and https://en.wikipedia.org/wiki/Clarkdale_(microprocessor) for more information. > > There's also chipsets that share an architecture (and thus share a > > codebase) but do not share the naming scheme, such as Q77 and C216 > > chipsets. Both of these are Panther Point chipsets but the x7x naming > > scheme does not capture this. > > Yes, you are correct. Thanks for mentioning this. And the codebase is also shared with 6-series PCHs, which include "UP server" (uniprocessor server, the term Intel uses to refer to servers using the same technology as "client" desktops) PCHs. It's hard to pick a name in such cases. Typically, the name for the older generation is used because support for the newer generation gets added later. This is the case for `cpu/intel/haswell`, which now supports Broadwell as well. > > otherwise we would need to resort to absurdly long names that accurately > > captures everything or duplicate code by forcing separate directories to be > > created for parts with incompatible names but otherwise compatible code. > > My point was not about the naming-lenght. It is about naming it about > something that is not a general part of the thing the code is written for. Naming can be difficult. There's several HP laptops supported under `mainboard/hp/snb_ivb_laptops` for lack of a better name. Besides the CPU and chipset, the only other thing they have in common is the SMSC KBC1126 EC. > > Yes, it makes things more confusing to navigate using the folder structure > > but I think that's already been accepted as a reality given the naming of > > the chipset directories and usage of the variant scheme for mainboards. > > My point is not about the simplicity of navigation in the folders. It was > about naming it about something that is not a general hardwarepart(cpu) of > the thing the code is written for(the mainboard). Simplicity of navigation doesn't change much when using variants, it's more that the specific supported models are less visible. This can be compensated by improving the supported boards list. Given that board-status got a rewrite in Go recently, it should be easier than ever to add proper support for variants (per-variant `board_info.txt` parsing, for instance). > > It's actually quite simple to put an accurate name on it: Use something > > that is soldered to the mainboard. In case of platform code that supports > > multiple chipsets, it's usually the CPU socket that they have in common. > > lga1155 should work here and similar names are used already in the tree. > > Perfect! This also include the C216 chipsets. The coreboot codebase is then > in general understandable (not naming it after parts (CPUs) that are not part > of the hardwareproduct the code is written for) again like it is in x4x and > like its wished its combined in one directory. It's reasonable, but there's some pitfalls. First of all, there's two incompatible types of LGA1151 socket: the Skylake/Kaby
[coreboot] [coreboot - Bug #455] superiotool recognizes the wrong chip and doesn't work.
Issue #455 has been updated by Angel Pons. Have you tried running `sudo superiotool -d`? This should show the register dump for the Nuvoton Super I/O on your board. The AST2400 detection procedure is delusional (read random registers, if any returns non-zero then we have an AST2400), so it often results in false positives. Bug #455: superiotool recognizes the wrong chip and doesn't work. https://ticket.coreboot.org/issues/455#change-1399 * Author: shen Liu * Status: New * Priority: Normal * Category: userspace utilities * Target version: master * Start date: 2023-02-07 * Affected versions: master * Needs backport to: none * Related links: More discussion： https://www.reddit.com/r/coreboot/comments/10ud7tk/is_b85me45_ms7817_supported_by_coreboot/ https://wiki.archlinux.org/title/Debuginfod * Affected hardware: MSI B85M-E45 * Affected OS: Manjaro Linux 22.0.2 (Kernel ver:6.1.9-1) ``` shell sudo ./superiotool Found Aspeed AST2400 (id=0x00) at 0x4e sudo ./superiotool superiotool r4.19-306-g12ec7901b7 No Super I/O found ``` Does superiotool provide debug symbols? Without debug symbols I can't use gdb to provide more useful information. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #449] ThinkPad T440p fail to start, continous beeping & LED blinking
Issue #449 has been updated by Angel Pons. https://review.coreboot.org/72806 fixes the UBSAN errors, please review. Note that UBSAN-enabled coreboot still dies later on: ``` Loading module at 0x0003 with entry 0x0003. filesize: 0x178 memsize: 0x178 Processing 16 relocs. Offset value of 0x0003 unaligned access src/lib/rmodule.c:152:27 ubsan: unrecoverable error. ``` So, any users that desire to have a bootable system should keep UBSAN disabled when building coreboot. Bug #449: ThinkPad T440p fail to start, continous beeping & LED blinking https://ticket.coreboot.org/issues/449#change-1394 * Author: Crazy Fox * Status: In Progress * Priority: Normal * Assignee: Angel Pons * Category: board support * Target version: 4.18 * Start date: 2023-01-14 * Affected versions: 4.19 * Related links: The USBAN error is: ``` [ERROR] shift out of bounds src/northbridge/intel/haswell/pcie.c:85:22 [EMERG] ubsan: unrecoverable error. ``` * Affected hardware: haswell Hi, Team Being corebooted before and works fine on 4.17. After flashing 4.18 my t440p wont startup (black screen, constant beeping & LED blinking). I've tried and retried different nconfigs but result is the same. I know that it is lack of information, but I need to recover the laptop first to grab some logs from it. Log from FT232H's debug is attached, the rest of info (defconfig, flashrom command etc. will upload soon) ---Files coreboot_t440p_emerg.log (7.85 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #449] (In Progress) ThinkPad T440p fail to start, continous beeping & LED blinking
Issue #449 has been updated by Angel Pons. Assignee set to Angel Pons Status changed from New to In Progress Category changed from coreboot common code to board support Looks like coreboot dies because UBSAN encounters a bug. Please disable UBSAN and try again. Note that things like ASAN and UBSAN are meant to be used for debugging purposes; for "production" use-cases, it's better to keep these options disabled. Bug #449: ThinkPad T440p fail to start, continous beeping & LED blinking https://ticket.coreboot.org/issues/449#change-1344 * Author: Crazy Fox * Status: In Progress * Priority: Normal * Assignee: Angel Pons * Category: board support * Target version: 4.18 * Start date: 2023-01-14 * Affected versions: 4.18 * Affected hardware: haswell Hi, Team Being corebooted before and works fine on 4.17. After flashing 4.18 my t440p wont startup (black screen, constant beeping & LED blinking). I've tried and retried different nconfigs but result is the same. I know that it is lack of information, but I need to recover the laptop first to grab some logs from it. Log from FT232H's debug is attached, the rest of info (defconfig, flashrom command etc. will upload soon) ---Files coreboot_t440p_emerg.log (7.85 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #432] t440p reboots on suspend
Issue #432 has been updated by Angel Pons. File osboot_t440p_ifd_bin_is_also_borked.log added Yes, it's definitely an osboot problem... Please report the issue to osboot folks, and point them to this ticket. After grabbing the T440p IFD.bin that osboot uses and using `util/ifdtool`'s `-d` option on it (after manually padding to 12 MiB; you can just use the osboot image you built), it's clear why coreboot thinks the flash chip is much larger... ``` Component 2 Density: 32MB Component 1 Density: 8MB ``` Component 2 Density should be "4MB" (technically, 4 MiB) instead. No clue where the IFD.bin that osboot uses comes from, but it's broken. See attached log for the complete `ifdtool -d` output. Bug #432: t440p reboots on suspend https://ticket.coreboot.org/issues/432#change-1218 * Author: Josh R * Status: Response Needed * Priority: Normal * Target version: none * Start date: 2022-10-21 * Affected versions: 4.15 * Related links: https://ticket.coreboot.org/issues/412 * Affected hardware: Lenovo ThinkPad T440p * Affected OS: Ubuntu 22.04 (Pop OS) Per request, adding new ticket for an issue with my t440p where attempting to resume on suspend results in a reboot (or at least, not resuming from DRAM). My t440p already has coreboot installed (via osbmk). Following instructions from issue #412, I have attempted the following: `sudo flashrom -p internal --ifd -i bios -w the_full_12MiB_osbmk.rom --noverify-all` ...but that did not seem to do the trick (still "restarts" without resuming from RAM). Note that I am using the "full" 12MB osbmk rom (not split by 4MiB and 8MiB, as that seemed intended for the hardware flashing instructions). coreboot version looks like 4.15.204, and flashrom version 1.2-640. If it helps, attached cbmem -1 output with a "normal boot" followed by a later resume from suspend (that resulted in a restart). Thanks in advance. I guess you don't realize how much you use suspend until it doesn't work anymore :) ---Files cbmem.20221019195923.normal_boot.log (36.2 KB) cbmem.20221019200724.from_suspend.log (36.3 KB) osboot_t440p_ifd_bin_is_also_borked.log (10.2 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #432] t440p reboots on suspend
Issue #432 has been updated by Angel Pons. *sigh* where is the "Edit" button? Looks like the issue happens because something is messed up with the "ROM size"... ``` flash size 0x280 bytes SF: Detected 00 with sector size 0x1000, total 0x280 SF size 0x280 does not correspond to CONFIG_ROM_SIZE 0xc0!! ``` This seems like a bug in osboot. Bug #432: t440p reboots on suspend https://ticket.coreboot.org/issues/432#change-1216 * Author: Josh R * Status: Response Needed * Priority: Normal * Target version: none * Start date: 2022-10-21 * Affected versions: 4.15 * Related links: https://ticket.coreboot.org/issues/412 * Affected hardware: Lenovo ThinkPad T440p * Affected OS: Ubuntu 22.04 (Pop OS) Per request, adding new ticket for an issue with my t440p where attempting to resume on suspend results in a reboot (or at least, not resuming from DRAM). My t440p already has coreboot installed (via osbmk). Following instructions from issue #412, I have attempted the following: `sudo flashrom -p internal --ifd -i bios -w the_full_12MiB_osbmk.rom --noverify-all` ...but that did not seem to do the trick (still "restarts" without resuming from RAM). Note that I am using the "full" 12MB osbmk rom (not split by 4MiB and 8MiB, as that seemed intended for the hardware flashing instructions). coreboot version looks like 4.15.204, and flashrom version 1.2-640. If it helps, attached cbmem -1 output with a "normal boot" followed by a later resume from suspend (that resulted in a restart). Thanks in advance. I guess you don't realize how much you use suspend until it doesn't work anymore :) ---Files cbmem.20221019195923.normal_boot.log (36.2 KB) cbmem.20221019200724.from_suspend.log (36.3 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #432] t440p reboots on suspend
Issue #432 has been updated by Angel Pons. Hmmm, looks like the issue happens because the MRC cache Bug #432: t440p reboots on suspend https://ticket.coreboot.org/issues/432#change-1215 * Author: Josh R * Status: Response Needed * Priority: Normal * Target version: none * Start date: 2022-10-21 * Affected versions: 4.15 * Related links: https://ticket.coreboot.org/issues/412 * Affected hardware: Lenovo ThinkPad T440p * Affected OS: Ubuntu 22.04 (Pop OS) Per request, adding new ticket for an issue with my t440p where attempting to resume on suspend results in a reboot (or at least, not resuming from DRAM). My t440p already has coreboot installed (via osbmk). Following instructions from issue #412, I have attempted the following: `sudo flashrom -p internal --ifd -i bios -w the_full_12MiB_osbmk.rom --noverify-all` ...but that did not seem to do the trick (still "restarts" without resuming from RAM). Note that I am using the "full" 12MB osbmk rom (not split by 4MiB and 8MiB, as that seemed intended for the hardware flashing instructions). coreboot version looks like 4.15.204, and flashrom version 1.2-640. If it helps, attached cbmem -1 output with a "normal boot" followed by a later resume from suspend (that resulted in a restart). Thanks in advance. I guess you don't realize how much you use suspend until it doesn't work anymore :) ---Files cbmem.20221019195923.normal_boot.log (36.2 KB) cbmem.20221019200724.from_suspend.log (36.3 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #432] (Response Needed) t440p reboots on suspend
Issue #432 has been updated by Angel Pons. Affected hardware changed from Lenovo t440p to Lenovo ThinkPad T440p Status changed from New to Response Needed Hi, osboot is not the same as coreboot. Have you asked the people responsible for osboot to provide support? It would be great if you could test with upstream coreboot, to make sure the issue is in coreboot and not about something the osboot people did. Bug #432: t440p reboots on suspend https://ticket.coreboot.org/issues/432#change-1214 * Author: Josh R * Status: Response Needed * Priority: Normal * Target version: none * Start date: 2022-10-21 * Affected versions: 4.15 * Related links: https://ticket.coreboot.org/issues/412 * Affected hardware: Lenovo ThinkPad T440p * Affected OS: Ubuntu 22.04 (Pop OS) Per request, adding new ticket for an issue with my t440p where attempting to resume on suspend results in a reboot (or at least, not resuming from DRAM). My t440p already has coreboot installed (via osbmk). Following instructions from issue #412, I have attempted the following: `sudo flashrom -p internal --ifd -i bios -w the_full_12MiB_osbmk.rom --noverify-all` ...but that did not seem to do the trick (still "restarts" without resuming from RAM). Note that I am using the "full" 12MB osbmk rom (not split by 4MiB and 8MiB, as that seemed intended for the hardware flashing instructions). coreboot version looks like 4.15.204, and flashrom version 1.2-640. If it helps, attached cbmem -1 output with a "normal boot" followed by a later resume from suspend (that resulted in a restart). Thanks in advance. I guess you don't realize how much you use suspend until it doesn't work anymore :) ---Files cbmem.20221019195923.normal_boot.log (36.2 KB) cbmem.20221019200724.from_suspend.log (36.3 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #412] x230 reboots on suspend
Issue #412 has been updated by Angel Pons. Josh, could you please open a separate issue? Thanks. Bug #412: x230 reboots on suspend https://ticket.coreboot.org/issues/412#change-1204 * Author: Carson A. * Status: New * Priority: Normal * Target version: none * Start date: 2022-09-02 * Affected versions: master * Related links: https://ticket.coreboot.org/issues/393 * Affected hardware: x230 * Affected OS: windows/arch linux Very similar to issue 393 where the x230 reboots when suspended to RAM. Seems to be an issue with coreboot v4.16 & 4.17 or something is missing in the config (attached). Any insight on this would be appreciated! ---Files coreboot_config.txt (18.8 KB) normal_boot.txt (48.1 KB) suspend_boot.txt (48 KB) 12mb_boot.txt (47.6 KB) cbmem.20221019200724.from_suspend.log (36.3 KB) cbmem.20221019195923.normal_boot.log (36.2 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #310] (Resolved) Coreboot 4.14 fails on a Lenvovo T440p
Issue #310 has been updated by Angel Pons. Affected OS set to All (coreboot bug) Affected hardware set to ThinkPad T440p Status changed from Response Needed to Resolved Bug #310: Coreboot 4.14 fails on a Lenvovo T440p https://ticket.coreboot.org/issues/310#change-1160 * Author: David Hoelscher * Status: Resolved * Priority: Normal * Assignee: Angel Pons * Start date: 2021-06-02 * Affected hardware: ThinkPad T440p * Affected OS: All (coreboot bug) Hi all, coreboot 4.14 dies on early boot. The T440p ended with led blinking and beep sound. This was my first try - so i think it was maybe a problem with mrc.bin or vga.rom. But if I skip back to version 4.13, everything works fine (4.13 working config is appended). I don't know how to get debug information on this early stage of boot. Does anyone has a hint? A Raspberry Pi as an external flasher is available. Further - is it possible to flash only the 4 MB BIOS chip? This IC is very easy accessible. I am afraid to disassemble the complete backplate to access the other 8MB chip again. Initially I flashed the complete Rom without ME on both chips. ---Files Coreboot_4.13.config (23.6 KB) descriptor.bin (4 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #427] x200: Two battery charging issues
Issue #427 has been updated by Angel Pons. Hi, Yes, the EC should be reset by unplugging all power supplies, as it loses power. The RTC/CMOS battery shouldn't matter, but it would be a good idea to disconnect it as well if it's easy to do so. Bug #427: x200: Two battery charging issues https://ticket.coreboot.org/issues/427#change-1156 * Author: Akura Ryu * Status: New * Priority: High * Category: board support * Target version: master * Start date: 2022-10-14 * Affected versions: master * Needs backport to: master * Affected hardware: ThinkPad X200 * Affected OS: Linux I've flashed my ThinkPad X200 with coreboot. Currently it has trouble when charging. ## 1. Charge state mismatch When I plug in my AC adapter, system always reports " **Not charging** ". Here's the output from the `acpi` utility: ``` Battery 0: Not charging, 23% Adapter 0: on-line ``` But weirdly, battery level is still increasing as the AC adapter is on-line. What's more, it still reports "Not charging" when AC adapter is detached (normally it should be "Discharging"). ## 2. Battery threshold doesn't seem to work. Since tp_smapi is unusable without stock firmware, I use `tpacpi-bat` to configure battery threshold. My KDE battery indicator can recognize these thresholds. ```sh sudo tpacpi-bat -s ST 1 88# Start threshold sudo tpacpi-bat -s SP 1 90# Stop threshold ``` But no matter how I charge, battery will always be fully charged. ## Revision - **OS**: Arch Linux with KDE - **Coreboot revision**: 93781523a - **Configuration**: See attachment ---Files .config (18.8 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #427] x200: Two battery charging issues
Issue #427 has been updated by Angel Pons. Could you please check if the "battery not charging" issues are still present when *not* using any software to mess with the thresholds? To properly test, please make sure the EC (Embedded Controller) gets reset: power off the laptop and remove all batteries and the AC adapter. Bug #427: x200: Two battery charging issues https://ticket.coreboot.org/issues/427#change-1154 * Author: Akura Ryu * Status: New * Priority: High * Category: board support * Target version: master * Start date: 2022-10-14 * Affected versions: master * Needs backport to: master * Affected hardware: ThinkPad X200 * Affected OS: Linux I've flashed my ThinkPad X200 with coreboot. Currently it has trouble when charging. ## 1. Charge state mismatch When I plug in my AC adapter, system always reports " **Not charging** ". Here's the output from the `acpi` utility: ``` Battery 0: Not charging, 23% Adapter 0: on-line ``` But weirdly, battery level is still increasing as the AC adapter is on-line. What's more, it still reports "Not charging" when AC adapter is detached (normally it should be "Discharging"). ## 2. Battery threshold doesn't seem to work. Since tp_smapi is unusable without stock firmware, I use `tpacpi-bat` to configure battery threshold. My KDE battery indicator can recognize these thresholds. ```sh sudo tpacpi-bat -s ST 1 88# Start threshold sudo tpacpi-bat -s SP 1 90# Stop threshold ``` But no matter how I charge, battery will always be fully charged. ## Revision - **OS**: Arch Linux with KDE - **Coreboot revision**: 93781523a - **Configuration**: See attachment ---Files .config (18.8 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: New Defects reported by Coverity Scan for coreboot
Hi all, On Tue, Oct 11, 2022 at 7:03 PM Angel Pons wrote: > > Hi Patrick, > > On Tue, Oct 11, 2022 at 6:43 PM Patrick Georgi wrote: > > > > "Angel Pons" schrieb: > > > > > We made the patches that made Coverity angry about this `format_pn()` > > > function. However, this is not an actual bug: the > > > `eeprom_read_serial()` function returns a buffer that is at most 32 > > > (`HERMES_SN_PN_LENGTH`) characters long, and the length of the > > > `prefix` string is known at build-time (it's a string literal in both > > > call sites) to be less than 32 characters long. > > > > There's no guarantee that the string returned by eeprom_read_serial() is > > 0-terminated (not even in its implementation) and strcpy proceeds until the > > first 0 it sees, even if that's only 2GB later. Use strncpy instead to > > prevent out of bound copies. > > Oh, we wanted to use `strncat()` but it doesn't exist in coreboot. > Then we considered `strcat()` and it didn't exist either, and we ended > up using `strcpy()`. Will use `strncpy()`, thank you! After some discussion on IRC, we ended up making https://review.coreboot.org/68322 and https://review.coreboot.org/68323 to address the issues. Thank you all. > > Patrick > > Best regards, > Angel Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: New Defects reported by Coverity Scan for coreboot
Hi Patrick, On Tue, Oct 11, 2022 at 6:43 PM Patrick Georgi wrote: > > "Angel Pons" schrieb: > > > We made the patches that made Coverity angry about this `format_pn()` > > function. However, this is not an actual bug: the > > `eeprom_read_serial()` function returns a buffer that is at most 32 > > (`HERMES_SN_PN_LENGTH`) characters long, and the length of the > > `prefix` string is known at build-time (it's a string literal in both > > call sites) to be less than 32 characters long. > > There's no guarantee that the string returned by eeprom_read_serial() is > 0-terminated (not even in its implementation) and strcpy proceeds until the > first 0 it sees, even if that's only 2GB later. Use strncpy instead to > prevent out of bound copies. Oh, we wanted to use `strncat()` but it doesn't exist in coreboot. Then we considered `strcat()` and it didn't exist either, and we ended up using `strcpy()`. Will use `strncpy()`, thank you! > Patrick Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: New Defects reported by Coverity Scan for coreboot
Hi list, We made the patches that made Coverity angry about this `format_pn()` function. However, this is not an actual bug: the `eeprom_read_serial()` function returns a buffer that is at most 32 (`HERMES_SN_PN_LENGTH`) characters long, and the length of the `prefix` string is known at build-time (it's a string literal in both call sites) to be less than 32 characters long. Does anyone have any ideas to make Coverity shut up without making the code unnecessarily ugly? Thanks in advance, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #412] x230 reboots on suspend
Issue #412 has been updated by Angel Pons. I concur with Nico's assessment. I imagine you changed the "ROM chip size" option to get a 4 MiB file to flash to the second flash chip (4 MiB). Instead of doing that, https://doc.coreboot.org/mainboard/lenovo/Ivy_Bridge_series.html#splitting-the-coreboot-rom provides the commands to split a 12 MiB image into 8 MiB and 4 MiB parts. You'd want to use `dd of=top.rom bs=1M if=build/coreboot.rom skip=8` to obtain a 4 MiB image. As you've already installed coreboot, you can also flash internally with `sudo flashrom -p internal --ifd -i bios -w build/coreboot.rom --noverify-all`. This tells flashrom to write `build/coreboot.rom` to the flash chip(s) using the internal programmer, but only the "bios" region as described by the IFD of the system. The `--noverify-all` option tells flashrom to not verify the entire flash chip (to make sure other regions did not change), but only the written regions. This is needed when flashrom cannot read the entire flash chip, and the ME region is not readable by default. Bug #412: x230 reboots on suspend https://ticket.coreboot.org/issues/412#change-1083 * Author: Carson Alberding * Status: New * Priority: Normal * Target version: none * Start date: 2022-09-02 * Affected versions: master * Related links: https://ticket.coreboot.org/issues/393 * Affected hardware: x230 * Affected OS: windows/arch linux Very similar to issue 393 where the x230 reboots when suspended to RAM. Seems to be an issue with coreboot v4.16 & 4.17 or something is missing in the config (attached). Any insight on this would be appreciated! ---Files coreboot_config.txt (18.8 KB) normal_boot.txt (48.1 KB) suspend_boot.txt (48 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: RFC: Deprecating VBOOT_VBNV_CMOS
Hi, On Mon, Aug 1, 2022 at 2:59 AM Yu-Ping Wu wrote: > Thanks for the feedback. > > I'm pretty sure Broadwell supports early flash writes: flashconsole >> works and it writes to flash as early as bootblock. I'm not sure why >> CB:45740 selected BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES for platforms >> older than Skylake/Apollo Lake, but I guess it's because it couldn't >> be tested. >> > > Thanks. I've made a revert > <https://review.coreboot.org/c/coreboot/+/66300> for the broadwell patch. > In addition to haswell, BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES is also > enabled for: > >- CPU_INTEL_MODEL_206AX >- CPU_INTEL_MODEL_2065X >- NORTHBRIDGE_INTEL_X4X >- SOC_INTEL_BAYTRAIL >- SOC_INTEL_BRASWELL > > Do you know offhand whether these platforms support early flash writes or > not? If not, who might know the answer? > These platforms should also support early writes, but it would be nice to test them. I'd suggest making one change for each platform, so that it's easier to keep track of the test status for each. I'll try to add reviewers to the changes who may be able to test them. > On Mon, Jul 18, 2022 at 5:13 PM Angel Pons wrote: > >> Hi, >> >> On Mon, Jul 18, 2022 at 8:34 AM Yu-Ping Wu via coreboot >> wrote: >> > >> > Hi, >> > >> > There's an ongoing effort to expand vboot nvdata (nvstorage) from 16 to >> 64 bytes [issue]. To reduce unnecessary complexity of our firmware code >> accessing nvdata, we'd like to drop 16-byte nvdata support from the >> firmware codebase (crossystem still needs to support both though). >> >> Sounds good. >> >> > One obstacle is the CMOS nvdata backend (VBOOT_VBNV_CMOS). We're not >> sure if there would be enough CMOS space for all boards using that. In >> addition, because CMOS loses state when the battery is removed, newer >> boards usually select VBOOT_VBNV_CMOS_BACKUP_TO_FLASH to backup nvdata to >> flash. Considering that, this seems like a good opportunity to migrate CMOS >> to flash nvdata [issue]. >> >> The new 64-byte nvdata would require 512 bits of CMOS. On most >> systems, CMOS has two banks, each of which holds 1024 bits. One could >> try using the upper bank to store nvdata, but it still has the problem >> of CMOS losing its contents when RTC battery power is lost. So I'd >> strongly recommend deprecating support for nvdata in CMOS as well. >> >> > One problem we faced is that many old platforms such as broadwell don't >> support writing to the flash in early stages >> (BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES). Therefore it looks like we'd need >> to drop vboot support on them (for example CB:65782). An alternative would >> be to keep the CMOS backend around as "deprecated" and not allow 64-byte >> nvdata for it, but that would at best be a transitory solution for a couple >> of years, not forever. >> >> I'm pretty sure Broadwell supports early flash writes: flashconsole >> works and it writes to flash as early as bootblock. I'm not sure why >> CB:45740 selected BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES for platforms >> older than Skylake/Apollo Lake, but I guess it's because it couldn't >> be tested. >> >> For Intel platforms with native raminit using MRC cache, I'd suggest >> selecting MRC_WRITE_NV_LATE when unselecting >> BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES just to be safe. Should native >> raminit produce training results that are at the limit of instability >> and ramstage crashes because of it, saving the training results in >> romstage could potentially result in a boot loop until something is >> done to invalidate the MRC cache data. Granted, the chances of this >> ocurring are extremely low, but native raminit isn't perfect (I'm >> pretty sure MRC isn't perfect either, but we can't really fix the >> blobs). >> >> > If there's any concern, please let me know. We have firmware branches >> for ChromeOS devices, so modifying ToT code wouldn't affect old devices in >> any way. However, I'm not sure how non-ChromeOS boards (such as >> mainboard/lenovo/haswell) would be affected by this. Please cc more people >> if needed. >> >> There are several Lenovo mainboards which use VBOOT_VBNV_CMOS, but I >> think it's possible to switch to SPI flash for nvdata on all of them. >> One thing to keep in mind is that vboot users will have to update >> everything as these changes won't be backwards-compatible. >> >> > -- >> > >> > Yu-Ping Wu | Software Engineer | yupin...@google.com | +886 937 057 080 >> <+886%20937%20057%20080> >> >> Best regards, >> Angel >> > > > -- > > Yu-Ping Wu | Software Engineer | yupin...@google.com | +886 937 057 080 > Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: [flashrom] Intel Kaby Lake Y w/ iHDCP2.2 Prem ERASE_FAILED
Hi Craft, Looks like you only replied to me, so the mailing list hasn't received your message. In the future, remember to use "Reply to all" so that the mailing list also gets a copy of your message. On Fri, Jul 22, 2022 at 12:10 AM J. Craft wrote: > > Appreciate you getting back to me, Angel. Write Protection had been disabled, > but I hadn't rebooted for it to take effect. :) Yes, a reboot is needed for the write-protect settings to be updated. > However, after rebooting and flashing properly, it appears that there is a > bug in the bios that causes an ACIP BIOS ERROR when trying to install Windows > 10. Any suggestions on what to do in this situation? Hmmm, https://www.reddit.com/r/chrultrabook/comments/aufp1q/getting_started_read_this_first/ says that Nocturne should be able to boot Windows... I presume it's a regression of some sort. > Kind regards, > Craft > > On Thu, Jul 21, 2022 at 3:59 AM Angel Pons wrote: >> >> Hi, >> >> On Thu, Jul 21, 2022 at 2:23 AM J. Craft wrote: >> > >> > Let me know if there's anything else needed and what might be suggested in >> > this situation. >> >> *snip* >> >> > 0x84: 0x89ef09d0 PR0: Warning: 0x009d-0x009e is read-only. >> >> flashrom errors out because this region is read-only. I'm pretty sure >> that's the MRC cache region. You have to disable write-protect by >> either removing the "WP screw" or by disconnecting the internal >> battery, then you will be able to flash coreboot successfully. >> >> > Good, writing to the flash chip apparently didn't do anything. >> >> You can safely reboot. >> >> Best regards, >> Angel Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Intel Quark - a quick update
Hi Andy, On Tue, Jul 19, 2022 at 2:19 PM Andy Pont wrote: > > Ron wrote… > > >so how's it going? > Slowly! The day job has got in the way a bit but I have been struggling > to build the FSP binaries based on the instructions at [1]. I’m not > sure whether that is down to me not fully understanding the instructions > (always possible) or whether there is work-in-progress that needs to be > completed. > > I managed to build the FSP 1.1 binary using the six year old version of > edk2 that Lee also has on his GitHub using an Ubuntu 16.04 development > machine. I haven’t yet managed to find a way to successful build the > FSP 2.0 binary. Trying to build EDK2 BaseTools throws a pile of Python > syntax errors which may or may not be critical. I’ve assumed they > aren’t for now and am working on getting the binary to build. Instructions on how to build QuarkFsp were added here: https://review.coreboot.org/29029 > -Andy. > > 1 - https://github.com/LeeLeahy/quarkfsp Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: RFC: Deprecating VBOOT_VBNV_CMOS
Hi, On Mon, Jul 18, 2022 at 8:34 AM Yu-Ping Wu via coreboot wrote: > > Hi, > > There's an ongoing effort to expand vboot nvdata (nvstorage) from 16 to 64 > bytes [issue]. To reduce unnecessary complexity of our firmware code > accessing nvdata, we'd like to drop 16-byte nvdata support from the firmware > codebase (crossystem still needs to support both though). Sounds good. > One obstacle is the CMOS nvdata backend (VBOOT_VBNV_CMOS). We're not sure if > there would be enough CMOS space for all boards using that. In addition, > because CMOS loses state when the battery is removed, newer boards usually > select VBOOT_VBNV_CMOS_BACKUP_TO_FLASH to backup nvdata to flash. Considering > that, this seems like a good opportunity to migrate CMOS to flash nvdata > [issue]. The new 64-byte nvdata would require 512 bits of CMOS. On most systems, CMOS has two banks, each of which holds 1024 bits. One could try using the upper bank to store nvdata, but it still has the problem of CMOS losing its contents when RTC battery power is lost. So I'd strongly recommend deprecating support for nvdata in CMOS as well. > One problem we faced is that many old platforms such as broadwell don't > support writing to the flash in early stages > (BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES). Therefore it looks like we'd need to > drop vboot support on them (for example CB:65782). An alternative would be to > keep the CMOS backend around as "deprecated" and not allow 64-byte nvdata for > it, but that would at best be a transitory solution for a couple of years, > not forever. I'm pretty sure Broadwell supports early flash writes: flashconsole works and it writes to flash as early as bootblock. I'm not sure why CB:45740 selected BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES for platforms older than Skylake/Apollo Lake, but I guess it's because it couldn't be tested. For Intel platforms with native raminit using MRC cache, I'd suggest selecting MRC_WRITE_NV_LATE when unselecting BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES just to be safe. Should native raminit produce training results that are at the limit of instability and ramstage crashes because of it, saving the training results in romstage could potentially result in a boot loop until something is done to invalidate the MRC cache data. Granted, the chances of this ocurring are extremely low, but native raminit isn't perfect (I'm pretty sure MRC isn't perfect either, but we can't really fix the blobs). > If there's any concern, please let me know. We have firmware branches for > ChromeOS devices, so modifying ToT code wouldn't affect old devices in any > way. However, I'm not sure how non-ChromeOS boards (such as > mainboard/lenovo/haswell) would be affected by this. Please cc more people if > needed. There are several Lenovo mainboards which use VBOOT_VBNV_CMOS, but I think it's possible to switch to SPI flash for nvdata on all of them. One thing to keep in mind is that vboot users will have to update everything as these changes won't be backwards-compatible. > -- > > Yu-Ping Wu | Software Engineer | yupin...@google.com | +886 937 057 080 Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #318] (Resolved) denverton_ns: Fix MRC cache write
Issue #318 has been updated by Angel Pons. Status changed from Response Needed to Resolved Marked as resolved, I don't know if backports are done yet. Bug #318: denverton_ns: Fix MRC cache write https://ticket.coreboot.org/issues/318#change-967 * Author: King Sumo * Status: Resolved * Priority: Normal * Start date: 2021-09-02 The RW_MRC_CACHE write is broken in denverton_ns platforms. More info: https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/message/26YJ22Z64DZXPAK2VMT6L3FNANNLHMDQ/ https://review.coreboot.org/c/coreboot/+/57033 (patch set as abandoned, it was already agreed with Mariusz to proceed the codereview process). -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: NULL pointer deref in soc/intel/skylake/irq.c
Hi Benjamin, On Wed, Jun 15, 2022 at 9:23 PM Benjamin Doron wrote: > > Hi all, > `src/soc/intel/skylake/irq.c:soc_irq_settings()` dereferences NULL by > memcpy'ing devintconfig to params->DevIntConfigPtr. As far as I can tell, > this happens because we're copying a structure onto a UPD that's actually > just the pointer, rather than assigning the UPD to the buffer. Yes, this code stinks. It makes no sense, where does `DevIntConfigPtr` originally point to? It might not even be pointing to RAM depending on how much RAM is installed! > devintconfig is static, so will `params->DevIntConfigPtr = devintconfig` > work? It would point inside the data section, as I understand. Alternatively, > calling `malloc()` first should work. Newer platforms simply do an assignment (with some casts) so I expect this to work. They also use a dynamically-allocated buffer because the data is generated at runtime from a coreboot-specific structure. I made https://review.coreboot.org/65217 but I haven't boot-tested it. > I'm away from my computer now, so I can't test these alternatives yet. > > Best regards, > Benjamin > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: [RFC] #pragma once
Hi Arthur, list, On Sun, May 15, 2022 at 6:56 PM Arthur Heymans wrote: > > Hi > > To make sure headers don't create conflicts, guards are added to all of them. > But the guard needs to be correct: e.g. > https://review.coreboot.org/c/coreboot/+/64360/2 > Most compilers implement '#pragma once ' as an alternative. > Should we use this instead across the tree, as it is less error prone and > less code? Given that coreboot is built with a very specific toolchain, it seems very reasonable. The only thing that worries me are headers used to build stuff with the system toolchain, e.g. util/ and src/commonlib/ headers. Still, it's highly unlikely that the system toolchain doesn't know about #pragma once provided that it is able to build crossgcc. > Sidenote: clang warns about wrong header guards. > https://review.coreboot.org/c/coreboot/+/62173/23 hooks up clang to our CI > for some platforms ;-). And mismatched names in #ifndef and #define is not the only problem. I recently pondered about the scenario in which a compilation unit includes two different header files that use the same name in their guard. Using #pragma once would fundamentally eliminate both problems. > Kind regards > Arthur Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: [RFC] i945 problematic code for IGD device enable, BUG?
Hi Petr,
On Sun, Apr 24, 2022 at 7:33 AM Petr Cvek wrote:
>
> Hello again :-D,
>
> I'm working on a code for a simultaneous use of IGD (GMA950) and x16 PCIe
> slot GPU. I've made some success, but the code which handles the IGD
> initialization is really weird.
If your PCIe device is a graphics card, you could try removing this
condition in early_init.c:
if (reg32 == 0x03) {
printk(BIOS_DEBUG, "PCIe device is VGA. Disabling IGD.\n");
reg16 = (1 << 1);
pci_write_config16(HOST_BRIDGE, GGC, reg16);
pci_and_config32(HOST_BRIDGE, DEVEN, ~(DEVEN_D2F0 | DEVEN_D2F1));
}
> The IGD is initialized by DEVEN register (DEVEN_D2F0 and DEVEN_D2F1 bits),
> which is first written in i945_setup_pci_express_x16(). Few times before that
> the DEVEN_D2F0 and DEVEN_D2F1 bits are already tested during
> sdram_initialize() code. Also after the reset these bits are initialized to
> 1. This will cause the test from:
>
> https://elixir.bootlin.com/coreboot/4.16/source/src/northbridge/intel/i945/raminit.c#L2127
>
> if (!(pci_read_config8(HOST_BRIDGE, DEVEN) & (DEVEN_D2F0 |
> DEVEN_D2F1)))
> integrated_graphics = false;
>
> to be effectively always -> if (0)
Well, there are i945 versions without integrated graphics (82945P,
82945PL, 82945PM). I haven't tested it, but I'm pretty sure the
DEVEN_D2F0 and DEVEN_D2F1 bits are always zero on these northbridges.
> also even when DEVEN_D2F0 is zeroed after chipset reset, the code located
> after a few lines:
>
> https://elixir.bootlin.com/coreboot/4.16/source/src/northbridge/intel/i945/raminit.c#L2270
>
> pci_or_config8(IGD_DEV, 0xc1, 1 << 2);
>
> will have a problem to work correctly. IGD_DEV is PCIe device enabled by
> DEVEN_D2F0 (setting DEVEN_D2F0 to 0 will remove IGD_DEV from the PCIe bus).
> It seems to not cause problems, but I didn't test it extensively.
This write has no effect if IGD_DEV is disabled by DEVEN. Looks like
this magic 0xc1 register is called UPMC4, but it's undocumented.
> Also the test in northbridge_get_tseg_base() (used everytime top of the
> memory is needed):
>
> https://elixir.bootlin.com/coreboot/4.16/source/src/northbridge/intel/i945/memmap.c#L39
>
> if (pci_read_config8(HOST_BRIDGE, DEVEN) & (DEVEN_D2F0 | DEVEN_D2F1))
> /* IGD enabled, get top of Memory from BSM register */
> tom = pci_read_config32(IGD_DEV, BSM);
>
> If only DEVEN_D2F1 is enabled, the test will succeed, but as the IGD_DEV is
> now disabled by DEVEN_D2F0 it will read garbage data for the global "top of
> the memory" value.
Having D2F1 enabled without D2F0 being enabled is not allowed by the
PCI specification. Function 0 of multi-function devices must always be
implemented.
> I've sort of solved the missing initialization problem with CMOS config entry
> in mainboard_romstage_entry():
>
> switch (get_uint_option("igd_en", 1)) {
> case 0:
> //disable
> pci_and_config32(HOST_BRIDGE, DEVEN, ~(DEVEN_D2F0 |
> DEVEN_D2F1));
> break;
> case 2:
> //enable func0 only ??? TEST
> pci_update_config16(HOST_BRIDGE, DEVEN,
> ~(DEVEN_D2F1), DEVEN_D2F0);
> break;
> case 1:
> default:
> //enabled both
> pci_or_config32(HOST_BRIDGE, DEVEN, DEVEN_D2F0 |
> DEVEN_D2F1);
> break;
> }
>
> sdram_initialize( ...
>
> RFC:
>
> Is this approach OK? Of course the patch will need to cover the if (0) tests
> and skip access to missing PCI devices. Does anybody know if GCFC (Graphics
> Clock Frequency Control) register (i945 datasheet, section 8.1.35, page 296)
> needs to be explicitly disabled when IGD PCIe access is disabled by DEVEN
> bits or do I need to enable IGD PCIe access with DEVEN, disable clocks in
> GCFC and then disable IGD PCIe access again with DEVEN bits?
Unless you need to disable cdclk and crclk (the two graphics clocks
controlled by GCFC, as I see in the document number 309219-006) for
some reason, I wouldn't worry too much about the GCFC details. Your
approach looks reasonable, I'd remove the "func0 only" case for
simplicity. I think the existing code should be able to handle this
properly.
> Similar to GCFC settings without enabled IGD PCIe access. There are many
> registers in affected code, which doesn't have a name/description in the i945
> datasheet. Does anybody know their function? It could help to determine if
> they needs to be set even when IGD will be disabled.
Ah yes, the magic registers. They're not publicly documented (I think
the i945 code was initially written based on information in
confidential documents), and I'm not sure if anyone still has access
to that information.
> Best regards,
> Petr
>
[coreboot] Re: Can coreboot run on a Dell Wyse 3290 or 3030?
Hi, On Sat, Apr 23, 2022 at 11:37 AM Peter Stuge wrote: > > Martin Butt wrote: > > Do you know if Coreboot would work on either of these systems? > .. > > Both the 3290 and the 3030 CPUs are a Intel Celeron N2807 1.58GHz > > That's the CPU marketing name which in firmware like coreboot doesn't > mean much. What matters is that this is a Bay Trail platform. Yes, it's a Bay Trail platform. > > From a visual inspection, the only difference between the boards of the two > > models is that the BIOS chip is different. The 3029 is a Winbond 25Q64FVSIG > > (or a 25Q64FWSIG, the chip is hard to read). The 3030 is a Macronix > > MX25U6435F. > > The 25Q64 chip is unproblematic. flashrom mentiones an OTP region in > the MX chip, I would investigate if and how that is being used, if > the OTP lies within the 8 Mbyte then that could be a problem and > you'd have to replace the chip by soldering. I've never seen the OTP being used in any x86 systems. Note that these SPI flash chips run at 1.8V, not the usual 3.3V that most programmers provide. > (If you need to replace a chip: cut its pins flush with the black > package so that you can first remove the package and then use a > soldering iron to remove one pin at a time. Clean the pads with > solder wick and then solder a new chip in.) > > > flashrom v1.2 on Linux 5.13.0-30-generic (x86_64) > .. > > Found chipset "Intel Bay Trail" with PCI ID 8086:0f1c. > > I know that coreboot *has* had *some* support for Bay Trail, IIRC > the minnowmax board, IIRC that was the very first attempt at using > Intel's FSP blob in coreboot and I think it did work but it wasn't > a great success. You'd have to investigate. Support for the Bay Trail FSP was dropped from coreboot after the 4.11 release because it's impossible to implement the postcar stage with FSP 1.0 (see 4.12 release notes). However, coreboot still has Bay Trail support using the MRC.bin blob from Chromebooks (the refcode.elf blob used to be required as well, but it was reimplemented as native coreboot code). You can use `mainboard/bostentech/gbyt4` as an example coreboot port for a Bay Trail board. > Kind regards > > //Peter > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: [coreboot][GSoC] idea for a proposal project porting to a Thinkpad AMD Ryzen 3rd gen machine
Hi Lahfa Samy, I was a GSoC student in 2020. I had already been a coreboot contributor for some time, so I came up with a project idea of my own: add support for Intel Bay Trail to libgfxinit (see https://blogs.coreboot.org/blog/2020/08/31/gsoc-libgfxinit-add-support-for-bay-trail/ for details). In a nutshell, I decided to implement support for "new" hardware. I eventually managed to make things work, but just in the nick of time. And I wasn't able to test everything (most notably DP/eDP) as I only had one board to test things with. Hmmm, this reminds me I should revisit these patches and get them submitted. In general, adding support for new (i.e. not yet supported) hardware involves some degree of trial and error. This largely depends on how much the hardware being ported differs from already-supported hardware and how much documentation/resources are available. Here's some examples (they're Intel-specific because that's what I'm most familiar with): - Porting an Asus LGA1155 (the socket for Intel Sandy/Ivy Bridge CPUs) desktop mainboard is (relatively) very easy: coreboot's Sandy/Ivy Bridge code has been tested on many different mainboards (Chromebooks, ThinkPads, other laptops, desktops and even entry-level servers with the same LGA1155 socket), including a dozen Asus LGA1155 desktop mainboards that can be used as reference. I've done Sandy/Ivy Bridge mainboard ports that booted successfully on the first try. - Porting a Sandy/Ivy Bridge laptop is more complicated because one also needs to add support for its EC (which largely consists of trial and error), but getting to the point where coreboot can boot to OS should still be rather easy in most (but not all) cases. In some cases, the EC firmware is on the same flash chip as the x86 boot firmware, so one has to avoid overwriting the EC firmware when flashing coreboot. - Porting a mainboard with an Intel Denverton-NS SoC is substantially more difficult, as parts of hardware init are done by the FSP (Firmware Support Package) blob. FSP is only publicly available as a binary, the source code is only available under NDA (Non-Disclosure Agreement). Moreover, upstream coreboot only supports two mainboards: scaleway/tagada and intel/harcuvar (an Intel reference board, and it's not a good example of a mainboard port). AIUI, most Denverton-NS development happens downstream, in forks that never get upstreamed. So, as very little Denverton-NS development happens upstream, most (upstream) developers don't really know about it, and porting such a board involves significantly more trial and error (and/or having access to NDA-only resources from Intel). - Porting a mainboard with an unsupported Intel chipset is extremely difficult and time-consuming (unless one has access to (normally, NDA-only) information that describes what needs to be done to initialize the chipset, then it's a matter of writing the code and making sure it works). While the high-level flow may be known, the hardware-specific initialisation steps are essentially arcane magic. RAM initialisation is by far the most complex thing that chipset code needs to do, and it's strictly required (can't do much without working RAM). AFAIK, the coreboot code for Intel Westmere (1st-gen Core iX) processors was written without access to NDA-only documentation, but from knowledge acquired through reverse engineering tools like SerialICE (and some parts were borrowed from Sandy/Ivy Bridge code). I don't know how long this took, but it definitely wasn't quick. And while the code seems to work fine on several laptops I've tried to port, it doesn't work on desktop processors (I'm still trying to figure out why). Another thing to note: looks like some of your ideas assume that hardware-based firmware verification mechanisms (e.g. AMD PSB, Intel Boot Guard) can somehow be bypassed. If this assumption can't be proved by the time the GSoC work period ends, the student doing the project will have absolutely nothing to show for it, which would be tragic. In contrast, most project ideas listed in https://doc.coreboot.org/contributing/project_ideas.html can provide results even when they haven't been fully completed. On Thu, Mar 31, 2022 at 10:00 PM Lahfa Samy wrote: > > Hi all Coreboot folks, > > I'm a first year graduate student in CS, been hanging around on #coreboot IRC > (Libera.Chat server) and was thinking if it was possible or not to port > Coreboot to a Thinkpad T495 (AMD Ryzen 7 3700U PRO) manufactured in May 2019, > I successfully dumped the BIOS using flashrom internally, see > `flashrom_info.log` and 'flashrom_info.err.log`. I'm afraid that it's not as easy as it sounds. While coreboot has some code for AMD Zen-based platforms, it's specifically designed to be used with Chromebooks. The Ryzen 7 PRO 3700U is a Picasso SoC, so one could try using the existing coreboot code (and blobs: part of hardware init is done by AGESA code inside binary-only FSP, which runs on the x86 cores). However, I think the Ch
[coreboot] Re: Memory Down approach Error on intel Denverton board
Hi,
On Mon, Jan 24, 2022 at 8:26 AM Ganesh Kumar C via coreboot
wrote:
>
> Hi MariuszX,
>
>
> Thanks for you time .
>
>
> Yes . I have added the below memoryDownConfig struct in
>
> src/mainboard/intel/harcuvar/romstage.c file .
>
> const MEMORY_DOWN_CONFIG mMemoryDownConfig = {
> .SlotState = {
> {STATE_MEMORY_DOWN, STATE_MEMORY_SLOT},
> {STATE_MEMORY_SLOT, STATE_MEMORY_SLOT}
> },
> .SpdDataLen = MAX_SPD_BYTES, //512
> .SpdDataPtr = {
> {(void *)CONFIG_SPD_LOC, (void *)NULL},
> {(void *)NULL, (void *)NULL}
> }
> };
Looks like the Harcuvar memory down code has never been tested,
there's no way it can work as-is. Moreover, documenting code changes
in comments is a terrible idea, because comments aren't compiled.
It's not a good idea to directly access files inside CBFS (for
example, spd.bin is in CBFS) via a hardcoded address (`CONFIG_SPD_LOC`
in this case), as it completely bypasses the CBFS API: nothing
guarantees that the expected data will always be at that address,
there's no way to know the size of the file at runtime and prevents
making use of CBFS security features such as file measurement and
TOCTOU safety (IIRC, it's still work in progress). The right way to
fetch the SPD data using the CBFS API is already implemented in
`src/mainboard/intel/harcuvar/spd/spd.c` function
`mainboard_find_spd_data()`, but the returned pointer is not used in
the code.
I just made https://review.coreboot.org/61341 to show how to do it The
Right Way. Let me know if the implementation from my change works for
you.
> Regards
>
> Ganeshc
Best regards,
Angel
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Denverton-NS refactoring
Hi Jeff, On Fri, Jan 7, 2022 at 5:13 AM Jeff Daly wrote: > > Another thing I'd like to say (and it's probably pretty obvious once the > majority of the commits start coming through) is that a lot of work has been > done for this. In order to make the commit chunks more logical in their > grouping will require that the build will end up breaking because changes in > one area will break another. I started by submitting the changes to the > ifdtool because that's independent of the rest, followed by the changes to > the southbridge/firmware area because again it won't break anything. Next, > is the pci_ids.h because it's just letting everyone know that I'm changing > the names globally (which of course will break the build). > The majority of the change is soc/intel/denverton_ns so that commit will be a > logical group, without worrying about platforms (again will break the build > because the mainboards depend on it), and lastly I'll submit the > mainboards/intel/harcuvar in order to have an example of a platform (and not > break the build if all the other commits before it are part of the build.) > since it look that the buildbot will try and build for each individual commit > vs applying an entire set of commits and building, you'll either have to live > with the breakage until everything is reviewed before applying everything all > at once and fixing it again or someone can point me to an example of how > doing a major overhaul like this would be usable. Normally I'd make a branch > and do it that way, but it seems that's not the way to do it in this > environment? Or did I miss something and I can actually create and push a > branch of my own into this repo? I'm afraid you'll have to restructure your work. Are these commits publicly visible somewhere? If not, you can push them to review.coreboot.org (just for reference, create new changes for the redesigned ). It's hard for me to give concrete suggestions without seeing the code, but I'll happily provide suggestions on how to restructure your work into upstreamable changes. We don't do any merges with Gerrit, so every commit needs to build successfully to get submitted. This is very useful when doing a git bisect to troubleshoot a regression: if the faulty commit got submitted amidst the commits of a patch train that only builds successfully at the end, one would need to fix the build errors while bisecting, with the risk of introducing new bugs which would make it harder to identify where the original problem is. When a commit doesn't break building but results in runtime problems (e.g. boot failure), we call this a regression and we address regressions by either fixing the issue if it's easy to find (e.g. https://review.coreboot.org/55289 used the wrong variable and caused boot issues, https://review.coreboot.org/58558 fixed it) or by reverting the problematic commit. Also, note that intel/harcuvar isn't the only Denverton-NS in the tree: scaleway/tagada would also need to be updated so that it builds successfully. In our workflow, changes to non-mainboard code that impact mainboard code also have to adapt mainboards accordingly. Yes, this is quite annoying when many boards are affected, but having to fix broken boards after non-mainboard code changes didn't update all affected boards accordingly is much worse by several orders of magnitude. Typically, the changes to mainboard code are only annoying because of their repetitive nature, but this shouldn't be an issue for Denverton-NS as there's only two boards in the tree. https://review.coreboot.org/49088 and https://review.coreboot.org/49089 are two examples of non-mainboard-code changes that affect mainboard code. Yes, I could've done this using only one commit, but I think it's easier to review the changes to mainboard code this way: the first commit just removes `cX_battery` settings under the premise that they have the same value as the corresponding `cX_acpower` settings, and the second commit just renames the `cX_acpower` settings to `acpi_cX`. In most cases, it's best to make one commit per logical change, where intermediate states still work even if they're incomplete. When a commit message has a "list of changes" or similar, it's a sign that it can likely be split into several commits. If unsure, it's better to make too many commits and squash some of them later than to make too few commits and end up having to split them up. Intermediate states of my patch trains still work (unless I messed up), but can have ugly things that get fixed later. For example, https://review.coreboot.org/60937 doesn't unindent the body of the original if-block because it gets cleaned up later in https://review.coreboot.org/60938 which is reproducible. A commit is reproducible if the resulting coreboot.rom when building with BUILD_TIMELESS=1 (which avoids including some info like commit hash into the image) is identical before and after the commit, and verifying this is a great way to
[coreboot] Re: Does PCI driver code belong in coreboot (ARM)?
Hi list, On Mon, Dec 6, 2021 at 7:37 AM Jianjun Wang wrote: > > On Sat, 2021-12-04 at 20:53 +0800, Hung-Te Lin wrote: > > On Wed, Dec 1, 2021 at 10:08 PM Patrick Georgi > > wrote: > > > 1. Dezember 2021 12:06, "Paul Menzel" > > > schrieb: > > > > If I remember correctly, coreboot’s goal to only do minimal > > > > hardware > > > > initialization originally meant, that the payload/OS does PCI > > > > initialization. > > > > > > The original idea was to boot into Linux (hence LinuxBIOS, back in > > > the day). coreboot is very different from this scheme, see the > > > presence of payloads that aren't Linux. > > > > > > > Should PCI support be added to coreboot for ARM, so it’s aligned > > > > with > > > > x86? > > > > Should coreboot stay minimal on ARM, for example PCI code adds > > > > 100 ms delay [4]? Paul, coreboot would "stay minimal" if that PCI code was moved into depthcharge as-is, but the 100ms delay would still be there and other payloads would be missing PCI init. I'm pretty sure this isn't what you want, though. > > Need to check with MTK folks, but I'd assume the 100ms will be > > eliminated in the end, or re-implemented as early-init (and do the > > rest in depthcharge). I don't think any of the PCI code belongs into depthcharge. I'm pretty sure it can be integrated better to leverage the existing coreboot infrastructure, e.g. the resource allocator and the devicetree. > Agree, this 100ms is defined by the PCI specification, remove it > directly will cause some compatibility issues, but I think we can put > this flow in the early stage to reduce its impact. As I understand the spec, 100ms is the *minimum* delay before PERST# de-assertion, so it's possible to use a longer delay while doing something else in the meantime. One way to implement this would be to assert PERST# early and do some other initialisation in the meantime, e.g. memory init. To ensure that at least 100ms have elapsed, a stopwatch from `src/include/timer.h` is very convenient. > > > > PCI drivers then have to be added to the payloads, which > > > > could be a minimal Linux kernel, so that booting from drives > > > > connected > > > > over PCI is possible? > > > > > > The only option I see for getting rid of PCI support on ARM is to > > > remodel the relationships between coreboot, the payload and the OS. > > > Reminds me that I wanted to build a proof-of-concept for > > > chainloaded payloads, a concept that might help with such a > > > redesign because we could move things out of coreboot to > > > "elsewhere" (wherever that might be) piece by piece. > > > > > > But as is, if there are PCI(e) devices that need early init, > > > coreboot is the place to put these drivers. > > > > Agree with Patrick - many eMMC devices do need early init, so in > > the > > end we still have to put some eMMC code in Coreboot, > > and I'd assume that will be the same situation for PCI-e (NVMe) and > > UFS. I don't know what this "early init" consists of, but it sounds like something that should be done in coreboot. It could possibly be done in a passthrough/chainloaded payload (which would do late ramstage init), but it wouldn't really make much of a difference. The idea is to start abstracting the hardware so that regular (non-passthrough) payloads don't need to know hardware-specific details. Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3
Hi Branden, On Mon, Nov 29, 2021 at 9:18 PM Branden Waldner wrote: > > I wasn't really sure that I wanted to comment on this, but seeing as > how I have some of the affected boards I guess I should. Thank you very much. > Angel Pons wrote: > > Besides AMD AGESA boards, the other boards that need to be updated are > > AOpen DXPL > > Plus-U (a dual-socket server board that uses Netburst Xeons, no other board > > in the tree uses > > the same chipset code) and various Asus P2B boards (which support Pentium > > 2/3 CPUs, these > > boards are older than me). Even though I only know two people who still > > have some of these > > boards (and they don't have the same boards), they're still supported > > because the code has > > been maintained so far. > > I am one of the two with Asus P2B boards, with Keith Hui being the > other. I've got a P2B and a P2-99 and I believe Keith Hui has a > P2B-LS. > So far there have not been very many changes and Keith Hui and others > have worked on them, all I've done is test master and relevant patch > sets every once in a while. > I know I have not been uploading board_status results and I have not > gotten around to fixing the variant set up for the P2-99 so I'm not > uploading results that are uncertain about which board they are for. > Not really relevant, but I think it is pretty neat to be running > coreboot on boards older then some of the contributors. > > Mike Banon wrote: > > I am often build-testing my boards (didn't notice a > > https://review.coreboot.org/c/coreboot/+/59636 problem for a while, but > > only because I've been > > re-using the previously built toolchains to save time). Also, I am actively > > tech-supporting all the > > people who would like to build coreboot for AMD boards from this list, even > > right now I am in an > > active message exchange with >10 people who are switching to these boards > > to run coreboot > > on them - and any user may give back to the project one day. > > I actually have a few AMD boards and laptops that might be viable for > porting to, but I've never looked in to it much because of the state > support is in coreboot and the fact most of the hardware was actively > being used. > > Arthur Heymans wrote: > > The first one I'd like to deprecate is LEGACY_SMP_INIT. This also includes > > the codepath for > > SMM_ASEG. This code is used to start APs and do some feature programming on > > each AP, but > > also set up SMM. This has largely been superseded by PARALLEL_MP, which > > should be able > > to cover all use cases of LEGACY_SMP_INIT, with little code changes. The > > reason for > > deprecation is that having 2 codepaths to do the virtually the same > > increases maintenance > > burden on the community a lot, while also being rather confusing. > > > > A few things are lacking in PARALLEL_MP init: - Support for !CONFIG_SMP on > > single core > > systems. It's likely easy to extend PARALLEL_MP or write some code that > > just does CPU > > detection on the BSP CPU. - Support smm in the legacy ASEG (0xa - > > 0xb) region. A > > POC showed that it's not that hard to do with PARALLEL_MP > > https://review.coreboot.org/c/coreboot/+/58700 > > I didn't even know that was a problem until now. I doubt there is much > I can do about it myself at this point in time, though I can try to > look through it I guess. Looks like Arthur has already implemented some changes to use PARALLEL_MP on i440bx. As of writing, the patches assume there's only one CPU (I already pointed out this is incorrect for boards with two CPU sockets/slots). I'd greatly appreciate if Keith and/or you could test them on actual hardware. The patches to apply, in order, are: https://review.coreboot.org/59694 https://review.coreboot.org/59695 https://review.coreboot.org/59692 https://review.coreboot.org/59693 > Branden Waldner > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: DIP8 flash programming for development
Hi Pedro, On Fri, Nov 26, 2021 at 11:02 PM Pedro Erencia wrote: > > Hi, > > I'm thinking about porting coreboot to a FM2A88X Extreme4+ board. This board > has a DIP8 flash with a socket and I wondered what would be the best way to > do an efficient development cycle. Ideally, I suppose that the best option > would be to use a clip test and a CH341A, but all the clips that I found are > SOIC/SOP. Should I buy a SOIC clip and an adapter from SOIC to DIP? I've seen > those adapters, but I'm not sure if they will fit well in the mobo DIP8 > socket. I wouldn't recommend a CH341A for the same reasons Nico explained, and would suggest the same alternatives. I've done a lot of development on the Asrock B85M Pro4 (a completely different board, but also has a socketed DIP8 flash chip) and, for me, the most efficient development cycle is to use a flash emulator like the Dediprog EM100. However, flash emulators aren't cheap. Before I had the EM100, I simply moved the flash chip back and forth by hand, from the mainboard to a breadboard wired to a CJMCU FT2232HL mini module (external programmer) and viceversa. I added another DIP8 socket between the flash chip and the mainboard's socket, so that I could easily and quickly remove and replace the flash chip. > Aside from the mechanical question, I'd appreciate any advice about the > safety of externally programming the board. I don't have the schematics and I > wonder if there could be any risk of damaging the board. If you remove the flash chip from the mainboard to reflash it, it's practically impossible to damage the board. > Cheers. > > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3
Hi Mike, I typically don't indulge in mailing list drama, but I'm sick and tired of seeing people waste their time and energy along with others'. This is not the first time I've seen something like this: something similar happened about two years ago when other AMD boards (KGPE-D16 and KCMA-D8, among others) were slated for removal. It was a difficult decision, but had to be done. I really don't want history to repeat itself again, but I fear it's going to happen unless there's a change of attitude right now. On Thu, Nov 25, 2021 at 4:05 PM Mike Banon wrote: > > > The word 'drop' has ominous connotations, but it's not a deletion. A board > > is never really gone. > > "Dropping" 50 boards may be ominous in relation to the future of the > coreboot project: Note that these boards will only be dropped if no one steps up to adapt their code accordingly. Moreover, the first deprecation notice for RESOURCE_ALLOCATOR_V3 was issued as part of the coreboot 4.13 release notes, i.e. last year. The removal was postponed indefinitely because https://review.coreboot.org/q/topic:amd_resource_allocator_v4 implements the required changes. However, not all patches have landed yet, and efforts seem to have stalled: as of writing, all but one of the unmerged changes were last updated in May 2021, and the outlier was last updated in 2021-06-23. Hopefully, this notice will reactivate efforts to get these patches submitted without reactivating the local mailing list volcanoes. IMHO, lamenting about deprecation notices on the mailing list is counterproductive: it invests no resources into addressing the root problem (code needs to be maintained, but isn't), but instead tries to somehow avoid having to address the root problem by inciting emotional responses from others, such as anger. In my experience, this is a recipe for a conflict, a bitterly unpleasant waste of many people's time and energy for naught, leading to an equally disgraceful aftermath; a war in which most of the casualties are motives to work on the project. Wouldn't it be much more useful to, say, work on adapting the code, add new features or improve existing functionality, write some documentation, or even check the grammar of the code comments in the tree? > 1. These boards will be gone for the people who check the "mainboards > supported by coreboot" and see only the "new Intel stuff". This > hinders the coreboot community growth around the "gone boards", and > also of the coreboot community in general: the fewer boards are > supported by coreboot, the more difficult it is for a potential > user/contributor to find the supported board and join us. In my experience, most people who've contributed didn't have a supported board. I myself got involved with the coreboot community because none of the boards I had was supported; about three and a half years later, I now am one of the most active contributors. I only tolerated the bugs and limitations of coreboot (let's be honest; we're not perfect and we don't provide the same features as vendor firmware) because I was experiencing first-hand how hard firmware development is. I'm pretty sure I wouldn't be writing this email had one of my boards already been supported. Granted, it's nearly impossible for a newcomer to port a board when its chipset is not supported. The first board I ported is the Asus P8H61-M PRO, an Intel Sandy/Ivy Bridge desktop board with a serial port and a socketed DIP8 flash chip. Back then, Sandy/Ivy Bridge was one of the best-supported platforms (and still is, as of writing). Several people on IRC (to which I'm forever thankful) helped me port this board. I only know of one person on IRC that could help porting an AMD board using AGESA, and there aren't many people who have AGESA-supported boards. > 2. It's not just the loss of boards - it's also the loss of coreboot > users/contributors who only have these boards and don't want to switch > to anything else: i.e. because the newer coreboot-supported boards > have Intel ME / AMD PSP that are viewed negatively by many people out > of security considerations, - and security is one of the top reasons > why the people switch to coreboot in the first place. First and foremost, there's support for older Intel boards that don't require ME firmware or simply don't have a ME at all, and people still use them. Besides AMD AGESA boards, the other boards that need to be updated are AOpen DXPL Plus-U (a dual-socket server board that uses Netburst Xeons, no other board in the tree uses the same chipset code) and various Asus P2B boards (which support Pentium 2/3 CPUs, these boards are older than me). Even though I only know two people who still have some of these boards (and they don't have the same boards), they're still supported because the code has been maintained so far. If there are contributors who only have these boards, where are they? Why aren't they trying to adapt the code? If they don't know how, why haven't they asked for help on how
[coreboot] Re: Personal challenge | Ramp up on coreboot : Trials on aftermarket X58 motherboards.
Hi Mickaël, On Tue, Nov 23, 2021 at 11:29 AM Master wrote: > > Hello everyone, > > I hope you're doing fine > > I would like to do some trials to see if I may be able to support few boards > I have cause they are aftermarket withoout EFI and without firmware updates > and not working as I would like them to. > (https://askubuntu.com/questions/1370496/cant-boot-latests-lives-for-install-without-kernel-option-noapic-would-like) > I really would not like to throw them... > > They are X58 chipset with ICH10 with Xeon Westmere on socket 1366 and > SuperIO NCT5532D. > (https://www.intel.com/content/dam/doc/datasheet/x58-express-chipset-datasheet.pdf) > (https://www.intel.com/content/dam/doc/datasheet/io-controller-hub-10-family-datasheet.pdf) > (https://datasheetspdf.com/pdf-file/1042365/novoTon/NCT5532D/1) Only the ICH10 southbridge (southbridge/intel/i82801jx) is currently supported. Neither the CPU nor the X58 IOH are supported. Most of the complexity is RAM initialization, especially because Intel does not publicly document the relevant registers. It would likely take years for an experienced developer to implement RAM init in coreboot. The NCT5532D Super I/O isn't supported either, but it's easy to add support for it using the datasheet. > I have the tooling to backup and restore the flash and already done that few > time. > I have built latest coreboot (4.14 using lenovo x201 config) with EDK2 > firmware as payload (edk2-stable202108 NOOPT) successfully but nothing is > happening after flash swap and power on. Flashing a firmware image for a different board is a bad idea. In extreme cases, incompatible GPIO configuration can result in short-circuits. It's unlikely, though. > I have RS232 debug working at ttyS0 (at I/O 0x3f8 (irq = 4, base_baud = > 115200) is a 16550A) > From the original firmware, just after power on, even before any bip or > display or keyboard light I see "Socket = 0" on serial, so the the original > firmware is able to output to this serial very early. > > I read quite a lot of literature about coreboot, but still, I am not sure how > to pursue now. It's hard. I can give you general ideas on how to proceed (I'm pretty sure we can get coreboot to print something over RS232), but RAM init is still a major roadblock. Once serial output is working, it's possible to use SerialICE to gather useful information to reimplement RAM init. > Thanks in advance, > Have a nice day, > Best Regards, > Mickaël. > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Does the mrc.bin extracted from BayTrail-M chromebox work with BayTrail-D celeron J1900
Hello, On Thu, Nov 4, 2021 at 8:58 AM Simon Newton wrote: > > Hi there > Yes it does. Rename mrc.bin to mrc.elf Yes, the latest Bay Trail MRC binaries are ELF files, so their entry point is not at the beginning of the file. MRC's position in flash needs to be adjusted accordingly using the data in the ELF header. However, the Makefile only does this if the filename contains `elf` somewhere. https://review.coreboot.org/57989 removed the filename check, but it's not in the coreboot 4.14 release. Things like this are the reason why using the master branch for development is best (in most cases; there are exceptions, but this isn't one of them). > Regards > > On Thu, 4 Nov 2021 at 08:45, Zhiwen Zheng wrote: >> >> Hi, >> >> I am trying to add a mainboard using celeron J1900 to coreboot-4.14, the >> serial console output stops after entering the MRC. The mrc.bin I used is >> extracted from Mrchromebox's roms for baytrail based chromebooks. Yes, Bay Trail MRC works with the Celeron J1900, I know for sure because I've tried it myself. I started porting the Asrock Q1900M mainboard many months ago, https://review.coreboot.org/39658 contains the code. It's been over a year since I last updated this change, so it's very likely that it doesn't build on current coreboot. I had to work around several MRC limitations to successfully boot coreboot on my Asrock Q1900M. The first limitation is that MRC can't read SPDs over SMBus, but https://review.coreboot.org/44092 already addresses this. The relevant code is in romstage.c after the `/* Patch memory type and voltage settings to make MRC happy */` comment on line 25, which overwrites some SPD information. The code does two things: 1. Bay Trail MRC refuses to work with the regular size DIMMs the Asrock Q1900M uses. Override the module type to SO-DIMM by patching byte 3 (Key Byte/Module Type). 2. Bay Trail MRC refuses to train DDR3 DIMMs that do not support 1.35V operation. Patch byte 6 (Module Nominal Voltage, VDD) to bypass this. Vendor firmware works properly with the same DIMMs. While I was typing this, I noticed your latest reply. If RAM init succeeded, then the above workarounds aren't needed. Still, someone else might find this information useful in the future. >> ___ >> coreboot mailing list -- coreboot@coreboot.org >> To unsubscribe send an email to coreboot-le...@coreboot.org > > -- > Kind Regards, > > Simon Newton > > E: simon.new...@gmail.com > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Installing OpenBIOS/coreboot
Hi Bernd, On Tue, Nov 2, 2021 at 12:08 PM bernd...@web.de wrote: > > Hi. Just to ensure I don't go in the wrong direction: If I follow these > instructions https://doc.coreboot.org/tutorial/part1.html do I install > coreboot with OpenBIOS (because I've read something with SeaBIOS or so)? These instructions build a coreboot image with coreinfo as a payload and run it on the QEMU virtual machine. They're a guide to get started with coreboot. If your goal is to install coreboot on an x86 system while keeping it simple, don't go with OpenBIOS. The simplest configuration is coreboot with the SeaBIOS payload. Feel free to try SeaBIOS with QEMU, experiment without any risks. Installing coreboot on actual hardware is more complex. Unlike operating systems (Windows, Linux...), coreboot is tightly coupled to the hardware it runs on, so it's not possible to simply "install coreboot" on any computer using a generic procedure. Instead, coreboot needs to be flashed to a flash chip on the mainboard, and the best flashing procedure is mainboard-dependent. For example, the X220 can easily be flashed externally with a SPI programmer and a SOIC-8 chip clip, but applying the same procedure on an X230 is very likely to cause problems (and recovery is even more complicated). > Regards, > > Bernd___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Installing OpenBIOS/coreboot
Hi ___ (hmmm, I don't think this is your name), On Tue, Nov 2, 2021 at 11:19 AM bernd...@web.de wrote: > > Hi. I follow these instructions: > > https://doc.coreboot.org/tutorial/part1.html > > I'm on Step 5 - Configure the build > Check your configuration (optional > step): > > I did > > $ make savedefconfig > $ cat defconfig > > The instructions say: > > "There should only be two lines (or 3 if you’re using the system toolchain): > > CONFIG_PAYLOAD_ELF=y > CONFIG_PAYLOAD_FILE="payloads/coreinfo/build/coreinfo.elf"" > > I'm not using the system toolchain. There are the following 9 lines (instead > of only two): > > CONFIG_CBFS_SIZE=0x0004 > CONFIG_CONSOLE_CBMEM_BUFFER_SIZE=0x2 > CONFIG_UART_PCI_ADDR=0x0 > CONFIG_SUBSYSTEM_VENDOR_ID=0x > CONFIG_SUBSYSTEM_DEVICE_ID=0x > CONFIG_CONSOLE_QEMU_DEBUGCON_PORT=0x402 > CONFIG_POST_IO_PORT=0x80 > CONFIG_PAYLOAD_ELF=y > CONFIG_PAYLOAD_FILE="payloads/coreinfo/build/coreinfo.elf" > > Why do I get 9 lines (instead of only two) and is that a problem or could I > go on with the instructions? Extra lines appear in defconfigs because of a recent regression, if I recall correctly. In any case, your config looks correct, you can go on with the instructions. > Regards,___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: ECC in native ram init? (sandy/ivy)
Hi Matt, list, On Wed, Sep 8, 2021 at 3:29 PM Matt B wrote: > > Would an Ivybridge CPU even be expected to work with RDIMMs? Was this > something anticipated when native raminit was written? I don't think so. RDIMMs have higher latencies and very likely exceed the maximum value that can be programmed into the chipset's timing registers. Native raminit doesn't account for RDIMMs at all. > -Matt Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Firmware another laptop
Hi Stefano, Keith, list, On Thu, Aug 19, 2021 at 10:17 PM Keith Emery wrote: > > I think you meant to ask if it's possible to do. That can't be answered > without more information about the hardware... A lot more. > > At a minimum the precise model of mainboard, or a precise model number. > > On 20/8/21 12:02 am, Stefano via coreboot wrote: > > Good morning I can install the coreboot firmware on my dell alienware 17 with > Linux mint (updated to the latest version)? No Dell Alienware laptops are currently supported, so no, you can't just install coreboot on it. It might be possible to port it (make coreboot work on it), but laptops are pretty hard to port because of the embedded controller: an often-undocumented microcontroller running proprietary firmware. > Best regards > Stefano > > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: coreboot-4.8.1 ... mce errors
Hi Nico, Sven, On Fri, Jun 11, 2021 at 9:19 AM Nico Huber wrote: > > Hi Sven, > > On 11.06.21 00:55, Sven Semmler wrote: > > On my ThinkPad T430 running Coreboot-4.8.1 as part of an Heads install, > > I see these error messages when turning on the PC: > > > > mce: [Hardware Error]: CPU 0: Machine Check: 0 Bank: 7: ee2000 > > 3110a > > mce: [Hardware Error]: TSC 0 ADDR fefe78c0 MISC 388086 > > mce: [Hardware Error]: PROCESSOR 0:306a9 TIME 1622589409 SOCKET 0 > > mce: [Hardware Error]: CPU 0: Machine Check: 0 Bank: 8: ee2000 > > 3110a > > mce: [Hardware Error]: TSC 0 ADDR fefe7880 MISC 388086 > > mce: [Hardware Error]: PROCESSOR 0:306a9 TIME 1622589409 SOCKET 0 > > APIC 0 microcode 1f > > > > I do not think it is an issue with the actual RAM: > > Indeed, this is not about the actual (D)RAM. One can tell by the > address already, 0xfefe this is part of what we call I/O hole, > a region reserved from the memory address space for different purposes. > > More specifically, 0xfefe..0xfeff is a range used for cache- > as-ram (CAR) which is a mode where the processor cache is used as RAM > before the actual DRAM is available. > > I have seen these MCEs before, but never investigated. They might affect > the stability of coreboot, but it seems less likely that they affect the > running OS once the system succeeded to boot. They look a lot like what https://review.coreboot.org/28443 fixed. You could check if commit dfaff4d18a711f764c9198f488435fdc553dcea2 exists on 4.8.1 (if it does not, there's your problem). Also, have you considered using a more recent coreboot version? 4.8.1 is over three years old, and the ThinkPad T430 is still supported on all newer releases (latest is 4.14). > Nico Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: link time optimization testing
Hi Branden, list, On Tue, Jun 1, 2021 at 2:10 AM Branden Waldner wrote: > > The LTO patches seem to both compile and work/boot for me on the p2b. > > I built it both on a debian sid x86_64 system and on the gentoo i686 > setup I currently have for the p2b, both with the coreboot > crossgcc-i386 toolchain. That's great to hear. I hope you didn't need to build crossgcc-i386 on the P2B, though! :P > It looks like it uses the system linker though (or something similiar, > I don't remember exactly), at least according to the executable path > it shows in the build log. I'm not sure if that's actually what's > desired or if I'm just misinterpreting something. It might be intentional, but it's not desired: using the system toolchain to build coreboot will wreak havoc when cross-compiling. > It still looks like it needs more test reports yet, though I guess I'm > not helping either by not commenting on gerrit. Yes, it needs more test reports. It would be great if you could comment on the Gerrit change, so as to keep all test reports in one place. > Branden Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: What should we do about freenode IRC services?
Hi, On Thu, May 27, 2021 at 10:05 AM Patrick Georgi wrote: > > For that reason I created https://review.coreboot.org/c/coreboot/+/55010 and > https://review.coreboot.org/c/coreboot/+/55011 that retarget IRC links to > libera.chat, promote the Matrix bridge and the Discord presence. Last link doesn't work, try with: https://review.coreboot.org/c/homepage/+/55011 > Regards, > Patrick Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: What should we do about freenode IRC services?
Hi list, On Thu, May 27, 2021 at 12:39 AM Stefan Reinauer wrote: > > On Tue, May 25, 2021 at 6:01 AM Patrick Georgi via coreboot > wrote: >> >> Hi everybody, >> >> you might have heard that freenode.org recently changed management under >> weird circumstances. Given that we use their services for our project >> chat, this concerns us as well. >> >> In last week's leadership meeting we had a wide variety of opinions: To >> go for libera.chat (a network created by former freenode staff), some >> other IRC network, to leave IRC behind and go for something newer and >> Matrix and Mattermost have been brought up as examples of where this >> might lead. Of course, we could also decide to stay on freenode, >> although from what transpires that option seems less and less attractive >> every day. >> >> So, what should we do? I'd suggest moving to Libera. I think the Matrix bridge to Libera is running now. > As we are present on a number of social media, I want to throw in another > option - which some folks will love, and others will hate - and that's > perfectly fine. This community has grown enough that there will never be a > one size fits all again: > > Discord > > It can both be accessed in a web browser or through a mobile app. I started a > "Discord Server" for us there. If you want to come check it out, join us > through https://discord.gg/JqT8NM5Zbg Sure, we can have both IRC and Discord. > Stefan >> >> Regards, >> Patrick On Thu, May 27, 2021 at 9:23 AM Urja Rannikko wrote: > > > > Currently, on libera there are 46 people and on OFTC 2 people (me > > > included). > > > > > > So I would say let's move to libera. > > > > Agreed. Let’s do what most members in #coreboot users already did. > +1 > > I know I'm not a regular contributor or anything, but fwiw currently > the only channels keeping me connected to freenode are #coreboot and > #flashrom (I assume flashrom will just tag along where coreboot goes), > so .. let's go, we've watched this long enough. Yes, definitely. It wouldn't make sense to have #coreboot on one IRC server and #flashrom on another. > -- > Urja Rannikko Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Yangling/ FW6C board with different SUPERIO CHIP, I found the problem
Hi, On Fri, May 14, 2021 at 7:38 PM lain via coreboot wrote: > > Probing for ITE Super I/O (init=standard) at 0x2e... > Failed. Returned data: id=0x8613, rev=0x8 superiotool doesn't know about the IT8613E, but looks like there's one. Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Intent to release coreboot 4.14 on May 10
Hi Patrick, list, On Mon, Apr 26, 2021 at 3:12 PM Patrick Georgi via coreboot wrote: > > Hi everybody, > > This email starts the release process for coreboot 4.14, so we're now at the > "~2 weeks prior to release" step in our > https://doc.coreboot.org/releases/checklist.html > > As usual, our releases don't denote any particular feature or stability > milestone, they only serve two purposes: > 1. Avoid the impression that coreboot is dead - an idea that actually came up > before we started doing time-based releases > 2. Provide anchor points that downstream coreboot users can use to base their > work against if they wish to do so > > What everybody can do: Consider testing the devices you have against our > current master branch, send in board-status reports so boards are known-good > in https://coreboot.org/status/board-status.html, report or, even better, fix > issues you encounter. Stoney Ridge fails to boot since https://review.coreboot.org/51723 landed. Something would need to be done about it before the release, most likely a revert. > As a developer, please consider if your large scale tree change can wait for > after the release so that the tree can settle down a bit. But also, if you > have large changes that are waiting (such as toolchain updates), you could > already start to bring them in shape to merge after the release! > > Also, please check out the release notes in > Documentation/releases/coreboot-4.14-relnotes.md to see if any notable work > of the last 6 months is missing there. Addition and deletion of mainboards > and SoCs will be added shortly before the release with script assistance, but > everything else won't be. Patches to extend our release notes are appreciated! I'm be glad to review any patches to the release notes, simply add me as a reviewer or poke me on IRC (hell__). > Thanks y'all for making coreboot what it is now. As a release manager I'll > merely put another label on it :-) > > > Best regards, > Patrick > -- > Google Germany GmbH, ABC-Str. 19, 20354 Hamburg > Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: > Hamburg > Geschäftsführer: Paul Manicle, Halimah DeLaine Prado > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: HP compaq 8200 compatability
Hi Peter, list, On Mon, Apr 12, 2021 at 12:06 PM Peter Stuge wrote: > > ppbruhuwu--- via coreboot wrote: > > Hello so i was talking to my friend about coreboot but i saw that > > only the SFF version of the compaq 8200 was compatible and so i > > wanted to know why that is? > > Those adding that code were only interested in supporting that model. Or only had a SFF model to test things on. > > Also will coreboot be available for the compaq 8200 in the future? > > It could, if you or someone else makes it happen. If you're interested > then you should not wait for someone else to do it for you, since > that's unlikely. It shouldn't be too hard to add support for the other form factors. After making sure the GPIO settings match (use util/autoport and compare the gpio.c files), it might be as simple as enabling a few devices in the devicetree. > //Peter > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: problem after "convert to ASL 2.0"
Hi Andrew, list On Tue, Apr 6, 2021 at 6:52 PM Andrew A. I. wrote: > > Hello, Elyes! > After "Convert to ASL 2.0 syntax" set of commits to current coreboot branch, > i lost the data of battery current on BAT state from: > cat /sys/class/power_supply/BAT0/current_now > 0 > On AC state (charging) data is present: > cat /sys/class/power_supply/BAT0/current_now > 1346000 > Checkout to coreboot tag/4.13 is fixing the problem. > But system was very unstable with: > > Apr 4 23:45:06 tp0 kernel: [ 60.868922] BUG: unable to handle page fault > for address: 00ccfffc > Apr 4 23:45:06 tp0 kernel: [ 60.868992] #PF: supervisor read access in > kernel mode > Apr 4 23:45:06 tp0 kernel: [ 60.869033] #PF: error_code(0x) - > not-present page > Apr 4 23:45:06 tp0 kernel: [ 60.869074] PGD 0 P4D 0 > Apr 4 23:45:06 tp0 kernel: [ 60.869102] Oops: [#1] SMP PTI > Apr 4 23:45:06 tp0 kernel: [ 60.869134] CPU: 0 PID: 1960 Comm: git > Tainted: G U5.10.0-5-amd64 #1 Debian 5.10.24-1 > Apr 4 23:45:06 tp0 kernel: [ 60.869261] RIP: 0010:__d_lookup_rcu+0x82/0x170 > > System: > Lenovo T420 > coreboot-4.13-2951-g0972871a23-T420 > Debian bullseye/sid > Battery in main slot > > Any ideas? It's most likely this commit, and I already noticed an issue with it: https://review.coreboot.org/50317 You can try reverting it to see if the problem gets fixed. > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Which of these mini-ITX mainboards is best supported?
Hi Andrew, On Fri, Feb 5, 2021 at 6:06 PM Andrew Luke Nesbit wrote: > > On 04/02/2021 09:41, Angel Pons wrote: > > Hi Andrew, > > Hi Angel, > > Thanks for the reply. > > > On Wed, Feb 3, 2021 at 11:46 PM U'll Be King Of The Stars > > wrote: > >> > >> - Intel D410PT (doesn't seem to be in current source tree) > > > > The D410PT and the D510MO use the same code. Support was added in > > https://review.coreboot.org/2 (which merely renames the Kconfig > > option). > > I think I misunderstand something... > > Are you saying that support for the D410PT came with support for the > D510MO, but that recent source trees have removed explicit support for > the D410PT for some reason? I can't find any reference to D410PT in the > latest source tree. If by "explicit" support you mean a dedicated mainboard folder or a "BOARD_INTEL_D410PT" Kconfig option, there was never one to begin with. The Gerrit change I linked merely added the model in the user-visible text of the "BOARD_INTEL_D510MO" Kconfig option, which is located in `src/mainboard/intel/d510mo/Kconfig.name`. In other words, the same coreboot config works for both the Intel D510MO and the Intel D410PT. > I'm still getting used to reading the coreboot source tree. Maybe I'm > doing this all wrong. > > If you could please point to something additional that is informative, > then that would be very helpful. > > Andrew Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Which of these mini-ITX mainboards is best supported?
Hi Andrew, On Wed, Feb 3, 2021 at 11:46 PM U'll Be King Of The Stars wrote: > > - Intel D410PT (doesn't seem to be in current source tree) The D410PT and the D510MO use the same code. Support was added in https://review.coreboot.org/2 (which merely renames the Kconfig option). Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] One QCLK is half a full clock cycle (tCK)
Hi list, I'm writing this email because there's one thing I always forget about. Now that I am sure about it, I would like to write it down somewhere so that I can't forget about it anymore. Anyway, that one thing is: On Intel memory controllers, one QCLK (Quadrature Clock) equals one half of a full clock cycle, i.e. tCK / 2. Best regards, Angel, the tormentor of memory controllers ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Help locating BIOS flash IC on a not yet supported mini PC board
Hi Peter, On Tue, Jan 12, 2021 at 6:15 PM Peter Mueller wrote: > > https://pasteboard.co/JJknICr.jpg Ah, I see it: it's on the top right quadrant next to the USB connector. That gray thing is a socket, and should contain the flash chip we're looking for. Lucky you! With the flash chip in a socket, you can simply put it in one of these sockets to program it: https://i.imgur.com/QPOSDAM.jpg Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Help locating BIOS flash IC on a not yet supported mini PC board
Hi Peter, On Tue, Jan 12, 2021 at 4:26 PM wrote: > > Hello coreboot community, > > as an open source fan I recently get to know coreboot and really like the > idea behind. > Sadly I bought my computer HW before learning more on libre friendly hardware > that > respects your freedom. Now I try to figure out if I could do one or both of > a) installing coreboot , b) remove /disable ME from my zotac mini PC, > or I had to look out for already supported HW to do so. > > I use a zotac CI 640 nano fanless mini PC with kaby lake Intel Core i5-8250U > and intel > UHD grafics. https://www.zotac.com/product/mini_pcs/ci640-nano#spec You may be able to port it, though you will need to use Intel FSP. I'm afraid no one wrote a coreboot porting guide for FSP platforms yet. If you ask me, I'd rather write a FSP replacement, but ENOTIME. > In the process of cleaning FW I got stuck while figuring out, what is the > relevant flash IC > storing the bios. Form running linux I could read an 8MB flashrom with > flashrom tool and > internal programmer. > > While reading, flashrom reported chipset "Intel Kaby Lake U w/ iHDCP2.2 Prem." > and gave the warning "SPI configuration lockdown activated". The programmer > flashchip was reported as "Opaque flash chip" 8192kB. > At least ME Cleaner worked with not errors on the captured fw image. > > Problem: I want to flash the modified image back to the IC using a raspberry > 4b > with gpio spi setup using a SOIC8 clip. But I could not manage to find the > correct > IC on the mainboard. I kept looking for SOIC8 200mil with some "25" signature > and found only a GD25Q20C(2M-bit)Serial flash chip, that I could successfully > read with raspberry spi setup. However, it contains only 256k data. strings > showed > me lots of HDMI related stuff. This chip contains the LSPCON (Parade PS175) firmware. I know because I've got a different board here with the same setup. It is a SPI flash chip, but it's not the one you are looking for. > I have created a list of chips I found while disassembling and some pics. > I hope that someone more experienced could explain me how the 8MB fw is > stored on this zotac and if it is "safely" possible to rewrite it. I it is to > difficult or > dangerous, as beginner I will stick with new hardware from already supported > hw list. > > The "promising" IC chips I found were > a - 1 piece of "G labeled" AH1815 25Q2 1BT EE455, I think it is related to the > GigaDevice GD25Q20C(2M-bit)I found on web. this chip I managed to read > out.. > b - 12 pieces of SOIC8 150mil (or samller?) : M B07 N03 EKH 1409 (Macronix? > could not find anything:/ ) > c - 1 piece of Issi IS25LQ020: 256K x 8 (2 Mbit) (maybe related to USB-C > extension module) > d - 1 piece of RT9059 GSP6E TOC, which I think could be a RichTek ultra low > power voltage regulator? > e - 4 pieces of "P labeled" 6982 GA9C1E ICs, I do not know what they are, > maybe some MOSFET? > f - 1 piece of "P labeled" 4435 GL9B2E SOIC8 200mil which I know nothing > about None of these is large enough. You are looking for a SOIC8 200mil chip: https://doc.coreboot.org/_images/librem_mini_flash.jpg > Pics of the mainboard front and back are here: > https://pasteboard.co/JJjQqQO.jpg > https://pasteboard.co/JJjRjLU.jpg > https://pasteboard.co/JJjRCDt.jpg I can't see any flash chip on the pictures you sent. Could you please take one picture of each side of the mainboard without any obstructions (RAM sticks, add-in cards, tape...) on it? > Any suggestion how to go on or stop it anyway would be appreciated. > > kind regards, > > Peter Mueller > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Supporting a new board
Hi, On Tue, Jan 12, 2021 at 11:24 AM Alif Ilhan wrote: > > Thank you. I will make sure it will not happen. But can anyone tell me where > can I find MRC.bin from pineview? Which chromebook specifically? Pineview Chromebooks did not use coreboot, so there's no MRC.bin to use with coreboot. In any case, Cedarview's memory controller is much different from Pineview, and is actually closer to Bay Trail: there's no MCHBAR, and the relevant registers are spread across several IOSF "units". For example, high-level memory controller registers are in the DUnit, and there's one DUnit per channel. The 2nd volume of the Atom D2000/N2000 datasheet contains a long table with IOSF ports and register offsets, which can be useful. Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: "Fixing" `1 << 31` (technically undefined behavior with known implementation-specific results)
Hi list, Since register fields usually have more than one bit, I prefer to always use explicit shifts for consistency. The one case where I prefer the BIT() macro is to reduce the amount of nested braces when testing for individual bits in a mask. GCC encourages adding unnecessary braces for expressions such as `1 << x + 3`, so it's easy to end up with five levels of brace nesting in a single expression. For silicon-specific code where portability isn't an issue (different hardware, different registers) and there's lots of hardware registers with multiple fields each, I prefer to use bitfield structs. The resulting code is rather verbose because it provides more information to both humans and compilers, so there can be less comments that can eventually become lies. This approach also prevents making certain kinds of mistakes, e.g. using the names from a different register or using too large constants in initializers, both of which will cause a build failure. This also avoids compiler woes when using bitwise negations in functions taking an AND-mask, where values get promoted to signed int and then need to be truncated to a smaller size unsigned type. Refer to https://review.coreboot.org/42134 for a more detailed explanation of the issue. When using bitfield structs, updating the value in a register field involves three discrete steps: read the register into a local variable, then assign the new value to the desired field (or fields), and finally write the updated value back. This is substantially more verbose, but it's also harder to make a dumb mistake such as forgetting to negate a mask. Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Announcing coreboot 4.13
SMRAM space and not by 64K. By default this loader version is disabled. Please see cpu/x86/Kconfig for more info. ### Address Sanitizer coreboot now has an in-built Address Sanitizer, a runtime memory debugger designed to find out-of-bounds access and use-after-scope bugs. It is made available on all x86 platforms in ramstage and on QEMU i440fx, Intel Apollo Lake, and Haswell in romstage. Further, it can be enabled in romstage on other x86 platforms as well. Refer [ASan documentation](../technotes/asan.md) for more info. ### Initial support for x86_64 The x86_64 code support has been revived and enabled for QEMU. While it started as PoC and the only supported platform is an emulator, there's interest in enabling additional platforms. It would allow to access more than 4GiB of memory at runtime and possibly brings optimised code for faster execution times. It still needs changes in assembly, fixed integer to pointer conversions in C, wrappers for blobs, support for running Option ROMs, among other things. ### Preparations to minimize enabling PCI bus mastering For security reasons, bus mastering should be enabled as late as possible. In coreboot, it's usually not necessary and payloads should only enable it for devices they use. Since not all payloads enable bus mastering properly yet, some Kconfig options were added as an intermediate step to give some sort of "backwards compatibility", which allow enabling or disabling bus mastering by groups. Currently available groups are: * PCI bridges * Any devices For now, "Any devices" is enabled by default to keep the traditional behaviour, which also includes all other options. This is currently necessary, for instance, for libpayload-based payloads as the drivers don't enable bus mastering for PCI bridges. Exceptional cases, that may still need early bus master enabling in the future, should get their own per-reason Kconfig option. Ideally before the next release. ### Early runtime configurability of the console log level Traditionally, we didn't allow the log level of the `romstage` console to be changed at runtime (e.g. via `get_option()`). It turned out that the technical constraints for this (no global variables in `romstage`) vanished long ago, though. The new behaviour is to query `get_option()` now from the second stage that uses the console on. In other words, if the `bootblock` already enables the console, the `romstage` log level can be changed via `get_option()`. Keeping the log level of the first console static ensures that we can see console output even if there's a bug in the more involved code to query options. ### Resource allocator v4 A new revision of resource allocator v4 is now added to coreboot that supports mutiple ranges for allocating resources. Unlike the previous allocator (v3), it does not use the topmost available window for allocation. Instead, it uses the first window within the address space that is available and satisfies the resource request. This allows utilization of the entire available address space and also allows allocation above the 4G boundary. The old resource allocator v3 is still retained for some AMD platforms that do not conform to the requirements of the allocator. Deprecations ### PCI bus master configuration options In order to minimize the usage of PCI bus mastering, the options we introduced in this release will be dropped in a future release again. For more details, please see [Preparations to minimize enabling PCI bus mastering](#preparations-to-minimize-enabling-pci-bus-mastering-in-coreboot). ### Resource allocator v3 Resource allocator v3 is retained in coreboot tree because the following platforms do not conform to the requirements of the resource allocation i.e. not all the fixed resources of the platform are provided during the `read_resources()` operation: * northbridge/amd/pi/00630F01 * northbridge/amd/pi/00730F01 * northbridge/amd/pi/00660F01 * northbridge/amd/agesa/family14 * northbridge/amd/agesa/family15tn * northbridge/amd/agesa/family16kb In order to have a single unified allocator in coreboot, this notice is being added to ensure that the platforms listed above are fixed before the next release. If there is interest in maintaining support for these platforms beyond the next release, please ensure that the platforms are fixed to conform to the expectations of resource allocation. Best regards, Angel Pons OpenPGP_0x53C88CBFBC4F65F3.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Memory initialisation error
Hi Andy On Wed, Nov 18, 2020 at 1:22 PM Andy Pont wrote: > > Angel wrote... > > I can’t match what is printed on the top of the Micron devices (two lines of > text “0JE75” and “D9ZFW”) to any part numbers on Micron’s website. Is it some > kind of encoded version of the part number or is it just factory and build > information? Looking at the website I would assume that the MT40A512M16JY > family would be the equivalent parts. > > > https://www.micron.com/support/tools-and-utilities/fbga > > That is a cool and useful tool, and not one that was obvious to stumble > across! That identifies the memory as MT40A1G16KD-062E:E. The existing > Coreboot sources seem to reference SPD for this part in two forms (Google > Zork and Drallion) so I have “borrowed” the SPD files. Nice! > The debug output on my board is different to before as the mainboard specific > memory initialisation code is now being called but ends with: > > SPD INDEX = 0 > FMAP: area COREBOOT found @ 490200 (11992576 bytes) > CBFS: Locating 'spd.bin' > CBFS: Found @ offset 50bc0 size 200 > SPD: module type is DDR4 > SPD: module part number is M471A5244BB0-CRC > SPD: banks 8, ranks 1, rows 16, columns 10, density 8192 Mb > SPD: device width 16 bits, bus width 64 bits > SPD: module size is 4096 MB (per channel) > memory slot: 0 configuration done. > memory slot: 2 configuration done. > POST: 0x36 > POST: 0x92 > POST: 0x98 > FspMemoryInit returned 0x8007 > POST: 0xe3 > FspMemoryInit returned an error! > > The values in the SPD look wrong but also FspMemoryInit is still failing. Is > there any way to understand what it making FspMemoryInit do so? Well, I'd like to see your code: which memcfg parameters you're using, among other things. Could you please put it somewhere (e.g. review.coreboot.org) so that I can take a look? > -Andy. Thanks in advance, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Memory initialisation error
Hi, On Wed, Nov 18, 2020 at 10:00 AM Andy Pont wrote: > > Naresh wrote… > > Don't know how to recover SPD from UEFI but Try to read memory part number > written on chip and provide that. Look for SPD file with that name if it's > already present in coreboot. > > The schematics for the platform show Samsung K4A8G165WB-BCRC devices which > are (8Gb, 2400Mbps, 512Mx16 DDR4). The samples of hardware that I have are > actually fitted with Micron parts. > > I can’t match what is printed on the top of the Micron devices (two lines of > text “0JE75” and “D9ZFW”) to any part numbers on Micron’s website. Is it > some kind of encoded version of the part number or is it just factory and > build information? Looking at the website I would assume that the > MT40A512M16JY family would be the equivalent parts. https://www.micron.com/support/tools-and-utilities/fbga > -Andy. > > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Planning the next coreboot release
Hello again, Given that there's still some activity going on regarding deprecations on the release notes, the release may be delayed one or two more days to let things settle down, but no more. I look into having the release done this week, but I'd also like to proceed without rushing as it's my first time doing a coreboot release. Thanks for your comprehension, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Information about "HP-Compaq 8200 Elite SFF"
Hi Dario, On Sun, Nov 15, 2020 at 5:42 PM wrote: > > Hi guys > Thanks a lot for the great work on coreboot. > > I'm looking for install coreboot on my "HP-Compaq 8200 Elite SFF", so > I was happy to found your site: > https://doc.coreboot.org/mainboard/hp/compaq_8200_sff.html > > In this documentation stands: "Internal programming: The SPI flash can > be accessed using flashrom.". So I tried to read the factory-BIOS with > flashrom but without success. Please consult the annexed log-file. I fear that stderr was not logged. Instead of shell redirection to pipe flashrom's text output into a logfile, I'd suggest using the built-in -o command-line switch: flashrom -p internal -r factoryBIOS.bin -o full_log_HP-Compaq_8200-Elite-SFF.txt Note that the -V option is now redundant, since -o will already make verbose enough logs. > Could you please explain-me why reading with the internal-programmer > doesn't work for me? Thanks in advance I have a suspicion which I should be able to confirm with a complete log: reading fails because the ME region is locked. > Best regards > Dario > > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Planning the next coreboot release
Hi again, About a week ago, I announced our plans to do a new coreboot release, which is scheduled to take place next Wednesday, November 18. This means we're currently at the "~1 week prior to release" point of our release checklist (at https://doc.coreboot.org/releases/checklist.html). To this end, please test the devices you have with master, fix (or at least report) regressions you encounter, and propose additions to the release notes. Furthermore, I would earnestly appreciate that any risky changes be postponed until after the release is done, in order to minimize the impact of any possible breakage. Owing to the lack of developers and testers for Denverton-NS, it has been proposed as a candidate for removal in a future release: https://review.coreboot.org/47539 If anyone is still interested in keeping this platform supported in the future, please consider becoming a maintainer or providing the means to boot-test its code. Personally, I believe the root of the problem is testing: most coreboot developers don't have access to a Denverton-NS system to boot-test any changes, so it's impossible to ensure changes won't accidentally break something. Thanks, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Including a video BIOS
Hi Andy, Naresh, On Wed, Nov 11, 2020 at 5:10 PM Andy Pont wrote: > > Naresh wrote… > > Looking at kconfig, the mainboard should select MAINBOARD_HAS_LIBGFXINIT. > For example see "grep -rsn MAINBOARD_HAS_LIBGFXINIT src/" > > I haven't used this, so not sure what else might be needed. > > In order to get the build to progress I have needed to select > MAINBOARD_HAS_LIBGFXINIT and MAINBOARD_USE_LIBGFXINIT. The build now fails > during compilation with: This means you're going to use libgfxinit instead of a video BIOS. libgfxinit is a graphics modesetting library written in SPARK, a subset of Ada with formal verification properties. You can read more about it here: https://doc.coreboot.org/gfx/libgfxinit.html I've made it work on Whiskey Lake (the immediate predecessor of Comet Lake), but I needed to implement a few workarounds to prevent system lock-ups. My board is a Librem Mini, which does not have an integrated LCD (unlike laptops), so I don't know if the backlight part needs special handling. Here's the relevant changes in Gerrit: https://review.coreboot.org/q/topic:"librem_whl_lgi"; > GCCramstage/libgfxinit/common/dyncpu/hw-gfx-gma-config.o > hw-gfx-gma-config.ads:19:32: missing operand > Makefile:356: recipe for target > 'build/ramstage/libgfxinit/common/dyncpu/hw-gfx-gma-config.o’ failed > > This feels like a rabbit hold down which I don’t want to find myself! Sounds like the sedprocessor (libgfxinit is configured using some sed-fu to fill in config parameters as constants) replaces `<>` (the graphics generation, which is an enumerated type) with an empty string, which is why the compiler complains about a missing operand. > -Andy. > > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Deprecating spurious PCI bus master enabling (was Re: Planning the next coreboot release)
Hi Werner, Ron, Nico, list, While it would be great to not have to implement Bus Master workarounds in coreboot, I guess it's sometimes unavoidable because of external constraints. I would much prefer to have the actual problem fixed instead (code assuming Bus Master is enabled by default), but if that's not possible I can live with some mechanism to enable Bus Master in coreboot, *as long as all usages are justified*. IMHO, enabling Bus Master for no reason is bad practice, but keeping code to enable Bus Master because no one knows what removing it could break is even worse. On Tue, Nov 10, 2020 at 3:24 PM werner@siemens.com wrote: > > We could introduce a Kconfig switch per driver Not per-driver, please! I'd rather have per-reason switches (reason-options): Kconfig options whose help-text gives the reason why enabling Bus Master in coreboot for certain devices is needed. Even if these Kconfig options end up being scattered across the tree, it's easier to see the relationship between multiple instances of Bus Master being set. Plus, if the actual bug is eventually fixed, it's very easy to drop the corresponding reason-option without breaking any other reason-options. > and let the driver handle the bit. > Everything else could be removed. This would make it easier to track the > usages. > It would be nice if we could agree on a naming scheme so that all switches > are named similar which would make it easier to track the usage. > > But there are cases where there is no driver in coreboot for a given PCI > device which needs this bit. For now, we (Siemens) handle this cases on > mainboard level. > So either we need drivers for these devices (just simply setting the master > bit) or we can agree on some kind of exceptions. > I am open to everything. This won't be a problem if using per-reason Kconfig options. I would still use these reason-options though, even when the option always gets selected (e.g. selected by the mainboard's Kconfig): this is to justify each instance of Bus Master being set with the corresponding reason-options. > Werner > > -Ursprüngliche Nachricht- > Von: ron minnich > Gesendet: Dienstag, 10. November 2020 16:15 > An: Nico Huber > Cc: coreboot > Betreff: [coreboot] Re: Deprecating spurious PCI bus master enabling (was Re: > Planning the next coreboot release) > > nice idea! > > On Tue, Nov 10, 2020 at 7:13 AM Nico Huber wrote: > > > > On 10.11.20 16:06, Nico Huber wrote: > > > If anybody knows or discovers more cases where it needs to be > > > enabled in advance by coreboot, please mention it here. > > > > We just discussed on IRC cases where unfixable OS drivers might need it. > > For such cases, it would probably be best to add individual Kconfig > > switches for each case. This would make it easier to get rid of the > > big switch. > > > > Nico > > ___ > > coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an > > email to coreboot-le...@coreboot.org > ___ > coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email > to coreboot-le...@coreboot.org > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Is HP ProLiant DL360e Gen8 supported in Coreboot?
Hi, On Mon, Nov 9, 2020 at 6:42 PM wrote: > > Hello! I'm trying to find if my hardware supports Coreboot. I found 1 table > which is retired, second that is probably not retired and then current > documentation that doesn't seem to say as much. So, sorry if I missed it. > Will Coreboot work with HP ProLiant DL360e Gen8? Flashrom worked ok but not > great. Northbridge is Intel Sandy Bridge-E 07, Southbridge Intel X79 05. Short answer: Nope. Long answer: Porting this board would be extremely time-consuming (several years for an experienced developer working exclusively on it), because there's no support at all for the chipset. While there's support for mundane Sandy (and Ivy) Bridge consumer (desktop, mobile, uniprocessor server) hardware, the SA and PCH (System Agent and Platform Controller Hub, i.e. integrated northbridge and southbridge respectively) on server platforms are radically different beasts. Memory initialization is by far the most complex thing that would need to be implemented, and the registers aren't publicly documented and differ across generations, as well as between consumer and server platforms. > References: > https://www.coreboot.org/Supported_Chipsets_and_Devices > https://coreboot.org/status/board-status.html > https://support.hpe.com/hpesc/public/docDisplay?docId=c03361169&docLocale=en_US > https://browser.geekbench.com/geekbench3/1879558 > https://doc.coreboot.org/mainboard/index.html > https://doc.coreboot.org/northbridge/intel/sandybridge/index.html > > Flashrom log: > > flashrom v1.2 on Linux 5.4.0-42-generic (x86_64) > flashrom is free software, get the source code at https://flashrom.org > > Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns). > Found chipset "Intel C60x/X79". > Enabling flash write... FREG0: Flash Descriptor region > (0x-0x) is read-only. > FREG2: Management Engine region (0x0001-0x001f) is locked. > Not all flash regions are freely accessible by flashrom. This is most likely > due to an active ME. Please see https://flashrom.org/ME for details. > At least some flash regions are read protected. You have to use a flash > layout and include only accessible regions. For write operations, you'll > additionally need the --noverify-all switch. See manpage for more details. > OK. > Found Macronix flash chip "MX25L1605" (2048 kB, SPI) mapped at physical > address 0xffe0. > Found Macronix flash chip "MX25L1605A/MX25L1606E/MX25L1608E" (2048 kB, SPI) > mapped at physical address 0xffe0. > Found Macronix flash chip "MX25L1605D/MX25L1608D/MX25L1673E" (2048 kB, SPI) > mapped at physical address 0xffe0. > Multiple flash chip definitions match the detected chip(s): "MX25L1605", > "MX25L1605A/MX25L1606E/MX25L1608E", "MX25L1605D/MX25L1608D/MX25L1673E" > Please specify which chip definition to use with the -c option. This is expected for this kind of platform, since the IFD (Intel Flash Descriptor) specifies the regions of the flash chip and their access permissions. > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org Regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Planning the next coreboot release
Hi everybody, It's high time we looked into cutting yet another release. As usual, other than our 6-monthly cadence of incrementing a number on our tree and pushing out tarballs and press releases, no particular rationale prompts this event. Unlike previous occasions, this is my first time executing the coreboot release process along with Patrick Georgi. We plan to do the release on Wednesday, November 18. This announcement is in conformity with the process described on https://doc.coreboot.org/releases/checklist.html, as we're currently at the "~2 weeks prior to release" point. For this reason, I would earnestly appreciate it if you (everyone subscribed to this list, but given that you're reading this mail, yes, you too!) could help out with the following: 1. Testing: the more, the better. Please test as much of your coreboot-supported hardware as you can, report and/or address any issues, and upload fresh reports to the board-status repo. Despite having no quality requirement to give a new number to our tree (create a new release), it is important to ensure what we have in the tree is still functional, since it lowers the work needed to pin-point new issues (bisections since 4.12 should still take 12 steps or less at this time, even though there's about 40% more commits than between the last two releases). 2. Please try to postpone riskier changes and similar until the release is done (unless they're ready to land in the next few days), in order to keep the tree stable while people test whether their hardware still works as expected. If a major feature doesn't make it into this release, don't worry; it can always be part of the following release. Let's make sure this coreboot release keeps booting. 3. Please take a look at the preliminary release notes in Documentation/releases/coreboot-4.13-relnotes.md and add whatever happened since 4.12 that is worth mentioning. If unsure, simply push a change to Gerrit and have your fellow developers discuss it. Thanks, Angel Pons ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: [RFC] Replace strapping entries in coreboot table
Hi list, On Wed, Oct 28, 2020 at 10:17 PM Julius Werner wrote: > Okay, fair enough. Angel commented on the CL that this email thread > needs to get resolved before the patch can land, so I wanted to try to > help resolve it. No, I never said that. I merely pointed out that discussion was taking place outside of Gerrit. Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: How to debug open-source AGESA with serial console?
Hi list, On Thu, Oct 15, 2020 at 5:48 PM Clay Daniels wrote: > > Paul, you are probably way ahead of this, but I found something pre-AGESA > from 2003 that says: > > "Unlike minicomputer systems, the IBM PC was not designed to use a serial > console. This has two consequences. > > Firstly, Power On Self-Test messages and Basic Input/Output System (BIOS) > messages are sent to the screen and received from the keyboard. This makes it > difficult to use the serial port to reconfigure the BIOS and impossible to > see Power On Self-Test errors. > > An increasing number of manufacturers of rackable server equipment are > altering their BIOSs to optionally use the RS-232 port for BIOS configuration > and test messages. If you are buying a machine specifically for use with > serial console you should seek this feature. If you have an existing machine > that definitely requires access to the BIOS from the serial port then there > are hardware solutions such as PC Weasel 2000. > > Secondly, the RS-232 port on the IBM PC is designed for connecting to a > modem. Thus a null modem cable is needed when connecting the PC's serial port > to a terminal." > > https://tldp.org/HOWTO/Remote-Serial-Console-HOWTO/intro-why.html How does any of this apply to coreboot? > Clay > > > On Thu, Oct 15, 2020 at 3:54 AM Paul Menzel wrote: >> >> Dear coreboot folks, >> >> >> To get PCI bridge 0:15.2 enabled for the network device on the Asus >> F2A85-M PRO, I want to debug the PCIe General Purpose Ports lane >> configuration of the FCH. >> >> I’d like to print some variables in >> >> src/vendorcode/amd/agesa/f15tn/Proc/Fch/Pcie/GppPortInit.c >> >> over the serial console. It looks like >> >> #include >> >> and `printk(BIOS_DEBUG, …)` compiles, but the messages are not sent over >> serial console. Is that expected? >> >> Do I need to use AGESA’s Integrated Debug Services (IDS) [1], and enable >> the console in `src/mainboard/asus/f2a85-m/OptionsIds.h`? I don't know if AGESA is compiled into a different stage, which would be called `libagesa`. I've just seen some mentions of this in the coreboot code. I suspect logging there might need to be handled differently (similar to how we handle logging in SMM, which is disabled by default). I'd be surprised if any of the IDS stuff still builds fine. No one bothered to migrate the IDS controls in OptionsIds.h to Kconfig. Should you want to do so, please add various config files in configs/ to ensure the IDS code gets build-tested. >> Kind regards, >> >> Paul >> >> >> [1]: >> https://www.coreboot.org/images/3/36/AGESA_Interface_Spec_for_Arch_2008_v3.00.pdf >> ___ >> coreboot mailing list -- coreboot@coreboot.org >> To unsubscribe send an email to coreboot-le...@coreboot.org > > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: FW: P8H61-m LX2 coreboot?
Hi Matej, On Sun, Oct 4, 2020 at 7:37 AM Matej Voľanský wrote: > > Hello, > I have P8H61-m LX2 in my desktop right now. I want to switch from Win10 to > Arch Linux and thought about also switching to coreboot. Unfortunately, I > can’t find this MBO in your board status. There’s P8H61-m LX, LX3 R2.0, PRO, > but LX2 not even mentioned. I’m not sure if I’m contacting the right person, > but I need help. I’ve never done coreboot before ( though I’m not a newbie in > electronics so I’m confident ) and I don’t know if it’s worth trying > corebooting this MBO if it’s not in your list. I do have needed tools for > this. The mailing list is a perfect place to ask for help. Welcome! If you haven't installed Arch already, I suggest that you use GRUB as a bootloader, and set up both legacy BIOS boot and UEFI boot. This is so that you can boot using either SeaBIOS, GRUB or TianoCore as payloads. The P8H61-M LX2 is similar to both the P8H61-M LX and the P8H61-M LX3 R2.0 (I ported this one). The SPI flash chip is socketed, so you can carefully remove it from its socket and plug it into an external programmer (ideally, one that is supported by flashrom). The first thing you can try to do is to make a backup of its contents. Make sure to verify the read contents (flashrom has the -v option to do so). This will allow you to go back to a known-working state later on. Then, you would want to check out `util/autoport`. While it does not do everything, it at least provides a good starting point to add a new Sandy/Ivy Bridge mainboard. Check out its README.md as it contains useful information. Then, use it, and it will hopefully create the `src/mainboard/asus/p8h61-m_lx2` folder with some files. The most significant thing that will be missing from autoport-generated files is the Super I/O configuration. The serial port is connected to the Super I/O, and it can be used to get log messages from coreboot, so it would be great to make it work. You can use `util/superiotool` to dump the Super I/O settings programmed by vendor firmware, and add them to the coreboot port. You can use the existing P8H61-M LX and P8H61-M LX3 R2.0 board ports as an example. Once this is done, selecting the board vendor/model should result in a bootable coreboot image. However, a scary warning appears at the end of the build process that tells you not to flash the resulting image as-is. Although the region sizes may differ, this is what the firmware on Sandy/Ivy Bridge systems looks like: https://doc.coreboot.org/_images/flashlayout_Sandy_Bridge.svg coreboot goes into the BIOS region. By default, the build system generates an image that only contains coreboot, so the other regions are empty. Flashing everything would erase the other regions, which renders the hardware unable to boot (same symptoms as trying to boot without a flash chip). So, the warning is just reminding you to make sure to only flash the BIOS region. With flashrom, you can use the command that appears here: https://doc.coreboot.org/flash_tutorial/index.html#using-an-ifd-to-determine-the-layout If this works, or if you get stuck, please push your code to review.coreboot.org so that anyone can take a look. For board ports, we prefer to have a single commit adding the board in a working state. Changes in Gerrit are identified by its Change-Id line in the commit message, so you can amend your commits and push them again to upload a new revision of the same change. You can follow this guide to get started: https://doc.coreboot.org/tutorial/part2.html Here's the changes that added the existing boards, as an example: P8H61-M LX: https://review.coreboot.org/27798 P8H61-M LX3 R2.0: https://review.coreboot.org/39099 I didn't add documentation when I ported my board, but it is a good idea to do so. Alternatively, one could adapt the existing P8H61-M LX page so that it covers all three LX boards. Documentation can be added in a different commit, so it's not critical. > Sincerely Matej Volansky. > > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Question about PR
Hi, On Thu, Sep 17, 2020 at 2:50 PM Michal Zygowski wrote: > > Hi, > > Please check out also this guide: > https://www.coreboot.org/Git#Pushing_changes > > you need to tell git where to push: `HEAD:refs/for/master`. It seems the > guide on https://doc.coreboot.org/tutorial/part2.html is missing one > crucial step: > > `git config remote.origin.push HEAD:refs/for/master` This shouldn't be needed after running `make gitconfig`. > You don't need any particular rights to push. You have two options to > authorize: > > 1. SSH key (add SSH key to gerrit account and configure git remote for > SSH or simply clone with SSH like here > https://www.coreboot.org/Git#Accessing_the_repository) > 2. HTTP password. If you cloned the repo by HTTP(S) then you should be > asked for password. You can generate it on your gerrit account. > > Even if you skip the git config commands, `git push origin > HEAD:refs/for/master` should push your commit(s) you have added on top > of your local master branch to gerrit. They will be public. if you > append %private at the end of the command, it will be private. If you > append %wip it will be marked as work in progress. > > Of course we can't see it if it is private. You would have to add > reviewers or people on CC. You can also `unmark private` on the change. This way, everyone can take a look. Note that private changes can't be submitted normally. https://gerritcodereview-test.gsrc.io/marking-a-change-as-private.html > Who to add as reviewer? It depends what the patch does. You may suggest > reviewers by looking at MAINTAINERS file in the repo which contains the > people who are more familiar with given part of coreboot source and can > provide good reviews. > > How to add reviewer? If your press reply button above the commit message > on gerrit (when displaying your patch) a window will pop up. You may > skip writing any message. Just click in the row with reviewers (where > Add reviewer is written) and start typing. Auto completion should give > you some results. Type by name, nick or email of the reviewer. > > Best regards, > > -- > Michał Żygowski > Firmware Engineer > https://3mdeb.com | @3mdeb_com > > On 17.09.2020 16:36, bzt wrote: > > Hi, > > > > I'd like to commit a patch to coreboot. I've followed the tutorials on > > https://doc.coreboot.org/tutorial/part2.html > > > > I've set up gerrit account, etc. created a local repo, configured git > > for submit, set up change-id hook, etc. etc. etc. However at step 4a, > > "git push", I got an error message from the server about missing > > "Push" rights and to contact the administrator. How can I do that? > > > > I was able to push the commit as a private patch: > > https://review.coreboot.org/c/coreboot/+/45480 > > > > I'm not sure if you can see this url, or is this for my user only. > > I guess now I should add a reviewer, but how and who? Or how can I get > > a "Push" right? I can't see it. You can `unmark private` on the change so that everyone can see it. > > Thanks for your help, > > bzt > > ___ > > coreboot mailing list -- coreboot@coreboot.org > > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Proper way to obtain mrc.bin for thinkpad t440p?
Hi all, That coreboot fork does not automate the process of obtaining mrc.bin at all. Instead, it contains a disassembled/decompiled version of MRC and uses that instead. I would not recommend using that fork because it's outdated. On coreboot master, there's https://review.coreboot.org/43559 which should fix hangs with libgfxinit when a VGA display is plugged in, and https://review.coreboot.org/44155 which might help with https://ticket.coreboot.org/issues/259 or similar issues. I don't have a T440p, though. On Fri, Aug 21, 2020 at 5:54 AM Harshit Sharma wrote: > > Hi yk, > > As Matt said It is not just meant for chromebooks but haswell in general. > Just follow the instructions given on the coreboot page to obtain mrc.bin and > place it in the root coreboot directory as it says. > > That tutorial seems fishy to me as well. I'd suggest just run 'make > menuconfig' and select t440p from mainboard menu. You don't need to change > any values. The default values should work. > > Finally, build the coreboot image, split into 8MB + 4MB chunks and just flash > the 4MB chip. > > > Best, > Harshit > > > On Thu, Aug 20, 2020, 5:13 PM yk via coreboot wrote: >> >> To anyone who has corebooted a t440p: >> >> I followed the instructions here >> https://doc.coreboot.org/northbridge/intel/haswell/mrc.bin.html to >> obtain an mrc.bin for the t440p, but it seems like these instructions >> are generalized and are meant for chromebooks, and not thinkpads. I >> gave it a try anyways and my t440p beeps and flashes LED's (as >> configured in .config, to do so on fatal error). Months of searching, >> and I can't find any documentation or archived emails from this >> mailing list for obtaining an mrc.bin specifically for the t440p. >> >> There exists this tutorial https://0xcb.dev/lenovo-t440p-coreboot/ but >> it tells me to use a forked version of coreboot which seems really >> fishy. I browsed the commits from that fork and I couldn't find anything >> that "automates obtaining mrc.bin" as it promises. >> >> What is the proper way to obtain the mrc.bin and configure for t440p? >> >> CONFIG_DCACHE_RAM_MRC_VAR_SIZE=0x3 <-- also what should this value >> be if the mrc.bin is 186K? >> ___ >> coreboot mailing list -- coreboot@coreboot.org >> To unsubscribe send an email to coreboot-le...@coreboot.org > > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Naming convention of register update functions
Dear mailing list, I've been asked in https://review.coreboot.org/42134 to please start a discussion on the mailing list about the naming convention of the functions I've added in said patch. I decided to use `unset_and_set` because that's what libgfxinit uses. In coreboot, we already have `clrsetbits` to operate on memory-mapped addresses. However, `pci_update_config` functions have different semantics, as they take an and-mask instead of an unset-mask. This requires one to use explicit casts to silence spurious overflow warnings if using bitwise negations on shorter-than-int types and the most significant bit is set. Since the added functions operate on bytes, the casts are necessary too often, which clutters the code and suppresses valid overflow warnings. Using an unset-mask solves all these problems, but having `update` in the names of two function families with different semantics would be too cruel. And `clrsetbits` doesn't look too good as a middle `word` in a function name, which is why I went with `unset_and_set` instead. Any thoughts? Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: kabylake RVP7 coreboot pcie/sata issue
Hello John, On Mon, Aug 17, 2020 at 11:31 PM john brown wrote: > > Our new board has intel skylake I3-6100U CPU, BIOS use coreboot based on > kabylake RVP7 > it can boot linux OS successfully. but there are two issues: Which mainboard do you have? *Is* your board an Intel Kaby Lake RVP7 reference board? If not, then it's expected that things don't work properly with a RVP7 image. > 1. > > intel Ethernet PHY I211 connected on I3-U6100 PCIE lane 1, I211 is not > shown in lspci. > > and serial port log: > > PCI: 00:1c.0 scanning... > do_pci_scan_bridge for PCI: 00:1c.0 > PCI: pci_scan_bus for bus 01 > POST: 0x24 > POST: 0x25 > POST: 0x55 > scan_bus: scanning of bus PCI: 00:1c.0 took 12591 usecs > > -- > > In our previous version board, I211 is on PCIE lane 5, which is shown in > lspci and works fine. and serial port log: Sounds like you have custom mainboards. Instead of using a RVP image on them, I would recommend adding support for your boards to coreboot. You can even use the variants mechanism to account for differences between revisions. You can use https://doc.coreboot.org/tutorial/part2.html as a guide to submit patches upstream for review. Feel free to add me as a reviewer there. > PCI: 00:1c.0 scanning... > do_pci_scan_bridge for PCI: 00:1c.0 > PCI: pci_scan_bus for bus 01 > POST: 0x24 > PCI: 01:00.0 [8086/1539] enabled > POST: 0x25 > POST: 0x55 > Capability: type 0x01 @ 0x40 > Capability: type 0x05 @ 0x50 > Capability: type 0x11 @ 0x70 > Capability: type 0x10 @ 0xa0 > Capability: type 0x10 @ 0x40 > Enabling Common Clock Configuration > PCIE CLK PM is not supported by endpoint > ASPM: Enabled L1 > Capability: type 0x01 @ 0x40 > Capability: type 0x05 @ 0x50 > Capability: type 0x11 @ 0x70 > Capability: type 0x10 @ 0xa0 > Failed to enable LTR for dev = PCI: 01:00.0 > scan_bus: scanning of bus PCI: 00:1c.0 took 56231 usecs > > 2. > > A m.2 sata on pcie lane 11(sata 1B) doesn't work(not shown on lsblk). On the > previous version board, sata is on PCIE lane 8 (1A) and works fine. This is probably due to misconfigured settings, and related to the NIC problems. From what you've explained, looks like the new board revision uses different HSIO lanes, so the configuration needs to be adjusted accordingly. As explained before, adding support for your boards is probably the best option. > The following 3 files are changed for this new board from the previous > version board . > > 1.IFWI configuration file settings, > > 2. devicetree.cb > > 3. gpio.h (SATAXPCIE1 detect) It would be nice to see which changes are needed. This would be very easy if the code were public, e.g.: upstream or on review. > Thanks a lot for your help on any of these issue. > > John > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org Best regards, Angel Pons ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: will my machine support coreboot ?
Hello,
On Thu, Jul 30, 2020 at 1:53 PM Jonathan Neuschäfer
wrote:
>
> On Tue, Jul 28, 2020 at 07:54:33PM +0530, Nihar Khuntia wrote:
> > Hi Developers,
> >
> > my laptop has hardwares details as attached in this email. will it support
> > coreboot ?
>
> At present time, no. As you can see in the coreboot source code[1] or
> menuconfig, this laptop (Dell Vostro 1014) is currently not supported in
> coreboot.
>
> While it is possible to change that, it involes weeks or months of
> programming and testing work ("porting").
According to the internet, this machine has a Mobile 4 Series (e.g.
GM45) northbridge with DDR2, an ICH9M southbridge, and an ITE IT8502E
embedded controller. There's some coreboot support for this
northbridge and southbridge, but support for DDR2 memory is missing.
There are some WIP patches on review.coreboot.org which are good
enough to boot, but other things like S3 suspend and resume don't work
well yet.
The embedded controller is another problem: it runs mainboard-specific
firmware. There's a datasheet for it on the internet, which should
help understand some things. However, making all laptop features work
correctly (e.g. keyboard, touchpad, special function keys, lid
open/close detection, fan control, backlight control, power
management...) will require some reverse engineering work.
Another thing I saw on schematics (yes, there's schematics on the
internet for this mainboard): on this mainboard, the flash chip is
connected to the EC, so it contains both the BIOS and the EC firmware.
This complicates coreboot porting (e.g. one usually can't use a chip
clip to reflash externally, because the EC gets powered through the
programmer and turns on). However, this board has some testpads, so it
is possible to solder a second flash chip directly to the ICH9M
southbridge. There's a pin on the ICH9M to choose the Boot BIOS
location, which can then be wired to a switch (e.g. the Wi-Fi switch)
to select between the two flash chips. Yes, this involves soldering
very small things onto even smaller testpads, but it would only need
to be done once. And since the original vendor firmware would be
untouched, the laptop would then be pretty much unbrickable.
I've added a second flash chip to a Toshiba A300-1ME, and I've used it
to test the GM45 DDR2 initialization code. I call it a "portable
coreboot development system": if coreboot doesn't boot, I can always
power off, switch to vendor BIOS, boot to Linux and reflash with
`flashrom -p internal`. No tools, no disassembly needed. :)
In short: there's currently no coreboot support for it. However, if
you're really adventurous, adding a second flash chip is a very
reasonable option: soldering small components requires some skills,
but once it's done, switching between the vendor BIOS and coreboot is
just a matter of flipping a switch. Not having to worry about
recovering from a non-booting coreboot.rom greatly simplifies
development.
> Best regards,
> Jonathan Neuschäfer
>
> [1]: https://review.coreboot.org/cgit/coreboot.git/tree/src/mainboard/dell
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
Best regards,
Angel
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: How to choose my ‘‘mainboard vendor’’ for Sony laptops?
Hi there, Currently, no Sony laptops are supported. So, there isn't any option to build coreboot for your laptop. If you *really* want to have coreboot on it, you could try porting (adding coreboot support for) this laptop. However, you *need* to be able to flash externally (something to flash a known-good BIOS when the laptop doesn't boot). I couldn't find schematics for this laptop, so I don't know if there are problems that would make in-circuit external flashing (using a clip) dangerous. On Mon, Jul 20, 2020 at 4:39 AM wrote: > > Laptop model: Sony VPCCB17FG > Cores: Intel i7-2620M > Coreboot release to be flashed: 4.12 > RAM’s: 7.45GiB That must be 8 GiB, with some memory being unavailable because it was reserved for something. > Graphics: AMD Radeon > Old BIOS: By AMI, versioned R0242v2 (no longer receiving Sony’s BIOS upgrades > since 2012) > > Mainboard vendor *snip* > choice[1-46]: > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Call for testing: Weird behavior of the EC on Thinkpad X230s
Hi Persmule, On Thu, Jul 16, 2020 at 5:17 PM Persmule wrote: > > Hi Angel Pons, > > It seems that we may copy ec/lenovo/h8 to ec/lenovo/mec16xx ( or separate > directory for different chips ) to start dedicated support to them, since > though they are different, their behavior are so similar that code for > ec/lenovo/h8 can work on them, though buggy. Nope. While it happens rather often, copying code to support a new chip is a terrible approach. Things get duplicated and get patched up independently, and then there are five copies of some file which only differ in cosmetics. If one wants to properly support the different ECs Lenovo uses on the Thinkpads, it's better to reverse engineer each platform again and add fresh code that is tested and known working. One also needs to remember that ECs are made of both hardware and software, and I doubt that any distinction is made in the case of ec/lenovo/h8. In case the software interface is the exact same for Lenovo laptops with different ECs, it should not go into either EC folder. > Best regards, > Persmule > > ‐‐‐ Original Message ‐‐‐ > On Thursday, July 16, 2020 5:10 PM, Angel Pons wrote: > > > Hi Persmule, > > > > On Thu, Jul 16, 2020 at 5:02 PM Persmule persm...@hardenedlinux.org wrote: > > > > > Hi Angel Pons, > > > ‐‐‐ Original Message ‐‐‐ > > > On Thursday, July 16, 2020 2:47 PM, Angel Pons th3fan...@gmail.com wrote: > > > > > > > I suspect that reusing the H8 EC code for the xx30 series Thinkpads is > > > > a source of bugs. There isn't any H8 EC on those mainboards anymore, > > > > the EC was replaced with a completely different SMSC MEC1619. The > > > > T440p port seems to have a few bugs which might be due to the > > > > different EC. > > > > > > Is the EC on the xx20 series Thinkpads (e.g. X220) an H8 EC or not? > > > > AFAIK, yes. The specific H8S model used varies, but they are similar. > > I re-checked the T440p and it uses a different SMSC MEC1633L EC. That > > would explain why only the T440p had some weird issues regarding EC > > stuff. > > > > Best regards, > > Angel Regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Call for testing: Weird behavior of the EC on Thinkpad X230s
Hi Persmule, On Thu, Jul 16, 2020 at 5:02 PM Persmule wrote: > > Hi Angel Pons, > > ‐‐‐ Original Message ‐‐‐ > On Thursday, July 16, 2020 2:47 PM, Angel Pons wrote: > > I suspect that reusing the H8 EC code for the xx30 series Thinkpads is > > a source of bugs. There isn't any H8 EC on those mainboards anymore, > > the EC was replaced with a completely different SMSC MEC1619. The > > T440p port seems to have a few bugs which might be due to the > > different EC. > > Is the EC on the xx20 series Thinkpads (e.g. X220) an H8 EC or not? AFAIK, yes. The specific H8S model used varies, but they are similar. I re-checked the T440p and it uses a different SMSC MEC1633L EC. That would explain why only the T440p had some weird issues regarding EC stuff. Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Call for testing: Weird behavior of the EC on Thinkpad X230s
Hi Persmule, I don't own any Thinkpads so I can't test anything. Still, here's my two cents about the issue at hand. On Thu, Jul 16, 2020 at 1:43 PM Persmule wrote: > > Hi all, > Days ago the coreboot port for Thinkpad X230s ( > https://review.coreboot.org/c/coreboot/+/41390 ) for one of my friends got > merged. Most stuffs on this laptop proves to work fine, but the interaction > between its EC and cellular modem installed in its internal M.2 socket is > detected to be a bit weird, and because of this the cellular modem installed > internally becomes hardly usable: I know there's some workaround for broken BDC detection. Maybe something similar is needed for the X230s. > If the laptop is connected to AC power, the cellular modem is disabled and > cannot be enabled with software. (e.g. Modem manager ) as if there were a > hardware switch set to flight mode; if the AC power is absent, whether the > cellular modem is usable depends on the operating system. > > The detailed testing result table collected by my friend is attached, in html > format. > > The direct cause of this phenomenon may be that the EC erroneously pull down > the GPIO pin for rfkill (Pin 8 of the M.2 socket with key B) when the AC > power gets present, but I cannot confirm whether the main board of this X230s > is faulty, or the EC firmware is buggy, or the EC of X230s should be treated > differently as the EC of X230, which I did not implement in my work. I suspect that reusing the H8 EC code for the xx30 series Thinkpads is a source of bugs. There isn't any H8 EC on those mainboards anymore, the EC was replaced with a completely different SMSC MEC1619. The T440p port seems to have a few bugs which might be due to the different EC. > Currently, this problem is walked around by blocking the Pin with a small > piece of insulating tape. > > Since I have experienced only one X230s, I cannot tell which one is the real > case. Could ye help me to confirm and/or improve this if ye have a chance to > access your own Thinkpad X230s? > > Regards, > Persmule > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org Best regards, Angel Pons ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: request simple information
Hi Marco, On Wed, Jul 15, 2020 at 6:25 PM Marco Franchi Moretti wrote: > > Thanks all coreboot core team for support and innovation, privacy and > free technology. I have a technician question. I have Onda OBook 11 > Plus, Intel Cherry Trail Z8300 64bit Quad Core and Intel Graphics. I > can ask at core team Coreboot: please suggest how to select in > menuconfig for try to install coreboot inside this tablet ? This mainboard isn't supported. That means there isn't any entry in menuconfig to build coreboot for this board. In such cases, one would need to port the board to coreboot, which would be rather complicated for Cherry Trail: there aren't any other Cherry Trail boards in the tree, and I don't know if the Braswell FSP supports Cherry Trail. > I hope someone respond, thanks for all. > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Extended IvyBridge CPU configuration
Hi Lars, list, On Wed, Jul 15, 2020 at 5:41 PM Lars Hochstetter wrote: > > Update: I tried the https://review.coreboot.org/c/coreboot/+/42547/ on > my T430 (i7-3840QM, Debian Buster 4.19.0-9-amd64) using coreboot v4.12 + > SeaBIOS as base. > > I used s-tui to track the CPU frequency. > > Without the patch on coreboot v4.12 the CPU reached its "usual" 3.3 - > 3.4 GHz (4C/8T) using the stress function of s-tui. > > With the patch the CPU reached at most 3.2GHz (intel_pstate) / 2.8GHz > (acpi-cpufreq). Thanks for testing! I'm the one who made that change, and I currently only have two CPUs to test it with. I generally check the CPU frequency with: `cat /proc/cpuinfo | grep MHz` > Maybe there is an issue with mobile CPUs? I'd say the issue is because of how I determine the overclocking headroom that the CPU is capable of. On my CPUs, it happens that the number of OC bins is the same as the number of steps between the base frequency ratio and the maximum turbo ratio. I imagine this isn't the case for other CPUs (which I do not currently have any of nearby) and would explain why the gains aren't as high as expected. It would be nice if you could provide a few MSR values from that CPU. You can use `rdmsr` from msr-tools: https://github.com/intel/msr-tools * 0xce (MSR_PLATFORM_INFO) * 0x194 (MSR_FLEX_RATIO) * 0x1ad (MSR_TURBO_RATIO_LIMIT) > On 24.06.20 20:00, Lars Hochstetter wrote: > > Hi, thanks for the pointer! > > > > I only fear that running my CPU at the maximum possible Turbo Ratio > > will overheat it. > > > > I can give it a try but I'm actually looking for an option to limit > > the maximum Turbo Ratio the CPU is allowed to reach (hence the > > disabling of TurboBoost altogether). In its current state, my patch seems to achieve that :P > > On 21/06/2020 00:52, Evgeny Zinoviev via coreboot wrote: > >> Hi again. There's another patch that fits to the topic that you will > >> probably want to try out: > >> https://review.coreboot.org/c/coreboot/+/42547/ > >> > >> On 12/15/19 3:57 PM, Lars Hochstetter wrote: > >>> Hi everyone, > >>> > >>> I'm looking for an option to configure my Intel IvyBridge CPU > >>> (enable / disable Hyperthreading, TurboBoost, set configurable TDP > >>> level etc.) using coreboot / nvramcui. My board is a Lenovo Thinkpad > >>> T430. So far, "only virtualization" is configurable and can not be > >>> enabled / disabled "in flight" but requires a rebuild of coreboot. > >>> > >>> Is anyone currently working on something similar? > >>> > >>> Is anything planned in that regard? > >>> > >>> Kind regards > >>> > >>> lhochstetter Thanks in advance, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Lenovo R500
Hi list, On Thu, Jun 18, 2020 at 9:18 AM Mike Banon wrote: > > It's a bit not obvious, but by searching at > ./coreboot/src/mainboard/lenovo$ find . -type f -print0 | xargs -0 > grep -n "R500" - I could see that R500 is a variant of Thinkpad > T400: i.e. " ./t400/Kconfig.name:10:config BOARD_LENOVO_R500 " . Since > this board_status table mentions each board type once, only T400 > appears there. Yes, this is a known problem of board status. > So your R500 is supported by coreboot, almost certainly blobless. > coreboot's installation is identical to libreboot: you simply flash a > compiled BIOS image. Tool to change a mac address: I haven't checked > if it could be found in ./coreboot/util/ - but almost certainly a > libreboot's tool should be compatible with coreboot, and maybe > libreboot project took this tool from somewhere else where there's an > even newer version This is untrue. By default, coreboot will not produce a full firmware image, so one must only flash the BIOS region. With a recent enough flashrom (v1.1 onwards), it's just a matter of adding the `--ifd -i bios` arguments when flashing coreboot. Moreover, the R500 does not use the Intel GbE controller inside the southbridge, but a Broadcom PCIe NIC. Its MAC address does not reside in the flash chip, so it is not easy to change. In any case, there's documentation in coreboot: https://doc.coreboot.org/mainboard/lenovo/montevina_series.html > On Tue, Jun 16, 2020 at 11:41 AM trabajo3 via coreboot > wrote: > > > > Hello!, I wantt to know if the Lenovo R500 has coreboot support without any > > blobs > > https://phoronix.com/scan.php?page=news_item&px=Coreboot-4.10-Released > > Here it says that is supported > > but > > https://coreboot.org/status/board-status.html > > doesnt appear > > and in the tree also no > > > > Another question is if there is any tool like in the libreboot proyect to > > change mac address and if there is any complete video tutorial to install > > libreboot, because in youtube there are full videos about libreboot but for > > coreboot i didnt find anyone with good explanation. > > Thanks for ur time! > > Best Regards > > > > > > Sent with ProtonMail Secure Email. > > > > ___ > > coreboot mailing list -- coreboot@coreboot.org > > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org Regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Hiccups bringing ACPI support to p3b-f
Hi all, On Sat, May 16, 2020 at 2:23 AM Keith Hui wrote: > > Hi Nico, > > I tried a few things. Looks like Linux kernel activated a couple PCI > quirks and claimed the ACPI and SMBus port ranges on top of what we > already reported. Seems to be the source of the conflict. > I have to omit the SMBus port range in pwrmgt_read_resources() in > southbridge/intel/i82371eb/smbus.c to make the conflict go away, but > that is not exactly correct. > > It is either this hack (which doesn't always work anyway), or rip the > SMBus driver out of DSDT, which S3 suspend for p3b-f is going to need, > or go expert mode and rebuild kernel with PCI_QUIRKS turned off. But I > also have a Realtek NIC with its own quirks, and turning PCI_QUIRKS > off kills that workaround as well. > > What is my proper next step? I would say: check why the quirk is getting enabled, and try to make it not enable for coreboot. Otherwise, we have to make coreboot be wrong just to make the kernel happy. > Thanks > Keith Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: About support for my netbook
Hi Piotr, On Mon, May 11, 2020 at 4:02 PM Piotr Król wrote: > > On 3/13/20 11:23 AM, Angel Pons wrote: > > Hi, > > > > On Thu, Mar 12, 2020 at 11:07 AM Michal Zygowski > > wrote: > >> > >> Hi, > >> > >> it may also be a Cedarview chipset. According to my knowledge there is > >> no support for Cedarview chipset in coreboot. However coreboot has > >> slightly older (1 year older) chipset support - Pineview. > > > > Pineview is very different, though. Memory initialization for Pineview > > resembles that of Eaglelake (src/northbridge/intel/x4x). Although it > > only has one memory channel, the registers in MCHBAR are very similar. > > > > On the other hand, Cedarview's internal architecture differs radically > > from Pineview, and it is actually more like Bay Trail. Both use the > > IOSF architecture, and memory is initialized by interacting with > > various "units" inside the chip. > > > > About the southbridge, I don't know if Cedarview can use NM10 (found > > on Pineview) or if it must use an EG20T PCH: > > https://ark.intel.com/content/www/us/en/ark/products/52501/intel-platform-controller-hub-eg20t.html > > Hi, > isn't Cedarview a processor code name and Cedar Trail platform code name? Yes, I was talking about the processor. Also, looks like I confused Cedarview with the older Tunnel Creek. Cedarview would only support the EG20T PCH, it seems. > This presentation mix both: > https://manualzz.com/doc/26041007/cedar-trail-platform-bios-session > > Interesting slide is 21, this lead me to pre-FSP time when BLDK was used > and I found this: > https://www.intel.pl/content/dam/www/public/us/en/documents/guides/cedar-trail-bldk-get-started-guide.pdf I recall that there were binaries for this somewhere, but can't find them anymore. > Probably only companies that have CNDA with Intel can still obtain > those, but who knows maybe it lays on some server somewhere. > > Best Regards, > -- > Piotr Król > Embedded Systems Consultant > GPG: B2EE71E967AA9E4C > https://3mdeb.com | @3mdeb_com > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: beginner's despair ;) coreboot update via internal fails
Hi, On Thu, May 7, 2020 at 7:13 PM Nico Huber wrote: > > Hi, > > On 07.05.20 18:11, Felix Held wrote: > > I'd say that flashrom only verifying the section it writes by default > > would be less surprising behavior than the current behavior. > > we'd need a distinction between reliable and unreliable programmers > first. Because not verifying everything with the latter can be fatal > (we don't even know if commands / addresses were correctly received > by the flash). And that's just the biggest problem. Restrictions of > internal programmers (e.g. Intel) can cause trouble too (what erase > command does the PCH send? oops, did the chip ignore the least signi- > ficant address bits?). Given these risks, I prefer to have safe defaults. It's better to error out early instead of silently corrupting something. Something I have noted is that flashrom is too verbose by default, and too much text means people are more likely to not read it in detail. If we can't be quieter, maybe we should indent warning and error messages so that they stick out (literally). > So, "the section it writes by default" is pretty much unknown. We > could still have a better default ofc. In this particular case (Intel > restricts reading) we could default to read everything that can be > read (usually, parts of the chip that can't be read also can't be > written, so that should be safe). But that's a bigger change (very > big given flashrom's development pace). That can be risky. If people just run flashrom and both reading and verifying complete successfully, they might think that they have a good backup image. However, that will not be the case. If running flashrom without any additional parameters does not work, people might wonder why and end up learning about the read restrictions imposed by the hardware. Maybe we can reach a compromise and make `--ifd` without specifying any regions do such a thing? Even then, we would still need to handle writes... > Nico > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Difference between GA-B75M-D3V and GA-B75M-D3H?
Hi,
On Wed, Mar 25, 2020 at 7:13 AM Paul Menzel wrote:
>
> Dear Matt,
>
> Am 25.03.20 um 03:36 schrieb Matt B:
>
> > Noticed someone running a GA-B75M-D3V with coreboot but that it
> > hadn't had a status report since 2017. I did notice that GA-B75M-D3H
> > is still around though with a status from may of 2019.
> >
> > Is the GA-B75M-D3H supported in the latest master?
Both of them are supported. However, board_status doesn't take
variants into account (it shows them as the "parent" board).
> Maybe the board owners know, but why do you assume it’s broken, if there
> is a success report from May 2019?
I guess the question was about the GA-B75M-D3V. In any case, both are
pretty similar.
> > What's the difference between these two?
Well, Gigabyte has pictures of their boards, so why not check it out
yourself? You can look up both models on your favorite search engine.
In any case, here's a picture of each:
GA-B75M-D3H: https://www.gigabyte.com/FileUpload/Product/2/4150/5670_big.jpg
GA-B75M-D3V: https://www.gigabyte.com/FileUpload/Product/2/4151/5674_big.jpg
So, the D3H has two extra DIMM slots, another PCI slot, a single PCIe
x4 slot (note the four pairs of capacitors between the PCIe slot and
the "All Japanese Capacitors" text), HDMI and a TPM connector.
> Before writing your post, did you check out the source for yourself?
> Please do so.
>
> Commit 1bffc4bd (mb/gigabyte/ga-b75m-d3{h,v}: Switch to variant setup)
> [1] sets them up as variants.
In layman's terms, if mainboards can be turned into variants, that any
of them is known to be working implies that the other variants are
working as well.
> Also run:
>
> $ diff -ur
> src/mainboard/gigabyte/ga-b75m-d3h/variants/{ga-b75m-d3v,ga-b75m-d3h}
>
> Then you see, that besides some license header difference, GPIO 17
> differs, the GA-B75M-D3H misses the HDA verb configuration, and it looks
> like it has one more HDMI connector.
Paul, comparing the source code isn't very useful, as it might be
wrong. It is best to draw conclusions from the mainboards themselves,
especially given that visual comparison (or even comparing the
manufacturer's specifications) is straightforward.
For example, have you checked out the change you have linked? More
specifically, the single line change of this file:
https://review.coreboot.org/c/coreboot/+/32708/16/src/mainboard/gigabyte/ga-b75m-d3h/romstage.c
> Kind regards,
>
> Paul
>
> [1]: https://review.coreboot.org/c/coreboot/+/32708
> _______
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
Best regards,
Angel Pons
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Need PCI(e) vs PNP resource allocation help
Hi, On Thu, Mar 19, 2020 at 9:52 AM Nico Huber wrote: > > Hi Keith, > > On 18.03.20 23:55, Keith Hui wrote: > > These are the devicetree.cb entries: > > > > device pnp 2e.b on # HWM, LED > > io 0x60 = 0x290 # HWM address > > drq 0xe4 = 0xf9 # GP50,52,55 > > drq 0xf0 = 0x3e # Enable all fan input debouncer > > end > > it looks like this 2e.b LDN has another i/o resource at 0x62. The > allocator often gets confused if a PNP device is enabled but the > resources are not assigned in the devicetree. Try setting it, maybe > even 0 works. It does, see CB:39299 as an example. > Nico > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: How to get a working snapshot of coreboot, submodules, seabios... everything for T440p?
Hi Dalao, On Sun, Mar 15, 2020 at 1:09 AM Dalao wrote: > > Thanks and it seems if I enable these configs it will not boot: > > CONFIG_CONSOLE_SPI_FLASH=y > CONFIG_SPI_CONSOLE=y > CONFIG_DEFAULT_CONSOLE_LOGLEVEL_8=y There should be no need to use such a high log level. It slows down boot a lot for no good reason. About the SPI console, I wonder why there are two different settings. Please try with only CONFIG_CONSOLE_SPI_FLASH. > At the very beginning I did not enable these settings, I believe it's due to > lack the microcode extracted from vendor's BIOS. > > Mar 15, 2020, 06:35 by th3fan...@gmail.com: > > Hi Dalao, > > On Sat, Mar 14, 2020 at 10:26 PM Dalao via coreboot > wrote: > > Finally make it boot now! I have asked for help on reddit > https://www.reddit.com/r/coreboot/comments/fibu68/after_several_days_work_still_cant_get_coreboot/ > and thanks to p4block he made a build and it works and he shared his config > https://hastebin.com/ojihusirok.ini > > I pulled the latest master and build using his config and it works! But I > still do't know what't the extract problem for my build... > > > Please use "make savedefconfig" with your settings. The full config is > too bloated and it's hard to see what differs from defaults (what the > defconfig contains). > > Best regards, > > Angel Pons > > PS: I've omitted the unnecessary quoted text from this reply. If > context is needed, it can be found in previous messages. Best regards, Angel Pons ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: How to get a working snapshot of coreboot, submodules, seabios... everything for T440p?
Hi Dalao, On Sat, Mar 14, 2020 at 10:26 PM Dalao via coreboot wrote: > > Finally make it boot now! I have asked for help on reddit > https://www.reddit.com/r/coreboot/comments/fibu68/after_several_days_work_still_cant_get_coreboot/ > and thanks to p4block he made a build and it works and he shared his config > https://hastebin.com/ojihusirok.ini > > I pulled the latest master and build using his config and it works! But I > still do't know what't the extract problem for my build... Please use "make savedefconfig" with your settings. The full config is too bloated and it's hard to see what differs from defaults (what the defconfig contains). Best regards, Angel Pons PS: I've omitted the unnecessary quoted text from this reply. If context is needed, it can be found in previous messages. ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: How to get a working snapshot of coreboot, submodules, seabios... everything for T440p?
Hi Dalao, On Fri, Mar 13, 2020 at 3:36 PM Dalao via coreboot wrote: > > I'm trying to build coreboot for T440p and still can't boot. I have tried the > official repo's latest master branch, it can't boot. The power button led is > on, keyboard led on for a second and then off, fan is on, but the screen is > not. I don't have a debug device. Ordered a FT232H but it's on the way. I > don't know what's the problem. So I looked around trying to find a working > one. I also tried the official repo's 4.11_branch, it's the same problem. I would suggest enabling SPI flash console, which writes logs to the SPI flash chip. Build, flash, and try booting. Then, power off and read the flash chip back. There should be a log somewhere inside the CBFS. > I also tried different configs use LIBGFXINIT or use VGAROM, and Tianocore or > Seabios payload. Still the same problem. The most recent config is: > https://pastebin.com/7vnji9i2 You are using me_cleaner. Try not using it, as it can break things. Ideally, just selecting USE_BLOBS (needed for microcode), selecting the mainboard and adding the mrc.bin should result in a bootable build. It will print a large warning, though: since the IFD/ME/GbE regions were left empty, flashing the result as-is will not work. On the t440p with two flash chips, you only need to flash the last 4 MiB of the 12 MiB coreboot.rom into the 4 MiB chip. libgfxinit should just work. The VBIOS is less likely to work fine on the first try, as extracting it is more error-prone. > The sha1sum of the blobs I obtained are: > $ sha1sum mrc.bin > d18de1e3d52c0815b82ea406ca07897c56c65696 mrc.bin Okay, that matches with the mrc.bin of peppy. The one I use (from wolf) has a different hash, no idea as to why. > $ sha1sum pci8086,0416.rom (obtained through linux kernel) > 4074e1fa2f788f91d3612b6fe861c9c3faf5560a pci8086,0416.rom > > I also tried archfan's repo for T440p but still can't build. It has some > issues with submodules https://github.com/archfan/coreboot/issues/12 > > I flashed back backuped original bios, and it can boot. I assume it's still a > software issue with my coreboot build. How to get a working snapshot of > coreboot, submodules, and seabios/tianocore at the time when the T440p can > work? That's good to hear. > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org Best regards, Angel Pons ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: About support for my netbook
Hi, On Thu, Mar 12, 2020 at 11:07 AM Michal Zygowski wrote: > > Hi, > > it may also be a Cedarview chipset. According to my knowledge there is > no support for Cedarview chipset in coreboot. However coreboot has > slightly older (1 year older) chipset support - Pineview. Pineview is very different, though. Memory initialization for Pineview resembles that of Eaglelake (src/northbridge/intel/x4x). Although it only has one memory channel, the registers in MCHBAR are very similar. On the other hand, Cedarview's internal architecture differs radically from Pineview, and it is actually more like Bay Trail. Both use the IOSF architecture, and memory is initialized by interacting with various "units" inside the chip. About the southbridge, I don't know if Cedarview can use NM10 (found on Pineview) or if it must use an EG20T PCH: https://ark.intel.com/content/www/us/en/ark/products/52501/intel-platform-controller-hub-eg20t.html > My experience is very little when it comes to older chipsets, but > judging by how sanydbridge and ivybridge works, pineview and cedarview > should have most thing in common. That said, i would try to go out from > pineview northbridge in coreboot. The next question is which southbirdge > to choose. There are two mainboards based on pineview. Most likely you > would have to select: > > select CPU_INTEL_SOCKET_FCBGA559 > select NORTHBRIDGE_INTEL_PINEVIEW > select SOUTHBRIDGE_INTEL_I82801GX > > in your mainboard Kconfig. The CPU socket also matches according to > Intel ARK about N2600 > > https://ark.intel.com/content/www/us/en/ark/products/58916/intel-atom-processor-n2600-1m-cache-1-6-ghz.html Note that, even though the LGA775 socket was used for many different CPU generations, not every LGA775 mainboard can take any LGA775 CPU. > The initialization for that particular silicon is native so no FSP > required. Since it may be hard to debug, I advise to get a USB debug > dongle and enable it in coreboot menuconfig. But before that, find out > which USB port on this netbook is connected to EHCI debug port. > Typically it is the first port on the root hub. You can find it out > using lspci and lsusb in Linux (by connecting a USB-UART dongle for > example to the investigated port). The dongles supported by coreboot > are: FTDI232H/FTDI2232H, or you can use BeagleBone board. There's also `util/find_usbdebug` in coreboot. > Regards, > > -- > Michał Żygowski > Firmware Engineer > https://3mdeb.com | @3mdeb_com > > On 12.03.2020 06:06, Benjamin Doron wrote: > > Hi, > > The Intel FSP (Firmware Support Package) is a required part of chipset > > initialisation. I can't find one for Cedar View, (github.com/IntelFsp/FSP) > > the family your CPU, an Atom N2600, is a part of. There is an old FSP around: QueensBayFspBinPkg. However, it will not work with current coreboot, as FSP 1.0 support had to be dropped. > > Somebody else should confirm (I don't know your platform well), but it > > seems impossible about this. Sorry. The first MinnowBoard uses a Cedarview chip. There is some ancient EFI firmware around: https://github.com/RafaelRMachado/MinnowBoard/tree/master There might be something better thank stinky binaries somewhere, but I don't know if it's still around after eight years... > > ___ > > coreboot mailing list -- coreboot@coreboot.org > > To unsubscribe send an email to coreboot-le...@coreboot.org > > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org Best regards, Angel Pons ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: About autoport in coreboot source tree
Hi, On Sat, Mar 7, 2020, 16:02 Alif Ilhan wrote: > Can I use autoport function to port coreboot to any unsupported netbook? > Please let me know > No. Autoport only generates files that can be used as a starting point. It is usually good enough to boot, but many things will not be working properly. To make a proper coreboot port for a laptop, one needs to add support for the embedded controller, which usually handles the battery charger, keyboard, touchpad and fan, among other things. Unfortunately, they are almost always undocumented: no datasheets are publicly available and it runs custom, mainboard-specific firmware. This is by far the hardest part of porting a laptop. Do you plan on porting any specific netbook? If the chipset is not supported, porting it may take years even for an experienced developer. ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org Regards, Angel Pons ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Still need assistance porting to ASUS P8Z77-M
AS latencies : 5 6 7 8 9 10 11 > tCKmin: 1.250 ns > tAAmin: 13.125 ns > tWRmin: 15.000 ns > tRCDmin : 13.125 ns > tRRDmin : 6.000 ns > tRPmin: 13.125 ns > tRASmin : 35.000 ns > tRCmin: 48.125 ns > tRFCmin : 160.000 ns > tWTRmin : 7.500 ns > tRTPmin : 7.500 ns > tFAWmin : 30.000 ns > channel[0] rankmap = 0x3 > SPD probe channel0, slot1 > Rowaddr bits : 15 > Column addr bits : 10 > Number of ranks : 2 > DIMM Capacity : 4096 MB > CAS latencies : 5 6 7 8 9 10 11 > tCKmin: 1.250 ns > tAAmin: 13.125 ns > tWRmin: 15.000 ns > tRCDmin : 13.125 ns > tRRDmin : 6.000 ns > tRPmin: 13.125 ns > tRASmin : 35.000 ns > tRCmin: 48.125 ns > tRFCmin : 160.000 ns > tWTRmin : 7.500 ns > tRTPmin : 7.500 ns > tFAWmin : 30.000 ns > channel[0] rankmap = 0xf > SPD probe channel1, slot0 > SPD probe channel1, slot1 > SPD probe channel1, slot0 > SPD probe channel1, slot1 > Starting Ivybridge RAM training (0). > No valid DIMMs found Both DIMMs are on the failing channel. This means that there are no DIMMs to initialize on the other channel, so raminit just halts. > --- END NATIVE RAMINIT LOG --- > > --- BEGIN MRC RAMINIT LOG --- (MRC raminit debug logs are wet noodles, not really useful) > --- END MRC RAMINIT LOG --- > > [1] This is a message I added in the stub. Best regards, Angel Pons ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Still need assistance porting to ASUS P8Z77-M
Hi Keith, On Fri, Feb 28, 2020 at 7:18 AM Keith Hui wrote: > > A week ago I wrote here about my problems trying to port coreboot to > my board. Unfortunately I am still no closer to booting. > > In the meantime I flashed my new chip with my OEM firmware backup. It > boots; then I flashed my patched IFD (for chip ID and flash unlock) > and it still boots. So it's not chip compatibility or corrupted > descriptor. > > The only sign of life I got is the bootblock banner left in the SPI > console. My PCI POST card is showing nothing, but knowing that it sits > on a PCIe-PCI bridge (ASM1063 that P8Z77M-PRO does not have) and not > knowing if it needs software init to work, I am now trying to pull > POST codes off the LPC bus over the TPM header, using an Arduino Due. > Do I have to add some early init to have port 80 accesses sent to LPC > bus for this to work? You have to tell coreboot where to route LPC post codes to. It defaults to "None", but you can choose PCI or LPC. I have never tried to print post codes with coreboot, though. I would try using the serial port though, as it is more practical for debugging than post codes. > Thanks for your help > Keith > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org Best regards, Angel Pons ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Need suggestions for SPI flash programmer, setting up to begin P8Z77-M port
Hi Keith, On Sun, Jan 26, 2020 at 9:41 PM Keith Hui wrote: > > Hi list, > > Seeing that my beloved i440BX platform will not support enough memory > to run Windows 10, and with 7 EOLed, its days are numbered even though > I enjoyed working on a blob-free platform. > > I am now setting myself up for porting coreboot to my P8Z77-M board, > where a close cousin is already in the tree. I would use autoport, and then add it as a variant of the P8Z77-M PRO. I have yet another cousin of these mainboards, the P8Z77-M LX2. > First, I need a 8MB SPI flash chip. I picked up a two W25Q64JVSSIM > from Digikey and some adapter as well since they don't carry any in > DIP form anymore. :( I mounted one and it seems to physically work. It > wasn't supported in flashrom yet, so I sent a patch there as well [1], > flagged as untested, because an issue I'll get to later, and my reason > for this email. > > Next, I need a SPI flash programmer. I'm trying to avoid making major > purchases. The most handy thing I have is a 5V Arduino Mega 2560 r3, > so I loaded frser-duino on it, and HoodLoader2 on its 16u2 for the > fast USB. I also picked up a level shifter module [2] because the > chips are 3.3V. When I wired up everything on a breadboard with the > board's original chip it reads fine and I was actually able to save a > backup of its contents. Of course I then wanted to build something > that I can just plug the chip in and go, as I will need to use it > quite often. > > I wired the level shifter and a DIP socket on a XBee shield (because > it has a 3.3V regulator and a proto area), but it's not detecting the > chip. I then reverted to the breadboard, this time using 3 resistor > dividers for level shifting because the level shifter's legs are now > soldered on the shield. > > I read the (still virgin) chip 3 times, and saw the read bytes > periodically goes to 0x00 instead of being all 0xff, as expected from > an unprogrammed chip. The connection is not working right. > > What else can I try? If I can't get this serprog-on-an-arduino setup > working, what is my next best setup I can use? I've always had issues when using an Arduino. I would only use it if nothing else is available. I have a pair of FT2232H, and they work pretty well as flashrom SPI programmers. They are much faster than an Arduino, which is nice when flashing often. Also, they work at 3.3V, so there's no need for level shifters. The FT2232H can also be used as an EHCI debug dongle for coreboot, which is useful when a serial port isn't available. > [1] https://review.coreboot.org/c/flashrom/+/38578 > [2] https://www.velleman.eu/products/view/?id=435578 > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org Best regards, Angel Pons ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Coreboot + ASUS P5K-E???
Hi Aaron, Mike, On Mon, Jan 13, 2020 at 9:34 AM Mike Banon wrote: > > On Mon, Jan 13, 2020 at 11:10 AM Aaron Garza wrote: > > > > Does Coreboot work on every motherboard or does it have to be certain > > motherboards/PCs? > > > > I have an old Intel Core 2 Quad and an ASUS P5K-E motherboard that I > > would love to set up with a coreboot BIOS replacement. Is it even possible? The Asus P5K-E uses a P35 northbridge, for which there is no support. Getting coreboot to run on it would require adding support for this northbridge (which is a rather complex task). About mainboard support: coreboot can run on anything as long as support for it is added. For example, porting (adding support for) LGA775 or LGA1155 desktop boards is not too hard, as long as the northbridge, southbridge and SuperIO are supported. Of course, flashing coreboot onto a supported board is easier, but you learn much more when doing a port. Laptops are harder to port, however. They have an EC (embedded controller), which is a microcontroller running some custom, undocumented firmware. coreboot does not replace the EC firmware, but has to interact with the EC to make things like keyboard, touchpad, fan control, lid switch, battery and power management function correctly. Adding support for the EC interface is the most time-consuming part of a laptop port. > As coreboot does the low level init of hardware, its' support is > board-specific of course. If you'd look at coreboot supported boards ( > i.e. those with a board status report here - > https://coreboot.org/status/board-status.html ), there are some ASUS > P5*** boards supported. Compare your P5K-E technical specification > against these boards, take the most similar one, build a coreboot for > it and (after a backup of previous chip contents just in case) try it > on your PC - maybe it will work. I've done ASUS P2B build for my > friend's ASUS P2B-B board, and it ran fine without any source code > modifications at all! Perhaps should add it as a board variant to > Kconfig, but I'm too lazy/busy solving the other problems. Please don't suggest "cross-flashing". That it worked does not mean that it is a wise thing to do. Different boards have different settings, and some of these are critical. The worst case are GPIOs: configurable pins that can be either inputs or outputs. If a GPIO that is wired as an input is configured as an output, this will result in a shortcircuit when the logic levels conflict, which can damage something. Maybe some GPIOs control the RAM voltage regulators on some boards? > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
