Message ID | 20230424123522.18302-23-nikita.shubin@maquefel.me |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp2637763vqo; Mon, 24 Apr 2023 03:23:32 -0700 (PDT) X-Google-Smtp-Source: AKy350YeZBNJ4a52GMcNKJZoetX9dX5MAjfizM19GfxM2RK6D9PPV6gM7Q7zGdglKmAKo3XM7erw X-Received: by 2002:a05:6a20:7345:b0:db:22dc:23d with SMTP id v5-20020a056a20734500b000db22dc023dmr18366363pzc.5.1682331812138; Mon, 24 Apr 2023 03:23:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1682331812; cv=none; d=google.com; s=arc-20160816; b=Ax5wUGoTQ6+BnxnV+eK8WOqj06liXK41c1Zwg5liqZ420ZiQrPc0NEho5jlTml4j8S UTPBQ8mzEd2UWTldGBgoKHWl5cY36V7hP48f86Ow1CKgqw8vVX4VVtTG6D05k5AhEArp AzflLg9HNqxE26SHFUkfrCDyHeRfFaB/EaS+FujaLkQNOd1UhsA7d19sMHEnTJ5kKnHD 7rNFFUbppgRDjgnXRKCwiE421ovEbUEXJr3IFoSeQcFk0G4CoQJjkKyBS6owyK0PU7g9 RrrSZNokcalSChDmpbtsVG+bFAtK+erJcMuxYsySUQkv/mVSM25N5w3cYQNtK0nZyrdr sh6Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:to:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:from :dkim-signature; bh=gzZfNhCP4gLQxuxIz1zy8IGUwOFk5Um/gkdDTo4axVY=; b=F00oNAyz2rXy029yvS0JoE+o96IOpCesy1eJgdOloOvKS9br+XFtC38UugM+/L+WQN nH/nb90Q6sGVBAUWA6R9qKzCuBt+hAxf6HES7qZQ5I0/yMpZxO73dkwOgmgW6jl/eGxx tKfittfv+KWBjFpHYQXz2DJeSmMIEoimN3Ip8P7nPSAZL9CLM59o58VmB5v4YUJKrVtO lvxk++MUkMy7MsmiBIuzDZCtAtMwBeAKDISEIQEc2DVD73BzUZG0aA1ztpLH7O/nVYVu baiR9RnbYxIaOwfvkImbUCYjkvT+s9DR2977xX1ZK9hkcrpu3JvYLKhT4es4LMbJA5cJ lFuw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@maquefel.me header.s=mail header.b=caqZCqDL; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id a1-20020aa794a1000000b0063d2561a285si10970628pfl.152.2023.04.24.03.23.20; Mon, 24 Apr 2023 03:23:32 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=fail header.i=@maquefel.me header.s=mail header.b=caqZCqDL; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231637AbjDXKVL (ORCPT <rfc822;zxc52fgh@gmail.com> + 99 others); Mon, 24 Apr 2023 06:21:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44286 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231558AbjDXKUm (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 24 Apr 2023 06:20:42 -0400 Received: from forward501c.mail.yandex.net (forward501c.mail.yandex.net [178.154.239.209]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2A3AD1FEE; Mon, 24 Apr 2023 03:20:41 -0700 (PDT) Received: from mail-nwsmtp-smtp-production-main-39.myt.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-39.myt.yp-c.yandex.net [IPv6:2a02:6b8:c12:261e:0:640:2e3d:0]) by forward501c.mail.yandex.net (Yandex) with ESMTP id 472855ECEC; Mon, 24 Apr 2023 12:35:55 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-39.myt.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id JZBb1pbWwKo0-2xt778SJ; Mon, 24 Apr 2023 12:35:54 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=maquefel.me; s=mail; t=1682328954; bh=gzZfNhCP4gLQxuxIz1zy8IGUwOFk5Um/gkdDTo4axVY=; h=Message-Id:Date:In-Reply-To:Cc:Subject:References:To:From; b=caqZCqDLVch5A8ypmNCfIAMmaENWkpVFbRauIda656kQ6KQThwDcE991Cawuw51ul AbXrWBNhpvkR7BsGW5b5ohmYThfKk4TDk4Qf5/3xZSL33tgiLyM+HtmaSe+33VREX1 /DbEUmHjj35NZzYFsT+cb1Zyn1hbCY231hA3Dpxg= Authentication-Results: mail-nwsmtp-smtp-production-main-39.myt.yp-c.yandex.net; dkim=pass header.i=@maquefel.me From: Nikita Shubin <nikita.shubin@maquefel.me> Cc: Arnd Bergmann <arnd@kernel.org>, Linus Walleij <linusw@kernel.org>, Alexander Sverdlin <alexander.sverdlin@gmail.com>, Miquel Raynal <miquel.raynal@bootlin.com>, Richard Weinberger <richard@nod.at>, Vignesh Raghavendra <vigneshr@ti.com>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Lukasz Majewski <lukma@denx.de>, linux-mtd@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH 22/43] dt-bindings: mtd: add DT bindings for ts7250 nand Date: Mon, 24 Apr 2023 15:34:38 +0300 Message-Id: <20230424123522.18302-23-nikita.shubin@maquefel.me> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20230424123522.18302-1-nikita.shubin@maquefel.me> References: <20230424123522.18302-1-nikita.shubin@maquefel.me> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net To: unlisted-recipients:; (no To-header on input) Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1764052761953306758?= X-GMAIL-MSGID: =?utf-8?q?1764052761953306758?= |
Series |
ep93xx device tree conversion
|
|
Commit Message
Nikita Shubin
April 24, 2023, 12:34 p.m. UTC
Add YAML bindings for ts7250 NAND.
Signed-off-by: Nikita Shubin <nikita.shubin@maquefel.me>
---
.../bindings/mtd/technologic,nand.yaml | 56 +++++++++++++++++++
1 file changed, 56 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/technologic,nand.yaml
Comments
On Mon, Apr 24, 2023 at 03:34:38PM +0300, Nikita Shubin wrote: > Add YAML bindings for ts7250 NAND. > > Signed-off-by: Nikita Shubin <nikita.shubin@maquefel.me> > --- > .../bindings/mtd/technologic,nand.yaml | 56 +++++++++++++++++++ > 1 file changed, 56 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mtd/technologic,nand.yaml > > diff --git a/Documentation/devicetree/bindings/mtd/technologic,nand.yaml b/Documentation/devicetree/bindings/mtd/technologic,nand.yaml > new file mode 100644 > index 000000000000..3234d93a1c21 > --- /dev/null > +++ b/Documentation/devicetree/bindings/mtd/technologic,nand.yaml > @@ -0,0 +1,56 @@ > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/mtd/technologic,nand.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Technologic Systems NAND controller > + > +maintainers: > + - Lukasz Majewski <lukma@denx.de> > + > +properties: > + compatible: > + items: > + - const: technologic,ts7200-nand > + - const: gen_nand Not a useful compatible. > + > + reg: > + maxItems: 1 > + > + '#address-cells': true > + '#size-cells': true > + > +required: > + - compatible > + - reg > + > +unevaluatedProperties: true No, 'true' is not allowed here. > + > +examples: > + - | > + nand-parts@0 { > + compatible = "technologic,ts7200-nand", "gen_nand"; > + reg = <0x60000000 0x8000000>; > + #address-cells = <1>; > + #size-cells = <1>; > + > + partition@0 { > + label = "TS-BOOTROM"; > + reg = <0x00000000 0x00020000>; > + read-only; > + }; > + > + partition@20000 { > + label = "Linux"; > + reg = <0x00020000 0x07d00000>; > + }; > + > + partition@7d20000 { > + label = "RedBoot"; > + reg = <0x07d20000 0x002e0000>; > + read-only; > + }; > + }; > + > +... > -- > 2.39.2 >
Hi Nikita, nikita.shubin@maquefel.me wrote on Mon, 24 Apr 2023 15:34:38 +0300: > Add YAML bindings for ts7250 NAND. > > Signed-off-by: Nikita Shubin <nikita.shubin@maquefel.me> > --- > .../bindings/mtd/technologic,nand.yaml | 56 +++++++++++++++++++ > 1 file changed, 56 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mtd/technologic,nand.yaml > > diff --git a/Documentation/devicetree/bindings/mtd/technologic,nand.yaml b/Documentation/devicetree/bindings/mtd/technologic,nand.yaml > new file mode 100644 > index 000000000000..3234d93a1c21 > --- /dev/null > +++ b/Documentation/devicetree/bindings/mtd/technologic,nand.yaml > @@ -0,0 +1,56 @@ > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/mtd/technologic,nand.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Technologic Systems NAND controller > + > +maintainers: > + - Lukasz Majewski <lukma@denx.de> > + > +properties: > + compatible: > + items: > + - const: technologic,ts7200-nand would -nand-controller instead of -nand work as a suffix here? You mention ts7250 in the title, should we have a more specific compatible than ts7200 as well? I see by looking at the mtd patch that you actually try to match both, so they should both be defined in the bindings. > + - const: gen_nand This is a old hack for very simple controllers (converted to DT probing 12 years ago). The logic used by this driver has been deprecated for like 10 years and does not really apply to modern APIs. I would really like to keep this driver contained with platform data coming from arch/ data only. I suggest you create a real NAND controller driver based on the generic one (should not be very complex, just duplicate the code so the migration to the up-to-date API is eased) and you flag it as "must be updated to ->exec_op() somehow. This way if someone starts the conversion, it does not need to cope with the 5 other users of the generic driver which anyway share nothing in common besides the deprecated ->cmd_ctrl() backbone. I read the comments on the cover letter, people are kind of pushing on having this merged quickly. I am fine accepting a legacy controller driver and migrating it to ->exec_op() later, but the current driver conversion does not fit the approach taken years ago towards a cleaner mtd tree. > + > + reg: > + maxItems: 1 > + > + '#address-cells': true > + '#size-cells': true > + > +required: > + - compatible > + - reg > + > +unevaluatedProperties: true > + > +examples: > + - | > + nand-parts@0 { > + compatible = "technologic,ts7200-nand", "gen_nand"; > + reg = <0x60000000 0x8000000>; > + #address-cells = <1>; > + #size-cells = <1>; > + > + partition@0 { > + label = "TS-BOOTROM"; > + reg = <0x00000000 0x00020000>; > + read-only; > + }; Partitions are not useful here, but if you want them, use the partitions container instead, please. > + > + partition@20000 { > + label = "Linux"; > + reg = <0x00020000 0x07d00000>; > + }; > + > + partition@7d20000 { > + label = "RedBoot"; > + reg = <0x07d20000 0x002e0000>; > + read-only; > + }; > + }; > + > +... Thanks, Miquèl
Hello Miquel! Thank you for looking into it. On Tue, 2023-05-02 at 11:48 +0200, Miquel Raynal wrote: > Hi Nikita, > > nikita.shubin@maquefel.me wrote on Mon, 24 Apr 2023 15:34:38 +0300: > > > Add YAML bindings for ts7250 NAND. > > > > Signed-off-by: Nikita Shubin <nikita.shubin@maquefel.me> > > --- > > .../bindings/mtd/technologic,nand.yaml | 56 > > +++++++++++++++++++ > > 1 file changed, 56 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/mtd/technologic,nand.yaml > > > > diff --git > > a/Documentation/devicetree/bindings/mtd/technologic,nand.yaml > > b/Documentation/devicetree/bindings/mtd/technologic,nand.yaml > > new file mode 100644 > > index 000000000000..3234d93a1c21 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/mtd/technologic,nand.yaml > > @@ -0,0 +1,56 @@ > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/mtd/technologic,nand.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Technologic Systems NAND controller > > + > > +maintainers: > > + - Lukasz Majewski <lukma@denx.de> > > + > > +properties: > > + compatible: > > + items: > > + - const: technologic,ts7200-nand > > would -nand-controller instead of -nand work as a suffix here? > > You mention ts7250 in the title, should we have a more specific > compatible than ts7200 as well? > > I see by looking at the mtd patch that you actually try to match > both, > so they should both be defined in the bindings. > > > + - const: gen_nand > > This is a old hack for very simple controllers (converted to DT > probing > 12 years ago). The logic used by this driver has been deprecated for > like 10 years and does not really apply to modern APIs. I would > really > like to keep this driver contained with platform data coming from > arch/ > data only. > > I suggest you create a real NAND controller driver based on the > generic one (should not be very complex, just duplicate the code so > the > migration to the up-to-date API is eased) and you flag it as "must be > updated to ->exec_op() somehow. This way if someone starts the > conversion, it does not need to cope with the 5 other users of the > generic driver which anyway share nothing in common besides the > deprecated ->cmd_ctrl() backbone. > > I read the comments on the cover letter, people are kind of pushing > on > having this merged quickly. I am fine accepting a legacy controller > driver and migrating it to ->exec_op() later, but the current driver > conversion does not fit the approach taken years ago towards a > cleaner > mtd tree. Did you mean that i should at least implement legacy nand controller, like, for example, Xway (xway_nand.c) ?: data->chip.legacy.cmd_ctrl = xway_cmd_ctrl; data->chip.legacy.dev_ready = xway_dev_ready; data->chip.legacy.select_chip = xway_select_chip; data->chip.legacy.write_buf = xway_write_buf; data->chip.legacy.read_buf = xway_read_buf; data->chip.legacy.read_byte = xway_read_byte; data->chip.legacy.chip_delay = 30; And the best solution would be switching to exec_op completely ? > > > + > > + reg: > > + maxItems: 1 > > + > > + '#address-cells': true > > + '#size-cells': true > > + > > +required: > > + - compatible > > + - reg > > + > > +unevaluatedProperties: true > > + > > +examples: > > + - | > > + nand-parts@0 { > > + compatible = "technologic,ts7200-nand", "gen_nand"; > > + reg = <0x60000000 0x8000000>; > > + #address-cells = <1>; > > + #size-cells = <1>; > > + > > + partition@0 { > > + label = "TS-BOOTROM"; > > + reg = <0x00000000 0x00020000>; > > + read-only; > > + }; > > Partitions are not useful here, but if you want them, use the > partitions container instead, please. > > > + > > + partition@20000 { > > + label = "Linux"; > > + reg = <0x00020000 0x07d00000>; > > + }; > > + > > + partition@7d20000 { > > + label = "RedBoot"; > > + reg = <0x07d20000 0x002e0000>; > > + read-only; > > + }; > > + }; > > + > > +... > > > Thanks, > Miquèl
Hi Nikita, nikita.shubin@maquefel.me wrote on Mon, 15 May 2023 18:48:31 +0300: > Hello Miquel! > > Thank you for looking into it. > > On Tue, 2023-05-02 at 11:48 +0200, Miquel Raynal wrote: > > Hi Nikita, > > > > nikita.shubin@maquefel.me wrote on Mon, 24 Apr 2023 15:34:38 +0300: > > > > > Add YAML bindings for ts7250 NAND. > > > > > > Signed-off-by: Nikita Shubin <nikita.shubin@maquefel.me> > > > --- > > > .../bindings/mtd/technologic,nand.yaml | 56 > > > +++++++++++++++++++ > > > 1 file changed, 56 insertions(+) > > > create mode 100644 > > > Documentation/devicetree/bindings/mtd/technologic,nand.yaml > > > > > > diff --git > > > a/Documentation/devicetree/bindings/mtd/technologic,nand.yaml > > > b/Documentation/devicetree/bindings/mtd/technologic,nand.yaml > > > new file mode 100644 > > > index 000000000000..3234d93a1c21 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/mtd/technologic,nand.yaml > > > @@ -0,0 +1,56 @@ > > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause > > > +%YAML 1.2 > > > +--- > > > +$id: http://devicetree.org/schemas/mtd/technologic,nand.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: Technologic Systems NAND controller > > > + > > > +maintainers: > > > + - Lukasz Majewski <lukma@denx.de> > > > + > > > +properties: > > > + compatible: > > > + items: > > > + - const: technologic,ts7200-nand > > > > would -nand-controller instead of -nand work as a suffix here? > > > > You mention ts7250 in the title, should we have a more specific > > compatible than ts7200 as well? > > > > I see by looking at the mtd patch that you actually try to match > > both, > > so they should both be defined in the bindings. > > > > > + - const: gen_nand > > > > This is a old hack for very simple controllers (converted to DT > > probing > > 12 years ago). The logic used by this driver has been deprecated for > > like 10 years and does not really apply to modern APIs. I would > > really > > like to keep this driver contained with platform data coming from > > arch/ > > data only. > > > > I suggest you create a real NAND controller driver based on the > > generic one (should not be very complex, just duplicate the code so > > the > > migration to the up-to-date API is eased) and you flag it as "must be > > updated to ->exec_op() somehow. This way if someone starts the > > conversion, it does not need to cope with the 5 other users of the > > generic driver which anyway share nothing in common besides the > > deprecated ->cmd_ctrl() backbone. > > > > I read the comments on the cover letter, people are kind of pushing > > on > > having this merged quickly. I am fine accepting a legacy controller > > driver and migrating it to ->exec_op() later, but the current driver > > conversion does not fit the approach taken years ago towards a > > cleaner > > mtd tree. > > Did you mean that i should at least implement legacy nand controller, > like, for example, Xway (xway_nand.c) ?: > > data->chip.legacy.cmd_ctrl = xway_cmd_ctrl; > data->chip.legacy.dev_ready = xway_dev_ready; > data->chip.legacy.select_chip = xway_select_chip; > data->chip.legacy.write_buf = xway_write_buf; > data->chip.legacy.read_buf = xway_read_buf; > data->chip.legacy.read_byte = xway_read_byte; > data->chip.legacy.chip_delay = 30; I don't know how urgent this conversion is, this is really the minimal step... > And the best solution would be switching to exec_op completely ? ...and this is what I would really prefer, yes. I don't think it's huge, the controller being very simple and straightforward. > > > > > > + > > > + reg: > > > + maxItems: 1 > > > + > > > + '#address-cells': true > > > + '#size-cells': true > > > + > > > +required: > > > + - compatible > > > + - reg > > > + > > > +unevaluatedProperties: true > > > + > > > +examples: > > > + - | > > > + nand-parts@0 { > > > + compatible = "technologic,ts7200-nand", "gen_nand"; > > > + reg = <0x60000000 0x8000000>; > > > + #address-cells = <1>; > > > + #size-cells = <1>; > > > + > > > + partition@0 { > > > + label = "TS-BOOTROM"; > > > + reg = <0x00000000 0x00020000>; > > > + read-only; > > > + }; > > > > Partitions are not useful here, but if you want them, use the > > partitions container instead, please. > > > > > + > > > + partition@20000 { > > > + label = "Linux"; > > > + reg = <0x00020000 0x07d00000>; > > > + }; > > > + > > > + partition@7d20000 { > > > + label = "RedBoot"; > > > + reg = <0x07d20000 0x002e0000>; > > > + read-only; > > > + }; > > > + }; > > > + > > > +... > > > > > > Thanks, > > Miquèl > Thanks, Miquèl
diff --git a/Documentation/devicetree/bindings/mtd/technologic,nand.yaml b/Documentation/devicetree/bindings/mtd/technologic,nand.yaml new file mode 100644 index 000000000000..3234d93a1c21 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/technologic,nand.yaml @@ -0,0 +1,56 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/technologic,nand.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Technologic Systems NAND controller + +maintainers: + - Lukasz Majewski <lukma@denx.de> + +properties: + compatible: + items: + - const: technologic,ts7200-nand + - const: gen_nand + + reg: + maxItems: 1 + + '#address-cells': true + '#size-cells': true + +required: + - compatible + - reg + +unevaluatedProperties: true + +examples: + - | + nand-parts@0 { + compatible = "technologic,ts7200-nand", "gen_nand"; + reg = <0x60000000 0x8000000>; + #address-cells = <1>; + #size-cells = <1>; + + partition@0 { + label = "TS-BOOTROM"; + reg = <0x00000000 0x00020000>; + read-only; + }; + + partition@20000 { + label = "Linux"; + reg = <0x00020000 0x07d00000>; + }; + + partition@7d20000 { + label = "RedBoot"; + reg = <0x07d20000 0x002e0000>; + read-only; + }; + }; + +...