From patchwork Sat Mar 16 18:16:42 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Leonard Crestez X-Patchwork-Id: 13594476 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id BE011C48BF6 for ; Sat, 16 Mar 2024 18:17:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:From:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=JC9W5qj1uQxd/6lMF02J8kbKvOil3IP6g0sk8WU9Jc0=; b=yFPV986xLWKYec Dy0ds1c0bh4pZmC80MMb/BRkYsyZ+Li3LjKSvQfzSg+T2kR1uV1/uFs34urzUSIWpNfEzlyBYsSz4 oReMLnBqJzXtHNiDoqHF0gbyvvl1XkoQibLXPbFnW6N42hz3mb/dabbqGPrUQvjyGBn9zo5wOcv69 ovcRDor/6y/tM8WwZiOGdF8VmwnAU1OKCmDERT1dBYW0z4PvUkn8LPtPPZogvIsfcE9r9DSp5xY7A jqnJmsX6VmzPDnEDD6wAf9X9LkfiYUadEbyuGhLRf8RTzC+lMdiV37ZAXEgQAQZvs59rEm48sIsR1 w7TowdYn1b+1OAB7H9ug==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rlYaR-00000003ebI-2yJG; Sat, 16 Mar 2024 18:16:52 +0000 Received: from mail-ed1-x52e.google.com ([2a00:1450:4864:20::52e]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rlYaO-00000003eaD-1gcB for linux-arm-kernel@lists.infradead.org; Sat, 16 Mar 2024 18:16:49 +0000 Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-568c51f44e5so419710a12.0 for ; Sat, 16 Mar 2024 11:16:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710613005; x=1711217805; darn=lists.infradead.org; h=content-transfer-encoding:content-language:cc:to:subject:from :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=3BQo86H+KKL2iQUpe5TXdIwdHBfwFbjXE7p1G/QNwns=; b=OT/7Db7YBsPrdTiniHbaaeTlw3f1eEDRMGjXcgaXe3UdfXttEk23/WdZm3K+4YY9GP ecVUyOrE4GpigA0r7KQIDLIpSaHXh9oX6BlxD2IjRv9EcQhw4ZYU1aF0wPreZH1N0DUK pHiIeaa2CWfoao5wEcnG6wUhFgFoSQPd0GTeLjZH+uTrwcB6jeIsFvpY2O1NSki92biO Mh/xxFvOq46vXGjP9Q5wdZ7+vJk5tSSfKkprlWXSf3eOizDD3XTna0NDO5KWvits2VZd YdGTf51pbs4j0lGCHg92UPUhC+ibIaD8ur63m35h5W599i22MTHTTKfl8toCqDXK5E2f Xj+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710613005; x=1711217805; h=content-transfer-encoding:content-language:cc:to:subject:from :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=3BQo86H+KKL2iQUpe5TXdIwdHBfwFbjXE7p1G/QNwns=; b=Aeqt/rUK8D5OU0i6E5iX7o3hRTXJtVEoMtB+aOFGBe5YyZcDA/8r1iJeoWLerRPfCs ZhSzUho2Yo1HSmAUaDiEvIYsFiX0xL/kpfAwbzrcJaROCuRmSmZhcV8pEYITJGK26hq3 nqi2+AQo67jOdQMKfhxhvJm3OpDE01Iws1RfTeZRD3ee6U45EgLHdiu61HPYmnsQ9/Dk 10EVUrjuH1DqWPJyJJEpWzLnoZsXrPlF5VAGI3LYMBZMxyQs87TQEOK00zrH1URlmAQ8 8sW/1jKWy0juvkTVJ95tPj8TtQRs1MMIJDVI4jHr2/PKr7kLVzkjRXZVtJKalWcb6fQQ xQ3A== X-Forwarded-Encrypted: i=1; AJvYcCWxXr17qKfps4plIO0uGV9WIt7dbd6q86GcdcW8XEenQLfeWq23OfuWTMDWU2+zSySpr1E91/mZCdpWge5PKsiFhLHmrO8ZtVx1NT6PwxM9zTDJiLY= X-Gm-Message-State: AOJu0Yy52L6Yxe70rcxxLVSDAniV3uuABVV7N2Wr2s9QZgs2P3KD+nmM p+DEluNh5ypUVst2lxaRisOPQVtMpl9I3EtV9VmI/UUw5WUJkj2U X-Google-Smtp-Source: AGHT+IEz0dVihumTjQvKXWaGYzSYaEM+ZgX/kWUB5N7UIRpD91MBvWDGamkrTuYAMHnwc07WagkUXA== X-Received: by 2002:a17:906:874d:b0:a46:11a9:430 with SMTP id hj13-20020a170906874d00b00a4611a90430mr5181284ejb.76.1710613004848; Sat, 16 Mar 2024 11:16:44 -0700 (PDT) Received: from ?IPV6:2a04:241e:501:580:d03e:506b:69fb:b04c? ([2a04:241e:501:580:d03e:506b:69fb:b04c]) by smtp.gmail.com with ESMTPSA id jx25-20020a170907761900b00a4503a78dd5sm3025404ejc.17.2024.03.16.11.16.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 16 Mar 2024 11:16:44 -0700 (PDT) Message-ID: Date: Sat, 16 Mar 2024 20:16:42 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Leonard Crestez Subject: [PATCH] remoteproc: zynqmp: Add coredump support To: Tanmay Shah , Mathieu Poirier Cc: Bjorn Andersson , Michal Simek , Sarangdhar Joshi , Siddharth Gupta , Rishabh Bhatnagar , linux-remoteproc@vger.kernel.org, linux-arm-kernel@lists.infradead.org Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240316_111648_499668_2685B836 X-CRM114-Status: GOOD ( 15.38 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Supporting remoteproc coredump requires the platform-specific driver to register coredump segments to be dumped. Do this by calling rproc_coredump_add_segment for every carveout. Also call rproc_coredump_set_elf_info when then rproc is created. If the ELFCLASS parameter is not provided then coredump fails with an error. Other drivers seem to pass EM_NONE for the machine argument but for me this shows a warning in gdb. Pass EM_ARM because this is an ARM R5. Signed-off-by: Leonard Crestez --- Tests were done by triggering an deliberate crash using remoteproc debugfs: echo 2 > /sys/kernel/debug/remoteproc/remoteproc0/crash This was tested using RPU apps which use RAM for everything so TCM dump was not verified. The freertos-gdb script package showed credible data: https://github.com/espressif/freertos-gdb The R5 cache is not flushed so RAM might be out of date which is actually very bad because information most relevant to determining the cause of a crash is lost. Possible workaround would be to flush caches in some sort of R5 crash handler? I don't think Linux can do anything about this limitation. The generated coredump doesn't contain registers, this seems to be a limitation shared with other rproc coredumps. It's not clear how the apu could access rpu registers on zynqmp, my only idea would be to use the coresight dap but that sounds difficult. --- drivers/remoteproc/xlnx_r5_remoteproc.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c b/drivers/remoteproc/xlnx_r5_remoteproc.c index 4395edea9a64..cfbd97b89c26 100644 --- a/drivers/remoteproc/xlnx_r5_remoteproc.c +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c @@ -484,10 +484,11 @@ static int add_mem_regions_carveout(struct rproc *rproc) of_node_put(it.node); return -ENOMEM; } rproc_add_carveout(rproc, rproc_mem); + rproc_coredump_add_segment(rproc, rmem->base, rmem->size); dev_dbg(&rproc->dev, "reserved mem carveout %s addr=%llx, size=0x%llx", it.node->name, rmem->base, rmem->size); i++; } @@ -595,10 +596,11 @@ static int add_tcm_carveout_split_mode(struct rproc *rproc) zynqmp_pm_release_node(pm_domain_id); goto release_tcm_split; } rproc_add_carveout(rproc, rproc_mem); + rproc_coredump_add_segment(rproc, da, bank_size); } return 0; release_tcm_split: @@ -674,10 +676,11 @@ static int add_tcm_carveout_lockstep_mode(struct rproc *rproc) goto release_tcm_lockstep; } /* If registration is success, add carveouts */ rproc_add_carveout(rproc, rproc_mem); + rproc_coredump_add_segment(rproc, da, bank_size); dev_dbg(dev, "TCM carveout lockstep mode %s addr=0x%llx, da=0x%x, size=0x%lx", bank_name, bank_addr, da, bank_size); } @@ -851,10 +854,12 @@ static struct zynqmp_r5_core *zynqmp_r5_add_rproc_core(struct device *cdev) if (!r5_rproc) { dev_err(cdev, "failed to allocate memory for rproc instance\n"); return ERR_PTR(-ENOMEM); } + rproc_coredump_set_elf_info(r5_rproc, ELFCLASS32, EM_ARM); + r5_rproc->auto_boot = false; r5_core = r5_rproc->priv; r5_core->dev = cdev; r5_core->np = dev_of_node(cdev); if (!r5_core->np) {