Re: [PATCH v2] ieee1275: obdisk driver
On 06/15/2018 02:02 PM, Daniel Kiper wrote: >> +static int disks_enumerated = 0; >> +static struct disk_dev *disk_devs = NULL; >> +static struct parent_dev *parent_devs = NULL; > > I would drop all these 0/NULL initializations. > Compiler will do work for you. I asked about > that in earlier comments. Not sure about that though. I seem to remember that newer gcc versions were quite nitpicky about that when building with -Werror and I had to add a NULL initialization to get it to build. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Any plans for GRUB 2.03 release?
On 08/01/2018 11:23 PM, Paul Menzel wrote: > A lot of changes have been made since the GRUB 2.02 release, and > distribution start to cherry-pick them. In my opinion, it’d be helpful > if a new release was made. Daniel and Vladimir actually talked about those plans at FOSDEM [1]. Adrian > [1] https://www.youtube.com/watch?v=c5aELZYK_5M -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
GRUB no longer builds on sparc64 after recent binutils changes
Hi! binutils upstream recently dropped support for a.out and COFF on sparc [1] which now causes GRUB failing to build on sparc64-linux [2]: if test x0 = x1; then ../grub-macho2img diskboot.image diskboot.img; else objcopy -O binary --strip-unneeded -R .note -R .comment -R .note.gnu.build-id -R .MIPS.abiflags -R .reginfo -R .rel.dyn -R .note.gnu.gold-version -R .ARM.exidx diskboot.image diskboot.img; fi objcopy:boot.img: invalid bfd target make[5]: *** [Makefile:42941: boot.img] Error 1 make[5]: *** Waiting for unfinished jobs objcopy:cdboot.img: invalid bfd target make[5]: *** [Makefile:42950: cdboot.img] Error 1 Does anyone know how we can resolve this issue? Can SPARC's OpenFirmware handle ELF files? Aren't COFF or a.out binaries often required by firmware loaders or similar? Thanks, Adrian > [1] > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=c9098af41e3246586a30f4f0bdb0ee4367e9a5e7#patch1 > [2] > https://buildd.debian.org/status/fetch.php?pkg=grub2&arch=sparc64&ver=2.02%2Bdfsg1-5&stamp=1533001924&raw=0 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Recent removal of a.out and COFF support for sparc
Hello! binutils/bfd recently removed a.out and COFF support for sparc [1]. Unfortunately, this means that we are no longer able to built GRUB or SILO for sparc/sparc64 which need to be built as a.out binaries as the Open Boot Firmware requires them to be in a.out format [2]. I would therefore like to ask to start a discussion about a potential reversal of this commit as I don't think we can forgo being able to build a bootloader on sparc/sparc64. Also, since m68k is still very actively maintained (there is even LLVM support in the works now) and since AmigaOS uses COFF, I would to ask for the a.out and COFF support for m68k to be reinstated as well [3]. Thanks, Adrian > [1] > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=c9098af41e3246586a30f4f0bdb0ee4367e9a5e7 > [2] https://docs.oracle.com/cd/E19457-01/801-7042/801-7042.pdf > [3] > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=dc12032bca08554cf0a72d224e44f755f7789ff3 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Recent removal of a.out and COFF support for sparc
On 08/07/2018 05:04 PM, Vladimir 'phcoder' Serbinenko wrote: > I can change code to do conversion to coff ourselves. Shouldn't that be a.out? And we would still have the problem that other binaries for OBP can no longer be generated using binutils. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Recent removal of a.out and COFF support for sparc
On 08/07/2018 12:51 PM, John Paul Adrian Glaubitz wrote: > binutils/bfd recently removed a.out and COFF support for sparc [1]. I just noticed that COFF/a.out support for MIPS was removed as well and shortly after restored since it seems that GRUB also needs COFF/a.out support on MIPS. So, can we have COFF/a.out support back, at least for sparc*? Thanks, Adrian > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=8e415ce8fee234cd86f29d8f4ebbbdf0f9c0b031 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Recent removal of a.out and COFF support for sparc
On 08/08/2018 03:55 AM, Alan Modra wrote: >> So, can we have COFF/a.out support back, at least for sparc*? > > I would rather remove all AOUT support. AOUT as a format has been > obsolete since the advent of ELF in the 1990s. See for example > J. Arnold "ELF: An Object File to Mitigate Mischievous Misoneism", In > Proc. of the Summer USENIX Conference, 1990. > COFF should have died too.. Yes, but that doesn't change the fact that people are still using it. OpenBoot firmware requires the binary to be in a.out format and we're therefore stuck with that. It's not that we can change the hardware in retrospect. Also, while AOUT and COFF might be old in general, it does not mean that these formats completely vanish. There are still places where they are used, see for example Microsoft's PE binaries. And users might still want to be able to analyze binaries from various sources without having to dig out a specific version of binutils first. > The sparc target obsolescence happened here: > https://sourceware.org/ml/binutils/2016-09/msg00184.html Well, that question was asked on the binutils mailing list and I think it's a bit unfair to expect all downstreams to follow all upstream mailing lists. There is a plethora of very important upstream projects like the Linux kernel, binutils, gcc, systemd, OpenJDK, gdb and so on and so forth and trying to keep track of what all of these upstreams are doing is nearly impossible. > You've had quite a bit of warning, but I guess you just built binutils > with --enable-obsolete, or stayed with older binutils. Again, I think this is an unfair statement. It's simply not possible for downstreams to track all upstream projects. On the other hand, why does bfd even need to be reworked so much? Isn't the idea that people are eventually moving to elfutils or Gold anyway? > Well, older > binutils are likely to be better for AOUT anyway. So what's to > prevent you using older binutils for sparc-aout? Distributions usually don't allow multiple versions of the same package to be part of the same distribution. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Recent removal of a.out and COFF support for sparc
On 08/08/2018 03:16 PM, Alan Modra wrote: > On Wed, Aug 08, 2018 at 11:07:58AM +0200, John Paul Adrian Glaubitz wrote: >> On the other hand, why does bfd even need to be reworked so much? > > You'd think that the AOUT and COFF support would be stable by now, and > that's true enough. There are two or three problems that waste > maintainers time though. It works for the people who use it. I don't think anyone claims the software is perfect. > One is that people write fuzzers and take a delight in submitting bug > reports for this old code. Those bugs take up time Nick and I would > rather spend elsewhere. I suppose we could just close them as "won't > fix", but they are undeniably bugs, and a bug that crashes a program > might just be exploitable when some luser runs objdump as root. I think closing those bugs as WONTFIX would be fair, yes. And I think you can just make AOUT/COFF support configurable at build time. > Another is that people report bugs about leaked memory. Generally > that's also a "don't care", since none of "ld", "as" or any of the > binutils run as servers. > > Finally, when anyone wants to make changes to data structures or > functions used by all the backends, we have to change all this old > code too. Why isn't this done on Gold though? > It's not a matter of reworking the code. No one wants to work on it > at all! At least, judging by the number of people actively > maintaining most of binutils, that seems to be the case. Are *you* > interested in maintaining sparc-aout or sparc-coff? There are sparc > bug reports dating back to 2004 that no one has analyzed! Again, this isn't fair. You cannot expect having to step up as a maintainer just because they are users of some code. Isn't the idea that Linux distributions are developed by a community and everyone takes their part? You are certainly also expecting someone to keep other software you are using maintained and would probably annoyed in a similar way if upstream just dropped it and told you to maintain it yourself, wouldn't it? What do you suggest on the other hand? Shall we tell them because upstream binutils has dropped AOUT/COFF support, there won't be any bootloaders anymore for SPARC machines? Don't get me wrong, I know maintenance resources are limited and I agree that's a good thing that unsued code gets removed. What I don't understand is that upstream maintainers remove code that people are still actively using. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Recent removal of a.out and COFF support for sparc
On 08/08/2018 03:54 PM, Joel Brobecker wrote: >> Again, this isn't fair. You cannot expect having to step up as a maintainer >> just because they are users of some code. > > Not every user has to step up, but someone has to step up. Someone > has to take care of the code, and using the fair-unfair approach, > it would not be fair to ask existing maintainers to maintain a target > they are not interested in either. Again, I understand the problem, it's not the first time I am having such a discussion. There was a similar one regarding POWER5 support in Golang [1] and the SPE backend in gcc [2]. The problem is just that we are talking about code here that people are actively using so I'm not sure what the alternatives are. Adrian > [1] https://github.com/golang/go/issues/19074 > [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Recent removal of a.out and COFF support for sparc
On 08/08/2018 04:39 PM, Cary Coutant wrote: >>> Another is that people report bugs about leaked memory. Generally >>> that's also a "don't care", since none of "ld", "as" or any of the >>> binutils run as servers. >>> >>> Finally, when anyone wants to make changes to data structures or >>> functions used by all the backends, we have to change all this old >>> code too. >> >> Why isn't this done on Gold though? > > Why isn't *what* done on gold? Gold is ELF-only and doesn't use BFD. Development of new features. I know that Gold is ELF-only that's why I was wondering why BFD isn't just kept in maintenance mode. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Recent removal of a.out and COFF support for sparc
On 08/08/2018 07:08 PM, Cary Coutant wrote: >>> Why isn't *what* done on gold? Gold is ELF-only and doesn't use BFD. >> >> Development of new features. I know that Gold is ELF-only that's why >> I was wondering why BFD isn't just kept in maintenance mode. > > Gold supports only a small fraction of the platforms that BFD does, Which of the platforms that are still relevant for commercial applications are supported by BFD which are not supported by Gold? As far as I know, Gold support x86*, POWER*, ARM*, s390* and MIPS* which covers all of the targets that distributions like Fedora, openSUSE and Debian consider as supported release architectures. > and many of those platforms don't use ELF. In addition, almost all of > the other binutils tools use BFD. BFD is far from being relegated to > maintenance mode. What about elfutils for these purposes? I have been told by gcc people that elfutils was supposed to replace binutils in this regard. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Recent removal of a.out and COFF support for sparc
On 08/08/2018 08:27 PM, Maciej W. Rozycki wrote: > On Wed, 8 Aug 2018, John Paul Adrian Glaubitz wrote: > >>> Gold supports only a small fraction of the platforms that BFD does, >> >> Which of the platforms that are still relevant for commercial applications >> are supported by BFD which are not supported by Gold? >> >> As far as I know, Gold support x86*, POWER*, ARM*, s390* and MIPS* which >> covers all of the targets that distributions like Fedora, openSUSE and >> Debian consider as supported release architectures. > > We have dozens of bare metal targets which only have support in BFD. Which is my whole point. If you remove all these targets from BFD, what would be the point of still using it over Gold or LLVM's LLD? It's the same argument I see with gcc. One of it's huge selling points is the plethora of targets it supports. If you go ahead now and cut out all targets except for the current mainstream targets, you are removing one huge advantage that gcc has over LLVM. > Some of these architectures happen to have Linux support too, for embedded > applications. All the world is not Linux. And all the world are not > distributions either. Freescale S12Z is the most recent addition I > believe, and has no gold support AFAICT. Yep. And that's why I think it's better to keep BFD useful for various targets and not bother about potential vulnerabilities which don't really pose a threat in the real world, e.g. the threat that someone is sending a user a manipulated object file and asking them to open it with "readelf" or "objcopy" running as root. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Recent removal of a.out and COFF support for sparc
On 08/08/2018 08:30 PM, Paul Koning wrote: >> We have dozens of bare metal targets which only have support in BFD. >> Some of these architectures happen to have Linux support too, for embedded >> applications. All the world is not Linux. > > Indeed. For example, NetBSD support 57 platforms (not quite that many > architectures, but a lot more than Linux). Not really. Linux supports about 25 unique architectures multiplied by various sub- architectures. You are counting sub-architectures as individual targets in NetBSD. You are already counting four or five different m68k targets which are covered by a single m68k target on Linux. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Recent removal of a.out and COFF support for sparc
On 08/08/2018 11:27 PM, Paul Koning wrote: > I don't quite understand. > > The original discussion seemed to be the removal of the a.out and coff output > options specifically for sparc. In other words, a target which used to > support ELF along with some other formats now supports ELF only. Yep. So you cut out support for the targets sparc/coff and sparc/a,out, the latter being the target format used by the OBP firmware used on nearly every SPARC machine. > There are also targets that do not support ELF. And I know of no plans to > remove those targets, or to remove the a.out support they rely on. I'm > maintainer for one of them. The SPARC OBP firmware is a target that does not support ELF which is why it is no longer possible to build binaries for this target despite being it an actively used target. > Nor are there plans to trim the target set of gcc down to "current mainstream > targets", whatever that might mean. Well, yes, I just linked one of those gcc targets - the e500 target - earlier today. The m68k target in gcc is also constantly under threat because of the planned cc0 removal. Both the e500 and the m68k targets in gcc are actively used. The m68k target is still very popular despite its age. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Recent removal of a.out and COFF support for sparc
On 08/10/2018 11:57 AM, Jose E. Marchesi wrote: > AFAIK Fedora successfully used elftoaout to generate the stage1 images > until they deprecated the SPARC support back in 2012. Debian > distributes elftoaout as part of the sparc-utils package [2]. Meh, I'll just leave it to GRUB upstream now to resolve this problem, I assume that Eric will soon run into the problem as well once the toolchain on Solaris gets updated. > [1] ftp://sunsite.icm.edu.pl/site/linux-sparc/elftoaout/ > [2] https://packages.debian.org/wheezy/sparc-utils FWIW, sparc-utils isn't part of an official Debian release, it's just part of Debian Ports. But we're working on building the package everywhere now. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Fixing GRUB build issues on SPARC
Hello! Since GRUB is still failing to build from source on SPARC targets due the fact that binutils upstream dropped support for a.out on SPARC [1, 2, 3], I have begun working on integrating the elftoaout [4] utility into the GRUB source tree to use the tool to convert ELF images to a.out during boot. Would integrating elftoaout into the GRUB source tree be an acceptable solution to address the build issue or would anyone rather like to see a different approach to address the build issue? Thanks, Adrian > [1] > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=c9098af41e3246586a30f4f0bdb0ee4367e9a5e7 > [2] https://sourceware.org/ml/binutils/2018-08/msg00138.html > [3] > https://buildd.debian.org/status/fetch.php?pkg=grub2&arch=sparc64&ver=2.02%2Bdfsg1-9&stamp=1544184516&raw=0 > [4] http://ftp.osuosl.org/pub/clfs/conglomeration/elftoaout/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Current status of [PATCH v2] ieee1275: obdisk driver
Hello! I was wondering what the current status of the new obdisk driver for GRUB was and whether there is still a chance for the driver to be merged? I know that Oracle is slowing down on SPARC work, but both in Debian and Gentoo, people are still actively working on Linux for SPARC so it would be great if pending improvements for GRUB on SPARC could still be integrated. FWIW, I will be around at FOSDEM, so I would be happy to meet for a chat. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] ieee1275: Include a.out header in assembly of sparc64 boot loader
Recent versions of binutils dropped support for the a.out and COFF
formats on sparc64 targets. Since the boot loader on sparc64 is
supposed to be an a.out binary and the a.out header entries are
rather simple to calculate in our case, we just write the header
ourselves instead of relying external tools to do that.
Signed-off-by: John Paul Adrian Glaubitz
---
grub-core/Makefile.core.def| 6 ++
grub-core/boot/sparc64/ieee1275/boot.S | 18 +++---
include/grub/sparc64/ieee1275/boot.h | 3 +--
3 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
index e16fb06ba..f9f845828 100644
--- a/grub-core/Makefile.core.def
+++ b/grub-core/Makefile.core.def
@@ -402,8 +402,7 @@ image = {
i386_qemu_ldflags =
'$(TARGET_IMG_BASE_LDOPT),$(GRUB_BOOT_MACHINE_LINK_ADDR)';
i386_qemu_ccasflags =
'-DGRUB_BOOT_MACHINE_LINK_ADDR=$(GRUB_BOOT_MACHINE_LINK_ADDR)';
- sparc64_ieee1275_objcopyflags = '-O a.out-sunos-big';
- sparc64_ieee1275_ldflags = ' -Wl,-Ttext=0x4000';
+ sparc64_ieee1275_ldflags = ' -Wl,-Ttext=0x3fe0';
objcopyflags = '-O binary';
enable = i386_pc;
@@ -432,8 +431,7 @@ image = {
i386_pc_ldflags = '$(TARGET_IMG_BASE_LDOPT),0x7C00';
sparc64_ieee1275 = boot/sparc64/ieee1275/boot.S;
- sparc64_ieee1275_objcopyflags = '-O a.out-sunos-big';
- sparc64_ieee1275_ldflags = ' -Wl,-Ttext=0x4000';
+ sparc64_ieee1275_ldflags = ' -Wl,-Ttext=0x3fe0';
sparc64_ieee1275_cppflags = '-DCDBOOT=1';
objcopyflags = '-O binary';
diff --git a/grub-core/boot/sparc64/ieee1275/boot.S
b/grub-core/boot/sparc64/ieee1275/boot.S
index 9ea9b4e06..0b43b6e80 100644
--- a/grub-core/boot/sparc64/ieee1275/boot.S
+++ b/grub-core/boot/sparc64/ieee1275/boot.S
@@ -21,6 +21,18 @@
.text
.align 4
+ /* We're writing the a.out header ourselves as newer
+* upstream versions of binutils no longer support
+* the a.out format on SPARC.
+*/
+ .word 0x1030107/* magic number */
+ .word 512 - GRUB_BOOT_AOUT_HEADER_SIZE /* size of text segment */
+ .word 0/* size of initialized data */
+ .word 0/* size of uninitialized data */
+ .word 0/* size of symbol table ||
checksum */
+ .word _start /* entry point */
+ .word 0/* size of text relocation */
+ .word 0/* size of data relocation */
.globl _start
_start:
/* OF CIF entry point arrives in %o4 */
@@ -41,9 +53,9 @@ pic_base:
* After loading in that block we will execute it by jumping to the
* load address plus the size of the prepended A.OUT header (32 bytes).
*/
- .org GRUB_BOOT_MACHINE_BOOT_DEVPATH
+ .org GRUB_BOOT_MACHINE_BOOT_DEVPATH + GRUB_BOOT_AOUT_HEADER_SIZE
boot_path:
- .org GRUB_BOOT_MACHINE_KERNEL_BYTE
+ .org GRUB_BOOT_MACHINE_KERNEL_BYTE + GRUB_BOOT_AOUT_HEADER_SIZE
boot_path_end:
kernel_byte: .xword (2 << 9)
kernel_address:.word GRUB_BOOT_MACHINE_KERNEL_ADDR
@@ -52,7 +64,7 @@ kernel_address: .word
GRUB_BOOT_MACHINE_KERNEL_ADDR
#define boot_path_end (_start + 1024)
#include
- .org 8
+ .org 8 + GRUB_BOOT_AOUT_HEADER_SIZE
kernel_byte: .xword (2 << 9)
kernel_size: .word 512
kernel_address:.word GRUB_BOOT_SPARC64_IEEE1275_IMAGE_ADDRESS
diff --git a/include/grub/sparc64/ieee1275/boot.h
b/include/grub/sparc64/ieee1275/boot.h
index 02d53f28e..cc5a941e3 100644
--- a/include/grub/sparc64/ieee1275/boot.h
+++ b/include/grub/sparc64/ieee1275/boot.h
@@ -46,8 +46,7 @@
#define GRUB_BOOT_MACHINE_KERNEL_BYTE 0x80
-#define GRUB_BOOT_MACHINE_CODE_END \
- (0x1fc - GRUB_BOOT_AOUT_HEADER_SIZE)
+#define GRUB_BOOT_MACHINE_CODE_END 0x1fc
#define GRUB_BOOT_MACHINE_KERNEL_ADDR 0x4200
--
2.20.1
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH, v2] ieee1275: Include a.out header in assembly of sparc64 boot loader
Recent versions of binutils dropped support for the a.out and COFF
formats on sparc64 targets. Since the boot loader on sparc64 is
supposed to be an a.out binary and the a.out header entries are
rather simple to calculate in our case, we just write the header
ourselves instead of relying on external tools to do that.
Signed-off-by: John Paul Adrian Glaubitz
---
v2:
- fix grammar in long description
grub-core/Makefile.core.def| 6 ++
grub-core/boot/sparc64/ieee1275/boot.S | 18 +++---
include/grub/sparc64/ieee1275/boot.h | 3 +--
3 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
index e16fb06ba..f9f845828 100644
--- a/grub-core/Makefile.core.def
+++ b/grub-core/Makefile.core.def
@@ -402,8 +402,7 @@ image = {
i386_qemu_ldflags =
'$(TARGET_IMG_BASE_LDOPT),$(GRUB_BOOT_MACHINE_LINK_ADDR)';
i386_qemu_ccasflags =
'-DGRUB_BOOT_MACHINE_LINK_ADDR=$(GRUB_BOOT_MACHINE_LINK_ADDR)';
- sparc64_ieee1275_objcopyflags = '-O a.out-sunos-big';
- sparc64_ieee1275_ldflags = ' -Wl,-Ttext=0x4000';
+ sparc64_ieee1275_ldflags = ' -Wl,-Ttext=0x3fe0';
objcopyflags = '-O binary';
enable = i386_pc;
@@ -432,8 +431,7 @@ image = {
i386_pc_ldflags = '$(TARGET_IMG_BASE_LDOPT),0x7C00';
sparc64_ieee1275 = boot/sparc64/ieee1275/boot.S;
- sparc64_ieee1275_objcopyflags = '-O a.out-sunos-big';
- sparc64_ieee1275_ldflags = ' -Wl,-Ttext=0x4000';
+ sparc64_ieee1275_ldflags = ' -Wl,-Ttext=0x3fe0';
sparc64_ieee1275_cppflags = '-DCDBOOT=1';
objcopyflags = '-O binary';
diff --git a/grub-core/boot/sparc64/ieee1275/boot.S
b/grub-core/boot/sparc64/ieee1275/boot.S
index 9ea9b4e06..0b43b6e80 100644
--- a/grub-core/boot/sparc64/ieee1275/boot.S
+++ b/grub-core/boot/sparc64/ieee1275/boot.S
@@ -21,6 +21,18 @@
.text
.align 4
+ /* We're writing the a.out header ourselves as newer
+* upstream versions of binutils no longer support
+* the a.out format on SPARC.
+*/
+ .word 0x1030107/* magic number */
+ .word 512 - GRUB_BOOT_AOUT_HEADER_SIZE /* size of text segment */
+ .word 0/* size of initialized data */
+ .word 0/* size of uninitialized data */
+ .word 0/* size of symbol table ||
checksum */
+ .word _start /* entry point */
+ .word 0/* size of text relocation */
+ .word 0/* size of data relocation */
.globl _start
_start:
/* OF CIF entry point arrives in %o4 */
@@ -41,9 +53,9 @@ pic_base:
* After loading in that block we will execute it by jumping to the
* load address plus the size of the prepended A.OUT header (32 bytes).
*/
- .org GRUB_BOOT_MACHINE_BOOT_DEVPATH
+ .org GRUB_BOOT_MACHINE_BOOT_DEVPATH + GRUB_BOOT_AOUT_HEADER_SIZE
boot_path:
- .org GRUB_BOOT_MACHINE_KERNEL_BYTE
+ .org GRUB_BOOT_MACHINE_KERNEL_BYTE + GRUB_BOOT_AOUT_HEADER_SIZE
boot_path_end:
kernel_byte: .xword (2 << 9)
kernel_address:.word GRUB_BOOT_MACHINE_KERNEL_ADDR
@@ -52,7 +64,7 @@ kernel_address: .word
GRUB_BOOT_MACHINE_KERNEL_ADDR
#define boot_path_end (_start + 1024)
#include
- .org 8
+ .org 8 + GRUB_BOOT_AOUT_HEADER_SIZE
kernel_byte: .xword (2 << 9)
kernel_size: .word 512
kernel_address:.word GRUB_BOOT_SPARC64_IEEE1275_IMAGE_ADDRESS
diff --git a/include/grub/sparc64/ieee1275/boot.h
b/include/grub/sparc64/ieee1275/boot.h
index 02d53f28e..cc5a941e3 100644
--- a/include/grub/sparc64/ieee1275/boot.h
+++ b/include/grub/sparc64/ieee1275/boot.h
@@ -46,8 +46,7 @@
#define GRUB_BOOT_MACHINE_KERNEL_BYTE 0x80
-#define GRUB_BOOT_MACHINE_CODE_END \
- (0x1fc - GRUB_BOOT_AOUT_HEADER_SIZE)
+#define GRUB_BOOT_MACHINE_CODE_END 0x1fc
#define GRUB_BOOT_MACHINE_KERNEL_ADDR 0x4200
--
2.20.1
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] ieee1275: Include a.out header in assembly of sparc64 boot loader
Recent versions of binutils dropped support for the a.out and COFF
formats on sparc64 targets. Since the boot loader on sparc64 is
supposed to be an a.out binary and the a.out header entries are
rather simple to calculate in our case, we just write the header
ourselves instead of relying on external tools to do that.
Signed-off-by: John Paul Adrian Glaubitz
---
v2:
- fix grammar in long description
v3:
- fix formatting in assembly code
- update comment in boot loader for consistency
grub-core/Makefile.core.def| 6 ++
grub-core/boot/sparc64/ieee1275/boot.S | 18 +++---
include/grub/sparc64/ieee1275/boot.h | 3 +--
3 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
index e16fb06ba..f9f845828 100644
--- a/grub-core/Makefile.core.def
+++ b/grub-core/Makefile.core.def
@@ -402,8 +402,7 @@ image = {
i386_qemu_ldflags =
'$(TARGET_IMG_BASE_LDOPT),$(GRUB_BOOT_MACHINE_LINK_ADDR)';
i386_qemu_ccasflags =
'-DGRUB_BOOT_MACHINE_LINK_ADDR=$(GRUB_BOOT_MACHINE_LINK_ADDR)';
- sparc64_ieee1275_objcopyflags = '-O a.out-sunos-big';
- sparc64_ieee1275_ldflags = ' -Wl,-Ttext=0x4000';
+ sparc64_ieee1275_ldflags = ' -Wl,-Ttext=0x3fe0';
objcopyflags = '-O binary';
enable = i386_pc;
@@ -432,8 +431,7 @@ image = {
i386_pc_ldflags = '$(TARGET_IMG_BASE_LDOPT),0x7C00';
sparc64_ieee1275 = boot/sparc64/ieee1275/boot.S;
- sparc64_ieee1275_objcopyflags = '-O a.out-sunos-big';
- sparc64_ieee1275_ldflags = ' -Wl,-Ttext=0x4000';
+ sparc64_ieee1275_ldflags = ' -Wl,-Ttext=0x3fe0';
sparc64_ieee1275_cppflags = '-DCDBOOT=1';
objcopyflags = '-O binary';
diff --git a/grub-core/boot/sparc64/ieee1275/boot.S
b/grub-core/boot/sparc64/ieee1275/boot.S
index 9ea9b4e06..a534e1853 100644
--- a/grub-core/boot/sparc64/ieee1275/boot.S
+++ b/grub-core/boot/sparc64/ieee1275/boot.S
@@ -21,6 +21,18 @@
.text
.align 4
+ /* We're writing the a.out header ourselves as newer
+* upstream versions of binutils no longer support
+* the a.out format on sparc64.
+*/
+ .word 0x1030107/* magic number */
+ .word 512 - GRUB_BOOT_AOUT_HEADER_SIZE /* size of text segment */
+ .word 0/* size of initialized data */
+ .word 0/* size of uninitialized data
*/
+ .word 0/* size of symbol table ||
checksum */
+ .word _start /* entry point */
+ .word 0/* size of text relocation */
+ .word 0/* size of data relocation */
.globl _start
_start:
/* OF CIF entry point arrives in %o4 */
@@ -41,9 +53,9 @@ pic_base:
* After loading in that block we will execute it by jumping to the
* load address plus the size of the prepended A.OUT header (32 bytes).
*/
- .org GRUB_BOOT_MACHINE_BOOT_DEVPATH
+ .org GRUB_BOOT_MACHINE_BOOT_DEVPATH + GRUB_BOOT_AOUT_HEADER_SIZE
boot_path:
- .org GRUB_BOOT_MACHINE_KERNEL_BYTE
+ .org GRUB_BOOT_MACHINE_KERNEL_BYTE + GRUB_BOOT_AOUT_HEADER_SIZE
boot_path_end:
kernel_byte: .xword (2 << 9)
kernel_address:.word GRUB_BOOT_MACHINE_KERNEL_ADDR
@@ -52,7 +64,7 @@ kernel_address: .word
GRUB_BOOT_MACHINE_KERNEL_ADDR
#define boot_path_end (_start + 1024)
#include
- .org 8
+ .org 8 + GRUB_BOOT_AOUT_HEADER_SIZE
kernel_byte: .xword (2 << 9)
kernel_size: .word 512
kernel_address:.word GRUB_BOOT_SPARC64_IEEE1275_IMAGE_ADDRESS
diff --git a/include/grub/sparc64/ieee1275/boot.h
b/include/grub/sparc64/ieee1275/boot.h
index 02d53f28e..cc5a941e3 100644
--- a/include/grub/sparc64/ieee1275/boot.h
+++ b/include/grub/sparc64/ieee1275/boot.h
@@ -46,8 +46,7 @@
#define GRUB_BOOT_MACHINE_KERNEL_BYTE 0x80
-#define GRUB_BOOT_MACHINE_CODE_END \
- (0x1fc - GRUB_BOOT_AOUT_HEADER_SIZE)
+#define GRUB_BOOT_MACHINE_CODE_END 0x1fc
#define GRUB_BOOT_MACHINE_KERNEL_ADDR 0x4200
--
2.20.1
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] ieee1275: Include a.out header in assembly of sparc64 boot loader
This is supposed to be version 3. Forgot to edit the subject.
Adrian
On 2/9/19 2:39 PM, John Paul Adrian Glaubitz wrote:
> Recent versions of binutils dropped support for the a.out and COFF
> formats on sparc64 targets. Since the boot loader on sparc64 is
> supposed to be an a.out binary and the a.out header entries are
> rather simple to calculate in our case, we just write the header
> ourselves instead of relying on external tools to do that.
>
> Signed-off-by: John Paul Adrian Glaubitz
> ---
> v2:
> - fix grammar in long description
> v3:
> - fix formatting in assembly code
> - update comment in boot loader for consistency
>
> grub-core/Makefile.core.def| 6 ++
> grub-core/boot/sparc64/ieee1275/boot.S | 18 +++---
> include/grub/sparc64/ieee1275/boot.h | 3 +--
> 3 files changed, 18 insertions(+), 9 deletions(-)
>
> diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
> index e16fb06ba..f9f845828 100644
> --- a/grub-core/Makefile.core.def
> +++ b/grub-core/Makefile.core.def
> @@ -402,8 +402,7 @@ image = {
>i386_qemu_ldflags =
> '$(TARGET_IMG_BASE_LDOPT),$(GRUB_BOOT_MACHINE_LINK_ADDR)';
>i386_qemu_ccasflags =
> '-DGRUB_BOOT_MACHINE_LINK_ADDR=$(GRUB_BOOT_MACHINE_LINK_ADDR)';
>
> - sparc64_ieee1275_objcopyflags = '-O a.out-sunos-big';
> - sparc64_ieee1275_ldflags = ' -Wl,-Ttext=0x4000';
> + sparc64_ieee1275_ldflags = ' -Wl,-Ttext=0x3fe0';
>
>objcopyflags = '-O binary';
>enable = i386_pc;
> @@ -432,8 +431,7 @@ image = {
>i386_pc_ldflags = '$(TARGET_IMG_BASE_LDOPT),0x7C00';
>
>sparc64_ieee1275 = boot/sparc64/ieee1275/boot.S;
> - sparc64_ieee1275_objcopyflags = '-O a.out-sunos-big';
> - sparc64_ieee1275_ldflags = ' -Wl,-Ttext=0x4000';
> + sparc64_ieee1275_ldflags = ' -Wl,-Ttext=0x3fe0';
>sparc64_ieee1275_cppflags = '-DCDBOOT=1';
>
>objcopyflags = '-O binary';
> diff --git a/grub-core/boot/sparc64/ieee1275/boot.S
> b/grub-core/boot/sparc64/ieee1275/boot.S
> index 9ea9b4e06..a534e1853 100644
> --- a/grub-core/boot/sparc64/ieee1275/boot.S
> +++ b/grub-core/boot/sparc64/ieee1275/boot.S
> @@ -21,6 +21,18 @@
>
> .text
> .align 4
> + /* We're writing the a.out header ourselves as newer
> + * upstream versions of binutils no longer support
> + * the a.out format on sparc64.
> + */
> + .word 0x1030107/* magic number */
> + .word 512 - GRUB_BOOT_AOUT_HEADER_SIZE /* size of text segment */
> + .word 0/* size of initialized data */
> + .word 0/* size of uninitialized data
> */
> + .word 0/* size of symbol table ||
> checksum */
> + .word _start /* entry point */
> + .word 0/* size of text relocation */
> + .word 0/* size of data relocation */
> .globl _start
> _start:
> /* OF CIF entry point arrives in %o4 */
> @@ -41,9 +53,9 @@ pic_base:
>* After loading in that block we will execute it by jumping to the
>* load address plus the size of the prepended A.OUT header (32 bytes).
>*/
> - .org GRUB_BOOT_MACHINE_BOOT_DEVPATH
> + .org GRUB_BOOT_MACHINE_BOOT_DEVPATH + GRUB_BOOT_AOUT_HEADER_SIZE
> boot_path:
> - .org GRUB_BOOT_MACHINE_KERNEL_BYTE
> + .org GRUB_BOOT_MACHINE_KERNEL_BYTE + GRUB_BOOT_AOUT_HEADER_SIZE
> boot_path_end:
> kernel_byte: .xword (2 << 9)
> kernel_address: .word GRUB_BOOT_MACHINE_KERNEL_ADDR
> @@ -52,7 +64,7 @@ kernel_address: .word
> GRUB_BOOT_MACHINE_KERNEL_ADDR
> #define boot_path_end (_start + 1024)
> #include
>
> - .org 8
> + .org 8 + GRUB_BOOT_AOUT_HEADER_SIZE
> kernel_byte: .xword (2 << 9)
> kernel_size: .word 512
> kernel_address: .word GRUB_BOOT_SPARC64_IEEE1275_IMAGE_ADDRESS
> diff --git a/include/grub/sparc64/ieee1275/boot.h
> b/include/grub/sparc64/ieee1275/boot.h
> index 02d53f28e..cc5a941e3 100644
> --- a/include/grub/sparc64/ieee1275/boot.h
> +++ b/include/grub/sparc64/ieee1275/boot.h
> @@ -46,8 +46,7 @@
>
> #define GRUB_BOOT_MACHINE_KERNEL_BYTE 0x80
>
> -#define GRUB_BOOT_MACHINE_CODE_END \
> - (0x1fc - GRUB_BOOT_AOUT_HEADER_SIZE)
> +#define GRUB_BOOT_MACHINE_CODE_END 0x1fc
>
> #define GRUB_BOOT_MACHINE_KERNEL_ADDR 0x4200
>
>
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Ping: [PATCH, v3] ieee1275: Include a.out header in assembly of sparc64 boot loader
Recent versions of binutils dropped support for the a.out and COFF
formats on sparc64 targets. Since the boot loader on sparc64 is
supposed to be an a.out binary and the a.out header entries are
rather simple to calculate in our case, we just write the header
ourselves instead of relying on external tools to do that.
Signed-off-by: John Paul Adrian Glaubitz
---
v2:
- fix grammar in long description
v3:
- fix formatting in assembly code
- update comment in boot loader for consistency
grub-core/Makefile.core.def| 6 ++
grub-core/boot/sparc64/ieee1275/boot.S | 18 +++---
include/grub/sparc64/ieee1275/boot.h | 3 +--
3 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
index e16fb06ba..f9f845828 100644
--- a/grub-core/Makefile.core.def
+++ b/grub-core/Makefile.core.def
@@ -402,8 +402,7 @@ image = {
i386_qemu_ldflags =
'$(TARGET_IMG_BASE_LDOPT),$(GRUB_BOOT_MACHINE_LINK_ADDR)';
i386_qemu_ccasflags =
'-DGRUB_BOOT_MACHINE_LINK_ADDR=$(GRUB_BOOT_MACHINE_LINK_ADDR)';
- sparc64_ieee1275_objcopyflags = '-O a.out-sunos-big';
- sparc64_ieee1275_ldflags = ' -Wl,-Ttext=0x4000';
+ sparc64_ieee1275_ldflags = ' -Wl,-Ttext=0x3fe0';
objcopyflags = '-O binary';
enable = i386_pc;
@@ -432,8 +431,7 @@ image = {
i386_pc_ldflags = '$(TARGET_IMG_BASE_LDOPT),0x7C00';
sparc64_ieee1275 = boot/sparc64/ieee1275/boot.S;
- sparc64_ieee1275_objcopyflags = '-O a.out-sunos-big';
- sparc64_ieee1275_ldflags = ' -Wl,-Ttext=0x4000';
+ sparc64_ieee1275_ldflags = ' -Wl,-Ttext=0x3fe0';
sparc64_ieee1275_cppflags = '-DCDBOOT=1';
objcopyflags = '-O binary';
diff --git a/grub-core/boot/sparc64/ieee1275/boot.S
b/grub-core/boot/sparc64/ieee1275/boot.S
index 9ea9b4e06..a534e1853 100644
--- a/grub-core/boot/sparc64/ieee1275/boot.S
+++ b/grub-core/boot/sparc64/ieee1275/boot.S
@@ -21,6 +21,18 @@
.text
.align 4
+ /* We're writing the a.out header ourselves as newer
+* upstream versions of binutils no longer support
+* the a.out format on sparc64.
+*/
+ .word 0x1030107/* magic number */
+ .word 512 - GRUB_BOOT_AOUT_HEADER_SIZE /* size of text segment */
+ .word 0/* size of initialized data */
+ .word 0/* size of uninitialized data
*/
+ .word 0/* size of symbol table ||
checksum */
+ .word _start /* entry point */
+ .word 0/* size of text relocation */
+ .word 0/* size of data relocation */
.globl _start
_start:
/* OF CIF entry point arrives in %o4 */
@@ -41,9 +53,9 @@ pic_base:
* After loading in that block we will execute it by jumping to the
* load address plus the size of the prepended A.OUT header (32 bytes).
*/
- .org GRUB_BOOT_MACHINE_BOOT_DEVPATH
+ .org GRUB_BOOT_MACHINE_BOOT_DEVPATH + GRUB_BOOT_AOUT_HEADER_SIZE
boot_path:
- .org GRUB_BOOT_MACHINE_KERNEL_BYTE
+ .org GRUB_BOOT_MACHINE_KERNEL_BYTE + GRUB_BOOT_AOUT_HEADER_SIZE
boot_path_end:
kernel_byte: .xword (2 << 9)
kernel_address:.word GRUB_BOOT_MACHINE_KERNEL_ADDR
@@ -52,7 +64,7 @@ kernel_address: .word
GRUB_BOOT_MACHINE_KERNEL_ADDR
#define boot_path_end (_start + 1024)
#include
- .org 8
+ .org 8 + GRUB_BOOT_AOUT_HEADER_SIZE
kernel_byte: .xword (2 << 9)
kernel_size: .word 512
kernel_address:.word GRUB_BOOT_SPARC64_IEEE1275_IMAGE_ADDRESS
diff --git a/include/grub/sparc64/ieee1275/boot.h
b/include/grub/sparc64/ieee1275/boot.h
index 02d53f28e..cc5a941e3 100644
--- a/include/grub/sparc64/ieee1275/boot.h
+++ b/include/grub/sparc64/ieee1275/boot.h
@@ -46,8 +46,7 @@
#define GRUB_BOOT_MACHINE_KERNEL_BYTE 0x80
-#define GRUB_BOOT_MACHINE_CODE_END \
- (0x1fc - GRUB_BOOT_AOUT_HEADER_SIZE)
+#define GRUB_BOOT_MACHINE_CODE_END 0x1fc
#define GRUB_BOOT_MACHINE_KERNEL_ADDR 0x4200
--
2.20.1
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] ieee1275: Include a.out header in assembly of sparc64 boot loader
Hi Daniel!
Thanks for the review!
On 2/20/19 9:59 PM, Daniel Kiper wrote:
> On Sat, Feb 09, 2019 at 02:39:05PM +0100, John Paul Adrian Glaubitz wrote:
>> Recent versions of binutils dropped support for the a.out and COFF
>> formats on sparc64 targets. Since the boot loader on sparc64 is
>> supposed to be an a.out binary and the a.out header entries are
>> rather simple to calculate in our case, we just write the header
>> ourselves instead of relying on external tools to do that.
>
> I am OK with the approach but:
> - I would like to hear Eric's opinion about it;
> or even see his RB on the final version of the patch,
Ok.
>> - sparc64_ieee1275_objcopyflags = '-O a.out-sunos-big';
>> - sparc64_ieee1275_ldflags = ' -Wl,-Ttext=0x4000';
>> + sparc64_ieee1275_ldflags = ' -Wl,-Ttext=0x3fe0';
>
> I would like to ask you to add the comment what this number means and
> why this number.
This is just the offset of the text segment adjusted with the a.out
header added to the beginning of the assembly code. As we're writing
out the header in the assembly source ourselves, we have to adjust
the offset.
The entry point is at 0x4000.
>>objcopyflags = '-O binary';
>>enable = i386_pc;
>> @@ -432,8 +431,7 @@ image = {
>>i386_pc_ldflags = '$(TARGET_IMG_BASE_LDOPT),0x7C00';
>>
>>sparc64_ieee1275 = boot/sparc64/ieee1275/boot.S;
>> - sparc64_ieee1275_objcopyflags = '-O a.out-sunos-big';
>> - sparc64_ieee1275_ldflags = ' -Wl,-Ttext=0x4000';
>> + sparc64_ieee1275_ldflags = ' -Wl,-Ttext=0x3fe0';
>
> Ditto.
Same here.
>>sparc64_ieee1275_cppflags = '-DCDBOOT=1';
>>
>>objcopyflags = '-O binary';
>> diff --git a/grub-core/boot/sparc64/ieee1275/boot.S
>> b/grub-core/boot/sparc64/ieee1275/boot.S
>> index 9ea9b4e06..a534e1853 100644
>> --- a/grub-core/boot/sparc64/ieee1275/boot.S
>> +++ b/grub-core/boot/sparc64/ieee1275/boot.S
>> @@ -21,6 +21,18 @@
>>
>> .text
>> .align 4
>> +/* We're writing the a.out header ourselves as newer
>> + * upstream versions of binutils no longer support
>> + * the a.out format on sparc64.
>> + */
>> +.word 0x1030107/* magic number */
>> +.word 512 - GRUB_BOOT_AOUT_HEADER_SIZE /* size of text segment */
>
> Why 512 - GRUB_BOOT_AOUT_HEADER_SIZE? Please add the comment.
The complete sector size is 512 but we have to make space for the header.
>> +.word 0/* size of initialized data */
>> +.word 0/* size of uninitialized data
>> */
>> +.word 0/* size of symbol table ||
>> checksum */
>> +.word _start /* entry point */
>> +.word 0/* size of text relocation */
>> +.word 0/* size of data relocation */
>
> I assume that 0 means that we do not care. Could you say it somewhere in the
> comments?
We just have a text section, nothing else. Hence everything else is zero.
>> .globl _start
>> _start:
>> /* OF CIF entry point arrives in %o4 */
>> @@ -41,9 +53,9 @@ pic_base:
>> * After loading in that block we will execute it by jumping to the
>> * load address plus the size of the prepended A.OUT header (32 bytes).
>> */
>> -.org GRUB_BOOT_MACHINE_BOOT_DEVPATH
>> +.org GRUB_BOOT_MACHINE_BOOT_DEVPATH + GRUB_BOOT_AOUT_HEADER_SIZE
>> boot_path:
>> -.org GRUB_BOOT_MACHINE_KERNEL_BYTE
>> +.org GRUB_BOOT_MACHINE_KERNEL_BYTE + GRUB_BOOT_AOUT_HEADER_SIZE
>> boot_path_end:
>> kernel_byte:.xword (2 << 9)
>> kernel_address: .word GRUB_BOOT_MACHINE_KERNEL_ADDR
>> @@ -52,7 +64,7 @@ kernel_address: .word
>> GRUB_BOOT_MACHINE_KERNEL_ADDR
>> #define boot_path_end (_start + 1024)
>> #include
>>
>> -.org 8
>> +.org 8 + GRUB_BOOT_AOUT_HEADER_SIZE
>
> If you touch code like that please add comment why 8 +
> GRUB_BOOT_AOUT_HEADER_SIZE.
> Or use a constant with meaningful name instead of 8.
The 8 is already there. The offset is again just being adjusted to accommodate
the a.out header size which we're now adding ourselves instead of letting
binutils do it for us.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] ieee1275: Include a.out header in assembly of sparc64 boot loader
Hi Daniel! On 2/21/19 4:40 PM, Daniel Kiper wrote: > If you sprinkle the comments similar to above ones into the code then > I will be happy with the patch. Ok, thanks. I'll try to get around doing it tomorrow. > And sorry for late reply but I am recovering after the travel. No worries. I'm currently moving apartments and I don't have much time for the fun stuff at the moment either. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB 2.04 freeze date announcement
Hi Vladimir! On 3/1/19 12:31 PM, Vladimir 'phcoder' Serbinenko wrote: > We are happy to announce that the upcoming release of Grub 2.04 is expected > in March. In order to prepare the release we would freeze on Monday, March > 11, 23:59:59 UTC. From that point no new features are accepted unless there > is a very good reason to. We will still accept bugfixes. In fact we kindly > ask to test systems and features you care about Those are fantastic news. I will hurry up then to post an updated version of my sparc64 build fix so that it can land in version 2.04 such that GRUB will build fine on sparc64 targets without any additional patches. Really looking forward to this release! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH V3] ieee1275: obdisk driver
On 3/8/19 4:05 AM, Daniel Kiper wrote: > OK, thanks. Then Reviewed-by: Daniel Kiper > > If there are no objections I will apply this patch next week. > > Thank you for doing the work. Yay, awesome \o/. @Eric: What do you think about my patch to write the a.out header manually? See: http://lists.gnu.org/archive/html/grub-devel/2019-02/msg00084.html Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] ieee1275: Include a.out header in assembly of sparc64 boot loader
Recent versions of binutils dropped support for the a.out and COFF
formats on sparc64 targets. Since the boot loader on sparc64 is
supposed to be an a.out binary and the a.out header entries are
rather simple to calculate in our case, we just write the header
ourselves instead of relying on external tools to do that.
Signed-off-by: John Paul Adrian Glaubitz
---
v2:
- fix grammar in long description
v3:
- fix formatting in assembly code
- update comment in boot loader for consistency
v4:
- add comments to explain offset adjustments and a.out header fields
grub-core/Makefile.core.def| 19 ++
grub-core/boot/sparc64/ieee1275/boot.S | 27 +++---
include/grub/sparc64/ieee1275/boot.h | 3 +--
3 files changed, 40 insertions(+), 9 deletions(-)
diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
index 43ed42191..5ed4643d2 100644
--- a/grub-core/Makefile.core.def
+++ b/grub-core/Makefile.core.def
@@ -425,8 +425,13 @@ image = {
i386_qemu_ldflags =
'$(TARGET_IMG_BASE_LDOPT),$(GRUB_BOOT_MACHINE_LINK_ADDR)';
i386_qemu_ccasflags =
'-DGRUB_BOOT_MACHINE_LINK_ADDR=$(GRUB_BOOT_MACHINE_LINK_ADDR)';
- sparc64_ieee1275_objcopyflags = '-O a.out-sunos-big';
- sparc64_ieee1275_ldflags = ' -Wl,-Ttext=0x4000';
+ /* The entry point for a.out binaries on sparc64 starts
+ at 0x4000. Since we are writing the 32 bytes long a.out
+ header in the assembly code ourselves, we need to tell
+ the linker to adjust the start of the text segment to
+ 0x4000 - 0x20 = 0x3fe0.
+ */
+ sparc64_ieee1275_ldflags = ' -Wl,-Ttext=0x3fe0';
objcopyflags = '-O binary';
enable = i386_pc;
@@ -455,8 +460,14 @@ image = {
i386_pc_ldflags = '$(TARGET_IMG_BASE_LDOPT),0x7C00';
sparc64_ieee1275 = boot/sparc64/ieee1275/boot.S;
- sparc64_ieee1275_objcopyflags = '-O a.out-sunos-big';
- sparc64_ieee1275_ldflags = ' -Wl,-Ttext=0x4000';
+
+ /* The entry point for a.out binaries on sparc64 starts
+ at 0x4000. Since we are writing the 32 bytes long a.out
+ header in the assembly code ourselves, we need to tell
+ the linker to adjust the start of the text segment to
+ 0x4000 - 0x20 = 0x3fe0.
+ */
+ sparc64_ieee1275_ldflags = ' -Wl,-Ttext=0x3fe0';
sparc64_ieee1275_cppflags = '-DCDBOOT=1';
objcopyflags = '-O binary';
diff --git a/grub-core/boot/sparc64/ieee1275/boot.S
b/grub-core/boot/sparc64/ieee1275/boot.S
index 9ea9b4e06..ed3aec464 100644
--- a/grub-core/boot/sparc64/ieee1275/boot.S
+++ b/grub-core/boot/sparc64/ieee1275/boot.S
@@ -21,6 +21,23 @@
.text
.align 4
+ /* We're writing the a.out header ourselves as newer
+* upstream versions of binutils no longer support
+* the a.out format on sparc64.
+*
+* The boot loader fits into 512 bytes with 32 bytes
+* used for the a.out header, hence the text segment
+* size is 512 - 32. There is no data segment and no
+* code relocation, thus those fields remain zero.
+*/
+ .word 0x1030107/* magic number */
+ .word 512 - GRUB_BOOT_AOUT_HEADER_SIZE /* size of text segment */
+ .word 0/* size of initialized data */
+ .word 0/* size of uninitialized data
*/
+ .word 0/* size of symbol table ||
checksum */
+ .word _start /* entry point */
+ .word 0/* size of text relocation */
+ .word 0/* size of data relocation */
.globl _start
_start:
/* OF CIF entry point arrives in %o4 */
@@ -40,10 +57,14 @@ pic_base:
*
* After loading in that block we will execute it by jumping to the
* load address plus the size of the prepended A.OUT header (32 bytes).
+*
+* Since this assembly code includes the 32 bytes long a.out header,
+* we need to move the actual code entry point forward by the size
+* of the a.out header, i.e. += GRUB_BOOT_AOUT_HEADER_SIZE.
*/
- .org GRUB_BOOT_MACHINE_BOOT_DEVPATH
+ .org GRUB_BOOT_MACHINE_BOOT_DEVPATH + GRUB_BOOT_AOUT_HEADER_SIZE
boot_path:
- .org GRUB_BOOT_MACHINE_KERNEL_BYTE
+ .org GRUB_BOOT_MACHINE_KERNEL_BYTE + GRUB_BOOT_AOUT_HEADER_SIZE
boot_path_end:
kernel_byte: .xword (2 << 9)
kernel_address:.word GRUB_BOOT_MACHINE_KERNEL_ADDR
@@ -52,7 +73,7 @@ kernel_address: .word
GRUB_BOOT_MACHINE_KERNEL_ADDR
#define boot_path_end (_start + 1024)
#include
- .org 8
+ .org 8 + GRUB_BOOT_AOUT_HEADER_SIZE
kernel_byte: .xword (2 << 9)
kernel_size: .word 512
kernel_address:.word GRUB_BOOT
Build fails with missing save-cwd.h header
Hi! I'm currently test-building GRUB on various architectures to make sure it builds fine when 2.04 is released. Currently, I am always running into an issue with the "save-cwd.h" header missing: grub-core/osdep/unix/getroot.c:117:10: fatal error: save-cwd.h: No such file or directory #include "save-cwd.h" ^~~~ I'm building with: $ make clean && ./autogen.sh && ./configure && make -j16 Before digging through code myself, I was wondering whether I am missing something obvious, although it looks like we're missing the include path being passed to the compiler where save-cwd.h is sitting in the source tree. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Build fails with missing save-cwd.h header
On 3/25/19 12:34 PM, Daniel Kiper wrote: >> Before digging through code myself, I was wondering whether I am missing >> something >> obvious, although it looks like we're missing the include path being passed >> to >> the compiler where save-cwd.h is sitting in the source tree. > > Could you clone clean GRUB git repo and run ./bootstrap instead of > ./autogen.sh? Right, for some reason I forgot about that. Builds fine with my patch on sparc64 on Debian unstable now. Now for some testing on various PowerPC targets. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] ieee1275: Include a.out header in assembly of sparc64 boot loader
On 3/25/19 6:17 PM, John Paul Adrian Glaubitz wrote: >> $ grub-install --force --skip-fs-probe /dev/sdb1 >> Installing for sparc64-ieee1275 platform. >> grub-install: error: the size of `/boot/grub/sparc64-ieee1275/boot.img' is >> not 512. >> >> $ ls -al /boot/grub/sparc64-ieee1275/boot.img >> -rw-r--r--. 1 root root 544 Mar 25 12:10 /boot/grub/sparc64-ieee1275/boot.img > > Hmm, let me have another look. Thanks for testing. I am not done testing yet but I just realized, 544 = 512 + 32, so it looks like the a.out header is appended twice. Does an older binutils maybe default to a.out when just passing binary as the output format? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] ieee1275: Include a.out header in assembly of sparc64 boot loader
On 3/25/19 5:20 PM, Eric Snowberg wrote: > I tried it out, but on my system it doesn’t fit in the 512 byte block? Am I > missing something? > > Before the patch: > > $ grub-install --force --skip-fs-probe /dev/sdb1 > Installing for sparc64-ieee1275 platform. > grub-install: warning: Attempting to install GRUB to a partitionless disk or > to a partition. This is a BAD idea.. > grub-install: warning: Embedding is not possible. GRUB can only be installed > in this setup by using blocklists. However, blocklists are UNRELIABLE and > their use is discouraged.. > Installation finished. No error reported. > > $ ls -al /boot/grub/sparc64-ieee1275/boot.img > -rw-r--r--. 1 root root 512 Mar 25 12:13 /boot/grub/sparc64-ieee1275/boot.img > > After: > > $ grub-install --force --skip-fs-probe /dev/sdb1 > Installing for sparc64-ieee1275 platform. > grub-install: error: the size of `/boot/grub/sparc64-ieee1275/boot.img' is > not 512. > > $ ls -al /boot/grub/sparc64-ieee1275/boot.img > -rw-r--r--. 1 root root 544 Mar 25 12:10 /boot/grub/sparc64-ieee1275/boot.img Hmm, let me have another look. Thanks for testing. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] ieee1275: Include a.out header in assembly of sparc64 boot loader
On 3/25/19 6:22 PM, John Paul Adrian Glaubitz wrote: > I am not done testing yet but I just realized, 544 = 512 + 32, so it looks > like the a.out header is appended twice. Does an older binutils maybe default > to a.out when just passing binary as the output format? Just did another test build, the sizes are correct for me: glaubitz@kyoto:~/grub/grub-core$ ls -l *img -rwxr-xr-x 1 glaubitz glaubitz 512 Mar 25 19:02 boot.img -rwxr-xr-x 1 glaubitz glaubitz 512 Mar 25 19:02 cdboot.img -rwxr-xr-x 1 glaubitz glaubitz 512 Mar 25 19:02 diskboot.img -rwxr-xr-x 1 glaubitz glaubitz 85888 Mar 25 19:02 kernel.img glaubitz@kyoto:~/grub/grub-core$ I will try it with an older version of binutils then and see what happens. Will take a little longer as I also need to downgrade gcc and related libraries as gcc-8 pulls in the newer binutils. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] ieee1275: Include a.out header in assembly of sparc64 boot loader
On 3/25/19 5:20 PM, Eric Snowberg wrote: > I tried it out, but on my system it doesn’t fit in the 512 byte block? Am I > missing something? > > Before the patch: > > $ grub-install --force --skip-fs-probe /dev/sdb1 > Installing for sparc64-ieee1275 platform. > grub-install: warning: Attempting to install GRUB to a partitionless disk or > to a partition. This is a BAD idea.. > grub-install: warning: Embedding is not possible. GRUB can only be installed > in this setup by using blocklists. However, blocklists are UNRELIABLE and > their use is discouraged.. > Installation finished. No error reported. > > $ ls -al /boot/grub/sparc64-ieee1275/boot.img > -rw-r--r--. 1 root root 512 Mar 25 12:13 /boot/grub/sparc64-ieee1275/boot.img > > After: > > $ grub-install --force --skip-fs-probe /dev/sdb1 > Installing for sparc64-ieee1275 platform. > grub-install: error: the size of `/boot/grub/sparc64-ieee1275/boot.img' is > not 512. > > $ ls -al /boot/grub/sparc64-ieee1275/boot.img > -rw-r--r--. 1 root root 544 Mar 25 12:10 /boot/grub/sparc64-ieee1275/boot.img Could you tell me what build environment this is? Is this on Solaris? I want to try reproducing it, so I can figure what happened. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] ieee1275: Include a.out header in assembly of sparc64 boot loader
On 3/25/19 9:41 PM, Eric Snowberg wrote:
>> Is this on Solaris? I want to try reproducing it, so I can figure what
>> happened.
>>
>
> I’m using Oracle Linux for SPARC (6.9).
Ok, so it can only be a matter of the older binutils version implicitly
assuming the output format to be a.out.
Could you try the modified patch? I'm explicitly passing "-O binary"
now for the sparc64_ieee1275_objcopyflags.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
index 43ed42191..65f4ef1f7 100644
--- a/grub-core/Makefile.core.def
+++ b/grub-core/Makefile.core.def
@@ -425,8 +425,14 @@ image = {
i386_qemu_ldflags = '$(TARGET_IMG_BASE_LDOPT),$(GRUB_BOOT_MACHINE_LINK_ADDR)';
i386_qemu_ccasflags = '-DGRUB_BOOT_MACHINE_LINK_ADDR=$(GRUB_BOOT_MACHINE_LINK_ADDR)';
- sparc64_ieee1275_objcopyflags = '-O a.out-sunos-big';
- sparc64_ieee1275_ldflags = ' -Wl,-Ttext=0x4000';
+ sparc64_ieee1275_objcopyflags = '-O binary';
+ /* The entry point for a.out binaries on sparc64 starts
+ at 0x4000. Since we are writing the 32 bytes long a.out
+ header in the assembly code ourselves, we need to tell
+ the linker to adjust the start of the text segment to
+ 0x4000 - 0x20 = 0x3fe0.
+ */
+ sparc64_ieee1275_ldflags = ' -Wl,-Ttext=0x3fe0';
objcopyflags = '-O binary';
enable = i386_pc;
@@ -455,8 +461,15 @@ image = {
i386_pc_ldflags = '$(TARGET_IMG_BASE_LDOPT),0x7C00';
sparc64_ieee1275 = boot/sparc64/ieee1275/boot.S;
- sparc64_ieee1275_objcopyflags = '-O a.out-sunos-big';
- sparc64_ieee1275_ldflags = ' -Wl,-Ttext=0x4000';
+
+ sparc64_ieee1275_objcopyflags = '-O binary';
+ /* The entry point for a.out binaries on sparc64 starts
+ at 0x4000. Since we are writing the 32 bytes long a.out
+ header in the assembly code ourselves, we need to tell
+ the linker to adjust the start of the text segment to
+ 0x4000 - 0x20 = 0x3fe0.
+ */
+ sparc64_ieee1275_ldflags = ' -Wl,-Ttext=0x3fe0';
sparc64_ieee1275_cppflags = '-DCDBOOT=1';
objcopyflags = '-O binary';
diff --git a/grub-core/boot/sparc64/ieee1275/boot.S b/grub-core/boot/sparc64/ieee1275/boot.S
index 9ea9b4e06..ed3aec464 100644
--- a/grub-core/boot/sparc64/ieee1275/boot.S
+++ b/grub-core/boot/sparc64/ieee1275/boot.S
@@ -21,6 +21,23 @@
.text
.align 4
+ /* We're writing the a.out header ourselves as newer
+ * upstream versions of binutils no longer support
+ * the a.out format on sparc64.
+ *
+ * The boot loader fits into 512 bytes with 32 bytes
+ * used for the a.out header, hence the text segment
+ * size is 512 - 32. There is no data segment and no
+ * code relocation, thus those fields remain zero.
+ */
+ .word 0x1030107/* magic number */
+ .word 512 - GRUB_BOOT_AOUT_HEADER_SIZE /* size of text segment */
+ .word 0/* size of initialized data */
+ .word 0/* size of uninitialized data */
+ .word 0/* size of symbol table || checksum */
+ .word _start /* entry point */
+ .word 0/* size of text relocation */
+ .word 0/* size of data relocation */
.globl _start
_start:
/* OF CIF entry point arrives in %o4 */
@@ -40,10 +57,14 @@ pic_base:
*
* After loading in that block we will execute it by jumping to the
* load address plus the size of the prepended A.OUT header (32 bytes).
+ *
+ * Since this assembly code includes the 32 bytes long a.out header,
+ * we need to move the actual code entry point forward by the size
+ * of the a.out header, i.e. += GRUB_BOOT_AOUT_HEADER_SIZE.
*/
- .org GRUB_BOOT_MACHINE_BOOT_DEVPATH
+ .org GRUB_BOOT_MACHINE_BOOT_DEVPATH + GRUB_BOOT_AOUT_HEADER_SIZE
boot_path:
- .org GRUB_BOOT_MACHINE_KERNEL_BYTE
+ .org GRUB_BOOT_MACHINE_KERNEL_BYTE + GRUB_BOOT_AOUT_HEADER_SIZE
boot_path_end:
kernel_byte: .xword (2 << 9)
kernel_address: .word GRUB_BOOT_MACHINE_KERNEL_ADDR
@@ -52,7 +73,7 @@ kernel_address: .word GRUB_BOOT_MACHINE_KERNEL_ADDR
#define boot_path_end (_start + 1024)
#include
- .org 8
+ .org 8 + GRUB_BOOT_AOUT_HEADER_SIZE
kernel_byte: .xword (2 << 9)
kernel_size: .word 512
kernel_address: .word GRUB_BOOT_SPARC64_IEEE1275_IMAGE_ADDRESS
diff --git a/include/grub/sparc64/ieee1275/boot.h b/include/grub/sparc64/ieee1275/boot.h
index 02d53f28e..cc5a941e3 100644
--- a/include/grub/sparc64/ieee1275/boot.h
+++ b/include/grub/sparc64/ieee1275/boot.h
@@ -46,8 +46,7 @
Build test report on non-x86 targets
Hi! For the upcoming release, I have made build tests on all non-x86 targets we have in Debian unstable which are supposed to support GRUB. These are: * armel * armhf * ia64 * mipsel * mips * mips64el * powerpc * ppc64 * ppc64el * s390x * sparc64 I'm happy to report that GRUB builds fine on these targets without any additional patches or modifications necessary, except for sparc64 which needs my a.out patch for which I will send an updated revision later today. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH, v5] ieee1275: Include a.out header in assembly of sparc64 boot loader
Recent versions of binutils dropped support for the a.out and COFF
formats on sparc64 targets. Since the boot loader on sparc64 is
supposed to be an a.out binary and the a.out header entries are
rather simple to calculate in our case, we just write the header
ourselves instead of relying on external tools to do that.
Signed-off-by: John Paul Adrian Glaubitz
---
v2:
- fix grammar in long description
v3:
- fix formatting in assembly code
- update comment in boot loader for consistency
v4:
- add comments to explain offset adjustments and a.out header fields
v5:
- explicitly pass '-O binary' in sparc64_ieee1275_objcopyflags to force binary
output
- avoid redundant comments in grub-core/Makefile.core.def
- slightly reformat grub-core/Makefile.core.def for better readability
grub-core/Makefile.core.def| 16 +++
grub-core/boot/sparc64/ieee1275/boot.S | 27 +++---
include/grub/sparc64/ieee1275/boot.h | 3 +--
3 files changed, 37 insertions(+), 9 deletions(-)
diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
index 43ed42191..cda8ea34c 100644
--- a/grub-core/Makefile.core.def
+++ b/grub-core/Makefile.core.def
@@ -425,8 +425,14 @@ image = {
i386_qemu_ldflags =
'$(TARGET_IMG_BASE_LDOPT),$(GRUB_BOOT_MACHINE_LINK_ADDR)';
i386_qemu_ccasflags =
'-DGRUB_BOOT_MACHINE_LINK_ADDR=$(GRUB_BOOT_MACHINE_LINK_ADDR)';
- sparc64_ieee1275_objcopyflags = '-O a.out-sunos-big';
- sparc64_ieee1275_ldflags = ' -Wl,-Ttext=0x4000';
+ /* The entry point for a.out binaries on sparc64 starts
+ at 0x4000. Since we are writing the 32 bytes long a.out
+ header in the assembly code ourselves, we need to tell
+ the linker to adjust the start of the text segment to
+ 0x4000 - 0x20 = 0x3fe0.
+ */
+ sparc64_ieee1275_ldflags = ' -Wl,-Ttext=0x3fe0';
+ sparc64_ieee1275_objcopyflags = '-O binary';
objcopyflags = '-O binary';
enable = i386_pc;
@@ -455,8 +461,10 @@ image = {
i386_pc_ldflags = '$(TARGET_IMG_BASE_LDOPT),0x7C00';
sparc64_ieee1275 = boot/sparc64/ieee1275/boot.S;
- sparc64_ieee1275_objcopyflags = '-O a.out-sunos-big';
- sparc64_ieee1275_ldflags = ' -Wl,-Ttext=0x4000';
+
+ /* See comment for sparc64_ieee1275_ldflags above */
+ sparc64_ieee1275_ldflags = ' -Wl,-Ttext=0x3fe0';
+ sparc64_ieee1275_objcopyflags = '-O binary';
sparc64_ieee1275_cppflags = '-DCDBOOT=1';
objcopyflags = '-O binary';
diff --git a/grub-core/boot/sparc64/ieee1275/boot.S
b/grub-core/boot/sparc64/ieee1275/boot.S
index 9ea9b4e06..ed3aec464 100644
--- a/grub-core/boot/sparc64/ieee1275/boot.S
+++ b/grub-core/boot/sparc64/ieee1275/boot.S
@@ -21,6 +21,23 @@
.text
.align 4
+ /* We're writing the a.out header ourselves as newer
+* upstream versions of binutils no longer support
+* the a.out format on sparc64.
+*
+* The boot loader fits into 512 bytes with 32 bytes
+* used for the a.out header, hence the text segment
+* size is 512 - 32. There is no data segment and no
+* code relocation, thus those fields remain zero.
+*/
+ .word 0x1030107/* magic number */
+ .word 512 - GRUB_BOOT_AOUT_HEADER_SIZE /* size of text segment */
+ .word 0/* size of initialized data */
+ .word 0/* size of uninitialized data
*/
+ .word 0/* size of symbol table ||
checksum */
+ .word _start /* entry point */
+ .word 0/* size of text relocation */
+ .word 0/* size of data relocation */
.globl _start
_start:
/* OF CIF entry point arrives in %o4 */
@@ -40,10 +57,14 @@ pic_base:
*
* After loading in that block we will execute it by jumping to the
* load address plus the size of the prepended A.OUT header (32 bytes).
+*
+* Since this assembly code includes the 32 bytes long a.out header,
+* we need to move the actual code entry point forward by the size
+* of the a.out header, i.e. += GRUB_BOOT_AOUT_HEADER_SIZE.
*/
- .org GRUB_BOOT_MACHINE_BOOT_DEVPATH
+ .org GRUB_BOOT_MACHINE_BOOT_DEVPATH + GRUB_BOOT_AOUT_HEADER_SIZE
boot_path:
- .org GRUB_BOOT_MACHINE_KERNEL_BYTE
+ .org GRUB_BOOT_MACHINE_KERNEL_BYTE + GRUB_BOOT_AOUT_HEADER_SIZE
boot_path_end:
kernel_byte: .xword (2 << 9)
kernel_address:.word GRUB_BOOT_MACHINE_KERNEL_ADDR
@@ -52,7 +73,7 @@ kernel_address: .word
GRUB_BOOT_MACHINE_KERNEL_ADDR
#define boot_path_end (_start + 1024)
#include
- .org 8
+ .org 8 + GRUB_BOOT_AOUT_HEADER_SIZE
kerne
[PATCH, v6] ieee1275: Include a.out header in assembly of sparc64 boot loader
Recent versions of binutils dropped support for the a.out and COFF
formats on sparc64 targets. Since the boot loader on sparc64 is
supposed to be an a.out binary and the a.out header entries are
rather simple to calculate in our case, we just write the header
ourselves instead of relying on external tools to do that.
Signed-off-by: John Paul Adrian Glaubitz
---
v2:
- fix grammar in long description
v3:
- fix formatting in assembly code
- update comment in boot loader for consistency
v4:
- add comments to explain offset adjustments and a.out header fields
v5:
- explicitly pass '-O binary' in sparc64_ieee1275_objcopyflags to force binary
output
- avoid redundant comments in grub-core/Makefile.core.def
- slightly reformat grub-core/Makefile.core.def for better readability
v6:
- fix missing period in comment in grub-core/Makefile.core.def
grub-core/Makefile.core.def| 16 +++
grub-core/boot/sparc64/ieee1275/boot.S | 27 +++---
include/grub/sparc64/ieee1275/boot.h | 3 +--
3 files changed, 37 insertions(+), 9 deletions(-)
diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
index 43ed42191..474a63e68 100644
--- a/grub-core/Makefile.core.def
+++ b/grub-core/Makefile.core.def
@@ -425,8 +425,14 @@ image = {
i386_qemu_ldflags =
'$(TARGET_IMG_BASE_LDOPT),$(GRUB_BOOT_MACHINE_LINK_ADDR)';
i386_qemu_ccasflags =
'-DGRUB_BOOT_MACHINE_LINK_ADDR=$(GRUB_BOOT_MACHINE_LINK_ADDR)';
- sparc64_ieee1275_objcopyflags = '-O a.out-sunos-big';
- sparc64_ieee1275_ldflags = ' -Wl,-Ttext=0x4000';
+ /* The entry point for a.out binaries on sparc64 starts
+ at 0x4000. Since we are writing the 32 bytes long a.out
+ header in the assembly code ourselves, we need to tell
+ the linker to adjust the start of the text segment to
+ 0x4000 - 0x20 = 0x3fe0.
+ */
+ sparc64_ieee1275_ldflags = ' -Wl,-Ttext=0x3fe0';
+ sparc64_ieee1275_objcopyflags = '-O binary';
objcopyflags = '-O binary';
enable = i386_pc;
@@ -455,8 +461,10 @@ image = {
i386_pc_ldflags = '$(TARGET_IMG_BASE_LDOPT),0x7C00';
sparc64_ieee1275 = boot/sparc64/ieee1275/boot.S;
- sparc64_ieee1275_objcopyflags = '-O a.out-sunos-big';
- sparc64_ieee1275_ldflags = ' -Wl,-Ttext=0x4000';
+
+ /* See comment for sparc64_ieee1275_ldflags above. */
+ sparc64_ieee1275_ldflags = ' -Wl,-Ttext=0x3fe0';
+ sparc64_ieee1275_objcopyflags = '-O binary';
sparc64_ieee1275_cppflags = '-DCDBOOT=1';
objcopyflags = '-O binary';
diff --git a/grub-core/boot/sparc64/ieee1275/boot.S
b/grub-core/boot/sparc64/ieee1275/boot.S
index 9ea9b4e06..ed3aec464 100644
--- a/grub-core/boot/sparc64/ieee1275/boot.S
+++ b/grub-core/boot/sparc64/ieee1275/boot.S
@@ -21,6 +21,23 @@
.text
.align 4
+ /* We're writing the a.out header ourselves as newer
+* upstream versions of binutils no longer support
+* the a.out format on sparc64.
+*
+* The boot loader fits into 512 bytes with 32 bytes
+* used for the a.out header, hence the text segment
+* size is 512 - 32. There is no data segment and no
+* code relocation, thus those fields remain zero.
+*/
+ .word 0x1030107/* magic number */
+ .word 512 - GRUB_BOOT_AOUT_HEADER_SIZE /* size of text segment */
+ .word 0/* size of initialized data */
+ .word 0/* size of uninitialized data
*/
+ .word 0/* size of symbol table ||
checksum */
+ .word _start /* entry point */
+ .word 0/* size of text relocation */
+ .word 0/* size of data relocation */
.globl _start
_start:
/* OF CIF entry point arrives in %o4 */
@@ -40,10 +57,14 @@ pic_base:
*
* After loading in that block we will execute it by jumping to the
* load address plus the size of the prepended A.OUT header (32 bytes).
+*
+* Since this assembly code includes the 32 bytes long a.out header,
+* we need to move the actual code entry point forward by the size
+* of the a.out header, i.e. += GRUB_BOOT_AOUT_HEADER_SIZE.
*/
- .org GRUB_BOOT_MACHINE_BOOT_DEVPATH
+ .org GRUB_BOOT_MACHINE_BOOT_DEVPATH + GRUB_BOOT_AOUT_HEADER_SIZE
boot_path:
- .org GRUB_BOOT_MACHINE_KERNEL_BYTE
+ .org GRUB_BOOT_MACHINE_KERNEL_BYTE + GRUB_BOOT_AOUT_HEADER_SIZE
boot_path_end:
kernel_byte: .xword (2 << 9)
kernel_address:.word GRUB_BOOT_MACHINE_KERNEL_ADDR
@@ -52,7 +73,7 @@ kernel_address: .word
GRUB_BOOT_MACHINE_KERNEL_ADDR
#define boot_path_end (_start + 1024)
[PATCH] ieee1275: Fix path reference in comment of sparc64 boot loader code
Signed-off-by: John Paul Adrian Glaubitz --- grub-core/boot/sparc64/ieee1275/boot.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/grub-core/boot/sparc64/ieee1275/boot.S b/grub-core/boot/sparc64/ieee1275/boot.S index ed3aec464..c7eb8aae5 100644 --- a/grub-core/boot/sparc64/ieee1275/boot.S +++ b/grub-core/boot/sparc64/ieee1275/boot.S @@ -47,7 +47,7 @@ pic_base: #ifndef CDBOOT /* The offsets to these locations are defined by the -* GRUB_BOOT_MACHINE_foo macros in include/grub/sparc/ieee1275/boot.h, +* GRUB_BOOT_MACHINE_foo macros in include/grub/sparc64/ieee1275/boot.h, * and grub-setup uses this to patch these next three values as needed. * * The boot_path will be the OF device path of the partition where the -- 2.20.1 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Build test report on non-x86 targets
On 3/26/19 12:32 PM, Daniel Kiper wrote: >> I'm happy to report that GRUB builds fine on these targets without any >> additional patches or modifications necessary, except for sparc64 which >> needs my a.out patch for which I will send an updated revision later >> today. > > Thank you for doing these tests. You're welcome. And I just realized: I forgot to mention riscv64, I tested the build there as well and it builds fine, too :-). Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH, v6] ieee1275: Include a.out header in assembly of sparc64 boot loader
On 3/27/19 12:36 PM, Daniel Kiper wrote: > On Tue, Mar 26, 2019 at 09:45:02AM -0600, Eric Snowberg wrote: >>> On Mar 26, 2019, at 3:47 AM, John Paul Adrian Glaubitz >>> wrote: >>> Recent versions of binutils dropped support for the a.out and COFF >>> formats on sparc64 targets. Since the boot loader on sparc64 is >>> supposed to be an a.out binary and the a.out header entries are >>> rather simple to calculate in our case, we just write the header >>> ourselves instead of relying on external tools to do that. >>> >>> Signed-off-by: John Paul Adrian Glaubitz >> >> Reviewed-by: Eric Snowberg > > John, Eric, thank you for doing the work. If there are no objections > I will push it tomorrow. Great, thank you. Looking forward to the upcoming release :-). Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB 2.04 freeze date announcement
Hi! On 3/1/19 12:31 PM, Vladimir 'phcoder' Serbinenko wrote: > We are happy to announce that the upcoming release of Grub 2.04 is expected > in March. In order to prepare the release we would freeze on Monday, March > 11, 23:59:59 UTC. From that point no new features are accepted unless there > is a very good reason to. We will still accept bugfixes. In fact we kindly > ask to test systems and features you care about I was wondering how far we have progressed now towards the new release? Are there any pending fixes that need to go in before 2.04 can be tagged? Once we know there is nothing more coming, I would be happy to perform another build test on all supported targets. Actually installing GRUB would be difficult as I don't have root permissions on all machines for testing. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Change fs functions to add fs_ prefix
On 4/8/19 12:07 PM, Daniel Kiper wrote: > On Mon, Apr 08, 2019 at 03:28:48PM +1000, Vladimir 'phcoder' Serbinenko wrote: >> commit 820906d7b1e68559bcf1b3e0cb56e46cded3e84b >> Author: Vladimir Serbinenko >> Date: Mon Apr 8 07:24:24 2019 +0200 >> >> Change fs functions to add fs_ prefix >> >> This avoid conflict with gnulib >> >> Signed-off-by: Vladimir Serbinenko > > Is it at least build tested for all supported platforms? > If yes you can add Reviewed-by: Daniel Kiper I can help with the build-testing. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Change fs functions to add fs_ prefix
On 4/8/19 7:01 PM, Daniel Kiper wrote: >> I can help with the build-testing. > > Vladimir is trying to cut beta. If you can do your tests once again then > it will be nice. Yes, I'm also interested in a rather soonish release. Just let me know what you want to get tested. Shall I test GRUB with the patch applied on all supported targets? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB 2.04 RC01 released
Hi! On 4/9/19 12:53 PM, Vladimir 'phcoder' Serbinenko wrote: > Hello all. GRUB maintainers team is proud to announce 2.04~rc1 that we > have just released. > > We’re not aware of any of the release-critical bugs but we’re sure > that there are some so we need your help finding them. Compile-tested on Debian unstable (2019-04-09) on the following Linux targets: * amd64- OK * armel- OK * armhf- OK * arm64- OK * i386 - OK * mips - OK * mipsel - OK * mips64el - OK * ia64 - OK * powerpc - OK * ppc64- OK * ppc64el - OK * riscv64 - OK * s390x- OK * sparc64 - OK * x32 - OK Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB 2.04 RC01 does not build on Debian Jessie
On 4/12/19 7:37 AM, adrian15 wrote: > ./configure \ > --enable-grub-mkfont \ > --with-platform="pc" \ > --target="i386-pe" \ > --prefix \ > "/path/to/sg2d_grub_installations/hybrid/" Try passing "--disable-werror" here. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
GRUB fails to load kernel on linux-sparc64
Hi! I have been doing some RC testing with GRUB 2.04~rc1 and actually ran into a problem on sparc64 after updating from 2.02 (debian) to 2.04~rc1. GRUB itself starts fine, but it fails to load the kernel with the following error: Loading Linux 4.19.0-4-sparc64-smp ... error: premature end of file /boot/vmlinuz-4.19.0-4-sparc64-smp. Loading initial ramdisk ... error: you need to load the kernel first. Press any key to continue... I have tried reinstalling the kernel package but that didn't help. Does anyone have a clue? @Eric: Does GRUB 2.04~rc1 work fine for you on sparc64? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB fails to load kernel on linux-sparc64
Hi Eric! On 4/16/19 9:27 PM, Eric Snowberg wrote: >> @Eric: Does GRUB 2.04~rc1 work fine for you on sparc64? > > I boot with an uncompressed kernel and do not see a problem. If I try with a > compressed kernel I do see the error you have above. But this is a known > platform limitation: > https://www.gnu.org/software/grub/manual/grub/grub.html#Platform-limitations That would indeed explain the problem. However, Debian's GRUB version does support compressed kernels on sparc64. I wonder whether we have a local modification that makes this possible. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB fails to load kernel on linux-sparc64
On 4/17/19 11:02 AM, Vladimir 'phcoder' Serbinenko wrote: > Try > insmod xzio > insmod gzio > insmod lzopio That doesn't help unfortunately: GNU GRUB version 2.04~rc1 Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists possible device or file completions. ESC at any time exits. grub> insmod gzio grub> linux /boot/vmlinuz-4.19.0-4-sparc64-smp ro root=/dev/vdiska2 error: premature end of file /boot/vmlinuz-4.19.0-4-sparc64-smp. grub> insmod xzio grub> grub> linux /boot/vmlinuz-4.19.0-4-sparc64-smp ro root=/dev/vdiska2 error: premature end of file /boot/vmlinuz-4.19.0-4-sparc64-smp. grub> insmod lzopio grub> linux /boot/vmlinuz-4.19.0-4-sparc64-smp ro root=/dev/vdiska2 error: premature end of file /boot/vmlinuz-4.19.0-4-sparc64-smp. grub> Going to decompress the kernel now and see if that helps. I'm just surprised that GRUB supposedly doesn't support compressed kernels on sparc64 when we have used that before with 2.02. Not that I have a problem with an uncompressed kernel, I am just surprised. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB fails to load kernel on linux-sparc64
On 4/17/19 11:34 AM, John Paul Adrian Glaubitz wrote: > Going to decompress the kernel now and see if that helps. I'm just surprised > that GRUB supposedly doesn't support compressed kernels on sparc64 when > we have used that before with 2.02. Okay, the uncompressed kernel works. Guess it was just pure luck that it worked with the compressed one in the past. I'll just change debian-installer, the kernel package and debian-cd to use an uncompressed kernel in the future. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC 1/1] mkimage: revert "Align efi sections on 4k boundary"
On 4/19/19 9:11 PM, Jesús Diéguez Fernández wrote: >> /PS : may be making a summary of all architectures/configurations tests >> tutorials would be useful ? Even if it's just QEMU (it would even be a >> lot of work), and used on new releases or wide changes, or just from >> time to time to see if no accident happened in any recent changes. It >> would also be an awesome tutorial for people starting to deal with grub/ >> > > As a complete newbie, I can confirm that this is a real need. I recently > contributed a small modification and didn't know exactly which > compilation options I should enable. I finally used a configuration I > found elsewhere, but that's inconsistent if the official way ignores > some warnings or the other way around, treats all warnings as errors. Well, since it's open source, anyone is invited to make something like that happen. If you think it would be great to have a detailed set of documentation which explains how to build GRUB for the various configurations, you are welcome to send in a patch or set up a wiki. > I know that recently a travis configuration file was added to test that > GRUB builds fine on different platforms. I think that improving it has > more value than just creating a plain text documentation. If you really want to make thorough testing, you would also need to cross- compile the various targets and architectures which is certainly quite an involved task. An alternative would be to regularly create snapshots on Debian, e.g. for a Debian package called "grub-git". Or compile pseudo-natively with the help of QEMU which supports all GRUB targets except for IA64. > The travis integration requires that the code must be hosted on github > (or setup something like this https://stackoverflow.com/a/49019950 ). > Would it be possible to set a remote copy of GRUB's repository on > github? I mean, not my personal copy, but an official mirror, something > like the linux kernel has. Alex has already set up a Travis environment for GRUB, see: > https://travis-ci.org/agraf/grub/ > That would allow anyone to make trivial forks on their github account > that can be tested with travis. To deal with the PR submissions on > github, the kernel has a bot that automatically replies to people (see > this example > https://github.com/torvalds/linux/pull/663#issuecomment-474615610 ). To be fair, I think proper testing of GRUB can only be done when deployed on an actual target. It's also not really a beginner's project anyway, so I think people who send in patches should also be responsible for testing their changes thoroughly. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Creating bootable CD images for sparc64
Hi! I'm currently working on switching Debian's installation CDs for sparc and sparc64 to use GRUB instead of SILO for booting from CD. I have modified debian-installer to call grub-mkimage to generate an image of the type sparc64-ieee1275-cdcore which generates a GRUB image for booting. See [1] for a list of modifications that I have made so far (including patches). What I don't know yet is how to actually boot this image. My understanding is that one needs to inject the 512-byte long cdrom.img into a CD using genisoimage or similar tools. But how does the initial boot loader know where to find the GRUB image? Is that actually a fixed string for CD boot? I could not find any reference for that in the GRUB sources. I have briefly also analyzed the DVD image for Oracle Linux for SPARC [2] but that one has both SILO and GRUB files in its boot directory, so I have no idea what it actually uses. Adrian > [1] https://lists.debian.org/debian-sparc/2019/04/msg00036.html > [2] https://mirrors.dotsrc.org/oracle-linux/OL6/U9/x86_64/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Extend grub-ofpathname to behaves like yaboot/ofpath on PowerPC system
Hi Mathieu! On 5/3/19 8:19 AM, Mathieu Malaterre wrote: > We are looking to extend grub-ofpathname so that it also handles > PowerPC system such as PowerMac with a limited OpenFirmware > implementation[1]. In particular the following patch has been found to > produce an output compatible with such system [2]. > > While we understand that components of a path are in this general form: > > @: > > We also do understand that name can be safely omitted as the device is > actually getting located by > its address. Therefore, these two paths refer to the same device: > > /pci@f400/ata-6@d/disk@0:b > > /@f400/@d/@0:b > > However for the PowerMac we tested it on, only the second form has > been found to be accepted. Thanks for the detailed explanation and for investigating this! Much appreciated. > How best should we provide you with a patch (the current one is kind > of a hack)? Should we extend grub-ofpathname to take a new parameter > (eg. `--omit-names`) and decide to print or not the name, would that > be acceptable ? This sounds like a very reasonable approach. Let's use either that or maybe query OpenFirmware whether we're running on a PowerMac, if that's somehow possible. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: gcc9.1 and f2fs
On 5/6/19 7:15 PM, Neil MacLeod wrote:
> Does anyone have a patch?
Try the attached patch.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
>From b0d03dd5605220d0d23d72e662f10ce7b02a54a6 Mon Sep 17 00:00:00 2001
From: John Paul Adrian Glaubitz
Date: Mon, 6 May 2019 19:55:01 +0200
Subject: [PATCH] f2fs: Disable gcc9 -Waddress-of-packed-member
---
grub-core/fs/f2fs.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/grub-core/fs/f2fs.c b/grub-core/fs/f2fs.c
index 1cad2615f..0dd09bc23 100644
--- a/grub-core/fs/f2fs.c
+++ b/grub-core/fs/f2fs.c
@@ -1235,6 +1235,12 @@ grub_f2fs_utf16_to_utf8 (grub_uint16_t *in_buf_le)
return out_buf;
}
+
+#if __GNUC__ >= 9
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Waddress-of-packed-member"
+#endif
+
static grub_err_t
grub_f2fs_label (grub_device_t device, char **label)
{
@@ -1255,6 +1261,10 @@ grub_f2fs_label (grub_device_t device, char **label)
return grub_errno;
}
+#if __GNUC__ >= 9
+#pragma GCC diagnostic pop
+#endif
+
static grub_err_t
grub_f2fs_uuid (grub_device_t device, char **uuid)
{
--
2.20.1
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Extend grub-ofpathname to behaves like yaboot/ofpath on PowerPC system
On 5/3/19 9:57 AM, John Paul Adrian Glaubitz wrote: >> We also do understand that name can be safely omitted as the device is >> actually getting located by >> its address. Therefore, these two paths refer to the same device: >> >> /pci@f400/ata-6@d/disk@0:b >> >> /@f400/@d/@0:b >> >> However for the PowerMac we tested it on, only the second form has >> been found to be accepted. > > Thanks for the detailed explanation and for investigating this! Much > appreciated. > >> How best should we provide you with a patch (the current one is kind >> of a hack)? Should we extend grub-ofpathname to take a new parameter >> (eg. `--omit-names`) and decide to print or not the name, would that >> be acceptable ? > > This sounds like a very reasonable approach. Let's use either that or > maybe query OpenFirmware whether we're running on a PowerMac, if that's > somehow possible. Any comments from Daniel or Vladimir? Would be great to get this fixed before the 2.04 release comes out. GRUB itself works perfectly fine on PowerMacs but due to the grub-ofpathname tool being unreliable, we currently need to rely on external tools to determine the proper open firmware device path. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Extend grub-ofpathname to behaves like yaboot/ofpath on PowerPC system
On 5/10/19 12:22 PM, Daniel Kiper wrote: > How long it will take? I do not want to hold release any longer. If you actually want to release within the next days now, I'm okay with postponing this for the next release or an upcoming fix release. I have not performed enough tests to know whether ofpathname's different behavior here is specific to PowerMacs or PowerPC in general, i.e. I will have to test that on the IBM CHRP machines we have in Debian. Maybe the tool has only been tested on SPARC ever. > And I would like to hear Eric's opinion here. Sure. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Debian Installer GRUB test image available
CC-ing GRUB upstream. The context are the new Debian installation ISOs which are now using GRUB instead of Yaboot for booting the installer. The debian-cd script which generates the ISO image with xorriso can be found here: > https://salsa.debian.org/images-team/debian-cd/blob/master/tools/boot/buster/boot-powerpc This script uses files from the debian-cd_info.tar.gz tarball which has been created in debian-installer natively on powerpc with the help of this Makefile: > https://salsa.debian.org/installer-team/debian-installer/blob/master/build/config/powerpc.cfg It was noticed that the files bootinfo.txt.in and grub.chrp.in from GRUB upstream have one interesting difference. The grub.chrp.in script defines a partition in the boot-script tag while the bootinfo.txt.in does not (see below). On 5/11/19 1:22 AM, John Ogness wrote: > On 2019-05-05, John Paul Adrian Glaubitz wrote: >> If just removing the extra colon fixes the problem *and* also does not >> break the boot using a CD-ROM (which currently works so it should be >> tested it still does with the change), we should fix the bug upstream. > > I would like to point out that ppc/bootinfo.txt does _not_ specify > "&partition;". So I really wonder why System/Library/CoreServices/BootX > is specifying it. Both these files come from GRUB upstream. If you think those need to be corrected, I would appreciate if you send a patch upstream. Since GRUB 2.04 is due to be released within the next weeks, it probably makes sense to include the fix for the release. The bootinfo.txt is generated from bootinfo.txt.in which can be found here: > http://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/boot/powerpc/bootinfo.txt.in The BootX comes from the grub.chrp.in located in the same folder: > http://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/boot/powerpc/grub.chrp.in > When I get some free time I'll try to find out where &partition; came > from and why BootX is using it. > > If you find some time, I think it would be interesting if we had a > grub-boot test image where BootX is using: > > > boot &device;:,\System\Library\CoreServices\grub.elf > > > I suspect Apple users would then be able to "properly" boot from USB > with: > > boot usb0/disk:,\\:tbxi Well, I can do a test build if you like with the file manually edited. If that fixes the USB issue, we can just send a patch to GRUB upstream to fix the issue just before the release. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Debian Installer GRUB test image available
On 5/11/19 8:07 AM, John Paul Adrian Glaubitz wrote: >> If you find some time, I think it would be interesting if we had a >> grub-boot test image where BootX is using: >> >> >> boot &device;:,\System\Library\CoreServices\grub.elf >> >> >> I suspect Apple users would then be able to "properly" boot from USB >> with: >> >> boot usb0/disk:,\\:tbxi > > Well, I can do a test build if you like with the file manually edited. > > If that fixes the USB issue, we can just send a patch to GRUB upstream > to fix the issue just before the release. I have done this now. Please try the following test image: > https://cdimage.debian.org/cdimage/ports/grub-test/debian-10.0-powerpc-grub-new-NETINST-1.iso Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: gcc9.1 and f2fs
Hi Michael! On 5/17/19 9:13 AM, Michael Chang wrote: > Except for lacking commit message and SOB, the fix is LGTM. > > You could add my Reviewed-by: Michael Chang if you > resend the patch to mailing list with those missing message fixed. I can do that later today. I'm currently busy with work (I'm also @suse.com ;)). Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] f2fs: Fix gcc9 error -Werror=maybe-uninitialized
On 5/27/19 12:02 PM, Daniel Kiper wrote: >> http://lists.gnu.org/archive/html/grub-devel/2019-05/msg00099.html > > John, ping? Could you send us the patch soon? IMO this is the last thing > which blocks the release. Just a second, I will send the patch today. Sorry for the delay. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] f2fs: Fix gcc9 error -Werror=maybe-uninitialized
On 5/27/19 12:02 PM, Daniel Kiper wrote: >> Yes, we need the patch from John to solve reported gcc-9 build issue >> entirely. From the latest update he will do soon. :) >> >> http://lists.gnu.org/archive/html/grub-devel/2019-05/msg00099.html > > John, ping? Could you send us the patch soon? IMO this is the last thing > which blocks the release. Working on this now. Just need to perform a test build with gcc-9 now. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] f2fs: Disable gcc9 -Waddress-of-packed-member
Disable the -Wadress-of-packaed-member diagnostic for the grub_f2fs_label
function since the result is found to be false postive.
A pointer to the 'volume_name' member of 'struct grub_f2fs_superblock' is
guaranteed to be aligned as the offset of 'volume_name' within the struct
is dividable by the natural alignment on both 32- and 64-bit targets.
grub-core/fs/f2fs.c: In function ‘grub_f2fs_label’:
grub-core/fs/f2fs.c:1253:60: error: taking address of packed member of ‘struct
grub_f2fs_superblock’ may result in an unaligned pointer value
[-Werror=address-of-packed-member]
1253 | *label = (char *) grub_f2fs_utf16_to_utf8
(data->sblock.volume_name);
|^~~~
cc1: all warnings being treated as errors
Signed-off-by: John Paul Adrian Glaubitz
---
grub-core/fs/f2fs.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/grub-core/fs/f2fs.c b/grub-core/fs/f2fs.c
index bb28b291b..8a9992ca9 100644
--- a/grub-core/fs/f2fs.c
+++ b/grub-core/fs/f2fs.c
@@ -1240,6 +1240,11 @@ grub_f2fs_utf16_to_utf8 (grub_uint16_t *in_buf_le)
return out_buf;
}
+#if __GNUC__ >= 9
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Waddress-of-packed-member"
+#endif
+
static grub_err_t
grub_f2fs_label (grub_device_t device, char **label)
{
@@ -1260,6 +1265,10 @@ grub_f2fs_label (grub_device_t device, char **label)
return grub_errno;
}
+#if __GNUC__ >= 9
+#pragma GCC diagnostic pop
+#endif
+
static grub_err_t
grub_f2fs_uuid (grub_device_t device, char **uuid)
{
--
2.20.1
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] f2fs: Disable gcc9 -Waddress-of-packed-member
On 6/3/19 1:03 PM, Daniel Kiper wrote: > John, could you do your test builds? Yes, can do. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Build test report on all supported targets
Hello! I just performed test builds with the latest HEAD of grub.git (g8e8723a6b) on the following Debian target architectures in Debian unstable with gcc-8 and glibc-2.28 and the latest set of build dependencies: * amd64- OK * armel- OK * armhf- OK * arm64- OK * i386 - OK * ia64 - OK * mipsel - OK * mips - OK * mips64el - OK * powerpc - OK * ppc64- OK * ppc64el - OK * s390x- OK * sparc64 - OK * x32 - OK So, from my side there is no objection against releasing GRUB 2.04 now. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB failed to install on Fujitsu M10-4
On 6/3/19 3:37 PM, Sonnie Hook wrote: > When installing Debian SPARC 10.0(2019-05-24) on Fujitsu M10-4, everything > seemed OK except that the GRUB installation reported an EFI warning. Wait, you didn't say that there was an "EFI warning" when you posted this to the debian-sparc mailing list. And there shouldn't be one as the machine uses OpenFirmware plus GPT for the partitions tables. I forced to install GRUB on /dev/sda, finally the installation finished without any error...but failed to boot with "Can't open boot device". > > Then I re-installed the whole OS and before rebooting, I executed a shell and > tried to find the real OBP boot path. > # chroot /target grub-ofpathname /dev/sda > grub-ofpathname: error: failed to get canonical path of `/sys/block/sda'. You need to bind-mount /dev, /proc and /sys into the chroot before that command works: # mount -o bind /dev /target/dev # mount -o bind /proc /target/proc # mount -o bind /sys /target/sys > It seemed that there was something wrong with GRUB installation , so I > manually executed: > # chroot /target grub-install --force-extra-removable --force "/dev/sda" > Installing for sparc64-ieee1275 platform. > /proc/devices: fopen failed: No such file or directory > Unknown device "/dev/sda2": No such device > Unknown device "/dev/sda1": No such device > Unknown device "/dev/sda1": No such device > Unknown device "/dev/sda2": No such device > Unknown device "/dev/sda1": No such device > Unknown device "/dev/sda2": No such device > Unknown device "/dev/sda3": No such device > Unknown device "/dev/sda2": No such device > /proc/devices: fopen failed: No such file or directory > Unknown device "/dev/sda2": No such device > /proc/devices: fopen failed: No such file or directory > Unknown device "/dev/sda2": No such device > /proc/devices: fopen failed: No such file or directory > Unknown device "/dev/sda2": No such device > Installation finished. No error reported. Those above error messages are also a result of the missing bind mounts. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB failed to install on Fujitsu M10-4
On 6/3/19 4:18 PM, Sonnie Hook wrote: > You are right. In the past few mails, the messages I pasted were all from > rescue mode until I re-installed the whole OS tonight. > Besides, after bind-mount those directories, those "Unknown device" errors > disappeared. Manual installation of GRUB succeeded. > `grub-ofpathname /dev/sda` output: > /pci@8000/pci@4/pci@0/pci@0/scsi@0/disk@w0,0 > And... still can't open boot device :( The best would be to ask Eric Snowberg from Oracle for advise. He has the most insight. Adrian > John Paul Adrian Glaubitz <mailto:glaub...@physik.fu-berlin.de>> 于2019年6月3日周一 下午9:47写道： > > On 6/3/19 3:37 PM, Sonnie Hook wrote: > > When installing Debian SPARC 10.0(2019-05-24) on Fujitsu M10-4, > everything > > seemed OK except that the GRUB installation reported an EFI warning. > > Wait, you didn't say that there was an "EFI warning" when you posted this > to the debian-sparc mailing list. And there shouldn't be one as the > machine > uses OpenFirmware plus GPT for the partitions tables. > > I forced to install GRUB on /dev/sda, finally the installation finished > without any error...but failed to boot with "Can't open boot device". > > > > Then I re-installed the whole OS and before rebooting, I executed a > shell and tried to find the real OBP boot path. > > # chroot /target grub-ofpathname /dev/sda > > grub-ofpathname: error: failed to get canonical path of > `/sys/block/sda'. > > You need to bind-mount /dev, /proc and /sys into the chroot before > that command works: > > # mount -o bind /dev /target/dev > # mount -o bind /proc /target/proc > # mount -o bind /sys /target/sys > > > It seemed that there was something wrong with GRUB installation , so I > manually executed: > > # chroot /target grub-install --force-extra-removable --force > "/dev/sda" > > Installing for sparc64-ieee1275 platform. > > /proc/devices: fopen failed: No such file or directory > > Unknown device "/dev/sda2": No such device > > Unknown device "/dev/sda1": No such device > > Unknown device "/dev/sda1": No such device > > Unknown device "/dev/sda2": No such device > > Unknown device "/dev/sda1": No such device > > Unknown device "/dev/sda2": No such device > > Unknown device "/dev/sda3": No such device > > Unknown device "/dev/sda2": No such device > > /proc/devices: fopen failed: No such file or directory > > Unknown device "/dev/sda2": No such device > > /proc/devices: fopen failed: No such file or directory > > Unknown device "/dev/sda2": No such device > > /proc/devices: fopen failed: No such file or directory > > Unknown device "/dev/sda2": No such device > > Installation finished. No error reported. > > Those above error messages are also a result of the missing bind mounts. > > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaub...@debian.org > <mailto:glaub...@debian.org> > `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de > <mailto:glaub...@physik.fu-berlin.de> > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB failed to install on Fujitsu M10-4
On 6/4/19 2:56 AM, Sonnie Hook wrote: > Now I re-installed from cdrom. When installing GRUB on disk, I got this > message: > It seems that this computer is configured to boot via EFI, but maybe that > configuration will not work for booting from the hard drive. Some EFI > firmware implementations do not meet the EFI specification ... blabla This message is generated by grub-installer, i.e. the component of debian-installer which installs GRUB during installation. The relevant code part can found here [1], the relevant message text here [2]. I haven't analyzed the code in detail yet so I'm not sure why it triggers in your case. I will perform a test installation inside a SPARC T5 LDOM to find out. Adrian > [1] > https://salsa.debian.org/installer-team/grub-installer/blob/master/grub-installer#L883 > [2] > https://salsa.debian.org/installer-team/grub-installer/blob/master/debian/grub-installer.templates#L267 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v3 10/10] travis: Disable IA64 target
On 6/4/19 12:27 PM, Alexander Graf wrote: > The IA64 target currently does not compile due to the following error > message: > > grub-mkimage: error: undefined symbol grub_arch_sync_dma_caches. > > If anyone cares enough about IA64 to fix it up, be my guest and revert > this commit afterwards. For now, we really need to move forward with > a fully successful travis run to ensure that we catch regressions early > on. This can't be. GRUB builds just fine on ia64, I just tested that yesterday. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v3 09/10] travis: Disable MIPS target
On 6/4/19 12:27 PM, Alexander Graf wrote: > The MIPS target currently does not compile due to the following error > message: > > configure: error: could not force big-endian > > If anyone cares enough about MIPS to fix it up, be my guest and revert > this commit afterwards. For now, we really need to move forward with > a fully successful travis run to ensure that we catch regressions early > on. Same here, builds fine on Debian unstable. Just tested yesterday. In fact, all supported targets build fine. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v3 10/10] travis: Disable IA64 target
On 6/4/19 1:46 PM, Alexander Graf wrote: > Travis doesn't lie :). Maybe it's something about the toolchain used? > > https://travis-ci.org/agraf/grub/jobs/541099309 I don't lie either :P. Toolchain and kernel are recent: root@titanium:~# gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/ia64-linux-gnu/8/lto-wrapper Target: ia64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 8.3.0-10~ia64.1' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-8 --program-prefix=ia64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libssp --disable-libitm --disable-libsanitizer --enable-plugin --with-system-zlib --disable-libphobos --enable-objc-gc=auto --enable-multiarch --disable-werror --with-system-libunwind --enable-checking=release --build=ia64-linux-gnu --host=ia64-linux-gnu --target=ia64-linux-gnu Thread model: posix gcc version 8.3.0 (Debian 8.3.0-10~ia64.1) root@titanium:~# ld --version GNU ld (GNU Binutils for Debian) 2.31.1 Copyright (C) 2018 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty. root@titanium:~# uname -a Linux titanium 4.19.0-5-mckinley #1 SMP Debian 4.19.37-3 (2019-05-18) ia64 GNU/Linux root@titanium:~# This is built natively on ia64. I'll try on one of SUSE's own ia64 boxes now. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v3 09/10] travis: Disable MIPS target
On 6/4/19 1:47 PM, Alexander Graf wrote: > Could you please just fix up the travis tests to succeed? I think the > MIPS problem is definitely toolchain related. Maybe you can somehow > convince that travis ubuntu container to use official Debian cross > compilers instead of the kernel.org ones that we use right now? Yes, Travis should use the cross-compiler packages from Debian. We have cross-compilers for all targets in Debian except for ia64 as it's a bit more complicated to build a cross-compiler there due to the fact that gcc needs libunwind there. I will look into this, at least for all other targets, the cross-compilers can easily be installed with "apt install gcc-$GCCVER-$ARCH-linux-gnu", so if Travis uses Docker here, it will be trivial to fix. The cross-compilers from kernel.org are bare-bone and can't be used to build anything but the kernel and a few other utilities due to missing std libraries. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v3 09/10] travis: Disable MIPS target
On 6/4/19 2:07 PM, Alexander Graf wrote: > Yes, it does. I did try back when I first added the cross compiler > support, but for some reason did not manage to make use of the built-in > cross compilers. Maybe the versions in that Ubuntu version were just too > old? I really don't remember. Those compilers all come from Debian, so it might be a better idea to use a Debian container anyway. The maintainer of those compilers maintains them in Debian, they just get imported into Ubuntu at some point. > I'll be more than happy to see you make them work though :). I'll give it a try. Native builds are 100% fine in any case. >> The cross-compilers from kernel.org are bare-bone and can't be used to build >> anything but the kernel and a few other utilities due to missing std >> libraries. > > > They seem to work surprisingly well for grub, given that we're even > doing execution tests against a few of the resulting binaries ;). Interesting. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v3 10/10] travis: Disable IA64 target
On 6/4/19 3:34 PM, Leif Lindholm wrote:
> I am reasonably convinced this was simply neglected when d8901e3ba1
> ("cache: Fix compilation for ppc, sparc and arm64") was pushed.
> (And I don't believe ia64 has been buildable since.)
*cross*-buildable. It's build absolutely fine naively.
Daniel explicitly asked me to test build GRUB on all supported architectures
and I did that natively on all those targets:
> http://lists.gnu.org/archive/html/grub-devel/2019-06/msg5.html
> Adding (__ia64__) to that conditional makes the mkimage step work.
> Unless someone convinces me differently, I'll submit that as a patch.
I would have to test that on an actual ia64 machine.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] ia64: build fix in cache.h
On 6/4/19 8:51 PM, Leif Lindholm wrote:
> Add ia64 to the architectures excluding a declaration for
> grub_arch_sync_dma_caches.
>
> IA64 does not include any of the source files that require the function,
> but was overlooked for d8901e3ba115 ("cache: Fix compilation for ppc,
> sparc and arm64").
>
> Add it to the list of excluding architectures in order to not get
> missing symbol errors when running grub-mkimage.
Ah, now I get what the actual problem is. I'll test that tomorrow on real
hardware.
> #ifndef GRUB_MACHINE_EMU
> -#if defined (__aarch64__) || defined (__powerpc__) || defined (__sparc__)
> +#if defined (__aarch64__) || defined (__powerpc__) || defined (__sparc__) ||
> \
> +defined (__ia64__)
Nitpick, but could you actually put the arch names in alphabetical order?
It looks weird adding ia64 at the end when everything is already sorted.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] ia64: build fix in cache.h
Hi! On 6/5/19 12:33 AM, Leif Lindholm wrote: > On Wed, Jun 05, 2019 at 12:11:00AM +0200, John Paul Adrian Glaubitz wrote: >> On 6/4/19 8:51 PM, Leif Lindholm wrote: >>> #ifndef GRUB_MACHINE_EMU >>> -#if defined (__aarch64__) || defined (__powerpc__) || defined (__sparc__) >>> +#if defined (__aarch64__) || defined (__powerpc__) || defined (__sparc__) >>> || \ >>> +defined (__ia64__) >> >> Nitpick, but could you actually put the arch names in alphabetical order? >> >> It looks weird adding ia64 at the end when everything is already sorted. > > Haha, you're worse than me - I love it :) Yes, I'm a bit of an OCD person when it comes to sending patches. > If you can confirm the end result actually works on hardware, I'm > happy to resubmit with macros sorted. (If not, I'm with Alex on > dropping the CI until it's actually testable.) So, I have build-tested the patch on ia64 now. GRUB still builds fine with the patch applied. So no regression this regard. And here are the tests with grub-mkimage. First, without the patch: glaubitz@titanium:/srv/tmp/grub$ ./grub-mkimage --config=/boot/grub/grub.cfg --prefix="" -d grub-core -O ia64-efi -o ia64.efi ./grub-mkimage: error: undefined symbol grub_arch_sync_dma_caches. glaubitz@titanium:/srv/tmp/grub$ And now with the patch: glaubitz@titanium:/srv/tmp/grub$ ./grub-mkimage --config=/boot/grub/grub.cfg --prefix="" -d grub-core -O ia64-efi -o ia64.efi glaubitz@titanium:/srv/tmp/grub$ So, I can confirm the patch does what was expected. Tested-by: John Paul Adrian Glaubitz Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Summary: GRUB installed but boot failed on Fujitsu M10-4
Hi! On 6/5/19 7:30 PM, Eric Snowberg wrote: >> This is an Fujitsu M10-4 machine. > > It could be we are not enumerating the disk correctly. What kind of HBA is in > this system? FWIW, we don't have all of your SPARC fixes in Debian's current GRUB package as we're still waiting for the 2.04 release. The issues that Sonnie are seeing might resolve with the 2.04 version. I hope we can get 2.04 real(TM) soonish. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2] ia64: build fix in cache.h
On 6/6/19 11:13 AM, Leif Lindholm wrote: > Changes in v2: > - Alphabetically sort macros in conditional. > - Add Adrian's T-b. Superb, thanks a lot ;). Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB release is nearing...
Hi! On 6/7/19 4:42 PM, Daniel Kiper wrote: > I have pushed fixes for last known issues a few minutes ago. So, please > test the GRUB from latest git master branch. If nothing blows up then > I will release GRUB in a week or so. I think we're in a state now where it's safe to release. If there are any issues showing up on the lesser tested targets, I will forward them upstream. Thanks for all the work and I'm looking forward to release! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Debian's GRUB fails to load on sparc64 with GPT
Hi!
Debian's grub2 package has now been updated to 2.04 and while it works fine
on sparc64 machines with Sun partition tables, it bails out on those with GPT
partition tables with:
{0} ok boot
Boot device: disk File and args:
WARNING: Unsupported bootblk image, can not extract fcode
WARNING: Bootblk fcode extraction failed
GRUB
ERROR: Last Trap: Illegal Instruction
{0} ok
GRUB was installed with "grub-install /dev/vdiska". Interestingly, building
GRUB from git source from upstream and installing it, doesn't show this
problem, so it must be something Debian-specific.
The debian/rules file can be found in [1].
@Eric: Do you have any suggestion what could be wrong with the Debian package?
Adrian
> [1] https://salsa.debian.org/grub-team/grub/blob/master/debian/rules
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] sparc64: Fix BIOS Boot Partition support
On 7/15/19 12:40 AM, James Clarke wrote:
> Currently, gpt_offset is uninitialised when using a BIOS Boot Partition
> but is used unconditionally inside save_blocklists. Instead, ensure it
> is always initialised to 0 (note that there is already separate code to
> do the equivalent adjustment after we call save_blocklists on this code
> path).
>
> This patch has been tested on a T5-2 LDOM.
>
> Signed-off-by: James Clarke
> ---
> util/setup.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/util/setup.c b/util/setup.c
> index 6f88f3cc4..3be88aae1 100644
> --- a/util/setup.c
> +++ b/util/setup.c
> @@ -270,6 +270,9 @@ SETUP (const char *dir,
> #ifdef GRUB_SETUP_BIOS
>bl.current_segment =
> GRUB_BOOT_I386_PC_KERNEL_SEG + (GRUB_DISK_SECTOR_SIZE >> 4);
> +#endif
> +#ifdef GRUB_SETUP_SPARC64
> + bl.gpt_offset = 0;
> #endif
>bl.last_length = 0;
>
> @@ -730,7 +733,6 @@ unable_to_embed:
> #ifdef GRUB_SETUP_SPARC64
>{
> grub_partition_t container = root_dev->disk->partition;
> -bl.gpt_offset = 0;
>
> if (grub_strstr (container->partmap->name, "gpt"))
>bl.gpt_offset = grub_partition_get_start (container);
>
Works as expected and fixes the problem I reported earlier [1].
Tested-by: John Paul Adrian Glaubitz
@Eric: Any comments?
Adrian
> [1] https://lists.gnu.org/archive/html/grub-devel/2019-07/msg00017.html
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] sparc64: Fix BIOS Boot Partition support
On 7/16/19 2:02 PM, Vladimir 'phcoder' Serbinenko wrote: > LGTM. Let's give it another day on ML, then I'll commit it Friendly reminder ;-). Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v3 00/10] Travis fixes
On 7/18/19 6:58 PM, Vladimir 'phcoder' Serbinenko wrote: > LGTM for the whole series. I do care about mips and ia64 but I think > it's fine to disable them for now and iterate from there Unless I am missing something, ia64 should be fine as the issue in question has been fixed. So, it's only mips that needs to be disabled due to the toolchain being used not being able to build all mips targets. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Grub-devel Digest, Vol 185, Issue 15
On 7/19/19 7:47 AM, Artyom Pozharov wrote: > Why Ubuntu? On Fedora, Debian, Deepin, Mint, Solus, etc. I have the > same problem. So problem connected with GRUB. I don't see this problem > with Chromium OS forks (FydeOS, ATB, but nit Cloudready), because GRUB > is modified there (I guess). I have looked at your bug report and it's not possible to tell from the information you provided what the problem is. It seems though that while grub-installer is being run, a kernel panic occurs which might cause the GRUB installation to be interrupted [1]. > So it's your problem. Please try to be a bit more polite. We're mostly volunteers here. > [1] https://photos.app.goo.gl/4Pimhpr8SwPerA1h7 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Grub-devel Digest, Vol 185, Issue 15
On 7/19/19 9:52 AM, Artyom Pozharov wrote: > Am I impolite? Yes. You are phrasing your mails rather harsh, this shouldn't be necessary. We're all volunteers here, so it should to be up to everyone to decide what they work on and what not. We're also not sitting at the computer all the time. > I don't understand from your words it's my problem or kernel panic? Your screenshot which I linked shows a kernel panic/OOPS in the details window. > I don't have any problems with GNU/Linux with BIOS-compability session. That doesn't mean there isn't a bug in the kernel. When run in EFI mode, the whole system is booted in a different mode, it's not just the bootloader > So it's problem with GRUB, because installation will go normally, while GRUB > is not installed. That doesn't automatically mean it's a GRUB problem. The GRUB installation failure may just be a result of the kernel panic/OOPS that's happening in the background while running grub-install. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Don't run f2fs test on systems with PAGE_SIZE > 4096 bytes.
Hi Anatoly! On 7/30/19 10:11 AM, Anatoly Pugachev wrote: > don't run f2fs test on systems with PAGE_SIZE > 4096 bytes. > Since f2fs is not supported on this systems (can't mount f2fs filesystem). Some spelling fixes and re-phrasing suggestion: > Don't run f2fs tests on systems with PAGE_SIZE > 4096 bytes since f2fs > is not supported on these systems and mounting a f2fs filesystems fails. And: +PAGE_SIZE=$(getconf PAGE_SIZE) +F2FS_BLKSIZE=4096 +if [ $PAGE_SIZE > $F2FS_BLKSIZE ]; then + printf "F2FS not supported on PAGE_SIZE(%d) != %d\n" $PAGE_SIZE $F2FS_BLKSIZE I would write "f2fs" in lower case here for consistency with the rest of the script. + exit 77 +fi Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v3 5/5] docs: Update info with grub.cfg netboot selection order
On 10/22/19 4:26 PM, Daniel Kiper wrote: > On Tue, Oct 22, 2019 at 10:48:14AM +0200, Javier Martinez Canillas wrote: >> From: Robert Marshall >> >> Add documentation to the grub info page that specifies the order >> netboot clients use to select a grub configuration file. >> >> Signed-off-by: Robert Marshall >> Signed-off-by: Javier Martinez Canillas > > Wow! We have a doc! Nice! That reminds me: Google has actually a project like GSoC these days, just for documentation. It's called "Google Season of Docs" [1]. It seems an interesting option for paying technical writers to work on documentation which is often lacking in many open source projects. Adrian > [1] https://developers.google.com/season-of-docs -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Upcomming trouble with grub-mkrescue ISOs and libblkid
On 12/14/19 11:58 AM, Thomas Schmitt wrote: > there is trouble at the horizon by > > > https://github.com/karelzak/util-linux/commit/7ef86a08914427d6486734614d7d3bbed1f108fe > > which disables the recognition of ISO 9660 filesystems on the base device > in favor of potential partitions which may or may not mark the range of > the ISO filesystem. I'm on the util-linux mailing list and I haven't seen this reported there yet. I would expect them to react to such rather problematic regressions if they are being reported. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB 2.06 release
Hi! On 2/19/20 4:01 PM, Daniel Kiper wrote: > As I told during my FOSDEM 2020 presentation we are preparing for > GRUB 2.06 release. Tentative schedule is below: > - code freeze: 15th of March, 23:59:59 UTC; everything posted after > that date will not be considered as a release material, > - release: taking into account last experience I think that it will > happen no later than June; hopefully earlier; exact date depends > on number of bugs found, etc. > > So, please plan accordingly... Let me know when you want me to start the build tests on all architectures. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 2/2] build: Disable PIE in TARGET_CCASFLAGS if needed
Hi Mike! On 2/20/20 7:51 AM, Matt Turner wrote: > PIE should be disabled in assembly sources as well, or else grub will > fail to boot. Indeed. We have always passed -fno-PIE on Debian/sparc64 in the debian/rules file to TARGET_CCASFLAGS, but it makes more sense to fix the issue in the configure.ac. > Bug: https://bugs.gentoo.org/667852 > --- > configure.ac | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/configure.ac b/configure.ac > index b5e31c787..e2c783652 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -1263,6 +1263,7 @@ grub_CHECK_LINK_PIE > # `-fPIE' or '-fpie' and '-pie' in the default specs. > if [ x"$pie_possible" = xyes ]; then >TARGET_CFLAGS="$TARGET_CFLAGS -fno-PIE -fno-pie" > + TARGET_CCASFLAGS="$TARGET_CCASFLAGS -fno-PIE -fno-pie" > fi > > if [ x"$link_nopie_needed" = xyes ] || [ x"$pie_possible" = xyes ]; then I have not verified yet that fix yet but it makes sense for the aforementioned reasons. Thanks for fixing this. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 2/2] build: Disable PIE in TARGET_CCASFLAGS if needed
On 2/20/20 7:51 AM, Matt Turner wrote: > From: Mike Gilbert > > PIE should be disabled in assembly sources as well, or else grub will > fail to boot. > > Bug: https://bugs.gentoo.org/667852 > --- > configure.ac | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/configure.ac b/configure.ac > index b5e31c787..e2c783652 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -1263,6 +1263,7 @@ grub_CHECK_LINK_PIE > # `-fPIE' or '-fpie' and '-pie' in the default specs. > if [ x"$pie_possible" = xyes ]; then >TARGET_CFLAGS="$TARGET_CFLAGS -fno-PIE -fno-pie" > + TARGET_CCASFLAGS="$TARGET_CCASFLAGS -fno-PIE -fno-pie" > fi > > if [ x"$link_nopie_needed" = xyes ] || [ x"$pie_possible" = xyes ]; then > This fixes the issue for me on sparc64 (Debian unstable). Tested-by: John Paul Adrian Glaubitz Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 1/2] build: Move TARGET_* assignments earlier
On 2/20/20 7:51 AM, Matt Turner wrote: > From: Mike Gilbert > > On a 32-bit SPARC userland, configure fails to compile assembly and the > build fails: > > checking for options to compile assembly... configure: error: could not > compile assembly > > config.log shows: > > asm-tests/sparc64.S: Assembler messages: > asm-tests/sparc64.S:5: Error: Architecture mismatch on "lduw [%o4+4],%o4". > asm-tests/sparc64.S:5: (Requires v9|v9a|v9b|v9c|v9d|v9e|v9v|v9m|m8; > requested architecture is sparclite.) > asm-tests/sparc64.S:7: Error: Architecture mismatch on "stw %o5,[%o3]". > asm-tests/sparc64.S:7: (Requires v9|v9a|v9b|v9c|v9d|v9e|v9v|v9m|m8; > requested architecture is sparclite.) > asm-tests/sparc64.S:8: Error: Architecture mismatch on "bne,pt %icc,1b > ,pt %icc,1b". > asm-tests/sparc64.S:8: (Requires v9|v9a|v9b|v9c|v9d|v9e|v9v|v9m|m8; > requested architecture is sparclite.) > > Simply moving these blocks earlier in configure.ac is sufficient to > ensure that the tests are executed with the appropriate flags > (specifically -m64 in this case). > > Bug: https://bugs.gentoo.org/667850 > --- > configure.ac | 36 ++-- > 1 file changed, 18 insertions(+), 18 deletions(-) > > diff --git a/configure.ac b/configure.ac > index e07ba4b56..b5e31c787 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -562,6 +562,24 @@ CPPFLAGS="$TARGET_CPPFLAGS" > LDFLAGS="$TARGET_LDFLAGS" > LIBS="" > > +if test "x$target_m32" = x1; then > + # Force 32-bit mode. > + TARGET_CFLAGS="$TARGET_CFLAGS -m32" > + TARGET_CCASFLAGS="$TARGET_CCASFLAGS -m32" > + TARGET_CPPFLAGS="$TARGET_CPPFLAGS -m32" > + TARGET_LDFLAGS="$TARGET_LDFLAGS -m32" > + TARGET_MODULE_FORMAT="elf32" > +fi > + > +if test "x$target_m64" = x1; then > + # Force 64-bit mode. > + TARGET_CFLAGS="$TARGET_CFLAGS -m64" > + TARGET_CCASFLAGS="$TARGET_CCASFLAGS -m64" > + TARGET_CPPFLAGS="$TARGET_CPPFLAGS -m64" > + TARGET_LDFLAGS="$TARGET_LDFLAGS -m64" > + TARGET_MODULE_FORMAT="elf64" > +fi > + > # debug flags. > TARGET_CFLAGS="$TARGET_CFLAGS $WARN_FLAGS -g -Wredundant-decls > -Wmissing-prototypes -Wmissing-declarations" > TARGET_CCASFLAGS="$TARGET_CCASFLAGS -g" > @@ -750,24 +768,6 @@ if test "x$target_cpu" = xi386 && test "x$platform" != > xemu; then >TARGET_CFLAGS="$TARGET_CFLAGS -march=i386" > fi > > -if test "x$target_m32" = x1; then > - # Force 32-bit mode. > - TARGET_CFLAGS="$TARGET_CFLAGS -m32" > - TARGET_CCASFLAGS="$TARGET_CCASFLAGS -m32" > - TARGET_CPPFLAGS="$TARGET_CPPFLAGS -m32" > - TARGET_LDFLAGS="$TARGET_LDFLAGS -m32" > - TARGET_MODULE_FORMAT="elf32" > -fi > - > -if test "x$target_m64" = x1; then > - # Force 64-bit mode. > - TARGET_CFLAGS="$TARGET_CFLAGS -m64" > - TARGET_CCASFLAGS="$TARGET_CCASFLAGS -m64" > - TARGET_CPPFLAGS="$TARGET_CPPFLAGS -m64" > - TARGET_LDFLAGS="$TARGET_LDFLAGS -m64" > - TARGET_MODULE_FORMAT="elf64" > -fi > - > if test "x$grub_cv_cc_target_clang" = xno && test "x$target_cpu" = xi386 && > test "x$platform" != xemu && test "x$platform" != xefi; then > TARGET_CFLAGS="$TARGET_CFLAGS -mrtd -mregparm=3" > fi > While I cannot say whether this fixes the issue reported as we are building grub with a 64-bit SPARC userland, I can confirm that these changes don't break the build on sparc64. Tested-by: John Paul Adrian Glaubitz Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 2/2] build: Disable PIE in TARGET_CCASFLAGS if needed
On 2/25/20 11:58 AM, Paul Menzel wrote: >> PIE should be disabled in assembly sources as well, or else grub will >> fail to boot. > > Could you please extend this with the list, on what architectures it > fails to boot? It seems to work on x86, doesn’t it? This issue has been observed on SPARC only, correct. But it generally sense to include the no-PIE/no-pie flags in ASFLAGS as well. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB 2.06 release
Hi! On 2/20/20 9:46 AM, John Paul Adrian Glaubitz wrote: > On 2/19/20 4:01 PM, Daniel Kiper wrote: >> As I told during my FOSDEM 2020 presentation we are preparing for >> GRUB 2.06 release. Tentative schedule is below: >> - code freeze: 15th of March, 23:59:59 UTC; everything posted after >> that date will not be considered as a release material, >> - release: taking into account last experience I think that it will >> happen no later than June; hopefully earlier; exact date depends >> on number of bugs found, etc. >> >> So, please plan accordingly... > > Let me know when you want me to start the build tests on all architectures. FWIW, it would be great if both these fixes could be included in the 2.06 release: * build: Disable PIE in TARGET_CCASFLAGS if needed * build: Move TARGET_* assignments earlier Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB 2.06 release
On 3/3/20 6:26 PM, Daniel Kiper wrote: > On Wed, Feb 19, 2020 at 04:01:38PM +0100, Daniel Kiper wrote: >> Hi all, >> >> As I told during my FOSDEM 2020 presentation we are preparing for >> GRUB 2.06 release. Tentative schedule is below: >> - code freeze: 15th of March, 23:59:59 UTC; everything posted after >> that date will not be considered as a release material, > > Just a kind reminder... Less than two weeks left... I really appreciate the faster release cycle. Much appreciated! Thanks a lot for your efforts, Daniel! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] build: Add soft-float handling for SuperH (sh4)
While GRUB has no platform support for SuperH (sh4) yet, this change adds the target-specific handling of soft-floats such that the GRUB utilities can be built on this target. Signed-off-by: John Paul Adrian Glaubitz --- configure.ac | 5 + 1 file changed, 5 insertions(+) diff --git a/configure.ac b/configure.ac index f19489418..4766f4190 100644 --- a/configure.ac +++ b/configure.ac @@ -854,6 +854,11 @@ if test x"$platform" != xemu ; then AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]], [[]])], [grub_cv_target_cc_soft_float="-mno-inline-float-divide -mno-inline-sqrt"], []) fi +if test "x$target_cpu" = xsh4; then + CFLAGS="$TARGET_CFLAGS -m4-nofpu -Werror" + AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]], [[]])], +[grub_cv_target_cc_soft_float="-m4-nofpu"], []) +fi for cand in "-msoft-float -Xclang -msoft-float -Xclang -no-implicit-float" \ "-Xclang -msoft-float -Xclang -no-implicit-float" \ "-Xclang -msoft-float" "-msoft-float"; do -- 2.25.1 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: compile error in master, restrict is missing
On 3/11/20 11:39 AM, Daniel Kiper wrote: >> [ 135s] + env CFLAGS=-Wall CXXFLAGS=-Wall FFLAGS=-Wall >> ../grub2-src/configure --target=i386-suse-linux Which version of SUSE Linux is that, in case I want to reproduce that? FWIW, I work at SUSE, so I have access to all versions :). Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: compile error in master, restrict is missing
On 3/11/20 12:01 PM, Olaf Hering wrote: > Am Wed, 11 Mar 2020 11:56:27 +0100 > schrieb John Paul Adrian Glaubitz : > >> Which version of SUSE Linux is that, in case I want to reproduce that? > > SLE_12 and Leap 42.3, everything with gcc-4.8. I may be able to work around > it by using a newer compiler. Ok, thanks. FWIW, Leap 42.3 is no longer supported by us. I happen to have a SLE-12 cloud instance running anyway now so I can help debug if necessary. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] efi: add missed space in GRUB_EFI_GLOBAL_VARIABLE_GUID
On 3/27/20 1:11 PM, Vladimir 'phcoder' Serbinenko wrote:
> Could you explain why we would need this patch? It changes nothing AFAICT
It's a cosmetic change, there is one space character missing before the last
value in the curly braces:
>> #define GRUB_EFI_GLOBAL_VARIABLE_GUID \
>> - { 0x8BE4DF61, 0x93CA, 0x11d2, { 0xAA, 0x0D, 0x00, 0xE0, 0x98, 0x03,
>> 0x2B,0x8C }}
>> + { 0x8BE4DF61, 0x93CA, 0x11d2, { 0xAA, 0x0D, 0x00, 0xE0, 0x98, 0x03,
>> 0x2B, 0x8C }}
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 1/4] configure: Drop unneeded TARGET_CFLAGS expansion
On 4/3/20 2:45 PM, Daniel Kiper wrote: > diff --git a/configure.ac b/configure.ac > index 88c0adbae..b2576b013 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -77,7 +77,7 @@ grub_TRANSFORM([grub-file]) > > # Optimization flag. Allow user to override. > if test "x$TARGET_CFLAGS" = x; then > - TARGET_CFLAGS="$TARGET_CFLAGS -Os" > + TARGET_CFLAGS=-Os > fi Good catch. It took me a few seconds to realize that the conditional is only true and "-Os" added when TARGET_CFLAGS is not set by the user :). Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] gitignore: Add a few forgotten files
Hi Hans Ulrich! On 4/22/20 9:44 PM, Hans Ulrich Niedermann wrote: > Signed-off-by: Hans Ulrich Niedermann > --- > .gitignore | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/.gitignore b/.gitignore > index 819cd185d..149b3713a 100644 > --- a/.gitignore > +++ b/.gitignore > @@ -3,6 +3,7 @@ > 10_* > 20_linux_xen > 30_os-prober > +/30_uefi-firmware > 40_custom > 41_custom > *.1 > @@ -18,6 +19,7 @@ build-grub-gen-asciih > build-grub-gen-widthspec > build-grub-mkfont > cdboot_test > +/ChangeLog > cmp_test > config.cache > config.guess > @@ -31,6 +33,7 @@ configure > core_compress_test > DISTLIST > docs/*.info > +/docs/*.info-* > docs/stamp-vti > docs/version.texi > ehci_test What's with the preceding slash in the filenames? Is it really "/30_uefi-firmware"? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] gitignore: Add a few forgotten files
On 4/22/20 10:31 PM, Hans Ulrich Niedermann wrote: >> What's with the preceding slash in the filenames? Is it really >> "/30_uefi-firmware"? > > Yes. > > If a ".gitignore" file contains > > /ChangeLog > > then git will only ignore a file named "ChangeLog" located in the same > directory where the .gitignore file is, i.e. a file like > "subdir/ChangeLog" will not match. > > If a ".gitignore" file contains > > Makefile > > then git will ignore all files named Makefile located in the same > directory where the .gitignore file is _and_in_all_of_its_subdirs_. Ah, I wasn't aware of that syntax. Thanks for the explanation. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
