Interesting discussion of open sourced VPU bootloader for Raspberry Pi from CNX
Krista Brooks's GitHub and her blog,,
Actually, the bulk SDRAM/ARM work was done by me in the space of around month (though I only ARM to finally work three days ago with Herman's help).
You could run Linux on ARM using this but you would need to write some more drivers, otherwise you'd be limited to pretty much GPIO/serial/SDHOST PIO.
SDHOST is actually a fairly trivial interface to implement, I'm going to use it in my chainloader but I haven't had the time to look at it yet.
from 6by9
The firmware is more than just the bootloader as it also provides the access to the bits of the SoC that Broadcom have chosen not to publish the docs for - things like the codec blocks, ISP, HVS, pixel valves, etc. Parts of that are being opened up via Eric Anholt's works but only in so far as his driver uses the blocks, but the documentation is not being released AFAIK.
The majority of the firmware code is also copyright Broadcom, so RPF (Raspberry Pi Foundation) can't ride roughshod over the licence they have with Broadcom. That licence is likely to be worded that it is for use in RP products, so in allowing ArduCAM or Hardkernel to use their firmware they would be in breach of their own licence to Broadcom.
Likewise Broadcom couldn't release the RPF modified firmware source to ArduCAM as (a) they don't have it, and (b) they don't hold the copyright to the RPF modifications (of which there are now lots).
Allwinner have created Linux drivers for many of their hardware blocks and therefore they have taken on the support burden of that. I doubt HardKernel or other of the SBC manufacturers using Allwinner chips have had to do any significant development effort beyond board bringup.
Broadcom chose not to create Linux drivers as that was not their main market. RPF took the risk 5 years ago with the chips that they could get hold of, and have stuck with Broadcom since due to their investment and expertise. They could jump ship to Allwinner or other chip manufacturer, but that would be throwing away all that effort, all of the optimisations, and instead potentially picking up support of binary blobs in other kernels.
You're all free to choose to buy an alternative SBC with a less restrictive licence, but you then need to accept the level of support provided by that manufacturer and community.
Krista Brooks's GitHub and her blog,,
raspi-internals and hacker news:Actually, the bulk SDRAM/ARM work was done by me in the space of around month (though I only ARM to finally work three days ago with Herman's help).
You could run Linux on ARM using this but you would need to write some more drivers, otherwise you'd be limited to pretty much GPIO/serial/SDHOST PIO.
SDHOST is actually a fairly trivial interface to implement, I'm going to use it in my chainloader but I haven't had the time to look at it yet.
from 6by9
The firmware is more than just the bootloader as it also provides the access to the bits of the SoC that Broadcom have chosen not to publish the docs for - things like the codec blocks, ISP, HVS, pixel valves, etc. Parts of that are being opened up via Eric Anholt's works but only in so far as his driver uses the blocks, but the documentation is not being released AFAIK.
The majority of the firmware code is also copyright Broadcom, so RPF (Raspberry Pi Foundation) can't ride roughshod over the licence they have with Broadcom. That licence is likely to be worded that it is for use in RP products, so in allowing ArduCAM or Hardkernel to use their firmware they would be in breach of their own licence to Broadcom.
Likewise Broadcom couldn't release the RPF modified firmware source to ArduCAM as (a) they don't have it, and (b) they don't hold the copyright to the RPF modifications (of which there are now lots).
Allwinner have created Linux drivers for many of their hardware blocks and therefore they have taken on the support burden of that. I doubt HardKernel or other of the SBC manufacturers using Allwinner chips have had to do any significant development effort beyond board bringup.
Broadcom chose not to create Linux drivers as that was not their main market. RPF took the risk 5 years ago with the chips that they could get hold of, and have stuck with Broadcom since due to their investment and expertise. They could jump ship to Allwinner or other chip manufacturer, but that would be throwing away all that effort, all of the optimisations, and instead potentially picking up support of binary blobs in other kernels.
You're all free to choose to buy an alternative SBC with a less restrictive licence, but you then need to accept the level of support provided by that manufacturer and community.
OpenGL driver on Raspberry Pi
留言
張貼留言