Re: [U-Boot] [PATCH 0/7] omap mmc: implement card detect and write protection
Hi Tom, On 02/15/2013 11:24 PM, Tom Rini wrote: On Mon, Dec 03, 2012 at 02:19:40PM +0200, Nikita Kiryanov wrote: This patchset implements card detection and write protection check for omap mmc. The write protect implementation also adds generic code that is usable by other mmc drivers. The first 3 patches are preparation patches that contain general maintenance for omap mmc driver. This patchset depends on http://patchwork.ozlabs.org/patch/202384/ Nikita Kiryanov (7): omap: consolidate common mmc definitions omap_hsmmc: fix out of bounds array access omap_hsmmc: introduce omap_hsmmc_data struct omap_hsmmc: implement driver check for card detection cm-t35: implement board specific card detect check mmc: add support for write protection omap_hsmmc: add driver check for write protection [...] For the series: Reviewed-by: Tom Rini Andy, since this touches generic code to add the write-protect stuff, which looks fine to me, I'd really like a chime-in before I take this to u-boot-ti, or you pick it all up for u-boot-mmc. Thanks! Now that rc1 is out, perhaps it is time to finally apply this series? Andy doesn't seem to be involved much in U-Boot these days, I don't think we should wait for him anymore. -- Regards, Nikita. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/mpc85xx: add setting of clock-frequency for mpic node
Hi york, Could you ack this patch? Thanks. > -Original Message- > From: Wang Dongsheng-B40534 > Sent: Monday, February 25, 2013 2:22 PM > To: Fleming Andy-AFLEMING > Cc: u-boot@lists.denx.de > Subject: RE: [PATCH] powerpc/mpc85xx: add setting of clock-frequency for > mpic node > > Hi Andy, > > Could you ack this patch? > > Thanks. > > > -Original Message- > > From: Wang Dongsheng-B40534 > > Sent: Thursday, January 31, 2013 12:52 PM > > To: u-boot@lists.denx.de > > Cc: Wang Dongsheng-B40534 > > Subject: [PATCH] powerpc/mpc85xx: add setting of clock-frequency for > mpic > > node > > > > Set the device tree property associated with the mpic source > > frequency. The frequency is used for mpic timer. > > > > Signed-off-by: Wang Dongsheng > > --- > > arch/powerpc/cpu/mpc85xx/fdt.c |5 + > > 1 files changed, 5 insertions(+), 0 deletions(-) > > > > diff --git a/arch/powerpc/cpu/mpc85xx/fdt.c > > b/arch/powerpc/cpu/mpc85xx/fdt.c > > index 3a268aa..f07d1cf 100644 > > --- a/arch/powerpc/cpu/mpc85xx/fdt.c > > +++ b/arch/powerpc/cpu/mpc85xx/fdt.c > > @@ -663,6 +663,11 @@ void ft_cpu_setup(void *blob, bd_t *bd) > > #ifdef CONFIG_FSL_CORENET > > do_fixup_by_compat_u32(blob, "fsl,qoriq-clockgen-1.0", > > "clock-frequency", CONFIG_SYS_CLK_FREQ, 1); > > + do_fixup_by_compat_u32(blob, "fsl,mpic", > > + "clock-frequency", get_bus_freq(0)/2, 1); > > +#else > > + do_fixup_by_compat_u32(blob, "fsl,mpic", > > + "clock-frequency", get_bus_freq(0), 1); > > #endif > > > > fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize); > > -- > > 1.7.5.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] ARM: mmu: Set domain permissions to client access - build warnings!
Hi, On Monday 04 March 2013 03:38 PM, Vincent Stehlé wrote: > On 03/02/2013 11:46 PM, Albert ARIBAUD wrote: >> (..) Basically, this means we need Vincent's series >> to be applied first, then we can apply Sricharan's. > Hi, > > I think this is too much trouble for a "one liner". Please feel free to > squash. > > Best regards, > > V. > Ok, i reposted the series again after squashing. http://www.mail-archive.com/u-boot@lists.denx.de/msg107487.html Regards, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH RESEND 3/3] ARM: mmu: Set domain permissions to client access
From: R Sricharan
The 'XN' execute never bit is set in the pagetables. This will
prevent speculative prefetches to non executable regions. But the
domain permissions are set as master in the DACR register.
So the pagetable attribute for 'XN' is not effective. Change the
permissions to client.
This fixes lot of speculative prefetch aborts seen on OMAP5
secure devices.
Signed-off-by: R Sricharan
Tested-by: Vincent Stehle
Cc: Vincent Stehle
Cc: Tom Rini
Cc: Albert ARIBAUD
---
arch/arm/cpu/armv7/cache_v7.c |3 ++
arch/arm/cpu/armv7/omap-common/hwinit-common.c | 35
arch/arm/include/asm/system.h | 14 ++
arch/arm/lib/cache-cp15.c |7 +
4 files changed, 59 insertions(+)
diff --git a/arch/arm/cpu/armv7/cache_v7.c b/arch/arm/cpu/armv7/cache_v7.c
index 5f6d039..8748c14 100644
--- a/arch/arm/cpu/armv7/cache_v7.c
+++ b/arch/arm/cpu/armv7/cache_v7.c
@@ -340,6 +340,9 @@ void mmu_page_table_flush(unsigned long start, unsigned
long stop)
{
}
+void arm_init_domains(void)
+{
+}
#endif /* #ifndef CONFIG_SYS_DCACHE_OFF */
#ifndef CONFIG_SYS_ICACHE_OFF
diff --git a/arch/arm/cpu/armv7/omap-common/hwinit-common.c
b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
index 9ef10bd..4eaf75b 100644
--- a/arch/arm/cpu/armv7/omap-common/hwinit-common.c
+++ b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
@@ -32,6 +32,12 @@
#include
#include
#include
+#include
+#include
+
+#define ARMV7_DCACHE_WRITEBACK 0xe
+#defineARMV7_DOMAIN_CLIENT 1
+#define ARMV7_DOMAIN_MASK (0x3 << 0)
DECLARE_GLOBAL_DATA_PTR;
@@ -258,4 +264,33 @@ void enable_caches(void)
/* Enable D-cache. I-cache is already enabled in start.S */
dcache_enable();
}
+
+void dram_bank_mmu_setup(int bank)
+{
+ bd_t *bd = gd->bd;
+ int i;
+
+ u32 start = bd->bi_dram[bank].start >> 20;
+ u32 size = bd->bi_dram[bank].size >> 20;
+ u32 end = start + size;
+
+ debug("%s: bank: %d\n", __func__, bank);
+ for (i = start; i < end; i++)
+ set_section_dcache(i, ARMV7_DCACHE_WRITEBACK);
+
+}
+
+void arm_init_domains(void)
+{
+ u32 reg;
+
+ reg = get_dacr();
+ /*
+ * Set DOMAIN to client access so that all permissions
+ * set in pagetables are validated by the mmu.
+ */
+ reg &= ~ARMV7_DOMAIN_MASK;
+ reg |= ARMV7_DOMAIN_CLIENT;
+ set_dacr(reg);
+}
#endif
diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
index 1918492..760345f 100644
--- a/arch/arm/include/asm/system.h
+++ b/arch/arm/include/asm/system.h
@@ -81,6 +81,20 @@ static inline void set_cr(unsigned int val)
isb();
}
+static inline unsigned int get_dacr(void)
+{
+ unsigned int val;
+ asm("mrc p15, 0, %0, c3, c0, 0 @ get DACR" : "=r" (val) : : "cc");
+ return val;
+}
+
+static inline void set_dacr(unsigned int val)
+{
+ asm volatile("mcr p15, 0, %0, c3, c0, 0 @ set DACR"
+ : : "r" (val) : "cc");
+ isb();
+}
+
/* options available for data cache on each page */
enum dcache_option {
DCACHE_OFF = 0x12,
diff --git a/arch/arm/lib/cache-cp15.c b/arch/arm/lib/cache-cp15.c
index 6ecbedf..4abe1cf 100644
--- a/arch/arm/lib/cache-cp15.c
+++ b/arch/arm/lib/cache-cp15.c
@@ -36,6 +36,10 @@ void __arm_init_before_mmu(void)
void arm_init_before_mmu(void)
__attribute__((weak, alias("__arm_init_before_mmu")));
+__weak void arm_init_domains(void)
+{
+}
+
static void cp_delay (void)
{
volatile int i;
@@ -117,6 +121,9 @@ static inline void mmu_setup(void)
/* Set the access control to all-supervisor */
asm volatile("mcr p15, 0, %0, c3, c0, 0"
: : "r" (~0));
+
+ arm_init_domains();
+
/* and enable the mmu */
reg = get_cr(); /* get control reg. */
cp_delay();
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH RESEND 2/3] ARM: mmu: Introduce weak dram_bank_setup function
From: R Sricharan
Introduce a weak version of dram_bank_setup function
to allow a platform specific function.
This is used in the subsequent patch to setup dram region
without 'XN' attribute in order to enable the region
under client permissions.
Signed-off-by: R Sricharan
Cc: Vincent Stehle
Cc: Tom Rini
Cc: Albert ARIBAUD
---
arch/arm/include/asm/cache.h |1 +
arch/arm/lib/cache-cp15.c|4 +++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/cache.h b/arch/arm/include/asm/cache.h
index 416d2c8..8153484 100644
--- a/arch/arm/include/asm/cache.h
+++ b/arch/arm/include/asm/cache.h
@@ -43,6 +43,7 @@ void l2_cache_enable(void);
void l2_cache_disable(void);
void set_section_dcache(int section, enum dcache_option option);
+void dram_bank_mmu_setup(int bank);
/*
* The current upper bound for ARM L1 data cache line sizes is 64 bytes. We
* use that value for aligning DMA buffers unless the board config has
specified
diff --git a/arch/arm/lib/cache-cp15.c b/arch/arm/lib/cache-cp15.c
index b6e5e95..6ecbedf 100644
--- a/arch/arm/lib/cache-cp15.c
+++ b/arch/arm/lib/cache-cp15.c
@@ -23,6 +23,8 @@
#include
#include
+#include
+#include
#if !(defined(CONFIG_SYS_ICACHE_OFF) && defined(CONFIG_SYS_DCACHE_OFF))
@@ -77,7 +79,7 @@ void mmu_set_region_dcache_behaviour(u32 start, int size,
mmu_page_table_flush((u32)&page_table[start], (u32)&page_table[end]);
}
-static inline void dram_bank_mmu_setup(int bank)
+__weak void dram_bank_mmu_setup(int bank)
{
bd_t *bd = gd->bd;
int i;
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH RESEND 1/3] ARM: cache: declare set_section_dcache
From: Vincent Stehlé We declare the set_section_dcache function globally in the cache header, for later use by e.g. machine specific code. Signed-off-by: Vincent Stehlé ti.com> Cc: Tom Rini ti.com> Cc: Albert ARIBAUD --- arch/arm/include/asm/cache.h |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/include/asm/cache.h b/arch/arm/include/asm/cache.h index eef6a5a..416d2c8 100644 --- a/arch/arm/include/asm/cache.h +++ b/arch/arm/include/asm/cache.h @@ -41,6 +41,7 @@ static inline void invalidate_l2_cache(void) void l2_cache_enable(void); void l2_cache_disable(void); +void set_section_dcache(int section, enum dcache_option option); /* * The current upper bound for ARM L1 data cache line sizes is 64 bytes. We -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH RESEND 0/3] ARM: mmu: Set domain permissions to client access
Currently for ARM based cpu's, mmu pagetable attributes are set with manager permissions for all 4GB address space. Because of this the 'execute never (XN)' permission is never checked on read sensitive regions which results in speculative aborts. This series changes the domain permissions of the full 4GB space to client access for OMAP socs. This avoids all the speculative aborts that are currently seen on OMAP5 secure devices. Tested on OMAP5 SDP (HS) soc. This is a repost of the older series to include Vincent's patch in the same one. R Sricharan (2): ARM: mmu: Introduce weak dram_bank_setup function ARM: mmu: Set domain permissions to client access Vincent Stehlé (1): ARM: cache: declare set_section_dcache arch/arm/cpu/armv7/cache_v7.c |3 ++ arch/arm/cpu/armv7/omap-common/hwinit-common.c | 35 arch/arm/include/asm/cache.h |2 ++ arch/arm/include/asm/system.h | 14 ++ arch/arm/lib/cache-cp15.c | 11 +++- 5 files changed, 64 insertions(+), 1 deletion(-) -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] ARM: atmel: add sama5d3xek support
Hi Tom, Thanks. On 3/5/2013 10:20, Tom Rini wrote: On Tue, Mar 05, 2013 at 10:03:57AM +0800, Bo Shen wrote: Hi Tom, On 3/4/2013 23:14, Tom Rini wrote: On Thu, Feb 28, 2013 at 03:00:47PM +0800, Bo Shen wrote: [snip] @@ -0,0 +1,268 @@ +/* + * Configuation settings for the SAMA5D3xEK board. [snip] +#undef CONFIG_USE_IRQ /* we don't need IRQ/FIQ stuff */ + +#undef CONFIG_CMDLINE_TAG /* enable passing of ATAGs */ +#undef CONFIG_SETUP_MEMORY_TAGS +#undef CONFIG_INITRD_TAG Just leave these, and the other #undef's out. You mean I need not to #undef these, because these are not defined, am I right? Correct. OK, I will remove it next version. +/* + * Command line configuration. + */ +#include +#undef CONFIG_CMD_FPGA +#undef CONFIG_CMD_IMI +#undef CONFIG_CMD_IMLS +#undef CONFIG_CMD_AUTOSCRIPT +#undef CONFIG_CMD_LOADS These are fine to leave in 'tho. These are no useful for us. I will consider remove unneeded #undef Right. Ditto. And please check things with checkpatch.pl, I thought I saw a '#defineFOO' in there. Thanks! I have checked this patch with checkpatch.pl, and get no errors and no warnings. OK, thanks. Best Regards, Bo Shen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 08/11] Blackfin: bf60x: add rsi/sdh support
Hi Wolfgang,
On Mon, Mar 4, 2013 at 7:21 PM, Wolfgang Denk wrote:
> Dear Sonic Zhang,
>
> In message
> you
> wrote:
>>
>> Maybe I didn't describe it clearly. Yes, I return 0 at the end of this
>> function. But, the same function may return UNUSABLE_ERR(-17) at the
>> beginning if the data flags match MMC_DATA_WRITE. That's why the
>> function can't return void. Is anything contradicting in my
>> explanation?
>
> I see. Sorry, I missed that other return.
>
> One additional question, though:
>
>> /* kick off transfer */
>> bfin_write_SDH_DATA_CTL(bfin_read_SDH_DATA_CTL() | DTX_DMA_E |
>> DTX_E);
>>
>> - return ret;
>> + return 0;
>
> Are the bfin_read_SDH_DATA_CTL() and bfin_write_SDH_DATA_CTL()
> supposed to always work, i. e. are we positively sure that these can
> never fail, so there is no need to test the return code and handle
> error conditions?
Yes, bfin_write_XXX and bfin_read_XXX are simply defined as memory
access operations. They either succeed or cause hardware error
exception.
#define bfin_read_SDH_DATA_CTL() bfin_read16(SDH_DATA_CTL)
#define _bfin_readX(addr, size, asm_size, asm_ext) ({ \
u32 __v; \
__asm__ __volatile__( \
"%0 = " #asm_size "[%1]" #asm_ext ";" \
: "=d" (__v) \
: "a" (addr) \
); \
__v; })
Regards,
Sonic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] ARM: atmel: add sama5d3xek support
On Tue, Mar 05, 2013 at 10:03:57AM +0800, Bo Shen wrote: > Hi Tom, > > On 3/4/2013 23:14, Tom Rini wrote: > >On Thu, Feb 28, 2013 at 03:00:47PM +0800, Bo Shen wrote: [snip] > >>@@ -0,0 +1,268 @@ > >>+/* > >>+ * Configuation settings for the SAMA5D3xEK board. > >[snip] > >>+#undef CONFIG_USE_IRQ /* we don't need IRQ/FIQ stuff > >>*/ > >>+ > >>+#undef CONFIG_CMDLINE_TAG /* enable passing of ATAGs */ > >>+#undef CONFIG_SETUP_MEMORY_TAGS > >>+#undef CONFIG_INITRD_TAG > > > >Just leave these, and the other #undef's out. > > You mean I need not to #undef these, because these are not defined, > am I right? Correct. > > >>+/* > >>+ * Command line configuration. > >>+ */ > >>+#include > >>+#undef CONFIG_CMD_FPGA > >>+#undef CONFIG_CMD_IMI > >>+#undef CONFIG_CMD_IMLS > >>+#undef CONFIG_CMD_AUTOSCRIPT > >>+#undef CONFIG_CMD_LOADS > > > >These are fine to leave in 'tho. > > These are no useful for us. > I will consider remove unneeded #undef Right. > >And please check things with checkpatch.pl, I > >thought I saw a '#defineFOO' in there. Thanks! > > I have checked this patch with checkpatch.pl, and get no errors and > no warnings. OK, thanks. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] ARM: atmel: add sama5d3xek support
Hi Tom,
On 3/4/2013 23:14, Tom Rini wrote:
On Thu, Feb 28, 2013 at 03:00:47PM +0800, Bo Shen wrote:
Add sama5d3xek support with following feature
- boot from NAND flash, PMECC support, 4bit ECC @ 512 bytes sector
- boot from SPI flash support
- boot from SD card support
- LCD support
- EMAC support
- USB support
Signed-off-by: Bo Shen
Some minor comments:
[snip]
+ if (cpu_is_sama5d3())
+ switch (extension_id) {
+ case ARCH_EXID_SAMA5D31:
+ return CONFIG_SYS_AT91_D31_CPU_NAME;
+ case ARCH_EXID_SAMA5D33:
+ return CONFIG_SYS_AT91_D33_CPU_NAME;
+ case ARCH_EXID_SAMA5D34:
+ return CONFIG_SYS_AT91_D34_CPU_NAME;
+ case ARCH_EXID_SAMA5D35:
+ return CONFIG_SYS_AT91_D35_CPU_NAME;
+ default:
+ return CONFIG_SYS_AT91_UNKNOWN_CPU;
These aren't configurable, and are used once. Just put the strings
here.
OK, I will use strings here directly here in next version.
@@ -0,0 +1,268 @@
+/*
+ * Configuation settings for the SAMA5D3xEK board.
[snip]
+#undef CONFIG_USE_IRQ /* we don't need IRQ/FIQ stuff */
+
+#undef CONFIG_CMDLINE_TAG /* enable passing of ATAGs */
+#undef CONFIG_SETUP_MEMORY_TAGS
+#undef CONFIG_INITRD_TAG
Just leave these, and the other #undef's out.
You mean I need not to #undef these, because these are not defined, am I
right?
+/*
+ * Command line configuration.
+ */
+#include
+#undef CONFIG_CMD_FPGA
+#undef CONFIG_CMD_IMI
+#undef CONFIG_CMD_IMLS
+#undef CONFIG_CMD_AUTOSCRIPT
+#undef CONFIG_CMD_LOADS
These are fine to leave in 'tho.
These are no useful for us.
I will consider remove unneeded #undef
+#ifdef CONFIG_USE_IRQ
+#error CONFIG_USE_IRQ not supported
+#endif
Just drop that part.
Ok, I will drop this in next version.
And please check things with checkpatch.pl, I
thought I saw a '#defineFOO' in there. Thanks!
I have checked this patch with checkpatch.pl, and get no errors and no
warnings.
Best Regards,
Bo Shen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd: nand: fix the written length when nand_write_skip_bad failed
On 03/02/2013 03:01:10 AM, Tao Hou wrote:
When the data has been partially written into the NAND Flash,
returning the written length instead of 0. The written length
may be useful when the upper level decides to continue the writing
after skipping the block causing the write failure.
We already do that in some code paths.
Signed-off-by: Tao Hou
Cc: Scott Wood
Cc: Ben Gardiner
Cc: Lei Wen
---
drivers/mtd/nand/nand_util.c | 22 +++---
1 file changed, 15 insertions(+), 7 deletions(-)
Could you rebase this on top of this patch:
http://patchwork.ozlabs.org/patch/224842/
BTW, are you actually using WITH_YAFFS_OOB? I think there are some
other things wrong with it at the moment, as mentioned here:
http://lists.denx.de/pipermail/u-boot/2013-March/148378.html
diff --git a/drivers/mtd/nand/nand_util.c
b/drivers/mtd/nand/nand_util.c
index de1d13e..f57d723 100644
--- a/drivers/mtd/nand/nand_util.c
+++ b/drivers/mtd/nand/nand_util.c
@@ -496,8 +496,10 @@ int nand_write_skip_bad(nand_info_t *nand,
loff_t offset, size_t *length,
#ifdef CONFIG_CMD_NAND_YAFFS
if (flags & WITH_YAFFS_OOB) {
- if (flags & ~WITH_YAFFS_OOB)
+ if (flags & ~WITH_YAFFS_OOB) {
+ *length = 0;
return -EINVAL;
+ }
int pages;
pages = nand->erasesize / nand->writesize;
@@ -505,6 +507,7 @@ int nand_write_skip_bad(nand_info_t *nand, loff_t
offset, size_t *length,
if (*length % (nand->writesize + nand->oobsize)) {
printf("Attempt to write incomplete page"
" in yaffs mode\n");
+ *length = 0;
return -EINVAL;
}
} else
@@ -542,7 +545,6 @@ int nand_write_skip_bad(nand_info_t *nand, loff_t
offset, size_t *length,
if (rval == 0)
return 0;
- *length = 0;
printf("NAND write to offset %llx failed %d\n",
offset, rval);
return rval;
OK so far...
@@ -550,7 +552,7 @@ int nand_write_skip_bad(nand_info_t *nand, loff_t
offset, size_t *length,
while (left_to_write > 0) {
size_t block_offset = offset & (nand->erasesize - 1);
- size_t write_size, truncated_write_size;
+ size_t write_size, truncated_write_size, written_size;
WATCHDOG_RESET();
@@ -586,8 +588,10 @@ int nand_write_skip_bad(nand_info_t *nand,
loff_t offset, size_t *length,
ops.oobbuf = ops.datbuf + pagesize;
rval = nand->write_oob(nand, offset,
&ops);
- if (rval != 0)
+ if (rval != 0) {
+ written_size = pagesize_oob *
page;
break;
+ }
offset += pagesize;
p_buffer += pagesize_oob;
@@ -605,14 +609,18 @@ int nand_write_skip_bad(nand_info_t *nand,
loff_t offset, size_t *length,
rval = nand_write(nand, offset,
&truncated_write_size,
p_buffer);
- offset += write_size;
- p_buffer += write_size;
+ if (rval == 0) {
+ offset += write_size;
+ p_buffer += write_size;
+ } else {
+ written_size = truncated_write_size;
+ }
}
if (rval != 0) {
printf("NAND write to offset %llx failed %d\n",
offset, rval);
- *length -= left_to_write;
+ *length -= left_to_write - written_size;
return rval;
}
...but I don't see why this part is needed (or correct). Why doesn't
"*length -= left_to_write" already get you what you want?
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/5] cmd_nand.c: Fix CONFIG_CMD_NAND_YAFFS
On 03/04/2013 07:27:40 PM, Tom Rini wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/04/2013 08:12 PM, Scott Wood wrote: > On 03/04/2013 04:17:10 PM, Tom Rini wrote: >> The flag changed from WITH_INLINE_OOB to WITH_YAFFS_OOB by >> accident in 418396e. >> >> Signed-off-by: Tom Rini --- Changes in v4: - Add >> patch to fix CONFIG_CMD_NAND_YAFFS >> >> Changes in v3: None Changes in v2: None >> >> common/cmd_nand.c |2 +- 1 file changed, 1 insertion(+), 1 >> deletion(-) >> >> diff --git a/common/cmd_nand.c b/common/cmd_nand.c index >> 76f4d3f..d9010d2 100644 --- a/common/cmd_nand.c +++ >> b/common/cmd_nand.c @@ -673,7 +673,7 @@ static int >> do_nand(cmd_tbl_t *cmdtp, int flag, int argc, char * const >> argv[]) } ret = nand_write_skip_bad(nand, off, &rwsize, NULL, >> maxsize, (u_char *)addr, - >> WITH_INLINE_OOB); +WITH_YAFFS_OOB); >> #endif > > Oops. Probably a leftover from an attempt to share code between > yaffs and raw accesses. > > BTW, it looks like there is no board that selects > CONFIG_CMD_NAND_YAFFS, so it doesn't get compile tested... ...and > smdk6400 defines CONFIG_SYS_NAND_YAFFS_WRITE, which nothing ever > tests. :-P Indeed. We lack some real users of YAFFS in U-Boot right now, and I don't wish to open a can of worms on why that might be. I see some other things in nand_write_skip_bad() that look broken for WITH_YAFFS_OOB (but have been there since before WITH_YAFFS_OOB was introduced...), in particular check_skip_len() and the call to nand_write() when need_skip is 0. Sorry if some worms just popped out. :-) -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/5] cmd_nand.c: Fix CONFIG_CMD_NAND_YAFFS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/04/2013 08:12 PM, Scott Wood wrote: > On 03/04/2013 04:17:10 PM, Tom Rini wrote: >> The flag changed from WITH_INLINE_OOB to WITH_YAFFS_OOB by >> accident in 418396e. >> >> Signed-off-by: Tom Rini --- Changes in v4: - Add >> patch to fix CONFIG_CMD_NAND_YAFFS >> >> Changes in v3: None Changes in v2: None >> >> common/cmd_nand.c |2 +- 1 file changed, 1 insertion(+), 1 >> deletion(-) >> >> diff --git a/common/cmd_nand.c b/common/cmd_nand.c index >> 76f4d3f..d9010d2 100644 --- a/common/cmd_nand.c +++ >> b/common/cmd_nand.c @@ -673,7 +673,7 @@ static int >> do_nand(cmd_tbl_t *cmdtp, int flag, int argc, char * const >> argv[]) } ret = nand_write_skip_bad(nand, off, &rwsize, NULL, >> maxsize, (u_char *)addr, - >> WITH_INLINE_OOB); +WITH_YAFFS_OOB); >> #endif > > Oops. Probably a leftover from an attempt to share code between > yaffs and raw accesses. > > BTW, it looks like there is no board that selects > CONFIG_CMD_NAND_YAFFS, so it doesn't get compile tested... ...and > smdk6400 defines CONFIG_SYS_NAND_YAFFS_WRITE, which nothing ever > tests. :-P Indeed. We lack some real users of YAFFS in U-Boot right now, and I don't wish to open a can of worms on why that might be. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRNUoMAAoJENk4IS6UOR1WH0IP/j0MPShdroqdmLXZKkG5wFOv yhg2hiXYGQU9eruBC0poGbPNQxaUA68rWwBe770f+S++ovpNQ3jORS/1I6OdpUqt c0EMcnY2GHCVP6Ct5lrqccif9SC0q0vueMqd2agErnkPZzfkKFFsyPkfAIoXIWcD vl8gA9yGpRP0GpIbN25Ow0WmV/cgyQzorwuwZPdQQ52jFKCH+g12YvdTdBG1nB70 ZZS79pKMy49YdSElTROb2WbfBU2j8kNK4FlOXoR+5wea6t6ejDr40WTFlqY+IU7E AYegnYNQcYcAq/yENKcTE6py7j94kDclVp5L+1aUpyZmsFNOP44BcGDIkubQAWR5 Cp9FRtRC2PEBOUTZv/3GDbn9OogIxqlKOwSbAj4A977bBT965IVZZoNS68hAOQph vTf1umSQQXqUjybPyhcCH3hDeULXjKkjj+Vi5pgwoBM28IRmbhBm68aSLX1FZL2x waWVsGa1J8bd96ZWZ6ML5vB9dUpdywW/tFOvPMkNyj43ugHEmaJ8EXdTB2H+1B+f b0tkCaMwU+Qd0kFlfIyEseR8QbG5K6ngZDCUtcw7LKQy+vC7YfaH6kx8sXaSdg4J QKNCqoQ+6uk6EfYJkVtK4NJTojRmu+jVTjv2Yne2if1uhYs7f04S1NZlqCmAUNAl QUU7sJ97JECLYDFITqBC =MFnf -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/5] cmd_nand.c: Fix CONFIG_CMD_NAND_YAFFS
On 03/04/2013 04:17:10 PM, Tom Rini wrote: The flag changed from WITH_INLINE_OOB to WITH_YAFFS_OOB by accident in 418396e. Signed-off-by: Tom Rini --- Changes in v4: - Add patch to fix CONFIG_CMD_NAND_YAFFS Changes in v3: None Changes in v2: None common/cmd_nand.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/common/cmd_nand.c b/common/cmd_nand.c index 76f4d3f..d9010d2 100644 --- a/common/cmd_nand.c +++ b/common/cmd_nand.c @@ -673,7 +673,7 @@ static int do_nand(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) } ret = nand_write_skip_bad(nand, off, &rwsize, NULL, maxsize, (u_char *)addr, - WITH_INLINE_OOB); + WITH_YAFFS_OOB); #endif Oops. Probably a leftover from an attempt to share code between yaffs and raw accesses. BTW, it looks like there is no board that selects CONFIG_CMD_NAND_YAFFS, so it doesn't get compile tested... ...and smdk6400 defines CONFIG_SYS_NAND_YAFFS_WRITE, which nothing ever tests. :-P -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Add new NAND flash
On 02/28/2013 07:55:56 PM, garyio wrote: Hi Scott, I know it's been a while but did you ever get this part to work? Thanks, Garyio What is "this part"? -- View this message in context: http://u-boot.10912.n7.nabble.com/U-Boot-Add-new-NAND-flash-tp72701p148633.html Sent from the U-Boot mailing list archive at Nabble.com. Oh, that. In the future, please provide context with quoted text, not just a link in the signature. I personally do not have this NAND chip and was not the one working on it. Ask Matthias if he got it to work. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] Tegra30: MMC: Add SD bus power-rail and SDMMC pad init routines
On 03/04/2013 04:11 PM, Tom Warren wrote:
> Stephen,
>
> On Wed, Feb 27, 2013 at 11:08 AM, Stephen Warren
> wrote:
>> On 02/27/2013 09:59 AM, Tom Warren wrote:
>>> Stephen,
>>>
>>> On Tue, Feb 26, 2013 at 4:26 PM, Stephen Warren
>>> wrote:
On 02/26/2013 01:46 PM, Tom Warren wrote:
> T30 requires specific SDMMC pad programming, and bus power-rail bringup.
> diff --git a/board/nvidia/cardhu/cardhu.c b/board/nvidia/cardhu/cardhu.c
> +/*
> + * Do I2C/PMU writes to bring up SD card bus power
> + *
> + */
> +void board_sdmmc_voltage_init(void)
We really shouldn't be adding to board files if we're remotely serious
about device tree; the whole point of DT is to remove code from the
board files, and describe the desired configuration as data in DT instead.
This function should be replaced by regulator nodes/properties in the
device tree, and the MMC (core?) driver calling into the board-specific
regulator driver to request the desired voltages.
But so long as we file a bug to replace this code with an explicit
regulator driver in the future, I guess it's fine for now.
>>>
>>> I'll file a bug for doing all PMU/power rail work from DT. I think it
>>> makes much more sense as a separate (non-MMC) patch.
>>
>> Yes, certainly a separate patch. Ideally it'd be implemented before
>> other code that relies on it. That's why I think we need to take a
>> higher-level look at DT support in U-Boot, rather than simply finding
>> these issue accidentally while implementing the features we already know
>> we need.
>>
BTW, I just noticed that commit f01b631 "Tegra30: Add/enable Cardhu
build (T30 reference board)" adds a file called
board/nvidia/cardhu/cardhu.c.mmc. That's a mistake, right?
>>>
>>> Yep, that's the Cardhu file I was hacking on for MMC support way back
>>> when. I can remove it in V2 of these patches, or would you prefer a
>>> single, separate patch to do that?
>>
>> Is the commit that adds that file already pulled into higher-level
>> repos? If not, I would simply rebase it to remove that file. If it has,
>> then a separate patch to delete it before this series would make sense.
>>
> diff --git a/board/nvidia/common/board.c b/board/nvidia/common/board.c
Hmm. This seems like SoC code, not board code...
> +void pad_init_mmc(struct tegra_mmc *reg)
> +{
> +#if defined(CONFIG_TEGRA30)
> + /* Set the pad drive strength for SDMMC1 or 3 only */
> + if (offset != TEGRA_SDMMC1_BASE && offset != TEGRA_SDMMC3_BASE) {
> + debug("%s: settings are only valid for SDMMC1/SDMMC3!\n",
> + __func__);
> + return;
> + }
Perhaps pass in the MMC instance ID instead of the base address. That'd
avoid having to know the base addresses in this code.
>>>
>>> I still need to know if I've got a SDIO or eMMC ID, though, and I
>>> don't think the flags for that in the mmc/host structs (mmc->version,
>>> etc.) get populated until the mmc driver has done some I/O with the
>>> device (eMMC or SD-card), and I need to set up the pads before that.
>>>
In fact, just putting this code into the pinmux driver (which owns these
registers) seems like a better idea; there's no need to only do this
when the SD controller is enabled, is there?
>>>
>>> Half of these regs are in the SD controller register space
>>> (sdmemcmpctl and autocalcfg), and get reset when the controller gets
>>> reset (mmc_reset). So they need to be set each time a reset occurs. It
>>> makes sense to keep the GP SDIOCFG writes here, too.
>>>
>>> As to where the pad_init_mmc function belongs, it is SoC-specific,
>>> yes. T20 doesn't need it (no sdmemcmpctl or autocalcfg regs on T20
>>> SDMMC), and T30 and T114 use slightly different bits/values for GP
>>> SDIOCFG and sdmemcmpctl/autocalcfg. But the differences are small
>>> enough that I thought this routine should be placed in a common area,
>>> and not duplicated for each SoC, so I put it here.
>>>
>>> Do you have a suggestion of where it would be better placed?
>>
>> For the pinmux registers, I think they should be programmed by the
>> pinmux driver at the same time as the rest of the pinmux is programmed.
>
> Technically, they're not pinmux registers (PINMUX_AUX_ space), but GP
> regs (APB_MISC_GP_ space). Since the pinmux _code_ (no pinmux driver
> is used in Tegra U-Boot)
The distinction isn't relevant for this discussion. Anyway, there really
is a driver...
> for T30 is just a large table slam, I don't
> think it makes sense to add GP pad reg writes there. These pads need
> to be tuned when you've got a board w/an SD-card device hanging off of
> them. So it makes sense to have these 2 register writes here in
> pad_init_mmc(). I can take out the SDMMC1/3 test and just write both
> SDIO1CFG and SDIO3CFG, since the values are the same.
Are these value board-specific or SoC-sp
Re: [U-Boot] dtb vs. kernel command line arguments
On Mon, 4 Mar 2013 10:30:45 -0800 Curt Brune wrote: > Hello - > > I want to pass a number of arguments from u-boot to the booted kernel. > The arguments are needed by user space applications, not the kernel. > > I can think of two ways: > > 1. append args by setting "bootargs". > 2. add nodes to the dtb before booting. > > Is there a preferred way to pass information like this? > > Like I said the arguments are not needed by the kernel device drivers, > but by user space applications. > > I like the structure of nodes in the dtb. please don't dual-purpose device trees as a mechanism of getting arguments through the kernel into userspace - device trees strictly describe the hardware. btw, this question would be more appropriately posted on devicetree-discuss (in case you have more). Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-x86.git
Hi Tom, Great to see the previous lot made it in. Here is the next x86 series. The following changes since commit 2536850d7cd90bdb75bf3ff86838f913392b68db: Prepare v2013.04-rc1 (2013-03-04 16:29:17 -0500) are available in the git repository at: git://git.denx.de/u-boot-x86.git master for you to fetch changes up to fc959081d41aab2d6f4614c5fb3dd1b77ffcdcf4: x86: Enable CONFIG_OF_CONTROL on coreboot (2013-03-04 15:57:52 -0800) Simon Glass (9): x86: Add function to get top of usable ram x86: Add basic cache operations x86: Permit bootstage and timer data to be used prior to relocation x86: Add an __end symbol to signal the end of the U-Boot binary x86: Rearrange the output input to remove BSS x86: Support relocation of FDT on start-up x86: Add error checking to x86 relocation code x86: Adjust link device tree include file x86: Enable CONFIG_OF_CONTROL on coreboot arch/x86/cpu/coreboot/coreboot.c| 15 +--- arch/x86/cpu/coreboot/sdram.c | 18 +++--- arch/x86/cpu/cpu.c | 23 + arch/x86/cpu/interrupts.c | 7 +++--- arch/x86/cpu/u-boot.lds | 21 ++-- arch/x86/include/asm/global_data.h | 4 +++ arch/x86/include/asm/init_helpers.h | 2 ++ arch/x86/include/asm/relocate.h | 1 + arch/x86/include/asm/u-boot-x86.h | 1 + arch/x86/lib/board.c| 3 +++ arch/x86/lib/init_helpers.c | 49 - arch/x86/lib/init_wrappers.c| 1 + arch/x86/lib/relocate.c | 37 ++-- arch/x86/lib/timer.c| 9 +++ board/chromebook-x86/dts/link.dts | 2 +- include/configs/coreboot.h | 6 + 16 files changed, 146 insertions(+), 53 deletions(-) Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] CONFIG_BOOTDELAY default should not affect runtime
Hi Tom, On Fri, Mar 1, 2013 at 2:28 PM, Tom Rini wrote: > On Wed, Feb 27, 2013 at 02:11:31PM -0600, Joe Hershberger wrote: >> Hi Tom, >> >> On Mon, Feb 18, 2013 at 11:20 AM, Tom Rini wrote: >> > -BEGIN PGP SIGNED MESSAGE- >> > Hash: SHA1 >> > >> > On 02/09/2013 11:21 AM, Otavio Salvador wrote: >> >> Hello Wolfgang, >> >> >> >> On Sat, Feb 9, 2013 at 4:54 AM, Wolfgang Denk wrote: >> >>> Dear Joe Hershberger, >> >>> >> >>> In message >> >>> <1360355280-1197-1-git-send-email-joe.hershber...@ni.com> you >> >>> wrote: >> Because the code that handles bootdelay is compiled in >> conditionally based on the default value, you are restricted in >> the default, regardless of what you want the runtime options to >> be. >> >> Change the source to always check if any default is given so >> that other values can be selected and used at runtime. >> >> Signed-off-by: Joe Hershberger --- >> common/main.c | 14 ++ 1 file changed, 6 >> insertions(+), 8 deletions(-) >> >> diff --git a/common/main.c b/common/main.c index >> e2d2e09..0973c59 100644 --- a/common/main.c +++ >> b/common/main.c @@ -95,7 +95,7 @@ extern void mdm_init(void); >> /* defined in board.c */ * Watch for 'delay' seconds for >> autoboot stop or autoboot delay string. * returns: 0 - no key >> string, allow autoboot 1 - got key string, abort */ -#if >> defined(CONFIG_BOOTDELAY) && (CONFIG_BOOTDELAY >= 0) +#if >> defined(CONFIG_BOOTDELAY) >> >>> >> >>> Careful!! This is probably changing behaviour of a number of >> >>> boards significantly. >> >>> >> >>> we have to check if we really want this, and if yes, we have to >> >>> announce it and provide a grace period (eventually using >> >>> doc/feature-removal-schedule.txt ?) >> >> >> >> It seems the CONFIG_BOOTDELAY as < 0 is not very common: >> >> >> >> ~/hacking/u-boot% git grep CONFIG_BOOTDELAY | egrep 'BOOTDELAY\s* >> >> \-[0-9]' include/configs/RPXsuper.h:#define CONFIG_BOOTDELAY >> >> -1 include/configs/ep8260.h:#define CONFIG_BOOTDELAY-1 >> >> include/configs/espt.h:#define CONFIG_BOOTDELAY-1 >> >> include/configs/scb9328.h:#define CONFIG_BOOTDELAY -1 >> >> include/configs/sh7763rdp.h:#define CONFIG_BOOTDELAY-1 >> > >> > I count 49 boards with git grep -E >> > 'CONFIG_BOOTDELAY[[:blank:]]+-[0-9]' so it's not _that_ uncommon. >> > >> >> So maybe those could have CONFIG_BOOTDELAY undefined keeping them >> >> working as before? >> > >> > The problem is that as I read the README, we document CONFIG_BOOTDELAY >> > as having a valid value range of from -2 to sane positive value. So >> > yes, if we want to change this we need to (a) change the README too >> > and (b) give some sort of heads-up. >> > >> > Off the top of my head, we could change to: >> > CONFIG_AUTOBOOT_DISABLED and CONFIG_FORCE_AUTOBOOT_NO_DELAY and update >> > doc/README.autoboot as well and add some sanity #warning checks for a >> > release or two in some common generated config related file or >> > something like that. >> >> The change has no effect on the behavior, it simply changes what is >> compiled in. If the default value is not changed, then the behavior >> is unchanged. The only impact this may have on existing boards is to >> make the code size slightly larger. If that is an issue for some >> reason, then CONFIG_BOOTDELAY can be undefined. >> >> If we want to add other config options, that's fine, but that's more >> involved that I was hoping for. > > I think we do have a behavior change as previously negative bootdelay > would not result in bootdelay being saved to the default env and thus > not in the env. Now, it's possible we can mostly retain compatibility > by making bootdelay part of the env if set, rather than if set >= 0. Or > am I still missing it and really, there's no change in behavior? The behavior change you are describing doesn't happen. The condition was not removed from include/env_default.h so the default env should remain exactly the same as before. The difference is that now the code that checks for the var to exists will initially hit the default case until "bootdelay" is added to the env. Cheers, -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Tegra: All Tamonten-derived boards use onboard NAND
On 03/04/2013 04:26 PM, Tom Warren wrote:
> Thierry,
>
> On Mon, Mar 4, 2013 at 3:41 PM, Thierry Reding
> wrote:
>> On Mon, Mar 04, 2013 at 01:46:48PM -0700, Tom Warren wrote:
>> [...]
>>> I kinda lost track of this patchset. I'd like to move it into
>>> u-boot-tegra/next if you think it's ready, but I'm not sure if it
>>> conflicts with/works with Stephen's 4th patch of his v2 series ("ARM:
>>> tegra: enable a common set of disk-related commands").
>>
>> I can rebase my patches on top of Stephen's work and resend them if it
>> helps.
>>
>> Thierry
> The only problem I see is that Stephen's patchset isn't exclusively
> Tegra-based, so I'm not sure I want to bring it into the Tegra tree
> and cause problems when I do a PR. The other half of the patchset is
> assigned to Tom Rini.
>
> Stephen - how would you like me to resolve this?
Hmmm. Thierry's patch series does quite a few things at once.
I'd suggest that Thierry posts a series that /just/ enables NAND
support. It should be possible to apply that on its own without any
conflicts/dependencies on my series.
Enabling FIT could also be a separate series without any
conflicts/dependencies.
A lot of the rest of that series is effectively part of my series, since
I ended up enabling all those new options in the various common Tegra
config files in my series.
The only thing left over is the removal of the custom definition of
CONFIG_BOOTCOMMAND in the AD headers. That should happen after my series.
Re: How to get my series into Tegra's tree. I think it'd be fine to
apply my series to the Tegra tree even though it touches disk/partition
code if you can get the/a maintainer for that code to ack it. Probably
someone like Tom Rini. That way, Thierry's CONFIG_BOOTCOMMAND changes
wouldn't have to wait long I hope.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] ARM: tegra: enable workaround for ARM erratum 716044
From: Stephen Warren Tegra20 requires the workaround for this erratum. Enable it. Signed-off-by: Stephen Warren --- include/configs/tegra20-common.h |1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/tegra20-common.h b/include/configs/tegra20-common.h index e464e06..395a657 100644 --- a/include/configs/tegra20-common.h +++ b/include/configs/tegra20-common.h @@ -28,6 +28,7 @@ /* * Errata configuration */ +#define CONFIG_ARM_ERRATA_716044 #define CONFIG_ARM_ERRATA_742230 #define CONFIG_ARM_ERRATA_751472 -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] ARM: implement erratum 716044 workaround
From: Stephen Warren Add common code to enable the workaround for ARM erratum 716044. This will be enabled for Tegra. Signed-off-by: Stephen Warren --- This depends on my previous ARM errata series. I found out we needed another one after I wrote the first series. README |1 + arch/arm/cpu/armv7/start.S |6 ++ 2 files changed, 7 insertions(+) diff --git a/README b/README index f2b1c88..97ef9f0 100644 --- a/README +++ b/README @@ -485,6 +485,7 @@ The following options need to be configured: Thumb2 this flag will result in Thumb2 code generated by GCC. + CONFIG_ARM_ERRATA_716044 CONFIG_ARM_ERRATA_742230 CONFIG_ARM_ERRATA_743622 CONFIG_ARM_ERRATA_751472 diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S index 30f02d3..6834ffe 100644 --- a/arch/arm/cpu/armv7/start.S +++ b/arch/arm/cpu/armv7/start.S @@ -310,6 +310,12 @@ ENTRY(cpu_init_cp15) #endif mcr p15, 0, r0, c1, c0, 0 +#ifdef CONFIG_ARM_ERRATA_716044 + mrc p15, 0, r0, c1, c0, 0 @ read system control register + orr r0, r0, #1 << 11@ set bit #11 + mcr p15, 0, r0, c1, c0, 0 @ write system control register +#endif + #ifdef CONFIG_ARM_ERRATA_742230 mrc p15, 0, r0, c15, c0, 1 @ read diagnostic register orr r0, r0, #1 << 4 @ set bit #4 -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Tegra: All Tamonten-derived boards use onboard NAND
Thierry,
On Mon, Mar 4, 2013 at 3:41 PM, Thierry Reding
wrote:
> On Mon, Mar 04, 2013 at 01:46:48PM -0700, Tom Warren wrote:
> [...]
>> I kinda lost track of this patchset. I'd like to move it into
>> u-boot-tegra/next if you think it's ready, but I'm not sure if it
>> conflicts with/works with Stephen's 4th patch of his v2 series ("ARM:
>> tegra: enable a common set of disk-related commands").
>
> I can rebase my patches on top of Stephen's work and resend them if it
> helps.
>
> Thierry
The only problem I see is that Stephen's patchset isn't exclusively
Tegra-based, so I'm not sure I want to bring it into the Tegra tree
and cause problems when I do a PR. The other half of the patchset is
assigned to Tom Rini.
Stephen - how would you like me to resolve this?
Thanks,
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] Tegra30: MMC: Add SD bus power-rail and SDMMC pad init routines
Stephen,
On Wed, Feb 27, 2013 at 11:08 AM, Stephen Warren wrote:
> On 02/27/2013 09:59 AM, Tom Warren wrote:
>> Stephen,
>>
>> On Tue, Feb 26, 2013 at 4:26 PM, Stephen Warren
>> wrote:
>>> On 02/26/2013 01:46 PM, Tom Warren wrote:
T30 requires specific SDMMC pad programming, and bus power-rail bringup.
>>>
diff --git a/board/nvidia/cardhu/cardhu.c b/board/nvidia/cardhu/cardhu.c
>>>
+/*
+ * Do I2C/PMU writes to bring up SD card bus power
+ *
+ */
+void board_sdmmc_voltage_init(void)
>>>
>>> We really shouldn't be adding to board files if we're remotely serious
>>> about device tree; the whole point of DT is to remove code from the
>>> board files, and describe the desired configuration as data in DT instead.
>>>
>>> This function should be replaced by regulator nodes/properties in the
>>> device tree, and the MMC (core?) driver calling into the board-specific
>>> regulator driver to request the desired voltages.
>>>
>>> But so long as we file a bug to replace this code with an explicit
>>> regulator driver in the future, I guess it's fine for now.
>>
>> I'll file a bug for doing all PMU/power rail work from DT. I think it
>> makes much more sense as a separate (non-MMC) patch.
>
> Yes, certainly a separate patch. Ideally it'd be implemented before
> other code that relies on it. That's why I think we need to take a
> higher-level look at DT support in U-Boot, rather than simply finding
> these issue accidentally while implementing the features we already know
> we need.
>
>>> BTW, I just noticed that commit f01b631 "Tegra30: Add/enable Cardhu
>>> build (T30 reference board)" adds a file called
>>> board/nvidia/cardhu/cardhu.c.mmc. That's a mistake, right?
>>
>> Yep, that's the Cardhu file I was hacking on for MMC support way back
>> when. I can remove it in V2 of these patches, or would you prefer a
>> single, separate patch to do that?
>
> Is the commit that adds that file already pulled into higher-level
> repos? If not, I would simply rebase it to remove that file. If it has,
> then a separate patch to delete it before this series would make sense.
>
diff --git a/board/nvidia/common/board.c b/board/nvidia/common/board.c
>>>
>>> Hmm. This seems like SoC code, not board code...
>>>
+void pad_init_mmc(struct tegra_mmc *reg)
+{
+#if defined(CONFIG_TEGRA30)
>>>
+ /* Set the pad drive strength for SDMMC1 or 3 only */
+ if (offset != TEGRA_SDMMC1_BASE && offset != TEGRA_SDMMC3_BASE) {
+ debug("%s: settings are only valid for SDMMC1/SDMMC3!\n",
+ __func__);
+ return;
+ }
>>>
>>> Perhaps pass in the MMC instance ID instead of the base address. That'd
>>> avoid having to know the base addresses in this code.
>>
>> I still need to know if I've got a SDIO or eMMC ID, though, and I
>> don't think the flags for that in the mmc/host structs (mmc->version,
>> etc.) get populated until the mmc driver has done some I/O with the
>> device (eMMC or SD-card), and I need to set up the pads before that.
>>
>>> In fact, just putting this code into the pinmux driver (which owns these
>>> registers) seems like a better idea; there's no need to only do this
>>> when the SD controller is enabled, is there?
>>
>> Half of these regs are in the SD controller register space
>> (sdmemcmpctl and autocalcfg), and get reset when the controller gets
>> reset (mmc_reset). So they need to be set each time a reset occurs. It
>> makes sense to keep the GP SDIOCFG writes here, too.
>>
>> As to where the pad_init_mmc function belongs, it is SoC-specific,
>> yes. T20 doesn't need it (no sdmemcmpctl or autocalcfg regs on T20
>> SDMMC), and T30 and T114 use slightly different bits/values for GP
>> SDIOCFG and sdmemcmpctl/autocalcfg. But the differences are small
>> enough that I thought this routine should be placed in a common area,
>> and not duplicated for each SoC, so I put it here.
>>
>> Do you have a suggestion of where it would be better placed?
>
> For the pinmux registers, I think they should be programmed by the
> pinmux driver at the same time as the rest of the pinmux is programmed.
Technically, they're not pinmux registers (PINMUX_AUX_ space), but GP
regs (APB_MISC_GP_ space). Since the pinmux _code_ (no pinmux driver
is used in Tegra U-Boot) for T30 is just a large table slam, I don't
think it makes sense to add GP pad reg writes there. These pads need
to be tuned when you've got a board w/an SD-card device hanging off of
them. So it makes sense to have these 2 register writes here in
pad_init_mmc(). I can take out the SDMMC1/3 test and just write both
SDIO1CFG and SDIO3CFG, since the values are the same.
>
> For the SD registers, I guess we need to program them from the SD driver
> as you say, but need to add some more properties to the DT in order to
> parameterize this.
Why don't we get this in so we can move forward, and when there's a
kernel version of these params in the DT files, I can
Re: [U-Boot] [PATCH 1/4] Tegra: All Tamonten-derived boards use onboard NAND
On Mon, Mar 04, 2013 at 01:46:48PM -0700, Tom Warren wrote:
[...]
> I kinda lost track of this patchset. I'd like to move it into
> u-boot-tegra/next if you think it's ready, but I'm not sure if it
> conflicts with/works with Stephen's 4th patch of his v2 series ("ARM:
> tegra: enable a common set of disk-related commands").
I can rebase my patches on top of Stephen's work and resend them if it
helps.
Thierry
pgp2haNftD6Di.pgp
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4 v3] gen: Add ACE acceleration to hash
On Fri, 1 Mar 2013 11:16:24 -0500
Akshay Saraswat wrote:
> +#include
>
> /*
> * These are the hash algorithms we support. Chips which support accelerated
> * crypto could perhaps add named version of these algorithms here.
> */
> static struct hash_algo hash_algo[] = {
> +#ifdef CONFIG_EXYNOS_ACE_SHA
> + {
> + "SHA1",
> + SHA1_SUM_LEN,
> + ace_sha_hash_digest,
> + ACE_SHA_TYPE_SHA1,
> + }, {
> + "SHA256",
> + SHA256_SUM_LEN,
> + ace_sha_hash_digest,
> + ACE_SHA_TYPE_SHA256,
> + },
Can we make this a generic "hardware accelerated SHA", not tied to
vendor-SoC-specific defines? I don't see more than one h/w
implementation being used on any one instance of u-boot...
> +#ifdef CONFIG_EXYNOS_ACE_SHA
> + int (*hash_func_ws)(const unsigned char *input, unsigned int ilen,
> + unsigned char *output, unsigned int chunk_sz);
> +#else
> void (*hash_func_ws)(const unsigned char *input, unsigned int ilen,
> unsigned char *output, unsigned int chunk_sz);
> +#endif
function signature mismatch, but I see Simon already got this.
Kim
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 5/5] am335x_evm: Enable DFU for NAND and MMC, provide example alt_info for both
From: Pantelis Antoniou
- Add CONFIG_DFU_NAND, CONFIG_DFU_MMC
- Set dfu_alt_info_nand and dfu_alt_info_mmc to show a working example
for both.
- Increase CONFIG_SYS_MAXARGS due to hush parsing bugs that would
otherwise disallow 'setenv dfu_alt_info ${dfu_alt_info_nand}'.
- Enable CONFIG_FAT_WRITE to allow updating on MMC
Signed-off-by: Pantelis Antoniou
Signed-off-by: Tom Rini
---
Changes in v4: None
Changes in v3:
- Fix checkpatch.pl warnings in include/configs/am335x_evm.h
Changes in v2:
- Enable DFU for NAND and MMC, set dfu_alt_info_(nand|mmc) as examples
for both in am335x_evm.h
- Increase CONFIG_SYS_MAXARGS due to hush parsing bugs that would
otherwise prevent 'setenv dfu_alt_info ${dfu_alt_info_nand}' on
am335x_evm
include/configs/am335x_evm.h | 38 --
1 file changed, 36 insertions(+), 2 deletions(-)
diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index 61b861d..14ffda7 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -62,6 +62,8 @@
"optargs=\0" \
"mtdids=" MTDIDS_DEFAULT "\0" \
"mtdparts=" MTDPARTS_DEFAULT "\0" \
+ "dfu_alt_info_mmc=" DFU_ALT_INFO_MMC "\0" \
+ "dfu_alt_info_nand=" DFU_ALT_INFO_NAND "\0" \
"mmcdev=0\0" \
"mmcroot=/dev/mmcblk0p2 ro\0" \
"mmcrootfstype=ext4 rootwait\0" \
@@ -118,8 +120,8 @@
#define CONFIG_CMD_ECHO
-/* max number of command args */
-#define CONFIG_SYS_MAXARGS 16
+/* We set the max number of command args high to avoid HUSH bugs. */
+#define CONFIG_SYS_MAXARGS 64
/* Console I/O Buffer Size */
#define CONFIG_SYS_CBSIZE 512
@@ -148,6 +150,7 @@
#define CONFIG_CMD_MMC
#define CONFIG_DOS_PARTITION
#define CONFIG_CMD_FAT
+#define CONFIG_FAT_WRITE
#define CONFIG_CMD_EXT2
#define CONFIG_SPI
@@ -158,6 +161,36 @@
#define CONFIG_CMD_SF
#define CONFIG_SF_DEFAULT_SPEED(2400)
+/* USB Composite download gadget - g_dnl */
+#define CONFIG_USB_GADGET
+#define CONFIG_USBDOWNLOAD_GADGET
+
+/* USB TI's IDs */
+#define CONFIG_USBD_HS
+#define CONFIG_G_DNL_VENDOR_NUM 0x0403
+#define CONFIG_G_DNL_PRODUCT_NUM 0xBD00
+#define CONFIG_G_DNL_MANUFACTURER "Texas Instruments"
+
+/* USB Device Firmware Update support */
+#define CONFIG_DFU_FUNCTION
+#define CONFIG_DFU_MMC
+#define CONFIG_DFU_NAND
+#define CONFIG_CMD_DFU
+#define DFU_ALT_INFO_MMC \
+ "boot part 0 1;" \
+ "rootfs part 0 2;" \
+ "MLO fat 0 1;" \
+ "u-boot.img fat 0 1;" \
+ "uEnv.txt fat 0 1"
+#define DFU_ALT_INFO_NAND \
+ "SPL part 0 1;" \
+ "SPL.backup1 part 0 2;" \
+ "SPL.backup2 part 0 3;" \
+ "SPL.backup3 part 0 4;" \
+ "u-boot part 0 5;" \
+ "kernel part 0 7;" \
+ "rootfs part 0 8"
+
/* Physical Memory Map */
#define CONFIG_NR_DRAM_BANKS 1 /* 1 bank of DRAM */
#define PHYS_DRAM_10x8000 /* DRAM Bank #1 */
@@ -302,6 +335,7 @@
#define CONFIG_MUSB_GADGET
#define CONFIG_MUSB_PIO_ONLY
#define CONFIG_USB_GADGET_DUALSPEED
+#define CONFIG_USB_GADGET_VBUS_DRAW2
#define CONFIG_MUSB_HOST
#define CONFIG_AM335X_USB0
#define CONFIG_AM335X_USB0_MODEMUSB_PERIPHERAL
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 4/5] am335x_evm: Add CONFIG_CMD_MTDPARTS and relevant defaults
Signed-off-by: Tom Rini --- Changes in v4: None Changes in v3: None Changes in v2: - Add CONFIG_CMD_MTDPARTS and relevant information to am335x_evm include/configs/am335x_evm.h |9 + 1 file changed, 9 insertions(+) diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h index 59647d1..61b861d 100644 --- a/include/configs/am335x_evm.h +++ b/include/configs/am335x_evm.h @@ -60,6 +60,8 @@ "fdtfile=\0" \ "console=ttyO0,115200n8\0" \ "optargs=\0" \ + "mtdids=" MTDIDS_DEFAULT "\0" \ + "mtdparts=" MTDPARTS_DEFAULT "\0" \ "mmcdev=0\0" \ "mmcroot=/dev/mmcblk0p2 ro\0" \ "mmcrootfstype=ext4 rootwait\0" \ @@ -341,6 +343,13 @@ /* NAND support */ #ifdef CONFIG_NAND #define CONFIG_CMD_NAND +#define CONFIG_CMD_MTDPARTS +#define MTDIDS_DEFAULT "nand0=omap2-nand.0" +#define MTDPARTS_DEFAULT "mtdparts=omap2-nand.0:128k(SPL)," \ + "128k(SPL.backup1)," \ + "128k(SPL.backup2)," \ + "128k(SPL.backup3),1920k(u-boot)," \ + "128k(u-boot-env),5m(kernel),-(rootfs)" #define CONFIG_NAND_OMAP_GPMC #define GPMC_NAND_ECC_LP_x16_LAYOUT1 #define CONFIG_SYS_NAND_BASE (0x0800)/* physical address */ -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 3/5] dfu: NAND specific routines for DFU operation
From: Pantelis Antoniou
Support for NAND storage devices to work with the DFU framework.
Signed-off-by: Pantelis Antoniou
Signed-off-by: Tom Rini
---
Changes in v4: None
Changes in v3:
- Rework logic in nand_block_op for nand_(read|write)_skip_bad returning
just a size for actual used length.
- Remove unused externs from drivers/dfu/dfu_nand.c
Changes in v2:
- nand_block_op calls nand_(read|write)_skip_bad directly.
- Bugfix in dfu_nand to make sure we set dfu->skip_bad to 0 on each
iteration.
drivers/dfu/Makefile |1 +
drivers/dfu/dfu.c |8 ++
drivers/dfu/dfu_nand.c | 195
include/dfu.h | 23 ++
4 files changed, 227 insertions(+)
create mode 100644 drivers/dfu/dfu_nand.c
diff --git a/drivers/dfu/Makefile b/drivers/dfu/Makefile
index 7b717bc..153095d 100644
--- a/drivers/dfu/Makefile
+++ b/drivers/dfu/Makefile
@@ -27,6 +27,7 @@ LIB = $(obj)libdfu.o
COBJS-$(CONFIG_DFU_FUNCTION) += dfu.o
COBJS-$(CONFIG_DFU_MMC) += dfu_mmc.o
+COBJS-$(CONFIG_DFU_NAND) += dfu_nand.o
SRCS:= $(COBJS-y:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS-y))
diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index fb9b417..44d29de 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -86,6 +86,7 @@ int dfu_write(struct dfu_entity *dfu, void *buf, int size,
int blk_seq_num)
/* initial state */
dfu->crc = 0;
dfu->offset = 0;
+ dfu->bad_skip = 0;
dfu->i_blk_seq_num = 0;
dfu->i_buf_start = dfu_buf;
dfu->i_buf_end = dfu_buf + sizeof(dfu_buf);
@@ -234,6 +235,8 @@ int dfu_read(struct dfu_entity *dfu, void *buf, int size,
int blk_seq_num)
dfu->i_buf = dfu->i_buf_start;
dfu->b_left = 0;
+ dfu->bad_skip = 0;
+
dfu->inited = 1;
}
@@ -263,6 +266,8 @@ int dfu_read(struct dfu_entity *dfu, void *buf, int size,
int blk_seq_num)
dfu->i_buf = dfu->i_buf_start;
dfu->b_left = 0;
+ dfu->bad_skip = 0;
+
dfu->inited = 0;
}
@@ -285,6 +290,9 @@ static int dfu_fill_entity(struct dfu_entity *dfu, char *s,
int alt,
if (strcmp(interface, "mmc") == 0) {
if (dfu_fill_entity_mmc(dfu, s))
return -1;
+ } else if (strcmp(interface, "nand") == 0) {
+ if (dfu_fill_entity_nand(dfu, s))
+ return -1;
} else {
printf("%s: Device %s not (yet) supported!\n",
__func__, interface);
diff --git a/drivers/dfu/dfu_nand.c b/drivers/dfu/dfu_nand.c
new file mode 100644
index 000..b7f60dd
--- /dev/null
+++ b/drivers/dfu/dfu_nand.c
@@ -0,0 +1,195 @@
+/*
+ * dfu_nand.c -- DFU for NAND routines.
+ *
+ * Copyright (C) 2012-2013 Texas Instruments, Inc.
+ *
+ * Based on dfu_mmc.c which is:
+ * Copyright (C) 2012 Samsung Electronics
+ * author: Lukasz Majewski
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+enum dfu_nand_op {
+ DFU_OP_READ = 1,
+ DFU_OP_WRITE,
+};
+
+static int nand_block_op(enum dfu_nand_op op, struct dfu_entity *dfu,
+ u64 offset, void *buf, long *len)
+{
+ loff_t start;
+ size_t count, actual;
+ int ret;
+ int dev;
+ nand_info_t *nand;
+
+ /* if buf == NULL return total size of the area */
+ if (buf == NULL) {
+ *len = dfu->data.nand.size;
+ return 0;
+ }
+
+ start = dfu->data.nand.start + offset + dfu->bad_skip;
+ count = *len;
+ if (start + count >
+ dfu->data.nand.start + dfu->data.nand.size) {
+ printf("%s: block_op out of bounds\n", __func__);
+ return -1;
+ }
+
+ dev = nand_curr_device;
+ if (dev < 0 || dev >= CONFIG_SYS_MAX_NAND_DEVICE ||
+ !nand_info[dev].name) {
+ printf("%s: invalid nand device\n", __func__);
+ return -1;
+ }
+
+ nand = &nand_info[dev];
+
+ if (op == DFU_OP_READ)
+ ret = nand_read_skip_bad(nand, start, &count, &actu
[U-Boot] [PATCH v4 2/5] cmd_nand.c: Fix CONFIG_CMD_NAND_YAFFS
The flag changed from WITH_INLINE_OOB to WITH_YAFFS_OOB by accident in
418396e.
Signed-off-by: Tom Rini
---
Changes in v4:
- Add patch to fix CONFIG_CMD_NAND_YAFFS
Changes in v3: None
Changes in v2: None
common/cmd_nand.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/cmd_nand.c b/common/cmd_nand.c
index 76f4d3f..d9010d2 100644
--- a/common/cmd_nand.c
+++ b/common/cmd_nand.c
@@ -673,7 +673,7 @@ static int do_nand(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
}
ret = nand_write_skip_bad(nand, off, &rwsize, NULL,
maxsize, (u_char *)addr,
- WITH_INLINE_OOB);
+ WITH_YAFFS_OOB);
#endif
} else if (!strcmp(s, ".oob")) {
/* out-of-band data */
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 1/5] nand: Extend nand_(read|write)_skip_bad with *actual and limit parameters
We make these two functions take a size_t pointer to how much space
was used on NAND to read or write the buffer (when reads/writes happen)
so that bad blocks can be accounted for. We also make them take an
loff_t limit on how much data can be read or written. This means that
we can now catch the case of when writing to a partition would exceed
the partition size due to bad blocks. To do this we also need to make
check_skip_len count not just complete blocks used but partial ones as
well. All callers of nand_(read|write)_skip_bad are adjusted to call
these with the most sensible limits available.
The changes were started by Pantelis and finished by Tom.
Signed-off-by: Pantelis Antoniou
Signed-off-by: Tom Rini
---
Changes in v4:
- Further reword nand_util.c comments, from Scott
- In nand_write_skip_bad make sure *actual is 0 for YAFFS2 errors too,
reminded by Scott.
- In cmd_nand.c don't drop the size is less than maxsize check in
arg_off_size as other nand functions need this still (Scott).
Changes in v3:
- Reworked skip_check_len changes to just add accounting for *used to
the logic.
- Allow for actual to be NULL in nand_(read|write)_skip_bad, only DFU
calls this with a non-NULL parameter. Make sure the comments for both
functions explain the parameters and their behavior.
- Other style changes requested by Scott.
- As nand_(write|read)_skip_bad passes back just a used length now.
Changes in v2:
- NAND skip_check_len changes reworked to allow
nand_(read|write)_skip_bad to return this information to the caller.
common/cmd_nand.c| 53 ++--
common/env_nand.c|3 +-
drivers/mtd/nand/nand_util.c | 68 +-
include/nand.h |4 +--
4 files changed, 95 insertions(+), 33 deletions(-)
diff --git a/common/cmd_nand.c b/common/cmd_nand.c
index 32348f3..76f4d3f 100644
--- a/common/cmd_nand.c
+++ b/common/cmd_nand.c
@@ -137,7 +137,8 @@ static inline int str2long(const char *p, ulong *num)
return *p != '\0' && *endptr == '\0';
}
-static int get_part(const char *partname, int *idx, loff_t *off, loff_t *size)
+static int get_part(const char *partname, int *idx, loff_t *off, loff_t *size,
+ loff_t *maxsize)
{
#ifdef CONFIG_CMD_MTDPARTS
struct mtd_device *dev;
@@ -160,6 +161,7 @@ static int get_part(const char *partname, int *idx, loff_t
*off, loff_t *size)
*off = part->offset;
*size = part->size;
+ *maxsize = part->size;
*idx = dev->id->num;
ret = set_dev(*idx);
@@ -173,10 +175,11 @@ static int get_part(const char *partname, int *idx,
loff_t *off, loff_t *size)
#endif
}
-static int arg_off(const char *arg, int *idx, loff_t *off, loff_t *maxsize)
+static int arg_off(const char *arg, int *idx, loff_t *off, loff_t *size,
+ loff_t *maxsize)
{
if (!str2off(arg, off))
- return get_part(arg, idx, off, maxsize);
+ return get_part(arg, idx, off, size, maxsize);
if (*off >= nand_info[*idx].size) {
puts("Offset exceeds device limit\n");
@@ -184,36 +187,35 @@ static int arg_off(const char *arg, int *idx, loff_t
*off, loff_t *maxsize)
}
*maxsize = nand_info[*idx].size - *off;
+ *size = *maxsize;
return 0;
}
static int arg_off_size(int argc, char *const argv[], int *idx,
- loff_t *off, loff_t *size)
+ loff_t *off, loff_t *size, loff_t *maxsize)
{
int ret;
- loff_t maxsize = 0;
if (argc == 0) {
*off = 0;
*size = nand_info[*idx].size;
+ *maxsize = *size;
goto print;
}
- ret = arg_off(argv[0], idx, off, &maxsize);
+ ret = arg_off(argv[0], idx, off, size, maxsize);
if (ret)
return ret;
- if (argc == 1) {
- *size = maxsize;
+ if (argc == 1)
goto print;
- }
if (!str2off(argv[1], size)) {
printf("'%s' is not a number\n", argv[1]);
return -1;
}
- if (*size > maxsize) {
+ if (*size > *maxsize) {
puts("Size exceeds partition or device limit\n");
return -1;
}
@@ -307,7 +309,8 @@ int do_nand_env_oob(cmd_tbl_t *cmdtp, int argc, char *const
argv[])
if (argc < 3)
goto usage;
- if (arg_off(argv[2], &idx, &addr, &maxsize)) {
+ /* We don't care about size, or maxsize. */
+ if (arg_off(argv[2], &idx, &addr, &maxsize, &maxsize)) {
puts("Offset or partition name expected\n");
return 1;
}
@@ -426,7 +429,7 @@ static int do_nand(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
{
int i, ret = 0;
ulong addr;
- loff_t off, size;
[U-Boot] [PATCH v4 0/5] Add NAND support to DFU, enable for am335x_evm
This series adds DFU support to NAND and was started by Pantelis. The
NAND changes have been compile-tested on all ARM and PowerPC targets and
run-time tested on ARM. DFU itself has been tested, for NAND, on
am335x_evm.
For practical reasons, this series depends on Pantelis' previous series
of generic DFU changes. Lukasz and I are discussing how to handle a few
changes there since one of them breaks file writing.
--
Tom
Changes in v4:
- Further reword nand_util.c comments, from Scott
- In nand_write_skip_bad make sure *actual is 0 for YAFFS2 errors too,
reminded by Scott.
- In cmd_nand.c don't drop the size is less than maxsize check in
arg_off_size as other nand functions need this still (Scott).
- Add patch to fix CONFIG_CMD_NAND_YAFFS
Changes in v3:
- Reworked skip_check_len changes to just add accounting for *used to
the logic.
- Allow for actual to be NULL in nand_(read|write)_skip_bad, only DFU
calls this with a non-NULL parameter. Make sure the comments for both
functions explain the parameters and their behavior.
- Other style changes requested by Scott.
- As nand_(write|read)_skip_bad passes back just a used length now.
- Rework logic in nand_block_op for nand_(read|write)_skip_bad returning
just a size for actual used length.
- Remove unused externs from drivers/dfu/dfu_nand.c
- Fix checkpatch.pl warnings in include/configs/am335x_evm.h
Changes in v2:
- NAND skip_check_len changes reworked to allow
nand_(read|write)_skip_bad to return this information to the caller.
- nand_block_op calls nand_(read|write)_skip_bad directly.
- Bugfix in dfu_nand to make sure we set dfu->skip_bad to 0 on each
iteration.
- Add CONFIG_CMD_MTDPARTS and relevant information to am335x_evm
- Enable DFU for NAND and MMC, set dfu_alt_info_(nand|mmc) as examples
for both in am335x_evm.h
- Increase CONFIG_SYS_MAXARGS due to hush parsing bugs that would
otherwise prevent 'setenv dfu_alt_info ${dfu_alt_info_nand}' on
am335x_evm
Pantelis Antoniou (2):
dfu: NAND specific routines for DFU operation
am335x_evm: Enable DFU for NAND and MMC, provide example alt_info for
both
Tom Rini (3):
nand: Extend nand_(read|write)_skip_bad with *actual and limit
parameters
cmd_nand.c: Fix CONFIG_CMD_NAND_YAFFS
am335x_evm: Add CONFIG_CMD_MTDPARTS and relevant defaults
common/cmd_nand.c| 55 +++-
common/env_nand.c|3 +-
drivers/dfu/Makefile |1 +
drivers/dfu/dfu.c|8 ++
drivers/dfu/dfu_nand.c | 195 ++
drivers/mtd/nand/nand_util.c | 68 +--
include/configs/am335x_evm.h | 47 +-
include/dfu.h| 23 +
include/nand.h |4 +-
9 files changed, 368 insertions(+), 36 deletions(-)
create mode 100644 drivers/dfu/dfu_nand.c
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] should tools/env/README also recommend setting HOSTSTRIP?
On Mon, 4 Mar 2013, Tom Rini wrote: > On Thu, Feb 28, 2013 at 08:46:15AM -0500, Robert P. J. Day wrote: > > > it would seem that in addition to manually setting HOSTCC, a user > > should also set HOSTSTRIP when building fw_printenv, no? there's no > > mention of that in the README but the strip operation will certainly > > fail without it. > > True, the README wasn't updated back when we added HOSTSTRIP into the > mix. soon as i get a sec, i can patch that unless someone wants to beat me to it. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4 v3] Exynos: Add hardware accelerated SHA 256
On Fri, 1 Mar 2013 11:16:22 -0500
Akshay Saraswat wrote:
> SHA-256 and SHA-1 accelerated using ACE hardware.
curious about the rationale: how much faster is this than software?
> ---
> Changes since v2:
> - Added falling back to software sha256 in case length exceeds buffer
> limit.
> - Reduced one tab at lines 533, 559 and 571 in this patch.
> - Removed space after a cast at line 506 in this patch.
> - Removed blank line at line 561 in this patch.
> - Removed space before semicolon at line 576 in this patch.
you should retain the list of changes since v1 here. Read:
http://www.denx.de/wiki/view/U-Boot/Patches#Sending_updated_patch_versions
> +/* Hash status */
> +#define ACE_HASH_BUFRDY_MASK (1 << 0)
> +#define ACE_HASH_BUFRDY_OFF (0 << 0)
> +#define ACE_HASH_BUFRDY_ON (1 << 0)
> +#define ACE_HASH_SEEDSETTING_MASK(1 << 1)
> +#define ACE_HASH_SEEDSETTING_OFF (0 << 1)
> +#define ACE_HASH_SEEDSETTING_ON (1 << 1)
> +#define ACE_HASH_PRNGBUSY_MASK (1 << 2)
> +#define ACE_HASH_PRNGBUSY_OFF(0 << 2)
> +#define ACE_HASH_PRNGBUSY_ON (1 << 2)
> +#define ACE_HASH_PARTIALDONE_MASK(1 << 4)
> +#define ACE_HASH_PARTIALDONE_OFF (0 << 4)
> +#define ACE_HASH_PARTIALDONE_ON (1 << 4)
based on the nomenclature of the above definitions, this hardware
obviously has support for breaking up hash requests into multiple
buffer submissions, so do that, and not this:
> + } else if (buf_len > BUF_LIMIT) {
> + /*
> + * ACE H/W cannot compute hash value for buffer > 8 MB.
> + * Falling back to software.
> + */
> + if (hash_type == ACE_SHA_TYPE_SHA1)
> + sha1_csum_wd(pbuf, buf_len, pout, CHUNKSZ_SHA1);
> + else
> + sha256_csum_wd(pbuf, buf_len, pout, CHUNKSZ_SHA256);
> + return 0;
> + }
Kim
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Exynos: Add hardware accelerated SHA 256
On Fri, 1 Mar 2013 16:11:36 + Akshay Saraswat wrote: > Samsung Enterprise Portal mySingle > > > > Hi Kim, > > > > >On Thu, 28 Feb 2013 11:08:21 + > > >Akshay Saraswat wrote: > > > > > >> >On Wed, 27 Feb 2013 10:24:39 -0500 > > >> > > >> >Akshay Saraswat wrote: > > > > > >can you fix your mailer to not double space lines? > > > > Sorry for the disarranged text. I hope this time it is good. > > As you can see, no. It looks like you didn't change anything. I have to manually single-space things below. > >> So, I have incremented this value > >> to 500 which shall be good enough for the lowest of all frequencies. But I > >> guess what we > >> need here is some formula, to calculate timeout on the basis of frequency, > >> which is nowhere > >> defined. > > >That's odd - I see a bunch of frequencies advertised in > >arch/arm/cpu/armv7/exynos/clock.c. > >Or how about using a cycle counter instead? > >btw, where can I find documentation for the ACE? > > I tried with different frequencies and data sizes and found that it takes 2 > to 3 msecs in all the cases. > Since, it is hardware accelerated encoding it is supposed to behave in this > same manner. > But the current version of u-boot behaves mysteriously and slow downs when > pressed enter for long. > In the above case mentioned I even saw time took to be more than 100 msecs > for all the cases. > I think it would not be a better idea to timeout encoding acceleration. > But still if it is needed, cycle counter suggestion would be a great solution. it depends on whether the h/w can fault during its operation. > You can read Exynos5250 manual's "Security subsystem" section, which I > referred for this. you mean this?: http://www.samsung.com/global/business/semiconductor/file/product/Exynos_5_Dual_User_Manaul_Public_REV100-0.pdf There is no "Security subsystem" section. Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch v7] Consolidate bool type
On 03/04/2013 01:38 PM, Tom Rini wrote: > On Wed, Jan 30, 2013 at 03:11:40PM -0800, York Sun wrote: > >> 'bool' is defined in random places. This patch consolidates them into a >> single header file include/linux/types.h, using stdbool.h introduced in C99. >> >> All other #define, typedef and enum are removed. They are all consistent with >> true = 1, false = 0. >> >> Replace FALSE, False with false. Replace TRUE, True with true. >> Skip *.py, *.php, lib/* files. >> >> Signed-off-by: York Sun >> Acked-by: Allen Martin > > There was a lot of talk from v1 to v6, and nothing to v7. Is everyone > happy now? Changes from v6 to v7 is to remove RFC from the subject and add Acked-byL Allen. I didn't hear any nack for v7. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [STATUS] v2013.04-rc1 released
Hey all, I've tagged and pushed v2013.04-rc1 now. I expect a number of changes still to come, but I want to remind folks when the next release is, and that is "sooner than you thought". I've also given patchwork a clean-up, so if you haven't checked your TODO list of late, it might have grown. And if it's wrong, please blame me :). If you're a submitter and not a custodian, please feel free to gently poke myself and the relevant custodian for an update. Thanks all! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch v7] Consolidate bool type
On Wed, Jan 30, 2013 at 03:11:40PM -0800, York Sun wrote: > 'bool' is defined in random places. This patch consolidates them into a > single header file include/linux/types.h, using stdbool.h introduced in C99. > > All other #define, typedef and enum are removed. They are all consistent with > true = 1, false = 0. > > Replace FALSE, False with false. Replace TRUE, True with true. > Skip *.py, *.php, lib/* files. > > Signed-off-by: York Sun > Acked-by: Allen Martin There was a lot of talk from v1 to v6, and nothing to v7. Is everyone happy now? -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v1] kerneldoc: Add Sonic Zhang to alias bfin in git-mailrc.
On Thu, Feb 28, 2013 at 08:21:13PM -, Sonic Zhang wrote: > Signed-off-by: Sonic Zhang Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] env: Avoid clobbering an edited variable on ctrl-c
On Fri, Feb 08, 2013 at 10:12:34AM -, Joe Hershberger wrote: > If readline says there was an error, don't write to the variable! > > Signed-off-by: Joe Hershberger Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] bootm: fix conditional compilation for bootm ramdisk subcommand
On Tue, Feb 26, 2013 at 04:54:19AM -, Daniel Schwierzeck wrote: > All code related to the bootm ramdisk subcommand is conditionally > enabled by CONFIG_SYS_BOOT_RAMDISK_HIGH except for the help message. > Replace the CONFIG_ARCH defines by CONFIG_SYS_BOOT_RAMDISK_HIGH > to fix this. > > Signed-off-by: Daniel Schwierzeck Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ubifs: Allow ubifsmount volume reference by number
On Thu, Nov 01, 2012 at 04:54:18PM -, Joe Hershberger wrote: > UBI can mount volumes by name or number The current code forces you > to name the volume by prepending every name with "ubi:". > > >From fs/ubifs/super.c > * There are several ways to specify UBI volumes when mounting UBIFS: > * o ubiX_Y- UBI device number X, volume Y; > * o ubiY - UBI device number 0, volume Y; > * o ubiX:NAME - mount UBI device X, volume with name NAME; > * o ubi:NAME - mount UBI device 0, volume with name NAME. > > Now any name passed in any of the above forms are allowed. > > Also update the configs that referenced ubifsmount. > > Signed-off-by: Joe Hershberger Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ubifs: Allow ubifsmount volume reference by number
On Thu, Nov 01, 2012 at 04:54:18PM -, Joe Hershberger wrote: > UBI can mount volumes by name or number The current code forces you > to name the volume by prepending every name with "ubi:". > > >From fs/ubifs/super.c > * There are several ways to specify UBI volumes when mounting UBIFS: > * o ubiX_Y- UBI device number X, volume Y; > * o ubiY - UBI device number 0, volume Y; > * o ubiX:NAME - mount UBI device X, volume with name NAME; > * o ubi:NAME - mount UBI device 0, volume with name NAME. > > Now any name passed in any of the above forms are allowed. > > Also update the configs that referenced ubifsmount. > > Signed-off-by: Joe Hershberger Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-x86.git
On Thu, Feb 28, 2013 at 07:55:39PM -0800, Simon Glass wrote: [snip] > The following changes since commit a1eac57a2001ecf86a46f520cd85ef8e9c8b3687: > > common/env_nand.c: calculate crc only when readenv was OK > (2013-02-22 19:59:53 -0600) > > are available in the git repository at: > > git://git.denx.de/u-boot-x86.git mem > > for you to fetch changes up to 218da0f35f4b5e5bf13d3dba6d975d4d5d65516f: > > hash: Use lower case for hash algorithm names (2013-02-28 19:49:13 -0800) > > > Allen Martin (1): > sandbox: fix compiler warning > > Simon Glass (21): > Tidy up error checking and fix bug in hash command > Update print_buffer() to use const > sandbox: Add un/map_sysmen() to deal with sandbox's ram_buf > sandbox: Change memory commands to use map_physmem > Split out the memory tests into separate functions > Use common mtest iteration counting > Fix mtest indenting > Bring mtest putc() into common code > Reduce casting in mtest > Update set_working_fdt_addr() to use setenv_addr() > common: Use new numeric setenv functions > fs: Use new numeric setenv functions > net: Use new numeric setenv functions > image: Use crc header file instead of C prototypes > hash: Add a flag to support saving hashes in the environment > Roll crc32 into hash infrastructure > sandbox: config: Enable hash functions and mtest > Move CONFIG_SYS_MEMTEST_SCRATCH #ifdef to top of file > sandbox: Update mtest to fix crashes > sandbox: Allow hash functions to work correctly > hash: Use lower case for hash algorithm names > > Taylor Hutt (1): > sandbox: Improve sandbox serial port keyboard interface > > README| 9 + > arch/sandbox/config.mk| 1 + > arch/sandbox/cpu/os.c | 8 + > arch/sandbox/cpu/start.c | 3 + > arch/sandbox/include/asm/io.h | 10 + > common/cmd_bootm.c| 11 +- > common/cmd_cbfs.c | 4 +- > common/cmd_cramfs.c | 4 +- > common/cmd_fdos.c | 4 +- > common/cmd_fdt.c | 11 +- > common/cmd_hash.c | 14 +- > common/cmd_jffs2.c| 4 +- > common/cmd_load.c | 12 +- > common/cmd_mem.c | 809 > > common/cmd_mtdparts.c | 4 +- > common/cmd_nand.c | 12 +- > common/cmd_nvedit.c | 11 +- > common/cmd_reiser.c | 4 +- > common/cmd_setexpr.c | 39 +++- > common/cmd_sha1sum.c | 6 +- > common/cmd_unzip.c| 4 +- > common/cmd_ximg.c | 7 +- > common/cmd_zfs.c | 3 +- > common/cmd_zip.c | 4 +- > common/hash.c | 194 +++- > common/image.c| 4 +- > drivers/net/fm/fm.c | 4 +- > drivers/serial/sandbox.c | 44 +++- > fs/fs.c | 4 +- > fs/ubifs/ubifs.c | 4 +- > include/common.h | 29 ++- > include/configs/sandbox.h | 9 +- > include/hash.h| 13 +- > include/os.h | 10 + > include/u-boot/crc.h | 11 + > lib/crc32.c | 9 + > lib/display_options.c | 3 +- > net/net.c | 8 +- > 38 files changed, 761 insertions(+), 583 deletions(-) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/11] sandbox: Add filesystem support
On Sun, Feb 24, 2013 at 09:35:42AM -0800, Simon Glass wrote: > Hi, > > On Wed, Dec 26, 2012 at 11:53 AM, Simon Glass wrote: > > This series adds support for filesystems to sandbox. While we don't yet have > > access to host machine block devices, we can access files on the host > > through > > a new 'host' filesystem type and the new sandbox command 'sb'. > > > > For example: > > > > sb load host 0 1000 foo.bar > > > > will load foo.bar from the host into memory at address 1000. The '0' > > parameter is the device number, currently unused. > > > > While doing this work, I noticed that fs.c had code that probably belongs > > more in the filesystems themselves. So this series moves fat/ext4 code into > > those files. This removes most of the #ifdefs from this file, as well as > > the #defines of functions to 'unsupported'. Now there is a list of > > filesystems that we support, and if we don't find the one we need, we > > automatically fall back to the 'unsupported' one. > > > > Finally, the ext4 write support is moved into a separate file since ext4fs.c > > was over 3500 lines and the write support seems entirely separate from the > > main function in that file. > > Are there any comments on this series please? It adds new methods to > the filesystem interface, and a new 'host' filesystem type for > sandbox. Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/12] cmd_sf: Add support for read and write instructions
On Sat, Mar 02, 2013 at 01:59:38PM +0530, Jagan Teki wrote: [snip] > Since these changes I have sent long back, I am just re-modified the > framework to > add new features at the same time with backward comparability for > current commands. > > Current command setup: > sf write > sf read > sf update > > Changed command set: [no changes in the argument count] > sf write --- current command > sf write.pp -- same as sf write > sf write.qp -- quad program > > sf read -- current read > sf read.af --- array flast read, same as sf read > sf read.as -- array slow read > sf read.do --- dual out > sf read.qo -- quad out > sf read.dio -- dual io > sf read.qio -- quad io > > sf update -- current update > sf update.pp.af -- write page program, read array fast, same as sf update > sf update.pp.as - write page program, read array slow > sf update.pp.do - write page program, read dual out > sf update.pp.qo - write page program, read quad out > sf update.pp.dio - write page program, read dual io > sf update.pp.qio - write page program, read quad io > sf update.qp.af - write quad program, read array fast > sf update.qp.as - write quad program, read array slow > sf update.qp.do - write quad program, read dual out > sf update.qp.qo - write quad program, read quad out > sf update.qp.dio - write quad program, read dual io > sf update.qp.qio - write quad program, read quad io > > Though it seems to be lengthy, but may useful with lot of combinations > from user. > My intention is to use the existing argument count with changes in the > command set. Are there cases where for the current device we're operating on that can handle more than one of these, aside from fast or slow? And do we really need to offer both fast and slow? -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/12] cmd_sf: Add support for read and write instructions
Hi All, Any suggestions please. Thanks, Jagan. On Sat, Mar 2, 2013 at 1:59 PM, Jagan Teki wrote: > Hi All, > > On Fri, Jan 11, 2013 at 7:46 AM, Simon Glass wrote: >> Hi Jagannadha, >> >> On Mon, Dec 31, 2012 at 3:13 AM, Jagannadha Sutradharudu Teki >> wrote: >>> All these patches are added a support for read and write instruction >>> for programming/reading SPI flash. >>> >> >> I think this is all great and very useful - since no one else has >> commented I will have a try. >> >>> Read and Write instruction are implemented as a command line >>> arguments for 'sf write' , 'sf read' and 'sf update' commands. >>> >>> Currently I have added below instructions those are commonly available >>> on all flash types. >> >> Maybe you could use flags like -d for dual, -q for quad, -p for page, >> -s for slow, -o for output only. So maybe: >> >> -p > pp - Page Program (existing one) >> -qp > qpp - Quad-input Page Program >> > afr - Array Fast Read (existing one) >> -s > asr - Array Slow Read >> -do > dofr - Dual Output Fast Read >> -qo > qofr - Quad Output Fast Read >> -d > diofr - Dual IO Fast Read >> -q > qiofr - Quad IO Fast Read >> >> I worry that your scheme would be hard to remember. >> >> >>> >>> I have tested mostly of the instruction on real h/w. >>> >>> This entire implementation will change the current sf framework little bit >>> but >>> I thought these changes are worth to add. >> >> Yes very much so. >> >>> >>> Request for all your comment, so-that I can move forward. >>> Please let me know for any issue regarding this new implementation. >> >> Regards, >> Simon >> >>> >>> Thanks, >>> Jagan. >>> >>> Jagannadha Sutradharudu Teki (12): >>> cmd_sf: Add wr_inst argument to 'sf write' command >>> cmd_sf: Add rd_inst argument to 'sf read' command >>> cmd_sf: Add wr_inst argument to 'sf update' command >>> cmd_sf: Add rd_inst argument to 'sf update' command >>> cmd_sf: Define a functions for parsing read and write instructions >>> cmd_sf: Add QPP(Quad-input Page Program) write instruction support >>> cmd_sf: Add ASR(Array Slow Read) read instruction support >>> cmd_sf: Add DOFR(Dual Output Fast Read) read instruction support >>> cmd_sf: Add QOFR(Quad Output Fast Read) read instruction support >>> cmd_sf: Add DIOFR(Dual IO Fast Read) read instruction support >>> cmd_sf: Add QIOFR(Quad IO Fast Read) read instruction support >>> sf: Pass rd_qeb_req variable as 0 for status and config reg reads >>> >>> common/cmd_sf.c | 198 >>> +- >>> drivers/mtd/spi/spi_flash.c | 40 +-- >>> drivers/mtd/spi/spi_flash_internal.h | 10 +- >>> include/spi_flash.h | 22 ++-- >>> include/spi_flash_inst.h | 39 +++ >>> 5 files changed, 257 insertions(+), 52 deletions(-) >>> create mode 100644 include/spi_flash_inst.h >>> > > Since these changes I have sent long back, I am just re-modified the > framework to > add new features at the same time with backward comparability for > current commands. > > Current command setup: > sf write > sf read > sf update > > Changed command set: [no changes in the argument count] > sf write --- current command > sf write.pp -- same as sf write > sf write.qp -- quad program > > sf read -- current read > sf read.af --- array flast read, same as sf read > sf read.as -- array slow read > sf read.do --- dual out > sf read.qo -- quad out > sf read.dio -- dual io > sf read.qio -- quad io > > sf update -- current update > sf update.pp.af -- write page program, read array fast, same as sf update > sf update.pp.as - write page program, read array slow > sf update.pp.do - write page program, read dual out > sf update.pp.qo - write page program, read quad out > sf update.pp.dio - write page program, read dual io > sf update.pp.qio - write page program, read quad io > sf update.qp.af - write quad program, read array fast > sf update.qp.as - write quad program, read array slow > sf update.qp.do - write quad program, read dual out > sf update.qp.qo - write quad program, read quad out > sf update.qp.dio - write quad program, read dual io > sf update.qp.qio - write quad program, read quad io > > Though it seems to be lengthy, but may useful with lot of combinations > from user. > My intention is to use the existing argument count with changes in the > command set. > > Request for your inputs. > > Thanks, > Jagan. > >>> ___ >>> U-Boot mailing list >>> U-Boot@lists.denx.de >>> http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Tegra: All Tamonten-derived boards use onboard NAND
Thierry,
On Thu, Feb 14, 2013 at 12:54 AM, Thierry Reding
wrote:
> Move the nand-controller node to the tegra20-tamonten.dtsi so that it
> can be shared between all derived boards.
>
> Signed-off-by: Thierry Reding
> ---
> This depends on Tom's "Tegra: MMC: Add DT support for MMC to T20 boards"
> patches.
>
> board/avionic-design/dts/tegra20-tamonten.dtsi | 11 +++
> board/avionic-design/dts/tegra20-tec.dts | 11 ---
> 2 files changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/board/avionic-design/dts/tegra20-tamonten.dtsi
> b/board/avionic-design/dts/tegra20-tamonten.dtsi
> index 4766aba..0a95ac1 100644
> --- a/board/avionic-design/dts/tegra20-tamonten.dtsi
> +++ b/board/avionic-design/dts/tegra20-tamonten.dtsi
> @@ -279,6 +279,17 @@
> status = "okay";
> };
>
> + nand-controller@70008000 {
> + nvidia,wp-gpios = <&gpio 23 0>; /* PC7 */
> + nvidia,width = <8>;
> + nvidia,timing = <26 100 20 80 20 10 12 10 70>;
> +
> + nand@0 {
> + reg = <0>;
> + compatible = "hynix,hy27uf4g2b", "nand-flash";
> + };
> + };
> +
> i2c@7000c000 {
> clock-frequency = <40>;
> status = "okay";
> diff --git a/board/avionic-design/dts/tegra20-tec.dts
> b/board/avionic-design/dts/tegra20-tec.dts
> index 376d279..694682c 100644
> --- a/board/avionic-design/dts/tegra20-tec.dts
> +++ b/board/avionic-design/dts/tegra20-tec.dts
> @@ -32,17 +32,6 @@
> clock-frequency = <21600>;
> };
>
> - nand-controller@70008000 {
> - nvidia,wp-gpios = <&gpio 23 0>; /* PC7 */
> - nvidia,width = <8>;
> - nvidia,timing = <26 100 20 80 20 10 12 10 70>;
> -
> - nand@0 {
> - reg = <0>;
> - compatible = "hynix,hy27uf4g2b", "nand-flash";
> - };
> - };
> -
> i2c@7000c000 {
> status = "disabled";
> };
> --
> 1.8.1.2
>
I kinda lost track of this patchset. I'd like to move it into
u-boot-tegra/next if you think it's ready, but I'm not sure if it
conflicts with/works with Stephen's 4th patch of his v2 series ("ARM:
tegra: enable a common set of disk-related commands").
Let me know how you want me to proceed - I'd like to get a PR off to
Albert for ARM/master this week if possible.
Thanks,
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] am335x-evm: enable ext4
On Mon, Feb 18, 2013 at 07:26:42AM +0100, Peter Korsgaard wrote: > > "Koen" == Koen Kooi writes: > > Koen> #define CONFIG_CMD_EXT2 > Koen> +#define CONFIG_CMD_EXT4 > >> > >> Shouldn't the bootcmd then also be changed to use ext4load instead? Why > >> keep CMD_EXT2 enabled? > > Koen> that will be a followup patch > > Ok. It imho makes sense to do both changes at once as they are strongly > related and in the same file. And we ought to add CONFIG_CMD_FS_GENERIC and just 'load' so that this can more easily work with folks still using FAT for boot. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/4] nand: Extend nand_(read|write)_skip_bad with *actual and limit parameters
On 03/03/2013 08:04:01 AM, Tom Rini wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/01/2013 09:59 PM, Scott Wood wrote: > On 03/01/2013 09:57:40 AM, Tom Rini wrote: >> On Thu, Feb 28, 2013 at 07:37:51PM -0600, Scott Wood wrote: + * @param limmaximum size that length may be in order to not + *exceed the buffer >>> >>> s/that length may be/that actual may be/ >> >> No? We check that the requested length to something will fit >> even if the caller doesn't care to know what actual is. > > What I mean is that we're not saying "if (length > lim) error". > We compute the actual, and if the actual exceeds "lim", then > there's an error. OK, I see your point. My hang-up is that actual may be NULL. That's just the pointer to store the actual length in, which is just an implementation detail of how we return additional values. We still compute the actual length. I'd hope it would be obvious that we're not talking about the pointer here. So, "maximum size that length may be once bad blocks are accounted for in order to not exceed the buffer" ? I think it would be better to not have to describe the concept twice. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] ARM: implement some Cortex-A9 errata workarounds
Albert, > -Original Message- > From: Albert ARIBAUD [mailto:albert.u.b...@aribaud.net] > Sent: Monday, March 04, 2013 11:00 AM > To: Tom Warren > Cc: Stephen Warren; u-boot@lists.denx.de; Stephen Warren; Tom Warren > Subject: Re: [U-Boot] [PATCH 1/3] ARM: implement some Cortex-A9 errata > workarounds > > Hi Tom, > > On Mon, 4 Mar 2013 08:30:11 -0800, Tom Warren > wrote: > > > Stephen & Albert, > > > > > -Original Message- > > > From: Stephen Warren [mailto:swar...@wwwdotorg.org] > > > Sent: Friday, March 01, 2013 2:54 PM > > > To: Tom Warren > > > Cc: u-boot@lists.denx.de; Stephen Warren > > > Subject: Re: [U-Boot] [PATCH 1/3] ARM: implement some Cortex-A9 > > > errata workarounds > > > > > > On 02/28/2013 10:08 AM, Stephen Warren wrote: > > > > On 02/26/2013 03:28 PM, Stephen Warren wrote: > > > >> From: Stephen Warren > > > >> > > > >> Various errata exist in the Cortex-A9 CPU, and may be worked > > > >> around by setting some bits in a CP15 diagnostic register. Add > > > >> code to implement the workarounds, enabled by new CONFIG_ options. > > > >> > > > >> This code was taken from the Linux kernel, v3.8, > > > >> arch/arm/mm/proc-v7.S, and modified to remove the logic to > > > >> conditionally apply the WAR (since we know exactly which CPU > > > >> we're running on given the U-Boot configuration), and use r0 > > > >> instead of r10 for consistency with the rest of U-Boot's > cpu_init_cp15(). > > > > > > > > Hmmm. Lets hold off on this series; there are some conditions > > > > under which the kernel has to be able to apply these WARs anyway > > > > (e.g. SMP CPU power saving), which may impact which of the WARs > > > > the bootloader should apply even when booting the initial CPU 0. > > > > I'll repost once that's been resolved. > > > > > > Tom, > > > > > > It looks like the bootloader should always apply these WARs for CPU 0. > > > We just have to make sure that the kernel applies them for CPUs 1..n > > > if/when running in secure mode. > > > > > > In other words, I think these patches are good to go in as-is. Since > > > there are no changes to the patches, I won't repost them, unless you > need me to. > > > > I can take these in via the Tegra tree, but the bulk of the changes are > for ARM, not Tegra. > > Albert - do you want to take this directly into the ARM repo, or would you > prefer me to take it? > > I will take them in tonight. Thanks. I'll assign the Tegra patch to you in Patchwork & take 'em out of u-boot-tegra/next. Tom > > > Tom > > Amicalement, > -- > Albert. -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] dtb vs. kernel command line arguments
Hello - I want to pass a number of arguments from u-boot to the booted kernel. The arguments are needed by user space applications, not the kernel. I can think of two ways: 1. append args by setting "bootargs". 2. add nodes to the dtb before booting. Is there a preferred way to pass information like this? Like I said the arguments are not needed by the kernel device drivers, but by user space applications. I like the structure of nodes in the dtb. Cheers, Curt ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [OT] Re: Beginners Questions on modding a NAS
Hi Michael, On Mon, 4 Mar 2013 12:23:05 -0500, Michael Cashwell wrote: > On Mar 4, 2013, at 10:40 AM, JPT wrote: > > > It's a Netgear ReadyNAS Duo V2, and the original sofware sucks. ;) > > standalone=fsload 0x200 $(image_name);setenv bootargs $(console) > > root=/dev/mtdblock0 rw ip=$(ipaddr):$(serverip)$(bootargs_end) > > $(mvPhoneConfig); bootm 0x200; > > bootcmd=nand read.e 0x120 0x20 0x60;nand read.e 0x200 > > 0x80 0x100;bootm 0x120 0x200 > > Strange for a NAS to have a u-boot environment variable called > "mvPhoneConfig". But anyway... OT: that's (older) Marvell/LaCie U-Boots for you. They have lots of these weird ad hoc env vars, which exist across a whole range of products even when they make sense only for a few. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Beginners Questions on modding a NAS
Hi Jagan, On Mon, 4 Mar 2013 23:02:58 +0530, Jagan Teki wrote: > Hi JPT, > > On Mon, Mar 4, 2013 at 9:10 PM, JPT wrote: > > Hi, > > > > I've got a NAS which uses uboot: > > U-Boot 1.1.4 (Feb 6 2012 - 14:40:46) Marvell version: 3.4.27 > > > > It's a Netgear ReadyNAS Duo V2, and the original sofware sucks. ;) > > > > I would like to start with the original kernel (because it contains some > > patches) and a custom debian made with multistrap. > > > > Where do I start? > > > > I'll add some information about the config. > > > > I believe these are the most important boot options. > > > > standalone=fsload 0x200 $(image_name);setenv bootargs $(console) > > root=/dev/mtdblock0 rw ip=$(ipaddr):$(serverip)$(bootargs_end) > > $(mvPhoneConfig); bootm 0x200; > > > > bootcmd=nand read.e 0x120 0x20 0x60;nand read.e 0x200 > > 0x80 0x100;bootm 0x120 0x200 > > > > bootargs=console=ttyS0,115200 reason=normal > > mtdparts=nand_mtd:0x18@0(u-boot),0x2@0x18(u-boot-env),0x60@0x20(uImage),0x100@0x80(minirootfs),0x680@0x180(jffs2); > > > > > > there are 5 mtds: > > 1,5M mtd0 - ? > > 128K mtd1 - ? > > 6,0M mtd2 - kernel > > 2,2M mtd3 - initrd (gzipped) > > 89M mtd4 - jffs2 image, I think it contains a rescue image of the > > filesystem which is applied to the harddisks. > > > > I dumped the kernel from mtd2, it is: > > u-boot legacy uImage, Linux-2.6.31.8.duov2, Linux/ARM, OS Kernel Image (Not > > compressed), 3442208 bytes, Tue Aug 28 05:21:43 2012, Load Address: > > 0x8000, Entry Point: 0x8000, Header CRC: 0xDA1ECA31, Data CRC: > > 0x269C27DE > > > > > > I tried to load the kernel through tftp, but it crashed: > > > > Marvell>> dhcp > > > > BOOTP broadcast 1 > > *** Unhandled DHCP Option in OFFER/ACK: 28 > > *** Unhandled DHCP Option in OFFER/ACK: 28 > > DHCP client bound to address 192.168.20.35 > > Marvell>> set serverip 192.168.20.24 > > > > Marvell>> tftpboot 0x0200 /boot/kernel.img > > > > Using egiga0 device > > TFTP from server 192.168.20.24; our IP address is 192.168.20.35 > > Filename '/boot/kernel.img'. > > Load address: 0x200 > > Loading: # > > ... > > done > > Bytes transferred = 3442272 (348660 hex) > > Marvell>> go 0x0200 > > Is this load address for kernel is correct? likely to have 8000 multiples.. > check it once. Just about any address can be used to load and bootm (as Michael notes) a kernel image. And 200 is a multiple of 8000, as we are talking hex here. :) > > ## Starting application at 0x0200 ... > > software interrupt > > pc : [<021c>] lr : [<00633cac>] > > sp : 005fef68 ip : fp : 005ff7de > > r10: 005ff3de r9 : e804 r8 : 005fffcc > > r7 : 005ff388 r6 : 0001 r5 : 005ff38c r4 : 0200 > > r3 : 30383101 r2 : f1012000 r1 : 005ff38c r0 : c0c0e0c4 > > Flags: nZCv IRQs off FIQs off Mode SVC_32 > > Resetting CPU ... > > Try to debug the value from pc. > Use the pc value using the instructions from doc/README.arm-unaligned-accesses doc/README.unaligned-accesses is about data aborts, not SW interrupts. > Thanks, > Jagan. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] ARM: implement some Cortex-A9 errata workarounds
Hi Tom, On Mon, 4 Mar 2013 08:30:11 -0800, Tom Warren wrote: > Stephen & Albert, > > > -Original Message- > > From: Stephen Warren [mailto:swar...@wwwdotorg.org] > > Sent: Friday, March 01, 2013 2:54 PM > > To: Tom Warren > > Cc: u-boot@lists.denx.de; Stephen Warren > > Subject: Re: [U-Boot] [PATCH 1/3] ARM: implement some Cortex-A9 errata > > workarounds > > > > On 02/28/2013 10:08 AM, Stephen Warren wrote: > > > On 02/26/2013 03:28 PM, Stephen Warren wrote: > > >> From: Stephen Warren > > >> > > >> Various errata exist in the Cortex-A9 CPU, and may be worked around > > >> by setting some bits in a CP15 diagnostic register. Add code to > > >> implement the workarounds, enabled by new CONFIG_ options. > > >> > > >> This code was taken from the Linux kernel, v3.8, > > >> arch/arm/mm/proc-v7.S, and modified to remove the logic to > > >> conditionally apply the WAR (since we know exactly which CPU we're > > >> running on given the U-Boot configuration), and use r0 instead of r10 > > >> for consistency with the rest of U-Boot's cpu_init_cp15(). > > > > > > Hmmm. Lets hold off on this series; there are some conditions under > > > which the kernel has to be able to apply these WARs anyway (e.g. SMP > > > CPU power saving), which may impact which of the WARs the bootloader > > > should apply even when booting the initial CPU 0. I'll repost once > > > that's been resolved. > > > > Tom, > > > > It looks like the bootloader should always apply these WARs for CPU 0. > > We just have to make sure that the kernel applies them for CPUs 1..n if/when > > running in secure mode. > > > > In other words, I think these patches are good to go in as-is. Since there > > are no changes to the patches, I won't repost them, unless you need me to. > > I can take these in via the Tegra tree, but the bulk of the changes are for > ARM, not Tegra. > Albert - do you want to take this directly into the ARM repo, or would you > prefer me to take it? I will take them in tonight. > Tom > -- > nvpublic Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Beginners Questions on modding a NAS
Hi JPT, On Mon, Mar 4, 2013 at 9:10 PM, JPT wrote: > Hi, > > I've got a NAS which uses uboot: > U-Boot 1.1.4 (Feb 6 2012 - 14:40:46) Marvell version: 3.4.27 > > It's a Netgear ReadyNAS Duo V2, and the original sofware sucks. ;) > > I would like to start with the original kernel (because it contains some > patches) and a custom debian made with multistrap. > > Where do I start? > > I'll add some information about the config. > > I believe these are the most important boot options. > > standalone=fsload 0x200 $(image_name);setenv bootargs $(console) > root=/dev/mtdblock0 rw ip=$(ipaddr):$(serverip)$(bootargs_end) > $(mvPhoneConfig); bootm 0x200; > > bootcmd=nand read.e 0x120 0x20 0x60;nand read.e 0x200 > 0x80 0x100;bootm 0x120 0x200 > > bootargs=console=ttyS0,115200 reason=normal > mtdparts=nand_mtd:0x18@0(u-boot),0x2@0x18(u-boot-env),0x60@0x20(uImage),0x100@0x80(minirootfs),0x680@0x180(jffs2); > > > there are 5 mtds: > 1,5M mtd0 - ? > 128K mtd1 - ? > 6,0M mtd2 - kernel > 2,2M mtd3 - initrd (gzipped) > 89M mtd4 - jffs2 image, I think it contains a rescue image of the > filesystem which is applied to the harddisks. > > I dumped the kernel from mtd2, it is: > u-boot legacy uImage, Linux-2.6.31.8.duov2, Linux/ARM, OS Kernel Image (Not > compressed), 3442208 bytes, Tue Aug 28 05:21:43 2012, Load Address: > 0x8000, Entry Point: 0x8000, Header CRC: 0xDA1ECA31, Data CRC: > 0x269C27DE > > > I tried to load the kernel through tftp, but it crashed: > > Marvell>> dhcp > > BOOTP broadcast 1 > *** Unhandled DHCP Option in OFFER/ACK: 28 > *** Unhandled DHCP Option in OFFER/ACK: 28 > DHCP client bound to address 192.168.20.35 > Marvell>> set serverip 192.168.20.24 > > Marvell>> tftpboot 0x0200 /boot/kernel.img > > Using egiga0 device > TFTP from server 192.168.20.24; our IP address is 192.168.20.35 > Filename '/boot/kernel.img'. > Load address: 0x200 > Loading: # > ... > done > Bytes transferred = 3442272 (348660 hex) > Marvell>> go 0x0200 Is this load address for kernel is correct? likely to have 8000 multiples.. check it once. > > ## Starting application at 0x0200 ... > software interrupt > pc : [<021c>] lr : [<00633cac>] > sp : 005fef68 ip : fp : 005ff7de > r10: 005ff3de r9 : e804 r8 : 005fffcc > r7 : 005ff388 r6 : 0001 r5 : 005ff38c r4 : 0200 > r3 : 30383101 r2 : f1012000 r1 : 005ff38c r0 : c0c0e0c4 > Flags: nZCv IRQs off FIQs off Mode SVC_32 > Resetting CPU ... Try to debug the value from pc. Use the pc value using the instructions from doc/README.arm-unaligned-accesses Thanks, Jagan. > > > thanks for any help, > > JPT > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Beginners Questions on modding a NAS
On Mar 4, 2013, at 10:40 AM, JPT wrote: > It's a Netgear ReadyNAS Duo V2, and the original sofware sucks. ;) > standalone=fsload 0x200 $(image_name);setenv bootargs $(console) > root=/dev/mtdblock0 rw ip=$(ipaddr):$(serverip)$(bootargs_end) > $(mvPhoneConfig); bootm 0x200; > bootcmd=nand read.e 0x120 0x20 0x60;nand read.e 0x200 > 0x80 0x100;bootm 0x120 0x200 Strange for a NAS to have a u-boot environment variable called "mvPhoneConfig". But anyway... > I dumped the kernel from mtd2, it is: > u-boot legacy uImage, Linux-2.6.31.8.duov2, Linux/ARM, OS Kernel Image (Not > compressed), 3442208 bytes, Tue Aug 28 05:21:43 2012, Load Address: > 0x8000, Entry Point: 0x8000, Header CRC: 0xDA1ECA31, Data CRC: > 0x269C27DE > > I tried to load the kernel through tftp, but it crashed: > Marvell>> go 0x0200 You're likely are off the rails here. Note the last command in your standalone and bootcmd variables: bootm. If your kernel is in a uImage (a u-boot wrapper) you have to use bootm to start it. Further, Linux kernels expect hardware information either as an ATAG list or a device tree. bootm sets this up before passing control but a bare "go" doesn't. Try bootm instead of go. HTH, -Mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] ARM: implement some Cortex-A9 errata workarounds
Stephen & Albert, > -Original Message- > From: Stephen Warren [mailto:swar...@wwwdotorg.org] > Sent: Friday, March 01, 2013 2:54 PM > To: Tom Warren > Cc: u-boot@lists.denx.de; Stephen Warren > Subject: Re: [U-Boot] [PATCH 1/3] ARM: implement some Cortex-A9 errata > workarounds > > On 02/28/2013 10:08 AM, Stephen Warren wrote: > > On 02/26/2013 03:28 PM, Stephen Warren wrote: > >> From: Stephen Warren > >> > >> Various errata exist in the Cortex-A9 CPU, and may be worked around > >> by setting some bits in a CP15 diagnostic register. Add code to > >> implement the workarounds, enabled by new CONFIG_ options. > >> > >> This code was taken from the Linux kernel, v3.8, > >> arch/arm/mm/proc-v7.S, and modified to remove the logic to > >> conditionally apply the WAR (since we know exactly which CPU we're > >> running on given the U-Boot configuration), and use r0 instead of r10 > >> for consistency with the rest of U-Boot's cpu_init_cp15(). > > > > Hmmm. Lets hold off on this series; there are some conditions under > > which the kernel has to be able to apply these WARs anyway (e.g. SMP > > CPU power saving), which may impact which of the WARs the bootloader > > should apply even when booting the initial CPU 0. I'll repost once > > that's been resolved. > > Tom, > > It looks like the bootloader should always apply these WARs for CPU 0. > We just have to make sure that the kernel applies them for CPUs 1..n if/when > running in secure mode. > > In other words, I think these patches are good to go in as-is. Since there > are no changes to the patches, I won't repost them, unless you need me to. I can take these in via the Tegra tree, but the bulk of the changes are for ARM, not Tegra. Albert - do you want to take this directly into the ARM repo, or would you prefer me to take it? Tom -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Beginners Questions on modding a NAS
Hi, I've got a NAS which uses uboot: U-Boot 1.1.4 (Feb 6 2012 - 14:40:46) Marvell version: 3.4.27 It's a Netgear ReadyNAS Duo V2, and the original sofware sucks. ;) I would like to start with the original kernel (because it contains some patches) and a custom debian made with multistrap. Where do I start? I'll add some information about the config. I believe these are the most important boot options. standalone=fsload 0x200 $(image_name);setenv bootargs $(console) root=/dev/mtdblock0 rw ip=$(ipaddr):$(serverip)$(bootargs_end) $(mvPhoneConfig); bootm 0x200; bootcmd=nand read.e 0x120 0x20 0x60;nand read.e 0x200 0x80 0x100;bootm 0x120 0x200 bootargs=console=ttyS0,115200 reason=normal mtdparts=nand_mtd:0x18@0(u-boot),0x2@0x18(u-boot-env),0x60@0x20(uImage),0x100@0x80(minirootfs),0x680@0x180(jffs2); there are 5 mtds: 1,5M mtd0 - ? 128K mtd1 - ? 6,0M mtd2 - kernel 2,2M mtd3 - initrd (gzipped) 89M mtd4 - jffs2 image, I think it contains a rescue image of the filesystem which is applied to the harddisks. I dumped the kernel from mtd2, it is: u-boot legacy uImage, Linux-2.6.31.8.duov2, Linux/ARM, OS Kernel Image (Not compressed), 3442208 bytes, Tue Aug 28 05:21:43 2012, Load Address: 0x8000, Entry Point: 0x8000, Header CRC: 0xDA1ECA31, Data CRC: 0x269C27DE I tried to load the kernel through tftp, but it crashed: Marvell>> dhcp BOOTP broadcast 1 *** Unhandled DHCP Option in OFFER/ACK: 28 *** Unhandled DHCP Option in OFFER/ACK: 28 DHCP client bound to address 192.168.20.35 Marvell>> set serverip 192.168.20.24 Marvell>> tftpboot 0x0200 /boot/kernel.img Using egiga0 device TFTP from server 192.168.20.24; our IP address is 192.168.20.35 Filename '/boot/kernel.img'. Load address: 0x200 Loading: # ... done Bytes transferred = 3442272 (348660 hex) Marvell>> go 0x0200 ## Starting application at 0x0200 ... software interrupt pc : [<021c>]lr : [<00633cac>] sp : 005fef68 ip : fp : 005ff7de r10: 005ff3de r9 : e804 r8 : 005fffcc r7 : 005ff388 r6 : 0001 r5 : 005ff38c r4 : 0200 r3 : 30383101 r2 : f1012000 r1 : 005ff38c r0 : c0c0e0c4 Flags: nZCv IRQs off FIQs off Mode SVC_32 Resetting CPU ... thanks for any help, JPT ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] ARM: atmel: add sama5d3xek support
On Thu, Feb 28, 2013 at 03:00:47PM +0800, Bo Shen wrote:
> Add sama5d3xek support with following feature
> - boot from NAND flash, PMECC support, 4bit ECC @ 512 bytes sector
> - boot from SPI flash support
> - boot from SD card support
> - LCD support
> - EMAC support
> - USB support
>
> Signed-off-by: Bo Shen
Some minor comments:
[snip]
> + if (cpu_is_sama5d3())
> + switch (extension_id) {
> + case ARCH_EXID_SAMA5D31:
> + return CONFIG_SYS_AT91_D31_CPU_NAME;
> + case ARCH_EXID_SAMA5D33:
> + return CONFIG_SYS_AT91_D33_CPU_NAME;
> + case ARCH_EXID_SAMA5D34:
> + return CONFIG_SYS_AT91_D34_CPU_NAME;
> + case ARCH_EXID_SAMA5D35:
> + return CONFIG_SYS_AT91_D35_CPU_NAME;
> + default:
> + return CONFIG_SYS_AT91_UNKNOWN_CPU;
These aren't configurable, and are used once. Just put the strings
here.
> @@ -0,0 +1,268 @@
> +/*
> + * Configuation settings for the SAMA5D3xEK board.
[snip]
> +#undef CONFIG_USE_IRQ/* we don't need IRQ/FIQ stuff
> */
> +
> +#undef CONFIG_CMDLINE_TAG/* enable passing of ATAGs */
> +#undef CONFIG_SETUP_MEMORY_TAGS
> +#undef CONFIG_INITRD_TAG
Just leave these, and the other #undef's out.
> +/*
> + * Command line configuration.
> + */
> +#include
> +#undef CONFIG_CMD_FPGA
> +#undef CONFIG_CMD_IMI
> +#undef CONFIG_CMD_IMLS
> +#undef CONFIG_CMD_AUTOSCRIPT
> +#undef CONFIG_CMD_LOADS
These are fine to leave in 'tho.
> +#ifdef CONFIG_USE_IRQ
> +#error CONFIG_USE_IRQ not supported
> +#endif
Just drop that part. And please check things with checkpatch.pl, I
thought I saw a '#defineFOO' in there. Thanks!
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-blackfin/master
On Mon, Mar 04, 2013 at 02:08:13PM +0800, Sonic Zhang wrote: > The following changes since commit 47104c37de076e2be35ae1b3d144614f4d24a766: > > MAKEALL: add support for per architecture toolchains (2013-02-20 > 09:40:34 -0500) > > are available in the git repository at: > > git://git.denx.de/u-boot-blackfin.git master > > for you to fetch changes up to 9faf4f08e752ca95d0986a200d48b67b59cde5ef: > > blackfin: bf60x: add resume from hibernate (2013-03-04 13:42:08 +0800) > > > Bob Liu (5): > blackfin: bf60x: new processor header files > blackfin: bf60x: add dma support > blackfin: bf60x: support big cplb page > blackfin: bf60x: add gpio support > blackfin: bf60x: add hw watchdog support > > Scott Jiang (1): > blackfin: add bf6xx spi driver > > Sonic Zhang (4): > blackfin: bf60x: Port blackfin core architecture code to boot on bf60x. > blackfin: bf60x: add serial support > blackfin: bf60x: add board and headers files to support bf609 > blackfin: bf60x: add rsi/sdh support > > Steven Miao (1): > blackfin: bf60x: add resume from hibernate > > MAINTAINERS|3 +- > arch/blackfin/cpu/cpu.c|4 +- > arch/blackfin/cpu/gpio.c | 36 +- > arch/blackfin/cpu/initcode.c | 384 > +++- > arch/blackfin/cpu/initcode.h | 52 +++ > arch/blackfin/cpu/reset.c |6 + > arch/blackfin/cpu/serial.c | 81 +++-- > arch/blackfin/cpu/serial.h | 222 +-- > arch/blackfin/cpu/serial1.h| 348 ++ > arch/blackfin/cpu/serial4.h| 161 > arch/blackfin/cpu/start.S |2 + > arch/blackfin/include/asm/blackfin_cdef.h |3 + > arch/blackfin/include/asm/blackfin_def.h |5 + > arch/blackfin/include/asm/blackfin_local.h |3 + > arch/blackfin/include/asm/config-pre.h |4 + > arch/blackfin/include/asm/cplb.h | 31 +- > arch/blackfin/include/asm/dma.h| 81 +++-- > arch/blackfin/include/asm/gpio.h |2 +- > arch/blackfin/include/asm/mach-bf533/BF531_def.h |1 + > arch/blackfin/include/asm/mach-bf561/BF561_def.h |1 + > arch/blackfin/include/asm/mach-bf609/BF609_cdef.h | 192 ++ > arch/blackfin/include/asm/mach-bf609/BF609_def.h | 247 + > arch/blackfin/include/asm/mach-bf609/anomaly.h | 97 + > arch/blackfin/include/asm/mach-bf609/def_local.h |5 + > arch/blackfin/include/asm/mach-bf609/gpio.h| 151 > arch/blackfin/include/asm/mach-bf609/portmux.h | 257 + > arch/blackfin/include/asm/mach-bf609/ports.h | 103 ++ > arch/blackfin/include/asm/mach-common/bits/cgu.h | 80 > arch/blackfin/include/asm/mach-common/bits/dde.h | 88 + > arch/blackfin/include/asm/mach-common/bits/dma.h | 54 ++- > arch/blackfin/include/asm/mach-common/bits/mpu.h |6 +- > arch/blackfin/include/asm/mach-common/bits/pll.h |5 + > arch/blackfin/include/asm/mach-common/bits/sdh.h | 38 +- > .../blackfin/include/asm/mach-common/bits/spi6xx.h | 240 > arch/blackfin/include/asm/mach-common/bits/uart4.h | 66 > arch/blackfin/lib/board.c | 25 +- > arch/blackfin/lib/clocks.c | 112 -- > arch/blackfin/lib/string.c | 97 ++--- > board/bf609-ezkit/Makefile | 55 +++ > board/bf609-ezkit/bf609-ezkit.c| 67 > boards.cfg |1 + > common/cmd_reginfo.c | 19 +- > drivers/mmc/bfin_sdh.c | 68 +++- > drivers/spi/Makefile |1 + > drivers/spi/bfin_spi6xx.c | 308 > include/configs/bf609-ezkit.h | 162 + > include/configs/bfin_adi_common.h |8 +- > 47 files changed, 3589 insertions(+), 393 deletions(-) > create mode 100644 arch/blackfin/cpu/serial1.h > create mode 100644 arch/blackfin/cpu/serial4.h > create mode 100644 arch/blackfin/include/asm/mach-bf609/BF609_cdef.h > create mode 100644 arch/blackfin/include/asm/mach-bf609/BF609_def.h > create mode 100644 arch/blackfin/include/asm/mach-bf609/anomaly.h > create mode 100644 arch/blackfin/include/asm/mach-bf609/def_local.h > create mode 100644 arch/blackfin/include/asm/mach-bf609/gpio.h > create mode 100644 arch/blackfin/include/asm/mach-bf609/portmux.h > create mode 100644 arch/blackfin/include/asm/mach-bf609/ports.h > create
Re: [U-Boot] should tools/env/README also recommend setting HOSTSTRIP?
On Thu, Feb 28, 2013 at 08:46:15AM -0500, Robert P. J. Day wrote: > it would seem that in addition to manually setting HOSTCC, a user > should also set HOSTSTRIP when building fw_printenv, no? there's no > mention of that in the README but the strip operation will certainly > fail without it. True, the README wasn't updated back when we added HOSTSTRIP into the mix. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: global_data: make tbl long long
Dear Wolfgang,
On 04.03.2013 12:10, Wolfgang Denk wrote:
Dear Dirk Behme,
In message <1362387637-32334-1-git-send-email-dirk.be...@de.bosch.com> you
wrote:
From: Dirk Behme
Several ARM timer implementations use gd->arch.tbl to record the
absolute tick count of 32-bit counters, including timer overflows.
For example arch/arm/imx-common/timer.c does:
ulong lastinc;
ulong now = counter value;
if (no overflow) {
...
} else { /* counter overflow */
gd->arch.tbl += (0x - lastinc) + now;
}
lastinc = now;
As we use a 32-bit counter and the two ulong (32-bit) variables 'lastinc'
and 'now' here, gd->arch.tbl should be long long (64-bit) to not overflow
at the same time, too.
I think this is wrong.
"tbl" means "time base, lower 32 bits" and is complemented by "tbu"
(time base, upper 32 bits) to form a 64 bit time base counter.
If you need the full 64 bit precision, then please either maintain the
carry manually, or use a proper union or similar.
Many thanks for this explanation!
This patch is obsolete now, replaced by
http://patchwork.ozlabs.org/patch/224740/
Thanks
Dirk
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] imx-common: timer: fix 32-bit overflow
From: Knut Wohlrab
The i.MX6 common timer uses the 32-bit variable tbl (time base lower)
to record the overflow of the 32-bit counter. I.e. if the counter
overflows, the variable tbl does overflow, too.
To capture this overflow, use the variable tbu (time base upper), too.
Return the combined value of tbl and tbu.
lastinc is unused then, remove it.
Signed-off-by: Knut Wohlrab
Signed-off-by: Dirk Behme
---
Note: This replaces the patch
http://patchwork.ozlabs.org/patch/224646/
arch/arm/imx-common/timer.c | 26 +++---
1 file changed, 7 insertions(+), 19 deletions(-)
Index: freescale-u-boot-imx.git/arch/arm/imx-common/timer.c
===
--- freescale-u-boot-imx.git.orig/arch/arm/imx-common/timer.c
+++ freescale-u-boot-imx.git/arch/arm/imx-common/timer.c
@@ -48,9 +48,6 @@ static struct mxc_gpt *cur_gpt = (struct
DECLARE_GLOBAL_DATA_PTR;
-#define timestamp (gd->arch.tbl)
-#define lastinc (gd->arch.lastinc)
-
static inline unsigned long long tick_to_time(unsigned long long tick)
{
tick *= CONFIG_SYS_HZ;
@@ -70,7 +67,6 @@ static inline unsigned long long us_to_t
int timer_init(void)
{
int i;
- ulong val;
/* setup GP Timer 1 */
__raw_writel(GPTCR_SWR, &cur_gpt->control);
@@ -85,9 +81,8 @@ int timer_init(void)
i = __raw_readl(&cur_gpt->control);
__raw_writel(i | GPTCR_CLKSOURCE_32 | GPTCR_TEN, &cur_gpt->control);
- val = __raw_readl(&cur_gpt->counter);
- lastinc = val / (MXC_CLK32 / CONFIG_SYS_HZ);
- timestamp = 0;
+ gd->arch.tbl = __raw_readl(&cur_gpt->counter);
+ gd->arch.tbu = 0;
return 0;
}
@@ -96,18 +91,11 @@ unsigned long long get_ticks(void)
{
ulong now = __raw_readl(&cur_gpt->counter); /* current tick value */
- if (now >= lastinc) {
- /*
-* normal mode (non roll)
-* move stamp forward with absolut diff ticks
-*/
- timestamp += (now - lastinc);
- } else {
- /* we have rollover of incrementer */
- timestamp += (0x - lastinc) + now;
- }
- lastinc = now;
- return timestamp;
+ /* increment tbu if tbl has rolled over */
+ if (now < gd->arch.tbl)
+ gd->arch.tbu++;
+ gd->arch.tbl = now;
+ return (((unsigned long long)gd->arch.tbu) << 32) | gd->arch.tbl;
}
ulong get_timer_masked(void)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 7/9] am33xx: support ti814x mmc reference clock
> "Matt" == Matt Porter writes: Hi, >> Did you figure out why it was working for you with 96 MHz ref? Matt> Unfortunately not at a root cause level. Unless I'm missing Matt> something I would have expected the calculations from the Matt> supplied 96 MHz ref clock to result in 2x the clock the SD card Matt> can handle due to the incorrect divider. However, with the LA Matt> attached, I found that a 2-3 MHz SDCLK was being generated after Matt> the capability probe occurs. Odd and incorrect, but Matt> functional. After switching to 192MHz I was able to sample a Matt> nominal 25MHz SDCLK as expected on a regular SD card advertising Matt> that as its capability. I don't like it but I'm going to mark Matt> this down as "something undocumented" as I only have PG1.0 Matt> silicon but can't find an errata sheet for that version right Matt> now. Ok, thanks for the info. -- Bye, Peter Korsgaard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Hang issue when applied patch "spi: Add SPI flash test"
+U-Boot mailing list Hi Mingkai, On Mon, Mar 4, 2013 at 12:48 AM, Hu Mingkai-B21284 wrote: > Hi Simon, > > > > After applied following patch, read from SPI flash will hang on p2041rdb > board. > > > > From 2400727318a0a1ecf15a9deae85b0719c4c47aba Mon Sep 17 00:00:00 2001 > > From: Simon Glass > > Date: Mon, 8 Oct 2012 13:16:02 + > > Subject: [PATCH] spi: Add SPI flash test > > > > It is useful to have a basic SPI flash test, which tests that the SPI chip, > > the SPI bus and the driver are behaving. > > > > This test erases part of the flash, writes data and reads it back as a > > sanity check that all is well. > > > > Use CONFIG_SF_TEST to enable it. > > > > Signed-off-by: Simon Glass s...@chromium.org > > > > If included the div64 header file after common.h, it doesn’t hang anymore. > > Do you have any suggestions? > > > > +#include > > #include > > Well I think div64.h should be after common, so it is fine to move it. I am not sure why that causes a hang though - do you have more details - e.g. what did you do when it hangs, what is console output? Also do you define CONFIG_CMD_SF_TEST? Regards, Simon > > Thanks, > > Mingkai ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 7/9] am33xx: support ti814x mmc reference clock
On Sun, Mar 03, 2013 at 10:34:08PM +, Peter Korsgaard wrote: > > "Matt" == Matt Porter writes: > > Matt> TI814x has a 192MHz hsmmc reference clock. Select that clock rate > Matt> when building for TI814x. > > Matt> Signed-off-by: Matt Porter > > Acked-by: Peter Korsgaard > > Did you figure out why it was working for you with 96 MHz ref? Unfortunately not at a root cause level. Unless I'm missing something I would have expected the calculations from the supplied 96 MHz ref clock to result in 2x the clock the SD card can handle due to the incorrect divider. However, with the LA attached, I found that a 2-3 MHz SDCLK was being generated after the capability probe occurs. Odd and incorrect, but functional. After switching to 192MHz I was able to sample a nominal 25MHz SDCLK as expected on a regular SD card advertising that as its capability. I don't like it but I'm going to mark this down as "something undocumented" as I only have PG1.0 silicon but can't find an errata sheet for that version right now. -Matt ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] Allow AM335x MPU core clock speed to be specified in the board config file
> "Mark" == Mark Jackson writes: Mark> Allow AM335x MPU core clock speed to be specified in the board config file. Mark> To use, add the following to the board's config file:- Mark> #define CONFIG_SYS_MPUCLK Mark> Signed-off-by: Mark Jackson Acked-by: Peter Korsgaard -- Bye, Peter Korsgaard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4] Allow AM335x MPU core clock speed to be specified in the board config file
Allow AM335x MPU core clock speed to be specified in the board config file. To use, add the following to the board's config file:- #define CONFIG_SYS_MPUCLK Signed-off-by: Mark Jackson --- Changes in v4: - Now defined as MHz (not Hz) Changes in v3: - Changed from V_MPUCLK to CONFIG_SYS_MPUCLK - Added entry in README Changes in v2: - Tweaked after comments from Peter Korsgaard README |4 arch/arm/include/asm/arch-am33xx/clocks_am33xx.h |7 +-- 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/README b/README index d8cb394..ddf6df2 100644 --- a/README +++ b/README @@ -3820,6 +3820,10 @@ Low Level (hardware related) configuration options: If defined, the x86 reset vector code is included. This is not needed when U-Boot is running from Coreboot. +- CONFIG_SYS_MPUCLK + Defines the MPU clock speed (in MHz). + + NOTE : currently only supported on AM335x platforms. Freescale QE/FMAN Firmware Support: --- diff --git a/arch/arm/include/asm/arch-am33xx/clocks_am33xx.h b/arch/arm/include/asm/arch-am33xx/clocks_am33xx.h index d748dd2..2d96007 100644 --- a/arch/arm/include/asm/arch-am33xx/clocks_am33xx.h +++ b/arch/arm/include/asm/arch-am33xx/clocks_am33xx.h @@ -21,8 +21,11 @@ #define OSC(V_OSCK/100) -/* MAIN PLL Fdll = 550 MHZ, */ -#define MPUPLL_M 550 +/* MAIN PLL Fdll = 550 MHz, by default */ +#ifndef CONFIG_SYS_MPUCLK +#define CONFIG_SYS_MPUCLK 550 +#endif +#define MPUPLL_M CONFIG_SYS_MPUCLK #define MPUPLL_N (OSC-1) #define MPUPLL_M2 1 -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] Allow AM335x MPU core clock speed to be specified in the board config file
On 04/03/13 11:14, Wolfgang Denk wrote: > Dear Mark Jackson, > > In message <51346856.8020...@mimc.co.uk> you wrote: >> Allow AM335x MPU core clock speed to be specified in the board config file. >> To use, add the following to the board's config file:- >> >> #define CONFIG_SYS_MPUCLK > > Why do you claim an accuracy of Hz here, when in the code you silently > throw away any sub-MHz parts anyway? Why not leaving it at MHz as it > was before, and as used in the code? I was simply copying the format of the existing V_OSCK defines, but I'm happy to change it. Regards Mark J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 08/11] Blackfin: bf60x: add rsi/sdh support
Dear Sonic Zhang, In message you wrote: > > Maybe I didn't describe it clearly. Yes, I return 0 at the end of this > function. But, the same function may return UNUSABLE_ERR(-17) at the > beginning if the data flags match MMC_DATA_WRITE. That's why the > function can't return void. Is anything contradicting in my > explanation? I see. Sorry, I missed that other return. One additional question, though: > /* kick off transfer */ > bfin_write_SDH_DATA_CTL(bfin_read_SDH_DATA_CTL() | DTX_DMA_E | DTX_E); > > - return ret; > + return 0; Are the bfin_read_SDH_DATA_CTL() and bfin_write_SDH_DATA_CTL() supposed to always work, i. e. are we positively sure that these can never fail, so there is no need to test the return code and handle error conditions? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de People have one thing in common: they are all different. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] Allow AM335x MPU core clock speed to be specified in the board config file
Dear Mark Jackson, In message <51346856.8020...@mimc.co.uk> you wrote: > Allow AM335x MPU core clock speed to be specified in the board config file. > To use, add the following to the board's config file:- > > #define CONFIG_SYS_MPUCLK Why do you claim an accuracy of Hz here, when in the code you silently throw away any sub-MHz parts anyway? Why not leaving it at MHz as it was before, and as used in the code? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de There are three ways to get something done: (1) Do it yourself. (2) Hire someone to do it for you. (3) Forbid your kids to do it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] problem with USB storage STALL status
Dear Anton Vasilyev,
In message
you wrote:
>
> Separating DATA phase and STATUS phase by mdelay(1) helps me solve current
> problem.
>
> diff --git a/common/usb_storage.c b/common/usb_storage.c
> index fb322b4..ea88536 100644
> --- a/common/usb_storage.c
> +++ b/common/usb_storage.c
> @@ -740,6 +740,7 @@ static int usb_stor_BBB_transport(ccb *srb, struct
> us_data *us)
> st:
> retry = 0;
> again:
> + mdelay(1);
> USB_STOR_PRINTF("STATUS phase\n");
> result = usb_bulk_msg(us->pusb_dev, pipein, csw, UMASS_BBB_CSW_SIZE,
> &actlen, USB_CNTL_TIMEOUT*5);
Indentation is all wrong, and there is no SoB line.
> I din't find any explanation for this delay in USB specification, but at
> Linux Kernel I found similar separation (drivers/usb/storage.c):
>
> /* Some USB-IDE converter chips need a 100us delay between the
> * command phase and the data phase. Some devices need a little
> * more than that, probably because of clock rate inaccuracies. */
Are you sure that you really need 1000 us, instead of the 100 us given
here? On which exact device does this happen? Do other devices work
with shorter delays?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Remember that the best relationship is one in which your love for
each other exceeds your need for each other. - Dalai Lama
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: global_data: make tbl long long
Dear Dirk Behme,
In message <1362387637-32334-1-git-send-email-dirk.be...@de.bosch.com> you
wrote:
> From: Dirk Behme
>
> Several ARM timer implementations use gd->arch.tbl to record the
> absolute tick count of 32-bit counters, including timer overflows.
> For example arch/arm/imx-common/timer.c does:
>
> ulong lastinc;
> ulong now = counter value;
> if (no overflow) {
> ...
> } else { /* counter overflow */
> gd->arch.tbl += (0x - lastinc) + now;
> }
> lastinc = now;
>
> As we use a 32-bit counter and the two ulong (32-bit) variables 'lastinc'
> and 'now' here, gd->arch.tbl should be long long (64-bit) to not overflow
> at the same time, too.
I think this is wrong.
"tbl" means "time base, lower 32 bits" and is complemented by "tbu"
(time base, upper 32 bits) to form a 64 bit time base counter.
If you need the full 64 bit precision, then please either maintain the
carry manually, or use a proper union or similar.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
A consultant is a person who borrows your watch, tells you what time
it is, pockets the watch, and sends you a bill for it.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] ARM: mmu: Set domain permissions to client access - build warnings!
On 03/02/2013 11:46 PM, Albert ARIBAUD wrote: > (..) Basically, this means we need Vincent's series > to be applied first, then we can apply Sricharan's. Hi, I think this is too much trouble for a "one liner". Please feel free to squash. Best regards, V. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] cmd_mem: Decode the mtest start and end values from fdt
Dear Jagannadha Sutradharudu Teki, In message <51f05678-4118-4be8-bb94-ad295c407...@db3ehsmhs015.ehs.local> you wrote: > > I think the entire logic to add mtest address support through devicetree with > the > help of environment variables is a mess as there are some side effects (as > you mentioned already). Agreed. > The main intention to add these address on devicetree is to make memory > address configured at > runtime instead of CONFIG_ macros. Then just use command line arguments! The defaults set in the CONFIG_ veriables are intended as safe margins; they should be set such that they exclude just the exception vector area (supposed to be located at the lower end of memory) and the U-Boot code and data (supposed to be located at the upper end of memory) from testing, but exclude nearly all otherwise available RAM. > As in most of the boards CONFIG_SYS_MEMTEST_START is depends on > CONFIG_SYS_SDRAM_BASE. > I am trying to remove the dependency instead use the devicetree nodes. This makes no sense to me. If CONFIG_SYS_SDRAM_BASE and the device tree settings don;t agree, you have a serious problem anyway, and need to fix this first. > Ok, maybe I will add my logic for decoding these address from devicetree on > to common/cmd_mem.c > instead of common/main.c, does it make sense? Help me I f am wrong. I have to admit that I don't see a use case where this might be needed, or even beneficial. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Time is a drug. Too much of it kills you. - Terry Pratchett, _Small Gods_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/85xx: Add workaround for errata USB-14 (enable on P204x/P3041/P50x0)
Dear xulei, In message <1362368146-738-1-git-send-email-b33...@freescale.com> you wrote: > On P204x/P304x/P50x0 Rev1.0, USB transmit will result in false internal > multi-bit ECC errors, which has impact on performance, so software should > disable all ECC reporting from USB1 and USB2 by setting bits 16 and 17 to 1 > in the register at DCSRBASE + 0x0002_0520. ... > + void *p; > + p = (void *)CONFIG_SYS_DCSRBAR + 0x20520; Um... and don't we have a proper C struct that describes the registers in this area? We don't allow base address + offset addressing like this. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Just because your doctor has a name for your condition doesn't mean he knows what it is. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] Allow AM335x MPU core clock speed to be specified in the board config file
Allow AM335x MPU core clock speed to be specified in the board config file. To use, add the following to the board's config file:- #define CONFIG_SYS_MPUCLK Signed-off-by: Mark Jackson --- Changes in v3: - Changed from V_MPUCLK to CONFIG_SYS_MPUCLK - Added entry in README Changes in v2: - Tweaked after comments from Peter Korsgaard README |4 arch/arm/include/asm/arch-am33xx/clocks_am33xx.h |7 +-- 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/README b/README index d8cb394..ddf6df2 100644 --- a/README +++ b/README @@ -3820,6 +3820,10 @@ Low Level (hardware related) configuration options: If defined, the x86 reset vector code is included. This is not needed when U-Boot is running from Coreboot. +- CONFIG_SYS_MPUCLK + Defines the MPU clock speed (in Hz). + + NOTE : currently only supported on AM335x platforms. Freescale QE/FMAN Firmware Support: --- diff --git a/arch/arm/include/asm/arch-am33xx/clocks_am33xx.h b/arch/arm/include/asm/arch-am33xx/clocks_am33xx.h index d748dd2..5f2939b 100644 --- a/arch/arm/include/asm/arch-am33xx/clocks_am33xx.h +++ b/arch/arm/include/asm/arch-am33xx/clocks_am33xx.h @@ -21,8 +21,11 @@ #define OSC(V_OSCK/100) -/* MAIN PLL Fdll = 550 MHZ, */ -#define MPUPLL_M 550 +/* MAIN PLL Fdll = 550 MHz, by default */ +#ifndef CONFIG_SYS_MPUCLK +#define CONFIG_SYS_MPUCLK 55000 +#endif +#define MPUPLL_M (CONFIG_SYS_MPUCLK/100) #define MPUPLL_N (OSC-1) #define MPUPLL_M2 1 -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/85xx: Add workaround for errata USB-14 (enable on P204x/P3041/P50x0)
Dear xulei,
In message <1362368146-738-1-git-send-email-b33...@freescale.com> you wrote:
>
> + /* On P204x/P304x/P50x0 Rev1.0, USB transmit will result internal
> + * multi-bit ECC errors, which has impact on performance, so software
> + * should disable all ECC reporting from USB1 and USB2 by setting bits
> + * 16 and 17 to 1 in the register at DCSRBASE + 0x0002_0520.
> + */
> +#ifdef CONFIG_SYS_FSL_ERRATUM_USB14
> + if (IS_SVR_REV(get_svr(), 1, 0)) {
> + void *p;
> + p = (void *)CONFIG_SYS_DCSRBAR + 0x20520;
> + setbits_be32(p, 3 << (31 - 17));
> + }
> +#endif
Please move the comment inside the #ifdef block.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
I distrust all systematisers, and avoid them. The will to a system
shows a lack of honesty.
- Friedrich Wilhelm Nietzsche _Götzen-Dämmerung [The Twilight of the
Idols]_ ``Maxims and Missiles'' no. 26
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Allow AM335x MPU core clock speed to be specified in the board config file
On 04/03/13 00:27, Wolfgang Denk wrote: > Dear Mark Jackson, > > In message <5130c537.8000...@mimc.co.uk> you wrote: >> Allow AM335x MPU core clock speed to be specified in the board config file. >> To use, add the following to the board's config file:- >> >> #define V_MPUCLK > > If this is a configurable option, it should be CONFIG_SYS_V_MPUCLK > instead. > >> arch/arm/include/asm/arch-am33xx/clocks_am33xx.h |7 +-- >> 1 file changed, 5 insertions(+), 2 deletions(-) > > Also, this new config option must be documented in the README. No problem ... I'll post a v3. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] problem with USB storage STALL status
Hello,
Separating DATA phase and STATUS phase by mdelay(1) helps me solve current
problem.
diff --git a/common/usb_storage.c b/common/usb_storage.c
index fb322b4..ea88536 100644
--- a/common/usb_storage.c
+++ b/common/usb_storage.c
@@ -740,6 +740,7 @@ static int usb_stor_BBB_transport(ccb *srb, struct
us_data *us)
st:
retry = 0;
again:
+ mdelay(1);
USB_STOR_PRINTF("STATUS phase\n");
result = usb_bulk_msg(us->pusb_dev, pipein, csw, UMASS_BBB_CSW_SIZE,
&actlen, USB_CNTL_TIMEOUT*5);
I din't find any explanation for this delay in USB specification, but at
Linux Kernel I found similar separation (drivers/usb/storage.c):
/* Some USB-IDE converter chips need a 100us delay between the
* command phase and the data phase. Some devices need a little
* more than that, probably because of clock rate inaccuracies. */
--
Best regards,
Anton Vasilyev.
2013/2/27 Anton Vasilyev
> Greetings,
>
> I faced with problem: when I read data from USB Storage It unpredictably
> goes to 'RESET:stall' condition.
> After this read continuously fall down to usb_stor_BBB_reset() function
> Comment to this function told about Reset recovery:
> * For Reset Recovery the host shall issue in the following order:
> * a) a Bulk-Only Mass Storage Reset
> * b) a Clear Feature HALT to the Bulk-In endpoint
> * c) a Clear Feature HALT to the Bulk-Out endpoint
> *
> * This is done in 3 steps.
> *
> * If the reset doesn't succeed, the device should be port reset.
>
> Whereas Universal Serial Bus Specification Revision 2.0 in section 8.5.3
> describes that STALL handshake will be returned on all succeeding accesses
> until a SETUP PID is received.
>
> I can't understand how correctly work with STALL status and where is a
> root of problem.
>
>
>
>
> Debug information is following:
>
> STATUS phase
> dev=3f3b03d8, pipe=c8008383, buffer=3f1f7490, length=13, req=(null)
> TOKEN=0x80008d00
> .read10: start 7c70 blocks 28
> COMMAND phase
> dev=3f3b03d8, pipe=c8008303, buffer=3f1f7444, length=31, req=(null)
> TOKEN=0x80008c00
> DATA phase
> dev=3f3b03d8, pipe=c8008383, buffer=0058e000, length=20480, req=(null)
> TOKEN=0x8000dd08
> usb_bulk_msg error status 32
> BBB_reset
> usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0
> length 0x0
> dev=3f3b03d8, pipe=88000303, buffer=(null), length=0, req=3f1f7430
> req=255 (0xff), type=33 (0x21), value=0 (0x0), index=0
> TOKEN=0x80248
> RESET:stall
> Read ERROR
> COMMAND phase
> dev=3f3b03d8, pipe=c8008303, buffer=3f1f7444, length=31, req=(null)
> dev=3, usbsts=0x88, p[1]=0x8001205, p[2]=0x0
> usb_stor_BBB_comdat:usb_bulk_msg error
> failed to send CBW status -2147483648
> BBB_reset
> usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0
> length 0x0
> dev=3f3b03d8, pipe=88000303, buffer=(null), length=0, req=3f1f7430
> req=255 (0xff), type=33 (0x21), value=0 (0x0), index=0
> TOKEN=0x80248
> RESET:stall
> Request Sense returned 00 00 00
> .read10: start 7c70 blocks 28
> COMMAND phase
> dev=3f3b03d8, pipe=c8008303, buffer=3f1f7444, length=31, req=(null)
> dev=3, usbsts=0x88, p[1]=0x8001205, p[2]=0x0
> usb_stor_BBB_comdat:usb_bulk_msg error
> failed to send CBW status -2147483648
> BBB_reset
> usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0
> length 0x0
> dev=3f3b03d8, pipe=88000303, buffer=(null), length=0, req=3f1f7430
> req=255 (0xff), type=33 (0x21), value=0 (0x0), index=0
> TOKEN=0x80248
> RESET:stall
> Read ERROR
> COMMAND phase
> dev=3f3b03d8, pipe=c8008303, buffer=3f1f7444, length=31, req=(null)
> dev=3, usbsts=0x88, p[1]=0x8001205, p[2]=0x0
> usb_stor_BBB_comdat:usb_bulk_msg error
> failed to send CBW status -2147483648
> BBB_reset
> usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0
> length 0x0
> dev=3f3b03d8, pipe=88000303, buffer=(null), length=0, req=3f1f7430
> req=255 (0xff), type=33 (0x21), value=0 (0x0), index=0
> TOKEN=0x80248
> RESET:stall
> Request Sense returned 00 00 00
> .read10: start 7c70 blocks 28
> COMMAND phase
> dev=3f3b03d8, pipe=c8008303, buffer=3f1f7444, length=31, req=(null)
> dev=3, usbsts=0x88, p[1]=0x8001205, p[2]=0x0
> usb_stor_BBB_comdat:usb_bulk_msg error
> failed to send CBW status -2147483648
> BBB_reset
> usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0
> length 0x0
> dev=3f3b03d8, pipe=88000303, buffer=(null), length=0, req=3f1f7430
> req=255 (0xff), type=33 (0x21), value=0 (0x0), index=0
> TOKEN=0x80248
> RESET:stall
> Read ERROR
>
> --
> Best regards,
> Anton Vasilyev.
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: global_data: make tbl long long
From: Dirk Behme
Several ARM timer implementations use gd->arch.tbl to record the
absolute tick count of 32-bit counters, including timer overflows.
For example arch/arm/imx-common/timer.c does:
ulong lastinc;
ulong now = counter value;
if (no overflow) {
...
} else { /* counter overflow */
gd->arch.tbl += (0x - lastinc) + now;
}
lastinc = now;
As we use a 32-bit counter and the two ulong (32-bit) variables 'lastinc'
and 'now' here, gd->arch.tbl should be long long (64-bit) to not overflow
at the same time, too.
Signed-off-by: Knut Wohlrab
Signed-off-by: Dirk Behme
---
arch/arm/include/asm/global_data.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/global_data.h
b/arch/arm/include/asm/global_data.h
index 37ac0da..1099af9 100644
--- a/arch/arm/include/asm/global_data.h
+++ b/arch/arm/include/asm/global_data.h
@@ -41,7 +41,7 @@ struct arch_global_data {
/* "static data" needed by most of timer.c on ARM platforms */
unsigned long timer_rate_hz;
unsigned long tbu;
- unsigned long tbl;
+ unsigned long long tbl;
unsigned long lastinc;
unsigned long long timer_reset_value;
#ifdef CONFIG_IXP425
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Problems around fatwrite command from uboot
> 2013/2/28 Damien HUANG > > After investigation, I believe the problem can be fixed at function > "set_cluster" within file fat_write.c under directory /fs/fat (patch file > was attached). > Hi Damien, I found no trace of your patch in the mailing list (perhaps the attachment was dropped by the list server or there was some other encoding error). It may be interesting for others (like me ;) to see what you have done so could you re-post it to the list as plain text in the mail? BR // Mats ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
