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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id BA9E3C7EE22 for ; Tue, 9 May 2023 18:30:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232313AbjEISar (ORCPT ); Tue, 9 May 2023 14:30:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53192 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229484AbjEISaq (ORCPT ); Tue, 9 May 2023 14:30:46 -0400 Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9E4C3107 for ; Tue, 9 May 2023 11:30:45 -0700 (PDT) Received: by mail-yb1-xb2c.google.com with SMTP id 3f1490d57ef6-ba2362d4ea9so3238230276.3 for ; Tue, 09 May 2023 11:30:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1683657045; x=1686249045; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=cQ5hIfVGYt176X0mmh5Nxb3U1ww7Q7ORWMM97Hft4mM=; b=VjqJEnqzTkEZ4iHn5ydijXymdY8/PV8bwyjXe+lzA3PjZfKpJ8NjCIR2auQ/yWySh6 ez1BUZukd6Xe9G6E6C2E+046wP2yVXKEmbXOaXCbEzKQITPhFpeGTZ3fkHkwTzKR6MYN DUSVuUlscFmiptusPeEEDTQfX6ggVPePqlPcm9wLs2h423+rsZRL7r+POmNERu+u0op2 1bOwKAxlp4EP8SWOHg64z/c8oIY0BACcnNcfgoqlEvteOObaTHDywjJV1VnipYuZeYkY 1xyJU0CXqrOJDLvONs7qFLrjVA2J0DyTrcKNe6TaIsg/RBT6o3qSpKnKaXW3XWcYAM9S qGMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683657045; x=1686249045; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=cQ5hIfVGYt176X0mmh5Nxb3U1ww7Q7ORWMM97Hft4mM=; b=LZPVuk0Gx8cz5Ii3DaXLnZSLLKKHGIEHWmn5MnR02Hx2mv0LfgTXChdGpMmcFdo3Wd 58mau/0AuQklY6Qm2GglL+1J8FhcNaY2cpHSZAz13s6EV9fWD1vtIn+UXIGd+E+uJONZ CngB1gpjBeCjw9byq1NANiq1GDoMuF4q5PaxMGsJsd4Q3wS05NtK1OXJNl0YjnNAG202 ZqGE/HYcASU8PNpVjUY8gB1c+LWw6C24wUs8+ZI6khP1/FbmE6UajD23AY9hIkqeQ94n RcghAaWEDrILOlYO1pwNwkQzljLs2gld+UIWGm25oCQOJ1SZTbg7SeGXSaUtN+fFslAI ePGg== X-Gm-Message-State: AC+VfDx1fKRf6XLwoua5uSDPyw+c2bF/QQI8Pt6JmQbpvMPyKEbyjUmZ agWPDrEMNNKOOxsw1m3DezcTXRSgX4ho5N/DKdCA0g== X-Google-Smtp-Source: ACHHUZ64WObK4alO23JU4r2bWXEcbsP3Y6beKyvnef7Og3R6aLy+mmjR1HujeuofX7PzFky5/HHtl4QtPES8PUPQ3To= X-Received: by 2002:a25:c549:0:b0:b97:4b7b:945c with SMTP id v70-20020a25c549000000b00b974b7b945cmr17021207ybe.57.1683657044881; Tue, 09 May 2023 11:30:44 -0700 (PDT) MIME-Version: 1.0 References: <20230506-seama-partitions-v1-0-5806af1e4ac7@linaro.org> <20230509093129.40b30c7a@xps-13> In-Reply-To: <20230509093129.40b30c7a@xps-13> From: Linus Walleij Date: Tue, 9 May 2023 20:30:33 +0200 Message-ID: Subject: Re: [PATCH 0/2] Add SEAMA partition types To: Miquel Raynal Cc: Richard Weinberger , Vignesh Raghavendra , Rob Herring , Krzysztof Kozlowski , Florian Fainelli , Hauke Mehrtens , =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= , Broadcom internal kernel review list , linux-mtd@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Tue, May 9, 2023 at 9:31=E2=80=AFAM Miquel Raynal wrote: > linus.walleij@linaro.org wrote on Sat, 06 May 2023 17:29:43 +0200: > > > This type of firmware partition appear in some devices in > > NAND flash, so we need to be able to tag the partitions > > with the appropriate type. > > > > The origin of the "SEAttle iMAge" is unknown. > > I don't see any kernel changes, why do we need an additional binding? The bindings are not strictly bound to Linux, it's more like all OS:es uses the Linux DT binding repo because it is the biggest project. Also we actually merge a bunch of bindings just to describe hardware (or things like partitions), in the hope of making use of them in the long run. Anyways, for the record, the full story: Currently this binding is used in out-of-tree OpenWrt code, where it is used as magic for splitting partitions with mtdsplit. I guess you might be familiar with mtdsplit. It is a software partition splitter that makes it possible to split a big partition into smaller partitions dynamically, using magic block identifiers. The typical usecase is to put the kernel in the first flash blocks, then pad up to the nearest even erase block, and then add a JFFS2 or UBI filesystem immediately there. This way it avoids using static partitioning, the tools rebuilding the firmware can dynamically split off more flash as the kernel image grows. The mtdsplit code uses different magic numbers to identify where the different partitions start. One such type of partition is seama, so the code needs to know that it should look for seama magic to determine the size and split this partition in a kernel and rootfs part. This is the code: https://git.openwrt.org/?p=3Dopenwrt/openwrt.git;a=3Dtree;f=3Dtarget/linux/= generic/files/drivers/mtd/mtdsplit;h=3D3e0df856713a84b1decf17190f171cb10ce7= a757;hb=3DHEAD It is a bit sad that no-one has the energy to propose mtdsplit upstream, I think it is quite generic and generally useful. I started to make an upstream patch but got exhausted with the task. Yours, Linus Walleij