[PATCH] arm64: Fix the bug in fdt module
From: Fu Wei
This patch goes with commit:
4d0cb755387d6f109b901386ed4d3d475df239fe
arm64: Move FDT functions to separate module
linux and xen_boot modules can't work without this patch.
Signed-off-by: Fu Wei
---
grub-core/Makefile.core.def | 1 +
grub-core/loader/arm64/fdt.c | 5 +
2 files changed, 6 insertions(+)
diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
index 2ef10d1..3ea4e49 100644
--- a/grub-core/Makefile.core.def
+++ b/grub-core/Makefile.core.def
@@ -1674,6 +1674,7 @@ module = {
module = {
name = fdt;
arm64 = loader/arm64/fdt.c;
+ fdt = lib/fdt.c;
enable = arm64;
};
diff --git a/grub-core/loader/arm64/fdt.c b/grub-core/loader/arm64/fdt.c
index 5202c14..d160ca0 100644
--- a/grub-core/loader/arm64/fdt.c
+++ b/grub-core/loader/arm64/fdt.c
@@ -25,6 +25,10 @@
#include
#include
+GRUB_MOD_LICENSE ("GPLv3+");
+
+static grub_dl_t my_mod;
+
static void *loaded_fdt;
static void *fdt;
@@ -177,6 +181,7 @@ GRUB_MOD_INIT (fdt)
cmd_devicetree =
grub_register_command ("devicetree", grub_cmd_devicetree, 0,
N_("Load DTB file."));
+ my_mod = mod;
}
GRUB_MOD_FINI (fdt)
--
2.4.3
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v3 2/4] arm64: Add xen_boot module file
Hi Vladimir,
After discussing with Ian Campbell, Since we already can load all
the necessary binaries for Xen boot on arm64 for now, we don't really
need "xen_module" command now.
But maybe someday , xen need a new type of binary in boot time, then
we still need this support.
So I will submit a "xen_module" command patch soon, in case we need it.
Great thanks ! :-)
On 30 October 2015 at 16:08, Fu Wei wrote:
> Hi Vladimir,
>
> yes, Thanks for your modification :-)
>
> I just follow the xen boot protocol :
> http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Multiboot
>
> xen_module is just for "--type" option, I will discuss this with Xen
> developer for this.
> If we need this option, I will resubmit it :-)
>
> Great thanks!
>
> On 29 October 2015 at 22:27, Vladimir 'φ-coder/phcoder' Serbinenko
> wrote:
>> Committed without the xen_module command. Its argument parsing was
>> non-trivial and I don't quite get what its intent is. Can you resubmit?
>> On 23.07.2015 07:16, fu@linaro.org wrote:
>>> From: Fu Wei
>>>
>>> grub-core/loader/arm64/xen_boot.c
>>>
>>> - This adds support for the Xen boot on ARM specification for arm64.
>>> - Introduce xen_hypervisor, xen_linux, xen_initrd and xen_xsm
>>> to load different binaries for xen boot;
>>> Introduce xen_module to load common or custom module for xen boot.
>>> - This Xen boot support is a separated module for aarch64,
>>> but reuse the existing code of devicetree in linux module.
>>>
>>> Signed-off-by: Fu Wei
>>> ---
>>> grub-core/Makefile.core.def | 7 +
>>> grub-core/loader/arm64/xen_boot.c | 685
>>> ++
>>> 2 files changed, 692 insertions(+)
>>>
>>> diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
>>> index a6101de..796f7e9 100644
>>> --- a/grub-core/Makefile.core.def
>>> +++ b/grub-core/Makefile.core.def
>>> @@ -1648,6 +1648,13 @@ module = {
>>> };
>>>
>>> module = {
>>> + name = xen_boot;
>>> + common = lib/cmdline.c;
>>> + arm64 = loader/arm64/xen_boot.c;
>>> + enable = arm64;
>>> +};
>>> +
>>> +module = {
>>>name = linux;
>>>x86 = loader/i386/linux.c;
>>>xen = loader/i386/xen.c;
>>> diff --git a/grub-core/loader/arm64/xen_boot.c
>>> b/grub-core/loader/arm64/xen_boot.c
>>> new file mode 100644
>>> index 000..33a65dd
>>> --- /dev/null
>>> +++ b/grub-core/loader/arm64/xen_boot.c
>>> @@ -0,0 +1,685 @@
>>> +/*
>>> + * GRUB -- GRand Unified Bootloader
>>> + * Copyright (C) 2014 Free Software Foundation, Inc.
>>> + *
>>> + * GRUB is free software: you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License as published by
>>> + * the Free Software Foundation, either version 3 of the License, or
>>> + * (at your option) any later version.
>>> + *
>>> + * GRUB is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>> + * GNU General Public License for more details.
>>> + *
>>> + * You should have received a copy of the GNU General Public License
>>> + * along with GRUB. If not, see
Re: [PATCH v3 2/4] arm64: Add xen_boot module file
On Tue, 2015-11-03 at 22:57 +0800, Fu Wei wrote: > Hi Vladimir, > > After discussing with Ian Campbell, Since we already can load all > the necessary binaries for Xen boot on arm64 for now, we don't really > need "xen_module" command now. > But maybe someday , xen need a new type of binary in boot time, then > we still need this support. You mean support for "--type" passed to the xen_module command, right? I thought the xen_module stuff had been applied. Or am I misunderstanding which bits have been applied? > So I will submit a "xen_module" command patch soon, in case we need > it. Just to clarify, my suggestion was to repost the bits which were omitted from the prior patches just so that they are available in the ML archives etc should anyone ever want to resurrect them in the future. Ian. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Dell Dimension 8300 reboots when grub2 cbfs module is loaded
The code itself looks good but I'd like more details. Reading 0x
shouldn't cause reboot. Why does it?
Le 1 nov. 2015 3:53 PM, "Andrei Borzenkov" a écrit :
> I was debugging problem reported by user on Dell Dimension 8300 - it
> rebooted when doing "ls -l". It turned out, the problem was triggered by
> loading cbfs which probed for header. System has 2GB memory, and attempt to
> read from address 0x caused instant reboot. 0x was returned
> by read from non-existing address 0xfffc.
>
> The proof of concept patch below avoids it, but I wonder what the proper
> fix is.
>
> diff --git a/grub-core/fs/cbfs.c b/grub-core/fs/cbfs.c
> index a34eb88..a5a2fde 100644
> --- a/grub-core/fs/cbfs.c
> +++ b/grub-core/fs/cbfs.c
> @@ -344,8 +344,9 @@ init_cbfsdisk (void)
>
>ptr = *(grub_uint32_t *) 0xfffc;
>head = (struct cbfs_header *) (grub_addr_t) ptr;
> + grub_dprintf ("cbfs", "head=%p\n", head);
>
> - if (!validate_head (head))
> + if (0x - ptr < sizeof (*head) || !validate_head (head))
> return;
>
>cbfsdisk_size = ALIGN_UP (grub_be_to_cpu32 (head->romsize),
>
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Dell Dimension 8300 reboots when grub2 cbfs module is loaded
03.11.2015 19:28, Vladimir 'phcoder' Serbinenko пишет:
The code itself looks good but I'd like more details. Reading 0x
shouldn't cause reboot. Why does it?
That I do not know nor do I have access to system in question myself. I
sent user patch that modified validate_header to do each comparison as
individual statement and did line by line debug print (fortunately it
was possible to connect serial port and capture output) and the last
line printed was immediately before the very first
head->magic == grub_cpu_to_be32_compile_time (CBFS_HEADER_MAGIC
I suppose reading *one* byte from 0x should not cause issues but
here we are reading 4 bytes which are beyond 0x. Who knows what
memory controller in this system does in this case.
Le 1 nov. 2015 3:53 PM, "Andrei Borzenkov" a écrit :
I was debugging problem reported by user on Dell Dimension 8300 - it
rebooted when doing "ls -l". It turned out, the problem was triggered by
loading cbfs which probed for header. System has 2GB memory, and attempt to
read from address 0x caused instant reboot. 0x was returned
by read from non-existing address 0xfffc.
The proof of concept patch below avoids it, but I wonder what the proper
fix is.
diff --git a/grub-core/fs/cbfs.c b/grub-core/fs/cbfs.c
index a34eb88..a5a2fde 100644
--- a/grub-core/fs/cbfs.c
+++ b/grub-core/fs/cbfs.c
@@ -344,8 +344,9 @@ init_cbfsdisk (void)
ptr = *(grub_uint32_t *) 0xfffc;
head = (struct cbfs_header *) (grub_addr_t) ptr;
+ grub_dprintf ("cbfs", "head=%p\n", head);
- if (!validate_head (head))
+ if (0x - ptr < sizeof (*head) || !validate_head (head))
return;
cbfsdisk_size = ALIGN_UP (grub_be_to_cpu32 (head->romsize),
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Dell Dimension 8300 reboots when grub2 cbfs module is loaded
Which platform is it? i386-pc, i386-efi or x86_64-efi? The behavior is
actually will defined, just different between cpu modes
Le 3 nov. 2015 6:08 PM, "Andrei Borzenkov" a écrit :
> 03.11.2015 19:28, Vladimir 'phcoder' Serbinenko пишет:
>
>> The code itself looks good but I'd like more details. Reading 0x
>> shouldn't cause reboot. Why does it?
>>
>
> That I do not know nor do I have access to system in question myself. I
> sent user patch that modified validate_header to do each comparison as
> individual statement and did line by line debug print (fortunately it was
> possible to connect serial port and capture output) and the last line
> printed was immediately before the very first
>
> head->magic == grub_cpu_to_be32_compile_time (CBFS_HEADER_MAGIC
>
> I suppose reading *one* byte from 0x should not cause issues but
> here we are reading 4 bytes which are beyond 0x. Who knows what
> memory controller in this system does in this case.
>
> Le 1 nov. 2015 3:53 PM, "Andrei Borzenkov" a écrit :
>>
>> I was debugging problem reported by user on Dell Dimension 8300 - it
>>> rebooted when doing "ls -l". It turned out, the problem was triggered by
>>> loading cbfs which probed for header. System has 2GB memory, and attempt
>>> to
>>> read from address 0x caused instant reboot. 0x was
>>> returned
>>> by read from non-existing address 0xfffc.
>>>
>>> The proof of concept patch below avoids it, but I wonder what the proper
>>> fix is.
>>>
>>> diff --git a/grub-core/fs/cbfs.c b/grub-core/fs/cbfs.c
>>> index a34eb88..a5a2fde 100644
>>> --- a/grub-core/fs/cbfs.c
>>> +++ b/grub-core/fs/cbfs.c
>>> @@ -344,8 +344,9 @@ init_cbfsdisk (void)
>>>
>>> ptr = *(grub_uint32_t *) 0xfffc;
>>> head = (struct cbfs_header *) (grub_addr_t) ptr;
>>> + grub_dprintf ("cbfs", "head=%p\n", head);
>>>
>>> - if (!validate_head (head))
>>> + if (0x - ptr < sizeof (*head) || !validate_head (head))
>>> return;
>>>
>>> cbfsdisk_size = ALIGN_UP (grub_be_to_cpu32 (head->romsize),
>>>
>>>
>>> ___
>>> Grub-devel mailing list
>>> Grub-devel@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/grub-devel
>>>
>>>
>>
>>
>> ___
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> https://lists.gnu.org/mailman/listinfo/grub-devel
>>
>>
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Dell Dimension 8300 reboots when grub2 cbfs module is loaded
03.11.2015 20:10, Vladimir 'phcoder' Serbinenko пишет:
Which platform is it? i386-pc, i386-efi or x86_64-efi? The behavior is
actually will defined, just different between cpu modes
i386-pc
Le 3 nov. 2015 6:08 PM, "Andrei Borzenkov" a écrit :
03.11.2015 19:28, Vladimir 'phcoder' Serbinenko пишет:
The code itself looks good but I'd like more details. Reading 0x
shouldn't cause reboot. Why does it?
That I do not know nor do I have access to system in question myself. I
sent user patch that modified validate_header to do each comparison as
individual statement and did line by line debug print (fortunately it was
possible to connect serial port and capture output) and the last line
printed was immediately before the very first
head->magic == grub_cpu_to_be32_compile_time (CBFS_HEADER_MAGIC
I suppose reading *one* byte from 0x should not cause issues but
here we are reading 4 bytes which are beyond 0x. Who knows what
memory controller in this system does in this case.
Le 1 nov. 2015 3:53 PM, "Andrei Borzenkov" a écrit :
I was debugging problem reported by user on Dell Dimension 8300 - it
rebooted when doing "ls -l". It turned out, the problem was triggered by
loading cbfs which probed for header. System has 2GB memory, and attempt
to
read from address 0x caused instant reboot. 0x was
returned
by read from non-existing address 0xfffc.
The proof of concept patch below avoids it, but I wonder what the proper
fix is.
diff --git a/grub-core/fs/cbfs.c b/grub-core/fs/cbfs.c
index a34eb88..a5a2fde 100644
--- a/grub-core/fs/cbfs.c
+++ b/grub-core/fs/cbfs.c
@@ -344,8 +344,9 @@ init_cbfsdisk (void)
ptr = *(grub_uint32_t *) 0xfffc;
head = (struct cbfs_header *) (grub_addr_t) ptr;
+ grub_dprintf ("cbfs", "head=%p\n", head);
- if (!validate_head (head))
+ if (0x - ptr < sizeof (*head) || !validate_head (head))
return;
cbfsdisk_size = ALIGN_UP (grub_be_to_cpu32 (head->romsize),
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Dell Dimension 8300 reboots when grub2 cbfs module is loaded
03.11.2015 20:14, Andrei Borzenkov пишет:
03.11.2015 20:10, Vladimir 'phcoder' Serbinenko пишет:
Which platform is it? i386-pc, i386-efi or x86_64-efi? The behavior is
actually will defined, just different between cpu modes
i386-pc
BTW here are specs from Dell site
Intel® Pentium® 4 microprocessor (2.4, 2.6, 2.8, 3.0,
3.2, and 3.4 for 800 FSB, and 2.4, 2.66, 2.8, and 3.06
for 533 FSB)
4GB max memory
Intel 875P chipset
Le 3 nov. 2015 6:08 PM, "Andrei Borzenkov" a
écrit :
03.11.2015 19:28, Vladimir 'phcoder' Serbinenko пишет:
The code itself looks good but I'd like more details. Reading
0x
shouldn't cause reboot. Why does it?
That I do not know nor do I have access to system in question myself. I
sent user patch that modified validate_header to do each comparison as
individual statement and did line by line debug print (fortunately it
was
possible to connect serial port and capture output) and the last line
printed was immediately before the very first
head->magic == grub_cpu_to_be32_compile_time (CBFS_HEADER_MAGIC
I suppose reading *one* byte from 0x should not cause issues but
here we are reading 4 bytes which are beyond 0x. Who knows what
memory controller in this system does in this case.
Le 1 nov. 2015 3:53 PM, "Andrei Borzenkov" a
écrit :
I was debugging problem reported by user on Dell Dimension 8300 - it
rebooted when doing "ls -l". It turned out, the problem was
triggered by
loading cbfs which probed for header. System has 2GB memory, and
attempt
to
read from address 0x caused instant reboot. 0x was
returned
by read from non-existing address 0xfffc.
The proof of concept patch below avoids it, but I wonder what the
proper
fix is.
diff --git a/grub-core/fs/cbfs.c b/grub-core/fs/cbfs.c
index a34eb88..a5a2fde 100644
--- a/grub-core/fs/cbfs.c
+++ b/grub-core/fs/cbfs.c
@@ -344,8 +344,9 @@ init_cbfsdisk (void)
ptr = *(grub_uint32_t *) 0xfffc;
head = (struct cbfs_header *) (grub_addr_t) ptr;
+ grub_dprintf ("cbfs", "head=%p\n", head);
- if (!validate_head (head))
+ if (0x - ptr < sizeof (*head) || !validate_head (head))
return;
cbfsdisk_size = ALIGN_UP (grub_be_to_cpu32 (head->romsize),
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [coreboot] Dell Dimension 8300 reboots when grub2 cbfs module is loaded
Thanks Andrei,
Vladimir, what do you think?
Martin
On Sun, Nov 1, 2015 at 7:53 AM, Andrei Borzenkov wrote:
> I was debugging problem reported by user on Dell Dimension 8300 - it
> rebooted when doing "ls -l". It turned out, the problem was triggered by
> loading cbfs which probed for header. System has 2GB memory, and attempt to
> read from address 0x caused instant reboot. 0x was returned
> by read from non-existing address 0xfffc.
>
> The proof of concept patch below avoids it, but I wonder what the proper fix
> is.
>
> diff --git a/grub-core/fs/cbfs.c b/grub-core/fs/cbfs.c
> index a34eb88..a5a2fde 100644
> --- a/grub-core/fs/cbfs.c
> +++ b/grub-core/fs/cbfs.c
> @@ -344,8 +344,9 @@ init_cbfsdisk (void)
>
>ptr = *(grub_uint32_t *) 0xfffc;
>head = (struct cbfs_header *) (grub_addr_t) ptr;
> + grub_dprintf ("cbfs", "head=%p\n", head);
>
> - if (!validate_head (head))
> + if (0x - ptr < sizeof (*head) || !validate_head (head))
> return;
>
>cbfsdisk_size = ALIGN_UP (grub_be_to_cpu32 (head->romsize),
>
>
> --
> coreboot mailing list: coreb...@coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [coreboot] Dell Dimension 8300 reboots when grub2 cbfs module is loaded
Le 3 nov. 2015 6:46 PM, "Aaron Durbin" a écrit :
>
> On Tue, Nov 3, 2015 at 10:28 AM, Vladimir 'phcoder' Serbinenko
> wrote:
> > The code itself looks good but I'd like more details. Reading 0x
> > shouldn't cause reboot. Why does it?
>
> It's probably implementation defined reading a multi-byte object from
> 4GiB-1. Does it wrap? Blow up the machine? Machine check? Transaction
> never gets terminated?
>
It would be interesting to find out. Since it's P4, it may be related to
PAE but paging is disabled when GRUB is active However it shouldn't hold
this patch. Andrei: go ahead, just please add reference to machine and cpu
in the comment and the fact that we have little idea what's going on.
> >
> > Le 1 nov. 2015 3:53 PM, "Andrei Borzenkov" a
écrit :
> >>
> >> I was debugging problem reported by user on Dell Dimension 8300 - it
> >> rebooted when doing "ls -l". It turned out, the problem was triggered
by
> >> loading cbfs which probed for header. System has 2GB memory, and
attempt to
> >> read from address 0x caused instant reboot. 0x was
returned
> >> by read from non-existing address 0xfffc.
> >>
> >> The proof of concept patch below avoids it, but I wonder what the
proper
> >> fix is.
> >>
> >> diff --git a/grub-core/fs/cbfs.c b/grub-core/fs/cbfs.c
> >> index a34eb88..a5a2fde 100644
> >> --- a/grub-core/fs/cbfs.c
> >> +++ b/grub-core/fs/cbfs.c
> >> @@ -344,8 +344,9 @@ init_cbfsdisk (void)
> >>
> >>ptr = *(grub_uint32_t *) 0xfffc;
> >>head = (struct cbfs_header *) (grub_addr_t) ptr;
> >> + grub_dprintf ("cbfs", "head=%p\n", head);
> >>
> >> - if (!validate_head (head))
> >> + if (0x - ptr < sizeof (*head) || !validate_head (head))
> >> return;
> >>
> >>cbfsdisk_size = ALIGN_UP (grub_be_to_cpu32 (head->romsize),
> >>
> >>
> >> ___
> >> Grub-devel mailing list
> >> Grub-devel@gnu.org
> >> https://lists.gnu.org/mailman/listinfo/grub-devel
> >
> >
> > --
> > coreboot mailing list: coreb...@coreboot.org
> > http://www.coreboot.org/mailman/listinfo/coreboot
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [coreboot] Dell Dimension 8300 reboots when grub2 cbfs module is loaded
On Tue, Nov 3, 2015 at 10:28 AM, Vladimir 'phcoder' Serbinenko
wrote:
> The code itself looks good but I'd like more details. Reading 0x
> shouldn't cause reboot. Why does it?
It's probably implementation defined reading a multi-byte object from
4GiB-1. Does it wrap? Blow up the machine? Machine check? Transaction
never gets terminated?
>
> Le 1 nov. 2015 3:53 PM, "Andrei Borzenkov" a écrit :
>>
>> I was debugging problem reported by user on Dell Dimension 8300 - it
>> rebooted when doing "ls -l". It turned out, the problem was triggered by
>> loading cbfs which probed for header. System has 2GB memory, and attempt to
>> read from address 0x caused instant reboot. 0x was returned
>> by read from non-existing address 0xfffc.
>>
>> The proof of concept patch below avoids it, but I wonder what the proper
>> fix is.
>>
>> diff --git a/grub-core/fs/cbfs.c b/grub-core/fs/cbfs.c
>> index a34eb88..a5a2fde 100644
>> --- a/grub-core/fs/cbfs.c
>> +++ b/grub-core/fs/cbfs.c
>> @@ -344,8 +344,9 @@ init_cbfsdisk (void)
>>
>>ptr = *(grub_uint32_t *) 0xfffc;
>>head = (struct cbfs_header *) (grub_addr_t) ptr;
>> + grub_dprintf ("cbfs", "head=%p\n", head);
>>
>> - if (!validate_head (head))
>> + if (0x - ptr < sizeof (*head) || !validate_head (head))
>> return;
>>
>>cbfsdisk_size = ALIGN_UP (grub_be_to_cpu32 (head->romsize),
>>
>>
>> ___
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> https://lists.gnu.org/mailman/listinfo/grub-devel
>
>
> --
> coreboot mailing list: coreb...@coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: C.UTF-8 may not be present resulting in failed build
Le 2 nov. 2015 7:48 PM, "Andrei Borzenkov" a écrit : > > Extra catalogs added in da0d5b3f explicitly require C.UTF-8 locale. This locale may not be present (e.g. openSUSE does not have it). > > Upstream gettext (and hence en@quot rules) does not use it. Is forcing this locale really needed? > > We use them in tests as an easy alternative to real translations. But we can generate them without this locale. We could replace y sed command with bunch of s and use pain C locale ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Grub get and set efi variables
Hi, Searching through google, I see there was an email thread to add a patch for getting and setting efi variable in GRUB2. https://lists.gnu.org/archive/html/grub-devel/2013-11/msg00328.html However, looking at the tree, it doesn't look like this patch was added, am I missing something? Does anyone know if we have command to get/set efi variables in GRUB2? http://git.savannah.gnu.org/gitweb/?p=grub.git;a=tree;f=grub-core/commands/efi;h=005fd2efc9a2eede2a1eb1cab8081c360219107b;hb=HEAD Thanks, Mat ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Grub get and set efi variables
On Tuesday, November 3, 2015, Mat Troi wrote: > Hi, > > Searching through google, I see there was an email thread to add a patch > for getting and setting efi variable in GRUB2. > https://lists.gnu.org/archive/html/grub-devel/2013-11/msg00328.html > > However, looking at the tree, it doesn't look like this patch was added, > am I missing something? Does anyone know if we have command to get/set efi > variables in GRUB2? > > > http://git.savannah.gnu.org/gitweb/?p=grub.git;a=tree;f=grub-core/commands/efi;h=005fd2efc9a2eede2a1eb1cab8081c360219107b;hb=HEAD > > I'm the author of that patch. No, it was never merged into the tree. As far as I know, there is no equivalent functionality; GRUB does not support this feature. > Thanks, > Mat > ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [coreboot] Dell Dimension 8300 reboots when grub2 cbfs module is loaded
Hi Andrei,
your patch looks good generally, but the check is off by one. It's
obvious, we want to have sane checking there. Reading from a random
address can cause trouble and 0x is not the only offending
address.
On x86, the cbfs is mapped right below the 4GiB line. Current machines
don't have more than 16MiB space for cbfs, FWIW. So maybe it's best to
check if the ptr points somewhere between 0xff00 and (0x1 -
sizeof(*head)).
Nico
On 01.11.2015 15:53, Andrei Borzenkov wrote:
> I was debugging problem reported by user on Dell Dimension 8300 - it
> rebooted when doing "ls -l". It turned out, the problem was triggered by
> loading cbfs which probed for header. System has 2GB memory, and attempt
> to read from address 0x caused instant reboot. 0x was
> returned by read from non-existing address 0xfffc.
>
> The proof of concept patch below avoids it, but I wonder what the proper
> fix is.
>
> diff --git a/grub-core/fs/cbfs.c b/grub-core/fs/cbfs.c
> index a34eb88..a5a2fde 100644
> --- a/grub-core/fs/cbfs.c
> +++ b/grub-core/fs/cbfs.c
> @@ -344,8 +344,9 @@ init_cbfsdisk (void)
>
>ptr = *(grub_uint32_t *) 0xfffc;
>head = (struct cbfs_header *) (grub_addr_t) ptr;
> + grub_dprintf ("cbfs", "head=%p\n", head);
>
> - if (!validate_head (head))
> + if (0x - ptr < sizeof (*head) || !validate_head (head))
> return;
>
>cbfsdisk_size = ALIGN_UP (grub_be_to_cpu32 (head->romsize),
>
>
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Grub get and set efi variables
Hi SevenBits, Thanks for letting me know. Out of curiosity, any particular reason why this patch did not get merged? It looks to be a useful feature. Thanks, Mat On Tue, Nov 3, 2015 at 12:12 PM, SevenBits wrote: > On Tuesday, November 3, 2015, Mat Troi wrote: > >> Hi, >> >> Searching through google, I see there was an email thread to add a patch >> for getting and setting efi variable in GRUB2. >> https://lists.gnu.org/archive/html/grub-devel/2013-11/msg00328.html >> >> However, looking at the tree, it doesn't look like this patch was added, >> am I missing something? Does anyone know if we have command to get/set efi >> variables in GRUB2? >> >> >> http://git.savannah.gnu.org/gitweb/?p=grub.git;a=tree;f=grub-core/commands/efi;h=005fd2efc9a2eede2a1eb1cab8081c360219107b;hb=HEAD >> >> > I'm the author of that patch. No, it was never merged into the tree. As > far as I know, there is no equivalent functionality; GRUB does not support > this feature. > > >> Thanks, >> Mat >> > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel > > ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Grub get and set efi variables
04.11.2015 02:05, Mat Troi пишет: Hi SevenBits, Thanks for letting me know. Out of curiosity, any particular reason why this patch did not get merged? It looks to be a useful feature. First, this patch was reverse patch :) I am not convinced making it easy to set EFI variable from within GRUB is good thing, because there are known reports about systems rendered unbootable by writing too much into EFI flash. What is your use case that absolutely requires setting EFI variables? How are you going to implement it on other platforms? Reading does not harm and may be useful, but then it should provide generic interface to access arbitrary vendor namespace, not only EFI global variables, and handle arbitrary binary data, even if initial implementation handles only subset of them. Once someone starts to use it changing it will be much more difficult. May be it should take hints how to interpret variable values, or have format option akin to printf. Thanks, Mat On Tue, Nov 3, 2015 at 12:12 PM, SevenBits wrote: On Tuesday, November 3, 2015, Mat Troi wrote: Hi, Searching through google, I see there was an email thread to add a patch for getting and setting efi variable in GRUB2. https://lists.gnu.org/archive/html/grub-devel/2013-11/msg00328.html However, looking at the tree, it doesn't look like this patch was added, am I missing something? Does anyone know if we have command to get/set efi variables in GRUB2? http://git.savannah.gnu.org/gitweb/?p=grub.git;a=tree;f=grub-core/commands/efi;h=005fd2efc9a2eede2a1eb1cab8081c360219107b;hb=HEAD I'm the author of that patch. No, it was never merged into the tree. As far as I know, there is no equivalent functionality; GRUB does not support this feature. Thanks, Mat ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
