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 fi
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
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 b
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 t
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
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. R
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
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 microp
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. Sy
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 mul
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?
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
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 an
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
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'
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 throug
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 G
17 matches
Mail list logo