Issue #631 has been updated by Sebastian Müller.
I need to correct this, because what you are saying about my work is simply not true. I wrote these patches myself. They were not AI-generated and they were not “vibe-coded”. I looked at the logs, the Super I/O dump, the existing coreboot code and the behaviour I was seeing on the actual hardware. I formed hypotheses from that and wrote the changes. Some of those hypotheses may be wrong. I may have missed existing work or misunderstood part of the platform. That is fair technical criticism, and I will correct or drop patches where I got it wrong. But that is not the same as saying that I did not write or understand my own code. Calling it “obviously vibe-coded” is not technical review. It is a claim about how I work, and in this case that claim is false. Regarding ASPM: you are right that the default board configuration does not enable it. I enabled `PCIEXP_ASPM` in my own build while experimenting with reducing the system’s power consumption. The NVMe problem I observed was a wake-up problem from L1.2, not an initial detection problem. I incorrectly mixed those two issues together in the commit description. At the time, I considered the workaround plausible because I had also verified that the stock firmware disables L1.2 on the affected port. The reason I did not want the board configuration to silently allow L1.2 when ASPM is enabled was not invented. The I226 advertises L1.2 support despite a hardware limitation that can cause packet loss and degraded performance because its L1.2 exit latency is too high under traffic: https://www.mail-archive.com/[email protected]/msg11497.html Yes, the Linux `igc` driver has since gained a workaround that disables L1.2 for the I226. But that does not make the firmware-side concern irrelevant. It only helps when the system is running a kernel that contains a correct version of that workaround. The follow-up patch also shows that the original workaround did not work correctly during initial probe and required another fix: https://www.mail-archive.com/[email protected]/msg12376.html That does not automatically prove that my board-level patch was the correct solution. It may have been too broad or implemented at the wrong layer. But there was a real hardware problem and a real reason behind the change. It was not random code produced without understanding. The RAM issue was also based on behaviour I observed with some of my modules on the BKHD-manufactured boards. BKHD is the actual board manufacturer behind several systems sold under reseller names such as Topton. Not every unit necessarily has the exact same memory, NVMe, board revision or behaviour as yours. A 49-day uptime on one configuration does not disprove instability on another configuration. I agree that I did not have enough evidence to describe the RAM behaviour as an established platform-wide issue. I should have presented it as a hypothesis based on specific hardware observations. That was my mistake. As i wrote, i had regularly segfaults with cronjobs running when the cpu was idle which were only fixed with setting SagV to a fixed point or disabled. I switched the memory module and the behavious was the same. Maybe voltage or routing problems on the board? Can that be? I am still learning parts of coreboot. Of course I do not have the same amount of accumulated project knowledge as someone who has worked on it for years. I have never pretended otherwise. But I do know how to program and debug hardware. I studied computer science, specifically Kerninformatik, as well as electrical engineering at TU Dortmund, and I am from the Dortmund area. I have already ported two boards to coreboot successfully. I also got fTPM working on Broadwell without modifying the common coreboot code. To the best of my knowledge, that functionality had previously only been available for newer platform generations. I am not mentioning that because I believe it makes my patches automatically correct. It does not. I am mentioning it because the public picture of me as someone who blindly generates code and submits it without understanding is false. If my code is bad, tell me exactly where and why. If an assumption is wrong, explain the mechanism I missed. If there is existing work I should have found, point me to it. I can work with all of that, and I will fix or withdraw changes where appropriate. What I cannot work with is being publicly dismissed as someone who did not write or understand his own work, or being told, directly or indirectly, that I should not have submitted code at all. I saw your coreboot talk on YouTube and found you open, welcoming and encouraging towards people interested in contributing. That is why the speed and certainty with which you judged both my work and how it was produced are especially disappointing. The tone here feels aggressive and discouraging. New contributors will inevitably make mistakes and lack some project-specific knowledge. That is what review is for. It should not require someone to already possess years of undocumented project knowledge before they are considered entitled to submit a patch. Please criticize the code as strongly as technically necessary. But stop calling code I wrote myself “obviously vibe-coded”. I have encountered real problems with these BKHD boards, and I have consistently tried to identify their causes and solve them. ---------------------------------------- Bug #631: Topton X2E (N150) instabilities/timer issues https://ticket.coreboot.org/issues/631#change-2348 * Author: Victor Bessonov * Status: New * Priority: Normal * Target version: none * Start date: 2026-02-23 * Affected versions: main * Affected hardware: Topton X2E * Affected OS: Linux, BSD ---------------------------------------- Image built from master (c9578eac246) as 25.12 does not support iPXE with SecureBoot in edk2 payload. After flashing the image a few bugs were discovered (all may be related to the same root cause) 1. Some USB drives and NVMes may be not detected in edk2 on boot - setting port speed to Gen3 manually and turning off power saving mostly helps with NVMes, however some flash drives may still need to be unplugged and re-plugged back 2. Booting from Ventoy USB mostly doesn't work - some linux images wait for mount and then fail with timout, others will just hang. Ventoy itself boots quickly and reliably. 3. USB booting from images written directly to flash mostly works, however BSD may still hang or panic out with spinlock timeout panic (OpnSense/FreeBSD) 4. Linux kernel reports about broken IRQ 9 (acpi_sci=low seemingly removes the message from dmesg) 5. After several tries to boot, BSD system got installed without any issues, however after rebooting into it the system became extremely laggy (even printing to the console worked word-by-word, high LA without any userspace CPU-loading process), switching the timer from LAPIC to HPET on running system seemingly resolved all the laginess instantly 6. Linux kernel reports that HPET is dysfunctional in PC10 (shouldn't it be fine on Alder Lake?) Build config (I tried both with default xApic and x2Apic - doesn't seem to change anything): ``` shell CONFIG_VENDOR_TOPTON=y # CONFIG_POST_DEVICE is not set # CONFIG_POST_IO is not set CONFIG_TPM_MEASURED_BOOT=y CONFIG_BOARD_TOPTON_X2E_N150=y # CONFIG_FSP_HYPERTHREADING is not set CONFIG_X2APIC_ONLY=y CONFIG_TPM2=y CONFIG_TPM_MEASURE_MRC_CACHE=y CONFIG_DEFAULT_CONSOLE_LOGLEVEL_6=y CONFIG_PAYLOAD_EDK2=y CONFIG_EDK2_ENABLE_IPXE=y ``` The majority of these problems can be explained by faulty timer - the reason for a single ticket I'm also attaching the patch suggested in Discord channel for reference - doesn't seem to solve the issue ---Files-------------------------------- coreboot.log (63.9 KB) linux-boot.log (274 KB) gpio.patch (3.1 KB) SuperIODump.txt (1.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 -- [email protected] To unsubscribe send an email to [email protected]
