From: Mukesh Ojha <quic_mojha@quicinc.com> To: <corbet@lwn.net>, <agross@kernel.org>, <andersson@kernel.org>, <konrad.dybcio@linaro.org>, <robh+dt@kernel.org>, <krzysztof.kozlowski+dt@linaro.org>, <conor+dt@kernel.org>, <keescook@chromium.org>, <tony.luck@intel.com>, <gpiccoli@igalia.com>, <mathieu.poirier@linaro.org>, <vigneshr@ti.com>, <nm@ti.com>, <matthias.bgg@gmail.com>, <kgene@kernel.org>, <alim.akhtar@samsung.com>, <bmasney@redhat.com> Cc: <linux-doc@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <linux-arm-msm@vger.kernel.org>, <linux-hardening@vger.kernel.org>, <linux-remoteproc@vger.kernel.org>, <linux-arm-kernel@lists.infradead.org>, <linux-mediatek@lists.infradead.org>, <linux-samsung-soc@vger.kernel.org>, <kernel@quicinc.com>, Mukesh Ojha <quic_mojha@quicinc.com> Subject: [Patch v6 10/12] pstore/ram: Add dynamic ramoops region support through commandline Date: Sat, 25 Nov 2023 03:49:53 +0530 [thread overview] Message-ID: <1700864395-1479-11-git-send-email-quic_mojha@quicinc.com> (raw) In-Reply-To: <1700864395-1479-1-git-send-email-quic_mojha@quicinc.com> The reserved memory region for ramoops is assumed to be at a fixed and known location when read from the devicetree. This may not be required for something like Qualcomm's minidump which is interested in knowing addresses of ramoops region but it does not put hard requirement of address being fixed as most of it's SoC does not support warm reset and does not use pstorefs at all instead it has firmware way of collecting ramoops region if it gets to know the address and register it with apss minidump table which is sitting in shared memory region in DDR and firmware will have access to these table during reset and collects it on crash of SoC. So, add the support of reserving ramoops region to be dynamically allocated early during boot if it is request through command line via 'dyn_ramoops_size=<size>' and fill up reserved resource structure and export the structure, so that it can be read by ramoops driver. Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com> --- Documentation/admin-guide/ramoops.rst | 7 ++++ fs/pstore/Kconfig | 15 +++++++++ fs/pstore/ram.c | 62 ++++++++++++++++++++++++++++++++--- include/linux/pstore_ram.h | 5 +++ init/main.c | 2 ++ 5 files changed, 87 insertions(+), 4 deletions(-) diff --git a/Documentation/admin-guide/ramoops.rst b/Documentation/admin-guide/ramoops.rst index e9f85142182d..af737adbf079 100644 --- a/Documentation/admin-guide/ramoops.rst +++ b/Documentation/admin-guide/ramoops.rst @@ -33,6 +33,13 @@ memory are implementation defined, and won't work on many ARMs such as omaps. Setting ``mem_type=2`` attempts to treat the memory region as normal memory, which enables full cache on it. This can improve the performance. +Ramoops memory region can also be allocated dynamically for a special case where +there is no requirement to access the logs from pstorefs on next boot instead there +is separate backend mechanism like minidump present which has awareness about the +dynamic ramoops region and can recover the logs. This is enabled via command line +parameter ``dyn_ramoops_size=<size>`` and should not be used in absence of +separate backend which knows how to recover this dynamic region. + The memory area is divided into ``record_size`` chunks (also rounded down to power of two) and each kmesg dump writes a ``record_size`` chunk of information. diff --git a/fs/pstore/Kconfig b/fs/pstore/Kconfig index 3acc38600cd1..e13e53d7a225 100644 --- a/fs/pstore/Kconfig +++ b/fs/pstore/Kconfig @@ -81,6 +81,21 @@ config PSTORE_RAM For more information, see Documentation/admin-guide/ramoops.rst. +config PSTORE_DYNAMIC_RAMOOPS_REGION_RESERVATION + bool "Reserve ramoops region dynamically" + select PSTORE_RAM + help + This enables the dynamic reservation of ramoops region for a special case + where there is no requirement to access the logs from pstorefs on next boot + instead there is separate backend mechanism like minidump present which has + awareness about the dynamic ramoops region and can recover the logs. This is + enabled via command line parameter dyn_ramoops_size=<size> and should not be + used in absence of separate backend which knows how to recover this dynamic + region. + + Note whenever this config is selected ramoops driver will be build statically + into kernel. + config PSTORE_ZONE tristate depends on PSTORE diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c index 88b34fdbf759..a6c0da8cfdd4 100644 --- a/fs/pstore/ram.c +++ b/fs/pstore/ram.c @@ -20,6 +20,7 @@ #include <linux/compiler.h> #include <linux/of.h> #include <linux/of_address.h> +#include <linux/memblock.h> #include <linux/mm.h> #include "internal.h" @@ -103,6 +104,55 @@ struct ramoops_context { }; static struct platform_device *dummy; +static int dyn_ramoops_size; +/* Location of the reserved area for the dynamic ramoops */ +static struct resource dyn_ramoops_res = { + .name = "ramoops", + .start = 0, + .end = 0, + .flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM, + .desc = IORES_DESC_NONE, +}; + +static int __init parse_dyn_ramoops_size(char *p) +{ + char *tmp; + + dyn_ramoops_size = memparse(p, &tmp); + if (p == tmp) { + pr_err("ramoops: memory size expected\n"); + return -EINVAL; + } + + return 0; +} +early_param("dyn_ramoops_size", parse_dyn_ramoops_size); + +#ifdef CONFIG_PSTORE_DYNAMIC_RAMOOPS_REGION_RESERVATION +/* + * setup_dynamic_ramoops() - reserves memory for dynamic ramoops + * + * This enable dynamic reserve memory support for ramoops through + * command line. + */ +void __init setup_dynamic_ramoops(void) +{ + unsigned long long ramoops_base; + unsigned long long ramoops_size; + + ramoops_base = memblock_phys_alloc_range(dyn_ramoops_size, SMP_CACHE_BYTES, + 0, MEMBLOCK_ALLOC_NOLEAKTRACE); + if (!ramoops_base) { + pr_err("cannot allocate ramoops dynamic memory (size:0x%llx).\n", + ramoops_size); + return; + } + + dyn_ramoops_res.start = ramoops_base; + dyn_ramoops_res.end = ramoops_base + dyn_ramoops_size - 1; + insert_resource(&iomem_resource, &dyn_ramoops_res); +} +#endif static int ramoops_pstore_open(struct pstore_info *psi) { @@ -915,14 +965,18 @@ static void __init ramoops_register_dummy(void) /* * Prepare a dummy platform data structure to carry the module - * parameters. If mem_size isn't set, then there are no module - * parameters, and we can skip this. + * parameters. If mem_size isn't set, check for dynamic ramoops + * size and use if it is set. */ - if (!mem_size) + if (!mem_size && !dyn_ramoops_size) return; - pr_info("using module parameters\n"); + if (dyn_ramoops_size) { + mem_size = dyn_ramoops_size; + mem_address = dyn_ramoops_res.start; + } + pr_info("using module parameters\n"); memset(&pdata, 0, sizeof(pdata)); pdata.mem_size = mem_size; pdata.mem_address = mem_address; diff --git a/include/linux/pstore_ram.h b/include/linux/pstore_ram.h index 9d65ff94e216..b3537336c4e1 100644 --- a/include/linux/pstore_ram.h +++ b/include/linux/pstore_ram.h @@ -39,4 +39,9 @@ struct ramoops_platform_data { struct persistent_ram_ecc_info ecc_info; }; +#ifdef CONFIG_PSTORE_DYNAMIC_RAMOOPS_REGION_RESERVATION +void __init setup_dynamic_ramoops(void); +#else +static inline void __init setup_dynamic_ramoops(void) {} +#endif #endif diff --git a/init/main.c b/init/main.c index e24b0780fdff..32c7d94558ec 100644 --- a/init/main.c +++ b/init/main.c @@ -99,6 +99,7 @@ #include <linux/init_syscalls.h> #include <linux/stackdepot.h> #include <linux/randomize_kstack.h> +#include <linux/pstore_ram.h> #include <net/net_namespace.h> #include <asm/io.h> @@ -895,6 +896,7 @@ void start_kernel(void) pr_notice("%s", linux_banner); early_security_init(); setup_arch(&command_line); + setup_dynamic_ramoops(); setup_boot_config(); setup_command_line(command_line); setup_nr_cpu_ids(); -- 2.7.4
WARNING: multiple messages have this Message-ID (diff)
From: Mukesh Ojha <quic_mojha@quicinc.com> To: <corbet@lwn.net>, <agross@kernel.org>, <andersson@kernel.org>, <konrad.dybcio@linaro.org>, <robh+dt@kernel.org>, <krzysztof.kozlowski+dt@linaro.org>, <conor+dt@kernel.org>, <keescook@chromium.org>, <tony.luck@intel.com>, <gpiccoli@igalia.com>, <mathieu.poirier@linaro.org>, <vigneshr@ti.com>, <nm@ti.com>, <matthias.bgg@gmail.com>, <kgene@kernel.org>, <alim.akhtar@samsung.com>, <bmasney@redhat.com> Cc: <linux-doc@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <linux-arm-msm@vger.kernel.org>, <linux-hardening@vger.kernel.org>, <linux-remoteproc@vger.kernel.org>, <linux-arm-kernel@lists.infradead.org>, <linux-mediatek@lists.infradead.org>, <linux-samsung-soc@vger.kernel.org>, <kernel@quicinc.com>, Mukesh Ojha <quic_mojha@quicinc.com> Subject: [Patch v6 10/12] pstore/ram: Add dynamic ramoops region support through commandline Date: Sat, 25 Nov 2023 03:49:53 +0530 [thread overview] Message-ID: <1700864395-1479-11-git-send-email-quic_mojha@quicinc.com> (raw) In-Reply-To: <1700864395-1479-1-git-send-email-quic_mojha@quicinc.com> The reserved memory region for ramoops is assumed to be at a fixed and known location when read from the devicetree. This may not be required for something like Qualcomm's minidump which is interested in knowing addresses of ramoops region but it does not put hard requirement of address being fixed as most of it's SoC does not support warm reset and does not use pstorefs at all instead it has firmware way of collecting ramoops region if it gets to know the address and register it with apss minidump table which is sitting in shared memory region in DDR and firmware will have access to these table during reset and collects it on crash of SoC. So, add the support of reserving ramoops region to be dynamically allocated early during boot if it is request through command line via 'dyn_ramoops_size=<size>' and fill up reserved resource structure and export the structure, so that it can be read by ramoops driver. Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com> --- Documentation/admin-guide/ramoops.rst | 7 ++++ fs/pstore/Kconfig | 15 +++++++++ fs/pstore/ram.c | 62 ++++++++++++++++++++++++++++++++--- include/linux/pstore_ram.h | 5 +++ init/main.c | 2 ++ 5 files changed, 87 insertions(+), 4 deletions(-) diff --git a/Documentation/admin-guide/ramoops.rst b/Documentation/admin-guide/ramoops.rst index e9f85142182d..af737adbf079 100644 --- a/Documentation/admin-guide/ramoops.rst +++ b/Documentation/admin-guide/ramoops.rst @@ -33,6 +33,13 @@ memory are implementation defined, and won't work on many ARMs such as omaps. Setting ``mem_type=2`` attempts to treat the memory region as normal memory, which enables full cache on it. This can improve the performance. +Ramoops memory region can also be allocated dynamically for a special case where +there is no requirement to access the logs from pstorefs on next boot instead there +is separate backend mechanism like minidump present which has awareness about the +dynamic ramoops region and can recover the logs. This is enabled via command line +parameter ``dyn_ramoops_size=<size>`` and should not be used in absence of +separate backend which knows how to recover this dynamic region. + The memory area is divided into ``record_size`` chunks (also rounded down to power of two) and each kmesg dump writes a ``record_size`` chunk of information. diff --git a/fs/pstore/Kconfig b/fs/pstore/Kconfig index 3acc38600cd1..e13e53d7a225 100644 --- a/fs/pstore/Kconfig +++ b/fs/pstore/Kconfig @@ -81,6 +81,21 @@ config PSTORE_RAM For more information, see Documentation/admin-guide/ramoops.rst. +config PSTORE_DYNAMIC_RAMOOPS_REGION_RESERVATION + bool "Reserve ramoops region dynamically" + select PSTORE_RAM + help + This enables the dynamic reservation of ramoops region for a special case + where there is no requirement to access the logs from pstorefs on next boot + instead there is separate backend mechanism like minidump present which has + awareness about the dynamic ramoops region and can recover the logs. This is + enabled via command line parameter dyn_ramoops_size=<size> and should not be + used in absence of separate backend which knows how to recover this dynamic + region. + + Note whenever this config is selected ramoops driver will be build statically + into kernel. + config PSTORE_ZONE tristate depends on PSTORE diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c index 88b34fdbf759..a6c0da8cfdd4 100644 --- a/fs/pstore/ram.c +++ b/fs/pstore/ram.c @@ -20,6 +20,7 @@ #include <linux/compiler.h> #include <linux/of.h> #include <linux/of_address.h> +#include <linux/memblock.h> #include <linux/mm.h> #include "internal.h" @@ -103,6 +104,55 @@ struct ramoops_context { }; static struct platform_device *dummy; +static int dyn_ramoops_size; +/* Location of the reserved area for the dynamic ramoops */ +static struct resource dyn_ramoops_res = { + .name = "ramoops", + .start = 0, + .end = 0, + .flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM, + .desc = IORES_DESC_NONE, +}; + +static int __init parse_dyn_ramoops_size(char *p) +{ + char *tmp; + + dyn_ramoops_size = memparse(p, &tmp); + if (p == tmp) { + pr_err("ramoops: memory size expected\n"); + return -EINVAL; + } + + return 0; +} +early_param("dyn_ramoops_size", parse_dyn_ramoops_size); + +#ifdef CONFIG_PSTORE_DYNAMIC_RAMOOPS_REGION_RESERVATION +/* + * setup_dynamic_ramoops() - reserves memory for dynamic ramoops + * + * This enable dynamic reserve memory support for ramoops through + * command line. + */ +void __init setup_dynamic_ramoops(void) +{ + unsigned long long ramoops_base; + unsigned long long ramoops_size; + + ramoops_base = memblock_phys_alloc_range(dyn_ramoops_size, SMP_CACHE_BYTES, + 0, MEMBLOCK_ALLOC_NOLEAKTRACE); + if (!ramoops_base) { + pr_err("cannot allocate ramoops dynamic memory (size:0x%llx).\n", + ramoops_size); + return; + } + + dyn_ramoops_res.start = ramoops_base; + dyn_ramoops_res.end = ramoops_base + dyn_ramoops_size - 1; + insert_resource(&iomem_resource, &dyn_ramoops_res); +} +#endif static int ramoops_pstore_open(struct pstore_info *psi) { @@ -915,14 +965,18 @@ static void __init ramoops_register_dummy(void) /* * Prepare a dummy platform data structure to carry the module - * parameters. If mem_size isn't set, then there are no module - * parameters, and we can skip this. + * parameters. If mem_size isn't set, check for dynamic ramoops + * size and use if it is set. */ - if (!mem_size) + if (!mem_size && !dyn_ramoops_size) return; - pr_info("using module parameters\n"); + if (dyn_ramoops_size) { + mem_size = dyn_ramoops_size; + mem_address = dyn_ramoops_res.start; + } + pr_info("using module parameters\n"); memset(&pdata, 0, sizeof(pdata)); pdata.mem_size = mem_size; pdata.mem_address = mem_address; diff --git a/include/linux/pstore_ram.h b/include/linux/pstore_ram.h index 9d65ff94e216..b3537336c4e1 100644 --- a/include/linux/pstore_ram.h +++ b/include/linux/pstore_ram.h @@ -39,4 +39,9 @@ struct ramoops_platform_data { struct persistent_ram_ecc_info ecc_info; }; +#ifdef CONFIG_PSTORE_DYNAMIC_RAMOOPS_REGION_RESERVATION +void __init setup_dynamic_ramoops(void); +#else +static inline void __init setup_dynamic_ramoops(void) {} +#endif #endif diff --git a/init/main.c b/init/main.c index e24b0780fdff..32c7d94558ec 100644 --- a/init/main.c +++ b/init/main.c @@ -99,6 +99,7 @@ #include <linux/init_syscalls.h> #include <linux/stackdepot.h> #include <linux/randomize_kstack.h> +#include <linux/pstore_ram.h> #include <net/net_namespace.h> #include <asm/io.h> @@ -895,6 +896,7 @@ void start_kernel(void) pr_notice("%s", linux_banner); early_security_init(); setup_arch(&command_line); + setup_dynamic_ramoops(); setup_boot_config(); setup_command_line(command_line); setup_nr_cpu_ids(); -- 2.7.4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-11-24 22:22 UTC|newest] Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-11-24 22:19 [Patch v6 00/12] Add Qualcomm Minidump driver related support Mukesh Ojha 2023-11-24 22:19 ` Mukesh Ojha 2023-11-24 22:19 ` [Patch v6 01/12] firmware: qcom_scm: Refactor code to support multiple dload mode Mukesh Ojha 2023-11-24 22:19 ` Mukesh Ojha 2023-11-24 22:19 ` [Patch v6 02/12] firmware/qcom: qcom_scm: Add multiple download mode support Mukesh Ojha 2023-11-24 22:19 ` Mukesh Ojha 2023-11-24 22:19 ` [Patch v6 03/12] docs: qcom: Add qualcomm minidump guide Mukesh Ojha 2023-11-24 22:19 ` Mukesh Ojha 2023-11-27 5:38 ` Bagas Sanjaya 2023-11-27 5:38 ` Bagas Sanjaya 2023-11-28 13:15 ` Bryan O'Donoghue 2023-11-28 13:15 ` Bryan O'Donoghue 2023-12-11 13:20 ` Mukesh Ojha 2023-12-11 13:20 ` Mukesh Ojha 2023-12-25 13:55 ` RESEND: " Ruipeng Qi 2023-12-25 13:55 ` Ruipeng Qi 2024-01-03 15:27 ` Mukesh Ojha 2024-01-03 15:27 ` Mukesh Ojha 2024-01-08 15:34 ` Ruipeng Qi 2024-01-08 15:34 ` Ruipeng Qi 2024-01-09 8:27 ` Mukesh Ojha 2024-01-09 8:27 ` Mukesh Ojha 2023-11-24 22:19 ` [Patch v6 04/12] soc: qcom: Add qcom_rproc_minidump module Mukesh Ojha 2023-11-24 22:19 ` Mukesh Ojha 2023-11-24 22:19 ` [Patch v6 05/12] remoteproc: qcom_q6v5_pas: Use qcom_rproc_minidump() Mukesh Ojha 2023-11-24 22:19 ` Mukesh Ojha 2023-11-24 22:19 ` [Patch v6 06/12] remoteproc: qcom: Remove minidump related data from qcom_common.c Mukesh Ojha 2023-11-24 22:19 ` Mukesh Ojha 2023-11-24 22:19 ` [Patch v6 07/12] init: export linux_banner data variable Mukesh Ojha 2023-11-24 22:19 ` Mukesh Ojha 2023-11-24 22:19 ` [Patch v6 08/12] soc: qcom: Add Qualcomm APSS minidump kernel driver Mukesh Ojha 2023-11-24 22:19 ` Mukesh Ojha 2023-11-24 22:19 ` [Patch v6 09/12] MAINTAINERS: Add entry for minidump related files Mukesh Ojha 2023-11-24 22:19 ` Mukesh Ojha 2023-11-24 22:19 ` Mukesh Ojha [this message] 2023-11-24 22:19 ` [Patch v6 10/12] pstore/ram: Add dynamic ramoops region support through commandline Mukesh Ojha 2023-11-27 11:34 ` Pavan Kondeti 2023-11-27 11:34 ` Pavan Kondeti 2023-11-28 10:32 ` Mukesh Ojha 2023-11-28 10:32 ` Mukesh Ojha 2023-11-28 16:03 ` Pavan Kondeti 2023-11-28 16:03 ` Pavan Kondeti 2023-11-24 22:19 ` [Patch v6 11/12] pstore/ram: Add ramoops ready notifier support Mukesh Ojha 2023-11-24 22:19 ` Mukesh Ojha 2023-11-27 10:10 ` Pavan Kondeti 2023-11-27 10:10 ` Pavan Kondeti 2023-11-28 11:10 ` Mukesh Ojha 2023-11-28 11:10 ` Mukesh Ojha 2023-11-24 22:19 ` [Patch v6 12/12] soc: qcom: register ramoops region with APSS minidump Mukesh Ojha 2023-11-24 22:19 ` Mukesh Ojha
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=1700864395-1479-11-git-send-email-quic_mojha@quicinc.com \ --to=quic_mojha@quicinc.com \ --cc=agross@kernel.org \ --cc=alim.akhtar@samsung.com \ --cc=andersson@kernel.org \ --cc=bmasney@redhat.com \ --cc=conor+dt@kernel.org \ --cc=corbet@lwn.net \ --cc=gpiccoli@igalia.com \ --cc=keescook@chromium.org \ --cc=kernel@quicinc.com \ --cc=kgene@kernel.org \ --cc=konrad.dybcio@linaro.org \ --cc=krzysztof.kozlowski+dt@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-arm-msm@vger.kernel.org \ --cc=linux-doc@vger.kernel.org \ --cc=linux-hardening@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mediatek@lists.infradead.org \ --cc=linux-remoteproc@vger.kernel.org \ --cc=linux-samsung-soc@vger.kernel.org \ --cc=mathieu.poirier@linaro.org \ --cc=matthias.bgg@gmail.com \ --cc=nm@ti.com \ --cc=robh+dt@kernel.org \ --cc=tony.luck@intel.com \ --cc=vigneshr@ti.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.