A probably naieve question. If the VPU can be used as the bootstrap loader for the CPU, much as a PDP11 on the door of the Vax 11/780 acted as bootstrap loader for the Vax, can we not simply replace all the complex VPU resident functions with 'just run on the CPU' and then resolve the external device bindings in normal CPU code?
Maybe I misread it, but it read like the VPU does more than the tiny necessary bootstrap to find an image, and chain load it. It reads like it has to do some timing critical initialisations of subsystems, but I cannot but think a CPU should be able to do this for itself, once it has some run state with a kernel in memory.
It's as if the VPU has to make the other bits of blobby hardware be alive, for the CPU to be able to see them. Most odd.
Oftentimes there are magic bits of this to do with ring states, and priviledge to alter ring at runtime. Maybe this is part of the story: the VPU initialises a specific ring state and some outer higher trust ring MUST be pre-initialised for the CPU ring state to be allowed to talk to it: it would violate the ring model, if the CPU did it.
Fun fact, the "ï" in "naïve" is not an umlaut, but a totally different use of the same notation called a diaresis! It's meant to inform the reader that the "a" and "i" are pronounced separately, rather than being combined into a single vowel sound. It's a bit old-fashioned in English, but you sometimes will see it in older texts on words like "coöperation". So "naieve" is not a valid spelling of "naïve" (but that's okay because English spelling has historically been a mess and everyone knew what you meant). https://en.m.wikipedia.org/wiki/Diaeresis_(diacritic)
>It's a bit old-fashioned in English, but you sometimes will see it in older texts on words like "coöperation".
You don't even need to search for older texts! The New Yorker actually uses the diaresis in their print edition. It's certainly a bit anachronistic, but I do think English spelling can be a bit obtuse to say the least, so the orthographic hint can sometimes be useful.
Fun fact: since a relatively recent reform the position of the diaeresis (in french: "tréma") kinda changed (at least for quite a few words). For example in the word "aigue", the diacritic sign can be put either on the 'e' (as used to be the case previously) or the 'u' (which is now recommended but not mandatory: you can still put it on the 'e' instead). So both "aigüe" and "aiguë" are correct AFAICT.
Although I'm a native french speaker TIL, thanks to you, that it's role was to inform that the letters are to be pronounced separately.
The diaeresis is very important in French (we call it tréma). Without this the word naïve instead of "na-iv" would sound "nev". The first name Loïc instead of "lo-ik" would be "looak" (it is even hard to say it loud for me). And many others.
Fortunately we still have the word for waters which is eaux and that we pronounce "o"
It's important in French because French tries very hard to have a consistent mapping between spelling and pronunciation. When you read a word you don't know, the spelling tells you how to pronounce it. English seems to have largely given up on this concept.
Your comment got me thinking, this concept is not obvious for a native French speaker.
So we have several words that are pronounced "unexpectedly" (What You Read Is Not What You Pronounce). An example would be the name if the physicist Louis de Broglie, pronounced [dəbʁɔj]. OK, that's a family name so there is some history behind.
Then we have words that different people pronounce differently: ananas (pineapple) - some pronounce the "s", some do not. Or the village Avoriaz, same but for the "z". Or Chamonix.
But now that I think about this, what you are saying is indeed a thing. My wife's primary languages do not include French and she did not have, I think, major issues when choosing a pronunciation (she had Himalayas of other problems, though).
> Then we have words that different people pronounce differently: ananas (pineapple) - some pronounce the "s", some do not. Or the village Avoriaz, same but for the "z". Or Chamonix.
As someone who is only fluent in English but tried to study French for a couple weeks before visting Paris many years ago... Spoken French has institutionalized mumbling; what I read is you're supposed to form the final consonants of words with your mouth, but not voice them... Which ends up in practice with the consonants being pretty much voiced if the next word starts with a vowel and not if not... But I'm not surprised there's some variance.
The best written reference I could find (which sadly, I can't find again) was from a Hong Kong university where the writers seemed to have learned both English and French analytically rather than natively, so they would explain the rule for French and compare with the rule(s) for English and expose me to the rules I unconciously followed without knowing they existed.
Studying written and spoken French simultaneously was pretty helpful for me, otherwise it was too hard to fill in the ending letters of many words as needed.
Interestingly, all of the Romance languages exhibited consonant-dropping in their development. In Spanish and Italian for example, the Latin ending -us became -o. And even as far back as classical Latin, it is believed that the "m" at the end of a word was often nasalized. Apparently this hasn't been a thing for millennia.
There are other examples that are much worse for French learners! In _fils_ (son) the _l_ is mute, but the _s_ is pronounced. In _août_ (August), tha _a_ is mute. In _tous_ (all, plural) the _s_ can be mute or not, depending on the sentence. And in _oeuf_ (egg) the f is pronounced, but in the plural _oeufs_ it isn't! A special mention to _Monsieur_ (Mister), which is pronounced as if it was written _Messieur_.
It's not ä but æ like in encyclopædia and archæology. British English generally simplified to ae. American English generally simplified to e. Wikipedia page has more info: https://en.wikipedia.org/wiki/%C3%86
If diaeresis is too hard a word to deal with, we can just call it trema.
Just as there was a "slashdot effect", I think we should apply for an "HN Tangent" - the effects being something like whiplash to the brain as the discussion veers off in directions undreamt of.
I'm not aware of the specific details, but one of the usual critical things is clock and PLL configuration. It looks like the PLLs that generate all the internal clock frequencies, including the 48MHz for USB, are connected to the VPU. It may be the case that relevant hardware simply isn't connected to the ARM.
(From Broadcom's point of view, the VPU is the "real" computer with all the processing power, and the ARM is tacked on the side)
This is so true, and so amusing. It almost makes me wonder if the microinstructions of the VPU could be where we run.. and use this ARM chip to do things like AES offload!
Thanks for a very useful observation. Clocking is fundamental to a lot of things, buses like the clock to be done right so I can believe booting requires good clocking and some bus initialisation.
Turns out there is some pretty good architecture documentation: https://docs.broadcom.com/doc/12358545 .. but that only describes the 3D capabilities, not the whole register map.
That doesn't really cover the processor under discussion here, only the shader cores called the QPUs.
This work and the processor under discussion is another core called the VPU that unfortunately gets confused because with the default firmware it runs the majority of the OpenGL driver stack, controlling the QPUs.
> Turns out there is some pretty good architecture documentation: https://docs.broadcom.com/doc/12358545 .. but that only describes the 3D capabilities, not the whole register map.
This documentation is for the VideoCore IV. The BCM2711 SOC that is used in the Raspberry Pi 4 has a VideoCore VI.
Yes, with some conditions. You can boot a very minimal version of Linux without the firmware and get it to work with UART and eMMC. Support for USB, DMA, and Ethernet are in the works, which will be sufficient for certain headless systems. Still, many other peripherals require bringup, such as video. Additionally, drivers for power management need to written.
So it isn't clear if this is code in the kernel, or code blobs still to be run in the VPU, and why.
"drivers" could refer to linux kernel, or the drivers as blob downloads, or VPU initialization.
This is separate code (a fork of the Little Kernel project) that runs on the VPU and loads later stages of the boot process, including initialising the ARM core and running the Linux kernel on it.
IIRC it was just architecture quirk of those chips as initally they were designed as basically fancy accelerators to be used with already existing systems
> VideoCore chips can run complete applications - they are not simply video DSP chips that require a separate processor to supply and collect data. In practice though, they are often used like simple accelerators, as companies usually prefer to cautiously assimilate new technology rather than take a big risk in porting a large amount of application code from an existing ARM-based design.
For example one of earlier ones was used as GPU for Nokia N8
This project focuses on being a drop in replacement to the proprietary firmware needed to bringup Linux on the other processor. (The ARM processor.)
Isn't anyone going to talk about running random stuff on the VPU itself?! Given it's the thing used for 3D and stuff, I imagine it's going to be crazy fast at certain computations, much faster than the ARM is.
Untapped potential of all Raspberry Pies out there... maybe the VPU can be (ab)used to do stuff similar to what the Raspberry Pico can do.
for (int i=0; i<16; i++) { int temp = a[i] * b[i]; if (store) c[i] = temp; if (accumulate) accumulator[i] += temp; }
basically, the VPU can run this entire line of code in just 2 clock cycles, and this isnt even the 3d core, which is entirely seperate and more complex
I encourage anyone who is interested in free boot/other firmware for the RPi to get involved in the project, it is mostly one person at the moment (not me).
Nobody's mentioned it yet, so... One reason this is so difficult is that the VPU runs an entire standalone OS of its own.
AIUI, the VPU is in control of the computer, and the Arm is an accessory device. Only once the VPU has loaded its OS and it's running will the Arm be initialised, the kernel image loaded into RAM by the VPU, and then the Arm pointed at it. The OS continues to run and control the computer even once the Arm is running.
The VPU runs a proprietary RTOS called ThreadX, which is now owned by Microsoft.
Pretty much all Allwinner based SoCs used in common SBCs have FOSS firmware. Some older Rochcip SoCs also do, but you have to be careful there (the most open/fully featured is RK3399). That covers a huge amount of SBCs out there. Some even have multiple alternatives for FOSS firmware.
If anything RPi seems like an outlier. Out of 9 different SBCs models I have at home only Rpi2b and Quartz64-A have proprietary firmware.
The Pine64 guys are working towards that goal I think. You can flash open source firmware on some of their boards, but I don't know if it's the default.
I really hope they can get HDMI up on this because I'm struggling with an incompatibility between my IP KVM and Raspberry Pis. I would really love to dig into the HDMI initialization code.
Something about the HDMI output on a Pi is just absolutely incompatible with the IP KVM's interface modules and it's maddeningly subtle because the Pis work _everywhere_ else.
Maybe I misread it, but it read like the VPU does more than the tiny necessary bootstrap to find an image, and chain load it. It reads like it has to do some timing critical initialisations of subsystems, but I cannot but think a CPU should be able to do this for itself, once it has some run state with a kernel in memory.
It's as if the VPU has to make the other bits of blobby hardware be alive, for the CPU to be able to see them. Most odd.
Oftentimes there are magic bits of this to do with ring states, and priviledge to alter ring at runtime. Maybe this is part of the story: the VPU initialises a specific ring state and some outer higher trust ring MUST be pre-initialised for the CPU ring state to be allowed to talk to it: it would violate the ring model, if the CPU did it.