Re: [U-Boot] [PATCH v2] cfi_flash: Fix unaligned accesses to cfi_qry structure
Hi Albert,
On 05/22/2013 08:50 PM, Albert ARIBAUD wrote:
snip
@@ -148,10 +152,10 @@ struct cfi_qry {
u8 block_erase_timeout_max;
u8 chip_erase_timeout_max;
u8 dev_size;
-u16 interface_desc;
-u16 max_buf_write_size;
+u16 interface_desc; /* aligned */
+u16 max_buf_write_size; /* aligned */
u8 num_erase_regions;
-u32 erase_region_info[NUM_ERASE_REGIONS];
+u32 erase_region_info[NUM_ERASE_REGIONS]; /* unaligned */
} __attribute__((packed));
struct cfi_pri_hdr {
Reviewed-By: Albert ARIBAUD albert.u.b...@aribaud.net
Seems ok to me.
Now, seeing as this is global to all architectures, yet motivated by
ARM alignment considerations, which repo should this go to?
I'm responsible for cfi-flash. I'll look at it today.
Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch v2 2/4] NET: macb: support sama5d3x devices
Hi Bo, On 22.05.13 10:45, Bo Shen wrote: Hi Andreas, On 5/14/2013 05:31, Joe Hershberger wrote: On Sun, May 12, 2013 at 6:33 AM, Andreas Bießmann andreas.de...@googlemail.com wrote: Dear Bo Shen, On 12.03.2013 07:15, Bo Shen wrote: Add macb support for sama5d3x devices Signed-off-by: Bo Shen voice.s...@atmel.com --- change in v2: No change --- drivers/net/macb.c |6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/net/macb.c b/drivers/net/macb.c index 8bacbda..9e7fbc6 100644 --- a/drivers/net/macb.c +++ b/drivers/net/macb.c @@ -469,7 +469,8 @@ static int macb_init(struct eth_device *netdev, bd_t *bd) #if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260) || \ defined(CONFIG_AT91SAM9263) || defined(CONFIG_AT91SAM9G20) || \ defined(CONFIG_AT91SAM9G45) || defined(CONFIG_AT91SAM9M10G45) || \ - defined(CONFIG_AT91SAM9XE) || defined(CONFIG_AT91SAM9X5) + defined(CONFIG_AT91SAM9XE) || defined(CONFIG_AT91SAM9X5) || \ + defined(CONFIG_SAMA5D3) I would like to apply http://patchwork.ozlabs.org/patch/239064/ instead of this one. Joe, do you have any objections? Agreed. Just remind to take this patch: net: macb: using AT91FAMILY replace #ifdeferry (http://patchwork.ozlabs.org/patch/239064/). or else the macb won't work with sama5d3xek board. I thought this would go through Joe's tree. There are some patches delegated to him regarding sama5 network too (gmac). I could pick up this single patch however, lets wait some days for Joe to work on the whole series. Best regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/4] README: document CONFIG_ENV_IS_IN_MMC
S == Stephen Warren swar...@wwwdotorg.org writes: S From: Stephen Warren swar...@nvidia.com S Describe the meaning of CONFIG_ENV_IS_IN_MMC, and all related defines that S must or can be set when using that option. S Signed-off-by: Stephen Warren swar...@nvidia.com S --- S v2: New patch. S --- S README | 38 ++ S 1 file changed, 38 insertions(+) S diff --git a/README b/README S index 3012dcd..b9936ca 100644 S --- a/README S +++ b/README S @@ -3606,6 +3606,44 @@ but it can not erase, write this NOR flash by SRIO or PCIE interface. S You will probably want to define these to avoid a really noisy system S when storing the env in UBI. S +- CONFIG_ENV_IS_IN_MMC: S + S + Define this if you have an MMC device which you want to use for the S + environment. S + S + - CONFIG_SYS_MMC_ENV_DEV: S + S + Specifies which MMC device the environment is stored in. S + S + - CONFIG_SYS_MMC_ENV_PART (optional): S + S + Specifies which MMC partition the environment is stored in. If not S + set, defaults to partition 0, the user area. Common values might be S + 1 (first MMC boot partition), 2 (second MMC boot partition). S + S + - CONFIG_ENV_OFFSET: S + - CONFIG_ENV_SIZE: S + S + These two #defines specify the offset and size of the environment S + area within the specified MMC device. S + S + These two values must be aligned to an MMC sector boundary. It would be good to explicitly mention that these values are in bytes, and not sectors. S + S + - CONFIG_ENV_OFFSET_REDUND (optional): S + S + Specifies a second storage area, of CONFIG_ENV_SIZE size, used to S + hold a redundant copy of the environment data. This provides a S + valid backup copy in case the other copy is corrupted, e.g. due S + to a power failure during a saveenv operation. S + S + This value must also be aligned to an MMC sector boundary. S + S + - CONFIG_ENV_SIZE_REDUND (optional): S + S + This value need not be set, even when CONFIG_ENV_OFFSET_REDUND is S + set. If this value is set, it must be set to the same value as S + CONFIG_ENV_OFFSET. s/CONFIG_ENV_OFFSET/CONFIG_ENV_SIZE/ -- Bye, Peter Korsgaard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v03 1/2] OMAP3+: introduce generic ABB support
On 05/22/2013 11:56 PM, Nishanth Menon wrote:
Hi Andrii,
We are almost there.. minor comments follow:
On 11:42-20130521, Andrii Tseglytskyi wrote:
[...]
diff --git a/arch/arm/cpu/armv7/omap5/abb.c b/arch/arm/cpu/armv7/omap5/abb.c
new file mode 100644
index 000..92470be
--- /dev/null
+++ b/arch/arm/cpu/armv7/omap5/abb.c
@@ -0,0 +1,67 @@
I might introduce this as part of patch #2... but no strong feelings
about it.
[...]
+s8 abb_setup_ldovbb(u32 fuse, u32 ldovbb)
+{
+ u32 vset;
+
+ /*
+* ABB parameters must be properly fused
+* otherwise ABB should be disabled
+*/
+ vset = readl(fuse);
+ if (!(vset OMAP5_ABB_FUSE_ENABLE_MASK))
+ return -1;
+
+ /* prepare VSET value for LDOVBB mux register */
+ vset = OMAP5_ABB_FUSE_VSET_MASK;
+ vset = ffs(OMAP5_ABB_FUSE_VSET_MASK) - 1;
+ vset = ffs(OMAP5_ABB_LDOVBBMPU_VSET_OUT_MASK) - 1;
+ vset |= OMAP5_ABB_LDOVBBMPU_MUX_CTRL_MASK;
+
+ /* setup LDOVBB using fused value */
+ clrsetbits_le32(ldovbb, OMAP5_ABB_LDOVBBMPU_VSET_OUT_MASK, vset);
OMAP5_ABB_LDOVBBMPU_MUX_CTRL_MASK wont get set :(
Sorry didn't get... I have
vset |= *OMAP5_ABB_LDOVBBMPU_MUX_CTRL_MASK*; -- set here
clrsetbits_le32(ldovbb, OMAP5_ABB_LDOVBBMPU_VSET_OUT_MASK, vset);
Maybe it would be more clear to rework to:
clrsetbits_le32(ldovbb, OMAP5_ABB_LDOVBBMPU_VSET_OUT_MASK, vset |
*OMAP5_ABB_LDOVBBMPU_MUX_CTRL_MASK*);
Is this your suggestion?
Regards,
Andrii
[...]
Other than this, I have no further comments.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] SPI: Winbond: Add W25Q32 to spi flash table
Hi Rajeshwari,
On Fri, Mar 22, 2013 at 11:51 AM, Rajeshwari Birje
rajeshwari.bi...@gmail.com wrote:
Hi Minkyu Kang,
Please let me know if we can merge this into u-boot-samsung branch or
do I need to re-base on some other branch.
Regards,
Rajeshwari Shinde
On Fri, Feb 8, 2013 at 9:56 AM, Simon Glass s...@chromium.org wrote:
On Thu, Feb 7, 2013 at 2:07 AM, Rajeshwari Shinde
rajeshwar...@samsung.com wrote:
Add W25Q32 to Winbond spi flash table as it is required for snow
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
drivers/mtd/spi/winbond.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/spi/winbond.c b/drivers/mtd/spi/winbond.c
index f6aab3d..f47634e 100644
--- a/drivers/mtd/spi/winbond.c
+++ b/drivers/mtd/spi/winbond.c
@@ -67,6 +67,11 @@ static const struct winbond_spi_flash_params
winbond_spi_flash_table[] = {
.nr_blocks = 128,
.name = W25Q80,
},
+ {
+ .id = 0x6016,
+ .nr_blocks = 64,
+ .name = W25Q32,
+ },
};
Can you please check that the same part support has been added already in master
http://git.denx.de/?p=u-boot/u-boot-spi.git;a=commitdiff;h=772ba15474f73adc942e817cc072b6e9750836cc
Please let me know you are referring a different part.
And also the change in above link seems to have incorrect nr_blocks, i
will write a mail CC you as well.
Thanks,
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 07/13] sf: winbond: add W25Q32DW
Hi Allen,
On Sun, Mar 17, 2013 at 10:28 AM, Allen Martin amar...@nvidia.com wrote:
Add support for Winbond W25Q32DW 32Mbit part
Signed-off-by: Allen Martin amar...@nvidia.com
---
drivers/mtd/spi/winbond.c |5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/mtd/spi/winbond.c b/drivers/mtd/spi/winbond.c
index 4418302..3560fcb 100644
--- a/drivers/mtd/spi/winbond.c
+++ b/drivers/mtd/spi/winbond.c
@@ -68,6 +68,11 @@ static const struct winbond_spi_flash_params
winbond_spi_flash_table[] = {
.name = W25Q80,
},
{
+ .id = 0x6016,
+ .nr_blocks = 512,
nr_blocks here should have 64 instead of 512.
please let me know, I will add correction-patch for this.
Thanks,
Jagan.
+ .name = W25Q32DW,
+ },
+ {
.id = 0x6017,
.nr_blocks = 128,
.name = W25Q64DW,
--
1.7.10.4
___
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 v2] cfi_flash: Fix unaligned accesses to cfi_qry structure
On 05/14/2013 07:27 PM, Andrew Gabbasov wrote: Packed structure cfi_qry contains unaligned 16- and 32-bits members, accessing which causes problems when cfi_flash driver is compiled with -munaligned-access option: flash initialization hangs, probably due to data error. Since the structure is supposed to replicate the actual data layout in CFI Flash chips, the alignment issue can't be fixed in the structure. So, unaligned fields need using of explicit unaligned access macros. Applied to u-boot-cfi-flash/master. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] cosmetic: cfi_flash: delete a space after an unary operator
On 05/17/2013 07:50 AM, Masahiro Yamada wrote: Linux Kernel Documentation/CodingStyle says: Do not add a space after unary operators such as , *, ... Applied to u-boot-cfi-flash/master. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] cfi_flash: return NULL for invalid base address input
On 05/17/2013 07:50 AM, Masahiro Yamada wrote: When base address given was out of valid flash address ranges, flash_get_info() function returned the pointer to the last element of flash_info[i] array. This patch changes this function to return NULL pointer in such a case, which is more correct behaviour. The function flash_protect_default() calls flash_protect() immediately after flash_get_info() invocation. With this correction, flash_protect() function would be able to return soon, for NULL flash_info. Applied to u-boot-cfi-flash/master. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 3/4] env_mmc: allow negative CONFIG_ENV_OFFSET
S == Stephen Warren swar...@wwwdotorg.org writes:
S From: Stephen Warren swar...@nvidia.com
S A negative value of CONFIG_ENV_OFFSET is treated as a backwards offset
S from the end of the eMMC device/partition, rather than a forwards offset
S from the start.
S This is useful when a single board may be stuffed with different eMMC
S devices, each of which has a different capacity, and you always want the
S environment to be stored at the very end of the device (or eMMC boot
S partition for example).
S One example of this case is NVIDIA's Ventana reference board.
S Signed-off-by: Stephen Warren swar...@nvidia.com
S ---
S v2: Also update README to describe the change.
S ---
S README | 11 +++
S common/env_mmc.c | 12 ++--
S 2 files changed, 21 insertions(+), 2 deletions(-)
S diff --git a/README b/README
S index b9936ca..4335730 100644
S --- a/README
S +++ b/README
S @@ -3627,6 +3627,14 @@ but it can not erase, write this NOR flash by SRIO
or PCIE interface.
S These two #defines specify the offset and size of the environment
S area within the specified MMC device.
S + If offset is positive (the usual case), it is treated as relative to
S + the start of the MMC partition. If offset is negative, it is treated
S + as relative to the end of the MMC partition. This can be useful if
S + your board may be fitted with different MMC devices, which have
S + different sizes for the MMC partitions, and you always want the
S + environment placed at the very end of the partition, to leave the
S + maximum possible space before it, to store other data.
S +
S These two values must be aligned to an MMC sector boundary.
S - CONFIG_ENV_OFFSET_REDUND (optional):
S @@ -3636,6 +3644,9 @@ but it can not erase, write this NOR flash by SRIO or
PCIE interface.
S valid backup copy in case the other copy is corrupted, e.g. due
S to a power failure during a saveenv operation.
S + This value may also be positive or negative; this is handled in the
S + same way as CONFIG_ENV_OFFSET.
S +
S This value must also be aligned to an MMC sector boundary.
S - CONFIG_ENV_SIZE_REDUND (optional):
S diff --git a/common/env_mmc.c b/common/env_mmc.c
S index 9ca098f..5d3a769 100644
S --- a/common/env_mmc.c
S +++ b/common/env_mmc.c
S @@ -53,11 +53,19 @@ DECLARE_GLOBAL_DATA_PTR;
S __weak int mmc_get_env_addr(struct mmc *mmc, int copy, u32 *env_addr)
S {
S - *env_addr = CONFIG_ENV_OFFSET;
S + s64 offset;
S +
S + offset = CONFIG_ENV_OFFSET;
S #ifdef CONFIG_ENV_OFFSET_REDUND
S if (copy)
S - *env_addr = CONFIG_ENV_OFFSET_REDUND;
S + offset = CONFIG_ENV_OFFSET_REDUND;
S #endif
S +
S + if (offset 0)
S + offset += mmc-capacity;
S +
S + *env_addr = offset;
S +
This is quite a mix of data types (u32/s64/u64). Not directly related to
this patch, but it would imho be nicer to let env_mmc work directly with
block numbers instead of bytes, that way stuff would also work with 4GB
MMCs.
--
Bye, Peter Korsgaard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-cfi-flash/master
Hi Tom, please pull some CFI fixes: The following changes since commit 8bcb6f43e98ffc76e998349e0ec32a0e359160d4: Update MAINTAINERS file for sandbox (2013-05-17 17:04:39 -0400) are available in the git repository at: git://www.denx.de/git/u-boot-cfi-flash.git master for you to fetch changes up to 24c185cf58a5bef1e0401a0f7e70526d6d9078c7: cfi_flash: return NULL for invalid base address input (2013-05-23 09:48:45 +0200) Andrew Gabbasov (1): cfi_flash: Fix unaligned accesses to cfi_qry structure Masahiro Yamada (2): cosmetic: cfi_flash: delete a space after an unary operator cfi_flash: return NULL for invalid base address input drivers/mtd/cfi_flash.c | 23 +-- include/mtd/cfi_flash.h | 18 +++--- 2 files changed, 24 insertions(+), 17 deletions(-) Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v03 1/2] OMAP3+: introduce generic ABB support
On 05/22/2013 11:56 PM, Nishanth Menon wrote:
Hi Andrii,
We are almost there.. minor comments follow:
On 11:42-20130521, Andrii Tseglytskyi wrote:
[...]
diff --git a/arch/arm/cpu/armv7/omap5/abb.c b/arch/arm/cpu/armv7/omap5/abb.c
new file mode 100644
index 000..92470be
--- /dev/null
+++ b/arch/arm/cpu/armv7/omap5/abb.c
@@ -0,0 +1,67 @@
I might introduce this as part of patch #2... but no strong feelings
about it.
I suggest to introduce OMAP5 logic in this patch. Now series is divided
to 2 patches:
1. Control logic and needed definitions for all OMAPs - so after this
patch ABB can be used for OMAP3/4/5
2. ABB setup function call (in common code) and ABB registers add to
OMAP5 data structures, so ABB will be configured for OMAP5 only in this
case.
So, we have - 1. complete control logic introduction + 2. using
previously introduced logic.
I suggest to leave this as is.
[...]
+s8 abb_setup_ldovbb(u32 fuse, u32 ldovbb)
+{
+ u32 vset;
+
+ /*
+* ABB parameters must be properly fused
+* otherwise ABB should be disabled
+*/
+ vset = readl(fuse);
+ if (!(vset OMAP5_ABB_FUSE_ENABLE_MASK))
+ return -1;
+
+ /* prepare VSET value for LDOVBB mux register */
+ vset = OMAP5_ABB_FUSE_VSET_MASK;
+ vset = ffs(OMAP5_ABB_FUSE_VSET_MASK) - 1;
+ vset = ffs(OMAP5_ABB_LDOVBBMPU_VSET_OUT_MASK) - 1;
+ vset |= OMAP5_ABB_LDOVBBMPU_MUX_CTRL_MASK;
+
+ /* setup LDOVBB using fused value */
+ clrsetbits_le32(ldovbb, OMAP5_ABB_LDOVBBMPU_VSET_OUT_MASK, vset);
OMAP5_ABB_LDOVBBMPU_MUX_CTRL_MASK wont get set :(
[...]
Other than this, I have no further comments.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd: spi: winbond: add W25PXX support
Hi,
On Wed, May 22, 2013 at 6:31 AM, Kuo-Jung Su dant...@gmail.com wrote:
2013/5/22 Jagan Teki jagannadh.t...@gmail.com:
Hi,
I have a simple question like these parts are legacy flashes i guess.
Could you please tell me on which boards these were used?
It's used on Faraday A369 evaluation board.
However the u-boot source codes for A369 is still waiting for approval.
Here is the link to u-boot patchwork:
Ok, Thanks for your information.
http://patchwork.ozlabs.org/patch/242006/
Thanks,
Jagan.
On Fri, Apr 26, 2013 at 1:32 PM, Kuo-Jung Su dant...@gmail.com wrote:
From: Kuo-Jung Su dant...@faraday-tech.com
Signed-off-by: Kuo-Jung Su dant...@faraday-tech.com
---
drivers/mtd/spi/winbond.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/spi/winbond.c b/drivers/mtd/spi/winbond.c
index 2716209..2a27837 100644
--- a/drivers/mtd/spi/winbond.c
+++ b/drivers/mtd/spi/winbond.c
@@ -18,6 +18,21 @@ struct winbond_spi_flash_params {
static const struct winbond_spi_flash_params winbond_spi_flash_table[] = {
{
+ .id = 0x2014,
+ .nr_blocks = 16,
+ .name = W25P80,
W25P80 is an 8Mbit flash right, is this name W25P80 or W25P08?
ofcourse, I have seen the same on datasheet as well.
Thanks,
Jagan.
+ },
+ {
+ .id = 0x2015,
+ .nr_blocks = 32,
+ .name = W25P16,
+ },
+ {
+ .id = 0x2016,
+ .nr_blocks = 64,
+ .name = W25P32,
+ },
+ {
.id = 0x3013,
.nr_blocks = 8,
.name = W25X40,
@@ -104,7 +119,7 @@ struct spi_flash *spi_flash_probe_winbond(struct
spi_slave *spi, u8 *idcode)
}
flash-page_size = 256;
- flash-sector_size = 4096;
+ flash-sector_size = (idcode[1] == 0x20) ? 65536 : 4096;
flash-size = 4096 * 16 * params-nr_blocks;
return flash;
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
--
Best wishes,
Kuo-Jung Su
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] FW: [PATCH 5/6] spl: Make CONFIG_SPL_BUILD contain more functionality
-Original Message- From: Wood Scott-B07421 Sent: Wednesday, May 22, 2013 3:42 AM To: Zhang Ying-B40530 Cc: u-boot@lists.denx.de; aflem...@gmail.com; Xie Xiaobo-R63061; Zhang Ying-B40530; Ilya Yanok Subject: Re: [PATCH 5/6] spl: Make CONFIG_SPL_BUILD contain more functionality Please change the title and the rest of the changelog to describe what functionality you're adding and why. On 05/20/2013 01:07:27 AM, ying.zh...@freescale.com wrote: diff --git a/common/env_common.c b/common/env_common.c index 906b41f..8cb81e9 100644 --- a/common/env_common.c +++ b/common/env_common.c @@ -156,7 +156,6 @@ int set_default_vars(int nvars, char * const vars[]) H_NOCLEAR | H_INTERACTIVE, nvars, vars); } -#ifndef CONFIG_SPL_BUILD /* * Check if CRC is valid and (if yes) import the environment. * Note that buf may or may not be aligned. @@ -188,7 +187,6 @@ int env_import(const char *buf, int check) return 0; } -#endif This ifndef was introduced by Ilya Yanok in commit 7ac2fe2da21d292aeaf3af74e5c80de9ce9dab56. Ilya, what are the consequences of removing this? Is there some other symbol we can use here? -Scott [Zhang Ying] Ilya, Can you answer this question? Thanks. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] U-Boot code git versions problem
Hi All, Before 6 months, I have taken U-Boot code from git repository and the version details: VERSION = 2012 PATCHLEVEL = 10 SUBLEVEL = EXTRAVERSION = -rc1 Now I have taken the same version code from git. But both looks very different. What is the problem? or where I need to take the proper version code from git? The link: http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=summary -Thanks, Balaji N ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [HELP]: sf: winbond: add W25Q32
Hi Rajeshwari,
+ {
+ .id = 0x5014,
is this id code is correct? it seems like 0x4014
+ .nr_blocks = 128,
nr_blocks must be 16 i think?
+ .name = W25Q80,
+ },
};
Honestly the commit message itself is wrong, i guess.
Please comment.
Thanks,
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Building two different SPL for the same board?
ons 2013-05-22 klockan 11:26 -0400 skrev Tom Rini: If we can implement it cleanly, this isn't (at the 1000 meter view) all that much different than what we do on some PowerPC platforms today where everything must fit within a few kilobytes. Yes it is quite doable. The pieces I have done should be possible to fit without too much effort. The question is more if these kinds of board initialization only programs is seen as suitable for having in the u-boot tree. It's not really an SPL as it does not load anything, but it's 99.9% the same code as used in u-boot SPL. Regards Henrik ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot code git versions problem
Hi, On Thu, May 23, 2013 at 1:31 PM, Balaji N balajin...@gmail.com wrote: Hi All, Before 6 months, I have taken U-Boot code from git repository and the version details: I think this is the link you cloned 6 months back, http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=Makefile;h=e3a27c624939d10c584781582e83749378cfa594;hb=ee1f4caaa2a3f79d692155eec8a4c7289d60e106 VERSION = 2012 PATCHLEVEL = 10 SUBLEVEL = EXTRAVERSION = -rc1 Now I have taken the same version code from git. But both looks very different. What is the problem? or where I need to take the proper version code from git? The link: http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=summary This is an updated u-boot, it got upgraded from since you cloned VERSION = 2013 PATCHLEVEL = 04 SUBLEVEL = EXTRAVERSION = There is process for rc* and master upgrades, Please find the release information from http://www.denx.de/wiki/U-Boot/ReleaseCycle Thanks, Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/p2041rdb: fix SerDes clock display for RevC RevD boards
For now there are three boards supported:
Early -PB board used schematic RevC(x) and it's PCBA rev4.0.
Now -PB board used schematic RevD(x) and it's PCBA rev5.0.
Now -PC board used schematic RevD(x) and it's PCBA rev5.0.
All RevD(x) boards have same clock setting on bank1 and bank2,
RevC(x) board has different clock setting on two banks, PCBA can
be used to distinguish the boards, PCBA could be increased on
RevD(x) board in future, but RevC(x) board will never has PCBA 4.
Signed-off-by: Shaohui Xie shaohui@freescale.com
---
board/freescale/p2041rdb/p2041rdb.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/board/freescale/p2041rdb/p2041rdb.c
b/board/freescale/p2041rdb/p2041rdb.c
index a706a6d..8549639 100644
--- a/board/freescale/p2041rdb/p2041rdb.c
+++ b/board/freescale/p2041rdb/p2041rdb.c
@@ -84,7 +84,10 @@ int checkboard(void)
};
unsigned int clock = (sw (2 * i)) 3;
- printf(Bank%u=%sMhz , i+1, freq[i][clock]);
+ if ((i == 1) (CPLD_READ(pcba_ver) = 5))
+ printf(Bank%u=%sMhz , i+1, freq[i-1][clock]);
+ else
+ printf(Bank%u=%sMhz , i+1, freq[i][clock]);
}
puts(\n);
@@ -227,6 +230,16 @@ int misc_init_r(void)
'00' is unsupported\n);
else
actual[i] = freq[i][clock];
+
+ /*
+* RevD(x) board has a different clock setting with RevC(x)
+* board, CPLD on RevD(x) board has pcba_ver = 5. RevC(x)
+* board has pcba_ver = 4, it can be used to distinguish
+* the two boards.
+*/
+ if ((i == 1) (CPLD_READ(pcba_ver) = 5))
+ /* RevD(x) board bank2 frequency */
+ actual[i] = freq[i-1][clock];
}
for (i = 0; i NUM_SRDS_BANKS; i++) {
--
1.8.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Building two different SPL for the same board?
Hi Henrik, On Thu, 23 May 2013 10:53:39 +0200, Henrik Nordström hen...@henriknordstrom.net wrote: ons 2013-05-22 klockan 11:26 -0400 skrev Tom Rini: If we can implement it cleanly, this isn't (at the 1000 meter view) all that much different than what we do on some PowerPC platforms today where everything must fit within a few kilobytes. Yes it is quite doable. The pieces I have done should be possible to fit without too much effort. The question is more if these kinds of board initialization only programs is seen as suitable for having in the u-boot tree. It's not really an SPL as it does not load anything, but it's 99.9% the same code as used in u-boot SPL. My opinion is that such code fits in U-Boot quite well. After all, SPL too was that much shorter bit of code that was run before U-Boot because U-Boot is too large to load and run directly on this platform. Granted, SPL now tends to outgrow itself -- to the point that it becomes more of a 'lightweight U-Boot', as Falcon mode shows -- but obviously, there is a need for a very short code piece that can fit in e.g. a NAND access device's read buffer. Regards Henrik Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd: spi: winbond: add W25PXX support
2013/5/23 Jagan Teki jagannadh.t...@gmail.com:
Hi,
On Wed, May 22, 2013 at 6:31 AM, Kuo-Jung Su dant...@gmail.com wrote:
2013/5/22 Jagan Teki jagannadh.t...@gmail.com:
Hi,
I have a simple question like these parts are legacy flashes i guess.
Could you please tell me on which boards these were used?
It's used on Faraday A369 evaluation board.
However the u-boot source codes for A369 is still waiting for approval.
Here is the link to u-boot patchwork:
Ok, Thanks for your information.
http://patchwork.ozlabs.org/patch/242006/
Thanks,
Jagan.
On Fri, Apr 26, 2013 at 1:32 PM, Kuo-Jung Su dant...@gmail.com wrote:
From: Kuo-Jung Su dant...@faraday-tech.com
Signed-off-by: Kuo-Jung Su dant...@faraday-tech.com
---
drivers/mtd/spi/winbond.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/spi/winbond.c b/drivers/mtd/spi/winbond.c
index 2716209..2a27837 100644
--- a/drivers/mtd/spi/winbond.c
+++ b/drivers/mtd/spi/winbond.c
@@ -18,6 +18,21 @@ struct winbond_spi_flash_params {
static const struct winbond_spi_flash_params winbond_spi_flash_table[] = {
{
+ .id = 0x2014,
+ .nr_blocks = 16,
+ .name = W25P80,
W25P80 is an 8Mbit flash right, is this name W25P80 or W25P08?
ofcourse, I have seen the same on datasheet as well.
It's W25P80.
They are formally NexFlash NX25P80, NX25P16 and NX25P32.
I've google for the W25P08, it looks like that Windond did have
some legacy small SPI flash: W25P01, W25P02 .. W25P16.
I guess it's a different production line...
BTW I don't have these chips and corresponding datasheet, too.
Thanks,
Jagan.
+ },
+ {
+ .id = 0x2015,
+ .nr_blocks = 32,
+ .name = W25P16,
+ },
+ {
+ .id = 0x2016,
+ .nr_blocks = 64,
+ .name = W25P32,
+ },
+ {
.id = 0x3013,
.nr_blocks = 8,
.name = W25X40,
@@ -104,7 +119,7 @@ struct spi_flash *spi_flash_probe_winbond(struct
spi_slave *spi, u8 *idcode)
}
flash-page_size = 256;
- flash-sector_size = 4096;
+ flash-sector_size = (idcode[1] == 0x20) ? 65536 : 4096;
flash-size = 4096 * 16 * params-nr_blocks;
return flash;
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
--
Best wishes,
Kuo-Jung Su
--
Best wishes,
Kuo-Jung Su
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/4] ARM: vexpress: add support for more core tiles
Hi Andre, On Tue, 9 Apr 2013 14:20:29 +0200, Andre Przywara andre.przyw...@linaro.org wrote: This series adds support for the Cortex-A5 and Cortex-A15 core tiles for the ARM Versatile Express boards. The first two patches have been around for about one and a half years in the Linaro tree now, they refactor the A9 support and add support for A5. I kept the original commits and authors, just resolved some trivial merge conflicts and checkpatch complaints. As per request, I merged the first two original patches into one for better readability. Patch 3/4 adds support for the A15 core tile, this is actually the same as the A5 for now, but will be extended later. Patch 4/4 enables bootz and hush parser for all boards, just for convenience. Changes: v3: - drop now unneeded default prompt definition in patch 4 v2: - merge patch 1/5 and 2/5 as per Albert's request - add support for raw initrd for full bootz experience Regards, Andre. -- Andre Przywara Linaro Virtualization Team Whole series applied to u-boot-arm/master, thanks! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/1] ARM: Add Seagate GoFlex Home support
Hi Suriyan, On Thu, 11 Apr 2013 10:17:25 -0700, Suriyan Ramasami suriya...@gmail.com wrote: Add Seagate GoFlex Home support Start with dockstar configuration define support for RTC, DATE, SATA and EXT4FS Signed-off-by: Suriyan Ramasami suriya...@gmail.com --- Changes in v4: Remove board/Seagate/goflexhome/goflexhome.h from patch and merge it in configs/include/goflexhome.h Snip commit messages and move comments Coding style changes - Blank line between decl and code - Dont mix declarations and code Changes in v3: Squash the board support in one file Remove goflexhomemenu.c from this patch as its not board related Changes in v2: Coding style changes MAINTAINERS |4 + board/Seagate/goflexhome/Makefile | 51 + board/Seagate/goflexhome/goflexhome.c | 189 + board/Seagate/goflexhome/kwbimage.cfg | 168 + boards.cfg|1 + include/configs/goflexhome.h | 151 ++ 6 files changed, 564 insertions(+), 0 deletions(-) create mode 100644 board/Seagate/goflexhome/Makefile create mode 100644 board/Seagate/goflexhome/goflexhome.c create mode 100644 board/Seagate/goflexhome/kwbimage.cfg create mode 100644 include/configs/goflexhome.h diff --git a/MAINTAINERS b/MAINTAINERS index 1614b91..6292a58 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -847,6 +847,10 @@ Sricharan R r.sricha...@ti.com omap4_sdp4430 ARM ARMV7 (OMAP4xx SoC) omap5_evm ARM ARMV7 (OMAP5xx Soc) +Suriyan Ramasami suriya...@gmail.com + + goflexhome ARM926EJS (Kirkwood SoC) + Thierry Reding thierry.red...@avionic-design.de plutux Tegra20 (ARM7 A9 Dual Core) diff --git a/board/Seagate/goflexhome/Makefile b/board/Seagate/goflexhome/Makefile new file mode 100644 index 000..9948fe2 --- /dev/null +++ b/board/Seagate/goflexhome/Makefile @@ -0,0 +1,51 @@ +# +# Copyright (C) 2013 Suriyan Ramasami suriya...@gmail.com +# +# Based on dockstar/Makefile originally written by +# Copyright (C) 2010 Eric C. Cooper e...@cmu.edu +# +# Based on sheevaplug/Makefile originally written by +# Prafulla Wadaskar prafu...@marvell.com +# (C) Copyright 2009 +# Marvell Semiconductor www.marvell.com +# +# See file CREDITS for list of people who contributed to this +# project. +# +# 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., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301 USA +# + +include $(TOPDIR)/config.mk + +LIB = $(obj)lib$(BOARD).o + +COBJS:= goflexhome.o + +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) +SOBJS:= $(addprefix $(obj),$(SOBJS)) + +$(LIB): $(obj).depend $(OBJS) $(SOBJS) + $(call cmd_link_o_target, $(OBJS) $(SOBJS)) + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/Seagate/goflexhome/goflexhome.c b/board/Seagate/goflexhome/goflexhome.c new file mode 100644 index 000..17c1905 --- /dev/null +++ b/board/Seagate/goflexhome/goflexhome.c @@ -0,0 +1,189 @@ +/* + * Copyright (C) 2013 Suriyan Ramasami suriya...@gmail.com + * + * Based on dockstar.c originally written by + * Copyright (C) 2010 Eric C. Cooper e...@cmu.edu + * + * Based on sheevaplug.c originally written by + * Prafulla Wadaskar prafu...@marvell.com + * (C) Copyright 2009 + * Marvell Semiconductor www.marvell.com + * + * See file CREDITS for list of people who contributed to this + * project. + * + * 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
Re: [U-Boot] [PATCH] arm: Enable -ffunction-sections / -fdata-sections / --gc-sections
Hi Tom, On Thu, 25 Apr 2013 13:40:22 -0400, Tom Rini tr...@ti.com wrote: While other architectures have enabled these gcc / ld options for some time on U-Boot itself, ARM has only been doing this on SPL. Enable this on full U-Boot as well now. I expect this was tested on various targets? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd: spi: winbond: add W25PXX support
On Thu, May 23, 2013 at 3:24 PM, Kuo-Jung Su dant...@gmail.com wrote:
2013/5/23 Jagan Teki jagannadh.t...@gmail.com:
Hi,
On Wed, May 22, 2013 at 6:31 AM, Kuo-Jung Su dant...@gmail.com wrote:
2013/5/22 Jagan Teki jagannadh.t...@gmail.com:
Hi,
I have a simple question like these parts are legacy flashes i guess.
Could you please tell me on which boards these were used?
It's used on Faraday A369 evaluation board.
However the u-boot source codes for A369 is still waiting for approval.
Here is the link to u-boot patchwork:
Ok, Thanks for your information.
http://patchwork.ozlabs.org/patch/242006/
Thanks,
Jagan.
On Fri, Apr 26, 2013 at 1:32 PM, Kuo-Jung Su dant...@gmail.com wrote:
From: Kuo-Jung Su dant...@faraday-tech.com
Signed-off-by: Kuo-Jung Su dant...@faraday-tech.com
---
drivers/mtd/spi/winbond.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/spi/winbond.c b/drivers/mtd/spi/winbond.c
index 2716209..2a27837 100644
--- a/drivers/mtd/spi/winbond.c
+++ b/drivers/mtd/spi/winbond.c
@@ -18,6 +18,21 @@ struct winbond_spi_flash_params {
static const struct winbond_spi_flash_params winbond_spi_flash_table[] =
{
{
+ .id = 0x2014,
+ .nr_blocks = 16,
+ .name = W25P80,
W25P80 is an 8Mbit flash right, is this name W25P80 or W25P08?
ofcourse, I have seen the same on datasheet as well.
It's W25P80.
They are formally NexFlash NX25P80, NX25P16 and NX25P32.
I've google for the W25P08, it looks like that Windond did have
some legacy small SPI flash: W25P01, W25P02 .. W25P16.
I guess it's a different production line...
BTW I don't have these chips and corresponding datasheet, too.
Ok.
Can you use the commit msg header as
sf: winbond:
Which is used for winbond mtd driver since from long, of-course not a
big deal and
also mentioned atleast single line message on body.
Simple recommendation here:.
Add support for Winbond's W25PXX SPI flash.
These devices is used on Faraday A369 evaluation board
Thanks,
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] ARMv7: Add HYP mode switching support
Hi Andre, On Mon, 6 May 2013 15:17:44 +0200, Andre Przywara andre.przyw...@linaro.org wrote: (for GIT URL and Changelog see below) ARM CPUs with the virtualization extension have a new mode called HYP mode, which allows hypervisors to safely control and monitor guests. The current hypervisor (KVM and Xen) implementations require the kernel to be entered in that HYP mode. This patch series introduces a configuration variable CONFIG_ARMV7_VIRT which enables code to switch all cores into HYP mode. This is done automatically during execution of the bootm command (but could also be done earlier - U-Boot runs fine in HYP mode without MMU usage). The process of switching into HYP mode requires the CPU to be in non-secure state, which requires the GIC to be programmed properly first. Explanations about the details are in the commit messages of the respective patches. The code aims to be as generic as possible, though currently it has only been tested on the Versatile Express TC-2 board. The last patch thus enables the feature for that board and relies on the Versatile Express updates patches sent out lately[1]. For convenience there is now a GIT tree which you can pull these and the Versatile Express patches from (hypmode branch): git://git.linaro.org/people/aprzywara/u-boot.git Changes from the RFC version I sent out before: * not a dedicated command anymore, code run by bootm friends * protecting code with #ifdefs to avoid unnecessary inclusion and accidental crashing (when accessing restricted registers) * moving prototypes to header file to meet checkpatch recommendation * adding comment as proposed by Christoffer Please review and comment! Contributions and comments to support other boards are welcome. I know... virtually... nothing in virtualization, so please excuse any silly questions below: - what happens if a target with these patches actually starts with HYP already enabled by some secure ROM boot code? - I thought that once HYP is enabled, then all secure functionalities are performed by some monitor code invoked through a sw exception. Is the swi handler this monitor code? If it is, then is this monitor crippled, and what will happen if the bootm code needs to use some secure functionality? Andre. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] ARM: add secure monitor handler to switch to non-secure state
Hi Andre, On Mon, 6 May 2013 15:17:45 +0200, Andre Przywara andre.przyw...@linaro.org wrote: A prerequisite for using virtualization is to be in HYP mode, which requires the CPU to be in non-secure state. Introduce a monitor handler routine which switches the CPU to non-secure state by setting the NS and associated bits. According to the ARM ARM this should not be done in SVC mode, so we ARM *TRM*, I suspect. Also, as there are a lot of ARM TRMs, if there is a more precise reference, please provide it. have to setup a SMC handler for this. We reuse the current vector table for this and make sure that we only access the MVBAR register if the CPU supports the security extension and only if we configured the board to use it, since boards entering u-boot already in non-secure mode would crash on accessing MVBAR otherwise. Signed-off-by: Andre Przywara andre.przyw...@linaro.org --- arch/arm/cpu/armv7/start.S | 31 --- 1 file changed, 28 insertions(+), 3 deletions(-) diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S index e9e57e6..da48b36 100644 --- a/arch/arm/cpu/armv7/start.S +++ b/arch/arm/cpu/armv7/start.S @@ -155,6 +155,13 @@ reset: /* Set vector address in CP15 VBAR register */ ldr r0, =_start mcr p15, 0, r0, c12, c0, 0 @Set VBAR + +#ifdef CONFIG_ARMV7_VIRT + mrc p15, 0, r1, c0, c1, 1 @ check for security extension + andsr1, r1, #0x30 + mcrne p15, 0, r0, c12, c0, 1 @ Set secure monitor MVBAR +#endif + #endif /* the mask ROM code should have PLL and others stable */ @@ -257,6 +264,12 @@ ENTRY(c_runtime_cpu_setup) ldr r0, =_start mcr p15, 0, r0, c12, c0, 0 @Set VBAR +#ifdef CONFIG_ARMV7_VIRT + mrc p15, 0, r1, c0, c1, 1 @ check for security extension + andsr1, r1, #0x30 + mcrne p15, 0, r0, c12, c0, 1 @ Set secure monitor MVBAR +#endif + bx lr ENDPROC(c_runtime_cpu_setup) @@ -490,11 +503,23 @@ undefined_instruction: bad_save_user_regs bl do_undefined_instruction +/* + * software interrupt aka. secure monitor handler + * This is executed on a smc instruction, we use a smc #0 to switch + * to non-secure state + */ .align 5 software_interrupt: - get_bad_stack_swi - bad_save_user_regs - bl do_software_interrupt + mrc p15, 0, r1, c1, c1, 0 @ read SCR + bic r1, r1, #0x07f + orr r1, r1, #0x31 @ enable NS, AW, FW + + mrc p15, 0, r0, c12, c0, 0 @ save secure copy of VBAR + mcr p15, 0, r1, c1, c1, 0 @ write SCR, switch to non-sec + isb + mcr p15, 0, r0, c12, c0, 0 @ write non-secure copy of VBAR + + movspc, lr .align 5 prefetch_abort: Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/p2041rdb: fix SerDes clock display for RevC RevD boards
For now there are three boards supported:
Early -PB board used schematic RevC(x) and it's PCBA rev4.0.
Now -PB board used schematic RevD(x) and it's PCBA rev5.0.
Now -PC board used schematic RevD(x) and it's PCBA rev5.0.
All RevD(x) boards have same clock setting on bank1 and bank2,
RevC(x) board has different clock setting on two banks, PCBA can
be used to distinguish the boards, PCBA could be increased on
RevD(x) board in future, but RevC(x) board will never has PCBA 4.
Signed-off-by: Shaohui Xie shaohui@freescale.com
---
board/freescale/p2041rdb/p2041rdb.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/board/freescale/p2041rdb/p2041rdb.c
b/board/freescale/p2041rdb/p2041rdb.c
index a706a6d..8549639 100644
--- a/board/freescale/p2041rdb/p2041rdb.c
+++ b/board/freescale/p2041rdb/p2041rdb.c
@@ -84,7 +84,10 @@ int checkboard(void)
};
unsigned int clock = (sw (2 * i)) 3;
- printf(Bank%u=%sMhz , i+1, freq[i][clock]);
+ if ((i == 1) (CPLD_READ(pcba_ver) = 5))
+ printf(Bank%u=%sMhz , i+1, freq[i-1][clock]);
+ else
+ printf(Bank%u=%sMhz , i+1, freq[i][clock]);
}
puts(\n);
@@ -227,6 +230,16 @@ int misc_init_r(void)
'00' is unsupported\n);
else
actual[i] = freq[i][clock];
+
+ /*
+* RevD(x) board has a different clock setting with RevC(x)
+* board, CPLD on RevD(x) board has pcba_ver = 5. RevC(x)
+* board has pcba_ver = 4, it can be used to distinguish
+* the two boards.
+*/
+ if ((i == 1) (CPLD_READ(pcba_ver) = 5))
+ /* RevD(x) board bank2 frequency */
+ actual[i] = freq[i-1][clock];
}
for (i = 0; i NUM_SRDS_BANKS; i++) {
--
1.8.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] why patch work cannot catch my patch
I can see it at link:
http://lists.denx.de/pipermail/u-boot/2013-May/154984.html
while the patch work did not catch it, what could be wrong?
Thanks!
Best Regards,
Shaohui Xie
-Original Message-
From: Xie Shaohui-B21989
Sent: Thursday, May 23, 2013 4:28 PM
To: u-boot@lists.denx.de; Fleming Andy-AFLEMING
Cc: Xie Shaohui-B21989
Subject: [PATCH] powerpc/p2041rdb: fix SerDes clock display for RevC
RevD boards
For now there are three boards supported:
Early -PB board used schematic RevC(x) and it's PCBA rev4.0.
Now -PB board used schematic RevD(x) and it's PCBA rev5.0.
Now -PC board used schematic RevD(x) and it's PCBA rev5.0.
All RevD(x) boards have same clock setting on bank1 and bank2,
RevC(x) board has different clock setting on two banks, PCBA can be used
to distinguish the boards, PCBA could be increased on
RevD(x) board in future, but RevC(x) board will never has PCBA 4.
Signed-off-by: Shaohui Xie shaohui@freescale.com
---
board/freescale/p2041rdb/p2041rdb.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/board/freescale/p2041rdb/p2041rdb.c
b/board/freescale/p2041rdb/p2041rdb.c
index a706a6d..8549639 100644
--- a/board/freescale/p2041rdb/p2041rdb.c
+++ b/board/freescale/p2041rdb/p2041rdb.c
@@ -84,7 +84,10 @@ int checkboard(void)
};
unsigned int clock = (sw (2 * i)) 3;
- printf(Bank%u=%sMhz , i+1, freq[i][clock]);
+ if ((i == 1) (CPLD_READ(pcba_ver) = 5))
+ printf(Bank%u=%sMhz , i+1, freq[i-1][clock]);
+ else
+ printf(Bank%u=%sMhz , i+1, freq[i][clock]);
}
puts(\n);
@@ -227,6 +230,16 @@ int misc_init_r(void)
'00' is unsupported\n);
else
actual[i] = freq[i][clock];
+
+ /*
+ * RevD(x) board has a different clock setting with RevC(x)
+ * board, CPLD on RevD(x) board has pcba_ver = 5. RevC(x)
+ * board has pcba_ver = 4, it can be used to distinguish
+ * the two boards.
+ */
+ if ((i == 1) (CPLD_READ(pcba_ver) = 5))
+ /* RevD(x) board bank2 frequency */
+ actual[i] = freq[i-1][clock];
}
for (i = 0; i NUM_SRDS_BANKS; i++) {
--
1.8.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] powerpc/mpc8xxx failed to compile: operand out of range
Hi all, I have an issue when I compile U-Boot for my target machine (P1022DS, 36-bit). Here is the error message: release.S: Assembler messages: release.S:154: Error: operand out of range (0xf144 is not between 0x and 0x) release.S:286: Error: operand out of range (0xf144 is not between 0x and 0x) release.S:311: Error: operand out of range (0xf140 is not between 0x and 0x) (release.S is located to arch/powerpc/cpu/mpc85xx/release.S) And here is the code for the first error (line 150): #define toreset(x) (x - __secondary_start_page + 0xf000) /* get our PIR to figure out our table entry */ lis r3,toreset(__spin_table_addr)@h ori r3,r3,toreset(__spin_table_addr)@l I don't really know why it doesn't work, but I think that ori is inappropried, the immediate value must be a 16-bit value. I use GCC 4.7.3, compiled in x86_64 for target powerpc-none-linux-gnuspe. My U-Boot come from the repository, but older versions fail too. Thanks for your help, Jérôme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 06/10] MIPS: qemu-malta: add PCI support
Hi Daniel,
Thank you for the review!
2013/5/22 Gabor Juhos juh...@openwrt.org:
Qemu emulates the Galileo GT64120 System Controller
which provides a CPU bus to PCI bus bridge.
The patch adds driver for this bridge and enables
PCI support for the emulated Malta board.
Signed-off-by: Gabor Juhos juh...@openwrt.org
Cc: Daniel Schwierzeck daniel.schwierz...@googlemail.com
ELDK-5.3 shows some warnings:
pci_indirect.c: In function 'indirect_read_config_byte':
pci_indirect.c:101:1: warning: implicit declaration of function
'out_le32' [-Wimplicit-function-declaration]
pci_indirect.c:101:1: warning: implicit declaration of function 'in_8'
[-Wimplicit-function-declaration]
pci_indirect.c: In function 'indirect_read_config_word':
pci_indirect.c:102:1: warning: implicit declaration of function
'in_le16' [-Wimplicit-function-declaration]
pci_indirect.c: In function 'indirect_read_config_dword':
pci_indirect.c:103:1: warning: implicit declaration of function
'in_le32' [-Wimplicit-function-declaration]
pci_indirect.c: In function 'indirect_write_config_byte':
pci_indirect.c:109:1: warning: implicit declaration of function
'out_8' [-Wimplicit-function-declaration]
pci_indirect.c: In function 'indirect_write_config_word':
pci_indirect.c:110:1: warning: implicit declaration of function
'out_le16' [-Wimplicit-function-declaration]
Hm, you are right. My toolchain also shows the warning but I did not notice
those because I forgot to redirect stderr when I have generated the build logs.
The pci_indirect.c file is always compiled when CONFIG_PCI is defined although
it is not needed at all for Malta PCI support.
The issue can be resolved on a few different ways:
1. Extend the '#if !defined(__I386__)' directive in pci_indirect.c with a new
' !defined(__MIPS__)' condition. This would be the simplest solution but the
drawback of this is that indirect support will not be usable on any MIPS board.
2. Introduce a new 'CONFIG_PCI_INDIRECT_BRIDGE' option and only compile the
pci_indirect.c file if this option is present. Probably this is the best
solution however the new symbol should be added into the configuration of the
affected boards.
3. Introduce a new 'CONFIG_PCI_NO_INDIRECT_BRIDGE' option and use an '#ifndef
CONFIG_PCI_NO_INDIRECT_BRIDGE' directive in pci_indirect.c.
I'm unsure about which approach is preferred.
pci_gt64120.c: In function 'gt64120_pci_init':
pci_gt64120.c:178:1: warning: control reaches end of non-void function
[-Wreturn-type]
snip
+int gt64120_pci_init(void *regs, unsigned long sys_bus, unsigned long
sys_phys,
+unsigned long sys_size, unsigned long mem_bus,
+unsigned long mem_phys, unsigned long mem_size,
+unsigned long io_bus, unsigned long io_phys,
+unsigned long io_size)
+{
+ static struct gt64120_pci_controller global_gt;
+ struct gt64120_pci_controller *gt;
+ struct pci_controller *hose;
+
+ gt = global_gt;
+ gt-regs = regs;
+
+ hose = gt-hose;
+
+ hose-first_busno = 0;
+ hose-last_busno = 0;
+
+ /* System memory space */
+ pci_set_region(hose-regions[0], sys_bus, sys_phys, sys_size,
+ PCI_REGION_MEM | PCI_REGION_SYS_MEMORY);
+
+ /* PCI memory space */
+ pci_set_region(hose-regions[1], mem_bus, mem_phys, mem_size,
+ PCI_REGION_MEM);
+
+ /* PCI I/O space */
+ pci_set_region(hose-regions[2], io_bus, io_phys, io_size,
+ PCI_REGION_IO);
+
+ hose-region_count = 3;
+
+ pci_set_ops(hose,
+ pci_hose_read_config_byte_via_dword,
+ pci_hose_read_config_word_via_dword,
+ gt_read_config_dword,
+ pci_hose_write_config_byte_via_dword,
+ pci_hose_write_config_word_via_dword,
+ gt_write_config_dword);
+
+ pci_register_hose(hose);
+ hose-last_busno = pci_hose_scan(hose);
missing return keyword
Correct. However the function never fails, so I will convert it to void instead
of adding a 'return 0;' line.
+}
-Gabor
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] ARM: add secure monitor handler to switch to non-secure state
Hi Marc, On Thu, 23 May 2013 13:14:01 +0100, Marc Zyngier marc.zyng...@arm.com wrote: On 23/05/13 11:52, Albert ARIBAUD wrote: Hi Andre, On Mon, 6 May 2013 15:17:45 +0200, Andre Przywara andre.przyw...@linaro.org wrote: A prerequisite for using virtualization is to be in HYP mode, which requires the CPU to be in non-secure state. Introduce a monitor handler routine which switches the CPU to non-secure state by setting the NS and associated bits. According to the ARM ARM this should not be done in SVC mode, so we ARM *TRM*, I suspect. Also, as there are a lot of ARM TRMs, if there is a more precise reference, please provide it. I believe the ARM ARM (as in ARM Architecture Reference Manual) is the correct document here. http://infocenter.arm.com/help/topic/com.arm.doc.ddi0406c/index.html Well -- if you form the acronym, you do end with 'A R M' indeed, but this is quite unfortunate, as 'ARM ARM' is redundant (as the acronym's A already has ARM in it), confusion (as 'ARM' already bears a quite established meaning) and ambiguous (as there are actually several documents with the title of 'ARMvXXX Reference Manual' and which would end up with the same acronym). So if you don't want to use 'TRM' (which I can understand), then at least please replace 'ARM ARM' with 'ARMv7-AR Reference Manual'. Stating the DDI* reference is not a must, unless you want to specify a given revision (but then I suggest adding it after 'Manual' too). Cheers, M. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] ARM: add secure monitor handler to switch to non-secure state
On Thu, 23 May 2013 14:34:38 +0200, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi Marc, So if you don't want to use 'TRM' (which I can understand), then at least please replace 'ARM ARM' with 'ARMv7-AR Reference Manual'. Stating the DDI* reference is not a must, unless you want to specify a given revision (but then I suggest adding it after 'Manual' too). My bad: this last paragraph was actually directed at Andrew, not Marc. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] ARM: add secure monitor handler to switch to non-secure state
On Thu, 23 May 2013 14:40:09 +0200, Albert ARIBAUD albert.u.b...@aribaud.net wrote: My bad: this last paragraph was actually directed at Andrew Make that Andre. Apologies, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v03 1/2] OMAP3+: introduce generic ABB support
On 10:39-20130523, Andrii Tseglytskyi wrote:
On 05/22/2013 11:56 PM, Nishanth Menon wrote:
Hi Andrii,
We are almost there.. minor comments follow:
On 11:42-20130521, Andrii Tseglytskyi wrote:
[...]
diff --git a/arch/arm/cpu/armv7/omap5/abb.c b/arch/arm/cpu/armv7/omap5/abb.c
new file mode 100644
index 000..92470be
--- /dev/null
+++ b/arch/arm/cpu/armv7/omap5/abb.c
@@ -0,0 +1,67 @@
I might introduce this as part of patch #2... but no strong feelings
about it.
[...]
+s8 abb_setup_ldovbb(u32 fuse, u32 ldovbb)
+{
+ u32 vset;
+
+ /*
+* ABB parameters must be properly fused
+* otherwise ABB should be disabled
+*/
+ vset = readl(fuse);
+ if (!(vset OMAP5_ABB_FUSE_ENABLE_MASK))
+ return -1;
+
+ /* prepare VSET value for LDOVBB mux register */
+ vset = OMAP5_ABB_FUSE_VSET_MASK;
+ vset = ffs(OMAP5_ABB_FUSE_VSET_MASK) - 1;
+ vset = ffs(OMAP5_ABB_LDOVBBMPU_VSET_OUT_MASK) - 1;
+ vset |= OMAP5_ABB_LDOVBBMPU_MUX_CTRL_MASK;
+
+ /* setup LDOVBB using fused value */
+ clrsetbits_le32(ldovbb, OMAP5_ABB_LDOVBBMPU_VSET_OUT_MASK, vset);
OMAP5_ABB_LDOVBBMPU_MUX_CTRL_MASK wont get set :(
Sorry didn't get... I have
vset |= *OMAP5_ABB_LDOVBBMPU_MUX_CTRL_MASK*; -- set here
clrsetbits_le32(ldovbb, OMAP5_ABB_LDOVBBMPU_VSET_OUT_MASK, vset);
define clrsetbits(type, addr, clear, set) \
out_##type((addr), (in_##type(addr) ~(clear)) | (set))
Arrgh.. I missed this :(. I had confused this with *rmw (read modify
write) in Linux which would do set = mask;
My Bad. the patch is doing the right thing.
In short,
Acked-by: Nishanth Menon n...@ti.com
--
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] ARM: add secure monitor handler to switch to non-secure state
On 23 May 2013 13:34, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Well -- if you form the acronym, you do end with 'A R M' indeed, but this is quite unfortunate, as 'ARM ARM' is redundant (as the acronym's A already has ARM in it), confusion (as 'ARM' already bears a quite established meaning) and ambiguous (as there are actually several documents with the title of 'ARMvXXX Reference Manual' and which would end up with the same acronym). ARM ARM is the standard abbreviated way of referring to the ARM Architecture Reference Manual (and as you can see it's not a redundant acronym, since the A doesn't stand for ARM). A TRM (Technical Reference Manual) is a completely different document type, describing a specific processor. Andre is correct that the restriction in question is architectural (and thus described in the ARM ARM), not implementation specific (which would be what you'd find in a TRM). So if you don't want to use 'TRM' (which I can understand), then at least please replace 'ARM ARM' with 'ARMv7-AR Reference Manual'. Stating the DDI* reference is not a must, unless you want to specify a given revision (but then I suggest adding it after 'Manual' too). ARMv7-AR Reference Manual is confusing, because you've dropped the Architecture bit. Since this is only a git comment, I'd suggest ARM architecture reference manual as both clear for non-ARM people and sufficiently unambiguous, or ARMv7-AR Architecture Reference Manual if you want to be a bit more formal about it. thanks -- PMM ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] MMC: DWMMC: Fix FIFO_DEPTH calculation
Current DWMMC driver used to give FIFO underrun/overrun error every 3rd time
for mmc rescan command.
In current code FIFO_DEPTH is getting calculated after reading the FIFOTH
register and extracting the RX_WMARK bits from it i.e (RX_WMARK = FIFO_DEPTH/2
-1).
Instead of storing the correct value, we were recalculating the FIFO_DEPT each
time which is not correct.
Signed-off-by: Hatim Ali hatim...@samsung.com
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
drivers/mmc/dw_mmc.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
index 4070d4e..be590a4 100644
--- a/drivers/mmc/dw_mmc.c
+++ b/drivers/mmc/dw_mmc.c
@@ -332,11 +332,13 @@ static int dwmci_init(struct mmc *mmc)
dwmci_writel(host, DWMCI_BMOD, 1);
fifo_size = dwmci_readl(host, DWMCI_FIFOTH);
- if (host-fifoth_val)
+ if (host-fifoth_val) {
fifoth_val = host-fifoth_val;
- else
+ } else {
fifoth_val = MSIZE(0x2) | RX_WMARK(fifo_size/2 -1) |
TX_WMARK(fifo_size/2);
+ host-fifoth_val = fifoth_val;
+ }
dwmci_writel(host, DWMCI_FIFOTH, fifoth_val);
dwmci_writel(host, DWMCI_CLKENA, 0);
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 06/10] MIPS: qemu-malta: add PCI support
Hi Tom, Wolfgang, we do not have a dedicated PCI custodian so could you comment this please? Thanks. 2013/5/23 Gabor Juhos juh...@openwrt.org: Hi Daniel, Thank you for the review! 2013/5/22 Gabor Juhos juh...@openwrt.org: Qemu emulates the Galileo GT64120 System Controller which provides a CPU bus to PCI bus bridge. The patch adds driver for this bridge and enables PCI support for the emulated Malta board. Signed-off-by: Gabor Juhos juh...@openwrt.org Cc: Daniel Schwierzeck daniel.schwierz...@googlemail.com ELDK-5.3 shows some warnings: pci_indirect.c: In function 'indirect_read_config_byte': pci_indirect.c:101:1: warning: implicit declaration of function 'out_le32' [-Wimplicit-function-declaration] pci_indirect.c:101:1: warning: implicit declaration of function 'in_8' [-Wimplicit-function-declaration] pci_indirect.c: In function 'indirect_read_config_word': pci_indirect.c:102:1: warning: implicit declaration of function 'in_le16' [-Wimplicit-function-declaration] pci_indirect.c: In function 'indirect_read_config_dword': pci_indirect.c:103:1: warning: implicit declaration of function 'in_le32' [-Wimplicit-function-declaration] pci_indirect.c: In function 'indirect_write_config_byte': pci_indirect.c:109:1: warning: implicit declaration of function 'out_8' [-Wimplicit-function-declaration] pci_indirect.c: In function 'indirect_write_config_word': pci_indirect.c:110:1: warning: implicit declaration of function 'out_le16' [-Wimplicit-function-declaration] Hm, you are right. My toolchain also shows the warning but I did not notice those because I forgot to redirect stderr when I have generated the build logs. The pci_indirect.c file is always compiled when CONFIG_PCI is defined although it is not needed at all for Malta PCI support. The issue can be resolved on a few different ways: 1. Extend the '#if !defined(__I386__)' directive in pci_indirect.c with a new ' !defined(__MIPS__)' condition. This would be the simplest solution but the drawback of this is that indirect support will not be usable on any MIPS board. 2. Introduce a new 'CONFIG_PCI_INDIRECT_BRIDGE' option and only compile the pci_indirect.c file if this option is present. Probably this is the best solution however the new symbol should be added into the configuration of the affected boards. 3. Introduce a new 'CONFIG_PCI_NO_INDIRECT_BRIDGE' option and use an '#ifndef CONFIG_PCI_NO_INDIRECT_BRIDGE' directive in pci_indirect.c. I'm unsure about which approach is preferred. I favor the second option. -- Best regards, Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] ARM: add secure monitor handler to switch to non-secure state
Hi Peter, (sorry for the duplicate; first reply sent was missing recipients, and I had a fix to do anyway) On Thu, 23 May 2013 14:00:17 +0100, Peter Maydell peter.mayd...@linaro.org wrote: On 23 May 2013 13:34, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Well -- if you form the acronym, you do end with 'A R M' indeed, but this is quite unfortunate, as 'ARM ARM' is redundant (as the acronym's A already has ARM in it), confusion (as 'ARM' already bears a quite established meaning) and ambiguous (as there are actually several documents with the title of 'ARMvXXX Reference Manual' and which would end up with the same acronym). ARM ARM is the standard abbreviated way of referring to the ARM Architecture Reference Manual (and as you can see it's not a redundant acronym, since the A doesn't stand for ARM). Before answering about the double 'ARM', I did google for possible meanings of the acronym 'ARM' and did not find any indication of it meaning 'Architecture Reference Manual' except on www.all-acronyms.com, which is completely foreign to the embedded world and where the definition is not backed by any substantial source. OTOH, the ARM Information Center does not use the acronym ARM to mean 'Architecture Reference Manual', nor does the Glossary section of ARM documents I've read so far - including the ARM Glossary (AEG0014E), which lists quite a lot of 'ARM something' but no 'ARM' alone, except in the preamble phrase: 'Where the term ARM is used it means “ARM or any of its subsidiaries as appropriate”'. Of course, I might have missed it, so any actual pointer to the definition is heartily welcome. A TRM (Technical Reference Manual) is a completely different document type, describing a specific processor. Andre is correct that the restriction in question is architectural (and thus described in the ARM ARM), not implementation specific (which would be what you'd find in a TRM). You are correct that here the document is not a TRM. So if you don't want to use 'TRM' (which I can understand), then at least please replace 'ARM ARM' with 'ARMv7-AR Reference Manual'. Stating the DDI* reference is not a must, unless you want to specify a given revision (but then I suggest adding it after 'Manual' too). ARMv7-AR Reference Manual is confusing, because you've dropped the Architecture bit. That drop was involuntary. Since this is only a git comment, I'd suggest ARM architecture reference manual as both clear for non-ARM people and sufficiently unambiguous, or ARMv7-AR Architecture Reference Manual if you want to be a bit more formal about it. Since a git comment is there for a reason, which includes helping its readers understand the commit, I consider ARMv7-AR Reference Manual to help them much more than 'ARM ARM', as it points them unambiguously to the document by stating the exact title under which it is listed in the ARM information center, but I am ok with 'ARMv7-AR Architecture Reference Manual' as this how its title goes. thanks -- PMM Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] ARM: add secure monitor handler to switch to non-secure state
On Thu, 23 May 2013 16:08:35 +0200, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Since a git comment is there for a reason, which includes helping its readers understand the commit, I consider ARMv7-AR Reference Manual to help them much more than 'ARM ARM', as it points them unambiguously to the document by stating the exact title under which it is listed in the ARM information center, but I am ok with 'ARMv7-AR Architecture Reference Manual' as this how its title goes. Just to clarify: yes, the document is listed (on the left, in the docs tree as ARMv7-AR Reference Manual, and yes, its title is 'ARMv7-AR Architecture Reference Manual'. That is not a mistake apparently, or it was a duly repeated one for all ARM architecture reference manuals on the Information Center. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] common/Makefile: Add new symbol CONFIG_SPL_ENV_SUPPORT for environment in SPL
On Mon, May 20, 2013 at 02:07:25PM +0800, ying.zh...@freescale.com wrote: From: Ying Zhang b40...@freescale.com There will need the environment in SPL for reasons other than network support (in particular, hwconfig contains info for how to set up DDR). Add a new symbol CONFIG_SPL_ENV_SUPPORT to replace CONFIG_SPL_NET_SUPPORT for environment in common/Makefile. Signed-off-by: Ying Zhang b40...@freescale.com Reviewed-by: Tom Rini tr...@ti.com -- 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: Enable -ffunction-sections / -fdata-sections / --gc-sections
On Thu, May 23, 2013 at 12:08:09PM +0200, Albert ARIBAUD wrote: Hi Tom, On Thu, 25 Apr 2013 13:40:22 -0400, Tom Rini tr...@ti.com wrote: While other architectures have enabled these gcc / ld options for some time on U-Boot itself, ARM has only been doing this on SPL. Enable this on full U-Boot as well now. I expect this was tested on various targets? I build-tested eldk 4.2/5.2 and the Linaro 4.7 that Ubuntu has available, with no build failures. I spot checked what was being dropped on am335x and some omap3/4 platforms and it looked correct, and I did boot test am335x. -- 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 v3 06/10] MIPS: qemu-malta: add PCI support
On Thu, May 23, 2013 at 03:55:43PM +0200, Daniel Schwierzeck wrote: Hi Tom, Wolfgang, we do not have a dedicated PCI custodian so could you comment this please? Thanks. 2013/5/23 Gabor Juhos juh...@openwrt.org: Hi Daniel, Thank you for the review! 2013/5/22 Gabor Juhos juh...@openwrt.org: Qemu emulates the Galileo GT64120 System Controller which provides a CPU bus to PCI bus bridge. The patch adds driver for this bridge and enables PCI support for the emulated Malta board. Signed-off-by: Gabor Juhos juh...@openwrt.org Cc: Daniel Schwierzeck daniel.schwierz...@googlemail.com ELDK-5.3 shows some warnings: pci_indirect.c: In function 'indirect_read_config_byte': pci_indirect.c:101:1: warning: implicit declaration of function 'out_le32' [-Wimplicit-function-declaration] pci_indirect.c:101:1: warning: implicit declaration of function 'in_8' [-Wimplicit-function-declaration] pci_indirect.c: In function 'indirect_read_config_word': pci_indirect.c:102:1: warning: implicit declaration of function 'in_le16' [-Wimplicit-function-declaration] pci_indirect.c: In function 'indirect_read_config_dword': pci_indirect.c:103:1: warning: implicit declaration of function 'in_le32' [-Wimplicit-function-declaration] pci_indirect.c: In function 'indirect_write_config_byte': pci_indirect.c:109:1: warning: implicit declaration of function 'out_8' [-Wimplicit-function-declaration] pci_indirect.c: In function 'indirect_write_config_word': pci_indirect.c:110:1: warning: implicit declaration of function 'out_le16' [-Wimplicit-function-declaration] Hm, you are right. My toolchain also shows the warning but I did not notice those because I forgot to redirect stderr when I have generated the build logs. The pci_indirect.c file is always compiled when CONFIG_PCI is defined although it is not needed at all for Malta PCI support. The issue can be resolved on a few different ways: 1. Extend the '#if !defined(__I386__)' directive in pci_indirect.c with a new ' !defined(__MIPS__)' condition. This would be the simplest solution but the drawback of this is that indirect support will not be usable on any MIPS board. 2. Introduce a new 'CONFIG_PCI_INDIRECT_BRIDGE' option and only compile the pci_indirect.c file if this option is present. Probably this is the best solution however the new symbol should be added into the configuration of the affected boards. 3. Introduce a new 'CONFIG_PCI_NO_INDIRECT_BRIDGE' option and use an '#ifndef CONFIG_PCI_NO_INDIRECT_BRIDGE' directive in pci_indirect.c. I'm unsure about which approach is preferred. I favor the second option. A quick check around in the kernel says that microblaze and powerpc have similar type code and keep it under arch/ rather than drivers, but I'm good with option #2. -- 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] MMC: DWMMC: Fix FIFO_DEPTH calculation
Hi Rajeshwari
On Thu, May 23, 2013 at 6:45 PM, Rajeshwari Shinde rajeshwar...@samsung.com
wrote:
Current DWMMC driver used to give FIFO underrun/overrun error every 3rd
time
for mmc rescan command.
In current code FIFO_DEPTH is getting calculated after reading the FIFOTH
register and extracting the RX_WMARK bits from it i.e (RX_WMARK =
FIFO_DEPTH/2 -1).
Instead of storing the correct value, we were recalculating the FIFO_DEPT
each
time which is not correct.
Signed-off-by: Hatim Ali hatim...@samsung.com
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
drivers/mmc/dw_mmc.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
index 4070d4e..be590a4 100644
--- a/drivers/mmc/dw_mmc.c
+++ b/drivers/mmc/dw_mmc.c
@@ -332,11 +332,13 @@ static int dwmci_init(struct mmc *mmc)
dwmci_writel(host, DWMCI_BMOD, 1);
fifo_size = dwmci_readl(host, DWMCI_FIFOTH);
- if (host-fifoth_val)
+ if (host-fifoth_val) {
fifoth_val = host-fifoth_val;
- else
+ } else {
fifoth_val = MSIZE(0x2) | RX_WMARK(fifo_size/2 -1) |
TX_WMARK(fifo_size/2);
+ host-fifoth_val = fifoth_val;
+ }
Looks Good to me.
Reviewed-by: Alim Akhtar alim.akh...@samsung.com
dwmci_writel(host, DWMCI_FIFOTH, fifoth_val);
dwmci_writel(host, DWMCI_CLKENA, 0);
--
1.7.4.4
___
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 v3 0/6] arm: mvf600: Add Freescale Vybrid MVF600 CPU and MVF600TWR board support
Hi Alison, On Wednesday, May 22, 2013 5:01:44 AM, Wang Huan-B18965 wrote: Hi, Benoit, -Original Message- From: Benoît Thébaudeau [mailto:benoit.thebaud...@advansee.com] Sent: Wednesday, May 22, 2013 12:28 AM To: Wang Huan-B18965 Cc: sba...@denx.de; u-boot@lists.denx.de; Estevam Fabio-R49496 Subject: Re: [U-Boot] [PATCH v3 0/6] arm: mvf600: Add Freescale Vybrid MVF600 CPU and MVF600TWR board support Hi Alison, On Tuesday, May 21, 2013 11:02:55 AM, Alison Wang wrote: This series contain the support for Freescale Vybrid MVF600 CPU and MVF600TWR board. Vybird devices are built on an asymmetrical-multiprocessing architecture using ARM cores. The families in the Vybrid portfolio span entry-level, single core Cortex-A class SoCs all the way to dual heterogeneous core SoCs with multiple communication and connectivity options. Part of the Vybrid platform, MVF600 is a dual-core eMPU combining the ARM Cortex A5 and Cortex M4 cores. MVF600 shares some IPs with i.MX family, such as FEC,ESDHC,WATCHDOG,I2C,ASRC and ESAI. MVF600 also shares some IPs with ColdFire family, such as eDMA and DSPI. MVF600 still has its own IPs, such as PIT,SAI,UART,QSPI and DCU. More documents for this soc can be found at: http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=VF6xxf srch=1sr=5 http://www.freescale.com/webapp/sps/site/homepage.jsp?code=VYBRID I have a question about the naming of this SoC. On Freescale's website, it is VF6xx everywhere, but you add a leading M (_M_VF600). Is it because you are using an internal SoC name known only by Freescale and different from the marketing SoC name, or is this M from the part number, or will the marketing SoC name change later, or some other reason? Please clarify. U-Boot users must be able to identify a SoC and to find information about it easily. [Alison Wang] We always use the name MVF600 in the internal development. We will check it with marketing team, and confirm it. Thanks. OK. You should also check for each part of the code in this patch set if it is specific to the (M)VF600 or common to all (M)VF6xx SoCs. In the latter case, the names in the code should be changed to either (m)vf6xx or (m)vf6, just like U-Boot uses mx5 to mean i.MX5xx. The naming for your Linux patches should also preferably be the same as in U-Boot in order to avoid confusion for users. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: pxa: PXA270 D-Cache as ram
On 05/21/2013 02:38 PM, Marek Vasut wrote: Dear Sergey Yanovich, Dear Marek Vasut, On Tue, 2013-05-21 at 22:07 +0200, Marek Vasut wrote: The OneNAND has 1kbyte limit on code it will directly address when booting from it, you can't even make generate the MMU table there. Do you mean there is no space left inside that 1K for lock_cache_for_stack()? How would you do that ? You need MMU enabled to lock lines IIRC. I have plans to dig deeper into this after I complete the current project. Faster boot is always a good thing. Thanks for explaining in details. Sure, yet I think I just piled work onto you ;-) It's OK. I have plans to do this anyway. CCing Mike Dunn, you two should coordinate. Thanks Marek. Was following this on the ML. Will take a look when I get a chance. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] wandboard: Disable data cache
Currently HDMI framebuffer only works if we disable data cache. Disable data cache until the proper fix is found. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- Hi, If someone has any suggestion for a proper fix, please let me know. Thanks include/configs/wandboard.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h index d4ac086..5a3f0fc 100644 --- a/include/configs/wandboard.h +++ b/include/configs/wandboard.h @@ -98,6 +98,7 @@ #define CONFIG_BMP_16BPP #define CONFIG_VIDEO_LOGO #define CONFIG_IPUV3_CLK 26000 +#define CONFIG_SYS_DCACHE_OFF #if defined(CONFIG_MX6DL) #define CONFIG_DEFAULT_FDT_FILEimx6dl-wandboard.dtb -- 1.8.1.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] wandboard: Enable HDMI splashscreen
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
board/wandboard/wandboard.c | 98 +
include/configs/wandboard.h | 15 ++-
2 files changed, 112 insertions(+), 1 deletion(-)
diff --git a/board/wandboard/wandboard.c b/board/wandboard/wandboard.c
index bb98352..5666cbf 100644
--- a/board/wandboard/wandboard.c
+++ b/board/wandboard/wandboard.c
@@ -10,9 +10,11 @@
*/
#include asm/arch/clock.h
+#include asm/arch/crm_regs.h
#include asm/arch/iomux.h
#include asm/arch/imx-regs.h
#include asm/arch/mx6-pins.h
+#include asm/arch/mxc_hdmi.h
#include asm/arch/sys_proto.h
#include asm/gpio.h
#include asm/imx-common/iomux-v3.h
@@ -21,9 +23,11 @@
#include asm/sizes.h
#include common.h
#include fsl_esdhc.h
+#include ipu_pixfmt.h
#include mmc.h
#include miiphy.h
#include netdev.h
+#include linux/fb.h
DECLARE_GLOBAL_DATA_PTR;
@@ -206,6 +210,88 @@ int board_phy_config(struct phy_device *phydev)
return 0;
}
+#if defined(CONFIG_VIDEO_IPUV3)
+static void enable_hdmi(void)
+{
+ struct hdmi_regs *hdmi = (struct hdmi_regs *)HDMI_ARB_BASE_ADDR;
+ u8 reg;
+ reg = readb(hdmi-phy_conf0);
+ reg |= HDMI_PHY_CONF0_PDZ_MASK;
+ writeb(reg, hdmi-phy_conf0);
+
+ udelay(3000);
+ reg |= HDMI_PHY_CONF0_ENTMDS_MASK;
+ writeb(reg, hdmi-phy_conf0);
+ udelay(3000);
+ reg |= HDMI_PHY_CONF0_GEN2_TXPWRON_MASK;
+ writeb(reg, hdmi-phy_conf0);
+ writeb(HDMI_MC_PHYRSTZ_ASSERT, hdmi-mc_phyrstz);
+}
+
+static struct fb_videomode const hdmi = {
+ .name = HDMI,
+ .refresh= 60,
+ .xres = 1024,
+ .yres = 768,
+ .pixclock = 15385,
+ .left_margin= 220,
+ .right_margin = 40,
+ .upper_margin = 21,
+ .lower_margin = 7,
+ .hsync_len = 60,
+ .vsync_len = 10,
+ .sync = FB_SYNC_EXT,
+ .vmode = FB_VMODE_NONINTERLACED
+};
+
+int board_video_skip(void)
+{
+ int ret;
+
+ ret = ipuv3_fb_init(hdmi, 0, IPU_PIX_FMT_RGB24);
+
+ if (ret)
+ printf(HDMI cannot be configured: %d\n, ret);
+
+ enable_hdmi();
+
+ return ret;
+}
+
+static void setup_display(void)
+{
+ struct mxc_ccm_reg *mxc_ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
+ struct hdmi_regs *hdmi = (struct hdmi_regs *)HDMI_ARB_BASE_ADDR;
+ int reg;
+
+ /* Turn on IPU clock */
+ reg = readl(mxc_ccm-CCGR3);
+ reg |= MXC_CCM_CCGR3_IPU1_IPU_DI0_OFFSET;
+ writel(reg, mxc_ccm-CCGR3);
+
+ /* Turn on HDMI PHY clock */
+ reg = readl(mxc_ccm-CCGR2);
+ reg |= MXC_CCM_CCGR2_HDMI_TX_IAHBCLK_MASK
+ | MXC_CCM_CCGR2_HDMI_TX_ISFRCLK_MASK;
+ writel(reg, mxc_ccm-CCGR2);
+
+ /* clear HDMI PHY reset */
+ writeb(HDMI_MC_PHYRSTZ_DEASSERT, hdmi-mc_phyrstz);
+
+ reg = readl(mxc_ccm-chsccdr);
+ reg = ~(MXC_CCM_CHSCCDR_IPU1_DI0_PRE_CLK_SEL_MASK
+ | MXC_CCM_CHSCCDR_IPU1_DI0_PODF_MASK
+ | MXC_CCM_CHSCCDR_IPU1_DI0_CLK_SEL_MASK);
+ reg |= (CHSCCDR_CLK_SEL_LDB_DI0
+MXC_CCM_CHSCCDR_IPU1_DI0_CLK_SEL_OFFSET)
+ | (CHSCCDR_PODF_DIVIDE_BY_3
+MXC_CCM_CHSCCDR_IPU1_DI0_PODF_OFFSET)
+ | (CHSCCDR_IPU_PRE_CLK_540M_PFD
+MXC_CCM_CHSCCDR_IPU1_DI0_PRE_CLK_SEL_OFFSET);
+ writel(reg, mxc_ccm-chsccdr);
+}
+#endif /* CONFIG_VIDEO_IPUV3 */
+
int board_eth_init(bd_t *bis)
{
int ret;
@@ -222,9 +308,21 @@ int board_eth_init(bd_t *bis)
int board_early_init_f(void)
{
setup_iomux_uart();
+#if defined(CONFIG_VIDEO_IPUV3)
+ setup_display();
+#endif
return 0;
}
+/*
+ * Do not overwrite the console
+ * Use always serial for U-Boot console
+ */
+int overwrite_console(void)
+{
+ return 1;
+}
+
#ifdef CONFIG_CMD_BMODE
static const struct boot_mode board_boot_modes[] = {
/* 4 bit bus width */
diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h
index 9d7ec3f..d4ac086 100644
--- a/include/configs/wandboard.h
+++ b/include/configs/wandboard.h
@@ -29,7 +29,7 @@
#define CONFIG_REVISION_TAG
/* Size of malloc() pool */
-#define CONFIG_SYS_MALLOC_LEN (3 * SZ_1M)
+#define CONFIG_SYS_MALLOC_LEN (10 * SZ_1M)
#define CONFIG_BOARD_EARLY_INIT_F
#define CONFIG_BOARD_LATE_INIT
@@ -86,6 +86,19 @@
#define CONFIG_PHYLIB
#define CONFIG_PHY_ATHEROS
+/* Framebuffer */
+#define CONFIG_VIDEO
+#define CONFIG_VIDEO_IPUV3
+#define CONFIG_CFB_CONSOLE
+#define CONFIG_VGA_AS_SINGLE_DEVICE
+#define CONFIG_SYS_CONSOLE_IS_IN_ENV
+#define CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE
+#define CONFIG_VIDEO_BMP_RLE8
+#define CONFIG_SPLASH_SCREEN
+#define CONFIG_BMP_16BPP
+#define CONFIG_VIDEO_LOGO
+#define CONFIG_IPUV3_CLK 26000
+
#if defined(CONFIG_MX6DL)
#define CONFIG_DEFAULT_FDT_FILEimx6dl-wandboard.dtb
#elif defined(CONFIG_MX6S)
Re: [U-Boot] [PATCH 1/6] ARM: add secure monitor handler to switch to non-secure state
On 23/05/13 11:52, Albert ARIBAUD wrote: Hi Andre, On Mon, 6 May 2013 15:17:45 +0200, Andre Przywara andre.przyw...@linaro.org wrote: A prerequisite for using virtualization is to be in HYP mode, which requires the CPU to be in non-secure state. Introduce a monitor handler routine which switches the CPU to non-secure state by setting the NS and associated bits. According to the ARM ARM this should not be done in SVC mode, so we ARM *TRM*, I suspect. Also, as there are a lot of ARM TRMs, if there is a more precise reference, please provide it. I believe the ARM ARM (as in ARM Architecture Reference Manual) is the correct document here. http://infocenter.arm.com/help/topic/com.arm.doc.ddi0406c/index.html Cheers, M. -- Jazz is not dead. It just smells funny... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Can not get linux prompt using sandbox
Hi All, I'm using sandbox architecture on my PC to work on some sign-verify issues. However, I can not get linux prompt after bootm a linux kernel. I understand sandbox development is in progress, so I want to ask is it doable to get a linux prompt using sandbox currently? Thanks. Best Regards, Christian -- View this message in context: http://u-boot.10912.n7.nabble.com/Can-not-get-linux-prompt-using-sandbox-tp155545.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V9 7/9] MMC: APIs to support resize of EMMC boot partition
Hi Amar,
On Apr 27, 2013 at 6:12 AM, Amar amarendra...@samsung.com wrote:
+#ifdef CONFIG_SUPPORT_EMMC_BOOT
+/*
+ * This function changes the size of boot partition and the size of rpmb
+ * partition present on EMMC devices.
+ *
+ * Input Parameters:
+ * struct *mmc: pointer for the mmc device strcuture
+ * bootsize: size of boot partition
+ * rpmbsize: size of rpmb partition
+ *
+ * Returns 0 on success.
+ */
+
+int mmc_boot_partition_size_change(struct mmc *mmc, unsigned long bootsize,
+ unsigned long rpmbsize)
+{
+ int err;
+ struct mmc_cmd cmd;
+
+ /* Only use this command for raw EMMC moviNAND. Enter backdoor mode */
+ cmd.cmdidx = MMC_CMD_RES_MAN;
+ cmd.resp_type = MMC_RSP_R1b;
+ cmd.cmdarg = MMC_CMD62_ARG1;
+
+ err = mmc_send_cmd(mmc, cmd, NULL);
+ if (err) {
+ debug(mmc_boot_partition_size_change: Error1 = %d\n, err);
+ return err;
+ }
+
+ /* Boot partition changing mode */
+ cmd.cmdidx = MMC_CMD_RES_MAN;
+ cmd.resp_type = MMC_RSP_R1b;
+ cmd.cmdarg = MMC_CMD62_ARG2;
The function description above implies that this function will work on all EMMC
devices, but you are using vendor commands here and have the comment Only use
this command for raw EMMC moviNAND.
This was brought up in the V4 patch by Jaehoon Chung, but never addressed.
Vendor specific code should probably be broken off to a vendor specific area,
or there should at least be some conditional check that the EMMC is compatible.
+
+ err = mmc_send_cmd(mmc, cmd, NULL);
+ if (err) {
+ debug(mmc_boot_partition_size_change: Error2 = %d\n, err);
+ return err;
+ }
+ /* boot partition size is multiple of 128KB */
+ bootsize = (bootsize * 1024) / 128;
+
+ /* Arg: boot partition size */
+ cmd.cmdidx = MMC_CMD_RES_MAN;
+ cmd.resp_type = MMC_RSP_R1b;
+ cmd.cmdarg = bootsize;
+
+ err = mmc_send_cmd(mmc, cmd, NULL);
+ if (err) {
+ debug(mmc_boot_partition_size_change: Error3 = %d\n, err);
+ return err;
+ }
+ /* RPMB partition size is multiple of 128KB */
+ rpmbsize = (rpmbsize * 1024) / 128;
+ /* Arg: RPMB partition size */
+ cmd.cmdidx = MMC_CMD_RES_MAN;
+ cmd.resp_type = MMC_RSP_R1b;
+ cmd.cmdarg = rpmbsize;
+
+ err = mmc_send_cmd(mmc, cmd, NULL);
+ if (err) {
+ debug(mmc_boot_partition_size_change: Error4 = %d\n, err);
+ return err;
+ }
+ return 0;
+}
Thanks,
Michael Pratt
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] disassembler ?
Sorry for being delayed on getting back to you on this. Work issues took hold. There were several good questions. Let me give you some background. I am working at a start-up. We are building a new processor and system for that new processor. So we have hardware work and software work to get through. Part of my reasoning in asking the question about a disassembler is becuase there is a reference to BedBug in the manual. http://www.denx.de/wiki/view/U-Bootdoc/BedbugEmbeddedDebuggerCommands . As well as, the BedBug debugger is in the source code. So I'm trying to understand at a high level if I can utilize this work to help me. Or should I just go and implement this independently. Why not just use JTAG? We are doing new processor design, so it's not defined if the system will even have a JTAG interface. There are lots of systems that do not have a JTAG interface. Why not use use objdump? We are in the process of porting binutils, so I currently don't have an objdump to use. I do have a manual disassembly routine that we created in h/w design to help us. But, until binutils has been ported, there is no objdump. I think the big issue that is confusing to me is why is BedBug still in U-Boot? Should i try and graft my work into BedBug? If so, then I'm happy to do the work and contribute it back to the group. But, if not, then I'll just go ahead implement the work independently. Hopefully, this makes sense. Feel free to ask questions. -brad w. On Thu, May 16, 2013 at 4:15 PM, Wolfgang Denk w...@denx.de wrote: Dear Brad Walker, In message CAPKZHbVOpoLNHAsjfwyEi9783zgYbfNuf9_GZ= avuxtmews...@mail.gmail.com you wrote: I am working on a new processor and board for that processor. I'm in need of a disassembler for this work. And why exactly do you need that on the target? Why cannot you just use objdump ? 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 We, the unwilling, led by the unknowing, are doing the impossible for the ungrateful. We have done so much, for so long, with so little, we are now qualified to do anything with nothing. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MMC: DWMMC: Fix FIFO_DEPTH calculation
On Thu, May 23, 2013 at 6:45 PM, Rajeshwari Shinde
rajeshwar...@samsung.com wrote:
Current DWMMC driver used to give FIFO underrun/overrun error every 3rd time
for mmc rescan command.
In current code FIFO_DEPTH is getting calculated after reading the FIFOTH
register and extracting the RX_WMARK bits from it i.e (RX_WMARK =
FIFO_DEPTH/2 -1).
Instead of storing the correct value, we were recalculating the FIFO_DEPT each
time which is not correct.
Signed-off-by: Hatim Ali hatim...@samsung.com
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
drivers/mmc/dw_mmc.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
index 4070d4e..be590a4 100644
--- a/drivers/mmc/dw_mmc.c
+++ b/drivers/mmc/dw_mmc.c
@@ -332,11 +332,13 @@ static int dwmci_init(struct mmc *mmc)
dwmci_writel(host, DWMCI_BMOD, 1);
fifo_size = dwmci_readl(host, DWMCI_FIFOTH);
- if (host-fifoth_val)
+ if (host-fifoth_val) {
What is the inital value for host-fifoth_val, for the first time call.?
fifoth_val = host-fifoth_val;
- else
+ } else {
fifoth_val = MSIZE(0x2) | RX_WMARK(fifo_size/2 -1) |
TX_WMARK(fifo_size/2);
+ host-fifoth_val = fifoth_val;
+ }
dwmci_writel(host, DWMCI_FIFOTH, fifoth_val);
dwmci_writel(host, DWMCI_CLKENA, 0);
--
1.7.4.4
Thanks,
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] disassembler ?
Hi Brad, On Thu, 23 May 2013 11:13:53 -0600, Brad Walker bwal...@musings.com wrote: Sorry for being delayed on getting back to you on this. Work issues took hold. There were several good questions. Let me give you some background. I am working at a start-up. We are building a new processor and system for that new processor. So we have hardware work and software work to get through. Part of my reasoning in asking the question about a disassembler is becuase there is a reference to BedBug in the manual. http://www.denx.de/wiki/view/U-Bootdoc/BedbugEmbeddedDebuggerCommands . As well as, the BedBug debugger is in the source code. So I'm trying to understand at a high level if I can utilize this work to help me. Or should I just go and implement this independently. Why not just use JTAG? We are doing new processor design, so it's not defined if the system will even have a JTAG interface. There are lots of systems that do not have a JTAG interface. Why not use use objdump? We are in the process of porting binutils, so I currently don't have an objdump to use. I do have a manual disassembly routine that we created in h/w design to help us. But, until binutils has been ported, there is no objdump. I think the big issue that is confusing to me is why is BedBug still in U-Boot? Should i try and graft my work into BedBug? If so, then I'm happy to do the work and contribute it back to the group. But, if not, then I'll just go ahead implement the work independently. Hopefully, this makes sense. Feel free to ask questions. The way I understand your project, I wonder why you want to disassemble code at all: if you manage to get U-Boot running on your target with BedBug support for your CPU enabled, this means you have a working gcc+binutils, which in turn means you have a toolchain, including an assembler, that works well enough for bedbug to become pointless. Compare the bedbug and objdump/gdb options: on the one hand you get a crude debugger and disassembler that will only run from U-Boot and will be practically useless for debugging say a Linux kernel or U-Boot itself; and on the other hand, with objdump you get a disassembler that will work on just about any binary, and with gdb, you get a debugger that will debug anything from U-boot to userland apps. Also, I *very* strongly suggest that you integrate *some* debugging interface, based on *some* industry standard. Seeing as you're working on a brand new, untested so far, silicon, such a debugging interface is an absolute must IMO. -brad w. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] disassembler ?
On 05/23/2013 02:53 PM, Albert ARIBAUD wrote: Also, I *very* strongly suggest that you integrate *some* debugging interface, based on *some* industry standard. Seeing as you're working on a brand new, untested so far, silicon, such a debugging interface is an absolute must IMO. Ditto here. JTAG (or some other industry debugging standard) allows attaching mature tools (like an Abatron BDI or some such) to not only help verify the state, but develop/debug the code you're writing. Without such you'll only be able to do a postmortem and inspect memory after the code/processor crash - a much more laborious process... -- Peter Barada peter.bar...@logicpd.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] wandboard: Disable data cache
Hi Fabio, On Thu, 23 May 2013 14:50:24 -0300 Fabio Estevam fabio.este...@freescale.com wrote: Currently HDMI framebuffer only works if we disable data cache. Disable data cache until the proper fix is found. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- Hi, If someone has any suggestion for a proper fix, please let me know. There is a patch for a proper fix, queued in my video repo: http://git.denx.de/?p=u-boot/u-boot-video.git;a=commit;h=db0d47dd433bc7ba60b927fb0ff6835758a8893d Thanks, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] wandboard: Disable data cache
Hi Anatolij, On Thu, May 23, 2013 at 4:31 PM, Anatolij Gustschin ag...@denx.de wrote: There is a patch for a proper fix, queued in my video repo: http://git.denx.de/?p=u-boot/u-boot-video.git;a=commit;h=db0d47dd433bc7ba60b927fb0ff6835758a8893d Excellent, just applied this patch, kept dcache on and the splash can be seen withour distortion. Thanks, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] disassembler ?
Hi Peter, On Thu, 23 May 2013 15:08:24 -0400, Peter Barada peter.bar...@logicpd.com wrote: On 05/23/2013 02:53 PM, Albert ARIBAUD wrote: Also, I *very* strongly suggest that you integrate *some* debugging interface, based on *some* industry standard. Seeing as you're working on a brand new, untested so far, silicon, such a debugging interface is an absolute must IMO. Ditto here. JTAG (or some other industry debugging standard) allows attaching mature tools (like an Abatron BDI or some such) to not only help verify the state, but develop/debug the code you're writing. Without such you'll only be able to do a postmortem and inspect memory after the code/processor crash - a much more laborious process... One won't even be able to do that, at least not if the inspection is done using Bedbug within U-Boot since launching U-boot will, in itself, overwrite some of the memory -- and Murphy guarantees that the overwritten memory will include the areas needed for a successful postmortem. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ext4: assign get_fs()-dev_desc before using it
From: Stephen Warren swar...@nvidia.com
Commit 50ce4c0 fs/ext4: Support device block sizes != 512 bytes
modified ext4fs_set_blk_dev() to calculate total_sect based on
get_fs()-dev_desc-log2blksz rather than SECTOR_SIZE. However, this
value wasn't yet assigned. Move the assignment earlier so the code
doesn't crash or hang.
Cc: Egbert Eich e...@suse.com
Signed-off-by: Stephen Warren swar...@nvidia.com
---
fs/ext4/dev.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ext4/dev.c b/fs/ext4/dev.c
index 3e993cc..81b7633 100644
--- a/fs/ext4/dev.c
+++ b/fs/ext4/dev.c
@@ -51,11 +51,11 @@ void ext4fs_set_blk_dev(block_dev_desc_t *rbdd,
disk_partition_t *info)
{
assert(rbdd-blksz == (1 rbdd-log2blksz));
ext4fs_block_dev_desc = rbdd;
+ get_fs()-dev_desc = rbdd;
part_info = info;
part_offset = info-start;
get_fs()-total_sect = (info-size * info-blksz)
get_fs()-dev_desc-log2blksz;
- get_fs()-dev_desc = rbdd;
}
int ext4fs_devread(int sector, int byte_offset, int byte_len, char *buf)
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Building two different SPL for the same board?
On Thu, May 23, 2013 at 10:53:39AM +0200, Henrik Nordstr?m wrote: ons 2013-05-22 klockan 11:26 -0400 skrev Tom Rini: If we can implement it cleanly, this isn't (at the 1000 meter view) all that much different than what we do on some PowerPC platforms today where everything must fit within a few kilobytes. Yes it is quite doable. The pieces I have done should be possible to fit without too much effort. The question is more if these kinds of board initialization only programs is seen as suitable for having in the u-boot tree. It's not really an SPL as it does not load anything, but it's 99.9% the same code as used in u-boot SPL. My rather poor understanding of how some of the Freescale ARM parts do SPL is a lot more like this (whack things about, let ROM load next parts) than the SPL takes over, loads U-Boot method. And this is OK, in so far as it gets needed jobs done in the resources available. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 3/4] env_mmc: allow negative CONFIG_ENV_OFFSET
From: Stephen Warren swar...@nvidia.com
A negative value of CONFIG_ENV_OFFSET is treated as a backwards offset
from the end of the eMMC device/partition, rather than a forwards offset
from the start.
This is useful when a single board may be stuffed with different eMMC
devices, each of which has a different capacity, and you always want the
environment to be stored at the very end of the device (or eMMC boot
partition for example).
One example of this case is NVIDIA's Ventana reference board.
Signed-off-by: Stephen Warren swar...@nvidia.com
---
v3: No change.
v2: Also update README to describe the change.
---
README | 11 +++
common/env_mmc.c | 12 ++--
2 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/README b/README
index e7fedb8..56d5e91 100644
--- a/README
+++ b/README
@@ -3627,6 +3627,14 @@ but it can not erase, write this NOR flash by SRIO or
PCIE interface.
These two #defines specify the offset and size of the environment
area within the specified MMC device.
+ If offset is positive (the usual case), it is treated as relative to
+ the start of the MMC partition. If offset is negative, it is treated
+ as relative to the end of the MMC partition. This can be useful if
+ your board may be fitted with different MMC devices, which have
+ different sizes for the MMC partitions, and you always want the
+ environment placed at the very end of the partition, to leave the
+ maximum possible space before it, to store other data.
+
These two values are in units of bytes, but must be aligned to an
MMC sector boundary.
@@ -3637,6 +3645,9 @@ but it can not erase, write this NOR flash by SRIO or
PCIE interface.
valid backup copy in case the other copy is corrupted, e.g. due
to a power failure during a saveenv operation.
+ This value may also be positive or negative; this is handled in the
+ same way as CONFIG_ENV_OFFSET.
+
This value is also in units of bytes, but must also be aligned to
an MMC sector boundary.
diff --git a/common/env_mmc.c b/common/env_mmc.c
index 9ca098f..5d3a769 100644
--- a/common/env_mmc.c
+++ b/common/env_mmc.c
@@ -53,11 +53,19 @@ DECLARE_GLOBAL_DATA_PTR;
__weak int mmc_get_env_addr(struct mmc *mmc, int copy, u32 *env_addr)
{
- *env_addr = CONFIG_ENV_OFFSET;
+ s64 offset;
+
+ offset = CONFIG_ENV_OFFSET;
#ifdef CONFIG_ENV_OFFSET_REDUND
if (copy)
- *env_addr = CONFIG_ENV_OFFSET_REDUND;
+ offset = CONFIG_ENV_OFFSET_REDUND;
#endif
+
+ if (offset 0)
+ offset += mmc-capacity;
+
+ *env_addr = offset;
+
return 0;
}
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 4/4] ARM: tegra: make use of negative ENV_OFFSET on NVIDIA boards
From: Stephen Warren swar...@nvidia.com Use a negative value of CONFIG_ENV_OFFSET for all NVIDIA reference boards that store the U-Boot environment in the 2nd eMMC boot partition. This makes U-Boot agnostic to the size of the eMMC boot partition, which can vary depending on which eMMC device was actually stuffed into the board. Signed-off-by: Stephen Warren swar...@nvidia.com --- v3: No change. v2: No change. --- include/configs/beaver.h |2 +- include/configs/cardhu.h |2 +- include/configs/dalmore.h |2 +- include/configs/paz00.h|2 +- include/configs/seaboard.h |2 +- include/configs/ventana.h |2 +- include/configs/whistler.h |4 ++-- 7 files changed, 8 insertions(+), 8 deletions(-) diff --git a/include/configs/beaver.h b/include/configs/beaver.h index 058da4f..d51f5f8 100644 --- a/include/configs/beaver.h +++ b/include/configs/beaver.h @@ -56,7 +56,7 @@ /* Environment in eMMC, at the end of 2nd boot sector */ #define CONFIG_ENV_IS_IN_MMC -#define CONFIG_ENV_OFFSET ((1024 * 1024) - CONFIG_ENV_SIZE) +#define CONFIG_ENV_OFFSET (-CONFIG_ENV_SIZE) #define CONFIG_SYS_MMC_ENV_DEV 0 #define CONFIG_SYS_MMC_ENV_PART2 diff --git a/include/configs/cardhu.h b/include/configs/cardhu.h index fd46083..142d20b 100644 --- a/include/configs/cardhu.h +++ b/include/configs/cardhu.h @@ -55,7 +55,7 @@ /* Environment in eMMC, at the end of 2nd boot sector */ #define CONFIG_ENV_IS_IN_MMC -#define CONFIG_ENV_OFFSET ((512 * 1024) - CONFIG_ENV_SIZE) +#define CONFIG_ENV_OFFSET (-CONFIG_ENV_SIZE) #define CONFIG_SYS_MMC_ENV_DEV 0 #define CONFIG_SYS_MMC_ENV_PART2 diff --git a/include/configs/dalmore.h b/include/configs/dalmore.h index 2723843..b6e0161 100644 --- a/include/configs/dalmore.h +++ b/include/configs/dalmore.h @@ -60,7 +60,7 @@ #define CONFIG_ENV_IS_IN_MMC #define CONFIG_SYS_MMC_ENV_DEV 0 #define CONFIG_SYS_MMC_ENV_PART2 -#define CONFIG_ENV_OFFSET ((4096 * 1024) - CONFIG_ENV_SIZE) +#define CONFIG_ENV_OFFSET (-CONFIG_ENV_SIZE) #define MACH_TYPE_DALMORE 4304/* not yet in mach-types.h */ diff --git a/include/configs/paz00.h b/include/configs/paz00.h index eac1ef9..9e2686a 100644 --- a/include/configs/paz00.h +++ b/include/configs/paz00.h @@ -46,7 +46,7 @@ /* Environment in eMMC, at the end of 2nd boot sector */ #define CONFIG_ENV_IS_IN_MMC -#define CONFIG_ENV_OFFSET ((1024 * 1024) - CONFIG_ENV_SIZE) +#define CONFIG_ENV_OFFSET (-CONFIG_ENV_SIZE) #define CONFIG_SYS_MMC_ENV_DEV 0 #define CONFIG_SYS_MMC_ENV_PART 2 diff --git a/include/configs/seaboard.h b/include/configs/seaboard.h index f66173e..f0da1fc 100644 --- a/include/configs/seaboard.h +++ b/include/configs/seaboard.h @@ -72,7 +72,7 @@ /* Environment in eMMC, at the end of 2nd boot sector */ #define CONFIG_ENV_IS_IN_MMC -#define CONFIG_ENV_OFFSET ((512 * 1024) - CONFIG_ENV_SIZE) +#define CONFIG_ENV_OFFSET (-CONFIG_ENV_SIZE) #define CONFIG_SYS_MMC_ENV_DEV 0 #define CONFIG_SYS_MMC_ENV_PART 2 diff --git a/include/configs/ventana.h b/include/configs/ventana.h index 5755f11..41a7176 100644 --- a/include/configs/ventana.h +++ b/include/configs/ventana.h @@ -52,7 +52,7 @@ /* Environment in eMMC, at the end of 2nd boot sector */ #define CONFIG_ENV_IS_IN_MMC -#define CONFIG_ENV_OFFSET ((1024 * 1024) - CONFIG_ENV_SIZE) +#define CONFIG_ENV_OFFSET (-CONFIG_ENV_SIZE) #define CONFIG_SYS_MMC_ENV_DEV 0 #define CONFIG_SYS_MMC_ENV_PART 2 diff --git a/include/configs/whistler.h b/include/configs/whistler.h index 9542c7e..994edec 100644 --- a/include/configs/whistler.h +++ b/include/configs/whistler.h @@ -61,12 +61,12 @@ /* * Environment in eMMC, at the end of 2nd boot sector. Note: This assumes - * the user plugged the standard 8MB MoviNAND card into J29/HSMMC/POP. If + * the user plugged the standard 8GB MoviNAND card into J29/HSMMC/POP. If * they didn't, the boot sector layout may be different. However, use of that * particular card is standard practice as far as I know. */ #define CONFIG_ENV_IS_IN_MMC -#define CONFIG_ENV_OFFSET ((512 * 1024) - CONFIG_ENV_SIZE) +#define CONFIG_ENV_OFFSET (-CONFIG_ENV_SIZE) #define CONFIG_SYS_MMC_ENV_DEV 0 #define CONFIG_SYS_MMC_ENV_PART 2 -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 1/4] README: document CONFIG_ENV_IS_IN_MMC
From: Stephen Warren swar...@nvidia.com Describe the meaning of CONFIG_ENV_IS_IN_MMC, and all related defines that must or can be set when using that option. Signed-off-by: Stephen Warren swar...@nvidia.com --- v3: * Mention that env size/offset are in bytes. * Fix typo; s/CONFIG_ENV_OFFSET/CONFIG_ENV_SIZE/ in one place. v2: New patch. --- README | 40 1 file changed, 40 insertions(+) diff --git a/README b/README index 3012dcd..e7fedb8 100644 --- a/README +++ b/README @@ -3606,6 +3606,46 @@ but it can not erase, write this NOR flash by SRIO or PCIE interface. You will probably want to define these to avoid a really noisy system when storing the env in UBI. +- CONFIG_ENV_IS_IN_MMC: + + Define this if you have an MMC device which you want to use for the + environment. + + - CONFIG_SYS_MMC_ENV_DEV: + + Specifies which MMC device the environment is stored in. + + - CONFIG_SYS_MMC_ENV_PART (optional): + + Specifies which MMC partition the environment is stored in. If not + set, defaults to partition 0, the user area. Common values might be + 1 (first MMC boot partition), 2 (second MMC boot partition). + + - CONFIG_ENV_OFFSET: + - CONFIG_ENV_SIZE: + + These two #defines specify the offset and size of the environment + area within the specified MMC device. + + These two values are in units of bytes, but must be aligned to an + MMC sector boundary. + + - CONFIG_ENV_OFFSET_REDUND (optional): + + Specifies a second storage area, of CONFIG_ENV_SIZE size, used to + hold a redundant copy of the environment data. This provides a + valid backup copy in case the other copy is corrupted, e.g. due + to a power failure during a saveenv operation. + + This value is also in units of bytes, but must also be aligned to + an MMC sector boundary. + + - CONFIG_ENV_SIZE_REDUND (optional): + + This value need not be set, even when CONFIG_ENV_OFFSET_REDUND is + set. If this value is set, it must be set to the same value as + CONFIG_ENV_SIZE. + - CONFIG_SYS_SPI_INIT_OFFSET Defines offset to the initial SPI buffer area in DPRAM. The -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 2/4] mmc: report capacity for the selected partition
From: Stephen Warren swar...@nvidia.com
Enhance the MMC core to calculate the size of each MMC partition, and
update mmc-capacity whenever a partition is selected. This causes:
mmc dev 0 1 ; mmcinfo
... to report the size of the currently selected partition, rather than
always reporting the size of the user partition.
Signed-off-by: Stephen Warren swar...@nvidia.com
---
v3: No change.
v2: No change.
---
drivers/mmc/mmc.c | 68 +++--
include/mmc.h |7 ++
2 files changed, 68 insertions(+), 7 deletions(-)
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 0a2f535..31036f7 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -700,16 +700,49 @@ static int mmc_change_freq(struct mmc *mmc)
return 0;
}
+static int mmc_set_capacity(struct mmc *mmc, int part_num)
+{
+ switch (part_num) {
+ case 0:
+ mmc-capacity = mmc-capacity_user;
+ break;
+ case 1:
+ case 2:
+ mmc-capacity = mmc-capacity_boot;
+ break;
+ case 3:
+ mmc-capacity = mmc-capacity_rpmb;
+ break;
+ case 4:
+ case 5:
+ case 6:
+ case 7:
+ mmc-capacity = mmc-capacity_gp[part_num - 4];
+ break;
+ default:
+ return -1;
+ }
+
+ mmc-block_dev.lba = lldiv(mmc-capacity, mmc-read_bl_len);
+
+ return 0;
+}
+
int mmc_switch_part(int dev_num, unsigned int part_num)
{
struct mmc *mmc = find_mmc_device(dev_num);
+ int ret;
if (!mmc)
return -1;
- return mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_PART_CONF,
- (mmc-part_config ~PART_ACCESS_MASK)
- | (part_num PART_ACCESS_MASK));
+ ret = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_PART_CONF,
+(mmc-part_config ~PART_ACCESS_MASK)
+| (part_num PART_ACCESS_MASK));
+ if (ret)
+ return ret;
+
+ return mmc_set_capacity(mmc, part_num);
}
int mmc_getcd(struct mmc *mmc)
@@ -917,7 +950,7 @@ static void mmc_set_bus_width(struct mmc *mmc, uint width)
static int mmc_startup(struct mmc *mmc)
{
- int err;
+ int err, i;
uint mult, freq;
u64 cmult, csize, capacity;
struct mmc_cmd cmd;
@@ -1035,8 +1068,12 @@ static int mmc_startup(struct mmc *mmc)
cmult = (mmc-csd[2] 0x00038000) 15;
}
- mmc-capacity = (csize + 1) (cmult + 2);
- mmc-capacity *= mmc-read_bl_len;
+ mmc-capacity_user = (csize + 1) (cmult + 2);
+ mmc-capacity_user *= mmc-read_bl_len;
+ mmc-capacity_boot = 0;
+ mmc-capacity_rpmb = 0;
+ for (i = 0; i 4; i++)
+ mmc-capacity_gp[i] = 0;
if (mmc-read_bl_len MMC_MAX_BLOCK_LEN)
mmc-read_bl_len = MMC_MAX_BLOCK_LEN;
@@ -1075,7 +1112,7 @@ static int mmc_startup(struct mmc *mmc)
| ext_csd[EXT_CSD_SEC_CNT + 3] 24;
capacity *= MMC_MAX_BLOCK_LEN;
if ((capacity 20) 2 * 1024)
- mmc-capacity = capacity;
+ mmc-capacity_user = capacity;
}
switch (ext_csd[EXT_CSD_REV]) {
@@ -1117,8 +1154,25 @@ static int mmc_startup(struct mmc *mmc)
if ((ext_csd[EXT_CSD_PARTITIONING_SUPPORT] PART_SUPPORT) ||
ext_csd[EXT_CSD_BOOT_MULT])
mmc-part_config = ext_csd[EXT_CSD_PART_CONF];
+
+ mmc-capacity_boot = ext_csd[EXT_CSD_BOOT_MULT] 17;
+
+ mmc-capacity_rpmb = ext_csd[EXT_CSD_RPMB_MULT] 17;
+
+ for (i = 0; i 4; i++) {
+ int idx = EXT_CSD_GP_SIZE_MULT + i * 3;
+ mmc-capacity_gp[i] = (ext_csd[idx + 2] 16) +
+ (ext_csd[idx + 1] 8) + ext_csd[idx];
+ mmc-capacity_gp[i] *=
+ ext_csd[EXT_CSD_HC_ERASE_GRP_SIZE];
+ mmc-capacity_gp[i] *= ext_csd[EXT_CSD_HC_WP_GRP_SIZE];
+ }
}
+ err = mmc_set_capacity(mmc, mmc-part_num);
+ if (err)
+ return err;
+
if (IS_SD(mmc))
err = sd_change_freq(mmc);
else
diff --git a/include/mmc.h b/include/mmc.h
index 566db59..ea198d8 100644
--- a/include/mmc.h
+++ b/include/mmc.h
@@ -158,7 +158,9 @@
/*
* EXT_CSD fields
*/
+#define EXT_CSD_GP_SIZE_MULT 143 /* R/W */
#define EXT_CSD_PARTITIONING_SUPPORT 160 /* RO */
+#define EXT_CSD_RPMB_MULT 168 /* RO */
#define EXT_CSD_ERASE_GROUP_DEF175 /* R/W */
#define EXT_CSD_PART_CONF 179 /* R/W */
#define EXT_CSD_BUS_WIDTH 183 /* R/W */
@@ -166,6 +168,7 @@
#define
Re: [U-Boot] disassembler ?
On 05/23/2013 03:49 PM, Albert ARIBAUD wrote: Hi Peter, On Thu, 23 May 2013 15:08:24 -0400, Peter Barada peter.bar...@logicpd.com wrote: On 05/23/2013 02:53 PM, Albert ARIBAUD wrote: Also, I *very* strongly suggest that you integrate *some* debugging interface, based on *some* industry standard. Seeing as you're working on a brand new, untested so far, silicon, such a debugging interface is an absolute must IMO. Ditto here. JTAG (or some other industry debugging standard) allows attaching mature tools (like an Abatron BDI or some such) to not only help verify the state, but develop/debug the code you're writing. Without such you'll only be able to do a postmortem and inspect memory after the code/processor crash - a much more laborious process... One won't even be able to do that, at least not if the inspection is done using Bedbug within U-Boot since launching U-boot will, in itself, overwrite some of the memory -- and Murphy guarantees that the overwritten memory will include the areas needed for a successful postmortem. If one was lucky maybe. But who builds schedules around luck? And yes, Murphy's a mother... I was assuming that through some black magic they could get into Bedbug on reset and use it to inspect memory. Of course this assumes that Bedbug and u-boot don't collide, u-boot doesn't try to relocate itself (or scribble over memory), all of which is extra development that a JTAG[1] attached debugger would preclude. A JTAG debugger would allow you to load code directly into memory and then step through the processor initialization(or supply instructions on the fly!), low-level startup development that everyone does on a new processor. Also by stepping you can see where/when the processor is about to go off into the weeds many, many, many instructions _before_ it munches any hope of postmortem debugging. From experience bringing up boards w/o JTAG is not only tedious but unpredictable and takes a lng time - the extra cost/effort of integrating JTAG (especially since this is a spanking new processor!) is more than justified by it reducing both total development time and overall schedule risk... [1] I use JTAG to mean any industry standard hardware debug/access method that allows arbitrary execution and inspection/modification of registers/memory... -- Peter Barada peter.bar...@logicpd.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] disassembler ?
Dear Brad Walker, In message capkzhbu1wkxjz82o9v54lct482o7mfcn4yq_wniwl-tb8_-...@mail.gmail.com you wrote: Why not just use JTAG? We are doing new processor design, so it's not defined if the system will even have a JTAG interface. There are lots of systems that do not have a JTAG interface. I have no information what the target for your new processor might be; there is such systems that go to basically a single big customer / a single, highly specific use case, and there are those that are intended for general use - the more use cases the better. If you want to make your system easy to use for a big grouyp of people, then make sure that standard debug tools work. Include JTAG, and make sure it works with standard tools like the Abatron BDI2000/3000, Lauterbach Trace32 and OpenOCD etc. Why not use use objdump? We are in the process of porting binutils, so I currently don't have an objdump to use. I do have a manual disassembly routine that we created in h/w design to help us. But, until binutils has been ported, there is no objdump. Well, without a working binut=ils you cannot build U-Boot anyway, so you probably have to wait for that. I think the big issue that is confusing to me is why is BedBug still in U-Boot? Should i try and graft my work into BedBug? If so, then I'm happy BedBug is strill there, because it was useful for some (at some point of time), and it does not hurt to have it. I think the actual number of users is epsilon. to do the work and contribute it back to the group. But, if not, then I'll just go ahead implement the work independently. I'd recommend to save the efforts, and rather help the guys who are working on binutils. This is probably better invested time, then. 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 Everyting looks interesting until you do it. Then you find it's just another job. - Terry Pratchett, _Moving Pictures_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] wandboard: Disable data cache
Dear Fabio Estevam, In message 1369331424-25835-2-git-send-email-fabio.este...@freescale.com you wrote: Currently HDMI framebuffer only works if we disable data cache. Disable data cache until the proper fix is found. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- Hi, If someone has any suggestion for a proper fix, please let me know. Even without a proper fix this should not be done unconditionally. Please do this only when you actually have to, i. e. when really using the HDMI framebuffer in a system. It's not a good idea to let all others suffer from that. Also, I wonder if we should issue a warning then (at build time). 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 Gewöhnlich glaubt der Mensch, wenn er nur Worte hört, es müsse sich dabei doch auch was denken lassen. -- Goethe, Faust I ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] wandboard: Disable data cache
Hi Wolfgang, On Thu, May 23, 2013 at 6:12 PM, Wolfgang Denk w...@denx.de wrote: Even without a proper fix this should not be done unconditionally. Please do this only when you actually have to, i. e. when really using the HDMI framebuffer in a system. It's not a good idea to let all others suffer from that. Right, I should have marked this patch as RFC. Anatolij kindly pointed me to a patch that solves the problem, so this one can be discarded. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch v2 2/4] NET: macb: support sama5d3x devices
Hi, On Thu, May 23, 2013 at 1:51 AM, Andreas Bießmann andreas.de...@googlemail.com wrote: Hi Bo, On 22.05.13 10:45, Bo Shen wrote: Hi Andreas, On 5/14/2013 05:31, Joe Hershberger wrote: On Sun, May 12, 2013 at 6:33 AM, Andreas Bießmann andreas.de...@googlemail.com wrote: Dear Bo Shen, On 12.03.2013 07:15, Bo Shen wrote: Add macb support for sama5d3x devices Signed-off-by: Bo Shen voice.s...@atmel.com --- change in v2: No change --- drivers/net/macb.c |6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/net/macb.c b/drivers/net/macb.c index 8bacbda..9e7fbc6 100644 --- a/drivers/net/macb.c +++ b/drivers/net/macb.c @@ -469,7 +469,8 @@ static int macb_init(struct eth_device *netdev, bd_t *bd) #if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260) || \ defined(CONFIG_AT91SAM9263) || defined(CONFIG_AT91SAM9G20) || \ defined(CONFIG_AT91SAM9G45) || defined(CONFIG_AT91SAM9M10G45) || \ - defined(CONFIG_AT91SAM9XE) || defined(CONFIG_AT91SAM9X5) + defined(CONFIG_AT91SAM9XE) || defined(CONFIG_AT91SAM9X5) || \ + defined(CONFIG_SAMA5D3) I would like to apply http://patchwork.ozlabs.org/patch/239064/ instead of this one. Joe, do you have any objections? Agreed. Just remind to take this patch: net: macb: using AT91FAMILY replace #ifdeferry (http://patchwork.ozlabs.org/patch/239064/). or else the macb won't work with sama5d3xek board. I thought this would go through Joe's tree. There are some patches delegated to him regarding sama5 network too (gmac). I could pick up this single patch however, lets wait some days for Joe to work on the whole series. Yes, I hope to be getting to patches assigned to me in patchwork in the next week or so. -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 1/4] README: document CONFIG_ENV_IS_IN_MMC
S == Stephen Warren swar...@wwwdotorg.org writes: S From: Stephen Warren swar...@nvidia.com S Describe the meaning of CONFIG_ENV_IS_IN_MMC, and all related defines that S must or can be set when using that option. S Signed-off-by: Stephen Warren swar...@nvidia.com S --- S v3: S * Mention that env size/offset are in bytes. S * Fix typo; s/CONFIG_ENV_OFFSET/CONFIG_ENV_SIZE/ in one place. S v2: New patch. S --- S README | 40 S 1 file changed, 40 insertions(+) S diff --git a/README b/README S index 3012dcd..e7fedb8 100644 S --- a/README S +++ b/README S @@ -3606,6 +3606,46 @@ but it can not erase, write this NOR flash by SRIO or PCIE interface. S You will probably want to define these to avoid a really noisy system S when storing the env in UBI. S +- CONFIG_ENV_IS_IN_MMC: S + S + Define this if you have an MMC device which you want to use for the S + environment. S + S + - CONFIG_SYS_MMC_ENV_DEV: S + S + Specifies which MMC device the environment is stored in. S + S + - CONFIG_SYS_MMC_ENV_PART (optional): S + S + Specifies which MMC partition the environment is stored in. If not S + set, defaults to partition 0, the user area. Common values might be S + 1 (first MMC boot partition), 2 (second MMC boot partition). S + S + - CONFIG_ENV_OFFSET: S + - CONFIG_ENV_SIZE: S + S + These two #defines specify the offset and size of the environment S + area within the specified MMC device. S + S + These two values are in units of bytes, but must be aligned to an S + MMC sector boundary. s/to an/t a/ Other than that: Reviewed-by: Peter Korsgaard jac...@sunsite.dk -- Bye, Peter Korsgaard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] input: simplify key_matrix_decode_fdt()
From: Stephen Warren swar...@nvidia.com
We know the exact property names that the code wants to process. Look
these up directly with fdt_get_property(), rather than iterating over
all properties within the node, and checking each property's name, in
a convoluted fashion, against the expected name.
Signed-off-by: Stephen Warren swar...@nvidia.com
---
Note: This depends on my previous patch input: fix unaligned access
in key_matrix_decode_fdt(). While to two patches could be squashed
together, I'd prefer them to go in separately, since the former is a
bug-fix that makes the original code work again on ARMv7 at least, and
this patch is an unrelated refactoring.
---
drivers/input/key_matrix.c | 66 +---
1 file changed, 26 insertions(+), 40 deletions(-)
diff --git a/drivers/input/key_matrix.c b/drivers/input/key_matrix.c
index c8b048e..ea05c77 100644
--- a/drivers/input/key_matrix.c
+++ b/drivers/input/key_matrix.c
@@ -154,54 +154,40 @@ static uchar *create_keymap(struct key_matrix *config,
u32 *data, int len,
return map;
}
-int key_matrix_decode_fdt(struct key_matrix *config, const void *blob,
- int node)
+int key_matrix_decode_fdt(struct key_matrix *config, const void *blob, int
node)
{
const struct fdt_property *prop;
- static const char prefix[] = linux,;
- int plen = sizeof(prefix) - 1;
- int offset;
-
- /* Check each property name for ones that we understand */
- for (offset = fdt_first_property_offset(blob, node);
- offset 0;
- offset = fdt_next_property_offset(blob, offset)) {
- const char *name;
- int len;
-
- prop = fdt_get_property_by_offset(blob, offset, NULL);
- name = fdt_string(blob, fdt32_to_cpu(prop-nameoff));
- len = strlen(name);
-
- /* Name needs to match 1,typekeymap */
- debug(%s: property '%s'\n, __func__, name);
- if (strncmp(name, prefix, plen) ||
- len plen + 6 ||
- strcmp(name + len - 6, keymap))
- continue;
+ int proplen;
+ uchar *plain_keycode;
- len -= plen + 6;
- if (len == 0) {
- config-plain_keycode = create_keymap(config,
- (u32 *)prop-data, fdt32_to_cpu(prop-len),
- KEY_FN, config-fn_pos);
- } else if (0 == strncmp(name + plen, fn-, len)) {
- config-fn_keycode = create_keymap(config,
- (u32 *)prop-data, fdt32_to_cpu(prop-len),
- -1, NULL);
- } else {
- debug(%s: unrecognised property '%s'\n, __func__,
- name);
- }
- }
- debug(%s: Decoded key maps %p, %p from fdt\n, __func__,
- config-plain_keycode, config-fn_keycode);
+ prop = fdt_get_property(blob, node, linux,keymap, proplen);
+ /* Basic keymap is required */
+ if (!prop)
+ return -1;
+ plain_keycode = create_keymap(config, (u32 *)prop-data,
+ proplen, KEY_FN, config-fn_pos);
+ config-plain_keycode = plain_keycode;
+ /* Conversion error - fail */
+ if (!config-plain_keycode)
+ return -1;
+
+ prop = fdt_get_property(blob, node, linux,fn-keymap, proplen);
+ /* fn keymap is optional */
+ if (!prop)
+ goto done;
+
+ config-fn_keycode = create_keymap(config, (u32 *)prop-data,
+ proplen, -1, NULL);
+ /* Conversion error - fail */
if (!config-plain_keycode) {
- debug(%s: cannot find keycode-plain map\n, __func__);
+ free(plain_keycode);
return -1;
}
+done:
+ debug(%s: Decoded key maps %p, %p from fdt\n, __func__,
+ config-plain_keycode, config-fn_keycode);
return 0;
}
--
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 V3 1/4] README: document CONFIG_ENV_IS_IN_MMC
On 05/23/2013 03:59 PM, Peter Korsgaard wrote: S == Stephen Warren swar...@wwwdotorg.org writes: ... S + These two values are in units of bytes, but must be aligned to an S + MMC sector boundary. s/to an/to a/ http://owl.english.purdue.edu/owl/resource/540/1/ disagrees since the M starts with a vowel sound. See the An MSDS ... example. Either way though is fine by me though I guess. I assume Tom can fix that up when applying, so I don't need to spam the list with another resend. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: tegra: only enable SCU on Tegra20
From: Tom Warren twar...@nvidia.com The non-SPL build of U-Boot on Tegra only runs on a single CPU, and hence there is no need to enable the SCU when running U-Boot. If an SMP OS is booted, and it needs the SCU enabled, it will enable the SCU itself. U-Boot doing so is redundant. The one exception is Tegra20, where an enabled SCU is required for some aspects of PCIe to work correctly. Some Tegra SoCs contain CPUs without a software-controlled SCU. In this case, attempting to turn it on actively causes problems. This is the case for Tegra114. For example, when running Linux, the first (or at least some very early) user-space process will trigger the following kernel message: Unhandled fault: imprecise external abort (0x406) at 0x This is typically accompanied by that process receving a fatal signal, and exiting. Since this process is usually pid 1, this causes total system boot failure. Signed-off-by: Tom Warren twar...@nvidia.com [swarren, fleshed out description, ported to upstream chipid APIs] Signed-off-by: Stephen Warren swar...@nvidia.com --- arch/arm/cpu/tegra-common/ap.c |4 1 file changed, 4 insertions(+) diff --git a/arch/arm/cpu/tegra-common/ap.c b/arch/arm/cpu/tegra-common/ap.c index e099683..9e6d51d 100644 --- a/arch/arm/cpu/tegra-common/ap.c +++ b/arch/arm/cpu/tegra-common/ap.c @@ -109,6 +109,10 @@ static void enable_scu(void) struct scu_ctlr *scu = (struct scu_ctlr *)NV_PA_ARM_PERIPHBASE; u32 reg; + /* Only enable the SCU on T20/T25 */ + if (tegra_get_chip() != CHIPID_TEGRA20) + return; + /* If SCU already setup/enabled, return */ if (readl(scu-scu_ctrl) SCU_CTRL_ENABLE) return; -- 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 4/5][v5] board/bsc9131rdb:Add NAND boot support using new SPL format
On Tue, Apr 16, 2013 at 2:58 AM, Prabhakar Kushwaha prabha...@freescale.com wrote: - Add NAND boot target - defines contants - Add spl_minimal.c to initialise DDR - update TLB entries as per NAND boot Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com I'm currently applying your SYSCLK change which depends on this patch. As soon as I've pushed that upstream, could you rebase this patch on the top of my tree? That patch added the BSC9131RDB_NAND_SYSCLK100 target, which doesn't make sense without the initial NAND target, so this patch should now add that target in addition to the BSC9131RDB_NAND target. I should be pushing them up later today. Thanks, Andy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 1/4] README: document CONFIG_ENV_IS_IN_MMC
Stephen == Stephen Warren swar...@wwwdotorg.org writes: Stephen On 05/23/2013 03:59 PM, Peter Korsgaard wrote: S == Stephen Warren swar...@wwwdotorg.org writes: Stephen ... S + These two values are in units of bytes, but must be aligned to an S + MMC sector boundary. s/to an/to a/ Stephen http://owl.english.purdue.edu/owl/resource/540/1/ disagrees Stephen since the M starts with a vowel sound. See the An MSDS ... Stephen example. Ok, I'm not a native speaker. -- Bye, Peter Korsgaard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5][v5] board/bsc9131rdb:Add NAND boot support using new SPL format
On Thu, May 23, 2013 at 5:27 PM, Andy Fleming aflem...@gmail.com wrote: On Tue, Apr 16, 2013 at 2:58 AM, Prabhakar Kushwaha prabha...@freescale.com wrote: - Add NAND boot target - defines contants - Add spl_minimal.c to initialise DDR - update TLB entries as per NAND boot Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com I'm currently applying your SYSCLK change which depends on this patch. As soon as I've pushed that upstream, could you rebase this patch on the top of my tree? That patch added the BSC9131RDB_NAND_SYSCLK100 target, which doesn't make sense without the initial NAND target, so this patch should now add that target in addition to the BSC9131RDB_NAND target. I should be pushing them up later today. Nevermind. It looks like subsequent patches also conflict. I will apply the patches in the requested order. :) Andy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mx6slevk: Allow booting a device tree kernel
From: Fabio Estevam fabio.este...@freescale.com When the mx6slevk board support was added in U-boot there was no device tree support for mx6sl, so only a FSL 3.0.35 was tested at that time. Now that mx6slevk support is available we can boot a device tree kernel, by adjusting CONFIG_LOADADDR into a proper location, so that a non-dt and a dt kernels can be booted. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- include/configs/mx6slevk.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/mx6slevk.h b/include/configs/mx6slevk.h index 8a94efd..19dcdd6 100644 --- a/include/configs/mx6slevk.h +++ b/include/configs/mx6slevk.h @@ -59,7 +59,7 @@ #define CONFIG_BOOTDELAY 3 -#define CONFIG_LOADADDR0x8080 +#define CONFIG_LOADADDR0x8200 #define CONFIG_SYS_TEXT_BASE 0x8780 #define CONFIG_EXTRA_ENV_SETTINGS \ -- 1.8.1.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-cfi-flash/master
On Thu, May 23, 2013 at 09:55:37AM +0200, Stefan Roese wrote: Hi Tom, please pull some CFI fixes: The following changes since commit 8bcb6f43e98ffc76e998349e0ec32a0e359160d4: Update MAINTAINERS file for sandbox (2013-05-17 17:04:39 -0400) are available in the git repository at: git://www.denx.de/git/u-boot-cfi-flash.git master for you to fetch changes up to 24c185cf58a5bef1e0401a0f7e70526d6d9078c7: cfi_flash: return NULL for invalid base address input (2013-05-23 09:48:45 +0200) Andrew Gabbasov (1): cfi_flash: Fix unaligned accesses to cfi_qry structure Masahiro Yamada (2): cosmetic: cfi_flash: delete a space after an unary operator cfi_flash: return NULL for invalid base address input drivers/mtd/cfi_flash.c | 23 +-- include/mtd/cfi_flash.h | 18 +++--- 2 files changed, 24 insertions(+), 17 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] mtd: spi: winbond: add W25PXX support
2013/5/23 Jagan Teki jagannadh.t...@gmail.com:
On Thu, May 23, 2013 at 3:24 PM, Kuo-Jung Su dant...@gmail.com wrote:
2013/5/23 Jagan Teki jagannadh.t...@gmail.com:
Hi,
On Wed, May 22, 2013 at 6:31 AM, Kuo-Jung Su dant...@gmail.com wrote:
2013/5/22 Jagan Teki jagannadh.t...@gmail.com:
Hi,
I have a simple question like these parts are legacy flashes i guess.
Could you please tell me on which boards these were used?
It's used on Faraday A369 evaluation board.
However the u-boot source codes for A369 is still waiting for approval.
Here is the link to u-boot patchwork:
Ok, Thanks for your information.
http://patchwork.ozlabs.org/patch/242006/
Thanks,
Jagan.
On Fri, Apr 26, 2013 at 1:32 PM, Kuo-Jung Su dant...@gmail.com wrote:
From: Kuo-Jung Su dant...@faraday-tech.com
Signed-off-by: Kuo-Jung Su dant...@faraday-tech.com
---
drivers/mtd/spi/winbond.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/spi/winbond.c b/drivers/mtd/spi/winbond.c
index 2716209..2a27837 100644
--- a/drivers/mtd/spi/winbond.c
+++ b/drivers/mtd/spi/winbond.c
@@ -18,6 +18,21 @@ struct winbond_spi_flash_params {
static const struct winbond_spi_flash_params winbond_spi_flash_table[]
= {
{
+ .id = 0x2014,
+ .nr_blocks = 16,
+ .name = W25P80,
W25P80 is an 8Mbit flash right, is this name W25P80 or W25P08?
ofcourse, I have seen the same on datasheet as well.
It's W25P80.
They are formally NexFlash NX25P80, NX25P16 and NX25P32.
I've google for the W25P08, it looks like that Windond did have
some legacy small SPI flash: W25P01, W25P02 .. W25P16.
I guess it's a different production line...
BTW I don't have these chips and corresponding datasheet, too.
Ok.
Can you use the commit msg header as
sf: winbond:
Which is used for winbond mtd driver since from long, of-course not a
big deal and
also mentioned atleast single line message on body.
Sure, I'll re-format the patch and re-post again.
Simple recommendation here:.
Add support for Winbond's W25PXX SPI flash.
These devices is used on Faraday A369 evaluation board
Thanks.
It's pretty helpful to me, because my English is really terrible. :)
Thanks,
Jagan.
--
Best wishes,
Kuo-Jung Su
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] sf: winbond: Add support for W25PXX SPI flash
From: Kuo-Jung Su dant...@faraday-tech.com
Add support for Winbond's W25PXX SPI flash.
These devices is used on Faraday A369 evaluation board.
Signed-off-by: Kuo-Jung Su dant...@faraday-tech.com
CC: Jagan Teki jagannadh.t...@gmail.com
CC: Tom Rini tr...@ti.com
---
Changes for v2:
- Update commit message header
- Add commit message body
drivers/mtd/spi/winbond.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/spi/winbond.c b/drivers/mtd/spi/winbond.c
index 2716209..2a27837 100644
--- a/drivers/mtd/spi/winbond.c
+++ b/drivers/mtd/spi/winbond.c
@@ -18,6 +18,21 @@ struct winbond_spi_flash_params {
static const struct winbond_spi_flash_params winbond_spi_flash_table[] = {
{
+ .id = 0x2014,
+ .nr_blocks = 16,
+ .name = W25P80,
+ },
+ {
+ .id = 0x2015,
+ .nr_blocks = 32,
+ .name = W25P16,
+ },
+ {
+ .id = 0x2016,
+ .nr_blocks = 64,
+ .name = W25P32,
+ },
+ {
.id = 0x3013,
.nr_blocks = 8,
.name = W25X40,
@@ -104,7 +119,7 @@ struct spi_flash *spi_flash_probe_winbond(struct spi_slave
*spi, u8 *idcode)
}
flash-page_size = 256;
- flash-sector_size = 4096;
+ flash-sector_size = (idcode[1] == 0x20) ? 65536 : 4096;
flash-size = 4096 * 16 * params-nr_blocks;
return flash;
--
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 v2 2/4] NET: macb: support sama5d3x devices
Hi Andreas, On 5/23/2013 14:51, Andreas Bießmann wrote: Hi Bo, On 22.05.13 10:45, Bo Shen wrote: Hi Andreas, On 5/14/2013 05:31, Joe Hershberger wrote: On Sun, May 12, 2013 at 6:33 AM, Andreas Bießmann andreas.de...@googlemail.com wrote: Dear Bo Shen, On 12.03.2013 07:15, Bo Shen wrote: Add macb support for sama5d3x devices Signed-off-by: Bo Shen voice.s...@atmel.com --- change in v2: No change --- drivers/net/macb.c |6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/net/macb.c b/drivers/net/macb.c index 8bacbda..9e7fbc6 100644 --- a/drivers/net/macb.c +++ b/drivers/net/macb.c @@ -469,7 +469,8 @@ static int macb_init(struct eth_device *netdev, bd_t *bd) #if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260) || \ defined(CONFIG_AT91SAM9263) || defined(CONFIG_AT91SAM9G20) || \ defined(CONFIG_AT91SAM9G45) || defined(CONFIG_AT91SAM9M10G45) || \ - defined(CONFIG_AT91SAM9XE) || defined(CONFIG_AT91SAM9X5) + defined(CONFIG_AT91SAM9XE) || defined(CONFIG_AT91SAM9X5) || \ + defined(CONFIG_SAMA5D3) I would like to apply http://patchwork.ozlabs.org/patch/239064/ instead of this one. Joe, do you have any objections? Agreed. Just remind to take this patch: net: macb: using AT91FAMILY replace #ifdeferry (http://patchwork.ozlabs.org/patch/239064/). or else the macb won't work with sama5d3xek board. I thought this would go through Joe's tree. There are some patches delegated to him regarding sama5 network too (gmac). I could pick up this single patch however, lets wait some days for Joe to work on the whole series. OK, I will wait Joe to take these patches. Thanks. Best regards Andreas Bießmann Best Regards, Bo Shen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Building two different SPL for the same board?
tor 2013-05-23 klockan 16:39 -0400 skrev Tom Rini: My rather poor understanding of how some of the Freescale ARM parts do SPL is a lot more like this (whack things about, let ROM load next parts) than the SPL takes over, loads U-Boot method. And this is OK, in so far as it gets needed jobs done in the resources available. Got it integrated into the tree now and after config changes it could be reduced to only a dummy (empty) start.c + linker script. The binary grew by a few KB compared to the separate version, but still well within the margin. https://github.com/linux-sunxi/u-boot-sunxi/commit/79272ff764ee392d616feb02fb91c2dcaad42f04 Will show up for review in next round of submitting the sunxi changes. Regards Henrik ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MMC: DWMMC: Fix FIFO_DEPTH calculation
On 05/24/2013 03:27 AM, Jagan Teki wrote:
On Thu, May 23, 2013 at 6:45 PM, Rajeshwari Shinde
rajeshwar...@samsung.com wrote:
Current DWMMC driver used to give FIFO underrun/overrun error every 3rd time
for mmc rescan command.
In current code FIFO_DEPTH is getting calculated after reading the FIFOTH
register and extracting the RX_WMARK bits from it i.e (RX_WMARK =
FIFO_DEPTH/2 -1).
Instead of storing the correct value, we were recalculating the FIFO_DEPT
each
time which is not correct.
Signed-off-by: Hatim Ali hatim...@samsung.com
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
drivers/mmc/dw_mmc.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
index 4070d4e..be590a4 100644
--- a/drivers/mmc/dw_mmc.c
+++ b/drivers/mmc/dw_mmc.c
@@ -332,11 +332,13 @@ static int dwmci_init(struct mmc *mmc)
dwmci_writel(host, DWMCI_BMOD, 1);
fifo_size = dwmci_readl(host, DWMCI_FIFOTH);
- if (host-fifoth_val)
+ if (host-fifoth_val) {
What is the inital value for host-fifoth_val, for the first time call.?
It should be set into board-specific file(dw-mmc_exynos.c) or others.
Best Regards,
Jaehoon Chung
fifoth_val = host-fifoth_val;
- else
+ } else {
fifoth_val = MSIZE(0x2) | RX_WMARK(fifo_size/2 -1) |
TX_WMARK(fifo_size/2);
+ host-fifoth_val = fifoth_val;
+ }
dwmci_writel(host, DWMCI_FIFOTH, fifoth_val);
dwmci_writel(host, DWMCI_CLKENA, 0);
--
1.7.4.4
Thanks,
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] da830: add MMC support
Add MMC support for da830 boards in order to perform
mmc operations(read,write and erase).
Signed-off-by: Vishwanathrao Badarkhe, Manish manish...@ti.com
---
:100644 100644 c45c94b... bf014ae... M board/davinci/da8xxevm/da830evm.c
:100644 100644 198892b... 28995a0... M include/configs/da830evm.h
board/davinci/da8xxevm/da830evm.c | 48 +
include/configs/da830evm.h| 24 +-
2 files changed, 70 insertions(+), 2 deletions(-)
diff --git a/board/davinci/da8xxevm/da830evm.c
b/board/davinci/da8xxevm/da830evm.c
index c45c94b..bf014ae 100644
--- a/board/davinci/da8xxevm/da830evm.c
+++ b/board/davinci/da8xxevm/da830evm.c
@@ -44,6 +44,11 @@
#include asm/arch/nand_defs.h
#include asm/arch/davinci_misc.h
+#ifdef CONFIG_DAVINCI_MMC
+#include mmc.h
+#include asm/arch/sdmmc_defs.h
+#endif
+
DECLARE_GLOBAL_DATA_PTR;
/* SPI0 pin muxer settings */
@@ -153,6 +158,23 @@ static const struct pinmux_config usb_pins[] = {
{ pinmux(9), 1, 1 }
};
+#ifdef CONFIG_DAVINCI_MMC
+/* MMC0 pin muxer settings */
+const struct pinmux_config mmc0_pins[] = {
+ { pinmux(15), 2, 7 }, /* MMCSD0_CLK */
+ { pinmux(16), 2, 0 }, /* MMCSD0_CMD */
+ { pinmux(13), 2, 6 }, /* MMCSD0_DAT_0 */
+ { pinmux(13), 2, 7 }, /* MMCSD0_DAT_1 */
+ { pinmux(14), 2, 0 }, /* MMCSD0_DAT_2 */
+ { pinmux(14), 2, 1 }, /* MMCSD0_DAT_3 */
+ { pinmux(14), 2, 2 }, /* MMCSD0_DAT_4 */
+ { pinmux(14), 2, 3 }, /* MMCSD0_DAT_5 */
+ { pinmux(14), 2, 4 }, /* MMCSD0_DAT_6 */
+ { pinmux(14), 2, 5 }, /* MMCSD0_DAT_7 */
+ /* DA830 supports 8-bit mode */
+};
+#endif
+
static const struct pinmux_resource pinmuxes[] = {
#ifdef CONFIG_SPI_FLASH
PINMUX_ITEM(spi0_pins),
@@ -169,6 +191,9 @@ static const struct pinmux_resource pinmuxes[] = {
#if defined(CONFIG_DRIVER_TI_EMAC)
PINMUX_ITEM(emac_pins),
#endif
+#ifdef CONFIG_DAVINCI_MMC
+ PINMUX_ITEM(mmc0_pins),
+#endif
};
static const struct lpsc_resource lpsc[] = {
@@ -177,8 +202,31 @@ static const struct lpsc_resource lpsc[] = {
{ DAVINCI_LPSC_EMAC }, /* image download */
{ DAVINCI_LPSC_UART2 }, /* console */
{ DAVINCI_LPSC_GPIO },
+#ifdef CONFIG_DAVINCI_MMC
+ { DAVINCI_LPSC_MMC_SD },
+#endif
+
};
+#ifdef CONFIG_DAVINCI_MMC
+static struct davinci_mmc mmc_sd0 = {
+ .reg_base = (struct davinci_mmc_regs *)DAVINCI_MMC_SD0_BASE,
+ .host_caps = MMC_MODE_8BIT,
+ .voltages = MMC_VDD_32_33 | MMC_VDD_33_34,
+ .version = MMC_CTLR_VERSION_2,
+};
+
+int board_mmc_init(bd_t *bis)
+{
+ mmc_sd0.input_clk = clk_get(DAVINCI_MMCSD_CLKID);
+
+ printf(%x\n, mmc_sd0.input_clk);
+
+ /* Add slot-0 to mmc subsystem */
+ return davinci_mmc_init(bis, mmc_sd0);
+}
+#endif
+
int board_init(void)
{
#ifndef CONFIG_USE_IRQ
diff --git a/include/configs/da830evm.h b/include/configs/da830evm.h
index 198892b..28995a0 100644
--- a/include/configs/da830evm.h
+++ b/include/configs/da830evm.h
@@ -226,6 +226,28 @@
#define CONFIG_CMD_SAVEENV
#endif
+/* SD/MMC configuration */
+#ifndef CONFIG_USE_NAND
+#define CONFIG_MMC
+#define CONFIG_DAVINCI_MMC_SD1
+#define CONFIG_GENERIC_MMC
+#define CONFIG_DAVINCI_MMC
+#endif
+
+/*
+ * Enable MMC commands only when
+ * MMC support is present
+ */
+#if defined(CONFIG_MMC) || defined(CONFIG_USB_DA8XX)
+#define CONFIG_DOS_PARTITION /* include support for FAT/storage */
+#define CONFIG_CMD_FAT /* include support for FAT cmd */
+#endif
+
+#ifdef CONFIG_MMC
+#define CONFIG_CMD_MMC
+#define CONFIG_CMD_EXT2
+#endif
+
#if !defined(CONFIG_USE_NAND) \
!defined(CONFIG_USE_NOR) \
!defined(CONFIG_USE_SPIFLASH)
@@ -244,8 +266,6 @@
#define CONFIG_USB_STORAGE /* MSC class support */
#define CONFIG_CMD_STORAGE /* inclue support for usb-storage cmd */
-#define CONFIG_CMD_FAT /* inclue support for FAT/storage */
-#define CONFIG_DOS_PARTITION /* inclue support for FAT/storage */
#ifdef CONFIG_USB_KEYBOARD /* HID class support */
#define CONFIG_SYS_USB_EVENT_POLL
--
1.7.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MMC: DWMMC: Fix FIFO_DEPTH calculation
Acked-by: Jaehoon Chung jh80.ch...@samsung.com
On 05/23/2013 10:15 PM, Rajeshwari Shinde wrote:
Current DWMMC driver used to give FIFO underrun/overrun error every 3rd time
for mmc rescan command.
In current code FIFO_DEPTH is getting calculated after reading the FIFOTH
register and extracting the RX_WMARK bits from it i.e (RX_WMARK =
FIFO_DEPTH/2 -1).
Instead of storing the correct value, we were recalculating the FIFO_DEPT each
time which is not correct.
Signed-off-by: Hatim Ali hatim...@samsung.com
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
drivers/mmc/dw_mmc.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
index 4070d4e..be590a4 100644
--- a/drivers/mmc/dw_mmc.c
+++ b/drivers/mmc/dw_mmc.c
@@ -332,11 +332,13 @@ static int dwmci_init(struct mmc *mmc)
dwmci_writel(host, DWMCI_BMOD, 1);
fifo_size = dwmci_readl(host, DWMCI_FIFOTH);
- if (host-fifoth_val)
+ if (host-fifoth_val) {
fifoth_val = host-fifoth_val;
- else
+ } else {
fifoth_val = MSIZE(0x2) | RX_WMARK(fifo_size/2 -1) |
TX_WMARK(fifo_size/2);
+ host-fifoth_val = fifoth_val;
+ }
dwmci_writel(host, DWMCI_FIFOTH, fifoth_val);
dwmci_writel(host, DWMCI_CLKENA, 0);
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MMC: DWMMC: Fix FIFO_DEPTH calculation
On Fri, May 24, 2013 at 7:12 AM, Jaehoon Chung jh80.ch...@samsung.com wrote:
On 05/24/2013 03:27 AM, Jagan Teki wrote:
On Thu, May 23, 2013 at 6:45 PM, Rajeshwari Shinde
rajeshwar...@samsung.com wrote:
Current DWMMC driver used to give FIFO underrun/overrun error every 3rd time
for mmc rescan command.
In current code FIFO_DEPTH is getting calculated after reading the FIFOTH
register and extracting the RX_WMARK bits from it i.e (RX_WMARK =
FIFO_DEPTH/2 -1).
Instead of storing the correct value, we were recalculating the FIFO_DEPT
each
time which is not correct.
Signed-off-by: Hatim Ali hatim...@samsung.com
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
drivers/mmc/dw_mmc.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
index 4070d4e..be590a4 100644
--- a/drivers/mmc/dw_mmc.c
+++ b/drivers/mmc/dw_mmc.c
@@ -332,11 +332,13 @@ static int dwmci_init(struct mmc *mmc)
dwmci_writel(host, DWMCI_BMOD, 1);
fifo_size = dwmci_readl(host, DWMCI_FIFOTH);
- if (host-fifoth_val)
+ if (host-fifoth_val) {
What is the inital value for host-fifoth_val, for the first time call.?
It should be set into board-specific file(dw-mmc_exynos.c) or others.
I am unable to find dw-mmc_exynos.c on the master, and also I haven't
see fifoth_val used other than dw_mmc.c
Could you please help me out.
Thanks,
Jagan.
Best Regards,
Jaehoon Chung
fifoth_val = host-fifoth_val;
- else
+ } else {
fifoth_val = MSIZE(0x2) | RX_WMARK(fifo_size/2 -1) |
TX_WMARK(fifo_size/2);
+ host-fifoth_val = fifoth_val;
+ }
dwmci_writel(host, DWMCI_FIFOTH, fifoth_val);
dwmci_writel(host, DWMCI_CLKENA, 0);
--
1.7.4.4
Thanks,
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V9 0/9] EXYNOS5: Enable DWMMC, add FDT support for DWMMC and enable EMMC boot
Hi Andy, Please do let us know if any comments on this patch set. If no comments can we get them merged, as they seem to be floating in mainline for quite sometime now. Regards, Rajeshwari Shinde On Sat, May 11, 2013 at 8:55 AM, Simon Glass s...@chromium.org wrote: On Sat, Apr 27, 2013 at 12:12 AM, amar_g amarendra...@samsung.com wrote: From: Amar amarendra...@samsung.com This patch set enables and initialises DWMMC for Exynos5250 on SMDK5250. Adds driver changes required for DWMMC. Adds FDT support for DWMMC. Adds EMMC boot support for SMDK5250. This patch set is based on: EXYNOS: mmc: support DesignWare Controller for Samsung-SoC, which is merged in u-boot-mmc. Exynos: clock: support get_mmc_clk for exynos. Add DT based ethernet driver for SMDK5250. SMDK5250: Add FDT support present at the following link http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/149991 Changes since V1: 1)Corrected in response to review comments. 2)Created separate board files for FDT and non-FDT versions. 3)Added binding file for DWMMC device node. 4)Removed the propname 'index' from device node. 5)Prefixed the vendor name 'samsung' before propname in device node. 6)Ensured to have same signature for the function exynos_dwmci_init() for both FDT and non-FDT versions. 7)EMMC clock setting has been moved from spl_boot.c to clock_init.c. Changes since V2: 1)Updation of commit message and resubmition of proper patch set. Changes since V3: 1)Updated to use the macro DWMCI_CTRL_SEND_AS_CCSD instead of the hard coded value (1 10). 2)In the file exynos_dw_mmc.c, replaced the new function exynos5_mmc_set_clk_div() with the existing function set_mmc_clk(). set_mmc_clk() will do the purpose. 3)In the file exynos_dw_mmc.c, computation of FSYS block clock divisor (pre-ratio) value is added. 4)Removed the new function exynos5_mmc_set_clk_div() from clock.c. Changes since V4: 1)Updated the function dwmci_send_cmd() to use get_timer() instead of using mdelay(1). 2)Replaced the function call 'exynos_dwmmc_init(0, 8);' with the function exynos_dwmmc_add_port() in smdk5250.c. 3)The function get_irom_func(int index) has been added to avoid type casting at many places. 4)Used the generic function mmc_boot_part_access() instead of two functions mmc_boot_open() and mmc_boot_close(). By doing so user can specify which boot partition to be accessed (opened / closed). Changes since V5: 1)Added the 'removable' flag to mmc device node. 2)Changed the mmc clock value from 50MHz to 52MHz in the function exynos_dwmci_add_port() present in file drivers/mmc/exynos_dw_mmc.c. 3)Enabled CONFIG_LCD only for non-FDT operation. 4)Removed the function call i2c_init() present inside the function board_i2c_init(). Changes since V6: 1)Re-based to the patch SMDK5250: Add PMIC voltage settings. Changes since V7: 1)Re-based to the patch Exynos: pwm: Remove dead code of function exynos5_get_pwm_clk. 2)In file dw_mmc.c, updated the function dwmci_setup_bus() to return 0 if (freq == 0).This is to avoid the run time exception raise:Signal # 8 caught. 3)In the files drivers/mmc/mmc.c and common/cmd_mmc.c, the piece of code involved in EMMC open/close and resize of EMMC boot partition has been made conditional and is enabled only if the macro CONFIG_SUPPORT_EMMC_BOOT is defined. 4)The macros FSYS1_MMC0_DIV_MASK and FSYS1_MMC0_DIV_VAL are made local to file clock_init.c. Changes since V8: 1)Re-based to the patch exynos: fdt: Add TMU node for snow. 2)In spl_boot.c, updated USB boot piece of code, to use get_irom_func(int index) to avoid type casting. 3)Updated the below in response to review comments a)Changed the type of input parameters from u32 to u8 for the function boot_part_access(). b)Updated the function call to use a constant value 1, for boot_part_access(mmc, 1, part_num, access). c)In function dwmci_init, auto stop command is disabled, as this feature is not required. The series tested on snow: Acked-by: Simon Glass s...@chromium.org Tested-by: Simon Glass s...@chromium.org Amar (9): FDT: Add compatible string for DWMMC EXYNOS5: FDT: Add DWMMC device node data DWMMC: Initialise dwmci and resolve EMMC read write issues EXYNOS5: DWMMC: Added FDT support for DWMMC EXYNOS5: DWMMC: Initialise the local variable to avoid unwanted results. SMDK5250: Initialise and Enable DWMMC, support FDT and non-FDT MMC: APIs to support resize of EMMC boot partition SMDK5250: Enable EMMC booting COMMON: MMC: Command to support
