Re: [PATCH v3 2/3] arm: Add an __image_copy_start symbol for ARMv8
On Sat, 2021-09-25 at 09:46 -0600, Simon Glass wrote:
> Hi Scott,
>
> On Thu, 5 Aug 2021 at 13:20, Simon Glass wrote:
> >
> > Hi Scott,
> >
> > On Wed, 4 Aug 2021 at 13:53, Scott Wood wrote:
> > >
> > > On Sun, 2021-08-01 at 14:59 -0600, Simon Glass wrote:
> > > > This symbol is needed for binman to locate the start of the image. Add
> > > > it.
> > > >
> > > > Note: the existing line to bring in the .__image_copy_start symbol
> > > > does
> > > > not appear to do anything.
> > > >
> > > > Signed-off-by: Simon Glass
> > > > ---
> > > > I have copied Scott Wood who originally added the line about the
> > > > __image_copy_start in the hope that he can decide if we should remove
> > > > it.
> > >
> > > It's been a long time since I looked at this stuff, but
> > > __image_copy_start is
> > > used for relocation and that code does not seem to be in the SPL, so the
> > > *(.__image_copy_start) was probably just a copy-and-paste leftover from
> > > the
> > > main SPL that can go away.
> > >
> > > Of course, that doesn't resolve the binman issue. :-)
> > >
> > > > diff --git a/arch/arm/cpu/armv8/u-boot-spl.lds b/arch/arm/cpu/armv8/u-
> > > > boot-
> > > > spl.lds
> > > > index 9edb662b094..2827a07590d 100644
> > > > --- a/arch/arm/cpu/armv8/u-boot-spl.lds
> > > > +++ b/arch/arm/cpu/armv8/u-boot-spl.lds
> > > > @@ -22,6 +22,7 @@ ENTRY(_start)
> > > > SECTIONS
> > > > {
> > > > .text : {
> > > > + __image_copy_start = .;
> > > > . = ALIGN(8);
> > > > *(.__image_copy_start)
> > > > CPUDIR/start.o (.text*)
> > >
> > > If for whatever reason you did need to define the symbol this way,
> > > shouldn't
> > > it be after the alignment?
> >
> > Well I don't want to miss out any of the image, otherwise the offsets
> > would be off.
> >
> > But perhaps that is another question. Since this is the first section,
> > it should already be aligned (to 16 I suspect). So why do we need it?
>
> I'd like to get this applied, assuming it is correct, because at
> present binman is silently ignoring problems where it cannot find
> symbols. The fix for that is:
>
> http://patchwork.ozlabs.org/project/uboot/patch/20210722210216.1.Id1246d1ff1cb5750f8c7ddde9665cf6f09615a7c@changeid/
>
> which has been sitting there for a while.
I'm not sure what you need from me... as I said before, as far as I can tell
the __image_copy_start stuff should not be needed by the SPL itself. If you
want to add it just for binman, there should probably be a comment to that
effect, but I'm not the ARM maintainer (or involved in U-Boot development at
all these days) so I can't help you get anything applied.
As for why the alignment is there, it's probably just paranoia, but in any
case, the SPL linker script probably shouldn't handle alignment in a
gratuitously different way from the main linker script.
-Scott
Re: [PATCH v3 2/3] arm: Add an __image_copy_start symbol for ARMv8
On Sun, 2021-08-01 at 14:59 -0600, Simon Glass wrote:
> This symbol is needed for binman to locate the start of the image. Add it.
>
> Note: the existing line to bring in the .__image_copy_start symbol does
> not appear to do anything.
>
> Signed-off-by: Simon Glass
> ---
> I have copied Scott Wood who originally added the line about the
> __image_copy_start in the hope that he can decide if we should remove it.
It's been a long time since I looked at this stuff, but __image_copy_start is
used for relocation and that code does not seem to be in the SPL, so the
*(.__image_copy_start) was probably just a copy-and-paste leftover from the
main SPL that can go away.
Of course, that doesn't resolve the binman issue. :-)
> diff --git a/arch/arm/cpu/armv8/u-boot-spl.lds b/arch/arm/cpu/armv8/u-boot-
> spl.lds
> index 9edb662b094..2827a07590d 100644
> --- a/arch/arm/cpu/armv8/u-boot-spl.lds
> +++ b/arch/arm/cpu/armv8/u-boot-spl.lds
> @@ -22,6 +22,7 @@ ENTRY(_start)
> SECTIONS
> {
> .text : {
> + __image_copy_start = .;
> . = ALIGN(8);
> *(.__image_copy_start)
> CPUDIR/start.o (.text*)
If for whatever reason you did need to define the symbol this way, shouldn't
it be after the alignment?
-Scott
Re: [U-Boot] [PATCH] MTD: mxs_nand: Fix BCH read timeout error on boards requiring ECC
On Sun, 2019-02-10 at 07:48 -0600, Adam Ford wrote: > On Sun, Feb 10, 2019 at 7:30 AM Adam Ford wrote: > > > > On Mon, Feb 4, 2019 at 12:17 PM Tim Harvey wrote: > > > > > > On Wed, Jan 2, 2019 at 6:37 PM Adam Ford wrote: > > > > > > > > The LogicPD board uses a Micron Flash with ECC. To boot this from > > > > SPL, the ECC needs to be correctly configured or the BCH engine > > > > times out. > > > > > > > > Signed-off-by: Adam Ford > > > > > > > > diff --git a/drivers/mtd/nand/raw/mxs_nand.c > > > > b/drivers/mtd/nand/raw/mxs_nand.c > > > > index e3341812a2..2d84bfffe2 100644 > > > > --- a/drivers/mtd/nand/raw/mxs_nand.c > > > > +++ b/drivers/mtd/nand/raw/mxs_nand.c > > > > @@ -1163,6 +1163,12 @@ int mxs_nand_init_spl(struct nand_chip *nand) > > > > > > > > nand_info->gpmi_regs = (struct mxs_gpmi_regs *)MXS_GPMI_BASE; > > > > nand_info->bch_regs = (struct mxs_bch_regs *)MXS_BCH_BASE; > > > > + > > > > + if (is_mx6sx() || is_mx7()) > > > > + nand_info->max_ecc_strength_supported = 62; > > > > + else > > > > + nand_info->max_ecc_strength_supported = 40; > > > > + > > > > err = mxs_nand_alloc_buffers(nand_info); > > > > if (err) > > > > return err; > > > > diff --git a/drivers/mtd/nand/raw/mxs_nand_spl.c > > > > b/drivers/mtd/nand/raw/mxs_nand_spl.c > > > > index c628f3adec..ba85baac60 100644 > > > > --- a/drivers/mtd/nand/raw/mxs_nand_spl.c > > > > +++ b/drivers/mtd/nand/raw/mxs_nand_spl.c > > > > @@ -201,6 +201,7 @@ static int mxs_nand_init(void) > > > > /* setup flash layout (does not scan as we override that) */ > > > > mtd->size = nand_chip.chipsize; > > > > nand_chip.scan_bbt(mtd); > > > > + mxs_nand_setup_ecc(mtd); > > > > > > > > return 0; > > > > } > > > > -- > > > > 2.17.1 > > > > > > > > > > Thanks Adam, > > Scott / Stefano, > > I had to use Scott's other -email. > > > Any chance this can get reviewed and/or applied for the next release? > We've got a few people who have their respective tested-by comments. I haven't been involved in U-Boot for a while now. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] MAINTAINERS: Mark NAND as Orphaned
On Thu, 2018-07-26 at 12:03 -0400, Tom Rini wrote: > Scott is no longer maintaining the NAND subsystem, mark as orphaned for > now. > > Cc: Scott Wood > Signed-off-by: Tom Rini > --- > Thanks again for your time and contributions Scott! > --- > MAINTAINERS| 4 ++-- > doc/git-mailrc | 3 +-- > 2 files changed, 3 insertions(+), 4 deletions(-) Acked-by: Scott Wood -Scott ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] board: freescale: ls1012ardb: Add command to switch QSPI bank
On Fri, 2018-04-20 at 03:16 +, Prabhakar Kushwaha wrote:
> Thanks Scott for reviewing this patch
>
> > -Original Message-
> > From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Scott
> > Wood
> > Sent: Friday, April 20, 2018 6:40 AM
> > To: Calvin Johnson
> > Cc: U-Boot Mailing List
> > Subject: Re: [U-Boot] [PATCH] board: freescale: ls1012ardb: Add command to
> > switch QSPI bank
> >
> > On Thu, 2018-04-19 at 14:09 +0530, Calvin Johnson wrote:
> > > On Thu, Apr 19, 2018 at 12:17 PM, Scott Wood wrote:
> > > > On Mon, 2018-04-16 at 08:40 +0530, Calvin Johnson wrote:
> > > > > On Fri, Apr 13, 2018 at 12:18 AM, Jagdish Gediya
> > > > > > > > > >
> > > > >
> > > > > wrote:
> > > > > > Add command "boot_bank X" to switch the boot bank to either
> > > > > > 1 or 2.
> > > > >
> > > > > Are these functions required as this can be handled by new env
> > > > > vars to switch banks?
> > > >
> > > > If you're going to add something new, a command is much more
> > > > pleasant than env vars -- particularly if you stick to something
> > > > like the familiar interfaces ("pix altbank", "qix altbank", etc),
> > > > and include reporting of which bank was booted from if it's not
> > > > there already. Of course, a fully standardized interface would be
> > > > even better.
> > >
> > > Yes, a fully standardized generic interface supporting all similar
> > > platforms with multiple banks
> >
> > And other boot sources such as NAND and MMC.
>
>
> LS1012A has only one boot source i.e. QSPI
I meant that if there is any effort to standardize the command it should
support multiple boot sources, not just bank selection.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] board: freescale: ls1012ardb: Add command to switch QSPI bank
On Thu, 2018-04-19 at 14:09 +0530, Calvin Johnson wrote:
> On Thu, Apr 19, 2018 at 12:17 PM, Scott Wood wrote:
> > On Mon, 2018-04-16 at 08:40 +0530, Calvin Johnson wrote:
> > > On Fri, Apr 13, 2018 at 12:18 AM, Jagdish Gediya > > >
> > > wrote:
> > > > Add command "boot_bank X" to switch the boot bank to either
> > > > 1 or 2.
> > >
> > > Are these functions required as this can be handled by new env vars to
> > > switch banks?
> >
> > If you're going to add something new, a command is much more pleasant than
> > env
> > vars -- particularly if you stick to something like the familiar
> > interfaces
> > ("pix altbank", "qix altbank", etc), and include reporting of which bank
> > was
> > booted from if it's not there already. Of course, a fully standardized
> > interface would be even better.
>
> Yes, a fully standardized generic interface supporting all similar
> platforms with multiple banks
And other boot sources such as NAND and MMC.
> would be better. What this patch currently does can be done with
> simple env vars, like :
>
> setenv boot_bank_1 'i2c mw 0x24 0x7 0xfc; i2c mw 0x24 0x3 0xf5'
> setenv boot_bank_2 'i2c mw 0x24 0x7 0xfc; i2c mw 0x24 0x3 0xf4'
...if the user knows to env reset those variables after the update (versus
something that shows up in help), and if they don't get corrupted in a multi-
user board farm environment, etc.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] board: freescale: ls1012ardb: Add command to switch QSPI bank
On Mon, 2018-04-16 at 08:40 +0530, Calvin Johnson wrote:
> On Fri, Apr 13, 2018 at 12:18 AM, Jagdish Gediya
> wrote:
> > Add command "boot_bank X" to switch the boot bank to either
> > 1 or 2.
>
> Are these functions required as this can be handled by new env vars to
> switch banks?
If you're going to add something new, a command is much more pleasant than env
vars -- particularly if you stick to something like the familiar interfaces
("pix altbank", "qix altbank", etc), and include reporting of which bank was
booted from if it's not there already. Of course, a fully standardized
interface would be even better.
I'm assuming this hardware isn't at all compatible with pixis/qixis?
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 00/20] Bring NAND support to Nintendo NES Classic
On Wed, 2018-03-07 at 08:57 +0100, Maxime Ripard wrote: > Hi Scott, > > On Wed, Feb 28, 2018 at 08:51:42PM +0100, Miquel Raynal wrote: > > This series first adds fixes and enhancements to sunxi NAND drivers (SPL > > and U-Boot). Once this is done, the SPL NAND driver is converted to use > > PIO instead of DMA with the goal to support all SoCs with this IP > > without the need for DMA-related code. Finally, NAND support is added to > > Nintendo NES Classic through Kconfig and DT additions. > > Should we merge it through the sunxi tree, or do you want to merge > these changes through yours? The sunxi tree. I'm not really involved much with U-Boot these days. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mtd: nand: fsl-ifc: fix support of multiple NAND devices
On Mon, 2017-10-30 at 18:50 +, York Sun wrote: > On 10/20/2017 03:43 AM, Kurt Kanzenbach wrote: > > Currently the chipselect used to identify the corresponding NAND chip is > > stored > > at the controller and only set during fsl_ifc_chip_init(). This way, only > > the > > last NAND chip is working, as the previous value of cs_nand gets > > overwritten. > > > > In order to solve this issue the chipselect is computed on demand by > > evaluating > > the bank variable. Thus, the correct chipselect for each NAND chip > > operation is > > used. > > > > Tested on hardware with two NAND chips connected to the IFC controller. > > > > Signed-off-by: Kurt Kanzenbach > > --- > > Changes for v2: > > - get rid of cs_nand and compute chipselect on demand > > - pass priv instead of mtd to fsl_ifc_sram_init() > > Scott, > > Are you OK with this version? Somehow this patch was assigned me. I can > bring it in if you ack it. Acked-by: Scott Wood -Scott ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd: nand: fsl-ifc: fix support of multiple NAND devices
On Tue, Oct 17, 2017 at 10:00:45AM +0200, Kurt Kanzenbach wrote:
> Currently the chipselect used to identify the corresponding NAND chip is
> stored
> at the controller and only set during fsl_ifc_chip_init(). This way, only the
> last NAND chip is working, as the previous value of cs_nand gets overwritten.
>
> In order to solve this issue the chipselect is moved from the controller to
> the
> NAND chip structure. Thus, the correct chipselect for each NAND chip operation
> is used.
>
> Tested on hardware with two NAND chips connected to the IFC controller.
>
> Signed-off-by: Kurt Kanzenbach
> ---
> drivers/mtd/nand/fsl_ifc_nand.c | 16 +---
> 1 file changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/mtd/nand/fsl_ifc_nand.c b/drivers/mtd/nand/fsl_ifc_nand.c
> index bc6bdc9b2c..57737dbe94 100644
> --- a/drivers/mtd/nand/fsl_ifc_nand.c
> +++ b/drivers/mtd/nand/fsl_ifc_nand.c
> @@ -36,6 +36,7 @@ struct fsl_ifc_mtd {
>
> struct device *dev;
> int bank; /* Chip select bank number*/
> + unsigned int cs_nand; /* On which chipsel NAND is connected */
This is redundant with "bank" -- just do like the Linux driver does
and write "priv->bank << IFC_NAND_CSEL_SHIFT" directly to the register
when needed.
> -static int fsl_ifc_sram_init(uint32_t ver)
> +static int fsl_ifc_sram_init(struct mtd_info *mtd, uint32_t ver)
> {
> + struct nand_chip *chip = mtd_to_nand(mtd);
> + struct fsl_ifc_mtd *priv = nand_get_controller_data(chip);
Could pass in priv instead of mtd to make it more like the Linux driver.
It's best to avoid gratuitous differences.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCHv5 15/17] armv8: ls2080a: Enable PCIe in defconfigs
On Tue, 2016-12-13 at 14:54 +0800, Zhiqiang Hou wrote: > From: Minghuan Lian > > The patch enables PCIe in ls2080a defconfigs and > removes unused PCIe related macro defines. > > Signed-off-by: Minghuan Lian > Signed-off-by: Hou Zhiqiang > --- > V5: > - No change As of this patch, PCIe ethernet stopped working in Linux (4.10-rc2) on ls2080ardb. The e1000e does get probed, but no interrupts are ever seen. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] booti: Set images.os.arch
Commit ec6617c39741adc6c549 ("armv8: Support loading 32-bit OS in AArch32
execution state") broke SMP boot by assuming that an image is 32-bit if
the arch field in the spin table != IH_ARCH_DEFAULT (i.e.
IH_ARCH_ARM64), even if the arch field also does not match IH_ARCH_ARM,
even though nothing actually set the arch field in the spin table.
Commit e2c18e40b111470f ("armv8: fsl-layerscape: SMP support for loading
32-bit OS") fixed this for bootm by setting the arch field of the spin
table based on images.os.arch, but booti remaineed broken because it did
not set images.os.arch.
Fixes: ec6617c39741adc6c549 ("armv8: Support loading 32-bit OS in AArch32
execution state")
Fixes: e2c18e40b111 ("armv8: fsl-layerscape: SMP support for loading 32-bit OS")
Cc: Alison Wang
Cc: Chenhui Zhao
Cc: York Sun
Cc: Stuart Yoder
Signed-off-by: Scott Wood
---
cmd/booti.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/cmd/booti.c b/cmd/booti.c
index 2d879f3..bff87a8 100644
--- a/cmd/booti.c
+++ b/cmd/booti.c
@@ -131,6 +131,7 @@ int do_booti(cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
bootm_disable_interrupts();
images.os.os = IH_OS_LINUX;
+ images.os.arch = IH_ARCH_ARM64;
ret = do_bootm_states(cmdtp, flag, argc, argv,
#ifdef CONFIG_SYS_BOOT_RAMDISK_HIGH
BOOTM_STATE_RAMDISK |
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] armv8/fsl-layerscape: fdt: remove SYSCLK frequency fixup for ls1012a
On Fri, 2017-01-20 at 21:38 +, york sun wrote:
> On 01/20/2017 01:36 PM, Scott Wood wrote:
> >
> > On Fri, 2017-01-20 at 16:28 +, york sun wrote:
> > >
> > > On 01/19/2017 07:34 PM, Yangbo Lu wrote:
> > > >
> > > >
> > > > Generally SYSCLK frequency is dependent on on-board switch settings.
> > > > It may vary as per requirement, but this doesn't apply to ls1012a.
> > > > ls1012a has its SYSCLK frequencies specified in the RM. The fixup
> > > > for all 'fixed-clock' compatibles of ls1012a would cause incorrect
> > > > SYSCLK frequency values. So remove the SYSCLK frequency fixup for
> > > > ls1012a.
> > > >
> > > > Fixes: 6f14e25 ("armv8: fsl-lsch3: fixup SYSCLK frequency in device
> > > > tree")
> > > > Signed-off-by: Yangbo Lu
> > > > ---
> > > > arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 2 ++
> > > > 1 file changed, 2 insertions(+)
> > > >
> > > > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > > > b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > > > index c10ccf9..e59c232 100644
> > > > --- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > > > +++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > > > @@ -161,8 +161,10 @@ void ft_cpu_setup(void *blob, bd_t *bd)
> > > > "clock-frequency",
> > > > CONFIG_SYS_NS16550_CLK,
> > > > 1);
> > > > #endif
> > > >
> > > > +#ifndef CONFIG_ARCH_LS1012A
> > > > do_fixup_by_compat_u32(blob, "fixed-clock",
> > > > "clock-frequency",
> > > > CONFIG_SYS_CLK_FREQ,
> > > > 1);
> > > > +#endif
> > > >
> > > > #ifdef CONFIG_PCI
> > > > ft_pci_setup(blob, bd);
> > > >
> > > Yangbo,
> > >
> > > Why fixing up this clock causes incorect frequency value? The macro
> > > CONFIG_SYS_CLK_FREQ is defined as 125MHz for ls1012a.
> > Because ls1012a has two different input frequencies -- 125 MHz for the
> > platform PLL and 100 MHz for the core PLLs. When we added a second fixed-
> > clock node for the latter, U-Boot was overwriting it.
> >
> > While the ifdef solves this immediate problem, it doesn't fix the
> > underlying
> > problem that this fixup is overly broad. It should identify the specific
> > node
> > it's looking for, and not overwrite every fixed-clock node it finds.
> >
> So current code tries to fix up any node with "fixed-clock"? That's not
> good. What if we have multiple fixed clocks?
>
That is exactly the problem. This patch avoids the issue on ls1012a but not
in general.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] armv8/fsl-layerscape: fdt: remove SYSCLK frequency fixup for ls1012a
On Fri, 2017-01-20 at 16:28 +, york sun wrote:
> On 01/19/2017 07:34 PM, Yangbo Lu wrote:
> >
> > Generally SYSCLK frequency is dependent on on-board switch settings.
> > It may vary as per requirement, but this doesn't apply to ls1012a.
> > ls1012a has its SYSCLK frequencies specified in the RM. The fixup
> > for all 'fixed-clock' compatibles of ls1012a would cause incorrect
> > SYSCLK frequency values. So remove the SYSCLK frequency fixup for ls1012a.
> >
> > Fixes: 6f14e25 ("armv8: fsl-lsch3: fixup SYSCLK frequency in device tree")
> > Signed-off-by: Yangbo Lu
> > ---
> > arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > index c10ccf9..e59c232 100644
> > --- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > +++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > @@ -161,8 +161,10 @@ void ft_cpu_setup(void *blob, bd_t *bd)
> > "clock-frequency", CONFIG_SYS_NS16550_CLK,
> > 1);
> > #endif
> >
> > +#ifndef CONFIG_ARCH_LS1012A
> > do_fixup_by_compat_u32(blob, "fixed-clock",
> > "clock-frequency", CONFIG_SYS_CLK_FREQ,
> > 1);
> > +#endif
> >
> > #ifdef CONFIG_PCI
> > ft_pci_setup(blob, bd);
> >
> Yangbo,
>
> Why fixing up this clock causes incorect frequency value? The macro
> CONFIG_SYS_CLK_FREQ is defined as 125MHz for ls1012a.
Because ls1012a has two different input frequencies -- 125 MHz for the
platform PLL and 100 MHz for the core PLLs. When we added a second fixed-
clock node for the latter, U-Boot was overwriting it.
While the ifdef solves this immediate problem, it doesn't fix the underlying
problem that this fixup is overly broad. It should identify the specific node
it's looking for, and not overwrite every fixed-clock node it finds.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] cmd/nand.c: Debug additional helpful NAND info
On Mon, 2016-10-10 at 06:08 +0200, Ahmed Samir Khalil wrote:
> While dealing with large chips (e.g. page: 4KB, OOB:224),
> we found it helpful to get these additional NAND info by
> enabling the DEBUG macro instead of full tracing every time
> and consuming time. Especially about the currently in use
> scheme for testing & development.
>
> Signed-off-by: Ahmed Samir Khalil
> ---
> cmd/nand.c | 26 ++
> 1 file changed, 26 insertions(+)
>
> diff --git a/cmd/nand.c b/cmd/nand.c
> index c16ec77..ec7f1df 100644
> --- a/cmd/nand.c
> +++ b/cmd/nand.c
> @@ -283,6 +283,9 @@ usage:
>
> static void nand_print_and_set_info(int idx)
> {
> +#ifdef DEBUG
> + unsigned int i;
> +#endif
> struct mtd_info *mtd = nand_info[idx];
> struct nand_chip *chip = mtd_to_nand(mtd);
>
> @@ -298,6 +301,29 @@ static void nand_print_and_set_info(int idx)
> printf(" options 0x%8x\n", chip->options);
> printf(" bbt options 0x%8x\n", chip->bbt_options);
>
> +#ifdef DEBUG
> + printf(" Chip delay %7d us\n", chip->chip_delay);
> + printf(" ECC bytes %8d b\n", nand->ecclayout->eccbytes);
> + printf(" OOB available %6d b\n\n", nand->ecclayout->oobavail);
> +
> + printf(" OOB free = {\n");
> + for (i=0; i < nand->ecclayout->oobfree[i].length; i++) {
> + if( !(nand->ecclayout->oobfree[i].offset<0) )
> + printf("{.offset=%d, ", nand->ecclayout-
> >oobfree[i].offset);
> +
> + if( !(nand->ecclayout->oobfree[i].length<0) )
> + printf(".length=%d}, \n", nand->ecclayout-
> >oobfree[i].length);
> + }
Please use standard U-Boot coding style.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] nand: force BBT scan for controllers which need it
On Wed, 2016-10-26 at 17:18 -0700, Stefan Agner wrote:
> From: Stefan Agner
>
> Commit 35c204d8a9d0 ("nand: reinstate lazy bad block scanning")
> introduced lazy BBT scanning. However, some controller do parts
> of the initialization (mxs_nand.c) during scan_bbt, hence for
> those controllers the BBT must be scanned at initialization time.
>
> In most situation the U-Boot environment gets read first, and
> the U-Boot environment code checks for bad blocks first. Checking
> for bad blocks will ask for scan_bbt before reading the first page,
> hence in most situation the issue does not appear in practice.
> However, when there is no environment configured, other code might
> access NAND first which does not explicitly checks for bad blocks,
> in those cases ECC reads will fail always.
>
> Cc: Rostislav Lisovy
> Signed-off-by: Stefan Agner
> ---
> Not sure if this solution is a nice solution as we diverge more
> and more from the kernel...
Why does this init code need to run at the end of nand_scan_tail()? If it can
run in between nand_scan_ident() and nand_scan_tail(), then use
CONFIG_SYS_NAND_SELF_INIT to allow the driver to run its init at that time.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/7] nand: sunxi: Add options for the SPL NAND configuration
On Tue, 2016-11-08 at 17:21 +0100, Maxime Ripard wrote: > The SPL image needs to be built with a different ECC configuration than the > U-Boot binary. > > Add Kconfig options with defaults to provide a value that should work for > anyone, but is still configurable if needs be. > > Signed-off-by: Maxime Ripard > --- > drivers/mtd/nand/Kconfig | 16 > 1 file changed, 16 insertions(+), 0 deletions(-) Acked-by: Scott Wood -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/7] mtd: nand: add support for the TC58NVG2S0H chip
On Tue, 2016-11-08 at 17:21 +0100, Maxime Ripard wrote: > From: Boris Brezillon > > Add the description of the Toshiba TC58NVG2S0H SLC nand to the nand_ids > table so we can use the NAND ECC infos and the ONFI timings. > > Signed-off-by: Boris Brezillon > Signed-off-by: Maxime Ripard > --- > drivers/mtd/nand/nand_ids.c | 3 +++ > 1 file changed, 3 insertions(+), 0 deletions(-) Acked-by: Scott Wood -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] FSL PowerPC platform: Not able to boot Linux with ramdisk size > 100MB
On 10/27/2016 04:27 AM, Prabhakar Kushwaha wrote: > Hi Masahiro, > > I am not able to boot Linux onF PowerPC platform with ramdisk size > 100MB. > I tried u-boot master with top commit as " > 5ac5861c4ba851b473e6a24940b412b397627d8d ". > > I tried git-bisect and figured out below patch causing this problem. If I > revert this patch, Linux boots properly. > > commit 20e072f37402c17741f67d9693eaabdd835b80f2 > Author: Masahiro Yamada > Date: Thu Dec 17 17:19:35 2015 +0900 > > image: check "bootm_low" and "bootm_size" if "initrd_high" is missing > > To boot Linux, we should prevent Initramdisk and FDT from going too > high. > > Currently, boot_relocate_fdt() checks "fdt_high" environment first, > and then falls back to getenv_bootm_mapsize() + getenv_bootm_low() > if "fdt_high" is missing. > > On the other hand, boot_ramdisk_high() only checks "initrd_high" to > get the address limit for the Initramdisk. We also want to let this > case fall back to getenv_bootm_mapsize() + getenv_bootm_low(). > > Signed-off-by: Masahiro Yamada > > Please advise!! On PPC the initrd does not need to be loaded within the boot mapping. This assumption of what the absence of initrd_high means is not universally appropriate. Why not just set initrd_high on the platforms that need it? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fsl_qman: Implement device tree fixup for QBMan on ARM processors
On Wed, 2016-10-26 at 10:01 -0400, Roy Pledge wrote:
> Add support for device tree fixup for the DPAA1 QBMan nodes in ARM platforms
>
> Signed-off-by: Roy Pledge
> ---
> arch/arm/cpu/armv8/fsl-layerscape/fdt.c| 89
>
> .../arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c |3 +
> .../include/asm/arch-fsl-layerscape/immap_lsch2.h |2 +
> include/configs/ls1043a_common.h |2 +
> 4 files changed, 96 insertions(+)
>
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> index 1a8321b..aedf0e7 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> @@ -25,6 +25,8 @@
> #ifdef CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT
> #include
> #endif
> +#include
> +#include
>
> int fdt_fixup_phy_connection(void *blob, int offset, phy_interface_t phyc)
> {
> @@ -32,6 +34,80 @@ int fdt_fixup_phy_connection(void *blob, int offset,
> phy_interface_t phyc)
> phy_string_for_interface(phyc));
> }
>
> +#if defined(CONFIG_SYS_DPAA_QBMAN)
> +
> +#define BMAN_IP_REV_1 0xBF8
> +#define BMAN_IP_REV_2 0xBFC
> +void fdt_fixup_bportals(void *blob)
> +{
> + int off, err;
> + unsigned int maj, min;
> + unsigned int ip_cfg;
> +
> + u32 rev_1 = in_be32(CONFIG_SYS_FSL_BMAN_ADDR + BMAN_IP_REV_1);
> + u32 rev_2 = in_be32(CONFIG_SYS_FSL_BMAN_ADDR + BMAN_IP_REV_2);
> + char compat[64];
> + int compat_len;
> +
> + maj = (rev_1 >> 8) & 0xff;
> + min = rev_1 & 0xff;
> +
> + ip_cfg = rev_2 & 0xff;
> +
> + compat_len = sprintf(compat, "fsl,bman-portal-%u.%u.%u",
> + maj, min, ip_cfg) + 1;
> + compat_len += sprintf(compat + compat_len, "fsl,bman-portal") + 1;
> +
> + off = fdt_node_offset_by_compatible(blob, -1, "fsl,bman-portal");
> + while (off != -FDT_ERR_NOTFOUND) {
> + err = fdt_setprop(blob, off, "compatible", compat,
> compat_len);
> + if (err < 0) {
> + printf("ERROR: unable to create props for %s:
> %s\n",
> + fdt_get_name(blob, off, NULL),
> + fdt_strerror(err));
> + return;
> + }
> +
> + off = fdt_node_offset_by_compatible(blob, off,
> + "fsl,bman-portal");
> + }
> +}
Please share code with PPC rather than duplicating it.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1]: add nand_bootupdate for i.MX6 and likes
On Wed, 2016-10-05 at 12:57 -0700, Sergey Kubushyn wrote:
> This one adds nand_bootupdate command for i.MX6 and similar MCUs. It
> generates proper NAND boot structures (FCB, DBBT, etc) and writes those
> along with U-Boot mx image to where they belong so system would be able
> to boot off of raw NAND.
This seems like a lot of code just to write some images to various places.
What are these "NAND boot structures" and do they really need to be generated
by U-Boot, or can they be generated by a tool to produce an image that U-Boot
writes to NAND as is? I do see there are some things to be filled in based on
NAND parameters, bad blocks, etc. but can this patching up be minimized (and
the necessary parts explained in the changelog)?
> This is my THIRD attempt to get it into the main U-Boot tree. I do
> really hope it would get applied before I retire.
It helps to CC relevant people...
> Signed-off-by: Sergey Kubushyn
> ---
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -571,6 +571,16 @@ config CMD_TIME
> help
> Run commands and summarize execution time.
>
> +config CMD_NAND_BOOTUPDATE
> + bool "Update NAND bootloader on iMX6 and its brethen"
> + depends on ARCH_MX6 && NAND_BOOT && CMD_NAND
Why does a hardware-specific option have a generic name?
> + help
> + Having iMX6 NAND U-Boot image in memory creates all necessary
> + structures and writes those where they belong along with that
> + U-Boot image so system is able to boot off of raw NAND. Kinda
> + like kobs-ng utility but simpler.
> +
> +
> # TODO: rename to CMD_SLEEP
> config CMD_MISC
> bool "sleep"
>
> --- a/drivers/mtd/nand/Makefile
> +++ b/drivers/mtd/nand/Makefile
> @@ -67,6 +67,7 @@ obj-$(CONFIG_NAND_OMAP_GPMC) += omap_gpmc.o
> obj-$(CONFIG_NAND_OMAP_ELM) += omap_elm.o
> obj-$(CONFIG_NAND_PLAT) += nand_plat.o
> obj-$(CONFIG_NAND_SUNXI) += sunxi_nand.o
> +obj-$(CONFIG_CMD_NAND_BOOTUPDATE) += mxs_nand_bootupdate.o
This looks like your mailer mangled the whitespace in the patch, or else it
was generated strangely... Why not use git to generate patches? That would
also help with conflicts due to the SHA1 info.
>
> else # minimal SPL drivers
>
> --- a/drivers/mtd/nand/mxs_nand.c
> +++ b/drivers/mtd/nand/mxs_nand.c
> @@ -26,6 +26,7 @@
> #include
> #include
> #include
> +#include
>
> #define MXS_NAND_DMA_DESCRIPTOR_COUNT 4
>
> @@ -150,7 +151,7 @@ static uint32_t mxs_nand_aux_status_offset(void)
> return (MXS_NAND_METADATA_SIZE + 0x3) & ~0x3;
> }
>
> -static inline uint32_t mxs_nand_get_ecc_strength(uint32_t page_data_size,
> +uint32_t mxs_nand_get_ecc_strength(uint32_t page_data_size,
> uint32_t page_oob_size)
Please adjust the continuation line to align with the line you modified.
> +#ifndef CONFIG_CMD_MTDPARTS
> +#error "CONFIG_CMD_MTDPARTS is not set, mtd partition support missing"
> +#endif
If this is an error then use kconfig to express the dependency.
> +
> +static const char *uboot_tgt = "nand0,0";
This is only used in one place, and you hardcode "nand0" elsewhere, so why not
just put the string where it's used?
> +static ssize_t raw_write_page(struct mtd_info *mtd, void *buf, loff_t
> offset)
> +{
> + struct mtd_oob_ops ops;
> + ssize_t ret;
> +
> + ops.mode = MTD_OPS_RAW;
> + ops.ooboffs = 0;
> + ops.datbuf = buf;
> + ops.len = mtd->writesize;
> + ops.oobbuf = buf + mtd->writesize;
> + ops.ooblen = mtd->oobsize;
> + ret = mtd_write_oob(mtd, offset, &ops);
> +
> +return ret;
> +}
Whitespace.
Is the raw access needed because certain boot blocks use different ECC than
the rest? It would be nice to handle this by having the driver apply the
proper ECC to each region, rather than having the caller do the ECC manually.
> +/* Erase entire U-Boot partition */
> +static int mxs_nand_uboot_erase(struct mtd_info *mtd, struct part_info
> *part)
> +{
> + uint64_toffset = 0;
> + struct erase_info erase;
> + int len = part->size;
> + int ret;
> +
> + while (len > 0) {
> + pr_debug("erasing at 0x%08llx\n", offset);
> + if (mtd_block_isbad(mtd, offset)) {
> + pr_debug("erase skip block @ 0x%08llx\n", offset);
> + offset += mtd->erasesize;
> + continue;
> + }
> +
> + memset(&erase, 0, sizeof(erase));
> + erase.addr = offset;
> + erase.len = mtd->erasesize;
> +
> + ret = mtd_erase(mtd, &erase);
> + if (ret)
> + return ret;
> +
> + offset += mtd->erasesize;
> + len -= mtd->erasesize;
> + }
> +
> + return 0;
> +}
What's wrong with nand_erase_opts()?
> +
> +/* Write the U-Boot proper (2 copies) to where it belongs. */
> +/* This is U-Boot binary image itself, n
Re: [U-Boot] [PATCH 16/16] README: Fix CONFIG_SYS_NAND_MAX_DEVICE typo
On Sun, 2016-10-02 at 18:01 -0600, Simon Glass wrote: > This should be CONFIG_SYS_MAX_NAND_DEVICE. Fix it. > > Signed-off-by: Simon Glass > --- > > doc/README.nand | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/doc/README.nand b/doc/README.nand > index f1c20ff..2295bb2 100644 > --- a/doc/README.nand > +++ b/doc/README.nand > @@ -160,7 +160,7 @@ Configuration Options: > > /* > * devnum is the device number to be used in nand commands > - * and in mtd->name. Must be less than CONFIG_SYS_NAND_MAX_DEVICE. > + * and in mtd->name. Must be less than CONFIG_SYS_MAX_NAND_DEVICE. > */ > if (nand_register(devnum, mtd)) > error out Acked-by: Scott Wood -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Rearrange CONFIG_* macros
On Fri, 2016-09-30 at 22:24 -0400, Tom Rini wrote: > On Fri, Sep 30, 2016 at 04:20:10AM +, york sun wrote: > > > > On 09/29/2016 08:59 PM, Masahiro Yamada wrote: > > > > > > If X86 and FSL are the only platforms that have interest in this > > > option, > > > we can save HAVE_... and put them directly in "depends on". > > > > > > config MAX_CPUS > > > int "Maximum number of CPUs permitted" > > > depends on (SMP && X86) || VENDOR_FSL > > > > > > I am not quite sure about "VENDOR_FSL", > > > so please choose your favorite one like > > > SOC_FSL, PLAT_FSL, ARCH_FSL, or whatever. > > This sounds like a bandage. I can go with this if there is no better > > solution. > If MAX_CPUS has the same meaning in both cases, this isn't imho a > bandage but one of the cleanups that was hoped for in moving to Kconfig. > We see that a problem is encountered in more than one area more easily > and instead of letting N solutions accumulate we get one. It's the depends line that looks like a bandage -- can't it just be "depends on SMP", and if there are any SMP platforms that can't be immediately converted to use this (e.g. the non-CONFIG MAX_CPUS define in arch/arm/cpu/armv7/mx6/mp.c should be pretty easily convertible), add a TODO note in the help text indicating that? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] fsl-ifc-nand : Corrected the programming of chip select
On 09/26/2016 09:48 PM, Matt Weber wrote:
> Corrected the chip selection in IFC_NAND_CSEL register. Due to this
> issue in multi-chip nand use-case, IFC was always pointing to the last
> probed chip even though the user select another device through "nand
> device " command.
>
> Also, remove the usage of ifc_ctrl->cs_nand from driver as chipselect
> is a property of the chip not the controller.
>
> Signed-off-by: Matthew Weber
> Signed-off-by: Ronak Desai
>
> --
> v1 -> v2
> [ Scott W
> - Update fsl_ifc_sram_init() with correct csel and
>cs_nand removed.
>
> v2 -> v3
> [ Prabhakar
> - Remove braces around if in fsl_ifc_chip_init()
> ---
> drivers/mtd/nand/fsl_ifc_nand.c | 16 +++-
> 1 file changed, 7 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/mtd/nand/fsl_ifc_nand.c b/drivers/mtd/nand/fsl_ifc_nand.c
> index bc6bdc9..990b698 100644
> --- a/drivers/mtd/nand/fsl_ifc_nand.c
> +++ b/drivers/mtd/nand/fsl_ifc_nand.c
> @@ -48,7 +48,7 @@ struct fsl_ifc_ctrl {
> /* device info */
> struct fsl_ifc regs;
> void __iomem *addr; /* Address of assigned IFC buffer*/
> - unsigned int cs_nand;/* On which chipsel NAND is connected*/
> + unsigned int cs_nand;/* On which chipsel NAND is connected*/
> unsigned int page; /* Last page written to / read from */
> unsigned int read_bytes; /* Number of bytes read during command */
> unsigned int column; /* Saved column from SEQIN */
Changelog says you removed cs_nand, but this hunk just changes whitespace.
> @@ -798,7 +798,7 @@ static void fsl_ifc_select_chip(struct mtd_info *mtd, int
> chip)
> {
> }
>
> -static int fsl_ifc_sram_init(uint32_t ver)
> +static int fsl_ifc_sram_init(uint32_t ver, struct fsl_ifc_mtd *priv)
Could you put priv first, as is usually done with context structs?
I notice Linux doesn't pass "ver" at all to this function, and only
implements the ver == 1.1.0 method. Prabhakar, any plans to update
Linux for that?
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arch: ifc: update the IFC IP input clock
On 09/22/2016 03:55 AM, Prabhakar Kushwaha wrote: > Hi Scott, > > Sorry for late reply on this thread > > >> -Original Message- >> From: Scott Wood >> Sent: Friday, September 09, 2016 7:30 AM >> To: Prabhakar Kushwaha ; york sun >> ; u-boot@lists.denx.de >> Subject: Re: [PATCH] arch: ifc: update the IFC IP input clock >> >> On 09/08/2016 08:46 PM, Prabhakar Kushwaha wrote: >>> >>>> -Original Message- >>>> From: Scott Wood >>>> Sent: Friday, September 09, 2016 6:05 AM >>>> To: Prabhakar Kushwaha ; york sun >>>> ; u-boot@lists.denx.de >>>> Subject: Re: [PATCH] arch: ifc: update the IFC IP input clock >>>> >>>> On 09/08/2016 07:05 PM, Prabhakar Kushwaha wrote: >>>>> >>>>>> -Original Message- >>>>>> From: york sun >>>>>> Sent: Thursday, September 08, 2016 9:22 PM >>>>>> To: Prabhakar Kushwaha ; u- >>>>>> b...@lists.denx.de; Scott Wood >>>>>> Subject: Re: [PATCH] arch: ifc: update the IFC IP input clock >>>>>> >>>>>> On 09/08/2016 02:33 AM, Prabhakar Kushwaha wrote: >>>>>> >>>>>> >>>>>> >>>>>>>>> So better to print IP clock to avoid any confusion. >>>>>>>>> IFC output clock will be printed when it is actually being used during >>>>>>>> synchronous NOR, syn NAND. >>>>>>>> >>>>>>>> I am not against changing it to internal clock. But what are you going >>>>>>>> to print on the console? I think it is confusing to say IFC or local >>>>>>>> bus >>>>>>>> internal clock speed. Please also check how this clock is used and make >>>>>>>> sure arch.lbc_clk is still correct, after passing to Linux. >>>>>>>> >>>>>>> arch.lbc_clk is only being used for eLBC for device tree fixup. >>>>>>> And I checked the Linux eLBC driver. Looks like it is not using used. >>>>>>> >>>>>> >>>>>> If this clock is not used, can we drop it completely? >>>>>> >>>>> >>>>> From my point of view Yes. >>>>> >>>>> Scott, Please advice >>>> >>>> Well, there is that patch from Matt Weber that is trying to guess the >>>> IFC frequency in order to use NWAIT... Not sure if we'll end up >>>> actually using NWAIT >>> (Prabhakar, can you answer my question of whether >>>> there is a better opcode to use with RNDOUT?) or ever sending a real >>>> RNDOUT, or if we'll ever care about these newer NAND chips on eLBC, but >>>> if U-Boot is currently writing the clock frequency into the device tree >>>> I don't see why we'd rip it out. >>>> >>> >>> IFC frequency means IP clock or IP output clock? >> >> External bus clock. Which is currently being written to the device tree? >> >>> If IP clock then other patch for eLBC still valid. >> >> What other patch? >> >>> >>> For IFC: Code needs to be added for device tree fixup for PowerPC, ARM SoC. >>> It is missing for now :( >> >> No, we don't want to introduce new clock-frequency fixups. If we need >> this on IFC we should add a clocks property. But if we already have >> clock-frequency on eLBC then no reason not to use that if needed. >> > I am not against keeping " bus-frequency" on eLBC. (U-boot fixup > bus-frequency not clock-frequncy) > > But the value which is getting assigned to " bus-frequency" is not right. > Currently, it is setting SYSCLK/LCRR i.e. output clock where eLBC run at CCB > or CCB/2. > So, if we want to have " bus-frequency " on eLBC then it needs to be > corrected. If the fixup is not correct then just remove it. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arch: ifc: update the IFC IP input clock
On 09/08/2016 08:46 PM, Prabhakar Kushwaha wrote: > >> -Original Message- >> From: Scott Wood >> Sent: Friday, September 09, 2016 6:05 AM >> To: Prabhakar Kushwaha ; york sun >> ; u-boot@lists.denx.de >> Subject: Re: [PATCH] arch: ifc: update the IFC IP input clock >> >> On 09/08/2016 07:05 PM, Prabhakar Kushwaha wrote: >>> >>>> -Original Message- >>>> From: york sun >>>> Sent: Thursday, September 08, 2016 9:22 PM >>>> To: Prabhakar Kushwaha ; u- >>>> b...@lists.denx.de; Scott Wood >>>> Subject: Re: [PATCH] arch: ifc: update the IFC IP input clock >>>> >>>> On 09/08/2016 02:33 AM, Prabhakar Kushwaha wrote: >>>> >>>> >>>> >>>>>>> So better to print IP clock to avoid any confusion. >>>>>>> IFC output clock will be printed when it is actually being used during >>>>>> synchronous NOR, syn NAND. >>>>>> >>>>>> I am not against changing it to internal clock. But what are you going >>>>>> to print on the console? I think it is confusing to say IFC or local bus >>>>>> internal clock speed. Please also check how this clock is used and make >>>>>> sure arch.lbc_clk is still correct, after passing to Linux. >>>>>> >>>>> arch.lbc_clk is only being used for eLBC for device tree fixup. >>>>> And I checked the Linux eLBC driver. Looks like it is not using used. >>>>> >>>> >>>> If this clock is not used, can we drop it completely? >>>> >>> >>> From my point of view Yes. >>> >>> Scott, Please advice >> >> Well, there is that patch from Matt Weber that is trying to guess the >> IFC frequency in order to use NWAIT... Not sure if we'll end up >> actually using NWAIT > (Prabhakar, can you answer my question of whether >> there is a better opcode to use with RNDOUT?) or ever sending a real >> RNDOUT, or if we'll ever care about these newer NAND chips on eLBC, but >> if U-Boot is currently writing the clock frequency into the device tree >> I don't see why we'd rip it out. >> > > IFC frequency means IP clock or IP output clock? External bus clock. Which is currently being written to the device tree? > If IP clock then other patch for eLBC still valid. What other patch? > > For IFC: Code needs to be added for device tree fixup for PowerPC, ARM SoC. > It is missing for now :( No, we don't want to introduce new clock-frequency fixups. If we need this on IFC we should add a clocks property. But if we already have clock-frequency on eLBC then no reason not to use that if needed. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arch: ifc: update the IFC IP input clock
On 09/08/2016 07:05 PM, Prabhakar Kushwaha wrote: > >> -Original Message- >> From: york sun >> Sent: Thursday, September 08, 2016 9:22 PM >> To: Prabhakar Kushwaha ; u- >> b...@lists.denx.de; Scott Wood >> Subject: Re: [PATCH] arch: ifc: update the IFC IP input clock >> >> On 09/08/2016 02:33 AM, Prabhakar Kushwaha wrote: >> >> >> >>>>> So better to print IP clock to avoid any confusion. >>>>> IFC output clock will be printed when it is actually being used during >>>> synchronous NOR, syn NAND. >>>> >>>> I am not against changing it to internal clock. But what are you going >>>> to print on the console? I think it is confusing to say IFC or local bus >>>> internal clock speed. Please also check how this clock is used and make >>>> sure arch.lbc_clk is still correct, after passing to Linux. >>>> >>> arch.lbc_clk is only being used for eLBC for device tree fixup. >>> And I checked the Linux eLBC driver. Looks like it is not using used. >>> >> >> If this clock is not used, can we drop it completely? >> > > From my point of view Yes. > > Scott, Please advice Well, there is that patch from Matt Weber that is trying to guess the IFC frequency in order to use NWAIT... Not sure if we'll end up actually using NWAIT (Prabhakar, can you answer my question of whether there is a better opcode to use with RNDOUT?) or ever sending a real RNDOUT, or if we'll ever care about these newer NAND chips on eLBC, but if U-Boot is currently writing the clock frequency into the device tree I don't see why we'd rip it out. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fsl-ifc-nand : Corrected the programming of chip select
On 09/06/2016 02:31 PM, Ronak Desai wrote: > We don't need to update fsl_ifc_sram_init() as fsl_ifc_sram_init is > called from the fsl_ifc_chip_init which configures the ifc_ctrl->cs_nand > with correct value based on the chip-select under initialization. > > Best Regards, > Ronak Desai We don't *need* to but we should. Chipselect is a property of the chip, not the controller, so it doesn't belong in the controller struct (unless it's going to be updated per-transaction like page, column, etc. but we already have priv->bank so let's just use it). -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fsl-ifc-nand : Corrected the programming of chip select
On 09/06/2016 08:44 AM, Matt Weber wrote: > Corrected the chip selection in IFC_NAND_CSEL register. Due to this > issue in multi-chip nand use-case, IFC was always pointing to the last > probed chip even though the user select another device through "nand > device" command. > > Signed-off-by: Ronak Desai > Signed-off-by: Matthew Weber > --- > drivers/mtd/nand/fsl_ifc_nand.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/mtd/nand/fsl_ifc_nand.c b/drivers/mtd/nand/fsl_ifc_nand.c > index 7001cbd..2ce4a7d 100644 > --- a/drivers/mtd/nand/fsl_ifc_nand.c > +++ b/drivers/mtd/nand/fsl_ifc_nand.c > @@ -296,7 +296,7 @@ static int fsl_ifc_run_command(struct mtd_info *mtd) > int i; > > /* set the chip select for NAND Transaction */ > - ifc_out32(&ifc->ifc_nand.nand_csel, ifc_ctrl->cs_nand); > + ifc_out32(&ifc->ifc_nand.nand_csel, priv->bank << IFC_NAND_CSEL_SHIFT); > > /* start read/write seq */ > ifc_out32(&ifc->ifc_nand.nandseq_strt, Ouch. fsl_ifc_sram_init() should also be updated and cs_nand removed. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: nand flash
The following changes since commit cb1cbdd96962931de2ac948a184874e2672f3f96: x86: qemu: efi: Add two boards for EFI 32-bit and 64-bit payload (2016-08-30 09:26:05 +0800) are available in the git repository at: git://git.denx.de/u-boot-nand-flash.git for you to fetch changes up to 8b7d51249eca113c4965a7c417f33d7eb569434b: nand: Fix some more NULL name tests (2016-09-01 20:08:48 -0500) Chris Packham (1): mtd: nand: pxa3xx: use nand_set_controller_data Scott Wood (1): nand: Fix some more NULL name tests Tony Lindgren (1): nand: Fix nand info for no device cmd/nand.c | 8 drivers/dfu/dfu_nand.c | 4 ++-- drivers/mtd/nand/omap_gpmc.c | 2 +- drivers/mtd/nand/pxa3xx_nand.c | 1 + 4 files changed, 8 insertions(+), 7 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] nand: Fix some more NULL name tests
Now that nand_info[] is an array of pointers we need to test the
pointer itself rather than using name as a proxy for NULLness.
Fixes: b616d9b0a708eb9 ("nand: Embed mtd_info in struct nand_chip")
Signed-off-by: Scott Wood
Cc: Lukasz Majewski
Cc: Tony Lindgren
---
cmd/nand.c | 2 +-
drivers/dfu/dfu_nand.c | 4 ++--
drivers/mtd/nand/omap_gpmc.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/cmd/nand.c b/cmd/nand.c
index c25e25a..c16ec77 100644
--- a/cmd/nand.c
+++ b/cmd/nand.c
@@ -191,7 +191,7 @@ int do_nand_env_oob(cmd_tbl_t *cmdtp, int argc, char *const
argv[])
struct mtd_info *mtd = nand_info[0];
char *cmd = argv[1];
- if (CONFIG_SYS_MAX_NAND_DEVICE == 0 || !mtd->name) {
+ if (CONFIG_SYS_MAX_NAND_DEVICE == 0 || !mtd) {
puts("no devices available\n");
return 1;
}
diff --git a/drivers/dfu/dfu_nand.c b/drivers/dfu/dfu_nand.c
index 9fb874c..23f1571 100644
--- a/drivers/dfu/dfu_nand.c
+++ b/drivers/dfu/dfu_nand.c
@@ -39,7 +39,7 @@ static int nand_block_op(enum dfu_op op, struct dfu_entity
*dfu,
if (nand_curr_device < 0 ||
nand_curr_device >= CONFIG_SYS_MAX_NAND_DEVICE ||
- !nand_info[nand_curr_device]->name) {
+ !nand_info[nand_curr_device]) {
printf("%s: invalid nand device\n", __func__);
return -1;
}
@@ -148,7 +148,7 @@ static int dfu_flush_medium_nand(struct dfu_entity *dfu)
if (nand_curr_device < 0 ||
nand_curr_device >= CONFIG_SYS_MAX_NAND_DEVICE ||
- !nand_info[nand_curr_device]->name) {
+ !nand_info[nand_curr_device]) {
printf("%s: invalid nand device\n", __func__);
return -1;
}
diff --git a/drivers/mtd/nand/omap_gpmc.c b/drivers/mtd/nand/omap_gpmc.c
index 6e201d6..af618fc 100644
--- a/drivers/mtd/nand/omap_gpmc.c
+++ b/drivers/mtd/nand/omap_gpmc.c
@@ -899,7 +899,7 @@ int __maybe_unused omap_nand_switch_ecc(uint32_t hardware,
uint32_t eccstrength)
if (nand_curr_device < 0 ||
nand_curr_device >= CONFIG_SYS_MAX_NAND_DEVICE ||
- !nand_info[nand_curr_device]->name) {
+ !nand_info[nand_curr_device]) {
printf("nand: error: no NAND devices found\n");
return -ENODEV;
}
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] nand: Fix nand info for no device
On Mon, 2016-08-29 at 09:11 -0700, Tony Lindgren wrote: > Looks like we have few more places where we're testing for > nand_info[i]->name. We can now use just test for nand_info[i] > instead. > > This fixes a data abort on devices with no NAND when doing > nand info. > > Signed-off-by: Tony Lindgren > --- > cmd/nand.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) I also see a few instances of this in drivers/dfu/dfu_nand.c and drivers/mtd/nand/omap_gpmc.c. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] nand: Fix set_dev checks for no device
On Tue, 2016-08-23 at 15:21 -0700, Tony Lindgren wrote: > OK seems to work. Updated patch below. > > Regards, > > Tony > 8< - > From: Tony Lindgren > Date: Tue, 23 Aug 2016 15:14:26 -0700 > Subject: [PATCHv2] nand: Fix set_dev checks for no device Could you please send a standalone patch (no 8< --) generated by git, or at least that has the "diff" line? These aren't even showing up in patchwork as is. > If we do nand device 0 command in u-boot on a device that has NAND support > enabled but no NAND chip, we can get data abort at least on omaps. > > Fix the issue by replaceing the check with nand_info[dev] as > suggested by Scott Wood. "replacing the name check with..." -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] nand: Fix set_dev checks for no device
On Tue, 2016-08-23 at 15:04 -0700, Tony Lindgren wrote:
> * Scott Wood [160823 14:31]:
> >
> > On Tue, 2016-08-23 at 14:26 -0700, Tony Lindgren wrote:
> > >
> > > If we do nand device 0 command in u-boot on a device that has NAND
> > > support
> > > enabled but no NAND chip, we can get data abort at least on omaps.
> > >
> > > Fix the issue by adding a check for nand_info[dev].
> > >
> > > Signed-off-by: Tony Lindgren
> > > --- a/cmd/nand.c
> > > +++ b/cmd/nand.c
> > > @@ -116,7 +116,7 @@ free_dat:
> > > static int set_dev(int dev)
> > > {
> > > if (dev < 0 || dev >= CONFIG_SYS_MAX_NAND_DEVICE ||
> > > - !nand_info[dev]->name) {
> > > + !nand_info[dev] || !nand_info[dev]->name) {
> > > puts("No such device\n");
> > > return -1;
> > > }
> > The new !nand_info[dev] check can replace the old name check (similarly to
> > how
> > commit 4cc9699be7ffc replaced the old zero-blocksize check).
> Do you mean we can now leave out the test for !nand_info[dev]->name
> in set_dev() with this patch?
Yes. It existed before because before the array-to-pointer conversion there
was no way to directly test nand_info[dev] for emptiness.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] nand: Fix set_dev checks for no device
On Tue, 2016-08-23 at 14:26 -0700, Tony Lindgren wrote:
> If we do nand device 0 command in u-boot on a device that has NAND support
> enabled but no NAND chip, we can get data abort at least on omaps.
>
> Fix the issue by adding a check for nand_info[dev].
>
> Signed-off-by: Tony Lindgren
> --- a/cmd/nand.c
> +++ b/cmd/nand.c
> @@ -116,7 +116,7 @@ free_dat:
> static int set_dev(int dev)
> {
> if (dev < 0 || dev >= CONFIG_SYS_MAX_NAND_DEVICE ||
> - !nand_info[dev]->name) {
> + !nand_info[dev] || !nand_info[dev]->name) {
> puts("No such device\n");
> return -1;
> }
The new !nand_info[dev] check can replace the old name check (similarly to how
commit 4cc9699be7ffc replaced the old zero-blocksize check).
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] common: env_nand: Ensure that we have nand_info[0] prior to use
On Mon, 2016-08-15 at 13:02 -0400, Tom Rini wrote:
> Now that nand_info[] is an array of pointers we need to ensure that it's
> been populated prior to use. We may for example have ENV in NAND set in
> configurations that run on boards with and without NAND (where default
> env is fine enough, such as omap3_beagle and beagleboard (NAND) vs
> beagle xM (no NAND)).
>
> Fixes: b616d9b0a708 ("nand: Embed mtd_info in struct nand_chip")
> Cc: Scott Wood
> Signed-off-by: Tom Rini
> ---
> Changes in v3:
> - Don't overload the blocksize check in readenv(), and now that
> blocksize would never be zero (this was the previous way to see that
> we had no NAND detected), remove that check.
> - Address the CONFIG_ENV_OFFSET_OOB case in env_relocate_spec() as this
> too would fail now if no NAND was detected.
>
> Changes in v2:
> - Oops, move check on the saveenv side in to erase_and_write_env
> ---
> common/env_nand.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
Acked-by: Scott Wood
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] common: env_nand: Ensure that we have nand_info[0] prior to use
On Mon, 2016-08-15 at 11:56 -0400, Tom Rini wrote:
> Now that nand_info[] is an array of pointers we need to ensure that it's
> been populated prior to use. We may for example have ENV in NAND set in
> configurations that run on boards with and without NAND (where default
> env is fine enough, such as omap3_beagle and beagleboard (NAND) vs
> beagle xM (no NAND)).
>
> Fixes: b616d9b0a708 ("nand: Embed mtd_info in struct nand_chip")
> Cc: Scott Wood
> Signed-off-by: Tom Rini
> ---
> Changes in v2:
> - Oops, move check on the saveenv side in to erase_and_write_env
> ---
> common/env_nand.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/common/env_nand.c b/common/env_nand.c
> index fc99a5e3fc0d..96a1020b5e79 100644
> --- a/common/env_nand.c
> +++ b/common/env_nand.c
> @@ -163,6 +163,9 @@ static int erase_and_write_env(const struct env_location
> *location,
> {
> int ret = 0;
>
> + if (!nand_info[0])
> + return 1;
> +
> printf("Erasing %s...\n", location->name);
> if (nand_erase_opts(nand_info[0], &location->erase_opts))
> return 1;
> @@ -244,10 +247,12 @@ static int readenv(size_t offset, u_char *buf)
> {
> size_t end = offset + CONFIG_ENV_RANGE;
> size_t amount_loaded = 0;
> - size_t blocksize, len;
> + size_t blocksize = 0, len;
> u_char *char_ptr;
>
> - blocksize = nand_info[0]->erasesize;
> + if (nand_info[0])
> + blocksize = nand_info[0]->erasesize;
> +
> if (!blocksize)
> return 1;
>
Messing around with blocksize rather than directly returning is awkward -- it
makes it look as if you could proceed with blocksize zero until you read the
next statement. And is there ever a case where blocksize can be zero, now
that uninitialized NAND devices will simply have a NULL pointer?
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-mpc85xx master
On Fri, 2016-07-22 at 00:17 +, york sun wrote: > Scott Wood (1): > powerpc/85xx: Increase fdt address Any comment on the 86xx patches I sent around the same time? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: nand flash
The following changes since commit 29d63a59eaf1c9f3b37e249cda2a97e5e4f183f8: ARM: uniphier: add clock/reset settings for xHCI of ProXstream2 (2016-07-24 00:44:55 +0900) are available in the git repository at: git://git.denx.de/u-boot-nand-flash.git for you to fetch changes up to 59441ac3c135c412c679bdd1c82c8f2a9b805bbc: mtd: fix compiler warnings (2016-07-24 20:36:29 -0500) Boris Brezillon (7): cmd, nand: add an option to disable the verification when writing in raw mode sunxi: Add missing macros to configure the NAND controller clk mtd: nand: Add the sunxi NAND controller driver mtd: nand: Add a full-id entry for the H27QCG8T2E5R‐BCF NAND mtd: nand: Increase the max OOB size sunxi: nand: Increase CONFIG_SYS_NAND_MAX_ECCPOS value sunxi: Enable NAND controller on the CHIP Brian Norris (1): mtd: nand: add common DT init code Hector Palacios (1): mtd: nand: fix bug writing 1 byte less than page size Maxime Ripard (1): sun5i: Add NAND controller to the sun5i DTSI Steve Rae (1): mtd: fix compiler warnings arch/arm/dts/sun5i-a10s.dtsi | 14 + arch/arm/dts/sun5i-a13-olinuxino.dts | 15 + arch/arm/dts/sun5i-r8-chip.dts| 15 + arch/arm/dts/sun5i.dtsi | 49 + arch/arm/include/asm/arch-sunxi/clock_sun4i.h |5 + board/sunxi/board.c |5 +- cmd/mtdparts.c|4 +- cmd/nand.c| 15 +- drivers/mtd/nand/Kconfig |8 +- drivers/mtd/nand/Makefile |1 + drivers/mtd/nand/nand_base.c | 72 +- drivers/mtd/nand/nand_ids.c |4 + drivers/mtd/nand/sunxi_nand.c | 1845 + include/configs/sunxi-common.h|3 + include/fdtdec.h |1 + include/linux/mtd/mtd.h |5 + include/linux/mtd/nand.h |5 +- include/nand.h|3 + lib/fdtdec.c |1 + 19 files changed, 2057 insertions(+), 13 deletions(-) create mode 100644 drivers/mtd/nand/sunxi_nand.c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] cmd, nand: add an option to disable the verification when writing in raw mode
On Wed, Jun 15, 2016 at 10:42:18AM +0200, Boris Brezillon wrote:
> diff --git a/cmd/nand.c b/cmd/nand.c
> index 583a18f..3a5e3a0 100644
> --- a/cmd/nand.c
> +++ b/cmd/nand.c
> @@ -306,7 +306,7 @@ static void nand_print_and_set_info(int idx)
> }
>
> static int raw_access(struct mtd_info *mtd, ulong addr, loff_t off,
> - ulong count, int read)
> + ulong count, int read, int noverify)
> {
> int ret = 0;
>
> @@ -324,7 +324,7 @@ static int raw_access(struct mtd_info *mtd, ulong addr,
> loff_t off,
> ret = mtd_read_oob(mtd, off, &ops);
> } else {
> ret = mtd_write_oob(mtd, off, &ops);
> - if (!ret)
> + if (!ret && !no_verify)
> ret = nand_verify_page_oob(mtd, &ops, off);
"noverify" versus "no_verify"... I've fixed it while applying.
I assume/hope that you just sent an old version by mistake, and that this
was actually tested?
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/85xx: Increase fdt address
Loading the fdt at 0xc0 fails if the uncompressed kernel image is greater than 12 MiB, which is quite common with modern kernels and multiplatform defconfigs. Move fdtaddr to 0x1e0 which is just under the ramdiskaddr on most targets. Signed-off-by: Scott Wood Cc: Peter Tyser Cc: Dirk Eibach Cc: Andy Fleming Cc: Paul Gortmaker --- include/configs/B4860QDS.h | 4 ++-- include/configs/BSC9131RDB.h | 2 +- include/configs/BSC9132QDS.h | 2 +- include/configs/C29XPCIE.h | 2 +- include/configs/MPC8536DS.h | 2 +- include/configs/MPC8544DS.h | 2 +- include/configs/MPC8548CDS.h | 2 +- include/configs/MPC8572DS.h | 2 +- include/configs/P1010RDB.h | 2 +- include/configs/P1022DS.h| 2 +- include/configs/P1023RDB.h | 2 +- include/configs/P2041RDB.h | 2 +- include/configs/T102xRDB.h | 2 +- include/configs/T1040QDS.h | 2 +- include/configs/T104xRDB.h | 2 +- include/configs/T208xQDS.h | 2 +- include/configs/T208xRDB.h | 2 +- include/configs/T4240QDS.h | 2 +- include/configs/T4240RDB.h | 2 +- include/configs/controlcenterd.h | 2 +- include/configs/corenet_ds.h | 2 +- include/configs/cyrus.h | 2 +- include/configs/p1_p2_rdb_pc.h | 2 +- include/configs/p1_twr.h | 2 +- include/configs/sbc8548.h| 2 +- include/configs/xpedite1000.h| 2 +- include/configs/xpedite517x.h| 2 +- include/configs/xpedite520x.h| 2 +- include/configs/xpedite537x.h| 2 +- include/configs/xpedite550x.h| 2 +- 30 files changed, 31 insertions(+), 31 deletions(-) diff --git a/include/configs/B4860QDS.h b/include/configs/B4860QDS.h index 5249751..444a1fc 100644 --- a/include/configs/B4860QDS.h +++ b/include/configs/B4860QDS.h @@ -831,7 +831,7 @@ unsigned long get_board_ddr_clk(void); "consoledev=ttyS0\0"\ "ramdiskaddr=200\0" \ "ramdiskfile=b4860qds/ramdisk.uboot\0" \ - "fdtaddr=c0\0" \ + "fdtaddr=1e0\0" \ "fdtfile=b4860qds/b4860qds.dtb\0" \ "bdev=sda3\0" @@ -869,7 +869,7 @@ unsigned long get_board_ddr_clk(void); "setenv bootargs root=/dev/ram rw " \ "console=$consoledev,$baudrate $othbootargs;" \ "setenv ramdiskaddr 0x0200;" \ - "setenv fdtaddr 0x00c0;" \ + "setenv fdtaddr 0x01e0;" \ "setenv loadaddr 0x100;" \ "bootm $loadaddr $ramdiskaddr $fdtaddr" diff --git a/include/configs/BSC9131RDB.h b/include/configs/BSC9131RDB.h index b092933..9e56640 100644 --- a/include/configs/BSC9131RDB.h +++ b/include/configs/BSC9131RDB.h @@ -404,7 +404,7 @@ extern unsigned long get_sdram_size(void); "consoledev=ttyS0\0"\ "ramdiskaddr=200\0" \ "ramdiskfile=rootfs.ext2.gz.uboot\0"\ - "fdtaddr=c0\0" \ + "fdtaddr=1e0\0" \ "fdtfile=bsc9131rdb.dtb\0" \ "bdev=sda1\0" \ "hwconfig=usb1:dr_mode=host,phy_type=ulpi\0"\ diff --git a/include/configs/BSC9132QDS.h b/include/configs/BSC9132QDS.h index aaddfca..4ca9fc0 100644 --- a/include/configs/BSC9132QDS.h +++ b/include/configs/BSC9132QDS.h @@ -648,7 +648,7 @@ combinations. this should be removed later "consoledev=ttyS0\0"\ "ramdiskaddr=200\0" \ "ramdiskfile=rootfs.ext2.gz.uboot\0"\ - "fdtaddr=c0\0" \ + "fdtaddr=1e0\0" \ "fdtfile=bsc9132qds.dtb\0" \ "bdev=sda1\0" \ CONFIG_DEF_HWCONFIG\ diff --git a/include/configs/C29XPCIE.h b/include/configs/C29XPCIE.h index 1e5b501..a36e6be 100644 --- a/include/configs/C29XPCIE.h +++ b/include/configs/C29XPCIE.h @@ -531,7 +531,7 @@ "consoledev=ttyS0\0"\ "ramdiskaddr=200\0" \ "ramdiskfile=rootfs.ext2.gz.uboot\0"\ - "fdtaddr=c0\0" \ + "fdtaddr=1e0\0" \ "fdtfile=name/of/device-tree.dtb\0" \ "othbootargs=ramdisk_size=60\0" \ diff --git a/include/configs/MPC8536DS.h b/inclu
[U-Boot] [PATCH] powerpc/86xx: Increase boot map size to 256 MiB
This is what Linux maps on classic PPC during boot, and modern kernel images don't fit within the current 8 MiB uncompressed limit. Adjust image load addresses to be above this limit to avoid conflicts. Signed-off-by: Scott Wood --- include/configs/MPC8610HPCD.h | 13 +++-- include/configs/MPC8641HPCN.h | 9 + 2 files changed, 12 insertions(+), 10 deletions(-) diff --git a/include/configs/MPC8610HPCD.h b/include/configs/MPC8610HPCD.h index f6d45a9..a19f4ab 100644 --- a/include/configs/MPC8610HPCD.h +++ b/include/configs/MPC8610HPCD.h @@ -477,7 +477,8 @@ * have to be in the first 8 MB of memory, since this is * the maximum mapped by the Linux kernel during initialization. */ -#define CONFIG_SYS_BOOTMAPSZ (8 << 20) /* Initial Memory map for Linux*/ +#define CONFIG_SYS_BOOTMAPSZ (256 << 20) /* Initial Memory map for Linux*/ +#define CONFIG_SYS_BOOTM_LEN (256 << 20) /* Increase max gunzip size */ #if defined(CONFIG_CMD_KGDB) #define CONFIG_KGDB_BAUDRATE 230400 /* speed to run kgdb serial port */ @@ -498,7 +499,7 @@ #define CONFIG_NETMASK 255.255.255.0 /* default location for tftp and bootm */ -#define CONFIG_LOADADDR100 +#define CONFIG_LOADADDR0x1000 #define CONFIG_BOOTDELAY 10/* -1 disables auto-boot */ #undef CONFIG_BOOTARGS /* the boot command will set bootargs */ @@ -567,9 +568,9 @@ "cmp.b $loadaddr " __stringify(CONFIG_SYS_TEXT_BASE)\ " $filesize\0" \ "consoledev=ttyS0\0" \ -"ramdiskaddr=200\0"\ +"ramdiskaddr=0x1800\0" \ "ramdiskfile=8610hpcd/ramdisk.uboot\0" \ -"fdtaddr=c0\0" \ +"fdtaddr=0x17c0\0" \ "fdtfile=8610hpcd/mpc8610_hpcd.dtb\0" \ "bdev=sda3\0" \ "en-wd=mw.b f8100010 0x08; echo -expect:- 08; md.b f8100010 1\0" \ @@ -605,9 +606,9 @@ "netdev=eth0\0" \ "uboot=" __stringify(CONFIG_UBOOTPATH) "\0" \ "consoledev=ttyS0\0"\ - "ramdiskaddr=200\0" \ + "ramdiskaddr=0x1800\0" \ "ramdiskfile=8610hpcd/ramdisk.uboot\0" \ - "fdtaddr=c0\0" \ + "fdtaddr=0x17c0\0" \ "fdtfile=8610hpcd/mpc8610_hpcd.dtb\0" \ "bdev=sda3\0" #endif diff --git a/include/configs/MPC8641HPCN.h b/include/configs/MPC8641HPCN.h index 9b2623c..756bb29 100644 --- a/include/configs/MPC8641HPCN.h +++ b/include/configs/MPC8641HPCN.h @@ -637,7 +637,8 @@ extern unsigned long get_board_sys_clk(unsigned long dummy); * have to be in the first 8 MB of memory, since this is * the maximum mapped by the Linux kernel during initialization. */ -#define CONFIG_SYS_BOOTMAPSZ (8 << 20) /* Initial Memory map for Linux*/ +#define CONFIG_SYS_BOOTMAPSZ (256 << 20) /* Initial Memory map for Linux*/ +#define CONFIG_SYS_BOOTM_LEN (256 << 20) /* Increase max gunzip size */ #if defined(CONFIG_CMD_KGDB) #define CONFIG_KGDB_BAUDRATE 230400 /* speed to run kgdb serial port */ @@ -664,7 +665,7 @@ extern unsigned long get_board_sys_clk(unsigned long dummy); #define CONFIG_NETMASK 255.255.255.0 /* default location for tftp and bootm */ -#define CONFIG_LOADADDR100 +#define CONFIG_LOADADDR0x1000 #define CONFIG_BOOTDELAY 10/* -1 disables auto-boot */ #undef CONFIG_BOOTARGS /* the boot command will set bootargs */ @@ -686,9 +687,9 @@ extern unsigned long get_board_sys_clk(unsigned long dummy); "cmp.b $loadaddr " __stringify(CONFIG_SYS_TEXT_BASE)\ " $filesize\0" \ "consoledev=ttyS0\0"\ - "ramdiskaddr=200\0" \ + "ramdiskaddr=0x1800\0" \ "ramdiskfile=your.ramdisk.u-boot\0" \ - "fdtaddr=c0\0" \ + "fdtaddr=0x17c0\0" \ "fdtfile=mpc8641_hpcn.dtb\0"\ "en-wd=mw.b ffdf0010 0x08; echo -expect:- 08; md.b ffdf0010 1\0" \ "dis-wd=mw.b ffdf0010 0x00; echo -expect:- 00; md.b ffdf0010 1\0" \ -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/86xx: Pass -mcpu=7400 to GCC
Without this, GCC uses the toolchain default, which may be incompatible with -maltivec. Signed-off-by: Scott Wood --- arch/powerpc/cpu/mpc86xx/config.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/cpu/mpc86xx/config.mk b/arch/powerpc/cpu/mpc86xx/config.mk index 69a0b96..aefb0f1 100644 --- a/arch/powerpc/cpu/mpc86xx/config.mk +++ b/arch/powerpc/cpu/mpc86xx/config.mk @@ -5,4 +5,4 @@ # SPDX-License-Identifier: GPL-2.0+ # -PLATFORM_CPPFLAGS += -mstring -maltivec -mabi=altivec -msoft-float +PLATFORM_CPPFLAGS += -mcpu=7400 -mstring -maltivec -mabi=altivec -msoft-float -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/1] mtd: nand: fix bug writing 1 byte less than page size
On Fri, 2016-07-15 at 09:45 +0200, Hector Palacios wrote:
> nand_do_write_ops() determines if it is writing a partial page with the
> formula:
> part_pagewr = (column || writelen < (mtd->writesize - 1))
>
> When 'writelen' is exactly 1 byte less than the NAND page size the formula
> equates to zero, so the code doesn't process it as a partial write, although
> it should.
> As a consequence the function remains in the while(1) loop with 'writelen'
> becoming 0x and iterating until the watchdog timeout triggers.
>
> To reproduce the issue on a NAND with 2K page (0x800):
> => nand erase.part
> => nand write $loadaddr 7ff
>
> Signed-off-by: Hector Palacios
> ---
> drivers/mtd/nand/nand_base.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
> index 689716753ae6..c8be74849e56 100644
> --- a/drivers/mtd/nand/nand_base.c
> +++ b/drivers/mtd/nand/nand_base.c
> @@ -877,7 +877,7 @@ static int nand_wait(struct mtd_info *mtd, struct
> nand_chip *chip)
>
> u32 timer = (CONFIG_SYS_HZ * timeo) / 1000;
> u32 time_start;
> -
> +
> time_start = get_timer(0);
> while (get_timer(time_start) < timer) {
> if (chip->dev_ready) {
This change is unrelated.
> @@ -2411,7 +2411,7 @@ static int nand_do_write_ops(struct mtd_info *mtd,
> loff_t to,
> int cached = writelen > bytes && page != blockmask;
> uint8_t *wbuf = buf;
> int use_bufpoi;
> - int part_pagewr = (column || writelen < (mtd->writesize -
> 1));
> + int part_pagewr = (column || writelen < mtd->writesize);
>
> if (part_pagewr)
> use_bufpoi = 1;
>
Could you send a non-RFC patch? This also needs to get fixed in Linux.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v3 2/4] mtd: fix compiler warnings
On Sat, 2016-03-12 at 14:48 -0800, Steve Rae wrote: > - add missing declaration > - update debug output format specifiers > > Signed-off-by: Steve Rae > --- > the checkpatch warning: > warning: cmd/mtdparts.c,1494: quoted string split across lines > is for the existing code; it is not introduced with this change... > > Changes in v3: None > Changes in v2: None Why is this an RFC patch? It seems like an attempt to fix straightforward problems, unrelated to the iproc driver. > > diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h > index 9da77ec..9c36f02 100644 > --- a/include/linux/mtd/mtd.h > +++ b/include/linux/mtd/mtd.h > @@ -495,5 +495,13 @@ int mtd_arg_off(const char *arg, int *idx, loff_t *off, > loff_t *size, > int mtd_arg_off_size(int argc, char *const argv[], int *idx, loff_t *off, > loff_t *size, loff_t *maxsize, int devtype, > uint64_t chipsize); > + > +#ifdef CONFIG_CMD_MTDPARTS_SPREAD > +/* drivers/mtd/mtdcore.c */ > +void mtd_get_len_incl_bad(struct mtd_info *mtd, uint64_t offset, > + const uint64_t length, uint64_t *len_incl_bad, > + int *truncated); > +#endif /* CONFIG_CMD_MTDPARTS_SPREAD */ Don't ifdef prototypes. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fastboot: nand: fix compile error
On Mon, 2016-06-20 at 15:15 +0800, Peng Fan wrote: > Error info " > common/fb_nand.c: In function 'fb_nand_lookup': > common/fb_nand.c:65:3: error: 'mtd' undeclared (first use in this function) > *mtd = nand_info[dev->id->num]; > ^ > " > > Correct fb_nand_lookup parameter name to fix this issue. > > Signed-off-by: Peng Fan > Cc: Maxime Ripard > Cc: Scott Wood > Cc: Tom Rini > --- > common/fb_nand.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) I've already received and applied a patch for this. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: nand flash
The following changes since commit 667067faa18334f1e28c01b47530b5cce1b6182f: nand: fix nand torture to use changed mtd api (2016-06-03 20:29:05 -0500) are available in the git repository at: git://git.denx.de/u-boot-nand-flash.git for you to fetch changes up to 30780f948346436f9974fd6eae89aa2eb841b436: mtd: nand: Patch remaining places where nand_to_mtd() should be used (2016-06-19 19:28:38 -0500) Boris Brezillon (8): spl: nand: sunxi: remove support for so-called 'syndrome' mode spl: nand: rework SYS_NAND_U_BOOT_OFFS Kconfig option dependency spl: nand: support redundant u-boot image spl: nand: sunxi: stop guessing the redundant u-boot offset spl: nand: sunxi: rework status polling loop spl: nand: sunxi: split 'load page' and 'read page' logic spl: nand: sunxi: add support for NAND config auto-detection mtd: nand: Patch remaining places where nand_to_mtd() should be used Fabian Mewes (1): nand: doc: fix example ecc scheme calculation Max Krummenacher (2): nand: nand torture: follow sync with linux v4.6 nand: extend nand torture Sergey Kubushyn (1): common: fb_nand: won't compile cmd/nand.c | 41 ++- common/fb_nand.c| 2 +- common/spl/spl_nand.c | 7 + doc/README.nand | 10 +- drivers/mtd/nand/Kconfig| 21 +- drivers/mtd/nand/am335x_spl_bch.c | 2 +- drivers/mtd/nand/atmel_nand.c | 2 +- drivers/mtd/nand/lpc32xx_nand_mlc.c | 2 +- drivers/mtd/nand/mxs_nand_spl.c | 2 +- drivers/mtd/nand/nand_spl_simple.c | 2 +- drivers/mtd/nand/nand_util.c| 2 +- drivers/mtd/nand/sunxi_nand_spl.c | 480 +++- 12 files changed, 383 insertions(+), 190 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,v3,2/2] nand: extend nand torture
On Mon, Jun 13, 2016 at 10:15:48AM +0200, Max Krummenacher wrote:
> nand torture currently works on exactly one nand block which is specified
> by giving the byteoffset to the beginning of the block.
>
> Extend this by allowing for a second parameter specifying the byte size
> to be tested.
>
> e.g.
> ==> nand torture 100
>
> NAND torture: device 0 offset 0x100 size 0x2 (block size 0x2)
> Passed: 1, failed: 0
>
> ==> nand torture 100 4
>
> NAND torture: device 0 offset 0x100 size 0x4 (block size 0x2)
> Passed: 2, failed: 0
>
> Signed-off-by: Max Krummenacher
> Reviewed-by: Benoît Thébaudeau
> ---
Applying with these changes:
diff --git a/cmd/nand.c b/cmd/nand.c
index 6d239a3..ffdeea4 100644
--- a/cmd/nand.c
+++ b/cmd/nand.c
@@ -659,11 +659,12 @@ static int do_nand(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
}
size = mtd->erasesize;
- if (argc > 3)
+ if (argc > 3) {
if (!str2off(argv[3], &size)) {
puts("Size is not a valid number\n");
return 1;
}
+ }
endoff = off + size;
if (endoff > mtd->size) {
@@ -803,7 +804,7 @@ static char nand_help_text[] =
"nand dump[.oob] off - dump page\n"
#ifdef CONFIG_CMD_NAND_TORTURE
"nand torture off - torture one block at offset\n"
- "nand torture off size - torture blocks from off to off+size\n"
+ "nand torture off [size] - torture blocks from off to off+size\n"
#endif
"nand scrub [-y] off size | scrub.part partition | scrub.chip\n"
"really clean NAND erasing bad blocks (UNSAFE)\n"
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,1/1] common: fb_nand: won't compile
On Tue, Jun 07, 2016 at 02:22:59PM -0700, Sergey Kubushyn wrote: > Somehow this got overlooked when getting rid of nand_info. > > Small patch, won't affect anything else, no reason to wait for the > next cycle. > > Signed-off-by: Sergey Kubushyn > --- "Somehow" would be that there is no board that enables this code in order to get build coverage... -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 3/7] spl: nand: support redundant u-boot image
On Mon, Jun 06, 2016 at 10:16:58AM +0200, Boris Brezillon wrote: > On modern NAND it's more than recommended to have a backup copy of the > u-boot binary to recover from corruption: bitflips are quite common on > MLC NANDs, and the read-disturbance will corrupt your u-boot partitition > more quickly than what you would see on an SLC NAND. > > Add an extra Kconfig option to specify the offset of the redundant u-boot > image. > > Signed-off-by: Boris Brezillon > Acked-by: Hans de Goede > > # Conflicts: > # common/spl/spl_nand.c > # drivers/mtd/nand/Kconfig > --- > common/spl/spl_nand.c| 5 + > drivers/mtd/nand/Kconfig | 8 > 2 files changed, 13 insertions(+) > > diff --git a/common/spl/spl_nand.c b/common/spl/spl_nand.c > index bbd9546..d8c5b9e 100644 > --- a/common/spl/spl_nand.c > +++ b/common/spl/spl_nand.c > @@ -107,6 +107,11 @@ int spl_nand_load_image(void) > #endif > /* Load u-boot */ > err = spl_nand_load_element(CONFIG_SYS_NAND_U_BOOT_OFFS, header); > +#if CONFIG_SYS_NAND_U_BOOT_OFFS != CONFIG_SYS_NAND_U_BOOT_OFFS_REDUND > + if (err) > + err = spl_nand_load_element(CONFIG_SYS_NAND_U_BOOT_OFFS_REDUND, > + header); > +#endif > nand_deselect(); > return err; > } > diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig > index 5fe169f..8c46a2f 100644 > --- a/drivers/mtd/nand/Kconfig > +++ b/drivers/mtd/nand/Kconfig > @@ -117,6 +117,14 @@ config SYS_NAND_U_BOOT_OFFS > Set the offset from the start of the nand where u-boot should be > loaded from. > > +config SYS_NAND_U_BOOT_OFFS_REDUND > + hex "Location in NAND to read U-Boot from" > + default SYS_NAND_U_BOOT_OFFS > + depends on SYS_NAND_U_BOOT_LOCATIONS > + help > + Set the offset from the start of the nand where the redundant u-boot > + should be loaded from. > + > config SPL_NAND_DENALI > bool "Support Denali NAND controller for SPL" > help I'm adding the below ifdef while applying, so that the build doesn't break on targets that don't define CONFIG_SYS_NAND_U_BOOT_LOCATIONS. diff --git a/common/spl/spl_nand.c b/common/spl/spl_nand.c index 952f644..0e35e0f 100644 --- a/common/spl/spl_nand.c +++ b/common/spl/spl_nand.c @@ -134,11 +134,13 @@ int spl_nand_load_image(void) #endif /* Load u-boot */ err = spl_nand_load_element(CONFIG_SYS_NAND_U_BOOT_OFFS, header); +#ifdef CONFIG_SYS_NAND_U_BOOT_OFFS_REDUND #if CONFIG_SYS_NAND_U_BOOT_OFFS != CONFIG_SYS_NAND_U_BOOT_OFFS_REDUND if (err) err = spl_nand_load_element(CONFIG_SYS_NAND_U_BOOT_OFFS_REDUND, header); #endif +#endif nand_deselect(); return err; } -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/7] mtd: nand: Add+use mtd_to/from_nand and nand_get/set_controller_data
On Wed, 2016-06-15 at 10:07 +0200, Boris Brezillon wrote: > On Wed, 15 Jun 2016 09:59:15 +0200 > Boris Brezillon wrote: > > > Hi Scott, > > > > On Thu, 09 Jun 2016 21:07:00 -0500 > > Scott Wood wrote: > > > > > On Mon, 2016-06-06 at 18:02 +0200, Boris Brezillon wrote: > > > > On Mon, 30 May 2016 13:57:56 -0500 > > > > Scott Wood wrote: > > > > > > > > > These functions are part of the Linux 4.6 sync. They are being > > > > > added > > > > > before the main sync patch in order to make it easier to address the > > > > > issue across all NAND drivers (many/most of which do not closely > > > > > track > > > > > their Linux counterparts) separately from other merge issues. > > > > > > > > Some drivers are still directly accessing chip->mtd. Here is a patch > > > > fixing those places [1] (not tested). > > > > > > > > [1] http://code.bulix.org/inu69a-100476; > > > > > > Could you send this as a proper patch? > > > > Sure, see below. You can squash the changes into you patch (hence the > > !fixup prefix). > > Oops, sorry this version was buggy: mtd_to_nand() was called instead of > nand_to_mtd() in a few places. Here is an updated one. > > --->8--- > From 9c885ff8b3d96f29dfa5ef9850c4519a88a7912d Mon Sep 17 00:00:00 2001 > From: Boris Brezillon > Date: Wed, 15 Jun 2016 09:48:48 +0200 > Subject: [PATCH] fixup! mtd: nand: Add+use mtd_to/from_nand and > nand_get/set_controller_data It's too late to amend the commit. I need a standalone patch with signoff, etc. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHV5 4/6] ARMv8/Layerscape: switch SMP method accordingly
On 06/11/2016 10:58 PM, Zhiqiang Hou wrote:
> Hi York,
>
> Thanks for your comments!
>
>> -Original Message-
>> From: York Sun [mailto:york@nxp.com]
>> Sent: 2016年6月8日 8:56
>> To: Zhiqiang Hou ; u-boot@lists.denx.de;
>> albert.u.b...@aribaud.net; scottw...@freescale.com;
>> mingkai...@freescale.com; york...@freescale.com; le...@freescale.com;
>> prabha...@freescale.com; bhupesh.sha...@freescale.com
>> Subject: Re: [PATCHV5 4/6] ARMv8/Layerscape: switch SMP method accordingly
>>
>> On 06/04/2016 11:40 PM, Zhiqiang Hou wrote:
>>> From: Hou Zhiqiang
>>>
>>> If the PSCI and PPA is ready, skip the fixup for spin-table and waking
>>> secondary cores. If not, change SMP method to spin-table, and the
>>> device node of PSCI will be removed.
>>>
>>> Signed-off-by: Hou Zhiqiang
>>> ---
>>> V5:
>>> - Changed the checking if the PSCI feature is ready to read the psci
>>> version.
>>>
>>> V4:
>>> - Reordered this patch.
>>>
>>> arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 17 +---
>>> arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 36
>>> +
>>> 2 files changed, 50 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
>>> b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
>>> index 672a453..eb566cd 100644
>>> --- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
>>> +++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
>>> @@ -23,6 +23,9 @@
>>> #ifdef CONFIG_FSL_ESDHC
>>> #include
>>> #endif
>>> +#ifdef CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT #include
>>> + #endif
>>>
>>> DECLARE_GLOBAL_DATA_PTR;
>>>
>>> @@ -618,6 +621,7 @@ int arch_early_init_r(void) { #ifdef CONFIG_MP
>>> int rv = 1;
>>> + bool psci_support = false;
>>> #endif
>>>
>>> #ifdef CONFIG_SYS_FSL_ERRATUM_A009635 @@ -625,9 +629,16 @@ int
>>> arch_early_init_r(void) #endif
>>>
>>> #ifdef CONFIG_MP
>>> - rv = fsl_layerscape_wake_seconday_cores();
>>> - if (rv)
>>> - printf("Did not wake secondary cores\n");
>>> +#if defined(CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT) &&
>> defined(CONFIG_ARMV8_PSCI)
>>> + /* Check the psci version to determine if the psci is supported */
>>> + psci_support = (int)sec_firmware_support_psci_version() > 0 ?
>>> + true : false;
>>
>> Another comment, even if the function can be used to indicate if psci is
>> available,
>> do you have to cast it to (int)? I think this can be simplified as
>> psci_support = sec_firmware_support_psci_version() > 0;
>
> The type of this func return value is 'unsigned int', so the cast is
> necessary.
If it can return negative values then change the function's return
value. If the value is not really negative but you just want to test
the upper bit, then do that explicitly. In any case, please explain
what the format of this return value is supposed to be.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/7] mtd: nand: Add+use mtd_to/from_nand and nand_get/set_controller_data
On Mon, 2016-06-06 at 18:02 +0200, Boris Brezillon wrote: > On Mon, 30 May 2016 13:57:56 -0500 > Scott Wood wrote: > > > These functions are part of the Linux 4.6 sync. They are being added > > before the main sync patch in order to make it easier to address the > > issue across all NAND drivers (many/most of which do not closely track > > their Linux counterparts) separately from other merge issues. > > Some drivers are still directly accessing chip->mtd. Here is a patch > fixing those places [1] (not tested). > > [1] http://code.bulix.org/inu69a-100476 Could you send this as a proper patch? Though some of the changes seem to be removing SPL mtd pointers rather than converting chip->mtd. I don't care much whether those pointers are retained but it's not "directly accessing chip->mtd". -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] nand: nand torture: follow sync with linux v4.6
On Thu, 2016-06-09 at 23:13 +0200, Max Krummenacher wrote:
> Am Donnerstag, den 09.06.2016, 12:10 -0500 schrieb Scott Wood:
> > On Thu, 2016-06-09 at 10:35 +0200, Max Krummenacher wrote:
> > > Hi Scott
> > >
> > > 2016-06-09 1:47 GMT+02:00 Scott Wood :
> > > > On 06/07/2016 06:47 AM, Max Krummenacher wrote:
> > > > > follow parameter name change (nand to mtd) to fix compiler
> > > > > error.
> > > > >
> > > > > Signed-off-by: Max Krummenacher
> > > > >
> > > > > ---
> > > > >
> > > > > Changes in v2:
> > > > > - Patch v1 1/1 went into master, but Scott's patch series
> > > > > syncing
> > > > > with kernel v4.6 introduced an additional compile time error.
> > > > >
> > > > > drivers/mtd/nand/nand_util.c | 2 +-
> > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/mtd/nand/nand_util.c
> > > > > b/drivers/mtd/nand/nand_util.c
> > > > > index 5bba66a..e8bcc34 100644
> > > > > --- a/drivers/mtd/nand/nand_util.c
> > > > > +++ b/drivers/mtd/nand/nand_util.c
> > > > > @@ -820,7 +820,7 @@ int nand_torture(struct mtd_info *mtd,
> > > > > loff_t
> > > > > offset)
> > > > > {
> > > > > u_char patterns[] = {0xa5, 0x5a, 0x00};
> > > > > struct erase_info instr = {
> > > > > - .mtd = nand,
> > > > > + .mtd = mtd,
> > > > > .addr = offset,
> > > > > .len = mtd->erasesize,
> > > > > };
> > > >
> > > > This got missed because no boards enable CONFIG_CMD_NAND_TORTURE.
> > > > If
> > > > you use this option could you enable it in the relevant board?
> > >
> > > I believe this makes option makes only sense if you do HW bringup
> > > or
> > > have issues with
> > > your NAND driver. (Which I currently have with an i.MX 7 design)
> > > So likely one would not want to enable this for production code.
> >
> > That's why I suggested the alternative of adding one or more targets
> > aimed at
> > build coverage.
> >
> > > On the other hand people switching on the option should be able to
> > > fix
> > > whatever issue
> > > arises.
> > >
> > > And, considering that it was broken since January 2013
> > > (dfe64e2c89731a3f9950d7acd8681b68df2bae03) it can not be that
> > > important.
> >
> > This patch fixes a breakage that was merged within the past week.
> > What was
> > broken by the 2013 sync?
>
> The 2013 sync did deprecate the outside use of the function pointers
> in the mtd_info struct. To force this it did also rename the struct
> members.
> Since the torture code did not follow the rename it did no longer
> compile.
> Now fixed with
> http://git.denx.de/?p=u-boot.git;a=commit;h=667067faa18334f1e28c01b4753
> 0b5cce1b6182f
Oh, from the description I didn't realize that the function pointers were
actually not working. Usually "deprecated" means marked for removal/change,
not actually removed/changed.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] nand: nand torture: follow sync with linux v4.6
On Thu, 2016-06-09 at 10:35 +0200, Max Krummenacher wrote:
> Hi Scott
>
> 2016-06-09 1:47 GMT+02:00 Scott Wood :
> > On 06/07/2016 06:47 AM, Max Krummenacher wrote:
> > > follow parameter name change (nand to mtd) to fix compiler error.
> > >
> > > Signed-off-by: Max Krummenacher
> > >
> > > ---
> > >
> > > Changes in v2:
> > > - Patch v1 1/1 went into master, but Scott's patch series syncing
> > > with kernel v4.6 introduced an additional compile time error.
> > >
> > > drivers/mtd/nand/nand_util.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/mtd/nand/nand_util.c b/drivers/mtd/nand/nand_util.c
> > > index 5bba66a..e8bcc34 100644
> > > --- a/drivers/mtd/nand/nand_util.c
> > > +++ b/drivers/mtd/nand/nand_util.c
> > > @@ -820,7 +820,7 @@ int nand_torture(struct mtd_info *mtd, loff_t
> > > offset)
> > > {
> > > u_char patterns[] = {0xa5, 0x5a, 0x00};
> > > struct erase_info instr = {
> > > - .mtd = nand,
> > > + .mtd = mtd,
> > > .addr = offset,
> > > .len = mtd->erasesize,
> > > };
> >
> > This got missed because no boards enable CONFIG_CMD_NAND_TORTURE. If
> > you use this option could you enable it in the relevant board?
>
> I believe this makes option makes only sense if you do HW bringup or
> have issues with
> your NAND driver. (Which I currently have with an i.MX 7 design)
> So likely one would not want to enable this for production code.
That's why I suggested the alternative of adding one or more targets aimed at
build coverage.
> On the other hand people switching on the option should be able to fix
> whatever issue
> arises.
>
> And, considering that it was broken since January 2013
> (dfe64e2c89731a3f9950d7acd8681b68df2bae03) it can not be that important.
This patch fixes a breakage that was merged within the past week. What was
broken by the 2013 sync?
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] mtd: nand: Add the sunxi NAND controller driver
On Tue, 2016-06-07 at 07:41 +0200, Boris Brezillon wrote: > On Mon, 06 Jun 2016 18:54:03 -0500 > Scott Wood wrote: > > > Of course the driver model > > is probably the long-term solution. > > Definitely, and talking about things that need to be reworked, do you > know why u-boot is using its own MTD partition infrastructure instead > of relying on mtdpart.c? U-Boot's partition code predates the importation of the MTD code. > That's really a pain when one wants to add a new feature (like > definitions of partitions in the DT, or SLC mode on MLC NANDs) because > he has to do it twice. Defining partitions in the DT isn't such a great idea, at least on reference boards, as it's configuration that users are likely to want to change. > And that's not the only inconsistent part in the MTD/NAND layer IMO. > MTD is providing a generic abstraction for all flashes, but nand_util > is still directly accessing the NAND layer instead of going through the > MTD abstraction. As with partitions, that code predates the existence of the MTD abstraction in U-Boot. > By using the MTD abstraction everywhere (I mean for all flash devices), > we could provide generic utils (flash erase, flash write), even if > specific tools might be needed in a few cases. There are a lot of special NANDisms being handled in that code (bad block skipping, JFFS2 OOB cleanmarkers, etc), so I wonder what a generic version would look like. > Anyway, good to hear that you plan to switch to the driver model. I don't plan to do much of anything with the NAND code -- I'm still acting as custodian because nobody stepped up when I asked for volunteers to take it over a couple years back, but it's pretty low on my priority list regarding active development[1]. But if someone else wants to DM-ize a NAND driver I have no problem with that. :-) -Scott [1] Linux syncs are an exception, as they're easier to do than to review, especially since a patch only shows the end result rather than the process to produce it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] nand: nand torture: follow sync with linux v4.6
On 06/07/2016 06:47 AM, Max Krummenacher wrote:
> follow parameter name change (nand to mtd) to fix compiler error.
>
> Signed-off-by: Max Krummenacher
>
> ---
>
> Changes in v2:
> - Patch v1 1/1 went into master, but Scott's patch series syncing
> with kernel v4.6 introduced an additional compile time error.
>
> drivers/mtd/nand/nand_util.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/nand/nand_util.c b/drivers/mtd/nand/nand_util.c
> index 5bba66a..e8bcc34 100644
> --- a/drivers/mtd/nand/nand_util.c
> +++ b/drivers/mtd/nand/nand_util.c
> @@ -820,7 +820,7 @@ int nand_torture(struct mtd_info *mtd, loff_t offset)
> {
> u_char patterns[] = {0xa5, 0x5a, 0x00};
> struct erase_info instr = {
> - .mtd = nand,
> + .mtd = mtd,
> .addr = offset,
> .len = mtd->erasesize,
> };
This got missed because no boards enable CONFIG_CMD_NAND_TORTURE. If
you use this option could you enable it in the relevant board?
Or maybe we need to add an "allyesconfig"-type build (user-tunable
options only) to buildman? And/or some other test configs that add up
to decent build coverage of options that are only enabled by users.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] mtd: nand: Add the sunxi NAND controller driver
On Mon, 2016-06-06 at 20:31 +0200, Boris Brezillon wrote: > On Mon, 06 Jun 2016 12:56:48 -0500 > Scott Wood wrote: > > > On Mon, 2016-06-06 at 18:22 +0200, Boris Brezillon wrote: > > > On Mon, 6 Jun 2016 17:36:10 +0200 > > > Hans de Goede wrote: > > > > > > > > +#ifndef CONFIG_SPL_BUILD > > > > > +void sunxi_nand_init(void); > > > > > +#endif > > > > > + > > > > > > > > Can we have this in a header somewhere please, and without > > > > the #ifdef around it, that is not necessary for prototypes. > > > > > > Hehe, I was expecting this one :-). Do you know where I should put this > > > prototype definition? A board.h file in board/sunxi/? > > > > It's defined in drivers/mtd/nand and called from board/sunxi so the > > prototype > > needs to go somewhere under include/. It can go in include/configs/sunxi > > -common.h with #ifndef __ASSEMBLY__ around it -- or as long as it's > > limited to > > one init func per driver, maybe we could just put it in include/nand.h. > > Hm, none of these solutions seem ideal. > > Maybe we could define a generic void nand_controller_init(void) > prototype so that we don't need to add new xxx_nand_init() functions for > platforms needing this 2 steps initialization (platform specific pinmux > + clocks config before NAND controller initialization). > > Otherwise, I think I'll go for the 2nd solution (defining > sunxi_nand_init() in include/nand.h). I'd prefer not having a generic nand_controller_init() because some platforms may want to pass arguments, plus I don't want to rule out the possibility of two different NAND controller types being supported at once. include/nand.h is fine with me, as long as any driver than wants more than an initfunc moves its stuff into a dedicated header. Of course the driver model is probably the long-term solution. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] mtd: nand: Add the sunxi NAND controller driver
On Mon, 2016-06-06 at 18:22 +0200, Boris Brezillon wrote: > On Mon, 6 Jun 2016 17:36:10 +0200 > Hans de Goede wrote: > > > > +#ifndef CONFIG_SPL_BUILD > > > +void sunxi_nand_init(void); > > > +#endif > > > + > > > > Can we have this in a header somewhere please, and without > > the #ifdef around it, that is not necessary for prototypes. > > Hehe, I was expecting this one :-). Do you know where I should put this > prototype definition? A board.h file in board/sunxi/? It's defined in drivers/mtd/nand and called from board/sunxi so the prototype needs to go somewhere under include/. It can go in include/configs/sunxi -common.h with #ifndef __ASSEMBLY__ around it -- or as long as it's limited to one init func per driver, maybe we could just put it in include/nand.h. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/7] spl: nand: rename the SYS_NAND_U_BOOT_OFFS Kconfig option
On Sat, 2016-06-04 at 13:06 +0200, Boris Brezillon wrote: > On Sat, 04 Jun 2016 02:14:09 -0500 > Scott Wood wrote: > > > On Sat, 2016-06-04 at 08:06 +0200, Boris Brezillon wrote: > > > On Fri, 03 Jun 2016 20:08:49 -0500 > > > Scott Wood wrote: > > > > > > > This doesn't work. CONFIG_SPL_NAND_U_BOOT_OFFS will always be defined > > > > when SPL is defined, and the user will be forced to enter a value > > > > before > > > > kconfig will continue (or kconfig will error out in an automated > > > > build). > > > > > > Yes, CONFIG_SPL_NAND_U_BOOT_OFFS will always be defined, but won't be > > > used if CONFIG_SYS_NAND_U_BOOT_OFFS is defined in the config header > > > file. > > > And for the "user will forced to enter a value before Kconfig > > > continue" comment, we could just have > > > > > > config SPL_NAND_U_BOOT_OFFS > > > hex "Location in NAND to read U-Boot from" > > > default 0x8000 if NAND_SUNXI > > > default 0x0 > > > ... > > > > If you do that, then that zero will override CONFIG_SYS_NAND_U_BOOT_OFFS > > from > > the header. > > Nope, because the condition is > > #ifndef CONFIG_SYS_NAND_U_BOOT_OFFS > #define CONFIG_SYS_NAND_U_BOOT_OFFS CONFIG_SPL_NAND_U_BOOT_OFFS > #endif > > and not > > #ifdef CONFIG_SPL_NAND_U_BOOT_OFFS > #define CONFIG_SYS_NAND_U_BOOT_OFFS CONFIG_SPL_NAND_U_BOOT_OFFS > #endif > > So CONFIG_SYS_NAND_U_BOOT_OFFS is always preferred over > CONFIG_SPL_NAND_U_BOOT_OFFS if it's defined. Ah, right. Still, I think it would be less confusing to not have two different names for the same thing, both of which would be present (albeit only one is used) in the legacy case -- especially if we start adding references directly to the SPL name in some drivers. The bool could eventually be reversed so that only the legacy targets need it. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/7] spl: nand: support redundant u-boot image
On Sat, 2016-06-04 at 08:15 +0200, Boris Brezillon wrote: > On Fri, 03 Jun 2016 20:15:16 -0500 > Scott Wood wrote: > > > How does the failure get communicated to later > > parts of the system that would be responsible for such reflashing? > > Linux is taking care of that (a script tries to read the u-boot > partition, and if fails it reflashes it with the content of the > u-boot-backup partition, or with a reference u-boot.bin file). > I guess u-boot could do it too. > > Anyway, that's a different story ;). It seemed like it would be good to export the information if possible (e.g. an environment variable) rather than rereading and thus making failures happen twice as quickly. But that can wait until someone actually wants to use it that way. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/7] spl: nand: rename the SYS_NAND_U_BOOT_OFFS Kconfig option
On Sat, 2016-06-04 at 08:06 +0200, Boris Brezillon wrote: > On Fri, 03 Jun 2016 20:08:49 -0500 > Scott Wood wrote: > > > This doesn't work. CONFIG_SPL_NAND_U_BOOT_OFFS will always be defined > > when SPL is defined, and the user will be forced to enter a value before > > kconfig will continue (or kconfig will error out in an automated build). > > Yes, CONFIG_SPL_NAND_U_BOOT_OFFS will always be defined, but won't be > used if CONFIG_SYS_NAND_U_BOOT_OFFS is defined in the config header > file. > And for the "user will forced to enter a value before Kconfig > continue" comment, we could just have > > config SPL_NAND_U_BOOT_OFFS > hex "Location in NAND to read U-Boot from" > default 0x8000 if NAND_SUNXI > default 0x0 > ... If you do that, then that zero will override CONFIG_SYS_NAND_U_BOOT_OFFS from the header. > > If you want to do this there needs to be a separate bool config that > > controls whether the hex config exists. > > I can add an extra Kconfig option, but is it really necessary: > if people are relying on it they will choose a valid value, and leave > it to 0 otherwise. > It's just a detail, so I'm fine adding this extra option if you think > it's really useful. Zero *is* a valid value. Several boards already have that value for this symbol. Even if that weren't the case, we want a mechanism for migrating from header value to kconfig value that works for more than just this one specific symbol. > > > And there'd be no need to rename hex symbol. > > Well, functionally there's no problem keeping the existing SYS_ prefix > if we add this extra option to activate the U_OFFS config in Kconfig, > but I'm not sure this is a good idea to reuse config header names in > Kconfig. > > And what happens if the user enabled this option (some like to enable > everything :-)) and CONFIG_SYS_NAND_U_BOOT_OFFS is also defined in the > board config header? Then the build fails with a redefined symbol, and the user learns their lesson. :-) The "SYS" in CONFIG_SYS means it's not a user-tunable knob. From README: > There are two classes of configuration variables: > > * Configuration _OPTIONS_: > These are selectable by the user and have names beginning with > "CONFIG_". > > * Configuration _SETTINGS_: > These depend on the hardware etc. and should not be meddled with if > you don't know what you're doing; they have names beginning with > "CONFIG_SYS_". -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: nand flash
The following changes since commit b2f1858455e99a91aeafe59ac73c6c047106d5e8: arm: lib: fix push/pop-section directives (2016-06-03 15:14:11 -0400) are available in the git repository at: git://git.denx.de/u-boot-nand-flash.git for you to fetch changes up to 667067faa18334f1e28c01b47530b5cce1b6182f: nand: fix nand torture to use changed mtd api (2016-06-03 20:29:05 -0500) Marek Vasut (1): mtd: nand: Remove jz4740 driver Max Krummenacher (1): nand: fix nand torture to use changed mtd api Scott Wood (6): mtd: nand: Remove docg4 driver and palmtreo680 flashing tool mtd: nand: Remove nand_info_t typedef nand: Embed mtd_info in struct nand_chip mtd: nand: Add+use mtd_to/from_nand and nand_get/set_controller_data mtd: nand: Add page argument to write_page() etc. mtd: nand: Sync with Linux v4.6 Siva Durga Prasad Paladugu (1): mtd: nand: arasan_nfc: Correct nand ecc initialization board/BuR/common/common.c |2 +- board/atmel/at91sam9261ek/at91sam9261ek.c |2 +- board/atmel/at91sam9263ek/at91sam9263ek.c |2 +- board/atmel/at91sam9m10g45ek/at91sam9m10g45ek.c |2 +- board/atmel/at91sam9n12ek/at91sam9n12ek.c |2 +- board/atmel/at91sam9rlek/at91sam9rlek.c |2 +- board/atmel/at91sam9x5ek/at91sam9x5ek.c |2 +- board/atmel/sama5d3xek/sama5d3xek.c |2 +- board/atmel/sama5d4_xplained/sama5d4_xplained.c |2 +- board/atmel/sama5d4ek/sama5d4ek.c |2 +- board/esd/common/esd405ep_nand.c|2 +- board/freescale/m5329evb/nand.c |2 +- board/freescale/m5373evb/nand.c |2 +- board/ronetix/pm9261/pm9261.c |2 +- board/ronetix/pm9263/pm9263.c |2 +- board/socrates/nand.c |6 +- board/xes/common/actl_nand.c|2 +- cmd/bootm.c | 30 +- cmd/jffs2.c |8 +- cmd/nand.c | 189 ++--- common/env_nand.c | 24 +- common/fb_nand.c| 32 +- common/splash_source.c |4 +- doc/README.nand | 15 +- drivers/dfu/dfu_nand.c | 24 +- drivers/mtd/nand/Makefile |3 - drivers/mtd/nand/am335x_spl_bch.c | 54 +- drivers/mtd/nand/arasan_nfc.c | 42 +- drivers/mtd/nand/atmel_nand.c | 126 +-- drivers/mtd/nand/davinci_nand.c | 25 +- drivers/mtd/nand/denali.c | 37 +- drivers/mtd/nand/denali.h |1 - drivers/mtd/nand/denali_spl.c |2 +- drivers/mtd/nand/docg4.c| 1030 --- drivers/mtd/nand/docg4_spl.c| 219 - drivers/mtd/nand/fsl_elbc_nand.c| 41 +- drivers/mtd/nand/fsl_ifc_nand.c | 48 +- drivers/mtd/nand/fsl_upm.c | 22 +- drivers/mtd/nand/fsmc_nand.c| 15 +- drivers/mtd/nand/jz4740_nand.c | 258 -- drivers/mtd/nand/kb9202_nand.c |2 +- drivers/mtd/nand/kirkwood_nand.c|2 +- drivers/mtd/nand/lpc32xx_nand_mlc.c | 14 +- drivers/mtd/nand/lpc32xx_nand_slc.c |5 +- drivers/mtd/nand/mpc5121_nfc.c | 31 +- drivers/mtd/nand/mxc_nand.c | 62 +- drivers/mtd/nand/mxc_nand_spl.c |2 +- drivers/mtd/nand/mxs_nand.c | 50 +- drivers/mtd/nand/mxs_nand_spl.c | 40 +- drivers/mtd/nand/nand.c | 28 +- drivers/mtd/nand/nand_base.c| 420 + drivers/mtd/nand/nand_bbt.c | 62 +- drivers/mtd/nand/nand_bch.c | 33 +- drivers/mtd/nand/nand_ids.c | 10 +- drivers/mtd/nand/nand_plat.c|4 +- drivers/mtd/nand/nand_spl_simple.c | 84 +- drivers/mtd/nand/nand_util.c| 176 ++-- drivers/mtd/nand/ndfc.c | 16 +- drivers/mtd/nand/omap_gpmc.c| 46 +- drivers/mtd/nand/pxa3xx_nand.c | 45 +- drivers/mtd/nand/s3c2410_nand.c |6 +- drivers/mtd/nand/tegra_nand.c | 48 +- drivers/mtd/nand/vf610_nfc.c| 14 +- drivers/net/fm/fm.c |2 +- drivers/net/phy/cortina.c |4 +- fs/jffs2/jffs2_1pass.c |2 +- fs/jffs2/jffs2_nand_1pass.c
Re: [U-Boot] [PATCH v2 3/7] spl: nand: support redundant u-boot image
On Wed, 2016-06-01 at 13:23 +0200, Boris Brezillon wrote: > On modern NAND it's more than recommended to have a backup copy of the > u-boot binary to recover from corruption: bitflips are quite common on > MLC NANDs, and the read-disturbance will corrupt your u-boot partitition > more quickly than what you would see on an SLC NAND. Wouldn't the same happen to the SPL itself? Or is the boot block implemented in a different, more robust manner? > Add an extra Kconfig option to specify the offset of the redundant u-boot > image. > > Signed-off-by: Boris Brezillon > Acked-by: Hans de Goede > --- > common/spl/spl_nand.c| 8 > drivers/mtd/nand/Kconfig | 6 ++ > 2 files changed, 14 insertions(+) > > diff --git a/common/spl/spl_nand.c b/common/spl/spl_nand.c > index 612bd4a..0bf0848 100644 > --- a/common/spl/spl_nand.c > +++ b/common/spl/spl_nand.c > @@ -12,6 +12,9 @@ > > #ifndef CONFIG_SYS_NAND_U_BOOT_OFFS > #define CONFIG_SYS_NAND_U_BOOT_OFFS CONFIG_SPL_NAND_U_BOOT_OFFS > +#define CONFIG_SYS_NAND_U_BOOT_OFFS_REDUND > CONFIG_SPL_NAND_U_BOOT_OFFS_REDUND > +#else > +#define CONFIG_SYS_NAND_U_BOOT_OFFS_REDUND CONFIG_SYS_NAND_U_BOOT_OFFS > #endif > > #if defined(CONFIG_SPL_NAND_RAW_ONLY) > @@ -111,6 +114,11 @@ int spl_nand_load_image(void) > #endif > /* Load u-boot */ > err = spl_nand_load_element(CONFIG_SYS_NAND_U_BOOT_OFFS, header); > +#if CONFIG_SYS_NAND_U_BOOT_OFFS != CONFIG_SYS_NAND_U_BOOT_OFFS_REDUND > + if (err) > + err = > spl_nand_load_element(CONFIG_SYS_NAND_U_BOOT_OFFS_REDUND, > + header); > +#endif If one of the images has failed, doesn't it need to be reflashed before the other one goes bad as well? How does the failure get communicated to later parts of the system that would be responsible for such reflashing? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/7] spl: nand: rename the SYS_NAND_U_BOOT_OFFS Kconfig option
On Wed, 2016-06-01 at 13:23 +0200, Boris Brezillon wrote: > The SYS_NAND_U_BOOT_OFFS is quite generic, but the Kconfig entry is forced > to explicitly depend on platforms that are not already defining it in their > include/configs/.h header. > > Rename this Kconfig option into SPL_NAND_U_BOOT_OFFS, remove the dependency > on NAND_SUNXI and make it dependent on SPL selection. > > common/spl/spl_nand.c now sets CONFIG_SYS_NAND_U_BOOT_OFFS to > CONFIG_SPL_NAND_U_BOOT_OFFS only when it's undefined. This way we stay > compatible with the existing behavior. > > Signed-off-by: Boris Brezillon > Acked-by: Hans de Goede > --- > common/spl/spl_nand.c | 4 > drivers/mtd/nand/Kconfig | 9 + > drivers/mtd/nand/sunxi_nand_spl.c | 8 > 3 files changed, 13 insertions(+), 8 deletions(-) > > diff --git a/common/spl/spl_nand.c b/common/spl/spl_nand.c > index bbd9546..612bd4a 100644 > --- a/common/spl/spl_nand.c > +++ b/common/spl/spl_nand.c > @@ -10,6 +10,10 @@ > #include > #include > > +#ifndef CONFIG_SYS_NAND_U_BOOT_OFFS > +#define CONFIG_SYS_NAND_U_BOOT_OFFS CONFIG_SPL_NAND_U_BOOT_OFFS > +#endif [snip] > -# Enhance depends when converting drivers to Kconfig which use this config > -config SYS_NAND_U_BOOT_OFFS > +if SPL > + > +# This option should be used in replacement of CONFIG_SYS_NAND_U_BOOT_OFFS. > +# CONFIG_SYS_NAND_U_BOOT_OFFS is still preferred if defined. > +config SPL_NAND_U_BOOT_OFFS > hex "Location in NAND to read U-Boot from" > default 0x8000 if NAND_SUNXI > - depends on NAND_SUNXI > help > Set the offset from the start of the nand where u-boot should be > loaded from. This doesn't work. CONFIG_SPL_NAND_U_BOOT_OFFS will always be defined when SPL is defined, and the user will be forced to enter a value before kconfig will continue (or kconfig will error out in an automated build). If you want to do this there needs to be a separate bool config that controls whether the hex config exists. And there'd be no need to rename hex symbol. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/7] nand: add nand mtd concat support
On Thu, 2016-06-02 at 07:02 +0200, Heiko Schocher wrote: > Hello Scott, > > Am 02.06.2016 um 02:09 schrieb Scott Wood: > > On Tue, 2016-05-31 at 14:08 +0200, Heiko Schocher wrote: > > > @@ -59,6 +64,9 @@ int nand_register(int devnum, struct mtd_info *mtd) > > >* via the mtdcore infrastructure (e.g. ubi). > > >*/ > > > add_mtd_device(mtd); > > > +#ifdef CONFIG_MTD_CONCAT > > > + nand_devices_found++; > > > +#endif > > > #endif > > [snip] > > > + sprintf(c_mtd_name, "nand%d", nand_devices_found); > > > + mtd = mtd_concat_create(nand_info, nand_devices_found, > > > + c_mtd_name); > > > > This assumes that there are no gaps in the NAND numbering (e.g. because > > some > > device was optional or failed to init). It would be better to build an > > array > > by scanning nand_info[] for non-NULL devices. > > Yes, you are right ... Hmm... thinking about it ... this did exactly > my v1 ... I created such an array "mtd_nand_list" ... Ok, this > "mtd_nand_list" was a variable in file scope ... but as it is an array > of pointers, the mem footprint is not so big ... My concern was code organization, not (just) footprint. > but if you find it > better to scan nand_info and create a new array on stack, I can do > this ... what way do you preffer? On the stack. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/7] nand: add nand mtd concat support
On Tue, 2016-05-31 at 14:08 +0200, Heiko Schocher wrote: > @@ -59,6 +64,9 @@ int nand_register(int devnum, struct mtd_info *mtd) >* via the mtdcore infrastructure (e.g. ubi). >*/ > add_mtd_device(mtd); > +#ifdef CONFIG_MTD_CONCAT > + nand_devices_found++; > +#endif > #endif [snip] > + sprintf(c_mtd_name, "nand%d", nand_devices_found); > + mtd = mtd_concat_create(nand_info, nand_devices_found, > + c_mtd_name); This assumes that there are no gaps in the NAND numbering (e.g. because some device was optional or failed to init). It would be better to build an array by scanning nand_info[] for non-NULL devices. -SCott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/7] mtd: nand: Sync with Linux v4.6
On Tue, 2016-05-31 at 08:48 +0200, Heiko Schocher wrote: > Hello Scott, > > Am 30.05.2016 um 20:57 schrieb Scott Wood: > > Updates the NAND code to match Linux v4.6. The previous sync was from > > Linux v4.1 in commit d3963721d93fafa. > > > > Note that none of the individual NAND drivers tracked Linux closely > > enough to be synced themselves, other than manually applying a few > > cross-tree changes. > > > > Signed-off-by: Scott Wood > > --- > > drivers/mtd/nand/atmel_nand.c | 6 +- > > drivers/mtd/nand/davinci_nand.c | 6 +- > > drivers/mtd/nand/denali.c | 39 +++-- > > drivers/mtd/nand/denali.h | 1 - > > drivers/mtd/nand/denali_spl.c | 2 +- > > drivers/mtd/nand/mpc5121_nfc.c | 1 - > > drivers/mtd/nand/mxc_nand.c | 5 +- > > drivers/mtd/nand/mxc_nand_spl.c | 2 +- > > drivers/mtd/nand/mxs_nand.c | 2 +- > > drivers/mtd/nand/nand_base.c| 329 -- > > -- > > drivers/mtd/nand/nand_bbt.c | 30 ++-- > > drivers/mtd/nand/nand_bch.c | 29 ++-- > > drivers/mtd/nand/nand_ids.c | 10 +- > > drivers/mtd/nand/ndfc.c | 2 +- > > drivers/mtd/nand/omap_gpmc.c| 2 +- > > drivers/mtd/nand/s3c2410_nand.c | 2 +- > > drivers/mtd/nand/vf610_nfc.c| 1 - > > include/linux/mtd/mtd.h | 5 + > > include/linux/mtd/nand.h| 65 +--- > > include/linux/mtd/nand_bch.h| 10 +- > > 20 files changed, 347 insertions(+), 202 deletions(-) > > Thanks for your work! > > I tested this series on the imx6 based aristainetos board incl. some > basic UBI/UBIFS tests with tbot[1] without errors: > > http://xeidos.ddns.net/tests/test_db_auslesen.php#41 > > beside some checkpatchwarnings: > (you must press on the "[+] control" link, block does not yet unblock > automagically ...) > http://xeidos.ddns.net/tbot/id_41/html_log.html#96 > http://xeidos.ddns.net/tbot/id_41/html_log.html#116 > http://xeidos.ddns.net/tbot/id_41/html_log.html#136 > > I currently disable failing tbot on checkpatch warnings/errors, as I > think this warnings are from linux... or? The warnings are from (mostly minor) style problems in the existing U-Boot code, that weren't fixed when a (largely automatically generated with Coccinelle) patch did some search and replace. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 7/7] mtd: nand: Sync with Linux v4.6
Updates the NAND code to match Linux v4.6. The previous sync was from
Linux v4.1 in commit d3963721d93fafa.
Note that none of the individual NAND drivers tracked Linux closely
enough to be synced themselves, other than manually applying a few
cross-tree changes.
Signed-off-by: Scott Wood
---
drivers/mtd/nand/atmel_nand.c | 6 +-
drivers/mtd/nand/davinci_nand.c | 6 +-
drivers/mtd/nand/denali.c | 39 +++--
drivers/mtd/nand/denali.h | 1 -
drivers/mtd/nand/denali_spl.c | 2 +-
drivers/mtd/nand/mpc5121_nfc.c | 1 -
drivers/mtd/nand/mxc_nand.c | 5 +-
drivers/mtd/nand/mxc_nand_spl.c | 2 +-
drivers/mtd/nand/mxs_nand.c | 2 +-
drivers/mtd/nand/nand_base.c| 329
drivers/mtd/nand/nand_bbt.c | 30 ++--
drivers/mtd/nand/nand_bch.c | 29 ++--
drivers/mtd/nand/nand_ids.c | 10 +-
drivers/mtd/nand/ndfc.c | 2 +-
drivers/mtd/nand/omap_gpmc.c| 2 +-
drivers/mtd/nand/s3c2410_nand.c | 2 +-
drivers/mtd/nand/vf610_nfc.c| 1 -
include/linux/mtd/mtd.h | 5 +
include/linux/mtd/nand.h| 65 +---
include/linux/mtd/nand_bch.h| 10 +-
20 files changed, 347 insertions(+), 202 deletions(-)
diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index a81b96d..75e8307 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -513,7 +513,7 @@ normal_check:
if (err_nbr == -1) {
dev_err(host->dev, "PMECC: Too many errors\n");
mtd->ecc_stats.failed++;
- return -EIO;
+ return -EBADMSG;
} else {
pmecc_correct_data(mtd, buf_pos, ecc, i,
host->pmecc_bytes_per_sector, err_nbr);
@@ -562,7 +562,7 @@ static int atmel_nand_pmecc_read_page(struct mtd_info *mtd,
stat = pmecc_readl(host->pmecc, isr);
if (stat != 0)
if (pmecc_correction(mtd, stat, buf, &oob[eccpos[0]]) != 0)
- return -EIO;
+ return -EBADMSG;
return 0;
}
@@ -1112,7 +1112,7 @@ static int atmel_nand_correct(struct mtd_info *mtd,
u_char *dat,
* We can't correct so many errors */
dev_warn(host->dev, "atmel_nand : multiple errors detected."
" Unable to correct.\n");
- return -EIO;
+ return -EBADMSG;
}
/* if there's a single bit error : we can correct it */
diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index be9d666..48a8ca7 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -243,7 +243,7 @@ static int nand_davinci_correct_data(struct mtd_info *mtd,
u_char *dat,
"%d\n", find_byte, find_bit);
return 1;
} else {
- return -1;
+ return -EBADMSG;
}
} else if (!(diff & (diff - 1))) {
/* Single bit ECC error in the ECC itself,
@@ -254,7 +254,7 @@ static int nand_davinci_correct_data(struct mtd_info *mtd,
u_char *dat,
} else {
/* Uncorrectable error */
MTDDEBUG(MTD_DEBUG_LEVEL0, "ECC UNCORRECTED_ERROR 1\n");
- return -1;
+ return -EBADMSG;
}
}
return 0;
@@ -701,7 +701,7 @@ static int nand_davinci_4bit_correct_data(struct mtd_info
*mtd, uint8_t *dat,
return 0;
} else if (iserror == ECC_STATE_TOO_MANY_ERRS) {
val = __raw_readl(&davinci_emif_regs->nanderrval1);
- return -1;
+ return -EBADMSG;
}
numerrors = ((__raw_readl(&davinci_emif_regs->nandfsr) >> 16)
diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index 3ae7545..601e744 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -48,8 +48,10 @@ static int onfi_timing_mode = NAND_DEFAULT_TIMINGS;
* this macro allows us to convert from an MTD structure to our own
* device context (denali) structure.
*/
-#define mtd_to_denali(m) \
- container_of(mtd_to_nand(m), struct denali_nand_info, nand)
+static inline struct denali_nand_info *mtd_to_denali(struct mtd_info *mtd)
+{
+ return container_of(mtd_to_nand(mtd), struct denali_nand_info, nand);
+}
/*
* These constants are defined by the driver to enable common driver
@@ -866,8 +868,7 @@ static int write_page(struct mtd_info *mtd, struct
nand_chip *chip,
* by write_page above.
*/
static int denali
[U-Boot] [PATCH 6/7] mtd: nand: Add page argument to write_page() etc.
This change is part of the Linux 4.6 sync. It is being done before the
main sync patch in order to make it easier to address the issue across
all NAND drivers (many/most of which do not closely track their Linux
counterparts) separately from other merge issues.
Signed-off-by: Scott Wood
---
drivers/mtd/nand/arasan_nfc.c | 3 ++-
drivers/mtd/nand/atmel_nand.c | 2 +-
drivers/mtd/nand/davinci_nand.c | 11 +++
drivers/mtd/nand/denali.c | 6 --
drivers/mtd/nand/fsl_elbc_nand.c| 5 +++--
drivers/mtd/nand/fsl_ifc_nand.c | 2 +-
drivers/mtd/nand/lpc32xx_nand_mlc.c | 6 --
drivers/mtd/nand/lpc32xx_nand_slc.c | 3 ++-
drivers/mtd/nand/mxc_nand.c | 4 ++--
drivers/mtd/nand/mxs_nand.c | 2 +-
drivers/mtd/nand/nand_base.c| 31 +--
drivers/mtd/nand/pxa3xx_nand.c | 3 ++-
drivers/mtd/nand/tegra_nand.c | 21 -
drivers/mtd/nand/vf610_nfc.c| 2 +-
include/linux/mtd/nand.h| 6 +++---
15 files changed, 58 insertions(+), 49 deletions(-)
diff --git a/drivers/mtd/nand/arasan_nfc.c b/drivers/mtd/nand/arasan_nfc.c
index ef8ae04..e9a96dc 100644
--- a/drivers/mtd/nand/arasan_nfc.c
+++ b/drivers/mtd/nand/arasan_nfc.c
@@ -433,7 +433,8 @@ static void arasan_nand_fill_tx(const u8 *buf, int len)
}
static int arasan_nand_write_page_hwecc(struct mtd_info *mtd,
- struct nand_chip *chip, const u8 *buf, int oob_required)
+ struct nand_chip *chip, const u8 *buf, int oob_required,
+ int page)
{
u32 reg_val, i, pktsize, pktnum;
const u32 *bufptr = (const u32 *)buf;
diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index b1adff0..a81b96d 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -569,7 +569,7 @@ static int atmel_nand_pmecc_read_page(struct mtd_info *mtd,
static int atmel_nand_pmecc_write_page(struct mtd_info *mtd,
struct nand_chip *chip, const uint8_t *buf,
- int oob_required)
+ int oob_required, int page)
{
struct atmel_nand_host *host = nand_get_controller_data(chip);
uint32_t *eccpos = chip->ecc.layout->eccpos;
diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index 5e0c7bf..be9d666 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -380,10 +380,13 @@ static int nand_davinci_write_page(struct mtd_info *mtd,
struct nand_chip *chip,
chip->cmdfunc(mtd, NAND_CMD_SEQIN, 0x00, page);
- if (unlikely(raw))
- status = chip->ecc.write_page_raw(mtd, chip, buf, oob_required);
- else
- status = chip->ecc.write_page(mtd, chip, buf, oob_required);
+ if (unlikely(raw)) {
+ status = chip->ecc.write_page_raw(mtd, chip, buf,
+ oob_required, page);
+ } else {
+ status = chip->ecc.write_page(mtd, chip, buf,
+ oob_required, page);
+ }
if (status < 0) {
ret = status;
diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index d9bcd72..3ae7545 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -866,7 +866,8 @@ static int write_page(struct mtd_info *mtd, struct
nand_chip *chip,
* by write_page above.
*/
static int denali_write_page(struct mtd_info *mtd, struct nand_chip *chip,
- const uint8_t *buf, int oob_required)
+ const uint8_t *buf, int oob_required,
+ int page)
{
struct denali_nand_info *denali = mtd_to_denali(mtd);
@@ -890,7 +891,8 @@ static int denali_write_page(struct mtd_info *mtd, struct
nand_chip *chip,
* write_page() function above.
*/
static int denali_write_page_raw(struct mtd_info *mtd, struct nand_chip *chip,
- const uint8_t *buf, int oob_required)
+ const uint8_t *buf, int oob_required,
+ int page)
{
struct denali_nand_info *denali = mtd_to_denali(mtd);
diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index aafff67..f621f14 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -611,7 +611,8 @@ static int fsl_elbc_read_page(struct mtd_info *mtd, struct
nand_chip *chip,
* waitfunc.
*/
static int fsl_elbc_write_page(struct mtd_info *mtd, struct nand_chip *chip,
- const uint8_t *buf, int oob_required)
+ const uint8_t *buf, int oob_required,
+ int page)
{
fsl_elbc_write_buf(mtd, buf, mtd->writesize);
fsl_elbc_write_buf(mtd, chip->oob_poi, m
[U-Boot] [PATCH 5/7] mtd: nand: Add+use mtd_to/from_nand and nand_get/set_controller_data
These functions are part of the Linux 4.6 sync. They are being added
before the main sync patch in order to make it easier to address the
issue across all NAND drivers (many/most of which do not closely track
their Linux counterparts) separately from other merge issues.
Signed-off-by: Scott Wood
---
board/esd/common/esd405ep_nand.c| 2 +-
board/freescale/m5329evb/nand.c | 2 +-
board/freescale/m5373evb/nand.c | 2 +-
board/socrates/nand.c | 6 ++--
board/xes/common/actl_nand.c| 2 +-
cmd/nand.c | 4 +--
drivers/mtd/nand/am335x_spl_bch.c | 6 ++--
drivers/mtd/nand/arasan_nfc.c | 19 +-
drivers/mtd/nand/atmel_nand.c | 55 ++--
drivers/mtd/nand/davinci_nand.c | 8 ++---
drivers/mtd/nand/denali.c | 4 +--
drivers/mtd/nand/fsl_elbc_nand.c| 33 +
drivers/mtd/nand/fsl_ifc_nand.c | 43 +++---
drivers/mtd/nand/fsl_upm.c | 22 ++--
drivers/mtd/nand/fsmc_nand.c| 7 ++--
drivers/mtd/nand/kb9202_nand.c | 2 +-
drivers/mtd/nand/kirkwood_nand.c| 2 +-
drivers/mtd/nand/lpc32xx_nand_mlc.c | 2 --
drivers/mtd/nand/lpc32xx_nand_slc.c | 2 +-
drivers/mtd/nand/mpc5121_nfc.c | 27 +++---
drivers/mtd/nand/mxc_nand.c | 51 +-
drivers/mtd/nand/mxs_nand.c | 46
drivers/mtd/nand/mxs_nand_spl.c | 11 +++---
drivers/mtd/nand/nand.c | 5 ++-
drivers/mtd/nand/nand_base.c| 72 ++---
drivers/mtd/nand/nand_bbt.c | 32 -
drivers/mtd/nand/nand_bch.c | 4 +--
drivers/mtd/nand/nand_plat.c| 4 +--
drivers/mtd/nand/nand_spl_simple.c | 11 +++---
drivers/mtd/nand/nand_util.c| 8 ++---
drivers/mtd/nand/ndfc.c | 14
drivers/mtd/nand/omap_gpmc.c| 40 ++---
drivers/mtd/nand/pxa3xx_nand.c | 34 ++
drivers/mtd/nand/s3c2410_nand.c | 4 +--
drivers/mtd/nand/tegra_nand.c | 29 ---
drivers/mtd/nand/vf610_nfc.c| 8 ++---
fs/yaffs2/yaffs_uboot_glue.c| 2 +-
include/linux/mtd/nand.h| 20 +++
38 files changed, 328 insertions(+), 317 deletions(-)
diff --git a/board/esd/common/esd405ep_nand.c b/board/esd/common/esd405ep_nand.c
index f46936c..51ac10c 100644
--- a/board/esd/common/esd405ep_nand.c
+++ b/board/esd/common/esd405ep_nand.c
@@ -16,7 +16,7 @@
*/
static void esd405ep_nand_hwcontrol(struct mtd_info *mtd, int cmd, unsigned
int ctrl)
{
- struct nand_chip *this = mtd->priv;
+ struct nand_chip *this = mtd_to_nand(mtd);
if (ctrl & NAND_CTRL_CHANGE) {
if ( ctrl & NAND_CLE )
out_be32((void *)GPIO0_OR, in_be32((void *)GPIO0_OR) |
CONFIG_SYS_NAND_CLE);
diff --git a/board/freescale/m5329evb/nand.c b/board/freescale/m5329evb/nand.c
index 8d88bc0..8849681 100644
--- a/board/freescale/m5329evb/nand.c
+++ b/board/freescale/m5329evb/nand.c
@@ -24,7 +24,7 @@ DECLARE_GLOBAL_DATA_PTR;
static void nand_hwcontrol(struct mtd_info *mtdinfo, int cmd, unsigned int
ctrl)
{
- struct nand_chip *this = mtdinfo->priv;
+ struct nand_chip *this = mtd_to_nand(mtdinfo);
volatile u16 *nCE = (u16 *) CONFIG_SYS_LATCH_ADDR;
if (ctrl & NAND_CTRL_CHANGE) {
diff --git a/board/freescale/m5373evb/nand.c b/board/freescale/m5373evb/nand.c
index 92cef2a..a96a599 100644
--- a/board/freescale/m5373evb/nand.c
+++ b/board/freescale/m5373evb/nand.c
@@ -24,7 +24,7 @@ DECLARE_GLOBAL_DATA_PTR;
static void nand_hwcontrol(struct mtd_info *mtdinfo, int cmd, unsigned int
ctrl)
{
- struct nand_chip *this = mtdinfo->priv;
+ struct nand_chip *this = mtd_to_nand(mtdinfo);
volatile u16 *nCE = (u16 *) CONFIG_SYS_LATCH_ADDR;
if (ctrl & NAND_CTRL_CHANGE) {
diff --git a/board/socrates/nand.c b/board/socrates/nand.c
index 15e6ea6..a67d812 100644
--- a/board/socrates/nand.c
+++ b/board/socrates/nand.c
@@ -48,7 +48,7 @@ static void sc_nand_write_byte(struct mtd_info *mtd, u_char
byte)
static void sc_nand_write_buf(struct mtd_info *mtd, const u_char *buf, int len)
{
int i;
- struct nand_chip *this = mtd->priv;
+ struct nand_chip *this = mtd_to_nand(mtd);
for (i = 0; i < len; i++) {
out_be32(this->IO_ADDR_W,
@@ -88,7 +88,7 @@ static u16 sc_nand_read_word(struct mtd_info *mtd)
static void sc_nand_read_buf(struct mtd_info *mtd, u_char *buf, int len)
{
int i;
- struct nand_chip *this = mtd->priv;
+ struct nand_chip *this = mtd_to_nand(mtd);
int val;
val = (state & FPGA_NAND_ENABLE) | FPGA_NAND_CMD_READ;
@@ -105,7 +105,7 @@ static void sc_nand_read_buf(struct mtd_info *mtd, u_char
*buf, int len)
*/
static int sc_nand_device_ready(struct mtd_info *m
[U-Boot] [PATCH 2/7] mtd: nand: Remove docg4 driver and palmtreo680 flashing tool
Commit ad4f54ea86b ("arm: Remove palmtreo680 board") removed the only
user of the docg4 driver and the palmtreo680 image flashing tool. This
patch removes them.
Signed-off-by: Scott Wood
Cc: Mike Dunn
Cc: Simon Glass
---
drivers/mtd/nand/Makefile|2 -
drivers/mtd/nand/docg4.c | 1030 --
drivers/mtd/nand/docg4_spl.c | 219
include/linux/mtd/docg4.h| 132 -
tools/palmtreo680/flash_u-boot.c | 177 ---
5 files changed, 1560 deletions(-)
delete mode 100644 drivers/mtd/nand/docg4.c
delete mode 100644 drivers/mtd/nand/docg4_spl.c
delete mode 100644 include/linux/mtd/docg4.h
delete mode 100644 tools/palmtreo680/flash_u-boot.c
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index aea6a93..837d397 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -13,7 +13,6 @@ endif
obj-$(CONFIG_SPL_NAND_AM33XX_BCH) += am335x_spl_bch.o
obj-$(CONFIG_SPL_NAND_DENALI) += denali_spl.o
-obj-$(CONFIG_SPL_NAND_DOCG4) += docg4_spl.o
obj-$(CONFIG_SPL_NAND_SIMPLE) += nand_spl_simple.o
obj-$(CONFIG_SPL_NAND_LOAD) += nand_spl_load.o
obj-$(CONFIG_SPL_NAND_ECC) += nand_ecc.o
@@ -67,7 +66,6 @@ obj-$(CONFIG_TEGRA_NAND) += tegra_nand.o
obj-$(CONFIG_NAND_OMAP_GPMC) += omap_gpmc.o
obj-$(CONFIG_NAND_OMAP_ELM) += omap_elm.o
obj-$(CONFIG_NAND_PLAT) += nand_plat.o
-obj-$(CONFIG_NAND_DOCG4) += docg4.o
else # minimal SPL drivers
diff --git a/drivers/mtd/nand/docg4.c b/drivers/mtd/nand/docg4.c
deleted file mode 100644
index c1c1ff8..000
--- a/drivers/mtd/nand/docg4.c
+++ /dev/null
@@ -1,1030 +0,0 @@
-/*
- * drivers/mtd/nand/docg4.c
- *
- * Copyright (C) 2013 Mike Dunn
- *
- * SPDX-License-Identifier:GPL-2.0+
- *
- * mtd nand driver for M-Systems DiskOnChip G4
- *
- * Tested on the Palm Treo 680. The G4 is also present on Toshiba Portege,
Asus
- * P526, some HTC smartphones (Wizard, Prophet, ...), O2 XDA Zinc, maybe
others.
- * Should work on these as well. Let me know!
- *
- * TODO:
- *
- * Mechanism for management of password-protected areas
- *
- * Hamming ecc when reading oob only
- *
- * According to the M-Sys documentation, this device is also available in a
- * "dual-die" configuration having a 256MB capacity, but no mechanism for
- * detecting this variant is documented. Currently this driver assumes 128MB
- * capacity.
- *
- * Support for multiple cascaded devices ("floors"). Not sure which gadgets
- * contain multiple G4s in a cascaded configuration, if any.
- */
-
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-/*
- * The device has a nop register which M-Sys claims is for the purpose of
- * inserting precise delays. But beware; at least some operations fail if the
- * nop writes are replaced with a generic delay!
- */
-static inline void write_nop(void __iomem *docptr)
-{
- writew(0, docptr + DOC_NOP);
-}
-
-
-static int poll_status(void __iomem *docptr)
-{
- /*
-* Busy-wait for the FLASHREADY bit to be set in the FLASHCONTROL
-* register. Operations known to take a long time (e.g., block erase)
-* should sleep for a while before calling this.
-*/
-
- uint8_t flash_status;
-
- /* hardware quirk requires reading twice initially */
- flash_status = readb(docptr + DOC_FLASHCONTROL);
-
- do {
- flash_status = readb(docptr + DOC_FLASHCONTROL);
- } while (!(flash_status & DOC_CTRL_FLASHREADY));
-
- return 0;
-}
-
-static void write_addr(void __iomem *docptr, uint32_t docg4_addr)
-{
- /* write the four address bytes packed in docg4_addr to the device */
-
- writeb(docg4_addr & 0xff, docptr + DOC_FLASHADDRESS);
- docg4_addr >>= 8;
- writeb(docg4_addr & 0xff, docptr + DOC_FLASHADDRESS);
- docg4_addr >>= 8;
- writeb(docg4_addr & 0xff, docptr + DOC_FLASHADDRESS);
- docg4_addr >>= 8;
- writeb(docg4_addr & 0xff, docptr + DOC_FLASHADDRESS);
-}
-
-/*
- * This is a module parameter in the linux kernel version of this driver. It
is
- * hard-coded to 'off' for u-boot. This driver uses oob to mark bad blocks.
- * This can be problematic when dealing with data not intended for the mtd/nand
- * subsystem. For example, on boards that boot from the docg4 and use the IPL
- * to load an spl + u-boot image, the blocks containing the image will be
- * reported as "bad" because the oob of the first page of each block contains a
- * magic number that the IPL looks for, which causes the badblock scan to
- * erroneously add them to the bad block table. To erase such a block, use
- * u-boot's 'nand scrub'. scrub is safe for the docg4. The device does have a
- * factory bad block table, but it is read-only, and is used in conjunction
with
- * oob bad block markers that are w
[U-Boot] [PATCH 3/7] mtd: nand: Remove nand_info_t typedef
This typedef serves no purpose other than causing confusion with
struct nand_chip.
Signed-off-by: Scott Wood
---
cmd/bootm.c| 30 +++
cmd/jffs2.c| 6 +-
cmd/nand.c | 161 ++-
common/env_nand.c | 6 +-
common/fb_nand.c | 32 +++
drivers/dfu/dfu_nand.c | 20 ++---
drivers/mtd/nand/am335x_spl_bch.c | 2 +-
drivers/mtd/nand/atmel_nand.c | 2 +-
drivers/mtd/nand/mxs_nand_spl.c| 2 +-
drivers/mtd/nand/nand.c| 2 +-
drivers/mtd/nand/nand_spl_simple.c | 2 +-
drivers/mtd/nand/nand_util.c | 170 ++---
fs/jffs2/jffs2_nand_1pass.c| 24 +++---
fs/yaffs2/yaffs_uboot_glue.c | 2 +-
include/nand.h | 39 -
15 files changed, 251 insertions(+), 249 deletions(-)
diff --git a/cmd/bootm.c b/cmd/bootm.c
index 1bca6fa..3f440b1 100644
--- a/cmd/bootm.c
+++ b/cmd/bootm.c
@@ -372,8 +372,8 @@ next_bank: ;
#endif
#if defined(CONFIG_CMD_IMLS_NAND)
-static int nand_imls_legacyimage(nand_info_t *nand, int nand_dev, loff_t off,
- size_t len)
+static int nand_imls_legacyimage(struct mtd_info *mtd, int nand_dev,
+loff_t off, size_t len)
{
void *imgdata;
int ret;
@@ -386,8 +386,7 @@ static int nand_imls_legacyimage(nand_info_t *nand, int
nand_dev, loff_t off,
return -ENOMEM;
}
- ret = nand_read_skip_bad(nand, off, &len,
- imgdata);
+ ret = nand_read_skip_bad(mtd, off, &len, imgdata);
if (ret < 0 && ret != -EUCLEAN) {
free(imgdata);
return ret;
@@ -413,8 +412,8 @@ static int nand_imls_legacyimage(nand_info_t *nand, int
nand_dev, loff_t off,
return 0;
}
-static int nand_imls_fitimage(nand_info_t *nand, int nand_dev, loff_t off,
- size_t len)
+static int nand_imls_fitimage(struct mtd_info *mtd, int nand_dev, loff_t off,
+ size_t len)
{
void *imgdata;
int ret;
@@ -427,8 +426,7 @@ static int nand_imls_fitimage(nand_info_t *nand, int
nand_dev, loff_t off,
return -ENOMEM;
}
- ret = nand_read_skip_bad(nand, off, &len,
- imgdata);
+ ret = nand_read_skip_bad(mtd, off, &len, imgdata);
if (ret < 0 && ret != -EUCLEAN) {
free(imgdata);
return ret;
@@ -449,7 +447,7 @@ static int nand_imls_fitimage(nand_info_t *nand, int
nand_dev, loff_t off,
static int do_imls_nand(void)
{
- nand_info_t *nand;
+ struct mtd_info *mtd;
int nand_dev = nand_curr_device;
size_t len;
loff_t off;
@@ -463,20 +461,20 @@ static int do_imls_nand(void)
printf("\n");
for (nand_dev = 0; nand_dev < CONFIG_SYS_MAX_NAND_DEVICE; nand_dev++) {
- nand = &nand_info[nand_dev];
- if (!nand->name || !nand->size)
+ mtd = &nand_info[nand_dev];
+ if (!mtd->name || !mtd->size)
continue;
- for (off = 0; off < nand->size; off += nand->erasesize) {
+ for (off = 0; off < mtd->size; off += mtd->erasesize) {
const image_header_t *header;
int ret;
- if (nand_block_isbad(nand, off))
+ if (nand_block_isbad(mtd, off))
continue;
len = sizeof(buffer);
- ret = nand_read(nand, off, &len, (u8 *)buffer);
+ ret = nand_read(mtd, off, &len, (u8 *)buffer);
if (ret < 0 && ret != -EUCLEAN) {
printf("NAND read error %d at offset %08llX\n",
ret, off);
@@ -489,13 +487,13 @@ static int do_imls_nand(void)
header = (const image_header_t *)buffer;
len = image_get_image_size(header);
- nand_imls_legacyimage(nand, nand_dev, off, len);
+ nand_imls_legacyimage(mtd, nand_dev, off, len);
break;
#endif
#if defined(CONFIG_FIT)
case IMAGE_FORMAT_FIT:
len = fit_get_size(buffer);
- nand_imls_fitimage(nand, nand_dev, off, len);
+ nand_imls_fitimage(mtd, nand_dev, off, len);
break;
#endif
}
diff --git a/cmd/jffs2.c b/cmd/jffs2.c
index 0b2eefa..e4eaa48 100644
--- a/cmd/jffs2.c
+++ b/cmd/jffs2.c
@@ -
[U-Boot] [PATCH 1/7] mtd: nand: Remove jz4740 driver
From: Marek Vasut
This driver is not used by anyone, remove it.
Signed-off-by: Marek Vasut
Cc: Daniel Schwierzeck
Cc: Paul Burton
Cc: Scott Wood
Acked-by: Daniel Schwierzeck
Signed-off-by: Scott Wood
---
drivers/mtd/nand/Makefile | 1 -
drivers/mtd/nand/jz4740_nand.c | 258 -
2 files changed, 259 deletions(-)
delete mode 100644 drivers/mtd/nand/jz4740_nand.c
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 6fb3718..aea6a93 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -50,7 +50,6 @@ obj-$(CONFIG_NAND_FSL_ELBC) += fsl_elbc_nand.o
obj-$(CONFIG_NAND_FSL_IFC) += fsl_ifc_nand.o
obj-$(CONFIG_NAND_FSL_UPM) += fsl_upm.o
obj-$(CONFIG_NAND_FSMC) += fsmc_nand.o
-obj-$(CONFIG_NAND_JZ4740) += jz4740_nand.o
obj-$(CONFIG_NAND_KB9202) += kb9202_nand.o
obj-$(CONFIG_NAND_KIRKWOOD) += kirkwood_nand.o
obj-$(CONFIG_NAND_KMETER1) += kmeter1_nand.o
diff --git a/drivers/mtd/nand/jz4740_nand.c b/drivers/mtd/nand/jz4740_nand.c
deleted file mode 100644
index abcedc2..000
--- a/drivers/mtd/nand/jz4740_nand.c
+++ /dev/null
@@ -1,258 +0,0 @@
-/*
- * Platform independend driver for JZ4740.
- *
- * Copyright (c) 2007 Ingenic Semiconductor Inc.
- * Author:
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-#include
-
-#include
-#include
-#include
-
-#define JZ_NAND_DATA_ADDR ((void __iomem *)0xB800)
-#define JZ_NAND_CMD_ADDR (JZ_NAND_DATA_ADDR + 0x8000)
-#define JZ_NAND_ADDR_ADDR (JZ_NAND_DATA_ADDR + 0x1)
-
-#define JZ_NAND_ECC_CTRL_ENCODING BIT(3)
-#define JZ_NAND_ECC_CTRL_RSBIT(2)
-#define JZ_NAND_ECC_CTRL_RESET BIT(1)
-#define JZ_NAND_ECC_CTRL_ENABLEBIT(0)
-
-#define EMC_SMCR1_OPT_NAND 0x094c4400
-/* Optimize the timing of nand */
-
-static struct jz4740_emc * emc = (struct jz4740_emc *)JZ4740_EMC_BASE;
-
-static struct nand_ecclayout qi_lb60_ecclayout_2gb = {
- .eccbytes = 72,
- .eccpos = {
- 12, 13, 14, 15, 16, 17, 18, 19,
- 20, 21, 22, 23, 24, 25, 26, 27,
- 28, 29, 30, 31, 32, 33, 34, 35,
- 36, 37, 38, 39, 40, 41, 42, 43,
- 44, 45, 46, 47, 48, 49, 50, 51,
- 52, 53, 54, 55, 56, 57, 58, 59,
- 60, 61, 62, 63, 64, 65, 66, 67,
- 68, 69, 70, 71, 72, 73, 74, 75,
- 76, 77, 78, 79, 80, 81, 82, 83 },
- .oobfree = {
- {.offset = 2,
-.length = 10 },
- {.offset = 84,
-.length = 44 } }
-};
-
-static int is_reading;
-
-static void jz_nand_cmd_ctrl(struct mtd_info *mtd, int cmd, unsigned int ctrl)
-{
- struct nand_chip *this = mtd->priv;
- uint32_t reg;
-
- if (ctrl & NAND_CTRL_CHANGE) {
- if (ctrl & NAND_ALE)
- this->IO_ADDR_W = JZ_NAND_ADDR_ADDR;
- else if (ctrl & NAND_CLE)
- this->IO_ADDR_W = JZ_NAND_CMD_ADDR;
- else
- this->IO_ADDR_W = JZ_NAND_DATA_ADDR;
-
- reg = readl(&emc->nfcsr);
- if (ctrl & NAND_NCE)
- reg |= EMC_NFCSR_NFCE1;
- else
- reg &= ~EMC_NFCSR_NFCE1;
- writel(reg, &emc->nfcsr);
- }
-
- if (cmd != NAND_CMD_NONE)
- writeb(cmd, this->IO_ADDR_W);
-}
-
-static int jz_nand_device_ready(struct mtd_info *mtd)
-{
- return (readl(GPIO_PXPIN(2)) & 0x4000) ? 1 : 0;
-}
-
-void board_nand_select_device(struct nand_chip *nand, int chip)
-{
- /*
-* Don't use "chip" to address the NAND device,
-* generate the cs from the address where it is encoded.
-*/
-}
-
-static int jz_nand_rs_calculate_ecc(struct mtd_info *mtd, const u_char *dat,
- u_char *ecc_code)
-{
- uint32_t status;
- int i;
-
- if (is_reading)
- return 0;
-
- do {
- status = readl(&emc->nfints);
- } while (!(status & EMC_NFINTS_ENCF));
-
- /* disable ecc */
- writel(readl(&emc->nfecr) & ~EMC_NFECR_ECCE, &emc->nfecr);
-
- for (i = 0; i < 9; i++)
- ecc_code[i] = readb(&emc->nfpar[i]);
-
- return 0;
-}
-
-static void jz_nand_hwctl(struct mtd_info *mtd, int mode)
-{
- uint32_t reg;
-
- writel(0, &emc->nfints);
- reg = readl(&emc->nfecr);
- reg |= JZ_NAND_ECC_CTRL_RESET;
- reg |= JZ_NAND_ECC_CTRL_ENABLE;
- reg |= JZ_NAND_ECC_CTRL_RS;
-
- switch (mode) {
- case NAND_ECC_READ:
- reg &= ~JZ_NAND_ECC_CTRL_ENCODING;
- is_reading = 1;
- break;
- case NAND_ECC_WRITE:
- reg |= JZ_NAND_ECC_CTRL_ENCODING;
- is_reading = 0;
- break;
- default:
-
[U-Boot] [PATCH 4/7] nand: Embed mtd_info in struct nand_chip
nand_info[] is now an array of pointers, with the actual mtd_info
instance embedded in struct nand_chip.
This is in preparation for syncing the NAND code with Linux 4.6,
which makes the same change to struct nand_chip. It's in a separate
commit due to the large amount of changes required to accommodate the
change to nand_info[].
Signed-off-by: Scott Wood
---
board/BuR/common/common.c | 2 +-
board/atmel/at91sam9261ek/at91sam9261ek.c | 2 +-
board/atmel/at91sam9263ek/at91sam9263ek.c | 2 +-
board/atmel/at91sam9m10g45ek/at91sam9m10g45ek.c | 2 +-
board/atmel/at91sam9n12ek/at91sam9n12ek.c | 2 +-
board/atmel/at91sam9rlek/at91sam9rlek.c | 2 +-
board/atmel/at91sam9x5ek/at91sam9x5ek.c | 2 +-
board/atmel/sama5d3xek/sama5d3xek.c | 2 +-
board/atmel/sama5d4_xplained/sama5d4_xplained.c | 2 +-
board/atmel/sama5d4ek/sama5d4ek.c | 2 +-
board/ronetix/pm9261/pm9261.c | 2 +-
board/ronetix/pm9263/pm9263.c | 2 +-
cmd/bootm.c | 2 +-
cmd/jffs2.c | 4 +-
cmd/nand.c | 42 ++--
common/env_nand.c | 18 +++---
common/fb_nand.c| 2 +-
common/splash_source.c | 4 +-
doc/README.nand | 15 ++---
drivers/dfu/dfu_nand.c | 8 +--
drivers/mtd/nand/am335x_spl_bch.c | 54
drivers/mtd/nand/arasan_nfc.c | 4 +-
drivers/mtd/nand/atmel_nand.c | 77 +++---
drivers/mtd/nand/denali.c | 4 +-
drivers/mtd/nand/fsl_elbc_nand.c| 5 +-
drivers/mtd/nand/fsl_ifc_nand.c | 5 +-
drivers/mtd/nand/fsmc_nand.c| 10 ++-
drivers/mtd/nand/lpc32xx_nand_mlc.c | 10 ++-
drivers/mtd/nand/mpc5121_nfc.c | 3 +-
drivers/mtd/nand/mxc_nand.c | 2 +-
drivers/mtd/nand/mxs_nand_spl.c | 33 +-
drivers/mtd/nand/nand.c | 27 +---
drivers/mtd/nand/nand_spl_simple.c | 85 +
drivers/mtd/nand/omap_gpmc.c| 4 +-
drivers/mtd/nand/pxa3xx_nand.c | 10 +--
drivers/mtd/nand/tegra_nand.c | 4 +-
drivers/mtd/nand/vf610_nfc.c| 5 +-
drivers/net/fm/fm.c | 2 +-
drivers/net/phy/cortina.c | 4 +-
fs/jffs2/jffs2_1pass.c | 2 +-
fs/jffs2/jffs2_nand_1pass.c | 2 +-
fs/yaffs2/yaffs_uboot_glue.c| 8 +--
include/linux/mtd/nand.h| 1 +
include/nand.h | 6 +-
44 files changed, 247 insertions(+), 239 deletions(-)
diff --git a/board/BuR/common/common.c b/board/BuR/common/common.c
index ce4acc1..e947e54 100644
--- a/board/BuR/common/common.c
+++ b/board/BuR/common/common.c
@@ -259,7 +259,7 @@ static int load_devicetree(void)
}
#ifdef CONFIG_NAND
dtbsize = 0x2;
- rc = nand_read_skip_bad(&nand_info[0], 0x4, (size_t *)&dtbsize,
+ rc = nand_read_skip_bad(nand_info[0], 0x4, (size_t *)&dtbsize,
NULL, 0x2, (u_char *)dtbaddr);
#else
char *dtbname = getenv("dtb");
diff --git a/board/atmel/at91sam9261ek/at91sam9261ek.c
b/board/atmel/at91sam9261ek/at91sam9261ek.c
index 7b7cd2c..6398bcb 100644
--- a/board/atmel/at91sam9261ek/at91sam9261ek.c
+++ b/board/atmel/at91sam9261ek/at91sam9261ek.c
@@ -212,7 +212,7 @@ void lcd_show_board_info(void)
dram_size += gd->bd->bi_dram[i].size;
nand_size = 0;
for (i = 0; i < CONFIG_SYS_MAX_NAND_DEVICE; i++)
- nand_size += nand_info[i].size;
+ nand_size += nand_info[i]->size;
lcd_printf (" %ld MB SDRAM, %ld MB NAND\n",
dram_size >> 20,
nand_size >> 20 );
diff --git a/board/atmel/at91sam9263ek/at91sam9263ek.c
b/board/atmel/at91sam9263ek/at91sam9263ek.c
index af68e10..04e5812 100644
--- a/board/atmel/at91sam9263ek/at91sam9263ek.c
+++ b/board/atmel/at91sam9263ek/at91sam9263ek.c
@@ -191,7 +191,7 @@ void lcd_show_board_info(void)
dram_size += gd->bd->bi_dram[i].size;
nand_size = 0;
for (i = 0; i < CONFIG_SYS_MAX_NAND_DEVICE; i++)
- nand_size += nand_info[i].size;
+ nand_size += nand_info[i]->size;
#ifndef CONFIG_SYS_NO_FLASH
flash_size = 0;
for (i = 0; i < CONFIG_SYS_MAX_FLASH_BANKS; i++)
diff --git a/board/atmel/at91sam9m10g45ek/at91sam9m10g45ek.c
b/board/atmel/at91sam9m10g45ek/at91sam9m10g45ek.c
index 4
Re: [U-Boot] [PATCH v2 14/18] at91: mtd: nand: Add dev_warn() to correct build error in driver
On Thu, 2016-05-05 at 07:34 -0600, Simon Glass wrote: > The code does not compile if ECC is enabled. > > Signed-off-by: Andre Renaud > Signed-off-by: Simon Glass > --- > > Changes in v2: None > > drivers/mtd/nand/atmel_nand.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c > index 8fac824..15958cb 100644 > --- a/drivers/mtd/nand/atmel_nand.c > +++ b/drivers/mtd/nand/atmel_nand.c > @@ -20,6 +20,8 @@ > #include > #include > > +#define dev_warn(dev, msg...) > + > #ifdef CONFIG_ATMEL_NAND_HWECC > > /* Register access macros */ This should go in include/linux/compat.h with the others. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 3/7] nand: add nand mtd concat support
On 05/25/2016 01:10 AM, Heiko Schocher wrote:
> Hello Scott,
>
> Am 25.05.2016 um 07:30 schrieb Scott Wood:
>> On 05/25/2016 12:07 AM, Heiko Schocher wrote:
>>> add for nand devices mtd concat support. Generic MTD concat
>>> support is already ported to mainline, and used in the cfi_mtd
>>> driver. This patch adds it similiar for nand devices.
>>>
>>> Signed-off-by: Heiko Schocher
>>> ---
>>>
>>> drivers/mtd/nand/nand.c | 29 +
>>> 1 file changed, 29 insertions(+)
>>>
>>> diff --git a/drivers/mtd/nand/nand.c b/drivers/mtd/nand/nand.c
>>> index 8f0a921..5413123 100644
>>> --- a/drivers/mtd/nand/nand.c
>>> +++ b/drivers/mtd/nand/nand.c
>>> @@ -9,6 +9,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>>
>>> #ifndef CONFIG_SYS_NAND_BASE_LIST
>>> #define CONFIG_SYS_NAND_BASE_LIST { CONFIG_SYS_NAND_BASE }
>>> @@ -30,6 +31,12 @@ static char dev_name[CONFIG_SYS_MAX_NAND_DEVICE][8];
>>>
>>> static unsigned long total_nand_size; /* in kiB */
>>>
>>> +#ifdef CONFIG_MTD_CONCAT
>>> +static int nand_devices_found;
>>> +static struct mtd_info *mtd_nand_list[CONFIG_SYS_MAX_NAND_DEVICE];
>>> +static char c_mtd_name[16];
>>> +#endif
>>
>> Why is c_mtd_name file-scope rather than local?
>
> fixed.
>
>>> +
>>> /* Register an initialized NAND mtd device with the U-Boot NAND command.
>>> */
>>> int nand_register(int devnum)
>>> {
>>> @@ -49,6 +56,9 @@ int nand_register(int devnum)
>>> * via the mtdcore infrastructure (e.g. ubi).
>>> */
>>> add_mtd_device(mtd);
>>> +#ifdef CONFIG_MTD_CONCAT
>>> + mtd_nand_list[nand_devices_found++] = mtd;
>>> +#endif
>>
>> Why do we need another list of NAND devices? Use nand_info[].
>
> Ah, correct ... struct nand_info_t == struct mtd_info ... Hmm...
> why we need a "struct nand_info_t" ?
It's a typedef, not a struct... and we don't need it. I already have a
patch in the set I'm working on for the Linux NAND sync that removes the
typedef, and another that converts nand_info[] into an array of pointers
(which should make calling mtd_concat_create easier).
>
>>> #endif
>>>
>>> total_nand_size += mtd->size / 1024;
>>> @@ -102,4 +112,23 @@ void nand_init(void)
>>> */
>>> board_nand_select_device(nand_info[nand_curr_device].priv,
>>> nand_curr_device);
>>> #endif
>>> +
>>> +#ifdef CONFIG_MTD_CONCAT
>>> + if (nand_devices_found > 1) {
>>> + struct mtd_info *mtd;
>>> +
>>> + /*
>>> +* We detected multiple devices. Concatenate them together.
>>> +*/
>>> + sprintf(c_mtd_name, "nand%d", nand_devices_found);
>>> + mtd = mtd_concat_create(mtd_nand_list, nand_devices_found,
>>> + c_mtd_name);
>>> +
>>> + if (mtd == NULL)
>>> + return;
>>> +
>>> + if (add_mtd_device(mtd))
>>> + return;
>>> + }
>>> +#endif /* CONFIG_MTD_CONCAT */
>>> }
>>
>> Please don't add new features that depend on the old-style NAND init.
>
> Hmm... my add works for the "#ifdef CONFIG_SYS_NAND_SELF_INIT" case
> and the "else" case ... where would be the appropriate place?
You're right... For some reason I was thinking that none of this was
called with self-init.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 2/7] ubi: add new ubi command "ubi dettach"
On 05/25/2016 01:28 AM, Heiko Schocher wrote: > Hello Scott, > > Am 25.05.2016 um 07:47 schrieb Scott Wood: >> On 05/25/2016 12:07 AM, Heiko Schocher wrote: >>> @@ -661,7 +675,9 @@ static int do_ubi(cmd_tbl_t *cmdtp, int flag, int argc, >>> char * const argv[]) >>> U_BOOT_CMD( >>> ubi, 6, 1, do_ubi, >>> "ubi commands", >>> - "part [part] [offset]\n" >>> + "dettach" >> >> "detach", here and elsewhere. >> >>> + " - detach ubi from a mtd partition\n" >> >> Like that. :-) > > Thanks! Fixed. > >> P.S. When CCing me, please use o...@buserror.net so that my responses >> don't have to go through moderation. > > Huh... I used the address in u-boot:/doc/git-mailrc ... > changed. I changed it in MAINTAINERS... didn't realize there was another place I needed to change it. I'll send a patch to update that. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 6/7] dfu, nand, ubi: fix erasing after write finish
On 05/25/2016 12:07 AM, Heiko Schocher wrote: > writting to ubi nand partitions need after write ends an erase > of the remaining sectors. This fail, if dfu write size was not > a multiple of erasesize, example log: > > Failure erase: -1 > > Fix this error. > > Signed-off-by: Heiko Schocher Why don't you just erase the whole partition up front? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 3/7] nand: add nand mtd concat support
On 05/25/2016 12:07 AM, Heiko Schocher wrote:
> add for nand devices mtd concat support. Generic MTD concat
> support is already ported to mainline, and used in the cfi_mtd
> driver. This patch adds it similiar for nand devices.
>
> Signed-off-by: Heiko Schocher
> ---
>
> drivers/mtd/nand/nand.c | 29 +
> 1 file changed, 29 insertions(+)
>
> diff --git a/drivers/mtd/nand/nand.c b/drivers/mtd/nand/nand.c
> index 8f0a921..5413123 100644
> --- a/drivers/mtd/nand/nand.c
> +++ b/drivers/mtd/nand/nand.c
> @@ -9,6 +9,7 @@
> #include
> #include
> #include
> +#include
>
> #ifndef CONFIG_SYS_NAND_BASE_LIST
> #define CONFIG_SYS_NAND_BASE_LIST { CONFIG_SYS_NAND_BASE }
> @@ -30,6 +31,12 @@ static char dev_name[CONFIG_SYS_MAX_NAND_DEVICE][8];
>
> static unsigned long total_nand_size; /* in kiB */
>
> +#ifdef CONFIG_MTD_CONCAT
> +static int nand_devices_found;
> +static struct mtd_info *mtd_nand_list[CONFIG_SYS_MAX_NAND_DEVICE];
> +static char c_mtd_name[16];
> +#endif
Why is c_mtd_name file-scope rather than local?
> +
> /* Register an initialized NAND mtd device with the U-Boot NAND command. */
> int nand_register(int devnum)
> {
> @@ -49,6 +56,9 @@ int nand_register(int devnum)
>* via the mtdcore infrastructure (e.g. ubi).
>*/
> add_mtd_device(mtd);
> +#ifdef CONFIG_MTD_CONCAT
> + mtd_nand_list[nand_devices_found++] = mtd;
> +#endif
Why do we need another list of NAND devices? Use nand_info[].
> #endif
>
> total_nand_size += mtd->size / 1024;
> @@ -102,4 +112,23 @@ void nand_init(void)
>*/
> board_nand_select_device(nand_info[nand_curr_device].priv,
> nand_curr_device);
> #endif
> +
> +#ifdef CONFIG_MTD_CONCAT
> + if (nand_devices_found > 1) {
> + struct mtd_info *mtd;
> +
> + /*
> + * We detected multiple devices. Concatenate them together.
> + */
> + sprintf(c_mtd_name, "nand%d", nand_devices_found);
> + mtd = mtd_concat_create(mtd_nand_list, nand_devices_found,
> + c_mtd_name);
> +
> + if (mtd == NULL)
> + return;
> +
> + if (add_mtd_device(mtd))
> + return;
> + }
> +#endif /* CONFIG_MTD_CONCAT */
> }
Please don't add new features that depend on the old-style NAND init.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 2/7] ubi: add new ubi command "ubi dettach"
On 05/25/2016 12:07 AM, Heiko Schocher wrote: > @@ -661,7 +675,9 @@ static int do_ubi(cmd_tbl_t *cmdtp, int flag, int argc, > char * const argv[]) > U_BOOT_CMD( > ubi, 6, 1, do_ubi, > "ubi commands", > - "part [part] [offset]\n" > + "dettach" "detach", here and elsewhere. > + " - detach ubi from a mtd partition\n" Like that. :-) -Scott P.S. When CCing me, please use o...@buserror.net so that my responses don't have to go through moderation. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Porting Linux's MTD/NAND changes into U-Boot
On Mon, 2016-05-16 at 14:02 +0200, Boris Brezillon wrote: > Hi Scott, > > On Tue, 03 May 2016 00:06:45 -0500 > Scott Wood wrote: > > > I usually do syncs when someone complains about needing a sync. Every > > release > > seems a bit much. I'll try to do one soon. > > Sorry to bother you with that, but can I ask when you plan to do this > sync (I guess you'll sync with 4.6)? As I explained, I depend on > features introduced in 4.6 to make the sunxi NAND driver usable on > sunxi based boards (the concept of data randomizer/scrambler is > required on some MLC NANDs, and most Allwinner boards embed this > kind of NAND chips). > > Don't hesitate to let me know if you need some help. I'm working on it now. Yes, with 4.6. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Porting Linux's MTD/NAND changes into U-Boot
On Mon, 2016-04-25 at 22:53 +0200, Boris Brezillon wrote: > On Mon, 25 Apr 2016 13:36:46 -0400 > Tom Rini wrote: > > > On Mon, Apr 25, 2016 at 04:43:14PM +0200, Boris Brezillon wrote: > > > > > Hi Scott, > > > > > > I've recently contributed a lot of MTD/NAND related patches (and intend > > > to continue doing so). Some of them are transversal changes touching the > > > MTD and NAND framework internals, which implies patching all NAND > > > drivers along with the core changes. > > > > > > All those changes are required to properly handle modern NANDs (MLC/TLC > > > NANDs), and I need them to add proper NAND support to the sunxi > > > platform (and more particularly to the C.H.I.P from NextThing Co.). > > > > > > So my question is, how should I port those changes to U-Boot? I see > > > that your doing "synchronization commits", but in my case this mean > > > including a bunch of driver specific changes into this "sync commit". > > > > > > I think it's also worth mentioning that I plan to heavily rework the > > > Linux NAND framework to improve NAND performances on modern NAND > > > controllers and clarify the NAND chip / NAND controller concepts, and > > > other people are also working on merging the BBT code of the NAND and > > > OneNAND framework. Which unfortunately means that we're not done porting > > > invasive changes to U-Boot :-/. > > > > > > Any advice is welcome. > > > > I suppose my first suggestion would be to sync the kernel back into > > U-Boot more frequently. With our bi-monthly release cycle it shouldn't > > be too hard to pick a window to grab the current kernel release and > > bring it over. I think the more stuff we let build up prior to syncing > > the harder it will be. > > > > Okay, so this means I should be the one back-porting Linux changes into > U-Boot? I was planning on porting my current work on the sunxi NAND > driver (including all the core dependencies) and submitting it to > U-Boot, but honestly, I don't see how I can keep things in sync in the > long run. From my experience, porting things to U-Boot is never as > easy at it seems, and I don't think I'll have the time to maintain that > by myself. Scott, what's your policy regarding Linux -> U-Boot syncs? > Can I expect some help from your side? I usually do syncs when someone complains about needing a sync. Every release seems a bit much. I'll try to do one soon. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch v2] fsl-layerscape: fdt: add IFC fixup if no IFC is avaliable in U-Boot
On Thu, 2016-04-28 at 14:04 +0800, Gong Qianyu wrote: > IFC is considered as a required component in Layerscape platforms' Linux. What does this mean? > But if IFC is not enabled in U-Boot on some boards, accessing IFC memory > space would cause kernel call trace. So disable IFC node in such cases. That's the symptom, not the problem. The problem is that the kernel is assuming that U-Boot has done certain initialization, such as the chipselect registers, and clearing SRAM (though Linux really should be doing the latter). Why is U-Boot being configured without this? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Fix spelling of "occurred".
On Mon, 2016-05-02 at 13:26 -0600, Simon Glass wrote: > Hi Scott, > > On 2 May 2016 at 13:03, Scott Wood wrote: > > On Mon, 2016-05-02 at 12:57 -0600, Simon Glass wrote: > > > Hi Scott, > > > > > > On 1 May 2016 at 17:34, Scott Wood wrote: > > > > On Sun, 2016-05-01 at 12:55 -0600, Simon Glass wrote: > > > > > Hi, > > > > > > > > > > On 30 April 2016 at 20:18, Vagrant Cascadian > > > > > wrote: > > > > > > > > > > Please can you add a commit message? > > > > > > > > I don't understand these "empty/missing commit message" remarks when > > > > there's a > > > > one-line changelog (in the subject). Do you seriously want the same > > > > line > > > > repeated twice in the git commit, just so something shows up in the > > > > body > > > > of > > > > the e-mail? It's one thing if the commit warrants more than a single > > > > line > > > > (though it's still not accurate to say that the changelog is > > > > completely > > > > absent), but a spelling fix is about as trivial as it gets... > > > > -Scott > > > > > > > > > > It only takes a few seconds to add a commit message and I think it is > > > good practice. > > > > > > But if you want to allow commits with no message (other than > > > merge/release tag), then we should document it here: > > > http://www.denx.de/wiki/U-Boot/Patches > > > > There is a commit message. It is 'Fix spelling of "occurred"'. > > > > And that wiki link explicitly says, "Put a detailed description after the > > summary and blank line. If the summary line is sufficient to describe the > > change, you can omit the blank line and detailed description." > > OK I made a little update to make it more limited: > > "Put a detailed description after the summary and blank line. If the > summary line is sufficient to describe the change (e.g. it is a > trivial spelling correction or whitespace update), you can omit the > blank line and detailed description." > > Does that seem reasonable? It's an example so it doesn't really limit anything -- if it did, I think that'd be way too specific. The criteria should be whether the single line adequately describes the patch (including justification, etc. if non-obvious). If it doesn't, then ask for a more detailed changelog, the same as you would if it contained more than one line but still didn't adequately describe the patch. > We should avoid submitting new drivers and forgetting a commit > message. I could see a new driver sometimes reasonably having a one-line commit message (which is not the same as "forgetting a commit message"). It's a driver for hardware . If there's nothing unusual to be noted about the driver, known limitations, etc. then what else is there to say? > Also some fixes are trivial (e.g. adding 1 to a result) but > the reason for them needs to be explained. Yes, but simply mandating text beyond the summary line is likely to get you stuff like: foo: Add 1 to result of blah() Add one to the result of blah(). Signed-off-by: whoever The problem there is not brevity, it's that important information is missing. > Sorry if I'm being picky on this. I've spent a *lot* of time over the > past few years digging into code and finding changes that are not > self-explanatory. That's why I am keen on people adding comments to > header files for API functions and struct members Yes, we could definitely use more API/struct documentation. I have no problem with pushing for better changelogs in cases where more information would be helpful. But we shouldn't mandate the changelog equivalent of: i++; /* add one to i */ > I think it helps for people to answer the question 'why should this > code be submitted?' when writing a commit message. For the record. in > this case, I would have added a message something like 'Occurred is > spelled incorrectly in a number of places. Fix these up to provide > consistency'. OK, but "fix spelling" followed by a diff showing the misspellings conveys the same information quite clearly. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Fix spelling of "occurred".
On Mon, 2016-05-02 at 12:57 -0600, Simon Glass wrote: > Hi Scott, > > On 1 May 2016 at 17:34, Scott Wood wrote: > > On Sun, 2016-05-01 at 12:55 -0600, Simon Glass wrote: > > > Hi, > > > > > > On 30 April 2016 at 20:18, Vagrant Cascadian wrote: > > > > > > Please can you add a commit message? > > > > I don't understand these "empty/missing commit message" remarks when > > there's a > > one-line changelog (in the subject). Do you seriously want the same line > > repeated twice in the git commit, just so something shows up in the body > > of > > the e-mail? It's one thing if the commit warrants more than a single line > > (though it's still not accurate to say that the changelog is completely > > absent), but a spelling fix is about as trivial as it gets... > > -Scott > > > > It only takes a few seconds to add a commit message and I think it is > good practice. > > But if you want to allow commits with no message (other than > merge/release tag), then we should document it here: > http://www.denx.de/wiki/U-Boot/Patches There is a commit message. It is 'Fix spelling of "occurred"'. And that wiki link explicitly says, "Put a detailed description after the summary and blank line. If the summary line is sufficient to describe the change, you can omit the blank line and detailed description." -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Fix spelling of "occurred".
On Sun, 2016-05-01 at 12:55 -0600, Simon Glass wrote: > Hi, > > On 30 April 2016 at 20:18, Vagrant Cascadian wrote: > > Please can you add a commit message? I don't understand these "empty/missing commit message" remarks when there's a one-line changelog (in the subject). Do you seriously want the same line repeated twice in the git commit, just so something shows up in the body of the e-mail? It's one thing if the commit warrants more than a single line (though it's still not accurate to say that the changelog is completely absent), but a spelling fix is about as trivial as it gets... -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/9] drivers: nand: Kconfig: add NAND as Kconfig option
On Fri, 2016-04-08 at 15:45 -0400, Tom Rini wrote: > On Tue, Apr 05, 2016 at 02:07:46PM +0530, Mugunthan V N wrote: > > Scott/Tom > > > > On Saturday 02 April 2016 05:55 AM, Tom Rini wrote: > > > On Fri, Apr 01, 2016 at 06:45:03PM -0500, Scott Wood wrote: > > > > On Fri, 2016-04-01 at 19:41 -0400, Tom Rini wrote: > > > > > On Fri, Apr 01, 2016 at 06:07:18PM -0500, Scott Wood wrote: > > > > > > > > > > > On Fri, 2016-04-01 at 08:51 -0400, Tom Rini wrote: > > > > > > > On Fri, Apr 01, 2016 at 04:59:44PM +0530, Mugunthan V N wrote: > > > > > > > > > > > > > > > Add CONFIG_NAND as a Kconfig option so that it can be selected > > > > > > > > using menuconfig or defconfig. > > > > > > > > > > > > > > > > Signed-off-by: Mugunthan V N > > > > > > > > > > > > > > Good but you need to update configs/ to remove NAND from > > > > > > > CONFIG_SYS_EXTRA_OPTIONS and add CONFIG_NAND=y > > > > > > > > > > > > NACK > > > > > > > > > > > > That CONFIG_NAND is a target-local option used by some boards to > > > > > > indicate > > > > > > boot > > > > > > source. It is not equivalent to CONFIG_CMD_NAND which is what > > > > > > enables the > > > > > > NAND subsystem. > > > > > > > > > > Exactly! We need to have 'NAND' moved from CONFIG_SYS_EXTRA_OPTIONS > > > > > and > > > > > into a real Kconfig entry. That said, I think this might have > > > > > forgotten > > > > > to enable it in other places too but just 'NAND' needs to migrate > > > > > out of > > > > > where it is. > > > > > > > > If we must start using NAND rather than CMD_NAND to enable the NAND > > > > subsystem > > > > (which is what this patch does), then a lot more than that needs to > > > > change. > > > > We'll need a new name for the boot source selection, and we'll need > > > > to > > > > kconfigize all the boards that enable CONFIG_CMD_NAND via the board > > > > config > > > > header. > > > > > > OK, I see your point now too. Yes, we need to tackle NAND/CMD_NAND > > > Kconfig stuff (including the tangled web of CMD_NAND being how we toggle > > > NAND the functionality) as a pre-patch series to this. But it needs > > > doing :) > > > > Should I be moving back NAND to "CONFIG_SYS_EXTRA_OPTIONS"? > > > > Since CONFIG_CMD_NAND is used to enable NAND subsystem, so move > > CONFIG_CMD_NAND to drivers/mtd/nand/Kconfig? > > > > or am I missing something? > > I would like to see, but I want to hear Scott's opinion, move to > CONFIG_NAND is what enables NAND support for everyone (so yes, lots of > defconfigs will need an update) so that we can move it all over to > Kconfig. I'm fine with changing the names as long as everything gets updated properly. The boards which use CONFIG_NAND to mean NAND boot (which is a relic of an old and dead config mechanism that parsed extra words added to a target name) can be changed to CONFIG_NAND_BOOT. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [u-boot] [PATCH] arm: sleep: Get the entry point of kernel from SPARE4 register
On 04/07/2016 04:11 AM, Huan Wang wrote:
> Hi, Scott,
>
>> On 04/05/2016 09:16 PM, Huan Wang wrote:
>>> Hi, York and Scott,
>>>
On 04/05/2016 05:11 AM, Alison Wang wrote:
> For LS1021A Secure Boot, SPARE2 register is used and modified by the
> IBR. To avoid the conflict, SPARE4 is used instead of SPARE2 to
> store the entry point of kernel. This patch is to get the entry
> point of kernel from SPARE4 instead of SPARE2.
>
> Signed-off-by: Alison Wang
> ---
> board/freescale/common/arm_sleep.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/board/freescale/common/arm_sleep.c
> b/board/freescale/common/arm_sleep.c
> index 71ed15e..6d967f0 100644
> --- a/board/freescale/common/arm_sleep.c
> +++ b/board/freescale/common/arm_sleep.c
> @@ -88,7 +88,7 @@ int fsl_dp_resume(void)
> dp_resume_prepare();
>
> /* Get the entry address and jump to kernel */
> - start_addr = in_le32(&scfg->sparecr[1]);
> + start_addr = in_le32(&scfg->sparecr[3]);
> debug("Entry address is 0x%08x\n", start_addr);
> kernel_resume = (void (*)(void))start_addr;
> secure_ram_addr(_do_nonsec_entry)(kernel_resume, 0, 0, 0);
>
Alison,
Does this change need to be in sync with Kernel change?
York
Where does this get written?
-Scott
>>> [Alison Wang] Thanks for your replies. Your concerns are right.
>>> SPARE4 register needs to be written in kernel.
>>>
>>> This is an issue about deep sleep in LS1021A Secure Boot. It is found
>>> in SDK2.0. The corresponding patch for kernel is sent in SDK2.0.
>>>
>>> Well, deep sleep uses an old way in SDK2.0. For upstream, deep sleep
>>> patches haven't been sent out as it will use PSCI and there are some
>>> issues about PSCI. So the corresponding patch for kernel can't be sent
>>> out now.
>>
>> It's not about when the patch is sent. It's about managing
>> compatibility. There needs to be some way to communicate what the
>> expectations are between Linux and U-Boot, or to limit the change to
>> chips where this feature has never worked before. We can't introduce
>> regressions when the kernel is updated but not U-Boot, and regressions
>> when U-Boot is updated but not the kernel are almost as bad.
>>
>> -Scott
> [Alison Wang] Thanks for your advice. What you said is right. I will give up
> this patch in upstream now. Later, when the deep sleep patches for kernel is
> ready, I will fix the issue in U-Boot and kernel simultaneously. So there
> isn't
> any problem about the compatibility between U-Boot and kernel.
Please reread what I wrote. Fixing them simultaneously doesn't solve
the problem because there's no guarantee that users update
simultaneously. For a particularly bad example, consider someone
bisecting the kernel. It would be terrible to require that the boot
firmware be reflashed every time the kernel crosses this boundary.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [u-boot] [PATCH] arm: sleep: Get the entry point of kernel from SPARE4 register
On 04/05/2016 09:16 PM, Huan Wang wrote:
> Hi, York and Scott,
>
>> On 04/05/2016 05:11 AM, Alison Wang wrote:
>>> For LS1021A Secure Boot, SPARE2 register is used and modified by the
>>> IBR. To avoid the conflict, SPARE4 is used instead of SPARE2 to store
>>> the entry point of kernel. This patch is to get the entry point of
>>> kernel from SPARE4 instead of SPARE2.
>>>
>>> Signed-off-by: Alison Wang
>>> ---
>>> board/freescale/common/arm_sleep.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/board/freescale/common/arm_sleep.c
>>> b/board/freescale/common/arm_sleep.c
>>> index 71ed15e..6d967f0 100644
>>> --- a/board/freescale/common/arm_sleep.c
>>> +++ b/board/freescale/common/arm_sleep.c
>>> @@ -88,7 +88,7 @@ int fsl_dp_resume(void)
>>> dp_resume_prepare();
>>>
>>> /* Get the entry address and jump to kernel */
>>> - start_addr = in_le32(&scfg->sparecr[1]);
>>> + start_addr = in_le32(&scfg->sparecr[3]);
>>> debug("Entry address is 0x%08x\n", start_addr);
>>> kernel_resume = (void (*)(void))start_addr;
>>> secure_ram_addr(_do_nonsec_entry)(kernel_resume, 0, 0, 0);
>>>
>> Alison,
>>
>> Does this change need to be in sync with Kernel change?
>>
>> York
>>
>> Where does this get written?
>>
>> -Scott
> [Alison Wang] Thanks for your replies. Your concerns are right.
> SPARE4 register needs to be written in kernel.
>
> This is an issue about deep sleep in LS1021A Secure Boot. It is found
> in SDK2.0. The corresponding patch for kernel is sent in SDK2.0.
>
> Well, deep sleep uses an old way in SDK2.0. For upstream, deep sleep
> patches haven't been sent out as it will use PSCI and there are some
> issues about PSCI. So the corresponding patch for kernel can't be sent
> out now.
It's not about when the patch is sent. It's about managing
compatibility. There needs to be some way to communicate what the
expectations are between Linux and U-Boot, or to limit the change to
chips where this feature has never worked before. We can't introduce
regressions when the kernel is updated but not U-Boot, and regressions
when U-Boot is updated but not the kernel are almost as bad.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [u-boot] [PATCH] arm: sleep: Get the entry point of kernel from SPARE4 register
On 04/05/2016 05:11 AM, Alison Wang wrote:
> For LS1021A Secure Boot, SPARE2 register is used and modified by the
> IBR. To avoid the conflict, SPARE4 is used instead of SPARE2 to store
> the entry point of kernel. This patch is to get the entry point of
> kernel from SPARE4 instead of SPARE2.
>
> Signed-off-by: Alison Wang
> ---
> board/freescale/common/arm_sleep.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/board/freescale/common/arm_sleep.c
> b/board/freescale/common/arm_sleep.c
> index 71ed15e..6d967f0 100644
> --- a/board/freescale/common/arm_sleep.c
> +++ b/board/freescale/common/arm_sleep.c
> @@ -88,7 +88,7 @@ int fsl_dp_resume(void)
> dp_resume_prepare();
>
> /* Get the entry address and jump to kernel */
> - start_addr = in_le32(&scfg->sparecr[1]);
> + start_addr = in_le32(&scfg->sparecr[3]);
> debug("Entry address is 0x%08x\n", start_addr);
> kernel_resume = (void (*)(void))start_addr;
> secure_ram_addr(_do_nonsec_entry)(kernel_resume, 0, 0, 0);
>
Where does this get written?
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] kirkwood_nand: claim MPP pins on the fly
On 03/24/2016 03:40 AM, Stefan Roese wrote: > On 02.02.2016 00:35, Chris Packham wrote: >> Claim the MPP pins for the NAND flash controller only when it's actually >> being used. This allows the pins to be shared with the SPI interface >> which already supports an equivalent on-access MPP reconfiguration. >> >> Reviewed-by: Mark Tomlinson >> Signed-off-by: Chris Packham >> --- >> I haven't wrapped this with a configuration option because I think it >> should be safe to enable by default. It will either re-apply the same >> MPP configuration that has already been done in the board init or put >> the MPP pins into the correct mode to access NAND. >> >> I've only got access to one kirkwood based board with NAND flash so I'd >> appreciate some feedback from someone with access to a few different >> boards. >> >> From the datasheets I have access to it looks like there is only one >> possible MPP configuration for NF_IO[0-7] so that is what I've >> implemented. I'm not aware of anything using this driver that needs a >> different MPP config. >> >> Changes in v2: >> - make nand_config static const > > Scott, are you okay with this patch in v2? Yes. Acked-by: Scott Wood > If yes, will you pull it? > Or should I include it in a marvell pull request? Go ahead. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/9] drivers: nand: omap_gpmc: convert driver to adopt driver model
On Fri, 2016-04-01 at 16:59 +0530, Mugunthan V N wrote:
> adopt omap_gpmc driver to driver model.
>
> Signed-off-by: Mugunthan V N
> ---
> drivers/mtd/nand/omap_gpmc.c | 205
> +++
> 1 file changed, 205 insertions(+)
>
> diff --git a/drivers/mtd/nand/omap_gpmc.c b/drivers/mtd/nand/omap_gpmc.c
> index 4814fa2..df63491 100644
> --- a/drivers/mtd/nand/omap_gpmc.c
> +++ b/drivers/mtd/nand/omap_gpmc.c
> @@ -16,6 +16,10 @@
> #include
> #include
>
> +#include
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> #define BADBLOCK_MARKER_LENGTH 2
> #define SECTOR_BYTES 512
> #define ECCCLEAR (0x1 << 8)
> @@ -46,11 +50,22 @@ struct omap_nand_info {
> enum omap_ecc ecc_scheme;
> uint8_t cs;
> uint8_t ws; /* wait status pin (0,1) */
> + uint8_t bus_width; /* Bus width of NAND device */
> };
>
> +#ifndef CONFIG_DM_NAND
> /* We are wasting a bit of memory but al least we are safe */
> static struct omap_nand_info omap_nand_info[GPMC_MAX_CS];
>
> +#else
> +
> +struct omap_gpmc_platdata {
> + struct omap_nand_info *omap_nand_info;
> + struct gpmc *gpmc_cfg;
> + int max_cs;
> +};
> +#endif
> +
> /*
> * omap_nand_hwcontrol - Set the address pointers corretly for the
> * following address/data/command operation
> @@ -943,6 +958,8 @@ int __maybe_unused omap_nand_switch_ecc(uint32_t
> hardware, uint32_t eccstrength)
> }
> #endif /* CONFIG_SPL_BUILD */
>
> +#ifndef CONFIG_DM_NAND
> +
> /*
> * Board-specific NAND initialization. The following members of the
> * argument are board-specific:
> @@ -1034,3 +1051,191 @@ int board_nand_init(struct nand_chip *nand)
>
> return 0;
> }
> +
> +#else /* CONFIG_DM_NAND */
> +
> +static int omap_gpmc_probe(struct udevice *dev)
> +{
> + struct nand_chip *nand = dev_get_priv(dev);
> + struct omap_gpmc_platdata *pdata = dev_get_platdata(dev);
> + struct gpmc *gpmc_cfg = pdata->gpmc_cfg;
> + int32_t gpmc_config = 0;
> + int ecc_opt;
> + int cs = cs_next++;
> + int err = 0;
> +
> + while (cs < pdata->max_cs) {
> + /* Check if NAND type is set */
> + if ((readl(&gpmc_cfg->cs[cs].config1) & 0xC00) == 0x800) {
> + /* Found it!! */
> + break;
> + }
> + cs++;
> + }
> +
> + if (cs >= pdata->max_cs) {
> + printf("nand: error: Unable to find NAND settings in GPMC
> Configuration - quitting\n");
> + return -ENODEV;
> + }
> +
> + gpmc_config = readl(&gpmc_cfg->config);
> + /* Disable Write protect */
> + gpmc_config |= 0x10;
> + writel(gpmc_config, &gpmc_cfg->config);
> +
> + nand->IO_ADDR_R = (void __iomem *)&gpmc_cfg->cs[cs].nand_dat;
> + nand->IO_ADDR_W = (void __iomem *)&gpmc_cfg->cs[cs].nand_cmd;
> + nand->priv = &pdata->omap_nand_info[cs];
> + nand->cmd_ctrl = omap_nand_hwcontrol;
> + nand->options |= NAND_NO_PADDING | NAND_CACHEPRG;
> + nand->chip_delay = 100;
> + nand->ecc.layout = &omap_ecclayout;
> +
> + /* configure driver and controller based on NAND device bus-width
> */
> + gpmc_config = readl(&gpmc_cfg->cs[cs].config1);
> + if (pdata->omap_nand_info[cs].bus_width == 16) {
> + nand->options |= NAND_BUSWIDTH_16;
> + writel(gpmc_config | (0x1 << 12), &gpmc_cfg
> ->cs[cs].config1);
> + } else {
> + nand->options &= ~NAND_BUSWIDTH_16;
> + writel(gpmc_config & ~(0x1 << 12), &gpmc_cfg
> ->cs[cs].config1);
> + }
> +
> + ecc_opt = pdata->omap_nand_info[cs].ecc_scheme;
> + /* select ECC scheme */
> + if (ecc_opt != OMAP_ECC_HAM1_CODE_SW) {
> + err = omap_select_ecc_scheme(nand, ecc_opt,
> + CONFIG_SYS_NAND_PAGE_SIZE,
> + CONFIG_SYS_NAND_OOBSIZE);
> + } else {
> + /*
> + * pagesize and oobsize are not required to
> + * configure sw ecc-scheme
> + */
> + err = omap_select_ecc_scheme(nand, ecc_opt, 0, 0);
> + }
> + if (err)
> + return err;
> +
> +#ifdef CONFIG_NAND_OMAP_GPMC_PREFETCH
> + nand->read_buf = omap_nand_read_prefetch;
> +#else
> + if (nand->options & NAND_BUSWIDTH_16)
> + nand->read_buf = nand_read_buf16;
> + else
> + nand->read_buf = nand_read_buf;
> +#endif
> +
> + nand->dev_ready = omap_dev_ready;
> +
> + return 0;
> +}
Is it really necessary to duplicate the entire probe func based on DM?
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] MAINTAINERS: Update Scott Wood's email address
Freescale is now NXP. I still work there, but I won't be using their mail system for U-Boot development. Signed-off-by: Scott Wood --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 32f97b2..8f371fe 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -348,7 +348,7 @@ F: drivers/net/ F: net/ NAND FLASH -M: Scott Wood +M: Scott Wood S: Maintained T: git git://git.denx.de/u-boot-nand-flash.git F: drivers/mtd/nand/ -- 2.5.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/9] drivers: nand: Kconfig: add NAND as Kconfig option
On Fri, 2016-04-01 at 19:41 -0400, Tom Rini wrote: > On Fri, Apr 01, 2016 at 06:07:18PM -0500, Scott Wood wrote: > > > On Fri, 2016-04-01 at 08:51 -0400, Tom Rini wrote: > > > On Fri, Apr 01, 2016 at 04:59:44PM +0530, Mugunthan V N wrote: > > > > > > > Add CONFIG_NAND as a Kconfig option so that it can be selected > > > > using menuconfig or defconfig. > > > > > > > > Signed-off-by: Mugunthan V N > > > > > > Good but you need to update configs/ to remove NAND from > > > CONFIG_SYS_EXTRA_OPTIONS and add CONFIG_NAND=y > > > > NACK > > > > That CONFIG_NAND is a target-local option used by some boards to indicate > > boot > > source. It is not equivalent to CONFIG_CMD_NAND which is what enables the > > NAND subsystem. > > Exactly! We need to have 'NAND' moved from CONFIG_SYS_EXTRA_OPTIONS and > into a real Kconfig entry. That said, I think this might have forgotten > to enable it in other places too but just 'NAND' needs to migrate out of > where it is. If we must start using NAND rather than CMD_NAND to enable the NAND subsystem (which is what this patch does), then a lot more than that needs to change. We'll need a new name for the boot source selection, and we'll need to kconfigize all the boards that enable CONFIG_CMD_NAND via the board config header. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/9] drivers: nand: implement a NAND uclass
On Fri, 2016-04-01 at 18:25 -0500, Scott Wood wrote:
> On Fri, 2016-04-01 at 16:59 +0530, Mugunthan V N wrote:
> > +static int nand_child_pre_probe(struct udevice *dev)
> > +{
> > + nand_info_t *nand = dev_get_uclass_priv(dev);
> > + void *priv = dev_get_priv(dev);
> > +
> > + /*
> > +* Store nand device priv pointer in nand_info so that
> > +* it can be used by nand command
> > +*/
> > + nand->priv = priv;
>
> Wouldn't it make more sense to have a pointer to the device in the NAND
> struct, and let the driver manage both privs as it chooses?
This makes even less sense after seeing patch 5/9, which assumes dev priv is
nand_info_t, and stores its own data in nand->priv. Won't this overwrite
that?
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/9] drivers: nand: implement a NAND uclass
On Fri, 2016-04-01 at 16:59 +0530, Mugunthan V N wrote:
> +static int nand_child_pre_probe(struct udevice *dev)
> +{
> + nand_info_t *nand = dev_get_uclass_priv(dev);
> + void *priv = dev_get_priv(dev);
> +
> + /*
> + * Store nand device priv pointer in nand_info so that
> + * it can be used by nand command
> + */
> + nand->priv = priv;
Wouldn't it make more sense to have a pointer to the device in the NAND
struct, and let the driver manage both privs as it chooses?
> +
> + return 0;
> +}
> +
> +UCLASS_DRIVER(nand) = {
> + .id = UCLASS_NAND,
> + .name = "nand",
> + .flags = DM_UC_FLAG_SEQ_ALIAS,
> + .post_probe = nand_child_pre_probe,
> + .per_device_auto_alloc_size = sizeof(nand_info_t),
> +};
Post probe = pre probe?
> @@ -63,8 +63,10 @@ int nand_register(int devnum)
> static void nand_init_chip(int i)
> {
> struct mtd_info *mtd;
> +#ifndef CONFIG_DM_NAND
> struct nand_chip *nand = &nand_chip[i];
> ulong base_addr = base_address[i];
> +#endif
> int maxchips = CONFIG_SYS_NAND_MAX_CHIPS;
>
> if (maxchips < 1)
> @@ -74,11 +76,13 @@ static void nand_init_chip(int i)
> if (!mtd)
> return;
>
> +#ifndef CONFIG_DM_NAND
> mtd->priv = nand;
> nand->IO_ADDR_R = nand->IO_ADDR_W = (void __iomem *)base_addr;
>
> if (board_nand_init(nand))
> return;
> +#endif
>
> if (nand_scan(mtd, maxchips))
> return;
Please do not use this code for DM. Have drivers' probe functions call
nand_scan (split into ident and tail if necessary) as is done with
CONFIG_SYS_NAND_SELF_INIT.
> diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h
> index 37c4176..6a88d39 100644
> --- a/include/dm/uclass-id.h
> +++ b/include/dm/uclass-id.h
> @@ -49,6 +49,7 @@ enum uclass_id {
> UCLASS_MMC, /* SD / MMC card or chip */
> UCLASS_MOD_EXP, /* RSA Mod Exp device */
> UCLASS_MTD, /* Memory Technology Device (MTD) device
> */
> + UCLASS_NAND,/* NAND bus */
NAND is not a bus.
> +#ifndef CONFIG_DM_NAND
> static inline nand_info_t *get_nand_dev_by_index(int dev)
> {
> if (dev < 0 || dev >= CONFIG_SYS_MAX_NAND_DEVICE ||
> @@ -154,5 +156,8 @@ static inline nand_info_t *get_nand_dev_by_index(int
> dev)
>
> return &nand_info[dev];
> }
> +#else
> +nand_info_t *get_nand_dev_by_index(int idx);
> +#endif
Please use "if X/else", not "if !X/else".
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/9] drivers: nand: Kconfig: add NAND as Kconfig option
On Fri, 2016-04-01 at 08:51 -0400, Tom Rini wrote: > On Fri, Apr 01, 2016 at 04:59:44PM +0530, Mugunthan V N wrote: > > > Add CONFIG_NAND as a Kconfig option so that it can be selected > > using menuconfig or defconfig. > > > > Signed-off-by: Mugunthan V N > > Good but you need to update configs/ to remove NAND from > CONFIG_SYS_EXTRA_OPTIONS and add CONFIG_NAND=y NACK That CONFIG_NAND is a target-local option used by some boards to indicate boot source. It is not equivalent to CONFIG_CMD_NAND which is what enables the NAND subsystem. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/9] cmd: nand: abstract global variable usage for dm conversion
[Please CC me at this address rather than my NXP address]
On Fri, 2016-04-01 at 16:59 +0530, Mugunthan V N wrote:
> @@ -432,12 +435,7 @@ static int do_nand(cmd_tbl_t *cmdtp, int flag, int
> argc, char * const argv[])
>* one before these commands can run, even if a partition specifier
>* for another device is to be used.
>*/
> - if (dev < 0 || dev >= CONFIG_SYS_MAX_NAND_DEVICE ||
> - !nand_info[dev].name) {
> - puts("\nno devices available\n");
> - return 1;
> - }
> - nand = &nand_info[dev];
> + nand = get_nand_dev_by_index(dev);
>
> if (strcmp(cmd, "bad") == 0) {
You eliminated the error check -- now a NULL deref is likely if a bad dev is
requested. Even if it's checked elsewhere when setting nand_curr_device, it's
possible that the initial default is bad (no NAND devices present, or device 0
failed).
> printf("\nDevice %d bad blocks:\n", dev);
> @@ -496,13 +494,13 @@ static int do_nand(cmd_tbl_t *cmdtp, int flag, int
> argc, char * const argv[])
> /* skip first two or three arguments, look for offset and
> size */
> if (mtd_arg_off_size(argc - o, argv + o, &dev, &off, &size,
>&maxsize, MTD_DEV_TYPE_NAND,
> - nand_info[dev].size) != 0)
> + nand->size) != 0)
> return 1;
>
> if (set_dev(dev))
> return 1;
>
> - nand = &nand_info[dev];
> + nand = get_nand_dev_by_index(dev);
Maybe have set_dev return the dev pointer?
Or have a global for the pointer rather than just the index, saving a bunch of
these calls.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A with QSPI enabled
On Wed, 2016-03-30 at 06:20 +, Qianyu Gong wrote: > Hi Scott, > > > -Original Message- > > From: Scott Wood [mailto:o...@buserror.net] > > Sent: Wednesday, March 30, 2016 4:45 AM > > To: Qianyu Gong ; u-boot@lists.denx.de; york sun > > > > Cc: Mingkai Hu > > Subject: Re: [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A with > > QSPI > > enabled > > > > On Fri, 2016-03-11 at 10:18 +, Qianyu Gong wrote: > > > Hi Scott, > > > > > > > -Original Message- > > > > From: Scott Wood [mailto:o...@buserror.net] > > > > Sent: Tuesday, February 23, 2016 8:12 AM > > > > To: Qianyu Gong ; u-boot@lists.denx.de; york > > > > sun > > > > Cc: Mingkai Hu > > > > Subject: Re: [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A > > > > with QSPI enabled > > > > > > > > On Mon, 2016-02-22 at 18:05 +0800, Gong Qianyu wrote: > > > > > QSPI and IFC are pin-multiplexed on LS1043A. So if QSPI is > > > > > enabled, IFC should be disabled. > > > > > But just disable IFC driver in LS1043A Linux is not enough because > > > > > mdio-mux will access IFC address space -- actually it accesses > > > > > FPGA which is connected to IFC CS3. So disable the whole IFC node > > > > > in Linux device tree. > > > > > > > > > > Signed-off-by: Gong Qianyu > > > > > > > > > > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c > > > > > b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c > > > > > index 4e4861d..5bb3048 100644 > > > > > --- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c > > > > > +++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c > > > > > @@ -204,4 +204,11 @@ void ft_cpu_setup(void *blob, bd_t *bd) > > > > > #ifdef > > > > > CONFIG_FSL_LSCH3 > > > > > fdt_fixup_smmu(blob); > > > > > #endif > > > > > + > > > > > +#ifdef CONFIG_LS1043A > > > > > +#ifdef CONFIG_FSL_QSPI > > > > > + do_fixup_by_compat(blob, "fsl,ifc", > > > > > +"status", "disabled", 8 + 1, 1); #endif > > > > > #endif > > > > > } > > > > > > > > This muxing is done at runtime, right? It isn't a case of the board > > > > hardwiring one or the other? In that case, it should be handled at > > > > runtime here as well. > > > > At a > > > > minimum, allow the user to use hwconfig to choose which they want to > > > > be accessible. Ideally there would be something in the device tree > > > > to list the reason(s) for a device being disabled, so the OS knows > > > > it can regard the device as being enabled if it knows about and > > > > enables them all. > > > > > > > > -Scott > > > > > > Sorry for the late reply. We have been asking the silicon team for the > > > details of the pin muxing these days. > > > The conclusion is that all IFC interfaces(cs0/cs1/cs2) are disabled as > > > long as QSPI is enabled on LS1043AQDS board. > > > As I know, this muxing won't be handled in kernel. Since IFC is > > > disabled in U-Boot, IFC node would better be disabled in kernel as > > > well. > > > Also in such cases, users have no other choice. > > > > Why should the user not have a choice to choose IFC over QSPI? Where is > > the > > muxing configured? > > > > -Scott > > Because this muxing can't be changed at runtime. > Two ways so far to configure it: > 1. SW6[1-4] switches on ls1043aqds board. > 2. Modify QIXIS board config registers and reset the board. These sound like runtime to me -- not compile time. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
