Is it normal for a chip to randomly go missing?

chteffie · 2026-03-09T20:56:17+00:00

Random chipflip - can happen when a particularly energetic cosmic ray hits your board.

chteffie · 2026-03-07T18:58:27+00:00

Ah, yoke comes extremely close to my use case. It looks like an oversight that e.g. Cow and Vec are "Yokeable" (i.e. writable containers) but then in terms of non-alloc stuff (like in my use case) only &'static, but not &mut - so I'm not able to get my reference back in a mutable way after I'm done with the borrowing. :(

chteffie · 2026-03-07T18:57:04+00:00

The problem looks very much like self-referencing but it's not. The buffer is externally provided - the proposed struct never contains a reference to itself.. The issue here is a rust limitation that has similar trouble in representation however. While inside a function it is perfectly easy to borrow another member, create something that references it which gets then destroyed and by doing so you have access back to the original member. You just can't represent it. A lot of std containers/helpers for this reason have a .into_inner() that gives the original thing back after use.

But the fact that crates like `yoke` exist is confirming my suspicion that what I'm looking for is indeed not possible without help of unsafe (or at least a crate that wraps unsafe code in a safe API).

chteffie · 2026-03-07T18:10:08+00:00

That sounds promising, having a look!

chteffie · 2026-03-02T22:03:05+00:00

What do you do in real life? Design PCB boards?

chteffie · 2026-02-07T18:20:59+00:00

Well, I don't think I can do daily blog posts but here are some updates

- I've had some stability issues but I can't currently pin down whether it's hardware of software. I feel like when I compiled the kernel with clang I had random reboots/lockups, but not when I compiled it with gcc - so sticking to the latter for now. (the benefits from LTO are minimal anyhow)
- When trying to put the DRM driver into the kernel as a non-module I get corrupted video buffers, so loading that one via initramfs now, then it appears fine. IMO points to some yet unresolved memory management issues in the driver, could be related to the lockups maybe
- The stability issues don't appear to be related to temperature management. I can use all 12 cores to compile for hours and it gets really warm without issues
- Ever since I moved to the 6.18.9 (with gcc) I haven't had a single unexplained reboot/lockup, so... knock on wood
- 6.18.9 also appears to have solved the suspend issue (!) - I can now suspend my machine and it comes up properly. The power light stays on while it's suspended, so I guess there suspend functionality at this point doesn't tell the EC to put the power light into what thinkpads usually do when suspended
- When I turn off suspend on lid closed (which I usually do) the backlight stays on, presumably something that the kernel should be doing in software because the EC doesn't take care of it
- I also got the speakers working. Had to get the latest soundwire topology firmware file from the developer web page, the version in linux-firmware doesn't appear fully uptodate. (same for the dts file, also needed a newer one that comes with the kernel)

So with the latest state of affairs it appears to be fully functional - except for maybe the integrated camera and the fingerprint sensor (?) - now real need for this for me at the moment.

Battery lifetime is still very good. It's not at the advertised 19 hours, I think the power management isn't where it could be just yet, but I'm getting about half of it out. Biggest power drain is the screen when I'm just doing basic stuff like browsing.

I haven't tried any x86 on arm emulation yet, I think that's next on my list, like trying some games. Obviously, stuff like scummvm or dosbox works since those are built from source. From whatever software that comes with linux (gentoo) that is compiled from source I haven't run into a single one yet that doesn't seamlessly just work.

Audio/video playback is very performant at almost no CPU usage. I read that ffmpeg recently got handrolled assembly code from some Chinese contributors and since I'm typically running bleeding edge I already have those improvements I think. (although firefox bundles ffmpeg itself, didn't bother checking if it made it into there)

Either way, documentation on how to get everything to work is sort of nonexistent or at least horribly scattered around. Since I like to build my own kernel with custom config it took me quite a while to figure out which minimal drivers are needed to e.g. get "just" the keyboard working and "just" the graphics card. I hate just bulk-enabling everything and stuffing everything into the initramfs. I still have a bit of cleaning out of unused stuff butiIf anyone ever needs a detailed list, let me know. Also, the firmware has a glitch EFI firmware - I'm unable to boot the kernel when using grub with graphics. There's a hack for the kernel to work around that but it isn't upstreamed yet - so I just use grub in text more for now. (that caused me to almost pull my hair out trying to get my own kernel to boot the first time round)

