HN user
Cortex-M33 timings aren't documented, but one of our security consultants has made a lot of progress reverse engineering them to support his work on trace stacking for differential power analysis of our AES implementation. I've asked him to write this up to go in a future rev of the datasheet.
No official 48 GPIO board, I think: this is slightly intentional because it creates market space for our partners to do something.
It's a fair comment. Give our VSCode extension a go: the aspiration is to provide uniform developer experience across Linux, Windows, and MacOS.
Yes, several approaches. More here: https://x.com/ghidraninja/status/1821570157933912462
Signed boot. Unless someone at DEF CON wins our $10k bounty of course.
Significant improvements to flat-out power (switcher vs LDO) and to idle power (low quiescent current LDO for retention). Still not a coin-cell device, but heading in the right direction.
Thank you. It's been a major effort from the team, and I'm very proud of what they've accomplished.
It's actually 10 masters (I+D for 4 cores + DMA read + DMA write) versus 6 masters. Or you could pre-arbitrate each pair of I and each pair of D ports. But even there the timing impact is unpalatable.
That's correct. The Arm and RISC-V cores are entirely separate, sharing no logic.
We did look at this, but the AHB A-phase cost of putting a true arbiter (rather than a static mux) on each fabric port was excessive. Also, there's a surprising amount of impact elsewhere in the system design (esp debug).
It has: you can encrypt your code, store a decryption key in OTP, and decrypt into RAM. Or if your code is small and unchanging enough, store it directly in OTP.
It's aliiiiiive!
It is true ROM.
As did Graham Sanderson, whose Easter egg this is.
It is. Both from (https://direct.raspberrypi.com), and from various disties. Just shy of 300ku on hand at Farnell today (https://uk.farnell.com/search?st=rp2040).
No - the Model A is still 256MB.
And an additional 256MB (512MB versus 256MB for the Model A).
That's not correct. The code that's been released is for BCM21553, which doesn't have a VPU. There are bits and pieces of VPU assembler in there, but they're unused on the ARM target. The intention is that people port this (ARM-based) drop to run on the ARM on BCM2835. No reverse engineering required.
You're most welcome. Good times.
Figured you'd get a kick out of this release. Should be enough for people to figure out how Andrew's FFT code works.
The ability to boot a kernel with USB (and thus Ethernet) running. Probably not display in the first instance (we're hella-resource-constrained), but we'd want to add that later on.
Fancy meeting you here :)
BSD-like licenses seem to be the standard for userland graphics libraries. There's a lot of useful stuff in there (for example the shader compiler) that may be of general use elsewhere, and we wanted to make sure people could use it.
The 3-clause BSD is a compromise - we're happy for the stuff to be used but it's nice to get some credit :)
Fingers crossed. I'm most excited about the GPGPU stuff people will be able to do now we've documented the instruction set for the QPU. More on this next week.
:)
I did work on it directly. James (now working solely for Pi as HW director), Gordon (now working solely for Pi as SW director) and I (still working for Broadcom, and for Pi) were members of the VideoCore IV design team. James and I were responsible for the QPU (quad processor unit) design and implementation in the V3D block.
There's no one thing about V3D which makes it superior to other cores. Just lots of attention to detail at the design, RTL implementation and layout stages.
More a moral victory from my PoV. Remember, code that runs in the blob is running on another processor, so not costing you ARM cycles. That's why we've set the Quake fps target much lower than what you can hit with the blob.
Good point. Still hard for me to remember that mobile != ARM these days.
Less than you'd think. Other vendors have improved somewhat, but from often from pretty poor starting points. Jumping a process node is a "brute force" approach: we can all do that. I'm more interested in apples-to-apples comparisons on a given node.
Not quite yet. We're hoping to be able to provide a minimum-functionality blobless world fairly soon.