Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp3716350ybz; Mon, 27 Apr 2020 22:08:37 -0700 (PDT) X-Google-Smtp-Source: APiQypJ9dTEN/Mn6fpLGhrTXlN/dQ9HHztcjTByeJFyX9VeI3l7aKd/U3N1pS56esyoFFpY02r2P X-Received: by 2002:a17:906:af59:: with SMTP id ly25mr23223474ejb.65.1588050517184; Mon, 27 Apr 2020 22:08:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588050517; cv=none; d=google.com; s=arc-20160816; b=QhAiXLGnSqnigiBrIZrIeG3136bLlnXxOxllH5qL8R/tJknTJ8pRRiaQte7VZ+rexL dg8fKJtFc8d4hvbLh4mQgi9cogCFb9rJtUNkzv9adqiO3pYXRsxWLkKVBhB4WvJDYv2U e03OKJq19imKhf1jKgc6l9IjRXw4zqHV+LNYDscEe+UIlcQIVhVTR92fFxzOpnsrDAPm E0MMSrYmneZZqsb78PZ+v2wOY9vLdjt1q3ScrSRnVUSyQwRIR0YWaTLoaExd5adlc4J+ PIBsi8m/OAkFZmah8ZREcqg8yeTwj3cguZdQaaRBGFFDGeyIN12wCKHPoFcS+yFgUSQm FLdg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:content-disposition :mime-version:message-id:subject:cc:to:from:date:ironport-sdr :ironport-sdr; bh=hf6ZIohc20IBvQN6SjUTCIGV/8X+N6wZ5uzAAxSJMLE=; b=GLTk6YQ9p0B6qZEoPiacpEBiJGCZWGPrWR/eIzmKnxkh/bZcEWSdpf+R/9jZOfHxNL xTAWvdcJRVtOXvN9XViH0LWiYcPocq6cjwMfZdjxr2IrRr9QnAhZnRCW2TsUl3vy8zK4 4WEc7CDXeYHSPZOZ3afTHlGGF3Xy0W9jo2mkiv522HkGJG2HYTqrRmE3cuL30YfUE5sF XNjtDhkgv4JHE9afpzxcoJDWB2T/dBz4YQ9/qZEqhq3hRnOPFew2QUJTuodruOZ/VCaF Vi2eBGSnZyFsX15pyLgnvbrkznMEqIivnEVtK/3Vuhkgc4LFu11KmBhP7qNveEiVK0Pd tJEw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id rh26si1154751ejb.81.2020.04.27.22.08.14; Mon, 27 Apr 2020 22:08:37 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726466AbgD1FE1 (ORCPT + 99 others); Tue, 28 Apr 2020 01:04:27 -0400 Received: from mga14.intel.com ([192.55.52.115]:10411 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726042AbgD1FE1 (ORCPT ); Tue, 28 Apr 2020 01:04:27 -0400 IronPort-SDR: st8HWoiB/PiRtIxcsMIZZ+y6+xK/NiJnBbQRq2/c7UDIRubmDoh0s3+RwqOFosOVAiVdoEpiQ9 W5HBQticXTGw== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Apr 2020 22:04:26 -0700 IronPort-SDR: iPxTFM3ev1MWeMRC4aiL1oaNO47gnWGI3rOc8ZJrQ92tzn+Uf/L/rHO+D2h+9Xn5ybqKGfqhVk cxEq5b450dog== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,326,1583222400"; d="scan'208";a="302607777" Received: from yilunxu-optiplex-7050.sh.intel.com (HELO localhost) ([10.239.159.141]) by FMSMGA003.fm.intel.com with ESMTP; 27 Apr 2020 22:04:25 -0700 Date: Tue, 28 Apr 2020 13:01:35 +0800 From: Xu Yilun To: linux-fpga@vger.kernel.org Cc: linux-kernel@vger.kernel.org, mdf@kernel.org Subject: How to update a piece of flash for FPGA firmware? Message-ID: <20200428050135.GA27416@yilunxu-OptiPlex-7050> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, I wonder if an updating of FPGA Flash (but cannot reload) could be implemented as fpga-mgr? I have the pcie based FPGA card. The bitstream for FPGA static region is stored on flash chip. Board will load the bitstream to FPGA on system power cycle. The flash chip could be accessed through "PCIE -> ... -> Flash update engine -> Flash". So the update of the FPGA static region is basicly updating the flash chip through PCIE and rebooting system. Should I implement the flash update engine as a fpga-mgr device? On one hand it is just a flash write, FPGA functionality is actually not changed before reboot. Does fpga-mgr requires bitstream takes function immediately after write_complete()? On the other hand, the flash write do affects FPGA static region on next boot. Operating on the corresponding fpga region makes kernel fully aware of what is being done. Actually the FPGA card do has the capability to reload bitstream at runtime. But it will cause the whole PCIE device lost, static region is also destroyed. We need to rescan PCI to get it back. So I think basically this is the same case as system reboot from FPGA's perspective. Thanks Yilun