Message ID | 1440267221-22220-2-git-send-email-hdegoede@redhat.com |
---|---|
State | Accepted |
Delegated to: | Hans de Goede |
Headers | show |
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
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
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 --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++) {
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(-)