#netbsd on a Chromebook, because WCGW?

Standard ACPI stuff like CPU temperature reading, battery reporting, ATKBD or screen brightness does work.

However, nothing related to EC work (TigerLake and newer will not boot from USB-C due to Mux introduced in that generation, EC will also enter failsafe mode after few minutes, start ramping the fan up and hard power-off due to no response from nonexistent driver).

Graphical corruption in X11 (which also happens on Linux, this thing has a 4K display and works correctly only in Wayland).

Biggest surprise is that I2C seems broken, so touchpad/touchscreen/stylus probably wouldn't work (although I expect to beissing drivers for those devices as well).

Sound and WiFi of course doesn't work (Chromebooks use SOF, so it's not a standard HDA configuration and adding support for audio DSP would be... quite a lot of work) and WiFi is an Intel AX201 (cnvi), so obviously no luck there.

Probably biggest suprise to me is that NetBSD (seemingly) has zero complains about coreboot's ACPI, the only (mis)reporting of ACPI error is that it had no idea how to parse CrosEC stuff.

I'm positively surprised. Being the one to potentially write missing platform drivers sounds fun, I can implement some stuff I had in mind but maintainers of `platforms/chrome` in Linux absolutely hated :blobcat3c:

I think I'm gonna add NetBSD to my standard testing suite while working on coreboot, not just Linux and Windows.

"Yes we accept LLM contributions, but our code standards are high"

I can't believe someone from @netbsd managed to nerdsnipe me into bringing back AMD F15h support in coreboot :akko_giggle:

Netherlands country review:
- Really nice people with great sense of humour
- Gluten-free food available on every corner
- Quiet cities
- Every public toilet I've seen was unisex (finally, gender abolished /s)
- Dutch bikes are absolutely GOATed (I want one now)

Pretty nice, shall visit again :neocat_floof:

Sometimes, while porting #postmarketos you accidentally create abstract art

Finally after ~6 months of work we can (almost) boot AMD Phoenix (Ryzen 7000 Mobile) with upstream #coreboot (+3 unmerged patches as of now) and OpenSIL. Whew, what a ride.

Some issues still remain, platform still hangs while:
- Bringing-up UART0
- Sending POST_COMPLETE to PSP mailbox

So those need to be figured out (commenting-out those functions is just a massive hack as of now)

Signal integrity isn't real, it can't hurt you

"Look ma, we're running off of battery!"

ACPI on AMD and Framework-specific Chrome EC customizations are kicking my butt, but once I fix the suspend this will already be daily-drivable (with ~30% better battery life than stock firmware thanks to already having better power management than InsydeH2O) :ablobcatbongo:

