coreboot September 2023

coreboot@coreboot.org

26 participants
34 discussions

[coreboot - Bug #121] T520: Hangs in OS
by Anastasios Koutian 24 Sep '23

24 Sep '23

Issue #121 has been updated by Anastasios Koutian. File defconfig added The issue is resolved for me after doing the following: a) Change motherboards from FRU 04W2049 (dGPU + iGPU) to FRU 04W2045 (iGPU). b) Update coreboot to 4.21 with EDK II (defconfig is attached). System has been stable for 6+ hours with no c-state limit. Previously it would freeze after 1-3 hours. Everything else is the same as my previous post. I recommend anyone still facing this issue to try the above. ---------------------------------------- Bug #121: T520: Hangs in OS https://ticket.coreboot.org/issues/121#change-1664 * Author: Julz Buckton * Status: New * Priority: Normal * Start date: 2017-06-09 ---------------------------------------- I have been running coreboot since 2017.04.15 and have experienced hangs ever since then. It was suggested by folk on the IRC that I run memtest to check for incorrect raminit causing errors, however I have run memtest for 12 hours straight with no errors. Due to the ambiguous nature of the hangs (immediate freeze with no warning signs, audio gets stuck repeating the last 50ms or so of noise, not sure what this effect is called) I don't have much useful information other than the .config and dmesg. However one thing I can say with high confidence is that the hangs occur significantly more frequently in Linux (*buntu distros) than Windows 10. Within an hour of launching Linux a hang is likely, whereas Windows typically runs for many hours before a hang occurs. I considered this an insignificant anecdotal anomaly at first but over the course of the nearly 2 months I have been running coreboot it seems to be a solid trend. The hangs occur anywhere, typically during mere desktop usage or basic web browsing. Additionally there is another form of hang I experience where the screen goes black except for some sort of graphical corruption down the left side (http://i.imgur.com/4zWrlpX.jpg), whether this is related to the more common total freeze hangs I don't know but I figured I should include it nonetheless. These hangs only occur about 1:20 compared to the regular hangs. ---Files-------------------------------- config (20.7 KB) dmesg.txt (57.3 KB) cbmem-raminit.txt (62 KB) lspci.txt (29.6 KB) cpuinfo.txt (3.94 KB) defconfig (1023 Bytes) defconfig (699 Bytes) -- 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

1 0

Jasper Lake: Commit 21e61847 (ramtop caching) causes FSP-M to fail with EFI_UNSUPPORTED
by Jonathon Hall 22 Sep '23

22 Sep '23

2 1

2023-09-20 - coreboot Leadership meeting minutes
by coreboot org 20 Sep '23

20 Sep '23

# 2023-09-20 - coreboot Leadership meeting minutes ## Attendees: MartinR, MarshallD, MattD, RonM, TimC, FelixH, KarthikR, JuliusW, DanielM, JonathanH, SimonG, JonM, StefanR, NicoH, MinaW ## Minutes: ### sjg - RFC: Post-build control of serial console * https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/F5NP… * outside of the thread: https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/D2PI… * Enable/Disable the serial console on images with the console previously disabled/enabled. * In CrOS, both serial and non-serial are built. * Put control in the boot block. * Martin] This presents multiple issues: * Changing the bootblock will mess up cbfs verification * On AMD platforms, the bootblock is part of the AMDFW binary, not in the typical place. * CBFSTOOL would access the “coreboot control block” to enable/disable serial. CBFS attribute - use a magic number in the boot block. * [Martin] Let’s separate this into 2 issues - do we want this feature & how to enable it. * [Matt] What’s the size difference & impact to boot time. * No impact if serial is disabled at build time (since this feature of course will not be enabled) * Size of the serial drivers * Boot time is not impacted unless serial is enabled. * Stefan] We have defaults for cmos settings that can be changed (though obviously not all systems have cmos). There’s no uniformity across all platforms. Let’s make enabling/disabling options flexible so that we can use different back-ends depending on the platform. Can’t write to CMOS when the machine is up and running. * Julius] CBFS attributes are already (mostly) written up. * CBFS may not be a good option because of the code needed to read it. * [martin]This is just an argument about how to set up a new configuration mechanism. * Let’s use something that works with the current CMOS option mechanism. * Stefan] Let’s see if we can get rid of the ChromeOS GBB flags while we do this. * Julius] this is being discussed, but not really relevant here. We can already put the existing GBB flags in CBFS. * Martin] Let’s not add yet another method of configuration. * Smmstore - SJG: uses an FMAP region so available later in bootblock? * CMOS - SJG: not controlled by firmware image * can we use the options API? * one drawback?? is that it uses strings to access the values * Stefan] Can only be modified when the board is running. * Devicetree - SJG: build-time * CBI - SJG: doesn't this fetch from the EC? * Martin] Yes * Storing things in the SPI ROM. - that is this proposal. * Martin] I believe that there’s already a method for doing this that’s implemented. * CBFS flag files - SJG: available later in bootblock? * VPD - SJG: not available in bootblock? * Kconfig? - SJG: build-time * Nobody disagrees with the idea of being able to enable/disable the serial console at runtime, the thing that needs to be figured out is the method. ### [Nico] What to do about undisclosed downstream coreboot used in production? (cf. discussion of [CB:77466](https://review.coreboot.org/c/coreboot/+/77466)) * Martin] There was a misunderstanding about whether this code was used in production images or not. From the discussion last meeting, as David described it, the EINJ is strictly for debug. * What’s our official position? * [Martin] We decided this in the last meeting. EINJ is *debug* code and would never be used in a production image. It’s useful code, so the agreement was that it should be left in coreboot, but could be moved to vendorcode. * How could we push back? E.g. ask to add absence of such conflicts to the criteria for “OCP accepted” badge? * [Martin] I think pushing back should be handled on a case-by case basis. * Concerns: * It seems unfair to deny the addition of new blob support on one hand and allow direct linking to proprietary code on the other. * [Martin] Are you arguing that we should allow other blobs because of a blob that’s never going to be used in production images? * Weakening the idea of the GPL might make it harder to get code out of companies that see a business advantage in their work. * [Martin] How does this weaken the GPL? * We need better communication about what any code that is used along with sources outside of the tree are for. There needs to be a maintainer for these items. * Let’s discuss this further later. ### [MartinR] Formatting arguments: What’s the coreboot standard for wrapped lines? * Should they match the start of the previous block or just use two tabs beyond the previous indentation? Or something else? * Julius] Decide on place-by-place basis - let the developer decide. * Can we start using clang-format for everything so that we can stop arguing about formatting? * Julius] Let the author decide - new contributors should just follow the existing format. * Ron] This worked well on other platforms - Rust & Go communities - just format it and move on. * Nico] We decided on clang-format already. * Martin] We just need to finish the implementation. Clang format versions caused issues. * Jon] Not using clang-format causes confusion and keeps people from wanting to update patches. * Felixs] hook up clang-format to the CI and allow the reviewers to decide * Ron] this would keep the current situation. Make the automaton the arbiter. * Simon] Agrees with ron - let’s not argue about formatting. * Clang-format would be done a directory at a time. * Felix] Patches that are in flight will be problematic. * There’s a script to reformat patches: clang/tools/clang-format/clang-format-diff.py * Martin] I will pick up the existing patch for the clang-format config, and we can discuss the configuration settings. I’ll send out a sample to the mailing list and write up some instructions on how to use it. * We can use the clang-format from the coreboot toolchain. ### [MartinR] I’m planning on hiring someone to help with this meeting. Duties include: * Announcing the upcoming meeting on IRC, Slack & Discord. * Helping keep minutes during the meeting * Sending the minutes to the mailing list at the conclusion of the meeting. I’ve already picked a person, and hope they’ll start attending in the next few meetings. I’m paying for this out of my own pocket to avoid any issues with having the SFC pay someone, which involves contracts & whatnot. # Next meeting October 4th, 2023 * [Meeting link](https://meet.google.com/pyt-newq-rbb) * [coreboot Calendar](https://coreboot.org/calendar.html) # Notice Decisions shown here are not necessarily final, and are based on the current information available. If there are questions or comments about decisions made, or additional information to present, please put it on the leadership meeting agenda and show up if possible to discuss it. Of course items may also be discussed on the mailing list, but as it's difficult to interpret tone over email, controversial topics frequently do not have good progress in those discussions. For particularly difficult issues, it may be best to try to schedule another meeting. # coreboot leadership meeting minutes https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK…

1 1

RFC: Post-build control of serial console
by Keith Hui 18 Sep '23

18 Sep '23

Hi Simon, > Why not CMOS RAM / VVRAM? - If we allocate some space in CMOS for console / logging settings, then it would allow a similar feature. But it involves changing settings on the device. Each board would need to provide some CMOS options for this feature as part of the layout file. It would not be possible to enable console output without running some code on the device to update the CMOS RAM. (Pardon the formatting; I copied this out of my semi-regular digest) Many boards already have this space allocated in their cmos.layout. Take for example my sandybridge board, asus/p8z77-m: # coreboot config options: console 395 4 e 4 debug_level [...] # debug_level 4 0 Emergency 4 1 Alert 4 2 Critical 4 3 Error 4 4 Warning 4 5 Notice 4 6 Info 4 7 Debug 4 8 Spew Setting this to 0 suppresses almost all outputs unless it's a "I'm going to die()" scream. For development/hacking we do want to start with debug outputs on the console. If after ample testing a build has proved itself to be stable, cmos.default (that is a separate file) in CBFS can be patched to change the default log level. This would be done through cbfstool (albeit indirectly - extract, patch, re-insert) or a hex editor. I'd propose a tool that operates on this binary cmos.layout instead. In short, in my opinion, we don't need a new construct. Regards Keith

2 1

[coreboot - Bug #505] (New) Intel Harcuvar CRB Denverton_NS С3000. Only 15 cores of a 16 core processor is defined in the operating system.
by Dmitry Ponamorev 15 Sep '23

15 Sep '23

Issue #505 has been reported by Dmitry Ponamorev. ---------------------------------------- Bug #505: Intel Harcuvar CRB Denverton_NS С3000. Only 15 cores of a 16 core processor is defined in the operating system. https://ticket.coreboot.org/issues/505 * Author: Dmitry Ponamorev * Status: New * Priority: Normal * Assignee: Angel Pons * Category: board support * Target version: 4.15 * Start date: 2023-08-22 * Affected versions: 4.15 * Affected hardware: Intel Harcuvar CRB, Intel(R) Atom(TM) CPU C3958 * Affected OS: Debian 11, Ubunto 20.04 (and later) ---------------------------------------- Found a bug with the definition of not all processor cores of the Intel(R) Atom(TM) CPU C3958 processor in operating systems. The Debian or Ubuntu operating system defines only 15 cores. The problem concerns exactly the 16th core processor. For processors with fewer cores, the number of cores is determined correctly. The problem was found in coreboot version 4.14 and later. Version coreboot 4.11 did not have this problem. Most likely this is due to incorrect initialization of apic_id. (apic_id 0) An example of the initialization output of the processor cores is below: Will perform SMM setup. CPU: Intel(R) Atom(TM) CPU C3958 @ 2.00GHz. AP: slot 1 apic_id 6, MCU rev: 0x00000034 AP: slot 13 apic_id 1e, MCU rev: 0x00000034 AP: slot 6 apic_id a, MCU rev: 0x00000034 AP: slot 14 apic_id e, MCU rev: 0x00000034 AP: slot 5 apic_id 4, MCU rev: 0x00000034 AP: slot 2 apic_id 10, MCU rev: 0x00000034 AP: slot 4 apic_id 14, MCU rev: 0x00000034 AP: slot 11 apic_id 1c, MCU rev: 0x00000034 AP: slot 15 apic_id 8, MCU rev: 0x00000034 AP: slot 8 apic_id 16, MCU rev: 0x00000034 AP: slot 10 apic_id c, MCU rev: 0x00000034 AP: slot 3 apic_id 1a, MCU rev: 0x00000034 AP: slot 9 apic_id 2, MCU rev: 0x00000034 AP: slot 7 apic_id 12, MCU rev: 0x00000034 AP: slot 12 apic_id 18, MCU rev: 0x00000034 smm_place_entry_code: smbase 7ffe8400, stack_top 7fe08000 smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x7ffec000, cpu = 0 smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x7ffe9000, cpu = 12 smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x7ffe8800, cpu = 14 smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x7ffe9c00, cpu = 9 smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x7ffe8400, cpu = 15 smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x7ffeb800, cpu = 2 smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x7ffe9400, cpu = 11 smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x7ffe8c00, cpu = 13 smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x7ffea000, cpu = 8 smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x7ffeb400, cpu = 3 smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x7ffeb000, cpu = 4 smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x7ffea400, cpu = 7 smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x7ffe9800, cpu = 10 smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x7ffebc00, cpu = 1 smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x7ffea800, cpu = 6 smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x7ffeac00, cpu = 5 Initializing CPU #0 Turbo is unavailable CPU #0 initialized Initializing CPU #8 Initializing CPU #12 Initializing CPU #14 Initializing CPU #4 Initializing CPU #9 Initializing CPU #10 Initializing CPU #1 Initializing CPU #15 Initializing CPU #7 Initializing CPU #11 Initializing CPU #3 Initializing CPU #2 Initializing CPU #13 Initializing CPU #6 CPU #7 initialized CPU #14 initialized CPU #15 initialized CPU #2 initialized CPU #6 initialized CPU #12 initialized Initializing CPU #5 CPU #3 initialized CPU #1 initialized CPU #10 initialized CPU #4 initialized CPU #11 initialized CPU #5 initialized CPU #9 initialized CPU #8 initialized CPU #13 initialized -- 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

1 2

First time using coreboot+edk2, I didn't get to see the beginning.
by Keith Hui 14 Sep '23

14 Sep '23

tldr: After my latest reflash of coreboot with edk2 payload, serial log didn't start flowing right away and no on screen activity until OS on drive has begun booting. What gives? After hacking on coreboot with SeaBIOS for so long, I finally tried edk2. It wasn't the smoothest transition. My testing hard drive has a bit of special hackery done[1] in hope it will boot under both legacy and UEFI schemes. I did add SeaBIOS as secondary payload, and it couldn't boot. Then I pulled out the main drive out of my laptop which is all UEFI, and it booted fine after probably 30 seconds of nothing - the first thing I saw on screen is the Fedora spinner. Nothing from edk2 or grub on the drive. There also was a bit of delay on my connected serial console, then when info finally started flowing, it's already well into ramstage. And when I checked cbmem, it unfortunately overflowed so I lost logs of raminit, which would be most important given my patch train now under review. It would take a warm reboot before I start getting the head of the boot logs. I didn't set a boot logo. What more set up I have to do to get my edk2 and grub boot menu back? I've attached logs from minicom, cbmem, and my Kconfig, if it helps. Thanks for any insights. Keith [1] If I remember correctly, it is GPT partitioned with ESP plus a BIOS boot partition where grub can hide itself.

4 4

coreboot has switched the default git branch from "master" to "main"
by coreboot org 12 Sep '23

12 Sep '23

Hello all. As was mentioned in the 4.21 release notes, coreboot has switched the default branch from "master" to "main". We're currently in the process of updating the documentation and scripts in the coreboot repository, but anyone running scripts of their own will need to update them to point to the main branch. To change your coreboot local tree, see what's in your git config: /work/git/coreboot ((dc75d3e6c1...))% git config -l | grep master remote.origin.push=HEAD:refs/for/master branch.master.remote=origin branch.master.merge=refs/heads/master branch.master.rebase=true You can edit your .git/config file to change these to main, or do it from the command line: git config remote.origin.push HEAD:refs/for/main git config --remove-section branch.master git config branch.main.remote origin git config branch.main.merge refs/heads/main git config branch.main.rebase true In general, this name change shouldn't create any significant impact. Basically anything you previously used "master" for, you should change to "main". Instead of using "push origin HEAD:refs/for/master" you'll now use "push origin HEAD:refs/for/main". Instead of checking out or rebasing on master, you'll now use main. All of the open coreboot patches in gerrit have been updated to be pushed to main when merged. The master branch will no longer accept pushes. We will keep the master branch in sync with the main branch for a while so that everyone has time to switch any scripts that are running over to the main branch, but this will be discontinued at some point - probably around the end of November, after the 4.22 release. If you have any questions or issues about how to do things relating to this change, please feel free to reply to this message and we'll try to help solve any issues. Martin

3 2

Patches moved to main branch lost review scores
by Compostella, Jeremy 12 Sep '23

12 Sep '23

Hi, Most of my gerrit patches moved to the main branch over the week-end. But they lost reviews score such +2 or V+1. Typically, <https://review.coreboot.org/c/coreboot/+/77615>. If V+1 is mandatory how do I trigger the Jenkins gerrit build ? Regards, -- *Jeremy* /One Emacs to rule them all/

3 2

2023-08-23 - coreboot Leadership meeting minutes
by coreboot org 11 Sep '23

11 Sep '23

# 2023-08-23 - coreboot Leadership # Attendees: * ChrisW, MartinR, SubrataB, WernerZ, JonathanH, PatrickG, PaulP, JeremyC, KapilP, AnilK, HannahW, JasonG, RajA, FelixH, SimonG, JayT, JuliusW, ShelleyC, Nico, DavidH, MaximilianB, PratikkumarP, JonM, VincentZ, StefanR, MarshallD, ArthurH, FelixS # Minutes: ## [Subrata] Intel AP FW team would like to present the uGOP **implementation** meant for early Sign of Life (SOL). * The support commitment about libgfxinit is not strong from Intel management hence, Intel wished to leverage existing GFX PEIM in a much smaller format to support early display init. I’m hoping to invite the Intel team to present the talk. * [Martin] I’m not sure that we want to replace an open source solution with a proprietary solution. If we can get the uGOP source code opened, that would be ideal, but I can’t imagine how difficult that would be. * Discussion was started on the mailing list _[RFC] Pre-Memory Sign-of-Life using Intel uGOP_: https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/4OS4… * [sjg] Has there been discussion of libgfxinit in C? * https://code.google.com/archive/p/i915tool/source/default/source * https://review.coreboot.org/c/coreboot/+/76762 * The root cause is long memory-training times on recent Intel devices. For AMD it is around 1 second per GB, but Intel takes longer * The uGOP driver is needed to show graphics during the long DDR5 Initialization. * Why can’t the uGOP driver be in the FSPM? * An API needs to be exposed. * Intel wants to have a unified interface between coreboot & UEFI firmware, which is why they want to use the uGOP driver. * So why can’t the uGOP driver be open source? * Because of intel. Maybe in a year the situation will have changed. * This isn’t coreboot’s problem. The Meteor Lake GPU VPU Linux driver was [open sourced last year](https://patchwork.kernel.org/project/dri-devel/patch/20220728131709.1…. * Release the information, and the community can help. * The uGOP is needed for early bringup of the chip, but Google needs the uGOP driver for the length of the program, because any other possibility won’t be tested. * The uGOP driver allows comparison with libgfxinit. * But we can already compare libgfxinit with the full GOP driver. * Again, why should the coreboot community care? * The only way we can get Intel to change and actually support open source is by putting our foot down now and refusing the uGOP driver. Intel has *no* incentive to change otherwise. * coreboot does *NOT* want another blob. Intel keeps telling coreboot that it’s just not possible or that it’s going to take too long, but if they had started on a previous project, they’d be ready now. * Intel: Not able to make changes for current platform but may consider them in future. * [Patrick] Same answer as in the last 13 years. Nothing ever happens (and I don’t blame the messengers, I fully believe that they try) ## [FelixS] Broken Matrix/IRC bridge * Bridge is disconnected from IRC and will not be coming back soon. What can we do for coreboot? * Can we set up our own matrix bridge. We can do this, but need to work out the details. * GDPR may be a concern (need to limit data collection). ## [Martin]How do we want to handle renaming I2C master/slave to controller/target. The I2C Spec has changed the names, but most datasheets have not. * Should we rename everything I2C across all of coreboot so that the naming is consistent inside coreboot, but register names are different from datasheets. * Should we leave the master/slave terminology for registers so they match the datasheets, and have the mismatch inside of coreboot. * https://review.coreboot.org/c/coreboot/+/77098 * Julius and Arthur vote to leave the register names using the terminology from their datasheets. * [Nic] This seems to be in line with what is published on https://doc.coreboot.org/community/language_style.html * Consensus during meeting: Keep drivers consistent with datasheets, however the higher-level APIs can use the newer language. ## [Martin] Does anyone know if the workaround for xeon_sp/spr: Enable BROKEN_FSP_NEEDS_STACK_ABOVE_BSS is still needed? * https://review.coreboot.org/c/coreboot/+/61164/3 * Arthur can look to see. ## [Martin] A while back, we discussed trying to help people with patches to keep things from getting stale. Over the past several weeks, I’ve been trying to review things that are starting to get a little old. While this can be cumbersome with long patch trains, I think it’s very useful overall. Here are the searches I’ve been using: * [cb_review_1_week_ignore_starred](https://review.coreboot.org/q/repo:coreboo… * [cb_review_1_week](https://review.coreboot.org/q/repo:coreboot+AND+status:op… * [cb_review_2_weeks](https://review.coreboot.org/q/repo:coreboot+AND+status:o… * The 1 week search filters out a lot of patches - anything with open comments, anything that isn’t verified, anything with open comments. * The 2 week patch just filters WIP and anything over 3 months old. * I’ve been trying to keep fresh patches from getting over 7 days old. ## [Martin] Within AMD, we’ve been discussing the licensing for the APCB (AMD PSP Customization Block) blobs. We believe that they should be licensed similar to how we license the vbt.bin files - as pure configuration data. Currently we’re using the CC-PDDC license for those files, and including them in the main coreboot repository. How would people feel about doing the same with the APCB files? * APCB configuration tooling isn’t public, so the data block itself is the best that can be offered * Still, it’s only data (like SPD or VBT) * Concern if this is data that ought to be changed more often than, say, SPD? * It makes sense to keep APCB with mainboard, but user should be aware that APCB may get reconfigured at runtime, thus it will not necessarily match the blob stored in the repo. ## [FelixS] [https://felixsinger.github.io/bootguard-status/](https://felixsinger.github… * People often ask on which boards coreboot can be ported on or if their boards can be supported by coreboot. * This tracks hardware which has BootGuard enabled or disabled. * What do people think of this? Would it be reasonable to host this at a coreboot.org domain? * Yes, but let’s make it more generic to support other companies. * Maybe merge with the board-status list? * This is autogenerated, so it would be difficult. * Let’s put it on coreboot.org as it is now, but update it for other platforms. ## [Paul] Please let’s use the mailing list more. Some topics on the agenda could be discussed there first. The agenda sometimes looks like a different/alternative forum. * It’s easier to discuss things in the meeting by speaking than having to write an email. * People should look at the agenda, and add arguments here before the meeting, such as the discussion about renaming I2c. This does help shorten the meetings. ## [Paul] Experienced reviewers from coreboot companies? Who replaced Aaron, Furqan and Tim? Currently my feeling is, only 9elements does “deep” review for the general code base. * It’s hard to get the experience to do the in-depth reviews - When experienced people leave the companies, it’s hard to replace them * [David] Need to recruit more people to develop coreboot professionally. * FelixH and MartinR review everything they merge pretty thoroughly. ## [Paul] Early MRC caching: https://review.coreboot.org/c/coreboot/+/77295 * New Kconfig option or should integration with all platforms be evaluated first * (Ran out of time, we’ll discuss on the mailing list.) ## [Paul] Status amount of funds and spending thereof. * (Ran out of time, we’ll discuss on the mailing list.) ## [Kyösti] Public document, or some other approach, needed to complete review of Intel Thunderbolt: https://review.coreboot.org/c/coreboot/+/75286 * Add JeremyC to the review, and he can try to help find someone. * Bring up on the mailing list so the people at intel have more visibility. # Notice Decisions shown here are not necessarily final, and are based on the current information available. If there are questions or comments about decisions made, or additional information to present, please put it on the leadership meeting agenda and show up if possible to discuss it. Of course items may also be discussed on the mailing list, but as it's difficult to interpret tone over email, controversial topics frequently do not have good progress in those discussions. For particularly difficult issues, it may be best to try to schedule another meeting. # coreboot leadership meeting minutes https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK…

9 17

[coreboot - Bug #175] Most USB3 external disk enclosures do not work with coreboot on X230
by Robert Alessi 10 Sep '23

10 Sep '23

Issue #175 has been updated by Robert Alessi. Patrick Rudolph wrote in #note-3: > The RCBA register for USB seems fine, but we don't do that much xhci initialisation in coreboot. > From the error description I guess it's related to over-current or transmitter margins. Does this mean the situation is hopeless? As it stands, the problem seems to persist under both Linux and OpenBSD, which seems to indicate that neither kernel can complete the xhci initialitation. More information here: https://codeberg.org/libreboot/lbmk/issues/120 And here (please read the whole thread): https://marc.info/?t=151482563500001&r=1&w=2 Thank you! ---------------------------------------- Bug #175: Most USB3 external disk enclosures do not work with coreboot on X230 https://ticket.coreboot.org/issues/175#change-1656 * Author: Tobis Greer * Status: New * Priority: Normal * Start date: 2018-10-16 ---------------------------------------- I would like to report issues with USB3 external disk enclosures and coreboot on the Lenovo X230. I have several enclosures, and only one works without issues: Toshiba Stor E Alu 2.5. Every other one will cause the following messages in dmesg over USB3 (USB2 is fine): ``` [ 73.788819] usb 4-2: new SuperSpeed USB device number 3 using xhci_hcd [ 73.809949] usb 4-2: New USB device found, idVendor=0080, idProduct=a001 [ 73.809955] usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 73.809958] usb 4-2: Product: External USB 3.0 [ 73.809961] usb 4-2: Manufacturer: TOSHIBA [ 73.809964] usb 4-2: SerialNumber: 201503310007F [ 73.813049] scsi host8: uas [ 73.813861] scsi 8:0:0:0: Direct-Access TO Exter nal USB 3.0 0204 PQ: 0 ANSI: 6 [ 73.814609] sd 8:0:0:0: Attached scsi generic sg4 type 0 [ 73.815157] sd 8:0:0:0: [sde] 156301488 512-byte logical blocks: (80.0 GB/74.5 GiB) [ 73.815161] sd 8:0:0:0: [sde] 4096-byte physical blocks [ 73.815326] sd 8:0:0:0: [sde] Write Protect is off [ 73.815330] sd 8:0:0:0: [sde] Mode Sense: 53 00 00 08 [ 73.815659] sd 8:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 73.819382] sde: sde1 [ 73.820711] sd 8:0:0:0: [sde] Attached SCSI disk [ 105.329243] sd 8:0:0:0: [sde] tag#3 uas_eh_abort_handler 0 uas-tag 4 inflight: CMD IN [ 105.329252] sd 8:0:0:0: [sde] tag#3 CDB: Read(10) 28 00 00 00 00 80 00 01 80 00 [ 105.329334] sd 8:0:0:0: [sde] tag#2 uas_eh_abort_handler 0 uas-tag 3 inflight: CMD IN [ 105.329342] sd 8:0:0:0: [sde] tag#2 CDB: Read(10) 28 00 00 00 00 40 00 00 38 00 [ 105.345200] scsi host8: uas_eh_device_reset_handler start [ 105.345276] usb 4-2: cmd cmplt err -2 [ 105.473565] usb 4-2: reset SuperSpeed USB device number 3 using xhci_hcd [ 105.495210] scsi host8: uas_eh_device_reset_handler success [ 138.096012] sd 8:0:0:0: [sde] tag#5 uas_eh_abort_handler 0 uas-tag 6 inflight: CMD IN [ 138.096016] sd 8:0:0:0: [sde] tag#5 CDB: Read(10) 28 00 09 50 f5 d8 00 00 28 00 [ 138.096184] sd 8:0:0:0: [sde] tag#4 uas_eh_abort_handler 0 uas-tag 5 inflight: CMD IN [ 138.096187] sd 8:0:0:0: [sde] tag#4 CDB: Read(10) 28 00 09 50 f5 28 00 00 a8 00 [ 138.116005] scsi host8: uas_eh_device_reset_handler start [ 138.116027] usb 4-2: cmd cmplt err -2 [ 138.244231] usb 4-2: reset SuperSpeed USB device number 3 using xhci_hcd [ 138.265440] scsi host8: uas_eh_device_reset_handler success [ 168.816132] sd 8:0:0:0: [sde] tag#4 uas_eh_abort_handler 0 uas-tag 5 inflight: CMD IN [ 168.816138] sd 8:0:0:0: [sde] tag#4 CDB: Read(10) 28 00 09 50 f7 b8 00 00 48 00 [ 168.816174] sd 8:0:0:0: [sde] tag#3 uas_eh_abort_handler 0 uas-tag 4 inflight: CMD IN [ 168.816177] sd 8:0:0:0: [sde] tag#3 CDB: Read(10) 28 00 09 50 f7 28 00 00 80 00 [ 168.816208] sd 8:0:0:0: [sde] tag#2 uas_eh_abort_handler 0 uas-tag 3 inflight: CMD IN [ 168.816212] sd 8:0:0:0: [sde] tag#2 CDB: Read(10) 28 00 09 50 f6 68 00 00 b8 00 [ 168.832129] scsi host8: uas_eh_device_reset_handler start [ 168.832153] usb 4-2: cmd cmplt err -2 [ 168.960341] usb 4-2: reset SuperSpeed USB device number 3 using xhci_hcd [ 168.981496] scsi host8: uas_eh_device_reset_handler success [ 201.583792] sd 8:0:0:0: [sde] tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN [ 201.583796] sd 8:0:0:0: [sde] tag#0 CDB: Read(10) 28 00 00 00 10 00 00 00 08 00 [ 201.599793] scsi host8: uas_eh_device_reset_handler start [ 201.599817] usb 4-2: cmd cmplt err -2 [ 201.728046] usb 4-2: reset SuperSpeed USB device number 3 using xhci_hcd [ 201.749283] scsi host8: uas_eh_device_reset_handler success [ 234.351266] sd 8:0:0:0: [sde] tag#3 uas_eh_abort_handler 0 uas-tag 4 inflight: CMD IN [ 234.351270] sd 8:0:0:0: [sde] tag#3 CDB: Read(10) 28 00 00 00 08 80 00 01 80 00 [ 234.351343] sd 8:0:0:0: [sde] tag#2 uas_eh_abort_handler 0 uas-tag 3 inflight: CMD IN [ 234.351345] sd 8:0:0:0: [sde] tag#2 CDB: Read(10) 28 00 00 00 08 40 00 00 38 00 [ 234.375267] scsi host8: uas_eh_device_reset_handler start [ 234.375319] usb 4-2: cmd cmplt err -2 [ 234.503509] usb 4-2: reset SuperSpeed USB device number 3 using xhci_hcd [ 234.524774] scsi host8: uas_eh_device_reset_handler success [ 267.118802] sd 8:0:0:0: [sde] tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN [ 267.118810] sd 8:0:0:0: [sde] tag#0 CDB: Read(10) 28 00 00 00 0a 00 00 02 00 00 [ 267.138781] scsi host8: uas_eh_device_reset_handler start [ 267.138872] usb 4-2: cmd cmplt err -2 [ 267.267064] usb 4-2: reset SuperSpeed USB device number 3 using xhci_hcd [ 267.288888] scsi host8: uas_eh_device_reset_handler success [ 297.838883] sd 8:0:0:0: [sde] tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN [ 297.838890] sd 8:0:0:0: [sde] tag#0 CDB: Read(10) 28 00 00 60 08 00 00 00 08 00 [ 297.854785] scsi host8: uas_eh_device_reset_handler start [ 297.854827] usb 4-2: cmd cmplt err -2 [ 297.983104] usb 4-2: reset SuperSpeed USB device number 3 using xhci_hcd [ 298.004091] scsi host8: uas_eh_device_reset_handler success ``` Note that it says it's a Toshiba enclosure but it's not the Stor E Alu 2.5, it's from an Orico 2588US3-V1-BK-PRO with a 2.5" Intel X25M SSD in it. If I use Lenovo's BIOS, then I don't have any errors at all in dmesg, and I'm able to use the disk normally. With coreboot, I can't mount the disk at all and dmesg gets these error messages continuously. ---Files-------------------------------- .config (22.5 KB) lenovo_inteltool.txt (117 KB) cb_inteltool.txt (171 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

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot September 2023