This is something I've been keen to do for some time which is to generate an
OpenBIOS builder image with the required cross-compilers pre-installed, and
then implement workflows so that a push to a branch or a versioned release
tag will automatically create OpenBIOS binaries.
One of the barriers to OpenBIOS development is getting the correct cross
compilers installed: not just for the architecture being developed on, but
also for all current supported architectures to ensure there are no
…
[View More]regressions.
Up until now I was unable to find a set of compilers that built
working binaries across all architectures, but since Glenn pointed out the
existence of the crosstool releases on kernel.org I've done some tests and
confirmed that the cross compilers produce working binaries for all of SPARC32,
SPARC64 and PPC.
This series adds a manual action to create an openbios-builder image that
is then integrated into automated workflows for building debug and release
OpenBIOS binaries for all supported architectures (amd64, sparc32, sparc64, ppc
and x86). The behaviour is currently very simple:
- A push to a branch will build OpenBIOS binaries, and if it is the upstream
openbios repository, generate a "latest" release
- A push to a versioned release tag matching "v*" will build the OpenBIOS
binaries and generate a versioned release
For an example of how this will look when merged take a look at the release page
of my OpenBIOS fork on GitHub at https://github.com/mcayland/openbios/releases.
As a bonus once this has been merged and the openbios-builder image is pushed to
ghcr.io it is possible to perform a local development build with simply:
git clone https://github.com/openbios/openbios.git
docker run --rm -it -v "$(pwd)/openbios:/root" ghcr.io/openbios/openbios-builder:master
cd /root
./config/scripts/switch-arch sparc32 && make V=1
...
...
exit
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk>
Mark Cave-Ayland (4):
docker: introduce Dockerfile.builder for openbios-builder container
.github/workflows: add build-openbios-builder.yml action
.github/workflows: add main.yml for building OpenBIOS upon push
.github/workflows: add release.yml for generating an OpenBIOS release
.github/workflows/build-openbios-builder.yml | 42 ++++++++
.github/workflows/main.yml | 103 +++++++++++++++++++
.github/workflows/release.yml | 101 ++++++++++++++++++
docker/Dockerfile.builder | 19 ++++
4 files changed, 265 insertions(+)
create mode 100644 .github/workflows/build-openbios-builder.yml
create mode 100644 .github/workflows/main.yml
create mode 100644 .github/workflows/release.yml
create mode 100644 docker/Dockerfile.builder
--
2.20.1
[View Less]
Recent versions of GDB (and probably older ones too, but not checked) crash
with and abort when loading the non-stripped 32-bit PPC QEMU build[1]. This
is due to a bug in GDB on reading stab symbols. The only place in OpenBIOS
where stab symbols are generated is in libgcc/crtsavres.S, which was copied
from the linux kernel[2].
Symbols that were defined in the stabs section are still able to be seen in
GDB after stabs removal. There does not appear to be a loss in debugging
functionality.
[1] …
[View More]https://sourceware.org/bugzilla/show_bug.cgi?id=28900
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arc…
Signed-off-by: Glenn Washburn <development(a)efficientek.com>
---
libgcc/crtsavres.S | 4 ----
1 file changed, 4 deletions(-)
diff --git a/libgcc/crtsavres.S b/libgcc/crtsavres.S
index 40bd736..8a77ba1 100644
--- a/libgcc/crtsavres.S
+++ b/libgcc/crtsavres.S
@@ -76,13 +76,9 @@ GLUE(.,name):
#define _GLOBAL(n) \
.text; \
- .stabs __stringify(n:F-1),N_FUN,0,0,n;\
.globl n; \
n:
-/* some stab codes */
-#define N_FUN 36
-
#endif
/* arch/powerpc/lib/crtsavres.S continues */
--
2.30.2
[View Less]
The recent discussions about which architectures are currently supported has
inspired me to revisit my work on adding GitHub workflow actions. Glenn pointed
out that there are a couple of errors in the x86/amd64 builds which are fixed
by this patchset.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk>
Mark Cave-Ayland (2):
config/scripts/switch-arch: allow x86_64 prefix for x86 builds
arch/unix/unix.c: fix build on x86 architecture with modern gcc
compilers
…
[View More]arch/unix/unix.c | 2 ++
config/scripts/switch-arch | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
--
2.20.1
[View Less]
Instead of using a constant frequency for all CPUs, which have varying
frequencies, use the time frequency as returned by the processor. This
fixes issues where delays from ciface_milliseconds were not corresponding
to elapsed time as given by the real time clock on certain platforms, eg.
QEMU's mac99 machine.
Signed-off-by: Glenn Washburn <development(a)efficientek.com>
---
Mark, if I missed something in the commit message, feel free to make edits
as you see fit.
Glenn
---
arch/ppc/…
[View More]qemu/methods.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/ppc/qemu/methods.c b/arch/ppc/qemu/methods.c
index 930b47c..a423b9f 100644
--- a/arch/ppc/qemu/methods.c
+++ b/arch/ppc/qemu/methods.c
@@ -126,7 +126,8 @@ ciface_quiesce( unsigned long args[], unsigned long ret[] )
}
/* ( -- ms ) */
-#define TIMER_FREQUENCY 16600000ULL
+/* From drivers/timer.c */
+extern unsigned long timer_freq;
static void
ciface_milliseconds( unsigned long args[], unsigned long ret[] )
@@ -146,7 +147,7 @@ ciface_milliseconds( unsigned long args[], unsigned long ret[] )
: "cc");
ticks = (((unsigned long long)tbu) << 32) | (unsigned long long)tbl;
- msecs = (1000 * ticks) / TIMER_FREQUENCY;
+ msecs = (1000 * ticks) / timer_freq;
PUSH( msecs );
}
--
2.30.2
[View Less]