Andrew Zonenberg / is on Nostr

Security and open source at the hardware/software interface. Embedded sec @ IOActive. Lead dev of ngscopeclient/libscopehal. GHz probe designer. Open source networking hardware. "So others may live"

Toots searchable on tootfinder.

ngscopeclient: https://github.com/ngscopeclient/scopehal-apps
Blog: https://serd.es
Location: Seattle area
GitHub: https://github.com/azonenberg

Last Notes

2024-11-03 13:14:06

- reply

It's going to be ngscopeclient, with a bunch of upgrades for better handling of digital buses.
We already have a whole slew of protocol decode options available and it can happily keep up with multiple Gbps of waveform data. But I often find myself burning expensive analog scope channels to look at fast digital data simply because I don't have anything faster than the MSO channels on my LeCroy and Pico scopes.
I'm looking at building something fast enough to sniff e.g. SGMII or slower DDR3 on each of say 32 channels, and fast enough to sniff even faster stuff (say pcie gen1 or fast DDR3/slower DDR4) on the higher end channels.
With native 50 ohm inputs and the option to use various active probe heads.

2024-08-22 19:10:53

- reply

No, none of my hardware supports it so I've only skimmed documentation.

2024-08-22 18:53:43

- reply

I'm simplifying a bit :)
And USB3 is PCIe at the physical layer, but not the upper layers. USB4 is the obvious next step in further convergent evolution.

2024-08-22 18:51:50

Hypothesis: all short to medium range local buses will eventually converge to become PCIe, Ethernet, or both.
* [S]ATA? Being replaced by NVMe over PCIe
* CAN bus in cars? Being replaced by single pair Ethernet
* USB4 is basically Thunderbolt which is basically PCIe
* Lots of industrial RS485 etc field buses are being replaced with Ethernet
I suspect we're not too far from seeing a new PC monitor interface standard that encapsulates video inside Ethernet frames or PCIe TLPs the way this is headed.
The unification of PCIe and Ethernet is probably further off but isn't entirely implausible.

2024-07-20 21:15:14

- reply

I remember running password crackers on the PS3.
It was tricky even coming from a GPU background, the SPEs were an interesting animal for sure. Easy to make a small screwup and get bad performance.

2024-07-03 02:51:10

- reply

This is how I do all of my embedded stuff, how else would you put them at predictable locations?
For example on the PicoRV32 platform I'm playing with now I have...
volatile APB_GPIO GPIOA __attribute__((section(".gpioa")));
volatile APB_Timer TIM1 __attribute__((section(".tim1")));
volatile APB_UART UART1 __attribute__((section(".uart1")));
and then in the linker script
.sfr (NOLOAD):
{
. = ALIGN(1024);
KEEP(*(.gpioa))
. = ALIGN(1024);
KEEP(*(.tim1))
. = ALIGN(1024);
KEEP(*(.uart1))
. = ALIGN(1024);
KEEP(*(.spi1))
. = ALIGN(1024);
KEEP(*(.count1))
. = ALIGN(1024);
KEEP(*(.count2))
. = ALIGN(1024);
KEEP(*(.devinfo))
} > APB

2024-07-03 02:16:37

Well this was fun to root cause.
Turns out if you try to shrink the size of your firmware by removing unused library functions with -ffunction-sections and -Wl,--gc-sections, and you also have all of your SFRs in their own sections so the linker script can put them in the right place...
... it's very easy to accidentally GC unused SFRs. And if you don't design your linker script to ensure you still have a 1 kB hole in your address space at that location it will happily just put the next SFR there instead.
This will, predictably, lead to hardware getting extremely confused.

2024-07-02 12:01:13

Free product idea: microwave that lets you disable the beep by an obvious, easy-to-find switch with a visible status indicator.
Signed, all the night owls with family that is trying to sleep while they're snacking.

2024-06-21 03:24:45

- reply

Ok, looks like I had maybe blank flash content but the ECC metadata was partially written. Straightforward to just call the block partially written in this situation, fall back, and retry on a new blank flash block.
Where it gets scarier is when you have a half-written block that is malformed to the point of triggering a double ECC fault.
On STM32H735 a double flash ECC fault (sanely) triggers a data bus fault, which can be masked and the status register bit handled by application firmware easily enough.
But on STM32L431 it instead triggers a NMI. Which, by definition, can't be masked.
In order to avoid this forcing my board into a boot loop or hang every time I touch config flash, I need to be able to cleanly recover even in this scenario.
Whiiiich basically is going to involve implementing a SEH-like framework on ARMv7-M that can catch the NMI, return to application code with an error somehow, and cleanly recover.
Dis gon b gud. *rolls up sleeves and opens ARMv7-M architecture manual to study details of exception handling and stack frame unwinding*

2024-06-20 17:06:03

Fixed the first bug the power-loss fuzzer found by adding the header CRC.
Now I'm getting write failures, which I think are the result of it thinking a flash area is blank when it is, in fact, not blank.
Need to figure out what's going on with that next.

2024-06-19 21:49:58

- reply

I've often wondered if we're living through a "new Carboniferous period" because critters that can digest plastics haven't evolved yet.
I expect over e6-e9 year time scales, polymers will gradually break down into shorter and shorter chains and perhaps high concentrations of them, like landfills, will become oil-field-like natural resource reservoirs for whatever species inhabits our planet at that time.
But hopefully on a much shorter time scale recycling will evolve to the point that mining old landfills will become profitable, allowing us to recover some of these old resources for reuse.

2024-04-08 23:22:31

- reply

I'm curious if the UltraScale+ FPGAs I got on aliexpress packaged in BGA tray + paper towel + cling wrap are in decent shape.
Won't know until I spin a board.