cr1901_ has quit [Remote host closed the connection]
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
crabbedhaloablut has joined #rust-embedded
<Noah[m]>
Hmm what was this: LLVM ERROR: Global variable '_ZN9defmt_rtt6handle4NAME17h847705b8836c8cfbE' has an invalid section specifier '.data': mach-o section specifier requires a segment and section separated by a comma. again? :/
<Noah[m]>
h freaking target everytime
<Noah[m]>
but something is still off
<Noah[m]>
I get one million errors ... I selected the proper feature tho
<diondokter[m]>
Yeah I saw. Looks pretty nice but couldn't find a pricetag...
<thejpster[m]>
$60 for 4GB. $80 for 8GB.
<thejpster[m]>
not bad for a quad A76
<diondokter[m]>
Ah ok, similar to the Pi4 then
<thejpster[m]>
Did you ever wonder why the RP2040 was labelled RP2?
<thejpster[m]>
The chiplet on the Pi 5 is the RP1. it's quite late.
<diondokter[m]>
Oh lol
<thejpster[m]>
(also, the next chip you see will be RP3)
<thejpster[m]>
* The I/O controller on the Pi 5 is the RP1. it's quite late.
<thejpster[m]>
two USB 3.0, two USB 2.0, gigabit ethernet, four MIPI lanes, UART, SPI - all on the I/O controller
<thejpster[m]>
The main SoC only has 4-lane PCI-express, and HDMI.
<thejpster[m]>
And the PMIC now has super-capacitor backed RTC. This is pretty neat.
<M9names[m]>
wait, do we get an unbroken pci-e this time?
<thejpster[m]>
I'm sure Jeff will immediately tell us if the BCM2712 has enough BARs to handle GPUs this time. I suspect they made sure Broadcom fixed it.
<thejpster[m]>
The Pi 5 has an FFC PCI-e connector, and there's a hat to convert it to M.2. So I expect much PCI-e shenanigans.
<K900>
I'm just hoping this makes RK3588 boards to drop in price
<K900>
(or someone to pick up Orange Pi 5 support in mainline)
lightningwright has quit [Ping timeout: 255 seconds]
lightningwright has joined #rust-embedded
<K900>
The Pi5 specs are OK, but there's going to be the weird bootchain, the vendor kernels, the honestly depressing amounts of I/O compared to competition
<K900>
Like seriously they have one lane of PCIe 2.0 in the year of our lord 2023 and they're selling it as a breakthrough feature
<K900>
Come on
<JamesMunns[m]>
¯\_(ツ)_/¯ it's maintained much better/longer than any low cost sbc, it has an ecosystem, and despite supply issues, it's generally available for a reasonable amount of time
<K900>
I'm mostly looking at it from a distro maintainer PoV
<JamesMunns[m]>
It's not the best in every category, but it seems to have picked a constellation of strengths that have made it popular. it certainly could be better in many categories, but no one else has found a constellation of strengths that have made it more popular
<K900>
So my concerns are more with "how annoying will it be to support", and the answer seems to be "very, again"
<K900>
The long support lifetime is very nice for actually-embedded use cases
<K900>
But less so for cheap workstation/server ones
<JamesMunns[m]>
The really interesting question is if/when they move on to their own silicon designs, if everything will still be as bizarre and locked down as it is with broadcom parts. no idea how many years/decades that would be tho.
<K900>
I very much hope it won't
<K900>
Also I'm pretty sure that's a definite "when" now, not an "if"
<K900>
They're clearly building up to a full SoC
<K900>
What is unfortunately unlikely to change though is their relationship to mainline
<K900>
(or lack thereof)
mburton[m] has joined #rust-embedded
<mburton[m]>
Does it make sense to cut a l-e-h 0.4.0-alpha.4 release?
<thejpster[m]>
<K900> "The Pi5 specs are OK, but there..." <- They just spent $15m making a new PCI-express Southbridge. What I/O do you wish it had?
<thejpster[m]>
And their Linux kernel is fully open source without any blobs (AFAIK). And since getting off VC4 they've done a decent job of moving stuff off the VPU and on to the CPU (and the BCM2835 is 95% VPU/GPU and about 5% ARM11 so that's just historic baggage). Hell this one will boot off NVMe.
ErlandLewin[m] has joined #rust-embedded
<ErlandLewin[m]>
Centronics parallell port?
<ErlandLewin[m]>
Neuralink
<K900>
<thejpster[m]> "They just spent $15m making a..." <- More PCIe lanes would be nice (and yes, I know the SoC doesn't have those), USB-C with DP alt mode is also pretty standard for SBCs these days
<K900>
Their kernel is open source, but it's also a giant pile of patches, many of which have been explicitly rejected in mainline
<K900>
And they don't seem particularly interested in upstreaming their changes in the first place, which is not great for long term distro support
<K900>
The boot chain still requires (most of) the firmware to be on the external storage, as far as I can tell, and still relies on weird config.txt stuff that affects who knows what and mostly only applies to vendor flavored device trees
<K900>
And is proprietary up to the kernel
brazuca has joined #rust-embedded
<K900>
Though you can at least inject uboot, which breaks about a third of config.txt settings because uboot usually brings its own device trees
<K900>
And in fact already has special cased code to copy firmware-applied fixups from the platform DT to the final one because they don't use the standard one
<thejpster[m]>
if pi's used u-boot natively and I had to edit U-boot environment variables to change stuff, I don't think that would be an improvement.
<K900>
I would say something about UEFI but honestly that's an issue with all vendors currently
<K900>
But yes, having more onboard firmware would allow for things like a proper settings UI
<K900>
Or you just offload all of that to the DT and have some tooling to add overlays from the OS, which is something other vendors have done before
<thejpster[m]>
And given my wife's Pixel 4a ended updates after 3 years (and before she'd finished paying for the damned thing), but I can still boot today's Pi OS on a Raspberry Pi B from 2012, I'm fine with their approach
<K900>
(and even the RPi can kinda do with EDK2)
<K900>
thejpster[m]: It's fine if you treat it as a closed vendor ecosystem
<K900>
Like, as long as you run Raspbian, you'll be fine
<K900>
My perspective is that of a person who has to deal with their shenanigans in a non-Raspbian distro, and somehow reconcile them with however many other vendors we're trying to remain decently generic over at the moment
<K900>
It's definitely a much smoother experience if you treat it as a complete package and not as a general purpose computer
<K900>
But I think it's unfortunate that they are in position to make things a lot less painful for people that do choose to run other distros, or even other operating systems entirely, and they just... don't, generally
starblue has joined #rust-embedded
brazuca has quit [Quit: Client closed]
jessebraham[m] has quit [Quit: Idle timeout reached: 172800s]
andodeki2[m] has quit [Quit: Idle timeout reached: 172800s]
<thejpster[m]>
I think it's going to get worse
<thejpster[m]>
Pretty sure I read "Raspberry Pi OS 12 will be the only supported first-party OS"
<thejpster[m]>
> Raspberry Pi OS will launch in mid-October, and will be the sole supported first-party operating system for Raspberry Pi 5.
<thejpster[m]>
Kinda the Apple approach to OS support
<thejpster[m]>
(except you can't boot Ventura on a 2012 Mac)
<K900>
<thejpster[m]> "> Raspberry Pi OS will launch in..." <- "First-party"
<K900>
That doesn't sound like a change
<K900>
But it also doesn't sound like they're interested in changing the other direction
<K900>
Which, meh
<K900>
At this point I'm mostly just disappointed and would rather work on stuff that's more janky but more open
adamgreig[m] has quit [Quit: Idle timeout reached: 172800s]
mabez[m] has quit [Quit: Idle timeout reached: 172800s]
crabbedhaloablut has quit []
<thejpster[m]>
don't blame you to be honest
<thejpster[m]>
watching an interview with Eben; it's interesting that they didn't really "go back" to the Pi 3 layout of USB and Ethernet - this product sort of pre-dates the Pi 4 and they designed the RP1 I/O chip to have the pins in the right place to do their "normal" board layout. But Pi 4 came along in the interim and forced the USB and ethernet to swap because of the VL805 chip that they bought in.
<K900>
Anyone particularly good at IC sleuthing identified the SPI flash on the Pi5 yet?
<K900>
I'm very curious about the size of that
Guest7221 has left #rust-embedded [Error from remote client]
starblue has joined #rust-embedded
brazuca has joined #rust-embedded
d3zd3z[m] has joined #rust-embedded
<d3zd3z[m]>
Anyone successfully gotten probe-run or probe-rs to work within WSL2. I get an error "Probe could not be created", and strace suggests that the 'recvfrom' on the netlink socket is returning EAGAIN.
<d3zd3z[m]>
It works fine for me on the same board plugged directly into a Linux box, but I don't have the ability to take that box with me while traveling.
<d3zd3z[m]>
And, I'm not sure if that is the actual error, as I don't have the setup with the real machine readily available right now. I suspect something different about the behavior of the usbip device compared to the directly connected usb device.
<d3zd3z[m]>
Oh, and pyocd is able to flash. It doesn't work with rtt, as it seems to just exit if there isn't channel in both directions, but I'm not sure how useful defmt's output would be to a tool that doesn't understand it.
<thejpster[m]>
Do you know why Pi 4 has two USB 3 and two USB 2, even though the VL805 PCI-E to USB chip they use has four USB 3 ports?
<thejpster[m]>
Because they knew RP1 was coming and that it would only have two USB 3 (albeit two full USB3 busses not just ports).
<thejpster[m]>
Do you know why the BCM2711 on the Pi 4 even has a PCI-e lane? To connect to RP1. But the hedged their bets and left the GPIO in the 2711 just in case RP1 was not ready. RP1 was not ready.
brazuca has quit [Quit: Client closed]
brazuca has joined #rust-embedded
IlPalazzo-ojiisa has quit [Quit: Leaving.]
Foxyloxy has quit [Remote host closed the connection]
Foxyloxy has joined #rust-embedded
therealprof[m] has quit [Quit: Idle timeout reached: 172800s]