| Age | Commit message (Collapse) | Author |
|---|
|
commit 83e68189745ad931c2afd45d8ee3303929233e7f upstream.
Originally 'efi_enabled' indicated whether a kernel was booted from
EFI firmware. Over time its semantics have changed, and it now
indicates whether or not we are booted on an EFI machine with
bit-native firmware, e.g. 64-bit kernel with 64-bit firmware.
The immediate motivation for this patch is the bug report at,
https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557
which details how running a platform driver on an EFI machine that is
designed to run under BIOS can cause the machine to become
bricked. Also, the following report,
https://bugzilla.kernel.org/show_bug.cgi?id=47121
details how running said driver can also cause Machine Check
Exceptions. Drivers need a new means of detecting whether they're
running on an EFI machine, as sadly the expression,
if (!efi_enabled)
hasn't been a sufficient condition for quite some time.
Users actually want to query 'efi_enabled' for different reasons -
what they really want access to is the list of available EFI
facilities.
For instance, the x86 reboot code needs to know whether it can invoke
the ResetSystem() function provided by the EFI runtime services, while
the ACPI OSL code wants to know whether the EFI config tables were
mapped successfully. There are also checks in some of the platform
driver code to simply see if they're running on an EFI machine (which
would make it a bad idea to do BIOS-y things).
This patch is a prereq for the samsung-laptop fix patch.
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Corentin Chary <corentincj@iksaif.net>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Olof Johansson <olof@lixom.net>
Cc: Peter Jones <pjones@redhat.com>
Cc: Colin Ian King <colin.king@canonical.com>
Cc: Steve Langasek <steve.langasek@canonical.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 785107923a83d8456bbd8564e288a24d84109a46 upstream.
Some new ACPI 5.0 tables reference resources stored in boot services
memory, so keep that memory around until we have ACPI and can extract
data from it.
Signed-off-by: Josh Triplett <josh@joshtriplett.org>
Link: http://lkml.kernel.org/r/baaa6d44bdc4eb0c58e5d1b4ccd2c729f854ac55.1348876882.git.josh@joshtriplett.org
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Cc: Matt Fleming <matt@console-pimps.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
More recent versions of the UEFI spec have added new attributes for
variables. Add them.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Remove all #inclusions of asm/system.h preparatory to splitting and killing
it. Performed with the following command:
perl -p -i -e 's!^#\s*include\s*<asm/system[.]h>.*\n!!' `grep -Irl '^#\s*include\s*<asm/system[.]h>' *`
Signed-off-by: David Howells <dhowells@redhat.com>
|
|
Traditionally the kernel has refused to setup EFI at all if there's been
a mismatch in 32/64-bit mode between EFI and the kernel.
On some platforms that boot natively through EFI (Chrome OS being one),
we still need to get at least some of the static data such as memory
configuration out of EFI. Runtime services aren't as critical, and
it's a significant amount of work to implement switching between the
operating modes to call between kernel and firmware for thise cases. So
I'm ignoring it for now.
v5:
* Fixed some printk strings based on feedback
* Renamed 32/64-bit specific types to not have _ prefix
* Fixed bug in printout of efi runtime disablement
v4:
* Some of the earlier cleanup was accidentally reverted by this patch, fixed.
* Reworded some messages to not have to line wrap printk strings
v3:
* Reorganized to a series of patches to make it easier to review, and
do some of the cleanups I had left out before.
v2:
* Added graceful error handling for 32-bit kernel that gets passed
EFI data above 4GB.
* Removed some warnings that were missed in first version.
Signed-off-by: Olof Johansson <olof@lixom.net>
Link: http://lkml.kernel.org/r/1329081869-20779-6-git-send-email-olof@lixom.net
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
|
|
The x86 EFI stub needs to access files, for example when loading
initrd's. Add the required data types.
Cc: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Link: http://lkml.kernel.org/r/1318848017-12301-1-git-send-email-matt@console-pimps.org
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
|
|
The x86 EFI boot stub needs to locate handles for various protocols.
Cc: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Link: http://lkml.kernel.org/r/1318848017-12301-1-git-send-email-matt@console-pimps.org
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
|
|
The x86 EFI boot stub uses the Graphics Output Protocol and Universal
Graphics Adapter (UGA) protocol guids when initialising graphics
during boot.
Cc: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Link: http://lkml.kernel.org/r/1318848017-12301-1-git-send-email-matt@console-pimps.org
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
|
|
Add the allocation types detailed in section 6.2 - "AllocatePages()"
of the UEFI 2.3 specification. These definitions will be used by the
x86 EFI boot stub which needs to allocate memory during boot.
Cc: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Link: http://lkml.kernel.org/r/1318848017-12301-1-git-send-email-matt@console-pimps.org
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
|
|
Add the EFI loaded image structure and protocol guid which are
required by the x86 EFI boot stub. The EFI boot stub uses the
structure to figure out where it was loaded in memory and to pass
command line arguments to the kernel.
Cc: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Link: http://lkml.kernel.org/r/1318848017-12301-1-git-send-email-matt@console-pimps.org
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
|
|
With the forthcoming efi stub code we're gonna need to access boot
time services so let's define a struct so we can access the functions.
Cc: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Link: http://lkml.kernel.org/r/1318848017-12301-1-git-send-email-matt@console-pimps.org
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6
* 'pstore-efi' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6:
efivars: Introduce PSTORE_EFI_ATTRIBUTES
efivars: Use string functions in pstore_write
efivars: introduce utf16_strncmp
efivars: String functions
efi: Add support for using efivars as a pstore backend
pstore: Allow the user to explicitly choose a backend
pstore: Make "part" unsigned
pstore: Add extra context for writes and erases
pstore: Extend API for more flexibility in new backends
|
|
EFI provides an area of nonvolatile storage managed by the firmware. We
can use this as a pstore backend to maintain copies of oopses, aiding
diagnosis.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
|
|
We're currently missing support for any of the runtime service calls
introduced with the UEFI 2.0 spec in 2006. Add the infrastructure for
supporting them.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Link: http://lkml.kernel.org/r/1307388985-7852-2-git-send-email-mjg@redhat.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
|
|
The spec says this takes uint32 for attributes, not uintn.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Link: http://lkml.kernel.org/r/1307388985-7852-1-git-send-email-mjg@redhat.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
|
|
UEFI stands for "Unified Extensible Firmware Interface", where "Firmware"
is an ancient African word meaning "Why do something right when you can
do it so wrong that children will weep and brave adults will cower before
you", and "UEI" is Celtic for "We missed DOS so we burned it into your
ROMs". The UEFI specification provides for runtime services (ie, another
way for the operating system to be forced to depend on the firmware) and
we rely on these for certain trivial tasks such as setting up the
bootloader. But some hardware fails to work if we attempt to use these
runtime services from physical mode, and so we have to switch into virtual
mode. So far so dreadful.
The specification makes it clear that the operating system is free to do
whatever it wants with boot services code after ExitBootServices() has been
called. SetVirtualAddressMap() can't be called until ExitBootServices() has
been. So, obviously, a whole bunch of EFI implementations call into boot
services code when we do that. Since we've been charmingly naive and
trusted that the specification may be somehow relevant to the real world,
we've already stuffed a picture of a penguin or something in that address
space. And just to make things more entertaining, we've also marked it
non-executable.
This patch allocates the boot services regions during EFI init and makes
sure that they're executable. Then, after SetVirtualAddressMap(), it
discards them and everyone lives happily ever after. Except for the ones
who have to work on EFI, who live sad lives haunted by the knowledge that
someone's eventually going to write yet another firmware specification.
[ hpa: adding this to urgent with a stable tag since it fixes currently-broken
hardware. However, I do not know what the dependencies are and so I do
not know which -stable versions this may be a candidate for. ]
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Link: http://lkml.kernel.org/r/1306331593-28715-1-git-send-email-mjg@redhat.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: <stable@kernel.org>
|
|
Signed-off-by: Mike Waychison <mikew@google.com>
Cc: Matt Domsch <Matt_Domsch@dell.com>,
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
Shrinks vmlinux
without:
$ size vmlinux
text data bss dec hex filename
6975863 679652 1359668 9015183 898f8f vmlinux
with:
$ size vmlinux
text data bss dec hex filename
6975639 679652 1359668 9014959 898eaf vmlinux
Signed-off-by: Joe Perches <joe@perches.com>
Cc: Jeff Garzik <jgarzik@redhat.com>
Cc: Tejun Heo <tj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
It is generally agreed that it would be beneficial for u64 to be an
unsigned long long on all architectures. ia64 (in common with several
other 64-bit architectures) currently uses unsigned long. Migrating
piecemeal is too painful; this giant patch fixes all compilation warnings
and errors that come as a result of switching to use int-ll64.h.
Note that userspace will still see __u64 defined as unsigned long. This
is important as it affects C++ name mangling.
[Updated by Tony Luck to change efi.h:efi_freemem_callback_t to use
u64 for start/end rather than unsigned long]
Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
|
|
Look for a UV entry in the EFI tables.
Signed-off-by: Russ Anderson <rja@sgi.com>
Signed-off-by: Paul Jackson <pj@sgi.com>
Acked-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
|
Remove three extern declarations for routines
that don't exist. Fix a typo in a comment.
Signed-off-by: Paul Jackson <pj@sgi.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
|
Make x86 EFI code works when EFI_PAGE_SHIFT != PAGE_SHIFT. The
memrage_efi_to_native() provided in this patch can be used on other
EFI platform such as IA64 too.
This patch has been tested on Intel x86_64 platform with EFI 64/32
firmware.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
|
Add the BSS to the resource tree just as kernel text and kernel data are in
the resource tree. The main reason behind this is to avoid crashkernel
reservation in that area.
While it's not strictly necessary to have the BSS in the resource tree (the
actual collision detection is done in the reserve_bootmem() function before),
the usage of the BSS resource should be presented to the user in /proc/iomem
just as Kernel data and Kernel code.
Note: The patch currently is only implemented for x86 and ia64 (because
efi_initialize_iomem_resources() has the same signature on i386 and ia64).
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Bernhard Walle <bwalle@suse.de>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Vivek Goyal <vgoyal@in.ibm.com>
Cc: <linux-arch@vger.kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
We used to warn unless the EFI system table major revision was exactly 1.
But EFI 2.00 firmware is starting to appear, and the 2.00 changes don't
affect anything in Linux.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Andi Kleen <ak@suse.de>
Cc: "Luck, Tony" <tony.luck@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
fix the extern in efi.h
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
When using memmap kernel parameter in EFI boot we should also add to memory map
memory regions of runtime services to enable their mapping later.
AK: merged and cleaned up the patch
Signed-off-by: Artiom Myaskouvskey <artiom.myaskouvskey@intel.com>
Signed-off-by: Andi Kleen <ak@suse.de>
|
|
Function efi_get_time called not only during init kernel phase but also
during suspend (from get_cmos_time).
When it is called from get_cmos_time the corresponding runtime service
should be called in virtual and not in physical mode.
Signed-off-by: Artiom Myaskouvskey <artiom.myaskouvskey@intel.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Cc: "Narayanan, Chandramouli" <chandramouli.narayanan@intel.com>
Cc: "Jiossy, Rami" <rami.jiossy@intel.com>
Cc: "Satt, Shai" <shai.satt@intel.com>
Cc: Andi Kleen <ak@suse.de>
Cc: Matt Domsch <Matt_Domsch@dell.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
|
|
This closes a couple holes in our attribute aliasing avoidance scheme:
- The current kernel fails mmaps of some /dev/mem MMIO regions because
they don't appear in the EFI memory map. This keeps X from working
on the Intel Tiger box.
- The current kernel allows UC mmap of the 0-1MB region of
/sys/.../legacy_mem even when the chipset doesn't support UC
access. This causes an MCA when starting X on HP rx7620 and rx8620
boxes in the default configuration.
There's more detail in the Documentation/ia64/aliasing.txt file this
adds, but the general idea is that if a region might be covered by
a granule-sized kernel identity mapping, any access via /dev/mem or
mmap must use the same attribute as the identity mapping.
Otherwise, we fall back to using an attribute that is supported
according to the EFI memory map, or to using UC if the EFI memory
map doesn't mention the region.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
|
|
Almost all users of the table addresses from the EFI system table want
physical addresses. So rather than doing the pa->va->pa conversion, just keep
physical addresses in struct efi.
This fixes a DMI bug: the efi structure contained the physical SMBIOS address
on x86 but the virtual address on ia64, so dmi_scan_machine() used ioremap()
on a virtual address on ia64.
This is essentially the same as an earlier patch by Matt Tolentino:
http://marc.theaimsgroup.com/?l=linux-kernel&m=112130292316281&w=2
except that this changes all table addresses, not just ACPI addresses.
Matt's original patch was backed out because it caused MCAs on HP sx1000
systems. That problem is resolved by the ioremap() attribute checking added
for ia64.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Matt Domsch <Matt_Domsch@dell.com>
Cc: "Tolentino, Matthew E" <matthew.e.tolentino@intel.com>
Cc: "Brown, Len" <len.brown@intel.com>
Cc: Andi Kleen <ak@muc.de>
Acked-by: "Luck, Tony" <tony.luck@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Pass the size, not a pointer to the size, to efi_mem_attribute_range().
This function validates memory regions for the /dev/mem read/write/mmap paths.
The pointer allows arches to reduce the size of the range, but I think that's
unnecessary complexity. Simplifying it will let me use
efi_mem_attribute_range() to improve the ia64 ioremap() implementation.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Matt Domsch <Matt_Domsch@dell.com>
Cc: "Tolentino, Matthew E" <matthew.e.tolentino@intel.com>
Cc: "Brown, Len" <len.brown@intel.com>
Cc: Andi Kleen <ak@muc.de>
Acked-by: "Luck, Tony" <tony.luck@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
The memory descriptors that comprise the EFI memory map are not fixed in
stone such that the size could change in the future. This uses the memory
descriptor size obtained from EFI to iterate over the memory map entries
during boot. This enables the removal of an x86 specific pad (and ifdef)
in the EFI header. I also couldn't stomach the broken up nature of the
function to put EFI runtime calls into virtual mode any longer so I fixed
that up a bit as well.
For reference, this patch only impacts x86.
Signed-off-by: Matt Tolentino <matthew.e.tolentino@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
warning when building with gcc -W :
include/linux/efi.h: In function `efi_range_is_wc':
include/linux/efi.h:320: warning: comparison between signed and unsigned
It looks to me like a significantly large 'len' passed in could cause the
loop to never end. Isn't it safer to make 'i' an unsigned long as well?
Like this little patch below (which of course also kills the warning) :
Signed-off-by: Jesper Juhl <juhl-lkml@dif.dk>
Signed-off-by: Tony Luck <tony.luck@intel.com>
|
|
This is a megarollup of ~60 patches which give various things static scope.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
This patch cleans up the per-CPU MCA mess with the following changes
(and yields a UP kernel that actually boots again):
- In percpu.h, make per_cpu_init() a function-call even for the
UP case.
- In contig.c, enable per_cpu_init() even for UP since we need to
allocate the per-CPU MCA data in that case as well.
- Move the MCA-related stuff out of the cpuinfo structure into
per-CPU variables defined by mca.c.
- Rename IA64_KR_PA_CPU_INFO to IA64_KR_PER_CPU_DATA, since it really
is a per-CPU pointer now.
- In mca.h, move IA64_MCA_STACK_SIZE early enough so it gets defined
for assembly-code, too. Tidy up struct ia64_mca_struct. Add declaration
of ia64_mca_cpu_init().
- In mca_asm.[hS], replace various GET_*() macros with a single
GET_PERCPU_ADDR() which loads the physical address of an
arbitrary per-CPU variable. Remove all dependencies on the
layout of the cpuinfo structure. Replace hardcoded stack-size
with IA64_MCA_STACK_SIZE constant. Replace hardcoded references
to ar.k3 with IA64_KR(PER_CPU_DATA).
- In setup.c:cpu_init(), initialize ar.k3 to be the physical equivalent
of the per-CPU data pointer.
- Nuke silly ia64_mca_cpu_t typedef and just use struct ia64_mca_cpu instead.
- Move __per_cpu_mca[] from setup.c to mca.c.
- Rename set_mca_pointer() to ia64_mca_cpu_init() and sanitize it.
- Rename efi.c:pal_code_memdesc() to efi_get_pal_addr() and make it
return the PAL address, rather than a memory-descriptor.
- Make efi_map_pal_code() use efi_get_pal_addr().
Signed-off-by: David Mosberger-Tang <davidm@hpl.hp.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
|
|
Ok, here you go Tony. This one fixes the loop and also fixes drm_vm.c. All
of the bits aside from the efi.h bit are ia64 specific (either under
arch/ia64 or __ia64__), so your tree is probably the right place for all of
it.
This patch adds efi_range_is_wc() to efi.h. It's used to determine whether an
address range can be mapped with the write coalescing attribute. It also
fixes up some ia64 specific callers to use the new routine instead of
unconditionally calling pgprot_writecombined, which can be dangerous if used
on ranges that don't support it.
Signed-off-by: Jesse Barnes <jbarnes@sgi.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
|
|
This changes the HCDP/PCDP support to use the early uart console
rather than using early_serial_setup().
As a consequence, ia64 serial device names will now stay constant
regardless of firmware console settings. (A serial device selected as
an EFI console device on HP ia64 boxes used to automatically become
ttyS0.)
This also removes the ia64 early-boot kludge of assuming legacy COM
ports at 0x3f8 and 0x2f8. For boxes that have legacy ports but no
HCDP, "console=ttyS0" will still work, but the console won't start
working until after the serial driver initializes and discovers the
devices.
WARNING:
If you have an HP machine and you're using the MP serial console port
(the connector labelled "console" on the 3-headed cable), this patch
will break your console!
HOW TO FIX IT:
1) The console device will change from /dev/ttyS0 to /dev/ttyS1,
ttyS2, or ttyS3, so:
1a) Edit /etc/inittab to add a getty entry for
/dev/ttyS1 (rx4640, rx5670, rx7620, rx8620, Superdome),
/dev/ttyS2 (rx1600), or
/dev/ttyS3 (rx2600).
1b) Edit /etc/securetty to add ttyS1, ttyS2, or ttyS3.
1c) Leave the existing ttyS0 entries in /etc/inittab and
/etc/securetty so you can still boot old kernels.
2) Edit /etc/elilo.conf to remove any "console=" arguments (see [1]).
3) Run elilo to install the bootloader with new configuration.
4) Reboot and use the EFI boot option maintenance menu to select
exactly one device for console output, input, and standard error.
Then do a cold reset so the changes take effect.
For the MP console, be careful to select the device with
"Acpi(HWP0002,700)/Pci(...)/Uart" in the path (see [2]).
DETAILS:
- Prior to this patch, serial device names depended on the HCDP,
which in turn depends on EFI console settings. After this patch,
the naming always stays the same, regardless of firmware settings.
For example, an rx1600 with a single built-in serial port plus
an MP has these ports:
Old Old
MMIO (EFI console (EFI console
address on builtin) on MP port) New
========== ========== ========== ======
builtin 0xff5e0000 ttyS0 ttyS1 ttyS0
MP UPS 0xf8031000 ttyS1 ttyS2 ttyS1
MP Console 0xf8030000 ttyS2 ttyS0 ttyS2
MP 2 0xf8030010 ttyS3 ttyS3 ttyS3
MP 3 0xf8030038 ttyS4 ttyS4 ttyS4
- If you want to have multiple devices in the EFI console path, you
can, but Linux won't be able to deduce which console to use, so it
will default to using VGA. You can use "console=hcdp" (the UART
device from the EFI path) or "console=ttyS<n>" to select the
device directly.
TROUBLESHOOTING:
- No kernel output after "Uncompressing Linux... done":
-> You're using an MP port as the console and specified
"console=ttyS0". This port is now named something else.
Remove the "console=" option.
-> Multiple UARTs selected as EFI console devices, and you're
looking at the wrong one. Make sure only one UART is
selected (use the EFI Boot Manager "Boot option maintenance"
menu).
-> You're physically connected to the MP port but have a
non-MP UART selected as EFI console device. Either move
the console cable to the non-MP UART, or change the EFI
console path to the MP UART (the MP UART is the one with
"Acpi(HWP0002,700)/Pci(...)/Uart" in it.)
- Long pause (60+ seconds) between "Uncompressing Linux... done"
and start of kernel output:
-> No early console, probably because you used "console=ttyS<n>".
Remove the "console=" option.
- Kernel and init script output works fine, but no "login:" prompt:
-> Add getty entry to /etc/inittab for console tty. Use the table
in (1a) above or look for the "Adding console on ttyS<n>" message
that tells you which device is the console.
- "login:" prompt, but can't login as root:
-> Add entry to /etc/securetty for console tty.
[1] When the EFI console path contains exactly one device (either
serial or VGA), 2.6.6 and newer kernels default to that device
automatically. So if you remove "console=" arguments, you can use
the same elilo configuration to boot any 2.6.6 or newer kernel
with or without this patch.
If you need to boot kernels older than 2.6.6 (including RHEL3 and
SLES9), keep an 'append="console=ttyS0"' line in those elilo.conf
stanzas.
Non-HP machines will still need "console=" for serial consoles
because they don't supply the HCDP table.
[2] The HP management card (MP) causes confusion because it is always
active as an EFI console, even if it doesn't appear in the EFI
console path. If your console path is set to a non-MP UART, and
you happen to be attached to the MP UART, everything works in EFI,
but the kernel will think the non-MP UART is the console, so you
won't see any kernel output.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
efi.h declares a function type, and then uses that as an argument to
another function, and expects the compiler to magically demote the
function to a function pointer.
Even a gcc person (rth) was surprised that this was legal, and it
doesn't match any other use of a function pointer in the kernel, and
sparse doesn't like the implicit type-conversion.
So make the type sane in the first place, instead of depending on
a very weird corner case of the C language.
|
|
Add support for the EFI/DIG PCDP console discovery table (see
http://www.dig64.org/specifications/DIG64_HCDPv20_042804.pdf).
This moves the code from drivers/serial/8250_hcdp.[ch] to
drivers/firmware/pcdp.[ch], since it's no longer 8250-specific. It also
obsoletes CONFIG_SERIAL_8250_HCDP, replacing it with CONFIG_EFI_PCDP (which
defaults to Y for ia64).
In a nutshell, HCDP tells us "these UARTs are available for use as a
console," and it's up to the user to explicitly specify the console device.
The kernel can guess in some cases, but not all.
The PCDP (aka HCDP v2) tells us what we really want to know, namely, "this
UART or VGA device is the console device." (It also has provision for
support for new device types.)
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
From: Matt Tolentino <metolent@snoqualmie.dp.intel.com>
The /proc support for efi 'stuff' isn't used/needed anymore, yet the
efi_dir declaration remains. This removes it.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Patch from Bjorn Helgaas
This adds efi_uart_console_only() so we can default to using a serial
console if the EFI console path only contains UARTs.
|
|
From: Andi Kleen <ak@muc.de>
Just many more warning fixes for a gcc 3.4 snapshot.
It warns for a lot of things now, e.g. for ?: and ({ ... }) and casts as
lvalues. And for functions marked inline in headers, but no body.
Actually there are more warnings, i stopped fixing at some point. Some of
the warnings seem to be dubious (e.g. the binfmt_elf.c one, which looks
more like a compiler bug to me)
I also fixed the _exit() prototype to be void because gcc was complaining
about this.
|
|
From: David Mosberger <davidm@napali.hpl.hp.com>
There is some EFI-related code which is present in the ia64 build but is not
needed: variable efi_enabled is always zero.
The patch fiddles with the efi_enabled definition to arrange for
`efi_enabled' to be constant zero or constant one in those situations where
this can be guaranteed.
|
|
From: Jesper Juhl <juhl-lkml@dif.dk>
I'm compiling 2.6.1-rc1-mm1 with "-W -Wall" to look for potential problems
and minor stuff to clean up.
One of the things that enabling the extra warnings turn up is errors about
the placement of the inline keyword.
|
|
From: Matt Tolentino <metolent@snoqualmie.dp.intel.com>
Attached is a patch that enables EFI boot-up support in ia32 kernels.
In order to continue to determine whether the kernel should initialize using
EFI tables, I've temporarily added a check on the LOADER_TYPE boot parameter.
Although I haven't requested that elilo be assigned an id for this yet, I've
used this to determine whether the kernel should use the EFI initialization
path as well as a check to see if the EFI_SYSTAB boot parameter contains
anything. If someone has a better suggestion for determining this, I'm
open...
This patch also uses the existing ioremapping functions to map the efi tables
into kernel virtual address space. I've added an option such that I could
use Dave Hansen's boot_ioremap() before paging_init(). After paging_init, I
then remap the efi memmap using bt_ioremap for use later. This has
eliminated the need for several functions...thanks for the suggestions and
thanks for your help Dave. Still this could use a look-see.
|
|
From Matt Tolentino:
Here's a small patch to change several data types from u64 to
unsigned long in efi.h. These changes enable the use of the
same data structures and function prototypes for ia32 EFI kernels.
|
|
|
|
It makes no sense to keep efi.h as an ia64-specific header (there really
are x86 machines coming out with optional EFI BIOS support).
|
