frontpage.
newsnewestaskshowjobs

Made with ♥ by @iamnishanth

Open Source @Github

fp.

You can't trust macOS Privacy and Security settings

https://eclecticlight.co/2026/04/10/why-you-cant-trust-privacy-security/
212•zdw•2h ago•82 comments

WireGuard makes new Windows release following Microsoft signing resolution

https://lists.zx2c4.com/pipermail/wireguard/2026-April/009561.html
150•zx2c4•2h ago•60 comments

1D Chess

https://rowan441.github.io/1dchess/chess.html
178•burnt-resistor•2h ago•31 comments

Industrial design files for Keychron keyboards and mice

https://github.com/Keychron/Keychron-Keyboards-Hardware-Design
89•stingraycharles•1h ago•18 comments

Helium Is Hard to Replace

https://www.construction-physics.com/p/helium-is-hard-to-replace
99•JumpCrisscross•2h ago•54 comments

Bluesky April 2026 Outage Post-Mortem

https://pckt.blog/b/jcalabro/april-2026-outage-post-mortem-219ebg2
54•jcalabro•2h ago•7 comments

CPU-Z and HWMonitor compromised

https://www.theregister.com/2026/04/10/cpuid_site_hijacked/
96•pashadee•4h ago•52 comments

Bild AI (YC W25) Is Hiring a Founding Product Engineer

https://www.ycombinator.com/companies/bild-ai/jobs/dDMaxVN-founding-product-engineer
1•rooppal•50m ago

Clojure on Fennel Part One: Persistent Data Structures

https://andreyor.st/posts/2026-04-07-clojure-on-fennel-part-one-persistent-data-structures/
56•roxolotl•3d ago•1 comments

Mysteries of Dropbox: Testing of a Distributed Sync Service (2016) [pdf]

https://www.cis.upenn.edu/~bcpierce/papers/mysteriesofdropbox.pdf
84•JackeJR•3d ago•19 comments

The difficulty of making sure your website is broken

https://letsencrypt.org/2026/04/10/test-sites.html
10•mcpherrinm•1h ago•3 comments

A compelling title that is cryptic enough to get you to take action on it

https://ericwbailey.website/published/a-compelling-title-that-is-cryptic-enough-to-get-you-to-tak...
9•mooreds•58m ago•4 comments

FBI used iPhone notification data to retrieve deleted Signal messages

https://9to5mac.com/2026/04/09/fbi-used-iphone-notification-data-to-retrieve-deleted-signal-messa...
430•01-_-•6h ago•214 comments

How NASA built Artemis II’s fault-tolerant computer

https://cacm.acm.org/news/how-nasa-built-artemis-iis-fault-tolerant-computer/
558•speckx•1d ago•212 comments

I still prefer MCP over skills

https://david.coffee/i-still-prefer-mcp-over-skills/
388•gmays•15h ago•321 comments

France to ditch Windows for Linux to reduce reliance on US tech

https://techcrunch.com/2026/04/10/france-to-ditch-windows-for-linux-to-reduce-reliance-on-us-tech/
244•Teever•2h ago•103 comments

C++: Freestanding Standard Library

https://www.sandordargo.com/blog/2026/04/08/cpp-freestanding
23•ingve•2d ago•4 comments

Penguin 'Toxicologists' Find PFAS Chemicals in Remote Patagonia

https://www.ucdavis.edu/health/news/penguin-toxicologists-find-pfas-chemicals-remote-patagonia
114•giuliomagnifico•11h ago•46 comments

A new trick brings stability to quantum operations

https://ethz.ch/en/news-and-events/eth-news/news/2026/04/a-new-trick-brings-stability-to-quantum-...
208•joko42•13h ago•47 comments

Code is run more than read (2023)

https://olano.dev/blog/code-is-run-more-than-read/
95•facundo_olano•3h ago•63 comments

RSoC 2026: A new CPU scheduler for Redox OS

https://www.redox-os.org/news/rsoc-dwrr/
18•akyuu•2d ago•3 comments

Native Instant Space Switching on macOS

