From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2125CC12002 for ; Fri, 16 Jul 2021 07:16:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 01FCA613E9 for ; Fri, 16 Jul 2021 07:16:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235737AbhGPHTJ convert rfc822-to-8bit (ORCPT ); Fri, 16 Jul 2021 03:19:09 -0400 Received: from lithops.sigma-star.at ([195.201.40.130]:48144 "EHLO lithops.sigma-star.at" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235689AbhGPHTJ (ORCPT ); Fri, 16 Jul 2021 03:19:09 -0400 Received: from localhost (localhost [127.0.0.1]) by lithops.sigma-star.at (Postfix) with ESMTP id 8AD12616B568; Fri, 16 Jul 2021 09:16:13 +0200 (CEST) Received: from lithops.sigma-star.at ([127.0.0.1]) by localhost (lithops.sigma-star.at [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id wXv3S29yopAW; Fri, 16 Jul 2021 09:16:13 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by lithops.sigma-star.at (Postfix) with ESMTP id 2C4C56169BB9; Fri, 16 Jul 2021 09:16:13 +0200 (CEST) Received: from lithops.sigma-star.at ([127.0.0.1]) by localhost (lithops.sigma-star.at [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id tSjbk7sNumXT; Fri, 16 Jul 2021 09:16:13 +0200 (CEST) Received: from lithops.sigma-star.at (lithops.sigma-star.at [195.201.40.130]) by lithops.sigma-star.at (Postfix) with ESMTP id F31C9616B568; Fri, 16 Jul 2021 09:16:12 +0200 (CEST) Date: Fri, 16 Jul 2021 09:16:12 +0200 (CEST) From: Richard Weinberger To: Pintu Agarwal Cc: linux-kernel , linux-mtd , linux-fsdevel , Phillip Lougher , Sean Nyekjaer , Kernelnewbies Message-ID: <456614823.32530.1626419772792.JavaMail.zimbra@nod.at> In-Reply-To: References: Subject: Re: MTD: How to get actual image size from MTD partition MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-Originating-IP: [195.201.40.130] X-Mailer: Zimbra 8.8.12_GA_3807 (ZimbraWebClient - FF78 (Linux)/8.8.12_GA_3809) Thread-Topic: How to get actual image size from MTD partition Thread-Index: wRfeFLQcDSd8DiGHIt8B6zS4rgdF6w== Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org Pintu, ----- Ursprüngliche Mail ----- > Von: "Pintu Agarwal" > My requirement: > To find the checksum of a real image in runtime which is flashed in an > MTD partition. > > Problem: > Currently, to find the checksum, we are using: > $ md5sum /dev/mtd14 > This returns the proper checksum of the entire partition. > But we wanted to find the checksum only for the actual image data > which will be used by our C utility to validate the image. > Here, we don't know the actual image size. > We only know the "partition-size" and "erasesize". > > So, is there a mechanism to somehow find the image size at runtime? not really, UBI manages the MTD and does wearleveling, auto growing of volumes, etc... So as soon you attach the image once, it is changed and the checksum won't match. It may work if you don't attach UBI and your flash program tool keeps track of what pages it wrote. Thanks, //richard