On 21 February 2018 at 17:06, BALATON Zoltan <bala...@eik.bme.hu> wrote: > It's not that upstream u-boot has abandoned board support (it only removed > support for the PPC440 CPU it once had). The board itself never had support > in upstream u-boot, it only exists in vendor's fork which is the reason we > need a separate source and cannot use upstream u-boot source we already > have. > > In my opinion we don't aim to take on support for this board in u-boot, we > only need to include the firmware binary for the emulation to be useful > which then requires us to also include the source for the GPL it's licensed > under. I've also found a few bugs in the firmware which I've fixed but apart > from such occasional bug fixes when needed I don't expect to take over > support for the board from the hardware vendor so this source is only so we > can include the firmware binary which is needed for the board emulation. > Does this answer your concerns?
We have lots of boards we don't ship firmware blobs for and which we expect the users to provide the guest code for if they're going to use them. If we had a git submodule for every random dev board model that needs some hardware vendor's BSP and bootloader we'd probably have 50 submodules... Which isn't to say I'm definitely against this -- I'm just trying to figure out where we should draw the line of "these bits of guest code we build for you and ship with QEMU" versus "we provide the model of the hardware for you to run whatever guest code you happen to have". thanks -- PMM