i'm unsubscribing from this list as i did not get any
response about these patches from anyone but horms so far
and that was a long time ago.
http://lists.infradead.org/pipermail/kexec/2018-August/021357.html
http://lists.infradead.org/pipermail/kexec/2018-August/021358.html
http://lists.infradead
> Is it desirable for this check to be run for each iteration of the loop.
thats is not really the case. that statemet is executed exactly once.
the first check in the loop body looks for the multiboot header
signature and continues the loop if not found. once that check
passes the iteration ends
Hello,
I'v posted 3 patches on august and did not receive a response.
http://lists.infradead.org/pipermail/kexec/2018-August/021357.html
http://lists.infradead.org/pipermail/kexec/2018-August/021358.html
http://lists.infradead.org/pipermail/kexec/2018-August/021359.html
what is the issue? how do
When the kernel requests video information, pass it the
framebuffer information in the multiboot header from
the linux framebuffer ioctl's.
With the arch specific --reset-vga or --consolve-vga
options, purgatory will reset the framebuffer so pass
information for standard ega text mode.
Signed-off
Use the appropriate types for ACPI reclaim and ACPI NVS
ranges in the multiboot memory map.
This allows the kernel to locate ACPI tables on UEFI
systems without having a explicit pointer to the RSD.
Signed-off-by: Friedemann Gerold
---
diff --git a/kexec/arch/i386/kexec-multiboot-x86.c
b/kexec/
Add support for non-elf multiboot kernels (such as Plan 9)
by handling the MULTIBOOT_AOUT_KLUDGE bit.
When the bit is clear then we are dealing with an ELF file
and probe for ELF as before with elf_x86_probe().
When the bit is set then load_addr, load_end_addr, header_addr
and entry_addr from the
theres a patch that provides support for non-elf multiboot kernels
and passes framebuffer information to the kernel if requested in
the multiboot header.
only rgb truecolor framebuffers are supported right now. if --reset-vga
or --console-vga was specified, it assumes the framebuffer will be
stand
ok, this patch get me to load plan9 kernel.
also adds acpi memory types to multiboot memory map
instead of marking them as reserved. this is needed
for the kernel to locate acpi tables in lack of a
explicit rsd pointer.
sorry, not attaching this as a file as the list
appears to block my mails wit
good day.
previous mail seems to be stuck in moderation for some
reason. can someone please check?
anyway, theres some progress.
i'v changed the 9front kernel to cope with missing acpi
table pointer and use the memory map now looking for the
RSD PTR structure in the ACPI reserved area.
the linu
implemented support in kexec-tools to boot plan9 kernel last night
(see attachment).
this is very basic support. it loads the kernel and provides it
a memory map (from info->memory_range) in its config area and also
has a optional parameter to pass additional plan9.ini configuration.
but i have a
messages from yesterday are still held in moderation
for "suspicious header". i suspect this is because i attached
c source file. can someone please check? should i send hyperlinks
instead?
--
cinap
___
kexec mailing list
kexec@lists.infradead.org
http:
https://www.kernel.org/doc/Documentation/fb/api.txt
according to this, fb_fix_screeninfo struct should have the
physical start address and stride of the framebuffer. but
it lies: giving me *ZERO* for smem_start. driver id is
"svgadrmfb".
is there any other linux interface to get to the phyical
fr
12 matches
Mail list logo
