diff mbox

[U-Boot,2/4] sunxi_nand_spl: Remove NAND_SUNXI_SPL_SYNDROME_PARTITIONS_END

Message ID 1440267221-22220-2-git-send-email-hdegoede@redhat.com
State Accepted
Delegated to: Hans de Goede
Headers show

Commit Message

Hans de Goede Aug. 22, 2015, 6:13 p.m. UTC
We only ever use syndrome mode for the partitions which contain the SPL,
as that is required for the BROM to be able to read the SPL.

Instead of using some arbritray limit for deciding whether or not to
use syndrome, be smart and check if u-boot-dtb.bin is directly behind
the SPL, if it is not then it is on its own partition and we should not
use syndrome.

Note the reason why we only use syndrome mode is because it comes with
weaker randomization, introducing a risc for more bit errors, so we want
to avoid it when possible.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 drivers/mtd/nand/Kconfig          | 8 --------
 drivers/mtd/nand/sunxi_nand_spl.c | 8 ++++++--
 2 files changed, 6 insertions(+), 10 deletions(-)

Comments

Scott Wood Aug. 24, 2015, 5:02 p.m. UTC | #1
On Sat, 2015-08-22 at 20:13 +0200, Hans de Goede wrote:
> We only ever use syndrome mode for the partitions which contain the SPL,
> as that is required for the BROM to be able to read the SPL.
> 
> Instead of using some arbritray limit for deciding whether or not to
> use syndrome, be smart and check if u-boot-dtb.bin is directly behind
> the SPL, if it is not then it is on its own partition and we should not
> use syndrome.
> 
> Note the reason why we only use syndrome mode is because it comes with
> weaker randomization,

"...why we only use syndrome mode for the SPL is because..."

>  introducing a risc for more bit errors, 

risk


> -     int syndrome = offs < CONFIG_NAND_SUNXI_SPL_SYNDROME_PARTITIONS_END;
> -     int i;
> +     int i, syndrome;
> +
> +     if (CONFIG_SYS_NAND_U_BOOT_OFFS == CONFIG_SPL_PAD_TO)
> +             syndrome = 1; /* u-boot-dtb.bin appended to SPL */
> +     else
> +             syndrome = 0; /* u-boot-dtb.bin on its own partition */

Is it not possible for a separate partition to begin at CONFIG_SPL_PAD_TO, or 
would padding not be used in that case?

-Scott
Hans de Goede Aug. 25, 2015, 7:18 a.m. UTC | #2
Hi,

On 24-08-15 19:02, Scott Wood wrote:
> On Sat, 2015-08-22 at 20:13 +0200, Hans de Goede wrote:
>> We only ever use syndrome mode for the partitions which contain the SPL,
>> as that is required for the BROM to be able to read the SPL.
>>
>> Instead of using some arbritray limit for deciding whether or not to
>> use syndrome, be smart and check if u-boot-dtb.bin is directly behind
>> the SPL, if it is not then it is on its own partition and we should not
>> use syndrome.
>>
>> Note the reason why we only use syndrome mode is because it comes with
>> weaker randomization,
>
> "...why we only use syndrome mode for the SPL is because..."
>
>>   introducing a risc for more bit errors,
>
> risk

Will fix.

>> -     int syndrome = offs < CONFIG_NAND_SUNXI_SPL_SYNDROME_PARTITIONS_END;
>> -     int i;
>> +     int i, syndrome;
>> +
>> +     if (CONFIG_SYS_NAND_U_BOOT_OFFS == CONFIG_SPL_PAD_TO)
>> +             syndrome = 1; /* u-boot-dtb.bin appended to SPL */
>> +     else
>> +             syndrome = 0; /* u-boot-dtb.bin on its own partition */
>
> Is it not possible for a separate partition to begin at CONFIG_SPL_PAD_TO, or
> would padding not be used in that case?

CONFIG_SPL_PAD_TO always is 32k on sunxi, partitions must be on an eraseblock
boundary and eraseblocks are always much larger then 32k, so this cannot happen.

Regards,

Hans
Ian Campbell Aug. 26, 2015, 6:37 p.m. UTC | #3
On Tue, 2015-08-25 at 09:18 +0200, Hans de Goede wrote:
> Hi,
> 
> On 24-08-15 19:02, Scott Wood wrote:
> > On Sat, 2015-08-22 at 20:13 +0200, Hans de Goede wrote:
> > > We only ever use syndrome mode for the partitions which contain 
> > > the SPL,
> > > as that is required for the BROM to be able to read the SPL.
> > > 
> > > Instead of using some arbritray limit for deciding whether or not 
> > > to
> > > use syndrome, be smart and check if u-boot-dtb.bin is directly 
> > > behind
> > > the SPL, if it is not then it is on its own partition and we 
> > > should not
> > > use syndrome.
> > > 
> > > Note the reason why we only use syndrome mode is because it comes 
> > > with
> > > weaker randomization,
> > 
> > "...why we only use syndrome mode for the SPL is because..."
> > 
> > >   introducing a risc for more bit errors,
> > 
> > risk
> 
> Will fix.

With that: Acked-by: Ian Campbell <ijc@hellion.org.uk>
diff mbox

Patch

diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index c331f66..c65951e 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -93,14 +93,6 @@  config SPL_NAND_DENALI
 	  This is a small implementation of the Denali NAND controller
 	  for use on SPL.
 
-config NAND_SUNXI_SPL_SYNDROME_PARTITIONS_END
-	hex "Size of syndrome partitions in sunxi NAND"
-	default 0x400000
-	depends on NAND_SUNXI
-	---help---
-	End address for boot partitions on NAND. Those partitions have a
-	different random seed that has to match the sunxi BROM setting.
-
 endif
 
 endmenu
diff --git a/drivers/mtd/nand/sunxi_nand_spl.c b/drivers/mtd/nand/sunxi_nand_spl.c
index ebab2ed..0505424 100644
--- a/drivers/mtd/nand/sunxi_nand_spl.c
+++ b/drivers/mtd/nand/sunxi_nand_spl.c
@@ -355,8 +355,12 @@  int nand_spl_load_image(uint32_t offs, unsigned int size, void *dest)
 		2 * 1024 * 1024 + CONFIG_SYS_NAND_U_BOOT_OFFS,
 		4 * 1024 * 1024 + CONFIG_SYS_NAND_U_BOOT_OFFS,
 	};
-	int syndrome = offs < CONFIG_NAND_SUNXI_SPL_SYNDROME_PARTITIONS_END;
-	int i;
+	int i, syndrome;
+
+	if (CONFIG_SYS_NAND_U_BOOT_OFFS == CONFIG_SPL_PAD_TO)
+		syndrome = 1; /* u-boot-dtb.bin appended to SPL */
+	else
+		syndrome = 0; /* u-boot-dtb.bin on its own partition */
 
 	if (offs == CONFIG_SYS_NAND_U_BOOT_OFFS) {
 		for (i = 0; i < ARRAY_SIZE(boot_offsets); i++) {