Hi,
> - Why is the name bootloongarch64.efi a problem in the ISO filesystem ?
>
> The name length restriction of -iso-level 1 applies only to the dull
> ISO 9660 names, but not to Rock Ridge names, which GRUB uses if present.
I doubt the vfat driver of the uefi firmware supports rock
On Wed, Jun 21, 2023 at 03:14:17PM +0200, Julian Andres Klode wrote:
> So all we did with the surface in SDL1 was split into window,
> surface, renderer, and texture. Instead of drawing into the
> surface and then flipping, you build your pixels, then update
> a texture, and then copy the texture
Hi,
> - we decide that GRUB 2.xx (whichever was the most recent release at
> the time of the decision) is good enough to boot Linux on ia64 for the
> remaining life time of the architecture, and remove it from the GRUB
> tree.
That looks like the most reasonable option to me.
Note that ia64
Hi,
> > > Do not load the system 32-bit ARM firmware VARS file because it
> > > must be writable to prevent a data exception and boot failure. So
> > > in order to use the VARS file, it must be copied to a writable
> > > location, but its quite large at 64M and is not needed to boot
> > >
On Sat, Jan 21, 2023 at 12:15:20AM -0600, Glenn Washburn wrote:
> The current qemu firmware paths for arm-efi and arm64-efi are not available
> on Ubuntu/Debian but are hardcoded. Switch to first looking for firmware
> files in the source directory and if not found, look for them in locations
>
On Sun, Oct 02, 2022 at 05:18:05PM +0200, Oliver Steffen wrote:
> According to UEFI Specification Version 2.9, Section 10.3.5
> multiple File nodes are allowed in the path. So this is not really
> a bug.
Even though the uefi specification allows using multiple File nodes
actually doing so looks
Hi,
> GRUB_SERIAL_COMMAND="serial --port=0x40a0 --speed=115200"
> + grub_snprintf (com_names[i], sizeof (com_names[i]), "pci%d", i);
So this patch goes register the device(s) as 'pciN', so you don't have
to figure the ioport but can just use 'serial pci0' ?
take care,
Gerd
Hi,
> + /* FIXME: Scale bitmap pixel by pixel is slow */
So how about doing the scaling when loading the font,
so you have to do it only once?
take care,
Gerd
___
Grub-devel mailing list
Grub-devel@gnu.org
rn (2):
> efi: Add efitextmode command for getting/setting the text mode
> resolution
> docs: Add documentation for the efitextmode command
Looks sane to me, works fine on OVMF.
Reviewed-by: Gerd Hoffmann
Tested-by: Gerd Hoffmann
take care,
Gerd
___
On Wed, May 11, 2022 at 11:31:32AM -0400, Chris Murphy wrote:
> Hi,
>
> There's GRUB command "fwsetup" to bring the user from GRUB to the
> firmware's setup menu.
>
> Could there be a command that brings the user to the firmware's
> built-in boot manager? a.k.a. boot order, a.k.a. boot
> > Well, 80x25 is the only text mode which must be supported by the
> > firmware. Supporting larger modes is optional.
> >
> > I think the firmware is also free to choose the default text mode,
> > and the implementations I've seen so far seem to be conservative
> > and use 80x25 or 80x50 by
On Fri, May 06, 2022 at 07:59:15PM -0500, Glenn Washburn wrote:
> Hi Gerd,
>
> Thanks for taking a look at the patch.
>
> On Fri, 6 May 2022 12:39:52 +0200
> Gerd Hoffmann wrote:
>
> > Hi,
> >
> > > On some buggy EFI firmwares, GRUB is sta
Hi,
> v2: Fix to query each mode instead of just the current mode
Oh, right, that is another one ...
> + /* Set text-mode resolution to maximum supported */
> + o = grub_efi_system_table->con_out;
> + for (i=0, columns_max=0, rows_max=0, mode_max=0; i < o->mode->max_mode;
> i++)
> +if
Hi,
> On some buggy EFI firmwares, GRUB is started with the console resolution
> set to the maximum but the output console EFI object has the mode set as
> 0, which is the minimum supported mode of 80x25 characters. This causes
> strange behavior at the GRUB shell where output can fill the
Hi,
> But I am thinking how about align with the definition in UEFI now
> https://github.com/tianocore/edk2/blob/d372ab585a2cdc5348af5f701c56c631235fe698/MdePkg/Include/Protocol/CcMeasurement.h#L100.
It surely makes sense to update the uefi specs too.
> I will talk with UEFI owner to make
On Di, 2017-02-28 at 22:35 +, Leif Lindholm wrote:
> This patch series is really three different ones, but they unite around
> the need for (and the implementation) of more flexible control of memory
> allocation on UEFI systems.
Works fine in my testing, grub loads kernel, initrd, device
16 matches
Mail list logo