Also after dropping AMD's GOP into IDA I suspect it silently fails because it can't store NVRAM variables due to SMMSTORE being unavailable (SmmStore region initialization fails and throws an exception, I freakin' hate EDK2).

Given that GOP is patching the VBIOS in some way, I suspect fixing SMMSTORE will fix GOP init, and that in turn will fix DP AltMode.

With that sorted the only remaining things TODO will be Thunderbolt 4 and controlling bifurfication on RootPort exposed as an expansion bay :blobcat3c:

Asked around and were told that AMD ATOMBIOS wasn't storing device-specific configuration and I found that sus because I couldn't get eDP initialized with generic one provided by 3rdparty/amd_blobs and Intel has VBT for this exact reason...

Turns out my hunch was right, we're gaming :acat_sunglasses:
https://www.youtube.com/watch?v=7XlH_1Z0slk

I'm kinda curious if there are existing OSHW PCIe breakout boards (or debug cards)?

At this point I'm so annoyed by not being able to fully implement PCIe power management in my ports (due to lacking schematics) and too impatient/scared to poke M.2 connectors with a scope.

Making simple PCIe and M.2 cards with LEDs hooked up to power source via gates controlled by clock/reset lines would make it *so much* easier. Just plug one of those, mess with GPIOs from Linux and observe LEDs :akko_thonk:

*oven ding* it's done :ablobcatbongo:

Took me a while to finish this because of life-related reasons, but finally sat down and fixed (most) remaining issues during the weekend. Pretty much everything* is working - including S3 suspend/resume, automatic fan control and so on (plus it draws less power than stock, I have no idea what AMI is doing).
Feels kinda surreal to have a fully-functional computer :akko_giggle:

If you have an "MSI PRO B760-P WIFI DDR4" motherboard (or "MSI B760 GAMING PLUS WIFI DDR4", pretty sure they're the same just with different UISetup skin) you can now flash #coreboot on it.
DDR5 versions can be easily added if someone is willing to work/test it, just a matter of telling FSP you're using a different memory type.

Will document stuff (like making flashing cable that won't void warranty) later. Enjoy :blobcatsalute:
https://review.coreboot.org/c/coreboot/+/93127

I don't know where the misconception "you can't boot Windows using coreboot" came from, but I'm tired of correcting people... so here's the proof which should (hopefully) put that misconception to rest for once and for all :akko_tired:

All you need are sane ACPI tables (which makes booting windows a great test, otherwise it'll throw a BSOD at you) and payload providing UEFI services (for consumer versions). That's literally it.

Ok, I will bite: Any recommendations for affordable SPI flashers that are capable of driving it's I/O with 1.8V *natively*?

Spent 2 hours yesterday debugging PiPico with 1.8V level shifter to no avail, either using picoprog, or libreboot's repo for serprog firmware (which didn't even build because someone fatfingered int baud, but that was an easy fix since it's C).

Finally got fed up with it, disconnected my Glasgow from DUT I was working on for the past few months, connected it to the MSI board and it just... worked first-try.

Problem is that I often need more than one flasher on hand, and Glasgow is pretty expensive (plus I prefer to have it with me while traveling, it's insanely useful). The only other flasher that I know of is a DediProg SF600, but that has an astronomical price so... yeah.

Phew, this lifehack (stolen from @domi ) saved my butt so I'm just going to share it further.

Sure, it looks awful... but if you have windows facing south (or if you can't afford/your landlord doesn't allow you to mount sun-blocking curtains) this is a lifesaver.

In the current heatwave my apartment (according to temperature sensor on my desk) was already hitting 36*C inside despite window in the room being covered with a blanket. Standing in the kitchen in the afternoon made me feel dizzy within two minutes.

After applying the tinfoil to windows in the kitchen, over the few hours temperature dropped to 28*C. Tinfoil is so hot, that I can't keep my hand on the window for more than 4 seconds (so it's very close to 50*C).

Going to apply the tinfoil to the window in the room as well, it should reflect a lot of that heat and make blanket much colder as a result.

Something something Linux users don't need windows or something :akko_giggle:

#postmarketos can have contactless payments, as a treat :blobcat3c:

RE: https://js.meowingwo.men/notes/amdt8yp0lfgr007p

2012 is so back :blobcat3c:

When in doubt, use more printf's

Another month, another shitty behavior from Bambu Lab... and at this point they're just *asking* to get hacked (I guess they haven't heard of the "don't piss off the hackers" rule).

Apparently they sent a DMCA to someone working on cloud integration in OrcaSlicer. Not something I would use, but it just... pisses me off (especially because I'm waiting for A1 to arrive myself).

Started looking into it, based on pictures I see:
Mainboard:
- Spintrol SPC2168 (Dual-core Cortex-M4)
- ESP32-S3
- GigaDevice 25Q128ESIG
- 4x stepper motor controller under the heatsink?

TH board:
- Spintrol 50KB (Cortex-M4)
- 2x ZHONGKEWEI AT8236

Looks to be similar to other models made by them, as documented under:
https://github.com/opensourcemanufacturing/OpenBL/

While ARM MCUs have OTP, worst-case they can easily be replaced with STM32 equivalent thanks to LQFP packages.

Firmware on bambu's website looks to be encrypted (lol, lmao), but dumping it from device in hand (when I'll receive my printer) should solve that problem.
Those files also are self-describing if we look at the board and amount of flash space available:

- AMS: Didn't look into it (and didn't buy one), but it's under 100KB so AMS likely also has a SPC1168APE MCU in it
- AP-ES3: Juicy, easy target. It's 4.9MB in size, so it must live in the SPI flash and store firmware that ESP32-S3 is running.
- AP-HMS: Based on image files in the folder and 700KB size, this is likely firmware that SPC2168 is running and controls the display in front of the device.
- MC: Purely a speculation, maybe for the built-in camera?
- N3F/N3S/N2S: No idea, possibly an NFC chip?
- TH: 50KB, running on SPC1168APE

Pinout can be beeped-out, all you need are GPIOs for motor controllers anyway. Display would be a bit trickier, but oscilloscope solves that problem just fine. Besides, the MCU doesn't have MIPI or anything of sort so it's likely just an SPI for display and I2C/SPI for touchscreen :akko_shrug:

I do kinda wonder how people store their projects long-term.

Sure, git repo is the way to go, but sometimes you have stuff like vendor-provided sources or NDA documentation that can't be uploaded anywhere...

My work drive (Optane 900P 280GB that I received from a person working for Intel few years back) is used for projects that are ongoing, as compiling is crazy fast on it (kernel compiles ~3 minutes faster than on Kingston KC3000 which is my main drive).

I guess I probably should build a NAS, but in this economy... uuh, no thanks