| 146 ++
grub-core/loader/slaunch/x86_dlstub.c | 2 +-
include/grub/multiboot2.h | 3 +
include/grub/slaunch.h| 1 +
include/grub/slr_table.h | 2 +
7 files changed, 254 insertions(+), 2 deletions(-)
diff --git a/grub-core
grub_skl_setup_module (slparams);
+ if (err != GRUB_ERR_NONE)
+return grub_error (err, "Failed to setup SKL for Multiboot2");
+
+ err = grub_skl_prepare_bootloader_data (slparams);
+ if (err != GRUB_ERR_NONE)
+return grub_error (err, "SKL preparations have
In preparation of adding RISC-V (64-bit) support to multiboot2:
* new file include/grub/riscv64/multiboot.h added
* MULTIBOOT2_ARCHITECTURE_RISCV64 definition added
Signed-off-by: Yuri Zaporozhets
---
include/grub/riscv64/multiboot.h | 24
include/multiboot2.h
rr = grub_skl_setup_module (slparams);
+ if (err != GRUB_ERR_NONE)
+return grub_error (err, "Failed to setup SKL for Multiboot2");
+
+ err = grub_skl_prepare_bootloader_data (slparams);
+ if (err != GRUB_ERR_NONE)
+return grub_error (err, "SKL pre
/grub/i386/txt.h| 2 +
include/grub/multiboot2.h | 3 +
include/grub/slaunch.h | 1 +
include/grub/slr_table.h | 2 +
8 files changed, 241 insertions(+), 2 deletions(-)
diff --git a/grub-core/loader/multiboot.c b/grub-core/loader/multiboot.c
index
/multiboot_mbi2.c | 52 +++---
include/grub/multiboot2.h | 4 +--
4 files changed, 55 insertions(+), 34 deletions(-)
diff --git a/grub-core/loader/multiboot.c b/grub-core/loader/multiboot.c
index 561523a2b..1d1d6a2e9 100644
--- a/grub-core/loader/multiboot.c
+++ b
-off-by: Krystian Hebel
Signed-off-by: Sergii Dmytruk
---
grub-core/loader/multiboot.c | 23 ++-
grub-core/loader/multiboot_elfxx.c | 88 ++-
grub-core/loader/multiboot_mbi2.c | 96 ++
include/grub/multiboot2.h | 2 +
4 files
-core/loader/multiboot_elfxx.c | 88 ++-
grub-core/loader/multiboot_mbi2.c | 96 ++
include/grub/multiboot2.h | 2 +
4 files changed, 207 insertions(+), 2 deletions(-)
diff --git a/grub-core/loader/multiboot.c b/grub-core/loader
From: Krystian Hebel
Signed-off-by: Krystian Hebel
Signed-off-by: Sergii Dmytruk
---
grub-core/loader/multiboot.c | 11 +--
grub-core/loader/multiboot_elfxx.c | 22 ++---
grub-core/loader/multiboot_mbi2.c | 52 +++---
include/grub/multiboot2.h
Date: Thu, 28 Mar 2024 15:13:01 +
From: Ross Lagerwall
To: grub-devel@gnu.org
Cc: xen-de...@lists.xenproject.org, Ross Lagerwall
, Daniel Kiper ,
Daniel Kiper , Andrew Cooper
, Roger Pau Monné
Subject: [PATCH v2 2/3] multiboot2: Add PE load support
Message-ID
gt; > > relocate them below 4G, it should be possible for the binary to specify
> > > those entry points. Therefore, extend the multiboot2 protocol such that
> > > 64 bit addresses are allowed for entry points. The extension is done in
> > > a backwar
/multiboot_pe.c | 702 ++
include/grub/efi/pe32.h | 64 +++
include/grub/multiboot.h | 3 +
include/grub/multiboot2.h | 9 +
7 files changed, 796 insertions(+), 1 deletion(-)
create mode 100644 grub-core/loader/multiboot_pe.c
diff --git a
Currently, multiboot2-compatible bootloaders can load ELF binaries and
a.out binaries. The presence of the address header tag determines
how the bootloader tries to interpret the binary (a.out if the address
tag is present else ELF).
In addition to the existing address and ELF load types, specify
fy
> > those entry points. Therefore, extend the multiboot2 protocol such that
> > 64 bit addresses are allowed for entry points. The extension is done in
> > a backwards-compatible way.
> >
> > Signed-off-by: Ross Lagerwall
> > ---
> > doc/multiboot.texi | 32 +
On Fri, Mar 15, 2024 at 7:31 AM Vladimir 'phcoder' Serbinenko
wrote:
>
> Not a full review. Just one blocking problem
>
>>
>>
>> }
>> + case MULTIBOOT_LOAD_TYPE_PE:
>> + grub_fatal ("Unsupported load type: %u\n", mld.load_type);
>> + default:
>> +/* should be impossible */
>> +
On Tue, Mar 19, 2024 at 02:46:59PM +, Ross Lagerwall wrote:
> On Tue, Mar 19, 2024 at 1:18 PM Roger Pau Monné wrote:
> >
> > On Wed, Mar 13, 2024 at 03:07:42PM +, Ross Lagerwall wrote:
> > > Currently, multiboot2-compatible bootloaders can load ELF binaries and
&
On Tue, Mar 19, 2024 at 1:18 PM Roger Pau Monné wrote:
>
> On Wed, Mar 13, 2024 at 03:07:42PM +, Ross Lagerwall wrote:
> > Currently, multiboot2-compatible bootloaders can load ELF binaries and
> > a.out binaries. The presence of the address header tag determines
> >
On Wed, Mar 13, 2024 at 03:07:42PM +, Ross Lagerwall wrote:
> Currently, multiboot2-compatible bootloaders can load ELF binaries and
> a.out binaries. The presence of the address header tag determines
> how the bootloader tries to interpret the binary (a.out if the address
> ta
On Thu, Mar 14, 2024 at 02:24:31PM +, Ross Lagerwall wrote:
> On Thu, Mar 14, 2024 at 1:37 PM Jan Beulich wrote:
> >
> > On 14.03.2024 10:30, Ross Lagerwall wrote:
> > > On Thu, Mar 14, 2024 at 7:24 AM Jan Beulich wrote:
> > >>
> > >> On 13.03.2024 16:07, Ross Lagerwall wrote:
> > >>> In addi
On Wed, Mar 13, 2024 at 03:07:43PM +, Ross Lagerwall wrote:
> Binaries may be built with entry points above 4G. While bootloaders may
> relocate them below 4G, it should be possible for the binary to specify
> those entry points. Therefore, extend the multiboot2 protocol such that
Not a full review. Just one blocking problem
>
> }
> + case MULTIBOOT_LOAD_TYPE_PE:
> + grub_fatal ("Unsupported load type: %u\n", mld.load_type);
> + default:
> +/* should be impossible */
> +grub_fatal ("Unknown load type: %u\n", mld.load_type);
>
Don't use grub_fatal for th
On 14.03.2024 15:24, Ross Lagerwall wrote:
> On Thu, Mar 14, 2024 at 1:37 PM Jan Beulich wrote:
>> On 14.03.2024 10:30, Ross Lagerwall wrote:
>>> On Thu, Mar 14, 2024 at 7:24 AM Jan Beulich wrote:
On 13.03.2024 16:07, Ross Lagerwall wrote:
> In addition to the existing address and ELF lo
On Thu, Mar 14, 2024 at 1:37 PM Jan Beulich wrote:
>
> On 14.03.2024 10:30, Ross Lagerwall wrote:
> > On Thu, Mar 14, 2024 at 7:24 AM Jan Beulich wrote:
> >>
> >> On 13.03.2024 16:07, Ross Lagerwall wrote:
> >>> In addition to the existing address and ELF load types, specify a new
> >>> optional
On 14.03.2024 10:30, Ross Lagerwall wrote:
> On Thu, Mar 14, 2024 at 7:24 AM Jan Beulich wrote:
>>
>> On 13.03.2024 16:07, Ross Lagerwall wrote:
>>> In addition to the existing address and ELF load types, specify a new
>>> optional PE binary load type. This new type is a useful addition since
>>>
On Thu, Mar 14, 2024 at 7:24 AM Jan Beulich wrote:
>
> On 13.03.2024 16:07, Ross Lagerwall wrote:
> > In addition to the existing address and ELF load types, specify a new
> > optional PE binary load type. This new type is a useful addition since
> > PE binaries can be signed and verified (i.e. us
Please take this discussion to a separate thread. In this thread it's
pure offtopic
On Thu, Mar 14, 2024 at 10:25 AM Jan Beulich via Grub-devel
wrote:
>
> On 13.03.2024 16:07, Ross Lagerwall wrote:
> > In addition to the existing address and ELF load types, specify a new
> > optional PE binary lo
Hi, I saw this on the list and have concerns:
Original Message
On 14 Mar 2024, 6:24 pm, Jan Beulich via Grub-devel < grub-devel@gnu.org> wrote:
On 13.03.2024 16:07, Ross Lagerwall wrote:
>> In addition to the existing address and ELF load types, specify a new
>> optional PE binar
On 13.03.2024 16:07, Ross Lagerwall wrote:
> In addition to the existing address and ELF load types, specify a new
> optional PE binary load type. This new type is a useful addition since
> PE binaries can be signed and verified (i.e. used with Secure Boot).
And the consideration to have ELF signa
Binaries may be built with entry points above 4G. While bootloaders may
relocate them below 4G, it should be possible for the binary to specify
those entry points. Therefore, extend the multiboot2 protocol such that
64 bit addresses are allowed for entry points. The extension is done in
a
Currently, multiboot2-compatible bootloaders can load ELF binaries and
a.out binaries. The presence of the address header tag determines
how the bootloader tries to interpret the binary (a.out if the address
tag is present else ELF).
Add a new load type header tag that explicitly states the type
The binary may expose its type using the load type header tag. Implement
it according to the specification.
Signed-off-by: Ross Lagerwall
---
grub-core/loader/multiboot_mbi2.c | 45 ---
include/grub/multiboot2.h | 1 +
include/multiboot2.h | 13
Add support for entry addresses that may be either 32 bits or 64 bits in
size. This may be necessary if the binary is built with an entry address
above 4G.
Signed-off-by: Ross Lagerwall
---
grub-core/loader/multiboot_mbi2.c | 10 --
include/multiboot2.h | 6 +-
2 files
++
include/grub/efi/pe32.h | 64 +++
include/grub/multiboot2.h | 3 +
5 files changed, 775 insertions(+), 2 deletions(-)
create mode 100644 grub-core/loader/multiboot_pe.c
diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
index 1571421d7e84
e
image above 4 GiB? The Multiboot2 spec clearly states the machine has to
be in 32-bit mode during transition from the bootloader to the kernel.
I think it would be very helpful if you describe your use case in details.
Daniel
___
Grub-devel mailing list
images was interjected
as a side effect. Refer to multiboot2: Add support for relocatable images *
rhboot/grub2@a620876 *
GitHub<https://github.com/rhboot/grub2/commit/a620876e3b32e4ea0c9a7b3541fcb9a4dd4fb9eb>
--
Fred Baksik
Senior Principal Software Engineer
Mercury Systems
Office: +1 (97
Hi,
On Fri, Jun 16, 2023 at 10:50:14AM +, Baksik, Fred [USA] via Grub-devel
wrote:
>
> I tried report this issue to the bug-grub mailing list but didn’t see the Bug
> Tracker get updated.
> I’d like to get this reported so anyone else using multiboot2 to boot and
> embedde
I tried report this issue to the bug-grub mailing list but didn't see the Bug
Tracker get updated.
I'd like to get this reported so anyone else using multiboot2 to boot and
embedded RTOS knows of this problem.
I also supplied a patch that fixes the issue.
Regards,
Fred Baksik
Sr Pri
Hello folks.
Thank you for this. I a incurring the same problem, can’t boot into Xen.
Did anyone implement the grub2 patch? Is there any way around this?
I have posted it on stackexchange with more details and the config files:
https://unix.stackexchange.com/q/710400/375983
__
_addr_t entry = 0, efi_entry = 0;
> > grub_uint32_t console_required = 0;
> > @@ -123,6 +125,7 @@
> >
> > mld.mbi_ver = 2;
> > mld.relocatable = 0;
> > + grub_multiboot2_mlp.relocatable = 0;
>
> I would prefer if you use mld for this. Of course yo
On Mon, Aug 16, 2021 at 04:34:31PM +0200, Lukasz Hawrylko wrote:
> In contrast to Mulitboot, in Mulitboot2, there is currently no way to
> control where to load the modules to. This could be a problem, e.g., the
> OS loaded by Multiboot2 needs to reserve low address for some particular
&
On Mon, Aug 16, 2021 at 04:35:12PM +0200, Lukasz Hawrylko wrote:
> In the cases of users have preferences over Multiboot2 module load
> addresses, currently GRUB has no way to achieve it.
>
> Similar to the relocatable header tag, this new tag allows users to
> specify the minimum a
In the cases of users have preferences over Multiboot2 module load
addresses, currently GRUB has no way to achieve it.
Similar to the relocatable header tag, this new tag allows users to
specify the minimum and maximum load addresses, and other load
preferences on Multiboot2 modules.
Bump
In contrast to Mulitboot, in Mulitboot2, there is currently no way to
control where to load the modules to. This could be a problem, e.g., the
OS loaded by Multiboot2 needs to reserve low address for some particular
purposes and not for loading modules.
This new tag gives it flexibility to
ents separately.
>
> Looking at the grub manual, this behaviour of the `initrd` command isn't
> even documented. Perhaps that should be fixed first, and then maybe
> `module2_multi` added too?
I am OK with additional Multiboot2 command. Tho
On Thu, 1 Apr 2021 20:43:46 +0100
Andrew Cooper via Grub-devel wrote:
> On 01/04/2021 09:44, Roger Pau Monné wrote:
> > On Thu, Apr 01, 2021 at 09:31:07AM +0200, Jan Beulich wrote:
> >> On 01.04.2021 03:06, Roman Shaposhnik wrote:
> >>> And the obvious next question: is my EVE usecase esoteric en
On 06/04/2021 19:03, Roman Shaposhnik wrote:
> On Tue, Apr 6, 2021 at 10:51 AM Andrew Cooper
> mailto:andrew.coop...@citrix.com>> wrote:
>
> On 06/04/2021 09:19, Jan Beulich wrote:
> > On 01.04.2021 21:43, Andrew Cooper wrote:
> >> On 01/04/2021 09:44, Roger Pau Monné wrote:
> >>> O
On Tue, Apr 6, 2021 at 10:51 AM Andrew Cooper
wrote:
> On 06/04/2021 09:19, Jan Beulich wrote:
> > On 01.04.2021 21:43, Andrew Cooper wrote:
> >> On 01/04/2021 09:44, Roger Pau Monné wrote:
> >>> On Thu, Apr 01, 2021 at 09:31:07AM +0200, Jan Beulich wrote:
> On 01.04.2021 03:06, Roman Shapos
On 06/04/2021 09:19, Jan Beulich wrote:
> On 01.04.2021 21:43, Andrew Cooper wrote:
>> On 01/04/2021 09:44, Roger Pau Monné wrote:
>>> On Thu, Apr 01, 2021 at 09:31:07AM +0200, Jan Beulich wrote:
On 01.04.2021 03:06, Roman Shaposhnik wrote:
> And the obvious next question: is my EVE usecas
On Tue, Apr 6, 2021 at 1:19 AM Jan Beulich wrote:
> On 01.04.2021 21:43, Andrew Cooper wrote:
> > On 01/04/2021 09:44, Roger Pau Monné wrote:
> >> On Thu, Apr 01, 2021 at 09:31:07AM +0200, Jan Beulich wrote:
> >>> On 01.04.2021 03:06, Roman Shaposhnik wrote:
> And the obvious next question:
On 01.04.2021 21:43, Andrew Cooper wrote:
> On 01/04/2021 09:44, Roger Pau Monné wrote:
>> On Thu, Apr 01, 2021 at 09:31:07AM +0200, Jan Beulich wrote:
>>> On 01.04.2021 03:06, Roman Shaposhnik wrote:
And the obvious next question: is my EVE usecase esoteric enough that
I should just go a
On 01/04/2021 09:44, Roger Pau Monné wrote:
> On Thu, Apr 01, 2021 at 09:31:07AM +0200, Jan Beulich wrote:
>> On 01.04.2021 03:06, Roman Shaposhnik wrote:
>>> And the obvious next question: is my EVE usecase esoteric enough that
>>> I should just go ahead and do a custom GRUB patch or is there a mo
don't think Xen should
have any knowledge about it.
Keep in mind that loader is loading Xen, using multiboot2 which is kind of
generic boot protocol, not Linux with its specific protocol. There may be
other multiboot2 kernels that depend on modules being _not_ concatenated,
such change would m
On Thu, Apr 01, 2021 at 09:31:07AM +0200, Jan Beulich wrote:
> On 01.04.2021 03:06, Roman Shaposhnik wrote:
> > And the obvious next question: is my EVE usecase esoteric enough that
> > I should just go ahead and do a custom GRUB patch or is there a more
> > general interest in this?
>
> Not sure
On 01.04.2021 03:06, Roman Shaposhnik wrote:
> And the obvious next question: is my EVE usecase esoteric enough that
> I should just go ahead and do a custom GRUB patch or is there a more
> general interest in this?
Not sure if it ought to be a grub patch - the issue could as well
be dealt with in
Hi Andrew!
first of all -- thanks for pointing me in the right direction. So after
reading relevant sources: comments inline.
On Tue, Mar 30, 2021 at 12:08 PM Andrew Cooper
wrote:
> On 30/03/2021 19:28, Roman Shaposhnik wrote:
> > Hi!
> >
> > seems like I've run int
On 30/03/2021 19:28, Roman Shaposhnik wrote:
> Hi!
>
> seems like I've run into an issue with multiboot2 and module2
> commands that I can't quite explain. Since it may be something
> super simply and silly -- I wanted to reach out here before I do
> a GRUB/Xen/LK so
Add ARM64 relocator code to support multiboot2 loader
Signed-off-by: Chris plant
---
grub-core/lib/arm64/relocator.c | 267
grub-core/lib/arm64/relocator_asm.S | 57 ++
include/grub/arm64/relocator.h | 52 ++
3 files changed, 376 insertions
Enable multiboot2 support for arm64-efi target
Signed-off-by: Chris Plant
---
grub-core/Makefile.core.def | 6 ++
1 file changed, 6 insertions(+)
diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
index b5f47fc41..2c0bec83d 100644
--- a/grub-core/Makefile.core.def
Enable ARM64/aarch64 support in multiboot2 loader
Signed-off-by: Chris Plant
---
grub-core/loader/multiboot.c | 2 +-
grub-core/loader/multiboot_elfxx.c | 2 +-
grub-core/loader/multiboot_mbi2.c | 34 +++---
include/grub/arm64/multiboot.h | 56
Add ARM64 versions of the mmap functions to generate memory map for
multiboot2
Signed-off-by: Chris Plant
---
grub-core/mmap/arm64/uppermem.c | 72 +
include/grub/arm64/memory.h | 60 +++
2 files changed, 132 insertions(+)
create
/multiboot2.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/include/multiboot2.h b/include/multiboot2.h
index 5693923c0..e5071f6f6 100644
--- a/include/multiboot2.h
+++ b/include/multiboot2.h
@@ -63,6 +63,7 @@
#define MULTIBOOT_TAG_TYPE_EFI32_IH 19
#define
Hello,
As you may have guessed from my musings on the mailing list to date,
I've been creating a patch to enable the multiboot2 loader on
ARM64/aarch64.
Why? I am playing with GNU Mach (not sure why - blame COVID-19) on
Raspberry PI. I guess the key driver for why it's interesting
+0100
> > > > Chris Plant via Grub-devel wrote:
> > > >
> > > > > On Sat, 2020-05-23 at 12:43 +0200, Hans Ulrich Niedermann
> > > > > wrote:
> > > > > > On Fri, 22 May 2020 17:23:35 +0100
> > > > > >
> > > On Sat, 2020-05-23 at 12:43 +0200, Hans Ulrich Niedermann
> > > > wrote:
> > > > > On Fri, 22 May 2020 17:23:35 +0100
> > > > > Chris Plant via Grub-devel wrote:
> > > > >
> > > > > > I'm continuing t
Grub-devel wrote:
I'm continuing to work on Multiboot2 support on aarch64, and
I'm
looking at the alignment of the ELF headers which are passed
through
MB2.
At the risk of me sounding stupid...
Having read the MB2 specs quite thoroughly in the past few
months, I
still have no idea
Chris Plant via Grub-devel wrote:
> > >
> > > > I'm continuing to work on Multiboot2 support on aarch64, and
> > > > I'm
> > > > looking at the alignment of the ELF headers which are passed
> > > > through
> > > > MB2.
From: Konrad Rzeszutek Wilk
Fixes: CID 292468
Signed-off-by: Konrad Rzeszutek Wilk
Reviewed-by: Daniel Kiper
---
grub-core/loader/multiboot_mbi2.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/grub-core/loader/multiboot_mbi2.c
b/grub-core/loader/multiboot_mbi2.c
in
In contrast to Mulitboot, in Mulitboot2, there is currently no way to
control where to load the modules to. This could be a problem, e.g., the
OS loaded by Multiboot2 needs to reserve low address for some particular
purposes and not for loading modules.
This new tag gives it flexibility to
On Sat, 23 May 2020 12:21:27 +0100
Chris Plant via Grub-devel wrote:
> On Sat, 2020-05-23 at 12:43 +0200, Hans Ulrich Niedermann wrote:
> > On Fri, 22 May 2020 17:23:35 +0100
> > Chris Plant via Grub-devel wrote:
> >
> > > I'm continuing to work on Mul
On Sat, 2020-05-23 at 12:43 +0200, Hans Ulrich Niedermann wrote:
> On Fri, 22 May 2020 17:23:35 +0100
> Chris Plant via Grub-devel wrote:
>
> > I'm continuing to work on Multiboot2 support on aarch64, and I'm
> > looking at the alignment of the ELF headers which
On Fri, 22 May 2020 17:23:35 +0100
Chris Plant via Grub-devel wrote:
> I'm continuing to work on Multiboot2 support on aarch64, and I'm
> looking at the alignment of the ELF headers which are passed through
> MB2.
At the risk of me sounding stupid...
Having read the MB2 spe
Quoting the Multiboot2 specification:
> 3.1.3 General tag structure
> ---
>
> Tags constitutes a buffer of structures following each other padded
> when necessary in order for each tag to start at 8-bytes aligned
> address. Tags are terminated by a t
Hi,
I'm continuing to work on Multiboot2 support on aarch64, and I'm
looking at the alignment of the ELF headers which are passed through
MB2.
The alignment of the MB2 header's isn't the problem, the problem is in
the ELF headers which are linked through. Some of th
I have just noticed that when running the multiboot2 build with "configure
CC=clang" instead of going with the default gcc, clang10 will not recognize the
"-Wa,-adhlns=$(@:.o=.lst)" argument and abort.
Ist clang support for the multiboot2 example kernel important? If so, I c
t -u program])
+# we are too lazy to figure out whether 'sort -u' works
+SORT_U="\${SORT} | \${UNIQ}"
+AC_SUBST([SORT_U])
+AC_MSG_CHECKING([for sort -u])
+AC_MSG_RESULT([${SORT_U} (lazy)])
+
dnl Build the example Multiboot2 kernel (if possible on this host)
kernel_boot_arch=uns
Generate gcc temporary files for each object file, showing
the intermediate steps after the C preprocessor and immediately
before assembly.
This helps with examining how the example kernel code is
generated, making the example kernel more educational.
Signed-off-by: Hans Ulrich Niedermann
diff
Even if no one ever does a tarball release of the Multiboot2 spec,
"make distcheck" is a good way of checking the build system's
integrity.
Signed-off-by: Hans Ulrich Niedermann
diff --git a/Makefile.am b/Makefile.am
index 70eec9cd0..38e797aa7 100644
--- a/Makefile.am
+++ b/Make
)
+
AC_PROG_CC
AM_PROG_AS
dnl Build the example Multiboot2 kernel (if possible on this host)
-AC_CANONICAL_HOST
kernel_boot_arch=unsupported
kernel_ccasflags=
kernel_cflags=
@@ -57,8 +64,6 @@ AM_CONDITIONAL([BUILD_EXAMPLE_KERNEL],
[test "x$enable_example_kernel" =
le.am
@@ -9,12 +9,13 @@ pkginclude_HEADERS = multiboot2.h
# The example kernel is built if you specify --enable-example-kernel.
if BUILD_EXAMPLE_KERNEL
noinst_PROGRAMS = kernel
+endif
+
kernel_SOURCES = boot_$(kernel_boot_arch).S kernel.c multiboot2.h
kernel_CCASFLAGS = $(kernel_ccasf
ch_sources = boot_i386.S boot_mips.S
multiboot_TEXINFOS = boot_i386.S.texi boot_mips.S.texi kernel.c.texi
multiboot2.h.texi
@@ -17,6 +18,10 @@ kernel_CFLAGS = $(kernel_cflags) -fno-builtin -nostdinc -O
-g -Wall \
-imacros $(top_builddir)/config.h
kernel_LDFLAGS = -nostdlib -Wl,-N -Wl,
When building the example kernel for mips, there is a warning
about __start being undefined and some default address being
chosen as start address.
As this does not inspire confidence, we add a __start symbol
at the same place where start and _start are already defined.
Now the mips build builds
Ulrich Niedermann
diff --git a/doc/Makefile.am b/doc/Makefile.am
index e88f4d271..08fdbf342 100644
--- a/doc/Makefile.am
+++ b/doc/Makefile.am
@@ -1,6 +1,6 @@
info_TEXINFOS = multiboot.texi
arch_sources = boot_i386.S boot_mips.S
-multiboot_TEXINFOS = boot_i386.S.texi kernel.c.texi multiboot2.h.texi
Properly align all Multiboot2 header tags to 8 byte
boundaries as per the Multiboot2 specification.
Note that the assembler directive ".align 8" is machine
dependent: On i386, it means "align to 8 byte boundary".
On mips, it means that the lower 8 bits of address must
be
For code consistency and more clarity as to what these .short
and .long values actually are, use the same system for labeling
the terminator header tag as for labeling all other header tags.
This improves the readability of the code, without changing
the actual output.
Signed-off-by: Hans Ulrich
e3fd6a 100644
--- a/doc/boot_mips.S
+++ b/doc/boot_mips.S
@@ -15,7 +15,6 @@
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
-#define ASM_FILE 1
#include
/* C symbol format. HAVE_ASM_USCORE is defined by configure. */
diff --git a/doc/multiboot2.h b/doc/
Clean up the stack after calling C functions according to the
i386 cdecl calling conventions.
Signed-off-by: Hans Ulrich Niedermann
diff --git a/doc/boot_i386.S b/doc/boot_i386.S
index 20a600a6e..14dc14660 100644
--- a/doc/boot_i386.S
+++ b/doc/boot_i386.S
@@ -101,10 +101,12 @@ multiboot_entry:
dex dc7816d9f..d9efe8116 100644
--- a/doc/Makefile.am
+++ b/doc/Makefile.am
@@ -1,6 +1,6 @@
info_TEXINFOS = multiboot.texi
EXAMPLES = boot_mips.S kernel.c multiboot2.h
-multiboot_TEXINFOS = boot.S.texi kernel.c.texi multiboot2.h.texi
+multiboot_TEXINFOS = boot_i386.S.texi kernel.c.texi multibo
Remove unreferenced AOUT_KLUDGE from both boot_i386.S and
boot_mips.S.
There is no reference in the example kernel to AOUT_KLUDGE or
MULTIBOOT_AOUT_KLUDGE, so this has never had a function in the
Multiboot 2 example kernel.
I presume this was something left over from the Multiboot 1
specification
+25,37 @@ AM_INIT_AUTOMAKE([1.10.1])
AC_PROG_CC
AM_PROG_AS
-dnl Build the example Multiboot2 kernel.
+dnl Build the example Multiboot2 kernel (if possible on this host)
+AC_CANONICAL_HOST
+kernel_boot_arch=unsupported
+kernel_ccasflags=
+kernel_cflags=
+case "$host_cpu" in #(
+ i
Generate a kernel.map map file for the example kernel.
This helps with examining the generated machine code, making
the example kernel more educational.
Signed-off-by: Hans Ulrich Niedermann
diff --git a/.gitignore b/.gitignore
index 7a035c267..889e17f69 100644
--- a/.gitignore
+++ b/.gitignore
Remove the unnecessary separate definition of CC by AC_CHECK_TOOL.
AC_CHECK_TOOL(CC, gcc) might have been necessary back in 1999 when
this line has been written, but AC_PROG_CC has since taken over
defining CC so we do not need AC_CHECK_TOOL for this any more.
Signed-off-by: Hans Ulrich Niederman
In the i386 boot.S file, use the constants with the names
multiboot2.h actually defines them as, and which boot_mips.S
has been using already.
Signed-off-by: Hans Ulrich Niedermann
diff --git a/doc/boot.S b/doc/boot.S
index 8f6f66fcc..9ab016612 100644
--- a/doc/boot.S
+++ b/doc/boot.S
@@ -50,11
= multiboot.texi
-EXAMPLES = boot_mips.S kernel.c multiboot2.h
+arch_sources = boot_i386.S boot_mips.S
multiboot_TEXINFOS = boot_i386.S.texi kernel.c.texi multiboot2.h.texi
SRC2TEXI = src2texi
noinst_SCRIPTS = $(SRC2TEXI)
@@ -9,14 +9,14 @@ pkginclude_HEADERS = multiboot2.h
# The example kernel is built if you
This patch series cleans up the Multiboot2 build system and
example kernel:
* Fix initializing the source tree with autogen.sh when
using current gnulib.
* Change from obsolete .bzrignore to .gitignore.
* Fix the Multiboot2 header tag alignment in the assembly
language boot_*.S
The "CLEANFILES = $(noinst_PROGRAMS)" definition is from 2001-01,
and Automake has learned to clean up generated files automatically
since, so we can remove this.
Signed-off-by: Hans Ulrich Niedermann
diff --git a/doc/Makefile.am b/doc/Makefile.am
index a65b452cf..dc7816d9f 100644
--- a/doc/Make
The remark about "older versions of Autoconf" was added in 2001.
We already AC_PREREQ(2.63) which is from 2008, so we need not
worry about pre-2008 versions of Autoconf, much less about
pre-2001 versions.
Signed-off-by: Hans Ulrich Niedermann
diff --git a/configure.ac b/configure.ac
index 5bfc0
In source code comments, change "Multiboot" to "Multiboot2".
This forced us to touch the completely wrongly placed comment
on the 'flags' in multiboot2.h, so we have moved that comment
where it belongs and added comments for the groups of macro
definitions wh
l" = xyes)
+dnl Build the example Multiboot2 kernel.
+AC_ARG_ENABLE([example-kernel], [dnl
+AS_HELP_STRING([--enable-example-kernel],
+ [build the example Multiboot2 kernel])])
+
+AM_CONDITIONAL([BUILD_EXAMPLE_KERNEL],
+ [test "x$enable_example_kernel"
iboot.texi])
AC_CONFIG_HEADER([config.h])
-AM_INIT_AUTOMAKE
+AM_INIT_AUTOMAKE([1.10.1])
#
# Programs
@@ -26,10 +26,6 @@ AC_CHECK_TOOL([CC], [gcc])
AC_PROG_CC
AM_PROG_AS
-dnl Because recent automake complains about AS, set it here.
-CCAS="$CC"
-AC_SUBST([CCAS])
-
dnl Build the examp
$(top_builddir)/config.h
kernel_LDFLAGS = -nostdlib -Wl,-N -Wl,-Ttext -Wl,8010 -Wl,--build-id=none
-
-boot.o: multiboot2.h
endif
EXTRA_DIST = $(man_MANS) $(noinst_SCRIPTS) \
--
2.26.2
___
Grub-devel mailing list
Grub-devel@gnu.org
https
1 - 100 of 673 matches
Mail list logo
