please test patches from Matthias Lange
https://lists.gnu.org/archive/html/grub-devel/2017-02/msg00104.html
On Wed, Mar 1, 2017 at 9:15 AM, Gailu Singh wrote:
> Hi Experts,
>
> I am using GRUB2 on intel apollo lake board. This board does not have IO
> mapped uart instead it has 8250 memory mapp
Yes, Bjørn Forsman intended to work on implementation.
On Wed, Mar 1, 2017 at 9:14 AM, Gailu Singh wrote:
> Hi Experts,
>
> Is there any development on XHCI support on GRUB2? New Intel boards (e.g.
> Apollo Lake) has only XHCI controller so none my USB device (keyboarrd, mass
> storage) works on
Hi Experts,
I am using GRUB2 on intel apollo lake board. This board does not have IO
mapped uart instead it has 8250 memory mapped UART.
GRUB2 does not recognize memory mapped uart and gives error ("serial port
COM0 not found). There is a 8250 memory mapped driver available in
coreboot. Is it pos
Hi Experts,
Is there any development on XHCI support on GRUB2? New Intel boards (e.g.
Apollo Lake) has only XHCI controller so none my USB device (keyboarrd,
mass storage) works on GRUB2 on this board.
If there is any work going on, I can help with testing/development but
don't know where to star
01.03.2017 01:05, Lennart Sorensen пишет:
> On Tue, Feb 28, 2017 at 09:50:27PM +0300, Andrei Borzenkov wrote:
>> 28.02.2017 21:31, Lennart Sorensen пишет:
>>> On Tue, Feb 28, 2017 at 08:13:53PM +0300, Andrei Borzenkov wrote:
Sorry? vda7 is 256M, how can you suddenly pretend it is 2G?
I will review your patches later. There might be some overlap with my "arm"
branch. Can you have a look whether it diverges a lot?
On Tue, Feb 28, 2017, 14:48 Leif Lindholm wrote:
> This patch series is really three different ones, but they unite around
> the need for (and the implementation) of
In order to enable reuse of the arm64 efi linux loader for arm,
change a few function names and macros. Add a global definition
of GRUB_PE32_MAGIC in grub/efi/pe32.h.
Make the arm64 loader 32/64-bit safe.
Also update the arm64 xen loader, since it depends on some of the
functions in the linux loa
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.
1: Adding new interfaces
- A function for detecting the start address of RAM
Since ARM platforms have no standardised memor
Expose a new function, grub_efi_allocate_pages_real(), making it possible
to specify allocation type and memory type as supported by the UEFI
AllocatePages boot service.
Make grub_efi_allocate_pages() a consumer of the new function,
maintaining its old functionality.
Also delete some left-around
The original 32-bit arm EFI Linux loader reused the 32-bit Linux
loader for U-Boot. However, this meant it was acting in an
entirely not UEFI-compliant fashion.
Since EFI stub loader support for arm went into upstream Linux
for 4.5, we can now reuse the same loader as is used on arm64.
This resul
There is nothing ARM64 (or even ARM) specific about the efi fdt
helper library, which is used for locating or overriding a
firmware-provided devicetree in a UEFI system - so move it to
loader/efi for reuse.
Move the fdtload.h include file to grub/efi and move the (at least
theoretically) machine d
With upcoming changes to EDK2, allocations of type EFI_LOADER_DATA may
not return regions with execute ability. Since modules are loaded onto
the heap, change the heap allocation type to GRUB_EFI_LOADER_CODE in
order to permit execution on systems with this feature enabled.
Closes: 50420
Signed-o
The 32-bit arm Linux kernel is built as a zImage, which self-decompresses
down to near start of RAM. In order for an initrd/initramfs to be
accessible, it needs to be placed within the first ~768MB of RAM.
The initrd loader built into the kernel EFI stub restricts this down to
512MB for simplicity
Since ARM platforms do not have a common memory map, add a helper
function that finds the lowest address region with the EFI_MEMORY_WB
attribute set in the UEFI memory map.
Required for the (32-bit) arm linux loader to restrict the initrd
location to where it will be accessible by the kernel at ru
On Tue, Feb 28, 2017 at 09:50:27PM +0300, Andrei Borzenkov wrote:
> 28.02.2017 21:31, Lennart Sorensen пишет:
> > On Tue, Feb 28, 2017 at 08:13:53PM +0300, Andrei Borzenkov wrote:
> >> Sorry? vda7 is 256M, how can you suddenly pretend it is 2G?
> >>
> >> 10:~ # fdisk -l /dev/vda
> >> Disk /dev/vda:
28.02.2017 21:31, Lennart Sorensen пишет:
> On Tue, Feb 28, 2017 at 08:13:53PM +0300, Andrei Borzenkov wrote:
>> Sorry? vda7 is 256M, how can you suddenly pretend it is 2G?
>>
>> 10:~ # fdisk -l /dev/vda
>> Disk /dev/vda: 5 GiB, 5368709120 bytes, 10485760 sectors
>> Units: sectors of 1 * 512 = 512
On Tue, Feb 28, 2017 at 08:13:53PM +0300, Andrei Borzenkov wrote:
> Sorry? vda7 is 256M, how can you suddenly pretend it is 2G?
>
> 10:~ # fdisk -l /dev/vda
> Disk /dev/vda: 5 GiB, 5368709120 bytes, 10485760 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 byte
28.02.2017 17:08, Vladimir 'phcoder' Serbinenko пишет:
>>
>> OK I see, kernel skips BSD partition marked as "unused".
>>
>> So it appears that kernel always puts special nested partitions after
>> normal logical MSDOS partitions, so it will not skew MSDOS partition
>> numbers.
>>
>> [1.529752]
On Mon, Feb 27, 2017, 20:11 Andrei Borzenkov wrote:
> 27.02.2017 21:20, Vladimir 'phcoder' Serbinenko пишет:
> > On Mon, Feb 27, 2017, 09:55 Andrei Borzenkov
> wrote:
> >
> >> 27.02.2017 03:37, Vladimir 'phcoder' Serbinenko пишет:
> >> ...
> >>> This is not NT-style. NT uses partition offset
19 matches
Mail list logo