https://arhan.sh/blog/native-instant-space-switching-on-macos/
602•PaulHoule•22h ago•289 comments

Deterministic Primality Testing for Limited Bit Width

https://www.jeremykun.com/2026/04/07/deterministic-miller-rabin/
18•ibobev•2d ago•2 comments

Supply chain nightmare: How Rust will be attacked and what we can do to mitigate

https://kerkour.com/rust-supply-chain-nightmare
69•fanf2•3h ago•39 comments

We've raised $17M to build what comes after Git

https://blog.gitbutler.com/series-a
271•ellieh•15h ago•588 comments

US summons bank bosses over cyber risks from Anthropic's latest AI model

https://www.theguardian.com/technology/2026/apr/10/us-summoned-bank-bosses-to-discuss-cyber-risks...
81•ascold•4h ago•53 comments

DRAM has a design flaw from 1966. I bypassed it [video]

https://www.youtube.com/watch?v=KKbgulTp3FE
358•surprisetalk•2d ago•127 comments

Generative art over the years

https://blog.veitheller.de/Generative_art_over_the_years.html
215•evakhoury•3d ago•58 comments

Charcuterie – Visual similarity Unicode explorer

https://charcuterie.elastiq.ch/
297•rickcarlino•21h ago•68 comments

Why I'm Building a Database Engine in C#

https://nockawa.github.io/blog/why-building-database-engine-in-csharp/
25•vyrotek•1h ago•6 comments
Open in hackernews

Booting the RP2350 from UART

https://pfister.dev/blog/2025/rp2350-uart-bl.html
89•hugolundin•11mo ago

Comments

vardump•11mo ago
One could also send a binary stub that sets up fast CPU clock speed and decompresses the rest of the firmware at the RP2350 side. Should be even faster.

Just like old C64 decrunchers and Amiga PowerPacker. Or Fabrice Bellard's LZEXE. (Is there anything that guy did NOT write?!)

duskwuff•11mo ago
In principle, you could boot the RP2040 over SWD. It'd be much more difficult to code, but the possibility is there...
flyingcircus3•11mo ago
Are you implying the SWD signals would send the RAM contents every time? If I had to do that, I would first use a logic analyzer like Saleae to capture the SWD signals of a JLink performing the necessary operations to load the image into RAM. Then figure out, from the bytes that get send and received, whatever needs to be parameterized, and where to put the image data itself, perhaps by capturing different scenarios, and seeing what changes. Maybe even look up the SWD spec. You would also need to figure out what kind of back and forth is necessary, what must block waiting for a response. From there, assuming there isn't cryptography involved, it just becomes a matter of providing bytes to a bus in the correct order or timing based on the proper events. Some of those bytes are "canned" and never change. Some of them are parameters that describe some important quantity relevant your specific image. And the rest are your firmware image, probably chunked up with some overhead wrapped around it. I allow for the possibility that SWD is far more complex than I imagine, but this approach works pretty well for figuring out whats going on with SPI or I2C or BLE.
duskwuff•11mo ago
SWD and the associated debug interfaces are all documented by ARM; there's no need to reverse-engineer anything here. See the ADIv5 documentation [1] for a starter.

[1]: https://developer.arm.com/documentation/ihi0031/a

dmitrygr•11mo ago
ADIv6 for RP2350 (!important)
bsder•11mo ago
> I allow for the possibility that SWD is far more complex than I imagine, but this approach works pretty well for figuring out whats going on with SPI or I2C or BLE.

SWD is pretty well documented. I won't claim its simple, but, in my opinion, it's decent at what it does. The RISC-V folks haven't seemed to be able to do better (and, IMO, did quite a bit worse in a few places, actually).

The SWD description at the packet/command level: https://arm-software.github.io/CMSIS-DAP/latest/index.html

There is open source code directly from ARM for it: https://github.com/ARMmbed/DAPLink/tree/main/source/daplink/...

The documentation of the actual wire protocol is also extensive, but a little more scattered: https://developer.arm.com/documentation/ihi0031/a?lang=en https://community.nxp.com/pwmxy87654/attachments/pwmxy87654/...

