21–30 of 62 posts
While a port has been discussed, I don't think a port has been completed.
Earlier quoted context omitted.
> The Raspberry Pi is really a VideoCore IV processor with an ARM bolted on the side. I knew that the bootloader worked that way but didn't think of it being that way until reading your comment. Interesting to think of the hierarchy that way. Naively this makes me think that the ARM ISA could use something like UEFI (or BIOS) to unify the devices' bootstrapping logic around some common metaphor.
The ARM world is rapidly moving towards UEFI, partly thanks to Microsoft insisting there be something like it for them to build on. Even better, u-boot implements enough of it to boot a UEFI operating system. So on some new devices you'll get UEFI firmware, on everything else you can flash u-boot with UEFI support... and it's now part of their default configs. Pretty cool. :-)
Hope it isn't another quirky "just enough to boot windows, with other OSs having to clone windows behaviour to work" thing.
Can secure boot be disabled on ARM?
Earlier quoted context omitted.
Intel GPUs require neither a blob nor reverse engineering, so ironically the Minnowboard ( http://wiki.minnowboard.org/MinnowBoard_Wiki_Home ; current revision is "Minnowboard Turbot") is very open (also the UEFI implementation (TianaCore) is open source; just a small FSP (Firmware Support Package) by Intel containing binary data has to be compiled in - as far as I know it contains no suspicious data; start at https:…
Looks like this Minnowboard is costly... looks like it cost about 200 dollars. :-/
The SABRE Lite i.MX 6Quad has a similar price: On
> http://uk.farnell.com/nxp/mcimx6q-sl/i-mx6-quad-sabre-lite-d...
it costs £114.29 (about $140), on Mouser it is even $189.95.
Earlier quoted context omitted.
The ARM world is rapidly moving towards UEFI, partly thanks to Microsoft insisting there be something like it for them to build on. Even better, u-boot implements enough of it to boot a UEFI operating system. So on some new devices you'll get UEFI firmware, on everything else you can flash u-boot with UEFI support... and it's now part of their default configs. Pretty cool. :-)
>The ARM world is rapidly moving towards UEFI, partly thanks to Microsoft insisting there be something like it for them to build on. Hope it isn't another quirky "just enough to boot windows, with other OSs having to clone windows behaviour to work" thing. Can secure boot be disabled on ARM?
The property whether it can be disabled depends on the concrete UEFI implementation.
What can one do with it? Is it like a bootloader? Sorry really not enough know-how.
The Raspberry Pi is really a VideoCore IV processor with an ARM bolted on the side. At power on, a boot ROM loads an embedded OS image into the VC4 processor. That then sets up the hardware, powers up the ARM, and loads the OS image into that . The VC4 then continues running in the background servicing RPCs from the ARM. What this is is a replacement VC4 operating system image which just fires up the ARM with an embe…
Earlier quoted context omitted.
The Raspberry Pi is really a VideoCore IV processor with an ARM bolted on the side. At power on, a boot ROM loads an embedded OS image into the VC4 processor. That then sets up the hardware, powers up the ARM, and loads the OS image into that . The VC4 then continues running in the background servicing RPCs from the ARM. What this is is a replacement VC4 operating system image which just fires up the ARM with an embe…
I read through the wiki page for videocore but still did not get a complete picture of what this is. Is it a GPU? If its a GPU or something that specializes in processing video/audio why is it in charge of the boot process? Doesn't it usually happen the other way around, the boot ROM loads the host OS which in turn initializes the other firmware?
https://github.com/hermanhermitage/videocoreiv/wiki/VideoCor...
In particular we are talking about "Scalar/Vector (VPU)" "Dual Core VideoCore IV® Multimedia Co-Processor" (Figure 3B). As far as I understand, that's the thing that boots the device and usually runs ThreadX OS in the closed-source bootloader. The VPU is a dual core processor with scalar and integer vector instructions.
The VPU is more-or-less independent of the GPU, although I'm not sure whether the VPU gets involved with some GPU scheduling tasks.
The GPU has four "QPU" QuadProcessor pipelines, which from memory can do floating-point vector processing.
Earlier quoted context omitted.
> The Raspberry Pi is really a VideoCore IV processor with an ARM bolted on the side. I knew that the bootloader worked that way but didn't think of it being that way until reading your comment. Interesting to think of the hierarchy that way. Naively this makes me think that the ARM ISA could use something like UEFI (or BIOS) to unify the devices' bootstrapping logic around some common metaphor.
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…
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/VideoCor...
Earlier quoted context omitted.
> The Raspberry Pi is really a VideoCore IV processor with an ARM bolted on the side. I knew that the bootloader worked that way but didn't think of it being that way until reading your comment. Interesting to think of the hierarchy that way. Naively this makes me think that the ARM ISA could use something like UEFI (or BIOS) to unify the devices' bootstrapping logic around some common metaphor.
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…
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?