Raspberry Pi Supply Chain Issues Beginning To Ease Up

[ayumu]

There will be no RISC-V main series Pi, only Broadcom for you, forever. Maybe they will throw you a bone with a RISC-V Pico in the future.

Kind reminder that Broadcom is a member of the RISC-V foundation.

[coder]

Kind reminder that Broadcom is a member of the RISC-V foundation.

Interesting, though I think it'd probably be hard to find a decent-sized chip company that isn't. Have they announced or introduced any products that use RISC-V cores?

[jaxa]

Agreed. The Pi is like a Swiss Army Knife. Its strength is in its versatility, but it can't be all things to all people. If you need to do anything serious, you really want a more purpose-built tool. Furthermore, the Pi's port layout really isn't ideal for a mini-desktop.

It could become more things to more people with each new generation, as the performance required to have a good desktop experience is almost a non-moving target. They also continue to sell older models, the smaller form factors, and now cheaper, low-RAM models.

If they maintain the $35 base price for Pi5, then there's nothing to worry about. If they do something like raise it to $50, but point to the Pi4 still being manufactured and sold at $35, then they'll have made a big change to their strategy. They can argue that users who don't need a desktop are still well-served by Pi4 with 1-2 GB, Pi4A if they end up making one, Pi Zero, or Pico.

[coder]

It could become more things to more people with each new generation, as the performance required to have a good desktop experience is almost a non-moving target. They also continue to sell older models, the smaller form factors, and now cheaper, low-RAM models.

If they maintain the $35 base price for Pi5, then there's nothing to worry about. If they do something like raise it to $50, but point to the Pi4 still being manufactured and sold at $35, then they'll have made a big change to their strategy. They can argue that users who don't need a desktop are still well-served by Pi4 with 1-2 GB, Pi4A if they end up making one, Pi Zero, or Pico.

They have a 10-year support window, if I'm not mistaken. That means the original Pi should be dropping off in not too long. The support window is also something to keep in mind, if/when deciding to keep selling a previous generation.

As for "good desktop performance", they need to address GPU performance. It's still hardly better than llvmpipe, in my experience. I know they're thinking about AI acceleration, and I dearly hope they address it via beefing up the GPU, rather than adding a purpose-built hardware block.

[BrokenAnsible]

I have a Pi3 B model for a super famicon-like case but I have a Pine64 Quartz64 Model A 8gb version I am waiting to dig into when I get some tinker time. I wanted badly to get the Pi 4 CM4 cluster going with one of those neat 4x ITX/mATX boards but the CM4 is in such high demand the price is insane. Even the Pine64 knockoff CM's using Rock chips are kinda high in price and there is no guarantee they will 'just work' with the motherboard.

Of all things hit by supply chain... these 'hobby' boards have suffered a lot.

[coder]

I wanted badly to get the Pi 4 CM4 cluster going with one of those neat 4x ITX/mATX boards but the CM4 is in such high demand the price is insane.

Why?

You can get up to 16x A72 cores in systems from Solid Run:

https://www.solid-run.com/embedded-n...specifications

[Xake]

I have a Rock64 with a RK3328 and I would say it's quite well supported by mainline. In general I feel pine64 is doing a great job to gather community efforts to mainline as much as possible of their boards.
Mostly you are screwed if you want to use gpu acceleration, but this is not my use case normally

What operating system are you running?
Have you actually tried doing any real networking on them (more then "connect to network, and internet, no more advanced")?

Why I ask is because I have three of them, and tried running them headless.
And they have one glaring problem for me: the MAC-address.
The MAC-address of the internal NIC is supposed to be generated to something machine-uniq set from the CPU-ID in the efuse.
There is code in the main line linux kernel to read this efuse [1]. However how the mainline boot-chain is supposed to do this is by having u-boot reading the efuse, generate the mac, and then handover to the linux-kernel. However mainline u-boot that for example Fedora uses and most other distros use by default do only have code to read the efuse from a rk3399. No code for rk3328. [2]
And last time I tried to boot the main line kernel from rockchips u-boot fork it failed due to main line kernel needing some things their fork failed to provide.

This results in me only being able to use these cards if I manually set a MAC-address in the env for u-boot during boot. If I do not they often get colliding MACs with all the fun stuff that is related.

That, or use a fully customer boot-chain which is not really mainline.

[1] https://git.kernel.org/pub/scm/linux...ckchip-efuse.c
[2] https://source.denx.de/u-boot/u-boot...ckchip-efuse.c

[Kabbone]

What operating system are you running?
Have you actually tried doing any real networking on them (more then "connect to network, and internet, no more advanced")?

Why I ask is because I have three of them, and tried running them headless.
And they have one glaring problem for me: the MAC-address.
The MAC-address of the internal NIC is supposed to be generated to something machine-uniq set from the CPU-ID in the efuse.
There is code in the main line linux kernel to read this efuse [1]. However how the mainline boot-chain is supposed to do this is by having u-boot reading the efuse, generate the mac, and then handover to the linux-kernel. However mainline u-boot that for example Fedora uses and most other distros use by default do only have code to read the efuse from a rk3399. No code for rk3328. [2]
And last time I tried to boot the main line kernel from rockchips u-boot fork it failed due to main line kernel needing some things their fork failed to provide.

