lkml.org 
[lkml]   [2012]   [Sep]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH v4 0/2] ACPI: DBGP/DBG2 early console support for LPIA.
Date
Forgot to Cc x86 maintainers, will send again. Sorry for the noise.

> -----Original Message-----
> From: Zheng, Lv
> Sent: Friday, September 28, 2012 10:40 AM
> To: Brown, Len
> Cc: linux-kernel@vger.kernel.org; linux-acpi@vger.kernel.org; Zheng, Lv
> Subject: [PATCH v4 0/2] ACPI: DBGP/DBG2 early console support for LPIA.
>
> Microsoft Debug Port Table (DBGP or DBG2) is used by the Windows SoC
> platforms to describe their debugging facilities.
> Recent Low Power Intel Architecture (LPIA) platforms have utilized
> this for the SPI UART debug ports that are resident on their debug
> boards.
>
> This patch set enables the DBGP/DBG2 debug ports as an Linux early
> console launcher.
> The SPI UART debug ports support is also refined to co-exist with this
> new usage model.
>
> To use this facility on LPIA platforms, you need to enable the following
> kernel configurations:
> CONFIG_EARLY_PRINTK_ACPI=y
> CONFIG_EARLY_PRINTK_INTEL_MID_SPI=y
> Then you need to append the following kernel parameter to the kernel
> command line in your the boot loader configuration file:
> earlyprintk=acpi
>
> There is a dilemma in designing this patch set. There should be three
> steps to enable an early console for an operating system:
> 1. Probe: In this stage, the Linux kernel can detect the early consoles
> and the base address of their register block can be determined.
> This can be done by parsing the descriptors in the ACPI
> DBGP/DBG2
> tables. Note that acpi_table_init() must be called before
> parsing.
> 2. Setup: In this stage, the Linux kernel can apply user specified
> configuration options (ex. baudrate of serial ports) for the
> early consoles. This is done by parsing the early parameters
> passed to the kernel from the boot loaders. Note that
> parse_early_params() is called very early to allow parameters to
> be passed to other kernel subsystems.
> 3. Start: In this stage, the Linux kernel can make the console available
> to output messages. Since early consoles are always used for
> kernel boot up debugging, this must be done as early as possible
> to arm the kernel with more testability the kernel subsystems.
> Note that, this stage happens when the register_console() is
> called.
> The preferred sequence for the above steps is:
> +-----------------+ +-------------------+ +--------------------+
> | ACPI DBGP PROBE | -> | EARLY_PARAM SETUP | -> | EARLY_RPINTK
> START |
> +-----------------+ +-------------------+ +--------------------+
> But unfortunately, in the current x86 implementation, early parameters and
> early printk initialization are called before acpi_table_init() which
> requires early memory mapping facility.
> There are some choices for me to design this patch set:
> 1. Invoking acpi_table_init() before parse_early_param() to maintain the
> sequence:
> +-----------------+ +-------------------+ +--------------------+
> | ACPI DBGP PROBE | -> | EARLY_PARAM SETUP | -> | EARLY_RPINTK
> START |
> +-----------------+ +-------------------+ +--------------------+
> This requires other subsystem maintainers' review to ensure no
> regressions will be introduced. As far as I know, one kind of issue
> might be found in EFI subsystsm:
> The EFI boot services and runtime services are mixed up in the x86
> specific initialization process before the ACPI table initialization.
> Things are much worse that you even cannot disable the runtime services
> while still allow the boot services codes to be executed in the kernel
> compilation stage. Enabling the early consoles after the ACPI table
> initialization will make it difficult to debug the runtime BIOS bugs.
> If any progress is made to the kernel boot sequences, please let me
> know. I'll be willing to redesign the ACPI DBGP/DBG2 console probing
> facility. You can reach me at <zetalog@gmail.com>.
> 2. Modifying above sequece to make it look like:
> +-------------------+ +-----------------+ +--------------------+
> | EARLY_PARAM SETUP | -> | ACPI DBGP PROBE | -> | EARLY_RPINTK
> START |
> +-------------------+ +-----------------+ +--------------------+
> Early consoles started in this style will lose some debuggabilities in
> the kernel boot up. If the system does not crash very early,
> developers still can see the bufferred kernel outputs when the
> register_console() is called.
> Current early console implementation need to be modified to split their
> initialization codes into tow part:
> 1. Detecting hardware. This can be called in the PROBE stage.
> 2. Applying user parameters. This can be called in the SETUP stage.
> Individual early console drver maintainers need to be involved to avoid
> regressions that might occur on this modification as the maintainers
> might offer the real tests rather than I can do.
> 3. Introducing a barely new debugging facility that does not relate to the
> current early console implementation to allow automatic detection for
> the early consoles.
> +-------------------+ +--------------------+
> | EARLY_PARAM SETUP | -> | EARLY_RPINTK START |
> +-------------------+ +--------------------+
> +-----------------+ +--------------------+
> | ACPI DBGP PROBE | -> | EARLY_RPINTK START |
> +-----------------+ +--------------------+
> This is what the patch set has done to enable this new usage model.
> It is known as "ACPI early console launcher mode".
> Early consoles started in this style will lose some debuggabilities in
> the kernel boot up. If the system does not crash very early,
> developers still can see the bufferred kernel outputs when the
> register_console() is called.
> Note that the user configuration can not be applied to the registered
> early consoles in this way as the acpi_table_init() is still called
> after the parse_early_param(). Instead, the early consoles should
> derive the hardware settings used in the BIOS/bootloaders.
> As a launcher, ACPI DBGP will not actually output kernel messages
> without the real early console drivers, that's why the
> CONFIG_EARLY_PRINTK_INTEL_MID_SPI is still need to be enabled along
> along with the CONFIG_EARLY_PRINTK_ACPI.
> In order to disable this facility by default and enable it at runtime,
> an kernel parameter "earlyprintk=acpi" is introduced. This makes the
> actual sequence looks like:
> +-------------------+ +--------------------+
> | EARLY_PARAM SETUP | -> | EARLY_RPINTK START |
> +-------------------+ +....................+ +-----------------+
> | ACPI DBGP LAUNCH | -> | ACPI DBGP
> PROBE | ->
> +--------------------+ +-----------------+
> +--------------------+
> -> | EARLY_RPINTK START |
> +--------------------+
>
> Version 3 of this patch set is the first version that will be published
> in the Linux community. Earlier versions are reviewed internally in
> Intel. This patch set keeps the version number to track the history
> that is known to Intel internal developers.
> Version 4 of this patch set fixed bunch of CodingStyle issues.
>
> Lv Zheng (2):
> ACPI: Add early console framework for DBGP/DBG2.
> ACPI: Add Intel MID SPI early console support.
>
> Documentation/kernel-parameters.txt | 2 +
> arch/x86/Kconfig.debug | 38 +++++
> arch/x86/include/asm/mrst.h | 2 +-
> arch/x86/kernel/acpi/boot.c | 1 +
> arch/x86/kernel/early_printk.c | 25 +++-
> arch/x86/platform/mrst/early_printk_mrst.c | 186 +----------------------
> drivers/acpi/Makefile | 2 +
> drivers/acpi/early_printk.c | 201
> +++++++++++++++++++++++++
> drivers/platform/x86/Makefile | 2 +
> drivers/platform/x86/early/Makefile | 5 +
> drivers/platform/x86/early/intel_mid_spi.c | 220
> ++++++++++++++++++++++++++++
> include/acpi/actbl2.h | 1 +
> include/linux/acpi.h | 24 +++
> include/linux/intel_mid_early.h | 12 ++
> 14 files changed, 540 insertions(+), 181 deletions(-)
> create mode 100644 drivers/acpi/early_printk.c
> create mode 100644 drivers/platform/x86/early/Makefile
> create mode 100644 drivers/platform/x86/early/intel_mid_spi.c
> create mode 100644 include/linux/intel_mid_early.h
>
> --
> 1.7.10



\
 
 \ /
  Last update: 2012-09-28 07:41    [W:0.176 / U:0.544 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site