5 ms·

Well, the ARM is literally powered down until the VC4 turns it on. (I've heard that the only reason the ARM is there at all is that Broadcom had a royalty-free

Well, the ARM is literally powered down until the VC4 turns it on. (I've heard that the only reason the ARM is there at all is that Broadcom had a royalty-free license and there was some spare silicon, so they thought, hey, why not, it might be useful...) Traditionally ARMs have never used any kind of common boot process because they come out of the embedded world where every system is bespoke --- the focus is always on individual products, rather than building a platform. There have been various efforts to fix this but AFAIAA they've never come to much. I think the current one is DeviceTree, but I don't believe there's much vendor support.

geon 10y ago
> there was some spare silicon I don't think such a thing exists. Aren't dies made as small as possible to increase yield? I know the Cell processor in the ps3 had a spare spe core to significantly increase yield.
- bronson 10y ago
  Chip layout/floorplan isn't like laying tiles. Not everything is gridded and fits together perfectly.
geon 10y ago
> there was some spare silicon I don't think such a thing exists. Aren't dies made as small as possible to increase yield? I know the Cell processor in the ps3 had a spare spe core to significantly increase yield.
pjc50 10y ago
The VC4 was intended for use in set-top-boxes or TVs, where the ARM would run a regular lightweight OS to drive the UI menus and the VC4 would do the video decoding, and compose the UI onto the video. It's not an accident, but it is a second-class citizen. It was also clearly intended for possible use in mobile phones, as some of the patent diagrams have "baseband" on them: https://github.com/hermanhermitage/videocoreiv/wiki/VideoCore-IV---BCM2835-Overview https://github.com/hermanhermitage/videocoreiv/wiki/VideoCor...
yalogin 10y ago
> Traditionally ARMs have never used any kind of common boot process because they come out of the embedded world where every system is bespoke --- the focus is always on individual products, rather than building a platform. This is something I did not know. In the mobile world the boot happens in the UEFI mould right? So when someone licenses from ARM they get to design their own boot sequence?
- pjc50 10y ago
  Mobile doesn't have UEFI either. Usually what happens is the processor has some minimal boot ROM that can initialise the Flash (and enforce signed boot!), and then it just loads a chunk of Flash into RAM and jumps to it.
- nanolith 10y ago
  Well, it's two different use cases. PCs are platforms, and they have common components and optional peripherals. Embedded systems are completely custom designs that rarely have common components. Everything is driven by BOM cost, and if you don't need something, you don't add it. Booting such a system is highly dependent upon the board configuration and the peripherals that are needed. Furthermore, vendors have different boot-up requirements. Some boot loaders perform proprietary system checks before loading the RTOS. Some boot loaders need to be able to upgrade firmware from an image on-chip, in flash, or fed into it over SPI or a UART. Some boot loaders are little more than a jump table decoder that just jumps to the currently active firmware image on the chip. Creating a universal boot loader with enough flexibility for each of these situations is harder than just implementing a boot loader for a particular electronics product or product family.
  - david-given 10y ago
    There's a bit of a trend to embed a tiny ROM in the processor itself that's got just enough intelligence to bootstrap an image off various peripherals. The Broadcom parts work like this for the VC4; the boot ROM can talk to an SD card, parse a FAT filesystem, and load and run the second-stage loader (bootcode.bin). But Allwinner chips do this too, and they're even smart enough to try several different media types (including SATA, IIRC!). Ditto Tegra parts. I imagine that if you're a major customer you get to choose the contents of the boot ROM. From a hacker perspective, it's brilliant, because the devices are completely unbrickable. It doesn't matter how broken they get, you can't change the ROM, which means that you always have ability to get something working. But, of course, they all have entirely different APIs. The VC4 just dumps an image into memory, sets a couple of registers, and jumps to it, and I imagine the others all do the same thing.

geon 10y ago

> there was some spare silicon I don't think such a thing exists. Aren't dies made as small as possible to increase yield? I know the Cell processor in the ps3 had a spare spe core to significantly increase yield.

bronson 10y ago
Chip layout/floorplan isn't like laying tiles. Not everything is gridded and fits together perfectly.

geon 10y ago

pjc50 10y ago

The VC4 was intended for use in set-top-boxes or TVs, where the ARM would run a regular lightweight OS to drive the UI menus and the VC4 would do the video decoding, and compose the UI onto the video. It's not an accident, but it is a second-class citizen. It was also clearly intended for possible use in mobile phones, as some of the patent diagrams have "baseband" on them: https://github.com/hermanhermitage/videocoreiv/wiki/VideoCore-IV---BCM2835-Overview https://github.com/hermanhermitage/videocoreiv/wiki/VideoCor...

yalogin 10y ago

> Traditionally ARMs have never used any kind of common boot process because they come out of the embedded world where every system is bespoke --- the focus is always on individual products, rather than building a platform. This is something I did not know. In the mobile world the boot happens in the UEFI mould right? So when someone licenses from ARM they get to design their own boot sequence?

pjc50 10y ago
Mobile doesn't have UEFI either. Usually what happens is the processor has some minimal boot ROM that can initialise the Flash (and enforce signed boot!), and then it just loads a chunk of Flash into RAM and jumps to it.
nanolith 10y ago
Well, it's two different use cases. PCs are platforms, and they have common components and optional peripherals. Embedded systems are completely custom designs that rarely have common components. Everything is driven by BOM cost, and if you don't need something, you don't add it. Booting such a system is highly dependent upon the board configuration and the peripherals that are needed. Furthermore, vendors have different boot-up requirements. Some boot loaders perform proprietary system checks before loading the RTOS. Some boot loaders need to be able to upgrade firmware from an image on-chip, in flash, or fed into it over SPI or a UART. Some boot loaders are little more than a jump table decoder that just jumps to the currently active firmware image on the chip. Creating a universal boot loader with enough flexibility for each of these situations is harder than just implementing a boot loader for a particular electronics product or product family.
- david-given 10y ago
  There's a bit of a trend to embed a tiny ROM in the processor itself that's got just enough intelligence to bootstrap an image off various peripherals. The Broadcom parts work like this for the VC4; the boot ROM can talk to an SD card, parse a FAT filesystem, and load and run the second-stage loader (bootcode.bin). But Allwinner chips do this too, and they're even smart enough to try several different media types (including SATA, IIRC!). Ditto Tegra parts. I imagine that if you're a major customer you get to choose the contents of the boot ROM. From a hacker perspective, it's brilliant, because the devices are completely unbrickable. It doesn't matter how broken they get, you can't change the ROM, which means that you always have ability to get something working. But, of course, they all have entirely different APIs. The VC4 just dumps an image into memory, sets a couple of registers, and jumps to it, and I imagine the others all do the same thing.