This results in me only being able to use these cards if I manually set a MAC-address in the env for u-boot during boot. If I do not they often get colliding MACs with all the fun stuff that is related.

That, or use a fully customer boot-chain which is not really mainline.

[1] https://git.kernel.org/pub/scm/linux...ckchip-efuse.c
[2] https://source.denx.de/u-boot/u-boot...ckchip-efuse.c

I was running it headless with Archlinux for some time. There was LDAP, Postgresql or HAProxy running on it, can't really remember. I didn't use it for a year or so, but got it out again for something small I want to look into.
I was compiling the u-boot myself [1]. I had to go this route in the first place because I have one of the faulty v2 boards struggling with memory speed, so I had to lower it to become stable. In the end I upstreamed my version (except the memory clock change) to Arch, so I guess they still use it in the repos, but it fired of a bit of a discussion because people were using the setting of the MAC address which was not possible with mainline u-boot, you need the Rockchip bootloader for that. So my guess was (without looking in the source code) that this picked up the MAC from e-fuse.
Like I said this was already some time ago, seems like 2 years according to the commits in my repo and this was basically the first time I looked into u-boot so there is a possibility I picked up stuff wrong.

[1] https://git.kabtop.de/kabbone/rock64

[Xake]

In general I feel pine64 is doing a great job to gather community efforts to mainline as much as possible of their boards.

I was compiling the u-boot myself [1]. I had to go this route in the first place because I have one of the faulty v2 boards struggling with memory speed, so I had to lower it to become stable.

Having to compile your own version of uboot because pine64 has not upstreamed anything that identifies what boards are buggy and handling this is not a great job in mainlineing stuff.

In the end I upstreamed my version (except the memory clock change) to Arch,

Arch is not uboot upstream. It is a distribution. One of many.

so I guess they still use it in the repos, but it fired of a bit of a discussion because people were using the setting of the MAC address which was not possible with mainline u-boot, you need the Rockchip bootloader for that. So my guess was (without looking in the source code) that this picked up the MAC from e-fuse.

It did not. mainline uboot has never had the patches needed to read the e-fuse. You can find it in rockchips uboot repos, however that repo is more lined towards getting all their hardware supported and booting older android or a kernel as old as the ASOP is based on, and with whatever a developer might be able to tinker into something that can boot userland. As such not much in that repo is rebased against something newer then uboot 2017. Which fails to boot many distros based on more modern mainline kernels.
And neither pine64 nor rockchip has made much effort to make sure these patches for systems like rock64 is mainlined into uboot.

Like I said this was already some time ago, seems like 2 years according to the commits in my repo and this was basically the first time I looked into u-boot so there is a possibility I picked up stuff wrong.

Yeah, I had already given up on having to patch uboot by then, and more or less moved the things I cared about to rasberry pis as that meant I did not have to place as much time on patching, rebuilding and tinkering.
That is fun sometimes. But sometimes the things I want to tinker more with is what is running in my docker/k8s-hosts, and be able to update running operating system without it taking a weekend of tinkering so they boot and do not all get the same MAC-address.

I would love if it actually worked good on the rock64. To be able to place the boot-loader into the SPI and use it as a kind of BIOS would be great for USB-boot or netboot.
Just connected one of my rock64 for the first time in a year and tried to boot it with Fedora37, and noticed that they do not seem to even yet have fixed so mainline uboot can detect and boot from the USB-connected SSD I just tried with (tried both USB2 and USB3). If I place uboot and "/boot" on a sd-card, and let it then mount root from the USB-connected SSD it works fine. But yeah, more thing not correctly mainlined and more stuff that "just works" ^TM with my raspberry PI 4 placed next to it.


So I disagree with your original statement still.

[Kabbone]

Having to compile your own version of uboot because pine64 has not upstreamed anything that identifies what boards are buggy and handling this is not a great job in mainlineing stuff.

I bought a used one back then so it was hard to tell if it's vaulty since shipment or the pre owner did something sketchy. There was already a version with 333MHz clock speed (also rockchip already had one of this versions) which runs fine on these boards, but I didn't want to settle on this low speed so I tested what it can do.

Arch is not uboot upstream. It is a distribution. One of many.

I didn't say I upstreamed to uboot, because I didn't make any chances to the upstream code, only changed the frequency for my case. What I upstreamed to Arch was the packaging, which I changed from the back then used idbloader from rockchip to the u-boot mainlained spl/tpl with atf.

It did not. mainline uboot has never had the patches needed to read the e-fuse. You can find it in rockchips uboot repos, however that repo is more lined towards getting all their hardware supported and booting older android or a kernel as old as the ASOP is based on, and with whatever a developer might be able to tinker into something that can boot userland. As such not much in that repo is rebased against something newer then uboot 2017. Which fails to boot many distros based on more modern mainline kernels.
And neither pine64 nor rockchip has made much effort to make sure these patches for systems like rock64 is mainlined into uboot.

After your message I also looked around a bit in the u-boot code and also couldn't find anything about it, but also didn't understand how it gets the MAC now, since it's not the boot parameter anymore. But the mainlained u-boot was bootable for me on the rock64 and also works with the newer kernels.