From: Bean
Date: Wed, 4 Mar 2009 13:58:50 +0800
> On Wed, Mar 4, 2009 at 10:15 AM, David Miller wrote:
> >
> > We don't have that code model, and such a code model is unnecessary
> > on sparc64.
>
> Hi,
>
> Oh, thanks for pointing out. In fact, mcmodel=large is only needed in
> x86_64-efi. I m
On Wed, Mar 4, 2009 at 1:50 AM, Pavel Roskin wrote:
> Hello!
>
> Could somebody please fix the first line in commands/handler.c?
> Currently, it says:
>
> /* handler.c - test module for dynamic loading */
>
> That's a copy from hello/hello.c. I'm thinking of something like:
>
> /* handler.c - com
On Wed, Mar 4, 2009 at 10:15 AM, David Miller wrote:
>
> We don't have that code model, and such a code model is unnecessary
> on sparc64.
Hi,
Oh, thanks for pointing out. In fact, mcmodel=large is only needed in
x86_64-efi. I move the test to its own section, it would not interfere
with sparc64
phcoder wrote:
[...]
> 4) "This tag should contain a string that enables operating systems to
> distinguish between different bootloaders and different versions of the
> same bootloader."
> Parsing strings may be difficult. Perhaps we could include a version tag
> with a format dependent on bootl
Hi,
Currently, there is no mechanism to support running command at a
specific event, such as, whenever a menu is selected, this makes it
difficult to implement functions like savedefault or password. I
sugguest the following model.
First, UI components register events, which is a subclass of name
Again looking at the script parser, I notices that it uses a
Yacc-generated parser, but a hand-written tokenizer. Is there a reason
that it doesn't use Lex? Is it due to external dependencies, and if so,
is there a way to recreate these deps (library or whatever) within the
constraints of the boot
This replaces the C implementation with a proper assembler
one. Also add missing grub_prefix[] declaration to
kernel.h
2009-03-03 David S. Miller
* kern/sparc64/ieee1275/init.c: Delete, replace with...
* kern/sparc64/ieee1275/crt0.S: assembler implementation.
* includ
This corrects the sparc64 setjmp implementation.
We need to store the return address register, the
stack pointer, and frame pointer into the jump buf.
And on longjmp we need restore those registers, flush the register
window state, and pull in the top-most register window.
2009-03-03 David S.
The sparc64 cache flush implementation was wrong in so many
ways.
When you "save" you have to allocate at least a full register
save area, which would be 128 bytes on sparc64. But we
actually don't need a register window here, this is a leaf
function and there are enough global and out registers
We don't have that code model, and such a code model is unnecessary
on sparc64.
2009-03-03 David S. Miller
* configure.ac: Don't try to use -mcmodel=large on sparc.
* configure: Rebuilt.
---
configure|9 -
configure.ac |9 -
2 files changed, 16 ins
2009-03-03 David S. Miller
* include/grub/sparc64/ieee1275/loader.h: New file.
* include/grub/sparc64/ieee1275/memory.h: Likewise.
* include/grub/sparc64/kernel.h: Likewise.
* loader/sparc64/ieee1275/linux.c: Likewise.
* loader/sparc64/ieee1275/linux_nor
This isn't %100 correct, but it gets the tree building.
2009-03-03 David S. Miller
* loader/ieee1275/multiboot2.c (grub_mb2_arch_boot): Handle
sparc like powerpc.
---
loader/ieee1275/multiboot2.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/loader/ieee1275/
Here is a series of patches that fix the most obvious sparc bugs and
get the grub2 tree building again.
I have code for boot/ that will implement the sparc boot blocks and
things of that nature, but that will come later.
First things first, let's get it to actually build. :)
__
Marco Gerards wrote:
> Hi,
>
> Kevin Lacquement writes:
[...]
>>
>> It seems to me that a menu entry is nothing more than a function that,
>> instead of being referred to by a function name, is referred to by a
>> menu title.
>
> This was on purpose. My idea was that menu entries can be gene
Hello. Here is a zeroth draft of SoC proposal:
Complete TCP/IP stack
GRUB Legacy supported tftp. This is a basic protocal specially adapted
for netbooting. However we feel that grub2 can be much more flexible if
it supports other widely-used protocols like ftp, http, smb, nfs and
dns. The commo
Hi,
I've just tried installing debian lenny on Raid1 with Grub2 for boot.
The disks are raided using the command to create the raid:
mdadm -C /dev/md/d0 -ap2 -l1 /dev/sda /dev/sdb
I've tried both the lenny v1.96+20080724-16 and experimental v196
+20081201-1 on x86
I can't get grub-install to wo
Hi,
Kevin Lacquement writes:
> I was browsing through the recent SVN head, and noticed that functions
> and menu items are implemented separately. I was wondering if there's
> actually a reason for that.
>
> It seems to me that a menu entry is nothing more than a function that,
> instead of bei
Correction: Third point goes away as it was revealed that it was enough
to put these 2 structures in multiboot payload. Now fixed solaris kernel
boots fine with latest svn+my elf fix. And the first two points are
solaris bugs
phcoder wrote:
My previous letter was scarce on details. Here some m
My previous letter was scarce on details. Here some more comments:
grub1 and grub2 if they detect an elf executable with AOUT_KLUDGE bit
set they follow the specification and load the file using addresses from
multiboot header. grub-solaris however in the same case uses elf
headers. This error
Hello!
Could somebody please fix the first line in commands/handler.c?
Currently, it says:
/* handler.c - test module for dynamic loading */
That's a copy from hello/hello.c. I'm thinking of something like:
/* handler.c - commands to list or select handlers */
--
Regards,
Pavel Roskin
configured with --enable-grub-emu.
/home/Aleax/project/grub/grub2/commands/handler.c:46: undefined reference to
`grub_handler_class_list'
/home/Aleax/project/grub/grub2/commands/handler.c:62: undefined reference to
`grub_named_list_find'
/home/Aleax/project/grub/grub2/commands/handler.c:76: undefi
Hello I was looking into multiboot2 specifications and have some
suggestions:
1) double the size of flags. 8 features per category seems to be few. it
could even be made completely expandable by the following format:
...
2) "All undefined flags *should* be set to zero for future use. "
IMO
Hello, investigating Solaris/OpenSolaris/Pulsar kernel I found that it
makes assumptions which are false in grub2 environment. Now we should
decide what to do. Assumptions:
1) Bad multiboot header. AOUT_KLUDGE bit is set but no aout multiboot
fields. Actually the image is elf. I fixed it by just
On Tue, Mar 3, 2009 at 10:51 PM, phcoder wrote:
> Hello
> Have you tried -mno-red-zone? Here is an extract from man gcc:
> -mno-red-zone
> Do not use a so called red zone for x86-64 code. The red zone is
> mandated by the x86-64 ABI, it is a 128-byte area beyond the
>
Hi, all.
in the function grub_fs_probe, there something i can't understand.
the environment i'm on is :
a bootable image create by grub-mkrescue, boot with bochs. so in the grub's
view, there are two devieces, fd0 and memdisk.
fd0 with no filesystemm, memdisk with a tarfs filesystem.
i have set th
Robert Millan wrote:
> It's funny, we're all discussing about performing security measurements in
> GRUB and nobody mentioned that our user interface lacks even the most basic
> lock mechanism :-)
>
> Perhaps this would be a good time to retake the discussion on implementing
> an equivalent to "lo
Hello
Have you tried -mno-red-zone? Here is an extract from man gcc:
-mno-red-zone
Do not use a so called red zone for x86-64 code. The red
zone is
mandated by the x86-64 ABI, it is a 128-byte area beyond the
location of the stack pointer that will not be
Hi,
I've found a serious stack issue when debugging EFI amd64 port. The
problem is in grub_parser_cmdline_state, the c code is all right,
problem is in the assembly code generated by gcc:
grub_parser_cmdline_state:
mov%edi,-0x14(%rsp)
movl $0x1,-0xc(%rsp)
leaqEXT
28 matches
Mail list logo
