[PATCH] rockchip: rk3328: fix booting error for nanopi-r2s
>From 29cf326e24b657180e4cf90ded2366d49f33e88e Mon Sep 17 00:00:00 2001
From: jason416
Date: Mon, 5 Jul 2021 23:22:29 +0800
Subject: [PATCH] rockchip: rk3328: fix booting error for nanopi-r2s
devices can not boot properly during SPL stage by
using microSD card which model is SDSQUNC-032G-ZN6MA.
U-Boot SPL 2021.04 (Jul 02 2021 - 19:50:12 +)
Trying to boot from MMC1
mmc_load_image_raw_sector: mmc block read error
SPL: failed to boot from all boot devices
change dts and config to support booting from ultra
high speed microSD card on nanopi-r2s.
Signed-off-by: jason416
---
arch/arm/dts/rk3328-nanopi-r2s-u-boot.dtsi | 4
arch/arm/dts/rk3328-nanopi-r2s.dts | 2 +-
configs/nanopi-r2s-rk3328_defconfig| 4
3 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/rk3328-nanopi-r2s-u-boot.dtsi b/arch/arm/dts
/rk3328-nanopi-r2s-u-boot.dtsi
index 9e2ced1541..d5469748a2 100644
--- a/arch/arm/dts/rk3328-nanopi-r2s-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-nanopi-r2s-u-boot.dtsi
@@ -33,6 +33,10 @@
u-boot,dm-spl;
};
+_io_sdio {
+ u-boot,dm-spl;
+};
+
{
snps,reset-gpio = < RK_PC2 GPIO_ACTIVE_LOW>;
snps,reset-active-low;
diff --git a/arch/arm/dts/rk3328-nanopi-r2s.dts b/arch/arm/dts/rk3328-nanopi
-r2s.dts
index 5445c5cb3d..452e4764e6 100644
--- a/arch/arm/dts/rk3328-nanopi-r2s.dts
+++ b/arch/arm/dts/rk3328-nanopi-r2s.dts
@@ -323,7 +323,7 @@
bus-width = <4>;
cap-sd-highspeed;
disable-wp;
- pinctrl-0 = <_clk>, <_cmd>, <_dectn>, <_bus4>;
+ pinctrl-0 = <_clk>, <_cmd>, <_dectn>,
<_bus4>, <_gpio>;
pinctrl-names = "default";
sd-uhs-sdr12;
sd-uhs-sdr25;
diff --git a/configs/nanopi-r2s-rk3328_defconfig b/configs/nanopi
-r2s-rk3328_defconfig
index 52996266a1..a7969bd7ab 100644
--- a/configs/nanopi-r2s-rk3328_defconfig
+++ b/configs/nanopi-r2s-rk3328_defconfig
@@ -56,6 +56,10 @@ CONFIG_FASTBOOT_BUF_ADDR=0x800800
CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
CONFIG_ROCKCHIP_GPIO=y
CONFIG_SYS_I2C_ROCKCHIP=y
+CONFIG_MMC_IO_VOLTAGE=y
+CONFIG_SPL_MMC_IO_VOLTAGE=y
+CONFIG_MMC_UHS_SUPPORT=y
+CONFIG_SPL_MMC_UHS_SUPPORT=y
CONFIG_MMC_DW=y
CONFIG_MMC_DW_ROCKCHIP=y
CONFIG_SF_DEFAULT_SPEED=2000
--
2.17.1
Re: [U-Boot] On writing .ext4 image to MMC
I was hoping to get this done in the bootloader otherwise I have to change the rootfs ;) On Fri, Jan 12, 2018 at 1:18 PM Michael Nazzareno Trimarchi < mich...@amarulasolutions.com> wrote: > Hi > > On 12 Jan. 2018 7:15 pm, "Adam Lee" <adam.yh@gmail.com> wrote: > > Hi Michael, I used gparted to fix the issue. I am just wondering if I can > do all this in U-Boot. > If there is no good solution, I will put one-time script in my rootfs to > do this task. > > > Sorry most of the system on first boot create a first instance of > something like ssd for keys. I think that just use resize FS should do the > trick. Why is should be done in bootloader? > > Michael > > > Adam > > On Fri, Jan 12, 2018 at 10:18 AM Michael Nazzareno Trimarchi < > mich...@amarulasolutions.com> wrote: > >> Hi >> >> >> resize2fs from linux? >> >> Michael >> >> On Fri, Jan 12, 2018 at 4:15 PM, Adam Lee <adam.yh@gmail.com> wrote: >> > Hello everyone, >> > >> > I am able to download a .ext4 image over tftp and write it to my SD >> card. >> > The system boots fine. >> > One last thing I have to figure out is to expand this .ext4 file system >> > that I just populated. >> > If the image is 600MB, the partition size itself is 600MB, leaving no >> room. >> > >> > Is there anything I can do to remedy this in U-Boot? >> > >> > Adam >> > ___ >> > U-Boot mailing list >> > U-Boot@lists.denx.de >> > https://lists.denx.de/listinfo/u-boot >> >> >> >> -- >> | Michael Nazzareno Trimarchi Amarula Solutions BV | >> | COO - Founder Cruquiuskade 47 >> <https://maps.google.com/?q=Cruquiuskade+47=gmail=g> | >> | +31(0)851119172 <+31%2085%20111%209172> >> Amsterdam 1018 AM NL | >> | [`as] http://www.amarulasolutions.com | >> > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] On writing .ext4 image to MMC
Hi Michael, I used gparted to fix the issue. I am just wondering if I can do all this in U-Boot. If there is no good solution, I will put one-time script in my rootfs to do this task. Adam On Fri, Jan 12, 2018 at 10:18 AM Michael Nazzareno Trimarchi < mich...@amarulasolutions.com> wrote: > Hi > > > resize2fs from linux? > > Michael > > On Fri, Jan 12, 2018 at 4:15 PM, Adam Lee <adam.yh@gmail.com> wrote: > > Hello everyone, > > > > I am able to download a .ext4 image over tftp and write it to my SD card. > > The system boots fine. > > One last thing I have to figure out is to expand this .ext4 file system > > that I just populated. > > If the image is 600MB, the partition size itself is 600MB, leaving no > room. > > > > Is there anything I can do to remedy this in U-Boot? > > > > Adam > > ___ > > U-Boot mailing list > > U-Boot@lists.denx.de > > https://lists.denx.de/listinfo/u-boot > > > > -- > | Michael Nazzareno Trimarchi Amarula Solutions BV | > | COO - Founder Cruquiuskade 47 | > | +31(0)851119172 <+31%2085%20111%209172> > Amsterdam 1018 AM NL | > | [`as] http://www.amarulasolutions.com | > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] On writing .ext4 image to MMC
Hello everyone, I am able to download a .ext4 image over tftp and write it to my SD card. The system boots fine. One last thing I have to figure out is to expand this .ext4 file system that I just populated. If the image is 600MB, the partition size itself is 600MB, leaving no room. Is there anything I can do to remedy this in U-Boot? Adam ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Default rootfs type for OMAP4 is still ext3?
Hi everyone, is there a particular reason why OMAP4 has not migrated to ext4 from ext3? Specifically, the uenv variable 'rootfstype is still set to ext3, rather than ext4 [1]. Thanks, Adam [1] http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/ti_omap4_common.h;h=ef5a69da63407d52a315e8e326d90cefc37c0a6f;hb=HEAD#l98 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] omap_gpmc: Do not default to HAM1 when SW ECC is selected
Hi Andreas, for OMAP3 and AM35xx boards, it would have been ok omitting the
CONFIG_BCH check and simply use CONFIG_NAND_OMAP_ECCSCHEME.
Those boards use the ecc scheme config already. However I just wasn't 100%
sure if I could rely on this config for all TI OMAP/AM based boards. I know
OMAP3
and AM35xx board configs already have CONFIG_NAND_OMAP_ECCSCHEME.
Should I check for other OMAP and AM series? The original ecc detection
function
seems to be written with an assumption that config is nonexistent - hence
defaulting
to HAM1.
That said, I agree that the whole omap_nand_switch_ecc() could be improved.
However, to me, the confusion arised from the fact that OMAP3 can do BCH8
hw ECC
calculation but needs software to do the correction. Hence my patch changes
the
software part of the omap_nand_switch_ecc(), and not the hardware part.
Just to clarify, what you are saying is that I should leave the software
part as it was (defaulting
to HAM1), and in the hardware part I should check for ELM support and
choose a BCH8
scheme accordingly, regardless of what's defined by
CONFIG_NAND_OMAP_ECCSCHEME?
In other words, I will run 'nandecc hw' to enable BCH8?
Let me know,
Thanks,
Adam
On Wed, Feb 18, 2015 at 6:14 AM, Andreas Bießmann
andreas.de...@googlemail.com wrote:
Hi Adam,
On 02/18/2015 03:58 AM, Adam YH Lee wrote:
The ECC scheme selection algorithm in OMAP GPMC appears to be left
untested when
BCH8 handling code was added. Running 'nandecc sw' defaults to HAM1 even
if
the board is using another scheme (ex.
OMAP_ECC_BCH8_CODE_HW_DETECTION_SW on
OMAP3). This results in unrecoverable ECC errors when reading data. This
commit
fixes the behavior by checking for CONFIG_BCH and using the scheme
defined by
CONFIG_NAND_OMAP_ECCSCHEME in the board configuration file.
This has been tested on Gumstix Overo (OMAP3).
Signed-off-by: Adam YH Lee adam.yh@gmail.com
---
drivers/mtd/nand/omap_gpmc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/mtd/nand/omap_gpmc.c b/drivers/mtd/nand/omap_gpmc.c
index fc64f48..5daf932 100644
--- a/drivers/mtd/nand/omap_gpmc.c
+++ b/drivers/mtd/nand/omap_gpmc.c
@@ -901,8 +901,13 @@ int __maybe_unused omap_nand_switch_ecc(uint32_t
hardware, uint32_t eccstrength)
return -EINVAL;
}
} else {
+ #ifdef CONFIG_BCH
+ err = omap_select_ecc_scheme(nand,
CONFIG_NAND_OMAP_ECCSCHEME,
+ mtd-writesize, mtd-oobsize);
+ #else
err = omap_select_ecc_scheme(nand, OMAP_ECC_HAM1_CODE_SW,
mtd-writesize, mtd-oobsize);
Couldn't we just use the CONFIG_NAND_OMAP_ECCSCHEME instead of
OMAP_ECC_HAM1_CODE_SW here and omit the CONFIG_BCH define?
On the other hand I think the whole function omap_nand_switch_ecc() is
wrong. AFAIR it should only be used on omap3 aka am35xx/dm37xx devices
witch the nandecc command.
These SoC do not have a ELM. Therefore I decided to say BCH8 on those
devices is always 'HW ECC' when introduced BCH8 on omap3 first. Nowadays
it is the so called BCH8_CODE_HW_DETECTION_SW. Coming from this mindset
the right solution is to use some detection if the ELM is supported or
not and switch in the HW part of omap_nand_switch_ecc() between
OMAP_ECC_BCH8_CODE_HW and OMAP_ECC_BCH8_CODE_HW_DETECTION_SW.
Best regards
Andreas Bießmann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] omap_gpmc: Do not default to HAM1 when SW ECC is selected
Had a conversation with Ash @ Gumstix and he pointed out relying on
CONFIG_NAND_OMAP_ECCSCHEME could be dangerous as it could be anything other
than the two SW ECC schemes available for OMAP3.
Also it looks like making a selection between OMAP_ECC_BCH8_CODE_HW and
OMAP_ECC_BCH8_CODE_HW_DETECTION_SW may not make sense as the latter
clearly requires CONFIG_BCH, which enables software library for BCH.
On Wed, Feb 18, 2015 at 9:33 AM, Adam Lee adam.yh@gmail.com wrote:
Hi Andreas, for OMAP3 and AM35xx boards, it would have been ok omitting
the
CONFIG_BCH check and simply use CONFIG_NAND_OMAP_ECCSCHEME.
Those boards use the ecc scheme config already. However I just wasn't 100%
sure if I could rely on this config for all TI OMAP/AM based boards. I
know OMAP3
and AM35xx board configs already have CONFIG_NAND_OMAP_ECCSCHEME.
Should I check for other OMAP and AM series? The original ecc detection
function
seems to be written with an assumption that config is nonexistent - hence
defaulting
to HAM1.
That said, I agree that the whole omap_nand_switch_ecc() could be improved.
However, to me, the confusion arised from the fact that OMAP3 can do BCH8
hw ECC
calculation but needs software to do the correction. Hence my patch
changes the
software part of the omap_nand_switch_ecc(), and not the hardware part.
Just to clarify, what you are saying is that I should leave the software
part as it was (defaulting
to HAM1), and in the hardware part I should check for ELM support and
choose a BCH8
scheme accordingly, regardless of what's defined by
CONFIG_NAND_OMAP_ECCSCHEME?
In other words, I will run 'nandecc hw' to enable BCH8?
Let me know,
Thanks,
Adam
On Wed, Feb 18, 2015 at 6:14 AM, Andreas Bießmann
andreas.de...@googlemail.com wrote:
Hi Adam,
On 02/18/2015 03:58 AM, Adam YH Lee wrote:
The ECC scheme selection algorithm in OMAP GPMC appears to be left
untested when
BCH8 handling code was added. Running 'nandecc sw' defaults to HAM1
even if
the board is using another scheme (ex.
OMAP_ECC_BCH8_CODE_HW_DETECTION_SW on
OMAP3). This results in unrecoverable ECC errors when reading data.
This commit
fixes the behavior by checking for CONFIG_BCH and using the scheme
defined by
CONFIG_NAND_OMAP_ECCSCHEME in the board configuration file.
This has been tested on Gumstix Overo (OMAP3).
Signed-off-by: Adam YH Lee adam.yh@gmail.com
---
drivers/mtd/nand/omap_gpmc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/mtd/nand/omap_gpmc.c b/drivers/mtd/nand/omap_gpmc.c
index fc64f48..5daf932 100644
--- a/drivers/mtd/nand/omap_gpmc.c
+++ b/drivers/mtd/nand/omap_gpmc.c
@@ -901,8 +901,13 @@ int __maybe_unused omap_nand_switch_ecc(uint32_t
hardware, uint32_t eccstrength)
return -EINVAL;
}
} else {
+ #ifdef CONFIG_BCH
+ err = omap_select_ecc_scheme(nand,
CONFIG_NAND_OMAP_ECCSCHEME,
+ mtd-writesize, mtd-oobsize);
+ #else
err = omap_select_ecc_scheme(nand, OMAP_ECC_HAM1_CODE_SW,
mtd-writesize, mtd-oobsize);
Couldn't we just use the CONFIG_NAND_OMAP_ECCSCHEME instead of
OMAP_ECC_HAM1_CODE_SW here and omit the CONFIG_BCH define?
On the other hand I think the whole function omap_nand_switch_ecc() is
wrong. AFAIR it should only be used on omap3 aka am35xx/dm37xx devices
witch the nandecc command.
These SoC do not have a ELM. Therefore I decided to say BCH8 on those
devices is always 'HW ECC' when introduced BCH8 on omap3 first. Nowadays
it is the so called BCH8_CODE_HW_DETECTION_SW. Coming from this mindset
the right solution is to use some detection if the ELM is supported or
not and switch in the HW part of omap_nand_switch_ecc() between
OMAP_ECC_BCH8_CODE_HW and OMAP_ECC_BCH8_CODE_HW_DETECTION_SW.
Best regards
Andreas Bießmann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Writing u-boot to NAND from U-Boot results in ecc unrecoverable error
Hello everyone,
I have a Gumstix Overo (OMAP3) COM here that I am evaluating BCH8 ECC
scheme on boot-loader (2014.10) and the kernel (3.17.7).
Traditionally the board has been configured with 1 bit HAM, as are other
OMAP3 boards.
I have these changes in my board config:
+#define CONFIG_BCH
+#define CONFIG_SYS_NAND_MAX_ECCPOS 56
+#define CONFIG_SYS_NAND_ECCPOS {2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, \
+ 13, 14, 16, 17, 18, 19, 20, 21, 22, \
+ 23, 24, 25, 26, 27, 28, 30, 31, 32, \
+ 33, 34, 35, 36, 37, 38, 39, 40, 41, \
+ 42, 44, 45, 46, 47, 48, 49, 50, 51, \
+ 52, 53, 54, 55, 56}
+#define CONFIG_SYS_NAND_ECCBYTES 13
+#define CONFIG_NAND_OMAP_ECCSCHEME OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
+#define CONFIG_SPL_MAX_SIZE(58 * 1024)
And other than MLO, I make sure 'nandecc sw' before I do any NAND
write/read.
Now the first problem occurs after MLO executes and before U-Boot is
loaded. I get a whole bunch of ecc unrecoverable error from
`nand_spl_load_image` calls. Weird thing is that U-Boot image eventually
gets loaded after a couple hundred lines of these error messages.
This problem however does not occur when I write the U-Boot image from the
Kernel using flash_erase and nandwrite tools (my DTS has ti,nand-ecc-opt =
bch8; .
Any pointers would be greatly appreciated,
Adam
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
