Discussion:
Bug#685134: [s390-tools] please add patch from qemu
(too old to reply)
Dimitri John Ledkov
2016-02-02 00:10:02 UTC
Permalink
On Fri, 17 Aug 2012 11:21:04 +0200 bastien ROUCARIES
Package: s390-tools
Severity: important
Tags: patch
Please add http://repo.or.cz/w/s390-tools.git for booting s390 from qemu. it port virtio.
I have ported the pach queue to recent s390-tools. Not tested only merge without conflict.
Thanks
Bastien
Hello,

Is this still required? I see that qemu-2.5 has support for booting El
Torito .iso images, and it boots Debian off virtio block drives just
fine.

Granted, it looks like debian packaging strips the s390 firmware file,
and doesn't rebuild it. Maybe that should simply be fixed and that's
it?

Regards,

Dimitri.
Viktor Mihajlovski
2016-02-03 08:40:02 UTC
Permalink
Post by Dimitri John Ledkov
On Fri, 17 Aug 2012 11:21:04 +0200 bastien ROUCARIES
Package: s390-tools
Severity: important
Tags: patch
Please add http://repo.or.cz/w/s390-tools.git for booting s390 from qemu. it port virtio.
I have ported the pach queue to recent s390-tools. Not tested only merge without conflict.
Thanks
Bastien
Hello,
Is this still required? I see that qemu-2.5 has support for booting El
Torito .iso images, and it boots Debian off virtio block drives just
fine.
Granted, it looks like debian packaging strips the s390 firmware file,
and doesn't rebuild it. Maybe that should simply be fixed and that's
it?
Regards,
Dimitri.
Right, including the firmware file would be the proper way to enable
QEMU for booting on s390.
--
Mit freundlichen Grüßen/Kind Regards
Viktor Mihajlovski

IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martina Köderitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
Philipp Kern
2017-10-19 12:10:02 UTC
Permalink
Post by Viktor Mihajlovski
Post by Dimitri John Ledkov
On Fri, 17 Aug 2012 11:21:04 +0200 bastien ROUCARIES
Please add http://repo.or.cz/w/s390-tools.git for booting s390 from qemu. it port virtio.
I have ported the pach queue to recent s390-tools. Not tested only merge without conflict.
Is this still required? I see that qemu-2.5 has support for booting El
Torito .iso images, and it boots Debian off virtio block drives just
fine.
Granted, it looks like debian packaging strips the s390 firmware file,
and doesn't rebuild it. Maybe that should simply be fixed and that's
it?
Right, including the firmware file would be the proper way to enable
QEMU for booting on s390.
If I understand it correctly, this is now obsoleted by the fact that
qemu dropped s390-virtio and runs with their own s390-ccw rom now that's
built from the qemu source. Is that correct? Can we close the s390-tools
bug at least? And I suppose arrange for s390-ccw.rom to be shipped from
the qemu package?

Kind regards and thanks
Philipp Kern
Michael Tokarev
2017-10-19 13:20:01 UTC
Permalink
Post by Philipp Kern
Post by Viktor Mihajlovski
Post by Dimitri John Ledkov
On Fri, 17 Aug 2012 11:21:04 +0200 bastien ROUCARIES
Please add http://repo.or.cz/w/s390-tools.git <http://repo.or.cz/w/s390-tools.git> for booting s390 from qemu. it port virtio.
I have ported the pach queue to recent s390-tools. Not tested only merge without conflict.
Is this still required? I see that qemu-2.5 has support for booting El
Torito .iso images, and it boots Debian off virtio block drives just
fine.
Granted, it looks like debian packaging strips the s390 firmware file,
and doesn't rebuild it. Maybe that should simply be fixed and that's
it?
Right, including the firmware file would be the proper way to enable
QEMU for booting on s390.
There's no way to include firmware on debian without actually building it,
and building it, as far as I can see, only works on s390 architecture.
That's why we don't build other firmware stuff - either lack of cross-
compiler on all necessary architectures, or the requiriment to have
actual system of the necessary architecture (virtual or real). It'd be
nice to have it all in one place.
Post by Philipp Kern
If I understand it correctly, this is now obsoleted by the fact that
qemu dropped s390-virtio and runs with their own s390-ccw rom now that's
built from the qemu source. Is that correct? Can we close the s390-tools
bug at least? And I suppose arrange for s390-ccw.rom to be shipped from
the qemu package?
 
On Ubuntu there already is: /usr/share/qemu/s390-ccw.img
which works for me as part package qemu-system-s390x.
That is part of the suggested contribution in bug 874347 already.
See #2 in that bug and the suggestion to accept it without an ubuntu: label in d/control-in.
Debian has much stricter policy wrt blobs (DFSG),
and debian builds for more architectures (the firmware,
if it is part of qemu-system-s390 package, needs to be
built on all architectures where this binary package
builts, or it needs to be a separate arch-all package).

I'll take look at all this once again.

It looks like the s390-tools bug can be closed indeed.

Thanks,

/mjt
Dimitri John Ledkov
2017-11-15 13:20:02 UTC
Permalink
Post by Michael Tokarev
Debian has much stricter policy wrt blobs (DFSG),
and debian builds for more architectures (the firmware,
if it is part of qemu-system-s390 package, needs to be
built on all architectures where this binary package
builts, or it needs to be a separate arch-all package).
Note that the arch:all autobuilders are amd64. gcc-*-s390x-linux-gnu
exists in Debian, although only on i386 and amd64. I don't think there's
a policy today that precludes you from forcing users to build arch:all
on amd64 for technical reasons.
Well, depwait state is valid, no? E.g. i'm sure we have many arch:all
packages that cannot be built on some architectures if e.g. arch:all
source package has an arch:all build dependency that is not
installable on some architectures.

As long as arch:all is buildable on a few common architectures, that's
good enough, no?
Indeed that's one option to build it, that's for example the solution
chosen to build slof using gcc-powerpc64-linux-gnu. So far nobody
complained it's buildable only on amd64, i386, ppc64el and x32.
Note there are now two s390 firmwares in qemu: ccw and netboot. The
netboot one needs SLOF sources.
The other alternative is to build a cross-compiler using binutils-source
and gcc-source (that requires that the none or elf os is supported for
this architecture). This has the advantage of ignoring all the flags
that debhelper tries to push that make a firmware to not build or break.
That's the solution chosen for example for openbios.
Would the attached patch be acceptable for debian?

* It drops stripping roms/SLOF

* Adds Build-Depends-Indep: crossbuild-essential-s390x
(such that it is needed only on the arch:all debian builder, or when
building with -A, meaning it is not needed when doing arch builds,
tested that arch-only build doesn't require this)
(maybe we can add a build profile <!no-firmware> or like <!no-cross>
for this too, to exclude this step, and thus enable people to manually
build arch-all & arch-any packages, without the crosstoolchainy bits)

* Adds code to compile s390 firmwares and install them into
qemu-s390-firmware arch:all package
(package name is arbitrary - it did not feel right to call it bios...
any better name suggestions are welcome)

Given that roms/SLOF code is needed by two firmwares, maybe we can
explore collapsing src:qemu-slof into src:qemu too, using strategy
similar to the above one.

Installing s390x cross toolchain, and compiling s390 firmware adds
trivial amount of extra build-time, given how long/big the full
src:qemu build already is.
--
Regards,

Dimitri.
Loading...