The big problem with the SWD wire protocol ARM documentation (and everybody who copies it) is that they don't point out the fact that when you go from Write-to-Read the active edge of the clock changes. In SPI-speak, you switch from CPHA=1 to CPHA=0. This makes sense if you stop to think about it for a moment because during debug there is no clock. Consequently, SWD must provide the clock and you switch from "put something on DATA a half phase early->pulse clock to make chip do something with it" to "pulse clock which makes chip put something on Data->read it a half phase later". However, if it has never been pointed out to you before, it's likely to trip you up.

Sigrok (or similar) which can decode SWD properly and a digital signal analyzer (even a cheap $10 one) are your friends.

The only diagrams which seem to resemble scope traces that point this out are on obscure Chinese engineering blogs.

jdbxbdjehe•11mo ago
This is completely unnecessary since SWD is both trivial as well as well documented
duskwuff•11mo ago
Well... I wouldn't call it "trivial". But it is documented.
gadgetoid•11mo ago
We (Pimoroni) actually shipped this technique in PicoVision, used to load the “GPU” firmware (an RP2040 used to offload the HDMI signal generation) at runtime-

https://github.com/pimoroni/picovision/blob/main/drivers/dv_...

no_time•11mo ago
What are the advantages of doing this instead booting it through UART? Speed perhaps?
vardump•11mo ago
I think RP2040 does not support UART booting.
gadgetoid•11mo ago
In theory you wouldn’t even need to load firmware- you could just manipulate the relevant registers directly over SWD for the silliest IO expander.

In our case it was the only choice. I’d say we’d use UART now but the RP2350 can pretty much do it all in one chip.

mschuster91•11mo ago
There's nothing speaking "version 1.0" more than a bunch of stuff just manually soldered as piggyback over other components of the board :D

Thanks for the writeup.

mrheosuper•11mo ago
this is also how some BLE controller boot.
kees99•11mo ago
Some wifi controllers can also boot like that. In particular ESP8089 chip that shipped with some android tablets circa 2012-2014.

Later, Espressif took that chip, modified bootrom to be able to boot from an SPI flash as well, and marketed that variant as "ESP8266". Serial bootloader was kept as a debug/programming interface, and that was inherited to ESP32 and later chips. All of which can boot directly from serial.

bluehex•11mo ago
This is awesome. I've had similar ideas but wasn't able to do any prototyping yet as I only have Pico 2 boards that don't expose the CSn pin in the pinout.

Rather than UART booting every time I thought it might be nice to use UART Boot just as a way to deliver the firmware update to the sub chip - so the UART image you load would just be a program that accepts a larger image (over UART again) and would write to the flash for subsequent boots. I think that would get around the SRAM and boot time downsides the author mentioned. Is there a reason this might not work?

vardump•11mo ago
That requires having a flash chip in the first place. By booting via UART you don't need any flash at all.
zoobab•11mo ago
The CH32V003 has also a UART bootloader, but for some reason there is no open source command line client to do something with it. WCH has a Windows GUI though.
devdri•11mo ago
This is one of the tricks to enable using both QSPI slots for PSRAM instead of the typical FLASH+PSRAM.

This is great for making audio modules, where the firmware is be small and operates on a big audio buffer. Since the biggest available PSRAM chips are 8MB, this combined 16 MB could hold around 3 minutes of mono 16-bit audio, which allows for a very nice multi track looper.

Another way (in case there's no other MCU to help with uart bootstrap) would be to add a logic chip to multiplex the CS line between Flash and the first PSRAM - copy firmware to flash and then switch to using ram.

ThrowawayR2•11mo ago
Are there any off-the-shelf hobbyist boards that expose QSPI CSn (pin 75 on the RP2350B?) and QPI_SD1-3 signals to a header or pin? Doesn't seem like the official Pico 2 or the Adafruit or Pimoroni versions of the Pico 2 expose access to these signals without modifying the board, which most people won't be able to do.
ptorrone•11mo ago
https://www.adafruit.com/product/6000 has the pads for external PSRAM you can connect to the QSPI pins there (pt @ adafruit)