Re: boot/grub2: grub-core-build-fixes-for-i386 (grub-2.04 + binutils-2.35.2 + pseudo-op .code64)
Hello Jan! On 5/18/21 7:05 AM, Jan Nieuwenhuizen wrote: >>> Sure, sent separately to bug-grub. >> >> I cannot find your updated patch. > > It's here: > > https://lists.gnu.org/archive/html/bug-grub/2021-05/msg9.html > >> May I ask you to send it using "git-send-email" to grub-devel@gnu.org? > > (waiting with this for a bit, please ping if needed :) I think you should post the patch to this mailing list so it can be reviewed here. Reviewing the patch when it's located in the archives of a different mailing list is a bit awkward. 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 v2] grub-core: Build fixes for i386
This fixes cross-compiling to x86 (e.g., the Hurd) from x86-linux. To reproduce, update the Grub source description in your local Guix archive and run ./pre-inst-env guix build --system=i686-linux --target=i586-pc-gnu grub or install an x86 cross-build environment on x86-linux (32bit!) and configure to cross build and make, e.g., do something like ./configure \ CC_FOR_BUILD=gcc \ --build=i686-unknown-linux-gnu --host=i586-pc-gnu make * grub-core/lib/i386/relocator64.S: Avoid x86_64 instructions on i386. --- grub-core/lib/i386/relocator64.S | 27 +-- 1 file changed, 25 insertions(+), 2 deletions(-) diff --git a/grub-core/lib/i386/relocator64.S b/grub-core/lib/i386/relocator64.S index 148f38adb..b4675dd16 100644 --- a/grub-core/lib/i386/relocator64.S +++ b/grub-core/lib/i386/relocator64.S @@ -63,8 +63,10 @@ VARIABLE(grub_relocator64_cr3) movq%rax, %cr3 #endif +#ifdef __x86_64__ .code64 +#endif /* mov imm64, %rax */ .byte 0x48 @@ -71,7 +73,14 @@ VARIABLE(grub_relocator64_cr3) VARIABLE(grub_relocator64_rsp) .quad 0 +#ifdef __x86_64__ movq%rax, %rsp +#else + /* movq %rax, %rsp */ + .byte 0x48 + .byte 0x89 + .byte 0xc4 +#endif #ifdef GRUB_MACHINE_EFI jmp LOCAL(skip_efi_stack_align) @@ -85,7 +94,14 @@ VARIABLE(grub_relocator64_rsp) */ VARIABLE(grub_relocator64_efi_start) /* Align the stack as UEFI spec requires. */ +#ifdef __x86_64__ andq$~15, %rsp +#else + .byte 0x48 +.byte 0x83 +.byte 0xe4 +.byte 0xf0 +#endif LOCAL(skip_efi_stack_align): #endif @@ -95,8 +111,15 @@ LOCAL(skip_efi_stack_align): VARIABLE(grub_relocator64_rsi) .quad 0 +#ifdef __x86_64__ movq%rax, %rsi - +#else + /* movq %rax, %rsi */ + .byte 0x48 + .byte 0x89 + .byte 0xc6 +#endif + /* mov imm64, %rax */ .byte 0x48 .byte 0xb8 @@ -125,7 +148,7 @@ VARIABLE(grub_relocator64_rdx) payload and makes this implementation easier. */ cld -#ifdef __APPLE__ +#if defined (__APPLE__) || !defined (__x86_64__) .byte 0xff, 0x25 .quad 0 #else -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2] Fix backspace in the username login prompt
Indeed I tested it with both CLI and menu entry editing and it works fine. Thank you for taking the time to answer me. PS Sorry if you received this message more than once. Egor ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2] grub-core: Build fixes for i386
Hello Jan! On 5/18/21 12:47 PM, Jan (janneke) Nieuwenhuizen wrote: > or install an x86 cross-build environment on x86-linux (32bit!) and > configure to cross build and make, e.g., do something like Are we talking about a toolchain which exclusively supports 32-bit builds only? If yes, wouldn't it make sense to exclude the whole file relocator64.S? I think hacking the opcodes into the assembly sources directly to allow assembling the assembly source file with a pure 32-bit assembler seems like a crude workaround that I wouldn't use in an upstream source tree. It seems the issue is more that you are trying to build 64-bit code with a toolchain which exclusively supports 32-bit code which I'm not sure is something that can be officially supported. 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 v4] grub-install: Add backup and restore
On Wed, May 12, 2021 at 08:24:44PM +0100, Dimitri John Ledkov wrote:
> Refactor clean_grub_dir to create a backup of all the files, instead
> of just irrevocably removing them as the first action. If available,
> register atexit handle to restore the backup if errors occur before
> point of no return, or remove the backup if everything was
> successful. If atexit is not available, the backup remains on disk for
> manual recovery.
>
> Some platforms defined a point of no return, i.e. after modules & core
> images were updated. Failures from any commands after that stage are
> ignored, and backup is cleanedup. For example, on EFI platforms update
> is not reverted when efibootmgr fails.
>
> Extra care is taken to ensure atexit handler is only invoked by the
> parent process and not any children forks. Some older grub codebases
> can invoke parent atexit hooks from forks, which can mess up the
> backup.
>
> This allows safer upgrades of MBR & modules, such that
> modules/images/fonts/translations are consistent with MBR in case of
> errors. For example accidental grub-install /dev/non-existent-disk
> currently clobbers and upgrades modules in /boot/grub, despite not
> actually updating any MBR.
>
> This patch only handles backup and restore of files copied to
> /boot/grub. This patch does not perform backup (or restoration) of MBR
> itself or blocklists. Thus when installing i386-pc platform,
> corruption may still occur with MBR and blocklists which will not be
> attempted to be automatically recovered.
>
> Also add modinfo.sh and *.efi to the cleanup/backup/restore codepath,
> to ensure it is also cleaned / backed up / restored.
>
> Signed-off-by: Dimitri John Ledkov
> ---
> configure.ac| 2 +-
> include/grub/util/install.h | 13
> util/grub-install-common.c | 140
> util/grub-install.c | 33 ++---
> util/grub-mknetdir.c| 3 +
> util/grub-mkrescue.c| 3 +
> util/grub-mkstandalone.c| 2 +
> 7 files changed, 172 insertions(+), 24 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 74719416c4..a5e94f360e 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -419,7 +419,7 @@ else
> fi
>
> # Check for functions and headers.
> -AC_CHECK_FUNCS(posix_memalign memalign getextmntent)
> +AC_CHECK_FUNCS(posix_memalign memalign getextmntent atexit)
> AC_CHECK_HEADERS(sys/param.h sys/mount.h sys/mnttab.h limits.h)
>
> # glibc 2.25 still includes sys/sysmacros.h in sys/types.h but emits
> deprecation
> diff --git a/include/grub/util/install.h b/include/grub/util/install.h
> index b93c73caac..d6e9ce4460 100644
> --- a/include/grub/util/install.h
> +++ b/include/grub/util/install.h
> @@ -275,4 +275,17 @@ extern char *grub_install_copy_buffer;
> int
> grub_install_is_short_mbrgap_supported (void);
>
> +/*
> + * grub-install-common tries to make backups of modules & auxilary
> + * files, and restore the backup upon failure to install core.img. There
> + * are platforms with additional actions after modules & core got
> + * installed in place. It is a point of no return, as core.img cannot be
> + * reverted from this point onwards, and new modules should be kept
> + * installed. Before performing these additional actions raise
> + * grub_install_backup_ponr flag, this way failure to perform additional
> + * actions will not result in reverting new modules to the old
> + * ones. (i.e. in case efivars updates fails)
> + */
> +extern size_t grub_install_backup_ponr;
Hmmm... The size_t does not look like a good fit for this. I would define
grub_install_backup_ponr as an int.
> #endif
> diff --git a/util/grub-install-common.c b/util/grub-install-common.c
> index b4f28840f1..84c1db8674 100644
> --- a/util/grub-install-common.c
> +++ b/util/grub-install-common.c
> @@ -185,38 +185,148 @@ grub_install_mkdir_p (const char *dst)
>free (t);
> }
>
> +static int
> +strcmp_ext (const char *a, const char *b, const char *ext)
> +{
> + char *bsuffix = grub_util_path_concat_ext (1, b, ext);
> + int r = strcmp (a, bsuffix);
> +
> + free (bsuffix);
> + return r;
> +}
> +
> +enum clean_grub_dir_mode
> +{
> + CLEAN_NEW,
> + CLEAN_BACKUP,
> + CREATE_BACKUP,
> + RESTORE_BACKUP
> +};
> +
> +static size_t backup_dirs_size = 0;
> +static char **backup_dirs = NULL;
> +static pid_t backup_process = 0;
> +size_t grub_install_backup_ponr = 0;
Ditto...
[...]
> +static void
> +restore_backup_atexit (void)
> +{
> + /*
> + * some child inherited atexit handler, did not clear it, and called
> + * it; thus skip clean or restore logic.
> + */
> + if (backup_process != getpid ())
> +return;
> +
> + for (size_t i = 0; i < backup_dirs_size; i++)
I would define "i" at the beginning of this function.
> +{
> + /* if past point of no return simply clean the
> + backups. Otherwise cleanup newly installed files,
> + and restore the backups */
Please fix the formatting of this comment...
[...
Re: [PATCH v2] Fix backspace in the username login prompt
On 5/17/21 7:34 PM, Daniel Kiper wrote: Did you test your patch outside of username login prompt, e.g. CLI or menu entry editing? I am afraid your patch breaks at least these cases. Daniel Indeed I tested it with both CLI and menu entry editing and it works fine. Thank you for taking the time to answer me. Egor ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2] grub-core: Build fixes for i386
Hey Adrian, On Tue, May 18, 2021 at 12:58:07PM +0200, John Paul Adrian Glaubitz wrote: > Hello Jan! > > On 5/18/21 12:47 PM, Jan (janneke) Nieuwenhuizen wrote: > > or install an x86 cross-build environment on x86-linux (32bit!) and > > configure to cross build and make, e.g., do something like > > Are we talking about a toolchain which exclusively supports 32-bit builds > only? If yes, wouldn't it make sense to exclude the whole file relocator64.S? > > I think hacking the opcodes into the assembly sources directly to allow > assembling > the assembly source file with a pure 32-bit assembler seems like a crude > workaround > that I wouldn't use in an upstream source tree. > > It seems the issue is more that you are trying to build 64-bit code with a > toolchain > which exclusively supports 32-bit code which I'm not sure is something that > can be > officially supported. When I was looking at the issue first time I thought in the same way. Though after some thinking I realized that it is perfectly valid to start 64-bit kernel from 32-bit bootloader which was build in 32-bit environment. So, I think it makes sense to take that patch, which is not very complicated and does not introduce anything which did not exist earlier in the relocator64.S, even a such scenario is not very common today. Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2] grub-core: Build fixes for i386
Hi Daniel! On 5/18/21 4:26 PM, Daniel Kiper wrote: > When I was looking at the issue first time I thought in the same way. > Though after some thinking I realized that it is perfectly valid to > start 64-bit kernel from 32-bit bootloader which was build in 32-bit > environment. So, I think it makes sense to take that patch, which is not > very complicated and does not introduce anything which did not exist > earlier in the relocator64.S, even a such scenario is not very common > today. But this is about the toolchain, isn't it? Shouldn't even a 32-bit x86 toolchain be able to build 64-bit code? I just checked standard binutils on a 32-bit Debian system and both the assembler and the linker support 64-bit targets: (sid_i386-dchroot)glaubitz@barriere:~$ as --help|grep 64 --32/--64/--x32 generate 32bit/64bit/x32 code generic32, generic64, i386, i486, i586, i686, pconfig, waitpkg, cldemote, movdiri, movdir64b, nomovdiri, nomovdir64b, noavx512_bf16, generic32, generic64, i8086, i186, i286, i386, i486, -mamd64 accept only AMD64 ISA [default] -mintel64 accept only Intel64 ISA (sid_i386-dchroot)glaubitz@barriere:~$ (sid_i386-dchroot)glaubitz@barriere:~$ ld --help|grep supported ld: supported targets: elf32-i386 elf32-iamcu pei-i386 elf32-little elf32-big elf64-x86-64 elf32-x86-64 pei-x86-64 elf64-l1om elf64-k1om elf64-little elf64-big pe-x86-64 pe-bigobj-x86-64 pe-i386 srec symbolsrec verilog tekhex binary ihex plugin trad-core ld: supported emulations: elf_i386 elf_iamcu elf_x86_64 elf32_x86_64 elf_l1om elf_k1om i386pep i386pe (sid_i386-dchroot)glaubitz@barriere:~$ So I'm not sure what kind of host system we are talking about here? This looks more like a configuration issue of the distribution in question which deliberately builds its 32-bit toolchain without 64-bit support. 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] grub-core: Build fixes for i386
On 5/18/21 4:35 PM, John Paul Adrian Glaubitz wrote: > So I'm not sure what kind of host system we are talking about here? This looks > more like a configuration issue of the distribution in question which > deliberately > builds its 32-bit toolchain without 64-bit support. Hmm, I just noticed that the existing code already does use these crude hacks to be able to build 64-bit code with a 32-bit assembler: > http://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/lib/i386/relocator64.S#n57 But still, I find that very odd that the host system's toolchain isn't just built with 64-bit support enabled but maybe I'm missing something obvious. 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] grub-core: Build fixes for i386
On Tue, May 18, 2021 at 3:48 AM Jan (janneke) Nieuwenhuizen wrote: > > This fixes cross-compiling to x86 (e.g., the Hurd) from x86-linux. > > To reproduce, update the Grub source description in your local Guix > archive and run > >./pre-inst-env guix build --system=i686-linux --target=i586-pc-gnu grub > > or install an x86 cross-build environment on x86-linux (32bit!) and > configure to cross build and make, e.g., do something like > > ./configure \ >CC_FOR_BUILD=gcc \ >--build=i686-unknown-linux-gnu >--host=i586-pc-gnu > make > > * grub-core/lib/i386/relocator64.S: Avoid x86_64 instructions on i386. > --- > grub-core/lib/i386/relocator64.S | 27 +-- > 1 file changed, 25 insertions(+), 2 deletions(-) > > diff --git a/grub-core/lib/i386/relocator64.S > b/grub-core/lib/i386/relocator64.S > index 148f38adb..b4675dd16 100644 > --- a/grub-core/lib/i386/relocator64.S > +++ b/grub-core/lib/i386/relocator64.S > @@ -63,8 +63,10 @@ VARIABLE(grub_relocator64_cr3) > movq%rax, %cr3 > #endif > > > +#ifdef __x86_64__ > .code64 > +#endif > > /* mov imm64, %rax */ > .byte 0x48 > @@ -71,7 +73,14 @@ VARIABLE(grub_relocator64_cr3) > VARIABLE(grub_relocator64_rsp) > .quad 0 > > +#ifdef __x86_64__ > movq%rax, %rsp > +#else > + /* movq %rax, %rsp */ > + .byte 0x48 > + .byte 0x89 > + .byte 0xc4 > +#endif > > #ifdef GRUB_MACHINE_EFI > jmp LOCAL(skip_efi_stack_align) > @@ -85,7 +94,14 @@ VARIABLE(grub_relocator64_rsp) > */ > VARIABLE(grub_relocator64_efi_start) > /* Align the stack as UEFI spec requires. */ > +#ifdef __x86_64__ > andq$~15, %rsp > +#else > + .byte 0x48 > +.byte 0x83 > +.byte 0xe4 > +.byte 0xf0 Indentation on these lines is inconsistent. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH v2 0/3] ieee1275: find and claim more memory
I've posted a couple of RFC patches that attempted to claim some more memory on ieee1275 platforms, which is necessary for the verifiers to do their work. The RFCs were a bit unsatisfactory and also it turns out they broke in some corner cases. This, I believe, is a proper, upstream-worthy solution for getting more memory on ieee1275 platforms and powerpc-ieee1275 in particular. It is also, sadly, an set of quite complex solutions, as the commit messages for patches 2 and 3 show! It seems this is the cost of broad platform support and backwards compatibility. There's no reason for this to go into 2.06. Kind regards, Daniel v2: fix the bug where I mixed up model and compatible. Daniel Axtens (3): ieee1275: drop HEAP_MAX_ADDR, HEAP_MIN_SIZE ieee1275: claim more memory ieee1275: request memory with ibm,client-architecture-support docs/grub-dev.texi | 6 +- grub-core/kern/ieee1275/cmain.c | 3 + grub-core/kern/ieee1275/init.c | 238 ++- include/grub/ieee1275/ieee1275.h | 6 + 4 files changed, 218 insertions(+), 35 deletions(-) -- 2.27.0 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH v2 1/3] ieee1275: drop HEAP_MAX_ADDR, HEAP_MIN_SIZE
HEAP_MAX_ADDR is confusing. Currently it is set to 32MB, except
on ieee1275 on x86, where it is 64MB.
There is a comment which purports to explain it:
/* If possible, we will avoid claiming heap above this address, because it
seems to cause relocation problems with OSes that link at 4 MiB */
This doesn't make a lot of sense when the constants are well above 4MB
already. It was not always this way. Prior to
commit 7b5d0fe4440c ("Increase heap limit") in 2010, HEAP_MAX_SIZE and
HEAP_MAX_ADDR were indeed 4MB. However, when the constants were increased
the comment was left unchanged.
It's been over a decade. It doesn't seem like we have problems with
claims over 4MB on powerpc or x86 ieee1275. (sparc does things completely
differently and never used the constant.)
Drop the constant and the check.
The only use of HEAP_MIN_SIZE was to potentially override the
HEAP_MAX_ADDR check. It is now unused. Remove it.
Signed-off-by: Daniel Axtens
---
grub-core/kern/ieee1275/init.c | 17 -
1 file changed, 17 deletions(-)
diff --git a/grub-core/kern/ieee1275/init.c b/grub-core/kern/ieee1275/init.c
index 7a1ebdf94e06..c81cfc0320ae 100644
--- a/grub-core/kern/ieee1275/init.c
+++ b/grub-core/kern/ieee1275/init.c
@@ -46,9 +46,6 @@
#endif
#include
-/* The minimal heap size we can live with. */
-#define HEAP_MIN_SIZE (unsigned long) (2 * 1024 * 1024)
-
/* The maximum heap size we're going to claim */
#ifdef __i386__
#define HEAP_MAX_SIZE (unsigned long) (64 * 1024 * 1024)
@@ -56,14 +53,6 @@
#define HEAP_MAX_SIZE (unsigned long) (32 * 1024 * 1024)
#endif
-/* If possible, we will avoid claiming heap above this address, because it
- seems to cause relocation problems with OSes that link at 4 MiB */
-#ifdef __i386__
-#define HEAP_MAX_ADDR (unsigned long) (64 * 1024 * 1024)
-#else
-#define HEAP_MAX_ADDR (unsigned long) (32 * 1024 * 1024)
-#endif
-
extern char _start[];
extern char _end[];
@@ -184,12 +173,6 @@ heap_init (grub_uint64_t addr, grub_uint64_t len,
grub_memory_type_t type,
if (*total + len > HEAP_MAX_SIZE)
len = HEAP_MAX_SIZE - *total;
- /* Avoid claiming anything above HEAP_MAX_ADDR, if possible. */
- if ((addr < HEAP_MAX_ADDR) &&/* if it's too
late, don't bother */
- (addr + len > HEAP_MAX_ADDR) && /* if it wasn't
available anyway, don't bother */
- (*total + (HEAP_MAX_ADDR - addr) > HEAP_MIN_SIZE)) /* only limit
ourselves when we can afford to */
- len = HEAP_MAX_ADDR - addr;
-
/* In theory, firmware should already prevent this from happening by not
listing our own image in /memory/available. The check below is intended
as a safeguard in case that doesn't happen. However, it doesn't protect
--
2.27.0
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH v2 2/3] ieee1275: claim more memory
On powerpc-ieee1275, we are running out of memory trying to verify anything. This is because: - we have to load an entire file into memory to verify it. This is extremely difficult to change with appended signatures. - We only have 32MB of heap. - Distro kernels are now often around 30MB. So we want to claim more memory from OpenFirmware for our heap. There are some complications: - The grub mm code isn't the only thing that will make claims on memory from OpenFirmware: * PFW/SLOF will have claimed some for their own use. * The ieee1275 loader will try to find other bits of memory that we haven't claimed to place the kernel and initrd when we go to boot. * Once we load Linux, it will also try to claim memory. It claims memory without any reference to /memory/available, it just starts at min(top of RMO, 768MB) and works down. So we need to avoid this area. See arch/powerpc/kernel/prom_init.c as of v5.11. - The smallest amount of memory a ppc64 KVM guest can have is 256MB. It doesn't work with distro kernels but can work with custom kernels. We should maintain support for that. (ppc32 can boot with even less, and we shouldn't break that either.) - Even if a VM has more memory, the memory OpenFirmware makes available as Real Memory Area can be restricted. A freshly created LPAR on a PowerVM machine is likely to have only 256MB available to OpenFirmware even if it has many gigabytes of memory allocated. EFI systems will attempt to allocate 1/4th of the available memory, clamped to between 1M and 1600M. That seems like a good sort of approach, we just need to figure out if 1/4 is the right fraction for us. We don't know in advance how big the kernel and initrd are going to be, which makes figuring out how much memory we can take a bit tricky. To figure out how much memory we should leave unused, I looked at: - an Ubuntu 20.04.1 ppc64le pseries KVM guest: vmlinux: ~30MB initrd: ~50MB - a RHEL8.2 ppc64le pseries KVM guest: vmlinux: ~30MB initrd: ~30MB Ubuntu VMs struggle to boot with just 256MB under SLOF. RHEL likewise has a higher minimum supported memory figure. So lets first consider a distro kernel and 512MB of addressible memory. (This is the default case for anything booting under PFW.) Say we lose 131MB to PFW (based on some tests). This leaves us 381MB. 1/4 of 381MB is ~95MB. That should be enough to verify a 30MB vmlinux and should leave plenty of space to load Linux and the initrd. If we consider 256MB of RMA under PFW, we have just 125MB remaining. 1/4 of that is a smidge under 32MB, which gives us very poor odds of verifying a distro-sized kernel. However, if we need 80MB just to put the kernel and initrd in memory, we can't claim any more than 45MB anyway. So 1/4 will do. We'll come back to this later. grub is always built as a 32-bit binary, even if it's loading a ppc64 kernel. So we can't address memory beyond 4GB. This gives a natural cap of 1GB for powerpc-ieee1275. Also apply this 1/4 approach to i386-ieee1275, but keep the 32MB cap. make check still works for both i386 and powerpc and I've booted powerpc grub with this change under SLOF and PFW. Signed-off-by: Daniel Axtens --- docs/grub-dev.texi | 6 ++- grub-core/kern/ieee1275/init.c | 81 +++--- 2 files changed, 69 insertions(+), 18 deletions(-) diff --git a/docs/grub-dev.texi b/docs/grub-dev.texi index a834b3a9c32c..5dc7c285cf87 100644 --- a/docs/grub-dev.texi +++ b/docs/grub-dev.texi @@ -1047,7 +1047,9 @@ space is limited to 4GiB. GRUB allocates pages from EFI for its heap, at most 1.6 GiB. On i386-ieee1275 and powerpc-ieee1275 GRUB uses same stack as IEEE1275. -It allocates at most 32MiB for its heap. + +On i386-ieee1275, GRUB allocates at most 32MiB for its heap. On +powerpc-ieee1275, GRUB allocates up to 1GiB. On sparc64-ieee1275 stack is 256KiB and heap is 2MiB. @@ -1075,7 +1077,7 @@ In short: @item i386-qemu @tab 60 KiB @tab < 4 GiB @item *-efi @tab ? @tab < 1.6 GiB @item i386-ieee1275 @tab ? @tab < 32 MiB -@item powerpc-ieee1275@tab ? @tab < 32 MiB +@item powerpc-ieee1275@tab ? @tab < 1 GiB @item sparc64-ieee1275@tab 256KiB @tab 2 MiB @item arm-uboot @tab 256KiB @tab 2 MiB @item mips(el)-qemu_mips @tab 2MiB@tab 253 MiB diff --git a/grub-core/kern/ieee1275/init.c b/grub-core/kern/ieee1275/init.c index c81cfc0320ae..3053a59fe9e1 100644 --- a/grub-core/kern/ieee1275/init.c +++ b/grub-core/kern/ieee1275/init.c @@ -46,11 +46,12 @@ #endif #include -/* The maximum heap size we're going to claim */ +/* The maximum heap size we're going to claim. Not used by sparc. + We allocate 1/4 of the available memory under 4G, up to this limit. */ #ifdef __i386__ #define HEAP_MAX_SIZE (unsigned long) (64 * 1024 * 1024) -#else -#define HEAP_MAX_SIZE
[PATCH v2 3/3] ieee1275: request memory with ibm, client-architecture-support
On PowerVM, the first time we boot a Linux partition, we may only get
256MB of real memory area, even if the partition has more memory.
This isn't really enough. Fortunately, the Power Architecture Platform
Reference (PAPR) defines a method we can call to ask for more memory.
This is part of the broad and powerful ibm,client-architecture-support
(CAS) method.
CAS can do an enormous amount of things on a PAPR platform: as well as
asking for memory, you can set the supported processor level, the interrupt
controller, hash vs radix mmu, and so on. We want to touch as little of
this as possible because we don't want to step on the toes of the future OS.
If:
- we are running under what we think is PowerVM (compatible property of /
begins with "IBM"), and
- the full amount of RMA is less than 512MB (as determined by the reg
property of /memory)
then call CAS as follows: (refer to the Linux on Power Architecture
Reference, LoPAR, which is public, at B.5.2.3):
- Use the "any" PVR value and supply 2 option vectors.
- Set option vector 1 (PowerPC Server Processor Architecture Level)
to "ignore".
- Set option vector 2 with default or Linux-like options, including a
min-rma-size of 512MB.
This will cause a CAS reboot and the partition will restart with 512MB
of RMA. Grub will notice the 512MB and not call CAS again.
(A partition can be configured with only 256MB of memory, which would
mean this request couldn't be satisfied, but PFW refuses to load with
only 256MB of memory, so it's a bit moot. SLOF will run fine with 256MB,
but we will never call CAS under qemu/SLOF because /compatible won't
begin with "IBM".)
One of the first things Linux does while still running under OpenFirmware
is to call CAS with a much fuller set of options (including asking for
512MB of memory). This includes a much more restrictive set of PVR values
and processor support levels, and this will induce another reboot. On this
reboot grub will again notice the higher RMA, and not call CAS. We will get
to Linux, Linux will call CAS but because the values are now set for Linux
this will not induce another CAS reboot and we will finally boot.
On all subsequent boots, everything will be configured with 512MB of RMA
and all the settings Linux likes, so there will be no further CAS reboots.
(phyp is super sticky with the RMA size - it persists even on cold boots.
So if you've ever booted Linux in a partition, you'll probably never have
grub call CAS. It'll only ever fire the first time a partition loads grub,
or if you deliberately lower the amount of memory your partition has below
512MB.)
Signed-off-by: Daniel Axtens
---
grub-core/kern/ieee1275/cmain.c | 3 +
grub-core/kern/ieee1275/init.c | 144 ++-
include/grub/ieee1275/ieee1275.h | 6 ++
3 files changed, 151 insertions(+), 2 deletions(-)
diff --git a/grub-core/kern/ieee1275/cmain.c b/grub-core/kern/ieee1275/cmain.c
index 20cbbd761ec3..cc98811f4f99 100644
--- a/grub-core/kern/ieee1275/cmain.c
+++ b/grub-core/kern/ieee1275/cmain.c
@@ -124,6 +124,9 @@ grub_ieee1275_find_options (void)
break;
}
}
+
+ if (grub_strncmp (tmp, "IBM,", 4) == 0)
+ grub_ieee1275_set_flag (GRUB_IEEE1275_FLAG_CAN_TRY_CAS_FOR_MORE_MEMORY);
}
if (is_smartfirmware)
diff --git a/grub-core/kern/ieee1275/init.c b/grub-core/kern/ieee1275/init.c
index 3053a59fe9e1..5faf4e736074 100644
--- a/grub-core/kern/ieee1275/init.c
+++ b/grub-core/kern/ieee1275/init.c
@@ -241,6 +241,135 @@ heap_init (grub_uint64_t addr, grub_uint64_t len,
grub_memory_type_t type,
return 0;
}
+/* How much memory does OF believe it has? (regardless of whether
+ it's accessible or not) */
+static grub_err_t
+grub_ieee1275_total_mem (grub_uint64_t *total)
+{
+ grub_ieee1275_phandle_t root;
+ grub_ieee1275_phandle_t memory;
+ grub_uint32_t reg[4];
+ grub_ssize_t reg_size;
+ grub_uint32_t address_cells = 1;
+ grub_uint32_t size_cells = 1;
+ grub_uint64_t size;
+
+ /* If we fail to get to the end, report 0. */
+ *total = 0;
+
+ /* Determine the format of each entry in `reg'. */
+ grub_ieee1275_finddevice ("/", &root);
+ grub_ieee1275_get_integer_property (root, "#address-cells", &address_cells,
+ sizeof address_cells, 0);
+ grub_ieee1275_get_integer_property (root, "#size-cells", &size_cells,
+ sizeof size_cells, 0);
+
+ if (size_cells > address_cells)
+address_cells = size_cells;
+
+ /* Load `/memory/reg'. */
+ if (grub_ieee1275_finddevice ("/memory", &memory))
+return grub_error (GRUB_ERR_UNKNOWN_DEVICE,
+ "couldn't find /memory node");
+ if (grub_ieee1275_get_integer_property (memory, "reg", reg,
+ sizeof reg, ®_size))
+return grub_error (GRUB_ERR_UNKNOWN_DEVICE,
+ "couldn't examine /memory/reg property");
+ if (reg_size < 0 || (grub_size_t) reg_size
[PATCH 0/3] A few small OpenBSD-ish fixes
Hello, I built GRUB on OpenBSD 6.9 over the weekend, and ran into a few issues. The minor ones attached were easy enough to fix. Unfortunately, once installed, it merely prints "Grub Loading" (or something similar) and reboots. In trying to recover from this, I wiped out the MBR and that's when I gave up and figured maybe I should do this in a VM instead. One other issue I ran into was that setjmp.mod would fail to build because it didn't export any symbols. No other modules seemed to depend on it. I just removed it from Makefile, but I'm not familiar enough with GRUB to know whether that's a reasonable enough solution, or if that's related to the inability to boot. Cheers, // jacob jacob berkman (3): Do not fail configure if Python is missing. It's only required for developement of GRUB. Fix warning about misleading indentation on OpenBSD 6.9 with -Werror enabled (which is the default). Use size_t printf format to match type configure.ac| 2 +- grub-core/fs/zfs/zfs.c | 4 ++-- grub-core/lib/LzmaEnc.c | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) -- 2.30.1 (Apple Git-130) ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH 1/3] Do not fail configure if Python is missing. It's only required for developement of GRUB.
--- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 74719416c..dba38d731 100644 --- a/configure.ac +++ b/configure.ac @@ -362,7 +362,7 @@ gl_EARLY AC_PROG_CXX AM_PROG_CC_C_O AM_PROG_AS -AM_PATH_PYTHON([2.6]) +AM_PATH_PYTHON([2.6],, [:]) # Must be GCC. test "x$GCC" = xyes || AC_MSG_ERROR([GCC is required]) -- 2.30.1 (Apple Git-130) ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH 2/3] Fix warning about misleading indentation on OpenBSD 6.9 with -Werror enabled (which is the default).
---
grub-core/lib/LzmaEnc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/grub-core/lib/LzmaEnc.c b/grub-core/lib/LzmaEnc.c
index 52b331558..4636a9ffe 100644
--- a/grub-core/lib/LzmaEnc.c
+++ b/grub-core/lib/LzmaEnc.c
@@ -1358,7 +1358,7 @@ static UInt32 GetOptimum(CLzmaEnc *p, UInt32 position,
UInt32 *backRes)
if (repIndex == 0)
startLen = lenTest + 1;
- /* if (_maxMode) */
+ if (True /* _maxMode */)
{
UInt32 lenTest2 = lenTest + 1;
UInt32 limit = lenTest2 + p->numFastBytes;
--
2.30.1 (Apple Git-130)
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH 3/3] Use size_t printf format to match type
---
grub-core/fs/zfs/zfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/grub-core/fs/zfs/zfs.c b/grub-core/fs/zfs/zfs.c
index f9e755197..a29db8827 100644
--- a/grub-core/fs/zfs/zfs.c
+++ b/grub-core/fs/zfs/zfs.c
@@ -1881,8 +1881,8 @@ zio_read (blkptr_t *bp, grub_zfs_endian_t endian, void
**buf,
<< SPA_MINBLOCKSHIFT));
psize = get_psize (bp, endian);
}
- grub_dprintf("zfs", "zio_read: E %d: size %" PRIdGRUB_SSIZE "/%"
- PRIdGRUB_SSIZE "\n", (int)BP_IS_EMBEDDED(bp), lsize, psize);
+ grub_dprintf("zfs", "zio_read: E %d: size %" PRIuGRUB_SIZE "/%"
+ PRIuGRUB_SIZE "\n", (int)BP_IS_EMBEDDED(bp), lsize, psize);
if (size)
*size = lsize;
--
2.30.1 (Apple Git-130)
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
