Issue #631 has been updated by Alicja Michalska.
Sebastian Müller wrote in #note-6: > 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. I apologise if that's the case. I'm happy to see newcomers learning (even though they will make mistakes in the beginning), but your patches had a tell-tail signs of AI use (unnatural commit messages, large comment blocks for single functions, confidently incorrect solutions). > 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. At the time, I > considered the workaround plausible because I had also verified that the > stock firmware disables L1.2 on all ports. > > 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. Why are we suddenly talking about I226 NICs, when your patch didn't touch those RootPorts? That being said, I just tested your suggestion for EC 0x70 on my board and while going trough Kconfig I noticed ASPM gets enabled by default. Dropping it from Kconfig (board-level override) should "fix" all of those problems, adding flags you suggested in CB:94030 only kiiiinda helps. Of course real solution would be getting our hands on schematics and configuring everything as it should, but if my experience with erying is anything to go by... one can dream. I believe we could drop LegacyIoLowLatency if we knew which GPIO controls the PCIe reset and we can find it as mentioned above. I would have to pull my firewall out of service though which isn't... ideal. > 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? That is very likely, you're correct about BKHD being the ODM for Topton (and many other "AliExpress specials"). However, I'm pretty sure your board is different since you mentioned lacking UART on yours. Topton has an RS232 in RJ45 form on the front and additional RS232 header (LDN2) internally. I would say it's likely that your board's DRAM routing is off, but I can confidently say this hasn't been an issue on N100 (or N150, they're the same - just with newer SoC). > 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. Again, I apologise in this situation. I did in fact jump into conclusions your code must've been "vibe-coded" based on it's structure and well, mistakes. This probably wouldn't have happened (especially not publicly) if we would've discussed this on coreboot chat (but then again, we have so many communication channels it makes it difficult to know where to go and should decide on one - such as IRC or Matrix). I understand I've hurt your feelings and insulted your code, so once again - I'm sorry. Hope this won't stop you from contributing in the future :) ---------------------------------------- Bug #631: Topton X2E (N150) instabilities/timer issues https://ticket.coreboot.org/issues/631#change-2352 * 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]
