On Wed, Feb 21, 2018 at 06:33:42PM +0000, Peter Maydell wrote: > 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".
So, I encouraged Zoltan to attempt this because I thought boards
without suitable firmware blobs were the exception. If they're common
it's probably fine as is.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
