freedom-fries

The RISC-V implementation on RP2350 does not have any security features - it has no business to be on silicon that was supposed to be marketed for security features, but it is there. Then there are bits to disable ARM and/or RV cores, but disabling the ARM core takes priority over disabling insecure RV core - these are human decisions not architectural.

This isn't about the technology - the organization's priorities are clearly divided between two segments - one that's trying to expand the revenue by expanding into enterprise/commercial market and another that is trying to stick-on cool stuff and prioritizing fun. In this case neither won - the fun guys got kneecapped by the E9 bug making this silicon unusable for hobbyist projects, and the fun stuff kneecapped the enterprise stuff by bypassing the security bit.

(as you can imaging, I'm extremely disappointed with RP2350 - RPi needs to focus or they hobby/maker market is done)

RP2350 was supposed to be a game-changer for the RPi (the corp) and customers alike. It's an immensely powerful, and well documented platform so it's a shame that critical bugs have stolen the thunder. First the E9 errata made me junk the RP2350 for projects where I needed to interface with any kind of tri-state logic and now this one basically shows that extra RISC-V cores are a liability for any security conscious design.

If Rpi wants to rescue RP2350, they must release a new bug-fix stepping soon, or this one is done.

> May be I'm weird, but for me RP2040 was terrible chip for learning ARM. STM32 on the other hand just worked

My experience was opposite of yours. I found RP2040 refreshing compared to the complexity of dealing with proprietary toolchains that other devices required for me to start working with their chips. Nearly every part of RP2040 was documented in great detail and usable exclusively with the tools I could find in Arch Linux repo (when using Linux) and Homebrew (when using Mac). I could drop down to assembly or move up to C++, or even Rust or Python depending on whether I wanted to tool around or just get things done.

Even more impressive was that I was able to use debugger with another RP2040 Pico acting as SWD debug probe (Google Picoprobe) which again worked the same across Mac and Linux with the software I already had (gdb) and saved me from buying yet another piece of JTAG hardware with questionable software support.

Oh, and every single software with RP2040, including UF2 boot-rom, second stage bootloader and examples are on Github, which allowed me to go as deep as I wanted and more importantly, just get on with what I needed to do when I wanted things to just work.

I've worked with uC on and off, but never I have worked with a uC that just worked with just worked with tools I already had. I now work exclusively with RP2040, even when I find other chips much more capable (ESP32 in this case). RP2040 allows me to futz around as long as I want, as deep or shallow as I have time on hand, plus when I stop futzing around, it allows me to just flash new ROM over USB and get on do what I /need/ to do.

Oh.. and I just love the USB mass-storage mode – no more custom flasher tools, just `cp blah.uf2 /mnt/RP2040/` and off I go. I can smoke it, but I can't brick it! Plus, when I need quick iteration I can just use PicoProbe and do `code - flash - debug - code` almost as fast as I can hit keyboard buttons.

RP2040 is a game changer for me!

Contrary opinion: well, we like paying less! We get angry on high prices, swan at deals, and then get mad that businesses want to pay less too!

Something has to give - either the buyers get shafted, or the workers. I don't believe that margins will be the first to get a cut - margins go to the wealthiest of the bunch who're running the show :)

GC pauses are dependent on the code and its workload so general benchmarking is rarely useful. You can have a code that works really nicely with GC at a given throughput and request pattern, but not at all at a different load profile. Minor implementation change can also dramatically alter the GC workload. A generic work-queue, where one thread is enqueuing tasks (allocating memory) and another is consuming them and deallocating memory can make it hard for GC to do its work, while minor changes so that queue is fixed-sized and does not allocate can dramatically change the GC workload.

Even really simple optimizations where the `enqueue` may just copy to its queue-owned buffers can make allocations happen exclusively from TLAB with bump allocation which are essentially no-ops for GC & the allocator. Generic benchmarking happens but is more the domain of GC developers, and not very useful for developers – because usually, your workload is different from mine.

No. Due to spectre and other similar issues, all of them (at least all the sane ones) sell cores, but will count each core as either one "core" or more commonly two "vcpus".

Look at Mr bonuse-pants here. Y'all get bonus for writing software?

> It's been great so far and it's probably the worst full EV you can buy in the US.

You are right and so are the articles. Boring EVs like Nissan built are supremely reliable and cheap to run and inexpensive to repair when they do have issues, but unfortunately that's not the case for everyone else.

EV market is unfortunately dominated by "fancy EV" manufacturers who have loaded the cars with fancy structure and LCD screens everywhere. Teslas and Rivians cost upwards of 10K to repair (Rivian R1T requires 20K+ for repairs for low-speed rear-end) with months long parts backlog for things like rear quarter panels. Rivian recently accidentally bricked 10% of cars on road with a new OTA firmware update while Tesla is involved in several lawsuits over its Autopilot. The story is same with other manufacturers.

We don't yet have a "Toyota" of EV makers who would make a range (Sedan, SUV and a Truck) of great, reliable cars that look nice, are nearly boring to drive and inexpensive to repair.

787 isn't a small plane! 787 is just 11% smaller by wingspan and just 3% smaller range than long-range 747. In large part, 747 and 380 went away because they were fuel-inefficient 4-engine planes, not because airlines wanted to fly tiny planes between LA and NY.

Or high-speed cars. I hate trains.

You can't route MAC because there is no prefix matching - only exact matching. That's exactly why you need to "switch" them... and incidentally this is what your proposal accomplishes – it's equivalent to a fully-switched network. Switches (especially L3 switches) maintain port-MAC association tables to switch packets between ports and they're available off the shelf.

The article is talking code and demonstrating results.

Talk is cheap, show the code!

That's your opinion, but Tesla does not "need" to add anything from the point of view of actual Tesla customers!

Tesla cars are selling faster than they can make them and adding a Radar will slow down the manufacturing, not make it faster.

The thing is – nobody cares!

People can scream bloody murder till the cows come home, but Tesla for all its faults is king of the hill - literally more valuable the rest of the car industry combined. Musk is the invincible and irrespective of any shortcomings he's literally the richest person on Earth.

Tesla's approach is demonstrably the best approach in the court of the customer, irrespective of what we (others on the road) think or are put at risk.