Hacker News Reader

Comment by monocasa | Hacker News Reader

Sort of... There's two main architectures in the VideoCore. The QPUs are different than the main VideoCore, and the main videocore (which is also what runs the boot code) isn't really the GPU.

For a long time neither were documented so people just sort of assumed they were the same thing.

View on HN

The original raspberry pi documentation did kind of give people the wrong idea.

The whole block with the VPUs, ISPs, mpeg4 codec and 3d pipeline could be described as a "GPU", and the gpu firmware is the firmware that runs it.

Modern Desktop CPUs also contain a management/security cpu core which runs everything. And that correctly described as GPU firmware, though its commonly called vBIOS.

But the VPUs are so much more than a management processor for the 3d pipeline. They have a huge vector array and can do software encoded/decoding of video up to 480p MPEG2 (videocore 4 added hardware h264 codecs that could do 1080p)

I like to think of the VPUs as multimedia co-processor cores.

The ipod video used the VideoCore 2 as it's gpu. It had an arm SoC as it's main cpu and a separate videocore chip. The videocore handled all display output and video decoding. It has no 3d pipeline, but they wrote an software opengl implementation which runs on the VPU to implement the games.

There are actually a few set-top boxes (and maybe a cellphone) which just just the videocore VPUs the main cpu. It's flexible enough for that.

Well, yes, but changing how the initial boot code works still means changes in the thing we call the "videocore firmware", right?

Yeah, but lots of SoCs have special boot and SoC management cores with a different ISA. The Tegra X1 in the switch uses an ARM7, CortexMs are in vogue in a lot of designs, AMD and Intel have the PSP and ME respectively, and even the SiFive SoCs have a E core that boots the main core complex of U cores.

In none of these cases (including the RPi) is this core the GPU.

Appreciate the clarification, but your paragraph above is exactly what I was getting at. Roughly that "the article is right...ARM booting on dev boards is a crazy world". As crappy as legacy BIOS and UEFI is, booting on x86/x64 is more standardized, despite things like PSP and ME.

The point I'm getting at is that sub cores to boot a main core isn't a crazy world, and you're stuck with the same thing on almost all x86 designs as well.

It's not where you should be looking at if you want to make the ARM booting space any better.

Imho the most important part of the x86 standardization is the IBM pc platform. Arm boards doesn't have an equivalent platform to standardize on, so everybody does their own thing.

BSA and BBR specs from Arm fix that. They also have a certification program https://developer.arm.com/architectures/system-architectures...

I find it unfortunate though that quite a few of the requirements for those standards is "buy more ARM IP blocks" rather than asking defining blocks that can be implemented by others.

It feels like a self defeating cash grab.

There is the device tree[0], which Linux uses to know where all the ports are on an SoC. It’s become the de facto standard for ARM. Even non-Linux OSes like iOS adopted it.

[0]: https://www.kernel.org/doc/html/latest/devicetree/usage-mode...

Interestingly, Apple's use of device tree is older than even ARM's and Linux's. It was part of OpenFirmware and used in almost all of their Macs (and Mac derived lines like iOS) since the PowerMacs gained PCI slots. Even Intel Macs would use device tree internally too, for instance passing the user's password in the FDE unlock screen in the bootloader to the main OS via a DT chosen variable.

Unfortunately this is not common on ARM SBCs, at least not yet, they usually come with a SoC vendor supplied old kernel, and that's about it. And we forgive them, for the sake of low price.

Like Odroid Go Advance, a Rockchip 3326 based "retro handheld", and it's clones, was a tremendous hit of last year, still stuck with a 4.4 kernel.

Reply on news.ycombinator.com