Well, the mbi struct could have had a firmware type and firmware
context pointer defined or something of the sort. This would also play
nice with Multiboot on OF environments, without resorting to ugly
hacks like always passing the OF entry in a GPR on entry.
18.06.2008, в 1:27, Bean напис
Exactly on target. Then we need a more robust and permanent
solution I think right?
How about asking with 0 sized buffer first knowing it will fail then
asking with a rounded-up buffer the 2nd time.
I can coded it, but I can't check it in of course.
http://www.uefi.org/specs/
You sho
Straight from the public UEFI docs:
If the MemoryMap buffer is too small, the EFI_BUFFER_TOO_SMALL error
code is returned and
the MemoryMapSize value contains the size of the buffer needed to
contain the current
memory map. The actual size of the buffer allocated for the consequent
call to
My understanding, as a user of GRUB, was that GRUB relied on the
system BIOS to perform any disk I/O, thunk to RM to invoke INT 0x13
for all disk accesses.
Is the disk controller visible for the system BIOS? Can you boot off
of it? Is there a bios disk number assigned to it? Does it play n
I think the actual question should have been worded more like
"is it possible to return control to GRUB from a booted (say)
Multiboot kernel, provided nothing (say) below 1MB is touched...".
Is it possible? I'm curious myself.
Andrei Evgenievich Warkentin
[EMAIL PROTECTED]
Cell: (+1)
Juan,
You may use the CPUID instruction to correctly identify the processor
your code is executing on. GRUB does not provide such information as
part of the Multiboot info.
Andrei Evgenievich Warkentin
[EMAIL PROTECTED]
Cell: (+1) (847) 321-15-55
29.10.2007, в 12:00, Juan_2007 писал(а):
Fair enough. Your original response seemed a tad knee-jerk ;-)
Andrei Evgenievich Warkentin
[EMAIL PROTECTED]
Cell: (+1) (847) 321-15-55
23.10.2007, в 15:50, Robert Millan писал(а):
And to clarify a bit more, I don't have anything against local
security
checks that are controlled by the ow
[1] Well, assuming our hypervirus is not dumb, they would just see
that
your computer lacks a Treacherous Chip or is not using it,
which is
not very useful. But of course, this has an easy solution:
- Premise: everyone who's not on TC is therefore running an
hypervirus
- Co
...Because having the ability, to be certain you didn't have a
hypervirus or at runtime-binary-patched kernel booted due to a hacked
bootloader loading from something like a USB stick, is one step
towards "treacherous computing", whatever that is.
I think the SELinux people might object to
12.10.2007, в 11:19, Robert Millan писал(а):
It seems that grub-mkimage generates awkward ELF files, in which
the Program
header table is at the end of the file instead of right after the
ELF header.
I know very little about ELF, but:
- This figure in ELF standard seems to indicate whi
I wouldn't go as far as saying it is overly complex. If all you want
to do is linearly map the first 4GB (which is likely enough), you can
just pre-build the like... 6 or 7 tables you need (with 2m pages) in
an assembly source along with a 64-bit GDT and dummy IDT. Obviously
at start-up you
Heh, UEFI x64 runs in long mode, and it has no problems doing things
like that. To linearly map the first 4GB you need a whole of 24KB
worth of page tables (using 2m pages). And the code to enter long
mode directly from RM is pretty trivial. RM->16PM->LM.
Andrei Evgenievich Warkentin
[EMAI
I think it's safe to say that IDE is pretty much the same
anywhere on PowerPC there is no dedicated PIO address space, so
the IDE registers are memory mapped someplace (so don't forget to
eieio) (read PCI BARs or interpret device tree?).
Andrei Evgenievich Warkentin
[EMAIL PROTECTED]
Ce
).
Andrei Evgenievich Warkentin
[EMAIL PROTECTED]
Cell: (+1) (847) 321-15-55
On 24.03.2007, at 18:01, Yoshinori K. Okuji wrote:
On Saturday 24 March 2007 21:14, Andrei E. Warkentin wrote:
Actually, even now a Multiboot kernel has to do way too much work in
terms of memory initialization. The real
Actually, even now a Multiboot kernel has to do way too much work in
terms of memory initialization. The real problem is that GRUB only
gives you the BIOS memory map and the lowmem/highmem, which means you
need to figure out an "in use" memory map for yourself, by seeing if
any kernel modu
Inlined.
On 28.11.2006, at 19:55, bibo,mao wrote:
Yoshinori K. Okuji wrote:
On Tuesday 28 November 2006 13:46, bibo,mao wrote:
> yes, x84_64EFI starts with 64-bit long mode and page enabled
(virtual
> address equals physical address) if it is x86_64 efi bios, it
is defined in
> section
Shouldn't have done that. I'm assuming "sys" here is from Win9X or DOS.
The bootsector provided by NT looks for a file in the root of the
partition called "ntldr", which in turn looks for "boot.ini"
"ntdetect.com", and (obviously) ntoskrnl.exe and the initial drivers
loaded.
Basically, if
Well, couldn't the compressed .text/.rdata be stored in an ELF
section itself?
Andrei Evgenievich Warkentin
[EMAIL PROTECTED]
Cell: (+1) (847) 321-15-55
On 19.11.2006, at 10:55, Tristan Gingold wrote:
On Sun, Nov 19, 2006 at 10:26:54AM +, Brano Zarnovican wrote:
On 11/17/06, And
kernel
or not... and not ever be concerned with corrupt files with the
header past 8K.
Andrei Evgenievich Warkentin
[EMAIL PROTECTED]
Cell: (+1) (847) 321-15-55
On 17.11.2006, at 16:01, Hollis Blanchard wrote:
On Fri, 2006-11-17 at 15:27 -0600, Andrei E. Warkentin wrote:
How about having
How about having a custom e_type for ELF images booted by GRUB?
Something in the range between ET_LOOS and ET_HIOS (the OS specific
types). This way one could avoid the Multiboot header in ELF, as the
file would itself would identify self as GRUB-bootable or not.
Also...
I am not familiar w
http://www.ata-atapi.com/atadrvr.htm^^- Public domain ATAPI driver. Andrei Evgenievich Warkentin[EMAIL PROTECTED]Cell: (+1) (847) 321-15-55 On 25.10.2006, at 14:31, Tristan Gingold wrote:On Wed, Oct 25, 2006 at 07:41:41PM +0200, Marco Gerards wrote: Svante Signell <[EMAIL PROTECTED]> writes: Any co
I don't think it touches that area of memory at all. Why don't you try and find out ;-)? I think your real question is "how do I exit protected mode without crashing" - some useful info here (http://my.execpc.com/CE/AC/geezer/osd/gotchas/index.htm). Andrei Evgenievich Warkentin[EMAIL PROTECTED]Ce
On 13.10.2006, at 15:55, Hollis Blanchard wrote:
On Fri, 2006-10-13 at 15:06 -0500, Andrei E. Warkentin wrote:
I just stalk this mailing list, but I think it'd be great to turn the
Multiboot specification less PC BIOS-centric. The Multiboot spec
exposes various legacy structures for the x
I just stalk this mailing list, but I think it'd be great to turn the Multiboot specification less PC BIOS-centric. The Multiboot spec exposes various legacy structures for the x86 PC. How do you intend to work in platform specifics? Just expose the OF interface, or clone the device tree? What abou
Does the EFI version of GRUB work on an x64 EFI target? (as in... compiles for that particular target and uses EFI Boot Services instead of thunking down to 32 or 16 and relying on the CSM?). Is there anything to boot with it? Andrei Evgenievich Warkentin[EMAIL PROTECTED]Cell: (+1) (847) 321-15-5
25 matches
Mail list logo
