Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp1691529pxb; Fri, 20 Aug 2021 11:27:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxYqdgRwN/WkNj4BttrMTyalHju7TE5yFRhg6P6eztq3pF7+/aGG2bOecDum2T5xXsSM5Kg X-Received: by 2002:a05:6e02:eb0:: with SMTP id u16mr14524212ilj.303.1629484028097; Fri, 20 Aug 2021 11:27:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1629484028; cv=none; d=google.com; s=arc-20160816; b=U3f03GohFZrRKlm+QS5ElzkQear2Sj0rab06d1qSbOW38KIoCoUv3xvZD632c3mAJs k26O2PxodAsQ4c2we77bnTmAqeOtWRLDKDav1s1iI2GWSWWyg657gW0T+Ne5GiehzpFo Tff1fDoW61oC0YXOZwWQFD8Oj3fHz9qZndSWjv/NT7hOjJjE3sOmKOGY+ofAjuPVSpOH o+1kqLEs6E6XA9egR+niiWbWte5TWKhOPPDhZrcEm4Epham+qlnHbXcOWyv0J1fKYTzn qzInKYepYKOvCP28xjldluxHJolNHRqyvKJgvdLoRxaJyE9WE0P1aWjBRETqiTiy4CLi z4MQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=tF/rYLQ+DtMioyJLcb3Pd0DjkRnK2a1fMohMiDkI93E=; b=lN1pyGDZ/prRdecXRQQh3qW5nc7KrfCSMrsiu63ae2eqHLTV6s+fYtjbS6WllkX8EB kQ31sMgv+wkspdqblb91nw1Iifcwz362jX7XWUR2MQl5jCdwm/6TEfjj9vA5+soqYIcr dlJH9WH6fRfmdj5519VtS2i9AaDC7q5iBm0JRNfF1Ki62j9qXevYC/ZeljmHPjvHtNsL OL0YJ0gDlU4PBztEn4WmP3B+Hz7ZXpp6iNby0VXnNIM0TFMia9wh5FRT+78RSguKpjWq /5qSYcGOsG4taAN0wFc34EAVuWtUw8ZsOOjSTzTwbNYf+NVqiXo6PbAg2XmPrad9hCkt Aajw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=BiEuWlvz; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p14si2902819iov.81.2021.08.20.11.26.55; Fri, 20 Aug 2021 11:27:08 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=BiEuWlvz; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236855AbhHTSZo (ORCPT + 99 others); Fri, 20 Aug 2021 14:25:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33918 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237068AbhHTSZl (ORCPT ); Fri, 20 Aug 2021 14:25:41 -0400 Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0EBFFC061757; Fri, 20 Aug 2021 11:25:03 -0700 (PDT) Received: by mail-ej1-x62f.google.com with SMTP id lo4so21871492ejb.7; Fri, 20 Aug 2021 11:25:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=tF/rYLQ+DtMioyJLcb3Pd0DjkRnK2a1fMohMiDkI93E=; b=BiEuWlvzwz1TCjxw7PuZdooB500Q4kzhIVUdIw3j2f/DYzySsEKyZHNG2apBbVlKd+ S26tsKYb7CsPo4zgHSDtIzzYo00dcDHQDbnFmVFdGK44zilVcYPK8XbkEB0+pAMq50gC d4YZBHWkvFVZ1yHzBrmK/INfta5lh00UQTLjmPTz3Re3NlPs/oYT0HjmIRtpJk9TkiFY Ff3JYakC6Th0dSUjZssoBQ2UgXVUbcjpBstZ0r2py3h3LhDGnPij8AaFsW7zcw+tcLVo zI2dNXaeDh/LXQFbqvCN37iujdclM04i7cO/IY7dB1QRo+tCfc6BeP1HEMzkhkiqk5GF mnDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=tF/rYLQ+DtMioyJLcb3Pd0DjkRnK2a1fMohMiDkI93E=; b=QhiQ7UkRthAV6ciqLJ+dcblB1xVXsT2zPsF4q8k7vapFhRPEEvvW888z0VMLlbYGmL BI0D3DEU7qyE5f2+C2xJSr+aIEbGxgXc7QDylBIVP41dqplK1l2uxQ+beI9ebxXQrNWU F1VJCpJwmYKu9f7d6cGG97rDIKpfSPetqLC8VYoRT7dJRpaZ+62tsUpPW7B9ErEwrbUg A/sPFG1g8SeeorujhIYAyUwdbtW6khHUd/IfLvDlAmUvcnl3Q4DxU3Nl3ZjY4ykNshau BluswgcMTrNCE2t5tO4L/J0ybK1MZy5soOqX2aGfmL8PG/SFcmBf1qEmqAFfQ/TU91p/ K1xQ== X-Gm-Message-State: AOAM5320xObBdtNTp8IVXBK5yVrUCyiksfwIBM4txTZScT67FIGdlGht yeNesY2vV3RORZBI3/7NEv0PQ43mqx4wBPrjUrM5a/kgPfbR9Q== X-Received: by 2002:a17:907:1043:: with SMTP id oy3mr3902073ejb.116.1629483901606; Fri, 20 Aug 2021 11:25:01 -0700 (PDT) MIME-Version: 1.0 References: <1556211076.48404.1626763215205.JavaMail.zimbra@nod.at> <2132615832.4458.1626900868118.JavaMail.zimbra@nod.at> <1668790824.35266.1627559144878.JavaMail.zimbra@nod.at> In-Reply-To: From: Pintu Agarwal Date: Fri, 20 Aug 2021 23:54:50 +0530 Message-ID: Subject: Re: MTD: How to get actual image size from MTD partition To: Ezequiel Garcia Cc: Richard Weinberger , Kernelnewbies , Greg KH , linux-kernel , linux-mtd , Sean Nyekjaer , linux-fsdevel , Phillip Lougher Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 29 Jul 2021 at 22:41, Pintu Agarwal wrote: > > On Thu, 29 Jul 2021 at 17:33, Ezequiel Garcia > wrote: > > > > On Thu, 29 Jul 2021 at 08:45, Richard Weinberger wrote= : > > > > > > Ezequiel, > > > > > > ----- Urspr=C3=BCngliche Mail ----- > > > > [snip] > > > > > > > > Ouch, so surprised that after all these years someone is doing squa= shfs/mtdblock > > > > instead of using ubiblock :-) > > > > > > > > Can we patch either Kconfig or add some warn_once on mtdblock > > > > usage, suggesting to use ubiblock instead? > > > > > > a hint in Kconfig makes IMHO sense. Do you want to send a patch? > > > A warning is too much since on some tiny embedded system with NOR fla= sh mtdblock is still > > > a good choice. > > > ubiblock is mostly useful for NAND flash. > > > > > > > I remember there was still some use case(s) for mtdblock but I can'= t remember > > > > now what was it, perhaps we should document the expectations? > > > > (Is that for JFFS2 to mount?) > > > > > > a long time ago mount didn't accept character devices, so you had to = pass mtdblockX to mount > > > JFFS2. > > > This limitation is gone. > > > Hi, Just a further follow-up on this discussion. Whether to use /dev/mtdblock or /dev/ubiblock for rootfs (squashfs) mounting during boot. As suggested here: Instead of using this in kernel command line: [ 0.000000] Kernel command line: ... rootfstype=3Dsquashfs root=3D/dev/mtdblock44 ubi.mtd=3D40,0,30 ... I used this: [ 0.000000] Kernel command line: ... rootfstype=3Dsquashfs ubi.mtd=3D40,0,30 ubi.block=3D0,0 root=3D/dev/ubiblock0_0 ... The device is booting fine with ubiblock as well. But, per say, I could not find any visible difference. I just observed a slight improvement in boot time, but I need to double-check on this, with few more reboot cycles. Apart from this what are the other visible benefits of using ubiblock which can be explained to be management or internal team ? I could not find any documentation explaining the difference, except this o= ne: http://www.linux-mtd.infradead.org/doc/ubi.html#L_ubiblock Can someone also point me to the respective driver code in case of using /dev/mtdblock and /dev/ubiblock ? Apart from theory I also want to check the impact at the code level.. Thanks, Pintu