From: Alexander Dahl <ada@thorsis.com>
To: Benedikt Spranger <b.spranger@linutronix.de>
Cc: Alexander Dahl <ada@thorsis.com>,
u-boot@lists.denx.de, John Ogness <john.ogness@linutronix.de>
Subject: Re: [PATCH 0/5] collected fallout of porting an ATSAMA5D27 based board
Date: Mon, 21 Oct 2024 12:51:35 +0200 [thread overview]
Message-ID: <20241021-union-repressed-6ff41958aa98@thorsis.com> (raw)
In-Reply-To: <20241021122017.34fc9f3c@mitra>
Hello Benedikt,
Am Mon, Oct 21, 2024 at 12:20:17PM +0200 schrieb Benedikt Spranger:
> The SPL sits in the first Page in NAND flash. It does it's magic and
> then load the U-Boot payload from an UBI volume (Or directly load a
> kernel). Then it "starts" the payload.
>
> > Did you try reading/writing raw NAND from there?
> I try to read from SPL. That's all what ubispl wants. No need for write
> support here.
>
> > I'm not familiar with SPL, does it consider dts?
> It consider dts.
>
> > I could share my dts parts if that helps you.
> That would be great. I definitly give it a try.
> So here is a quick extract (EBI is also used otherwise) of what I did.
Using EBI for accessing an FPGA here on one of three boards.
So I'll share that dts excerpt from my v2024.10 branch.
> Hopefully I did not forget anything...
>
> --- a/arch/arm/dts/at91-sama5d27_ABC.dts
> +++ b/arch/arm/dts/at91-sama5d27_ABC.dts
> @@ -63,7 +63,62 @@
> bias-disable;
> bootph-all;
> };
> +
> + pinctrl_nand0_default: nand0_default {
> + pinmux =
> + <PIN_PA0__D0>,
> + <PIN_PA1__D1>,
> + <PIN_PA2__D2>,
> + <PIN_PA3__D3>,
> + <PIN_PA4__D4>,
> + <PIN_PA5__D5>,
> + <PIN_PA6__D6>,
> + <PIN_PA7__D7>,
> + <PIN_PA8__NWE_NANDWE>,
> + <PIN_PA9__NCS3>,
> + <PIN_PA10__A21_NANDALE>,
> + <PIN_PA11__A22_NANDCLE>,
> + <PIN_PA12__NRD_NANDOE>,
> + <PIN_PA21__NANDRDY>;
> + bias-disable;
> + };
> };
> };
> };
> };
> +
> +&ebi {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_nand0_default>;
> + status = "okay";
> +
> + nand_controller: nand-controller {
> + status = "okay";
> +
> + nand@3 {
> + reg = <0x3 0x0 0x800000>;
> + //atmel,rb = <0>;
> + nand-bus-width = <8>;
> + nand-ecc-mode = "hw";
> + nand-ecc-strength = <4>;
> + nand-ecc-step-size = <512>;
> + nand-on-flash-bbt;
> +
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + spl@0 {
> + label = "spl";
> + reg = <0x0 0x40000>;
> + };
> +
> + ubi@40000 {
> + label = "UBI";
> + reg = <0x40000 0x0>;
> + };
> + };
> + };
> + };
> +};
I have no partitions defined, but that should not hurt. Split pinctrl
settings here, but that's basically because I have more child nodes on
the EBI node in Linux which I don't use in U-Boot here. Should not
make such a difference.
Do you have external pull-ups for the A21_NANDALE, A22_NANDCLE,
NANDRDY, and NCS3 lines? Maybe cross check that with the board code
you probably have for the old non-DM NAND driver.
Now my example:
&ebi {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ebi_default>;
status = "okay";
nand_controller: nand-controller {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_nand_default>;
status = "okay";
nand@3 {
reg = <0x3 0x0 0x800000>;
atmel,rb = <0>;
nand-bus-width = <8>;
nand-ecc-mode = "hw";
nand-on-flash-bbt;
nand-ecc-strength = <8>;
nand-ecc-step-size = <512>;
label = "atmel_nand";
};
};
};
&pioA {
pinctrl_ebi_default: ebi_default {
rd_we_data {
pinmux = <PIN_PA22__D0>,
<PIN_PA23__D1>,
<PIN_PA24__D2>,
<PIN_PA25__D3>,
<PIN_PA26__D4>,
<PIN_PA27__D5>,
<PIN_PA28__D6>,
<PIN_PA29__D7>,
<PIN_PA30__NWE_NANDWE>,
<PIN_PB2__NRD_NANDOE>;
bias-disable;
atmel,drive-strength = <ATMEL_PIO_DRVSTR_ME>;
};
};
pinctrl_nand_default: nand_default {
ale_cle_rdy_cs {
pinmux = <PIN_PB0__A21_NANDALE>,
<PIN_PB1__A22_NANDCLE>,
<PIN_PC8__NANDRDY>,
<PIN_PA31__NCS3>;
bias-pull-up;
};
};
};
Notice mine uses IO Set 1 here, but your's should work with IO Set 2 as
well.
> > (What I do here: SoC loads at91bootstrap from raw NAND at offset 0,
> > at91bootstrap loads U-Boot from raw NAND at some offset like 0x20000,
> > U-Boot (proper) loads everything else from UBI.)
> From my experience that can cause significant headache starting after
> 5-6 years in use. That's what I try to avoid :)
I'm aware of that. The data retention time for the NAND flash used
here is 10 years according to datasheet. No big deal on Linux when
running ubihealthd for everything stored in UBI, but everything
outside of that is about to fail some day. :-/
Greets
Alex
prev parent reply other threads:[~2024-10-21 10:51 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-18 8:30 [PATCH 0/5] collected fallout of porting an ATSAMA5D27 based board Benedikt Spranger
2024-10-18 8:30 ` [PATCH 0/5] collected fallout of porting an ATSAMA5D2 " Benedikt Spranger
2024-11-12 13:45 ` Eugen Hristev
2024-11-19 15:46 ` Eugen Hristev
2024-11-21 22:48 ` Michael Nazzareno Trimarchi
2024-10-18 8:30 ` [PATCH 1/5] tiny-printf: Handle NULL pointer argument to %s Benedikt Spranger
2024-10-18 8:30 ` [PATCH 2/5] drivers/mtd/ubispl/ubispl.c: Fix error message Benedikt Spranger
2024-10-18 8:30 ` [PATCH 3/5] mtd: nand: raw: Fix potential NULL pointer dereference Benedikt Spranger
2024-10-18 8:30 ` [PATCH 4/5] mtd: nand: Update NAND manufacturer Ids Benedikt Spranger
2024-11-12 13:39 ` Eugen Hristev
2024-11-12 13:57 ` Benedikt Spranger
2024-11-12 14:48 ` Eugen Hristev
2024-10-18 8:30 ` [PATCH 5/5] mtd: nand: raw: atmel_nand: Add missing nand_scan_ident() Benedikt Spranger
2024-10-18 13:11 ` [PATCH 0/5] collected fallout of porting an ATSAMA5D27 based board Alexander Dahl
2024-10-18 14:19 ` Benedikt Spranger
2024-10-21 6:03 ` Alexander Dahl
2024-10-21 7:17 ` Eugen Hristev
2024-10-21 7:36 ` Alexander Dahl
2024-10-21 12:49 ` Eugen Hristev
2024-10-21 12:30 ` Benedikt Spranger
2024-10-21 12:47 ` Eugen Hristev
2024-10-21 10:20 ` Benedikt Spranger
2024-10-21 10:51 ` Alexander Dahl [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241021-union-repressed-6ff41958aa98@thorsis.com \
--to=ada@thorsis.com \
--cc=b.spranger@linutronix.de \
--cc=john.ogness@linutronix.de \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox