I've created a git repo for the Sam460ex u-boot sources and this adds
that as a submodule and a separate patch to add the binary built from
these sources. Feel free to keep this as two patches, squash them into
one patch or take the git repo and commit the content under the QEMU
repo and use that as a submodule as you see fit (or let me know if any
changes are needed for these patches).

BALATON Zoltan (2):
  roms: Added git submodule for u-boot-sam460 (firmware for sam460ex)
  pc-bios: Added u-boot-sam460 firmware binary

 .gitmodules                        |   3 +++
 Makefile                           |   2 +-
 pc-bios/u-boot-sam460-20100605.bin | Bin 0 -> 524288 bytes
 3 files changed, 4 insertions(+), 1 deletion(-)
 create mode 100755 pc-bios/u-boot-sam460-20100605.bin

-- 
2.7.6

On 20 February 2018 at 18:10, BALATON Zoltan <balaton@eik.bme.hu> wrote:
> I've created a git repo for the Sam460ex u-boot sources and this adds
> that as a submodule and a separate patch to add the binary built from
> these sources. Feel free to keep this as two patches, squash them into
> one patch or take the git repo and commit the content under the QEMU
> repo and use that as a submodule as you see fit (or let me know if any
> changes are needed for these patches).
>
> BALATON Zoltan (2):
>   roms: Added git submodule for u-boot-sam460 (firmware for sam460ex)
>   pc-bios: Added u-boot-sam460 firmware binary

We already have a submodule for u-boot. Is it not possible to
build this bios blob from those upstream u-boot sources?

thanks
-- PMM

On Tue, Feb 20, 2018 at 18:31:17 +0000, Peter Maydell wrote:
> On 20 February 2018 at 18:10, BALATON Zoltan <balaton@eik.bme.hu> wrote:
> > I've created a git repo for the Sam460ex u-boot sources and this adds
> > that as a submodule and a separate patch to add the binary built from
> > these sources. Feel free to keep this as two patches, squash them into
> > one patch or take the git repo and commit the content under the QEMU
> > repo and use that as a submodule as you see fit (or let me know if any
> > changes are needed for these patches).
> >
> > BALATON Zoltan (2):
> >   roms: Added git submodule for u-boot-sam460 (firmware for sam460ex)
> >   pc-bios: Added u-boot-sam460 firmware binary
> 
> We already have a submodule for u-boot. Is it not possible to
> build this bios blob from those upstream u-boot sources?

This is discussed in the following thread:
  Re: [Qemu-ppc] [PATCH v3 2/2] ppc: Add aCube Sam460ex board
  http://lists.gnu.org/archive/html/qemu-ppc/2018-02/msg00268.html

		Emilio

On 20 February 2018 at 20:44, Emilio G. Cota <cota@braap.org> wrote:
> On Tue, Feb 20, 2018 at 18:31:17 +0000, Peter Maydell wrote:
>> On 20 February 2018 at 18:10, BALATON Zoltan <balaton@eik.bme.hu> wrote:
>> > I've created a git repo for the Sam460ex u-boot sources and this adds
>> > that as a submodule and a separate patch to add the binary built from
>> > these sources. Feel free to keep this as two patches, squash them into
>> > one patch or take the git repo and commit the content under the QEMU
>> > repo and use that as a submodule as you see fit (or let me know if any
>> > changes are needed for these patches).
>> >
>> > BALATON Zoltan (2):
>> >   roms: Added git submodule for u-boot-sam460 (firmware for sam460ex)
>> >   pc-bios: Added u-boot-sam460 firmware binary
>>
>> We already have a submodule for u-boot. Is it not possible to
>> build this bios blob from those upstream u-boot sources?
>
> This is discussed in the following thread:
>   Re: [Qemu-ppc] [PATCH v3 2/2] ppc: Add aCube Sam460ex board
>   http://lists.gnu.org/archive/html/qemu-ppc/2018-02/msg00268.html

If upstream u-boot have abandoned the board support I'm not very
enthusiastic about our taking it on :-(

thanks
-- PMM

On Wed, 21 Feb 2018, Peter Maydell wrote:
> On 20 February 2018 at 20:44, Emilio G. Cota <cota@braap.org> wrote:
>> On Tue, Feb 20, 2018 at 18:31:17 +0000, Peter Maydell wrote:
>>> On 20 February 2018 at 18:10, BALATON Zoltan <balaton@eik.bme.hu> wrote:
>>>> I've created a git repo for the Sam460ex u-boot sources and this adds
>>>> that as a submodule and a separate patch to add the binary built from
>>>> these sources. Feel free to keep this as two patches, squash them into
>>>> one patch or take the git repo and commit the content under the QEMU
>>>> repo and use that as a submodule as you see fit (or let me know if any
>>>> changes are needed for these patches).
>>>>
>>>> BALATON Zoltan (2):
>>>>   roms: Added git submodule for u-boot-sam460 (firmware for sam460ex)
>>>>   pc-bios: Added u-boot-sam460 firmware binary
>>>
>>> We already have a submodule for u-boot. Is it not possible to
>>> build this bios blob from those upstream u-boot sources?
>>
>> This is discussed in the following thread:
>>   Re: [Qemu-ppc] [PATCH v3 2/2] ppc: Add aCube Sam460ex board
>>   http://lists.gnu.org/archive/html/qemu-ppc/2018-02/msg00268.html
>
> If upstream u-boot have abandoned the board support I'm not very
> enthusiastic about our taking it on :-(

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?

Regards,
BALATON Zoltan

On 21 February 2018 at 17:06, BALATON Zoltan <balaton@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

On Wed, Feb 21, 2018 at 06:33:42PM +0000, Peter Maydell wrote:
> On 21 February 2018 at 17:06, BALATON Zoltan <balaton@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

On 21.02.2018 19:33, Peter Maydell wrote:
> On 21 February 2018 at 17:06, BALATON Zoltan <balaton@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.

... which is also somewhat unfortunate. Have you ever tried to run one
of those boards to see whether you've broken something with your code
changes or not? Hunting the firmware for such a board can be quite
challenging. I'm not saying that we should now try to include way more
firmware blobs in our repository (its size would explode, I guess), but
maybe we should at least start a Wiki page with links to the various
firmware images or so?

 Thomas