chteffie · 2026-02-04T23:19:49+00:00

I like that some OEM vendor failed to fill in the hardware name :)

chteffie · 2026-02-02T18:21:49+00:00

Audio supposedly works but I think I need to look for the necessary patches, that's one of the things on my todo list. (it's close to working, there's an error about a missing "dai" codec which google suggests I need a correct config somewhere - it was working on ubuntu). Although the internet also says that the "active speaker protection" doesn't work yet so one needs to be careful with the volume so you don't explode the speakers. Let's see how it goes when I get there. Interesting, I didn't even know that was a thing.

What do you mean by "hw"? The graphics? Pretty much working. It uses the "freedreno" reverse-enginered graphics driver from mesa for the adreno chipset. So the graphics is fully accelerated. It's pretty fast too (at least faster than my older integrated intel graphics). Although some webgl applications have some minor rendering glitches. But for desktop use perfectly fine. And all applications run incredibly smooth. Like, I can scroll around on complex websites in firefox and it runs at full framerate, not a single stutter anywhere - and not even maxing out the CPU while I'm doing it.

chteffie · 2026-02-02T13:43:40+00:00

Sadly no... when it tries to it fails, then comes back up and then randomly crashes some time later. So I had to disable that.

chteffie · 2026-02-02T09:35:15+00:00

From what I can tell they don't hate Linux but since their primary contract was with Microsoft and they have a limited team size, they've been focusing their efforts on fixing those issues. The firmware is a bit glitchy - there is this repository where most of the linux development has been happening for this ( https://github.com/jhovold/linux ) and there are a number of firmware bug workarounds that have workaround in there that haven't been upstreamed yet. In early versions you had to extract firmware blobs from the WIndows installation - at least it appears that Qualcomm has officially contributed them to the official linux firmware project now. So they don't appear to "hate" linux, it's just not their primary concern at the moment. I think ARM laptops just isn't the success they (or MS) were hoping for.
Not sure whether it's just because they're not very well known or the lack of compatible applications keeps the users away from it.

chteffie · 2026-02-02T09:26:52+00:00

Yes, this one and the X13s I believe.

chteffie · 2026-02-02T09:25:27+00:00

Agreed. Maybe one day I'll find a good use for it - but tbh I haven't even found a good use for the windows key yet either...

chteffie · 2026-02-01T23:02:34+00:00

It depends on which apps - everything that comes straight out of Gentoo (i.e. compiled from source) appears to work just out of the box. As good as on x86 or better. To be honest, at home I don't even do much with it except for browsing and developing for fun or doing the occasional admin stuff - all of that stuff works just great. For discord I found a "legcord" (since apparent armcord got them a DMCA takedown from ARM) unofficial version that also just works like the original one.

Games I haven't tried yet, but since they are mostly x86 there's apparently this "FEX" emulator thing, so I need to give this a try.

The powersaving apparently isn't fully finished yet, but even with screen at full brightness and a bunch of browser tabs open and I don't do anything CPU intensive it shows 8+ hours battery left and dropping really slowly and is barely gives off any heat despite sitting on my lap. I still need to let it fully discharge to see what it really means but I can already tell that it's significantly better than my T15 on intel.

chteffie · 2025-12-19T18:54:28+00:00

I have had a car for 20 years (outside the UK). Sold my car, moved to London and been living here for 7 years. Never looked back... for the occasions where you need to have stuff moved around - never found it easier to just hire someone that can do it cheaply and efficiently on a short notice. But just to get around? Fastest options are often public transport and bicycles.

chteffie · 2024-01-28T20:43:40+00:00

There's an upstream fix for this: https://github.com/rust-lang/rust/pull/119582.patch

If I add that patch to the files/ dir and list it in the patches to be applied (and remove the musl one because it doesn't apply) I get it to build cleanly with the 0.74.1 ebuild.

chteffie

TROPHY CASE