[U-Boot] [PATCH] common: board_f: Do not call board_postclk_init twice
The generic-board board_init_f function called board_postclk_init twice.
The first one came from arch/arm/lib/board.c, while the second one
from arch/powerpc/lib/board.c.
This commit deletes the first occurrence.
In addition, the second get_clocks call is moved after
board_postclk_init in order to keep the function call order
both for ARM and PowerPC.
ARM board calles get_clocks function after board_postclk_init.
Signed-off-by: Masahiro Yamada
---
common/board_f.c |9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/common/board_f.c b/common/board_f.c
index 81edbdf..9fa7363 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -851,12 +851,6 @@ static init_fnc_t init_sequence_f[] = {
#ifdef CONFIG_ARM
timer_init, /* initialize timer */
#endif
-#ifdef CONFIG_BOARD_POSTCLK_INIT
- board_postclk_init,
-#endif
-#ifdef CONFIG_FSL_ESDHC
- get_clocks,
-#endif
#ifdef CONFIG_SYS_ALLOC_DPRAM
#if !defined(CONFIG_CPM2)
dpram_init,
@@ -865,6 +859,9 @@ static init_fnc_t init_sequence_f[] = {
#if defined(CONFIG_BOARD_POSTCLK_INIT)
board_postclk_init,
#endif
+#ifdef CONFIG_FSL_ESDHC
+ get_clocks,
+#endif
env_init, /* initialize environment */
#if defined(CONFIG_8xx_CPUCLK_DEFAULT)
/* get CPU and bus clocks according to the environment variable */
--
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] common/Makefile: Add new symbol CONFIG_SPL_ENV_SUPPORT for environment in SPL
-Original Message- From: Stefan Roese [mailto:s...@denx.de] Sent: Wednesday, May 22, 2013 2:09 PM To: Wood Scott-B07421 Cc: Zhang Ying-B40530; Wood Scott-B07421; x...@theia.denx.de; u-boot@lists.denx.de; aflem...@gmail.com Subject: Re: [U-Boot] [PATCH] common/Makefile: Add new symbol CONFIG_SPL_ENV_SUPPORT for environment in SPL (sorry for jumping in so late in this discussion) On 05/21/2013 09:14 PM, Scott Wood wrote: >> This is Tom's words: >> >> a3m071 relies on SPL always building cmd_nvedit.o and env_common.o and >> duplicated CONFIG_ENV_IS_IN_FLASH in the SPL section. >> >> CONFIG_SPL_NET_SUPPORT relies on the same always-built ins and adds >> env_nowhere.o which works because the regular CONFIG_ENV_IS_IN_... >> >> section is in the non-SPL-only area. > > If "SPL: Makefile: Build a separate autoconf.mk for SPL" gets merged, > we could just have a3m071 define CONFIG_ENV_IS_NOWHERE in the SPL build > case. But the a3m071 SPL U-Boot version also uses the env from NOR flash. So defining CONFIG_ENV_IS_NOWHERE here would be really confusing! [Zhang Ying] I think Scott means that the specific boards CONFIG_SPL_NET_SUPPORT is set should define CONFIG_ENV_IS_NOWHERE in the SPL build case. For example: am335x and pcm051. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 6/6] arm: mvf600: Add basic support for Vybrid MVF600TWR board
Hi, Benoit, > > On Tuesday, May 21, 2013 11:03:01 AM, Alison Wang wrote: > > MVF600TWR is a board based on Vybrid MVF600 SoC. > > > > This patch adds basic support for Vybrid MVF600TWR board. > > > > Signed-off-by: Alison Wang > > Signed-off-by: Jason Jin > > Signed-off-by: TsiChung Liew > > [...] > > > diff --git a/board/freescale/mvf600twr/mvf600twr.c > > b/board/freescale/mvf600twr/mvf600twr.c > > new file mode 100644 > > index 000..71ee12b > > --- /dev/null > > +++ b/board/freescale/mvf600twr/mvf600twr.c > > @@ -0,0 +1,413 @@ > > +/* > > + * Copyright 2013 Freescale Semiconductor, Inc. > > + * > > + * This program is free software; you can redistribute it and/or > > + * modify it under the terms of the GNU General Public License as > > + * published by the Free Software Foundation; either version 2 of > > + * the License, or (at your option) any later version. > > + * > > + * This program is distributed in the hope that it will be useful, > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > > + * GNU General Public License for more details. > > + * > > + * You should have received a copy of the GNU General Public License > > + * along with this program; if not, write to the Free Software > > + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, > > + * MA 02111-1307 USA > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +DECLARE_GLOBAL_DATA_PTR; > > + > > +#define UART_PAD_CTRL (PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED > | \ > > + PAD_CTL_DSE_25ohm | PAD_CTL_OBE_IBE_ENABLE) > > + > > +#define ESDHC_PAD_CTRL (PAD_CTL_PUE | PAD_CTL_PUS_100K_UP | \ > > + PAD_CTL_SPEED_HIGH | PAD_CTL_DSE_20ohm | \ > > + PAD_CTL_OBE_IBE_ENABLE) > > With the changes that I have suggested in my review of your IOMUX patch, > ESDHC_PAD_CTRL could be simplified by removing PAD_CTL_PUE. > > And without those changes, UART_PAD_CTRL and ENET_PAD_CTRL in your > current code set pull values that are actually unused (unless the > corresponding PKE/PUE bits do not exist and default to pull in the pad > control registers used with these definitions). [Alison Wang] Agree. > > > + > > +#define ENET_PAD_CTRL (PAD_CTL_PUS_47K_UP | PAD_CTL_SPEED_HIGH > | \ > > + PAD_CTL_DSE_50ohm | PAD_CTL_OBE_IBE_ENABLE) > > + > > +#define DDR_PAD_CTRL PAD_CTL_DSE_25ohm > > MUX_PAD_CTRL() could be added to the 4 pad control definitions above in > order to avoid repeating it everywhere below. But using MUX_PAD_CTRL() > relies on the fact that the pad control values in mvf_pins.h are all 0 > (which is the case, but this is dangerous if this is changed later), so > a better approach could be to use NEW_PAD_CTRL(), e.g.: > NEW_PAD_CTRL(MVF600_PAD_DDR_A15__DDR_A_15, DDR_PAD_CTRL), > instead of: > MVF600_PAD_DDR_A15__DDR_A_15 | MUX_PAD_CTRL(DDR_PAD_CTRL), > > > + [Alison Wang] I have a question about using NEW_PAD_CTRL(). If NEW_PAD_CTRL() is used, should the pad control values for MVF600_PAD_DDR_A15__DDR_A_15 in mvf_pins.h be the same as DDR_PAD_CTRL? I saw you didn't use the same value on other platforms, how do you define it? Best Regards, Alison Wang ___ 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/14/2013 05:31, Joe Hershberger wrote: On Sun, May 12, 2013 at 6:33 AM, Andreas Bießmann wrote: Dear Bo Shen, On 12.03.2013 07:15, Bo Shen wrote: Add macb support for sama5d3x devices Signed-off-by: Bo Shen --- 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. -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot Best Regards, Bo Shen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] please pull u-boot-atmel/master
Hi Andreas, On Tue, 21 May 2013 11:59:26 +0200, Andreas Bießmann wrote: > Dear Albert Aribaud, > > please pull the following changes from u-boot-atmel/master into > u-boot-arm/master. > > The following changes since commit d0a51373131c4ba565a2391d5ed78b87c406ce98: > > at91sam9260ek: move board id setup to config header (2013-05-12 16:49:14 > +0200) > > are available in the git repository at: > > git://git.denx.de/u-boot-atmel.git master > > for you to fetch changes up to 5ba444f092ae9f68a0bd1f53956be2e69d26cf61: > > ARM: at91: add NAND partition table and index (2013-05-21 11:54:21 +0200) > > > Bo Shen (6): > ARM: at91: add Atmel sama5d3 SoC new pmc register > USB: ohci-at91: support sama5d3x devices > ARM: atmel: add sama5d3xek support > ARM: at91: fix and update README.at91 document > ARM: at91: add at91sam9x5 and sama5d3x information > ARM: at91: add NAND partition table and index > > MAINTAINERS |1 + > arch/arm/cpu/armv7/at91/Makefile | 52 + > arch/arm/cpu/armv7/at91/clock.c | 125 > arch/arm/cpu/armv7/at91/cpu.c| 90 + > arch/arm/cpu/armv7/at91/reset.c | 47 + > arch/arm/cpu/armv7/at91/sama5d3_devices.c| 196 ++ > arch/arm/cpu/armv7/at91/timer.c | 139 + > arch/arm/include/asm/arch-at91/at91_dbu.h|4 + > arch/arm/include/asm/arch-at91/at91_pmc.h| 23 +++ > arch/arm/include/asm/arch-at91/clk.h |1 + > arch/arm/include/asm/arch-at91/hardware.h|2 + > arch/arm/include/asm/arch-at91/sama5d3.h | 212 > arch/arm/include/asm/arch-at91/sama5d3_smc.h | 79 > board/atmel/sama5d3xek/Makefile | 51 + > board/atmel/sama5d3xek/sama5d3xek.c | 275 > ++ > boards.cfg |3 + > doc/README.at91 | 84 ++-- > drivers/usb/host/ohci-at91.c | 14 +- > include/configs/sama5d3xek.h | 245 +++ > 19 files changed, 1624 insertions(+), 19 deletions(-) > create mode 100644 arch/arm/cpu/armv7/at91/Makefile > create mode 100644 arch/arm/cpu/armv7/at91/clock.c > create mode 100644 arch/arm/cpu/armv7/at91/cpu.c > create mode 100644 arch/arm/cpu/armv7/at91/reset.c > create mode 100644 arch/arm/cpu/armv7/at91/sama5d3_devices.c > create mode 100644 arch/arm/cpu/armv7/at91/timer.c > create mode 100644 arch/arm/include/asm/arch-at91/sama5d3.h > create mode 100644 arch/arm/include/asm/arch-at91/sama5d3_smc.h > create mode 100644 board/atmel/sama5d3xek/Makefile > create mode 100644 board/atmel/sama5d3xek/sama5d3xek.c > create mode 100644 include/configs/sama5d3xek.h 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
[U-Boot] [PATCH] mmc write bug fix
This patch fixes a bug related to mmc writes. When doing fatwrites on an SD-Card, MMC bus problems can occur. Depending on the size of the file, "MMC0: Bus busy timeout!" is reported, resulting in an SD-Card that is no longer responding. It appears to be, that set_cluster can be called with a size being zero. That can be with a file that has a size being an exact multiple (including 0) of the clustersize, but also for files that are smaller than the size of one cluster. The same problem occurs if the "mmc write" command is given with a block count being 0. By adding a check for the block count being zero in mmc_write_blocks (drivers/mmc.c), this problem is solved. Signed-off-by: Ruud Commandeur Cc: Tom Rini Cc: Benoît Thébaudeau Cc: Mats Karrman Cc: Andy Fleming Index: drivers/mmc/mmc.c === --- drivers/mmc/mmc.c (revision 9) +++ drivers/mmc/mmc.c (revision 35) @@ -280,10 +280,12 @@ return 0; } - if (blkcnt > 1) - cmd.cmdidx = MMC_CMD_WRITE_MULTIPLE_BLOCK; - else + if (blkcnt == 0) + return 0; + else if (blkcnt == 1) cmd.cmdidx = MMC_CMD_WRITE_SINGLE_BLOCK; + else + cmd.cmdidx = MMC_CMD_WRITE_MULTIPLE_BLOCK; if (mmc->high_capacity) cmd.cmdarg = start; ___ 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
Dear Marek Vasut, On Tue, 2013-05-21 at 23:38 +0200, Marek Vasut wrote: > > 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 see I don't know enough to continue the discussion, yet. Concerning the patch in question, is it possible to allow cache for ram on PXA270 somehow before we have a final solution? ___ 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
Dear Sergey Yanovich, > Dear Marek Vasut, > > On Tue, 2013-05-21 at 23:38 +0200, Marek Vasut wrote: > > > 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 see I don't know enough to continue the discussion, yet. > > Concerning the patch in question, is it possible to allow cache for ram > on PXA270 somehow before we have a final solution? I dont mind discussing this further and even using DCache for stack in board_init_f(), but we must make sure nothing gets broken. Best regards, Marek Vasut ___ 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
Dear Marek Vasut, On Wed, 2013-05-22 at 15:04 +0200, Marek Vasut wrote: > > Concerning the patch in question, is it possible to allow cache for ram > > on PXA270 somehow before we have a final solution? > > I dont mind discussing this further and even using DCache for stack in > board_init_f(), but we must make sure nothing gets broken. If it is possible, I would like to have a configuration option, which allows to use D-Cache as RAM not only on PXA25X, but also on PXA27X. I propose to preserve status-quo for now and only use D-Cache as RAM when it is explicitly configured so. You mentioned in a separate letter, that config options need documenting. This part is missing in my patch, and I'll fix this, if the above is OK. ___ 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
Dear Sergey Yanovich, > Dear Marek Vasut, > > On Wed, 2013-05-22 at 15:04 +0200, Marek Vasut wrote: > > > Concerning the patch in question, is it possible to allow cache for ram > > > on PXA270 somehow before we have a final solution? > > > > I dont mind discussing this further and even using DCache for stack in > > board_init_f(), but we must make sure nothing gets broken. > > If it is possible, I would like to have a configuration option, which > allows to use D-Cache as RAM not only on PXA25X, but also on PXA27X. I > propose to preserve status-quo for now and only use D-Cache as RAM when > it is explicitly configured so. See above, let's do it properly please. Check the OneNAND SPL config on vpac270 board, will it still work with this enabled? > You mentioned in a separate letter, that config options need > documenting. This part is missing in my patch, and I'll fix this, if the > above is OK. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 09/10] MIPS: bootm.c: add YAMON style Linux preparation/jump code
Signed-off-by: Gabor Juhos
Cc: Daniel Schwierzeck
---
Changes since v2:
- rebased against the master branch of git.denx.de/u-boot.git
Changes since v1:
- rebased against mips/testing
Changes since RFC: ---
---
arch/mips/lib/bootm.c | 60 +++--
1 file changed, 58 insertions(+), 2 deletions(-)
diff --git a/arch/mips/lib/bootm.c b/arch/mips/lib/bootm.c
index a36154a..85492e5 100644
--- a/arch/mips/lib/bootm.c
+++ b/arch/mips/lib/bootm.c
@@ -33,6 +33,12 @@ DECLARE_GLOBAL_DATA_PTR;
#defineLINUX_MAX_ENVS 256
#defineLINUX_MAX_ARGS 256
+#if defined(CONFIG_QEMU_MALTA)
+#define board_is_qemu_malta1
+#else
+#define board_is_qemu_malta0
+#endif
+
static int linux_argc;
static char **linux_argv;
@@ -43,7 +49,7 @@ static int linux_env_idx;
static void linux_params_init(ulong start, char *commandline);
static void linux_env_set(char *env_name, char *env_val);
-static void boot_prep_linux(bootm_headers_t *images)
+static void boot_prep_linux_legacy(bootm_headers_t *images)
{
char *commandline = getenv("bootargs");
char env_buf[12];
@@ -83,6 +89,52 @@ static void boot_prep_linux(bootm_headers_t *images)
linux_env_set("eth1addr", cp);
}
+static void malta_env_set(char *env_name, char *env_val)
+{
+ if (linux_env_idx >= LINUX_MAX_ENVS - 2)
+ return;
+
+ linux_env[linux_env_idx] = linux_env_p;
+
+ strcpy(linux_env_p, env_name);
+ linux_env_p += strlen(env_name);
+
+ linux_env_p++;
+ linux_env[++linux_env_idx] = linux_env_p;
+
+ strcpy(linux_env_p, env_val);
+ linux_env_p += strlen(env_val);
+
+ linux_env_p++;
+ linux_env[++linux_env_idx] = 0;
+}
+
+static void boot_prep_linux_qemu_malta(bootm_headers_t *images)
+{
+ char *bootargs = getenv("bootargs");
+ char env_buf[12];
+ char *cp;
+
+ linux_params_init(UNCACHED_SDRAM(gd->bd->bi_boot_params), bootargs);
+
+ /* setup environment variables */
+ sprintf(env_buf, "%lu", (ulong)gd->ram_size);
+ malta_env_set("memsize", env_buf);
+ malta_env_set("modetty0", "38400n8r");
+
+ cp = getenv("ethaddr");
+ if (cp)
+ malta_env_set("ethaddr", cp);
+}
+
+static void boot_prep_linux(bootm_headers_t *images)
+{
+ if (board_is_qemu_malta)
+ boot_prep_linux_qemu_malta(images);
+ else
+ boot_prep_linux_legacy(images);
+}
+
static void boot_jump_linux(bootm_headers_t *images)
{
void (*theKernel) (int, char **, char **, int *);
@@ -98,7 +150,11 @@ static void boot_jump_linux(bootm_headers_t *images)
/* we assume that the kernel is in place */
printf("\nStarting kernel ...\n\n");
- theKernel(linux_argc, linux_argv, linux_env, 0);
+ if (board_is_qemu_malta)
+ theKernel(linux_argc, linux_argv, linux_env,
+ (int *)gd->ram_size);
+ else
+ theKernel(linux_argc, linux_argv, linux_env, 0);
}
int do_bootm_linux(int flag, int argc, char * const argv[],
--
1.7.10
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 02/10] MIPS: qemu-malta: add reset support
The MIPS Malta board has a SOFTRES register. Writing a
magic value into that register initiates a board reset.
Use this feature to implement reset support.
Signed-off-by: Gabor Juhos
Cc: Daniel Schwierzeck
---
Changes since v2:
- don't use le32_to_cpu accessor, it is not needed because
the __raw_* IO accessors has been fixed mainline
- rebased against the master branch of git.denx.de/u-boot.git
Changes since v1:
- rebased against mips/testing
Changes since RFC: ---
Screenshot:
U-Boot 2013.04-00238-g0320f0c (May 21 2013 - 22:31:20)
Board: MIPS Malta CoreLV (Qemu)
DRAM: 256 MiB
Using default environment
In:serial
Out: serial
Err: serial
qemu-malta # reset
U-Boot 2013.04-00238-g0320f0c (May 21 2013 - 22:31:20)
Board: MIPS Malta CoreLV (Qemu)
DRAM: 256 MiB
Using default environment
In:serial
Out: serial
Err: serial
qemu-malta #
---
arch/mips/include/asm/malta.h |3 +++
board/qemu-malta/qemu-malta.c | 11 +++
2 files changed, 14 insertions(+)
diff --git a/arch/mips/include/asm/malta.h b/arch/mips/include/asm/malta.h
index b215164..f2bbf0f 100644
--- a/arch/mips/include/asm/malta.h
+++ b/arch/mips/include/asm/malta.h
@@ -13,4 +13,7 @@
#define MALTA_UART_BASE(MALTA_IO_PORT_BASE + 0x3f8)
+#define MALTA_RESET_BASE 0x1f000500
+#define GORESET0x42
+
#endif /* _MIPS_ASM_MALTA_H */
diff --git a/board/qemu-malta/qemu-malta.c b/board/qemu-malta/qemu-malta.c
index 9ba711d..449da9c 100644
--- a/board/qemu-malta/qemu-malta.c
+++ b/board/qemu-malta/qemu-malta.c
@@ -8,6 +8,9 @@
#include
+#include
+#include
+
phys_size_t initdram(int board_type)
{
return CONFIG_SYS_MEM_SIZE;
@@ -18,3 +21,11 @@ int checkboard(void)
puts("Board: MIPS Malta CoreLV (Qemu)\n");
return 0;
}
+
+void _machine_restart(void)
+{
+ void __iomem *reset_base;
+
+ reset_base = (void __iomem *)CKSEG1ADDR(MALTA_RESET_BASE);
+ __raw_writel(GORESET, reset_base);
+}
--
1.7.10
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 07/10] net: pcnet: use pci_virt_to_mem to obtain buffer addresses
The pcnet driver uses the pci_phys_to_mem function
to get the memory address of the DMA buffers. This
This assumes an 1:1 mapping between the PCI and
physical memory which is not true on all platforms.
On MIPS platform U-Boot is running within a mapped
memory region, and the pci_phys_to_mem macro can't
be used to obtain the memory address of the buffers.
Signed-off-by: Gabor Juhos
Cc: Daniel Schwierzeck
---
Changes since v2:
- rebased against the master branch of git.denx.de/u-boot.git
Changes since v1:
- rebased against mips/testing
Changes since RFC: ---
---
Note:
This is only tested with the qemu-malta target. The change
might break real platforms, however I have no suitable board
to test it.
-Gabor
---
drivers/net/pcnet.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/pcnet.c b/drivers/net/pcnet.c
index c028a44..45a66fb 100644
--- a/drivers/net/pcnet.c
+++ b/drivers/net/pcnet.c
@@ -146,7 +146,7 @@ static int pcnet_recv (struct eth_device *dev);
static void pcnet_halt (struct eth_device *dev);
static int pcnet_probe (struct eth_device *dev, bd_t * bis, int dev_num);
-#define PCI_TO_MEM(d,a) pci_phys_to_mem((pci_dev_t)d->priv, (u_long)(a))
+#define PCI_TO_MEM(d, a) pci_virt_to_mem((pci_dev_t)d->priv, (a))
#define PCI_TO_MEM_LE(d,a) (u32)(cpu_to_le32(PCI_TO_MEM(d,a)))
static struct pci_device_id supported[] = {
--
1.7.10
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 03/10] MIPS: qemu-malta: enable flash support
Signed-off-by: Gabor Juhos Cc: Daniel Schwierzeck --- Changes since v2: - remove CONFIG_SYS_WRITE_SWAPPED_DATA option, it is not needed since the __raw_* IO accessors has been fixed. - rebased against the master branch of git.denx.de/u-boot.git Changes since v1: - rebased against mips/testing Changes since RFC: --- Screenshot: U-Boot 2013.04-00239-gea7c438 (May 22 2013 - 13:03:22) Board: MIPS Malta CoreLV (Qemu) DRAM: 256 MiB pflash_write: Unimplemented flash cmd sequence (offset , wcycle 0x0 cmd 0x0 value 0xf0) Flash: 4 MiB Using default environment In:serial Out: serial Err: serial qemu-malta # flinfo Bank # 1: CFI conformant flash (32 x 32) Size: 4 MB in 64 Sectors Intel Extended command set, Manufacturer ID: 0x00, Device ID: 0x00 Erase timeout: 16384 ms, write timeout: 3 ms Buffer write timeout: 3 ms, buffer size: 2048 bytes Sector Start Addresses: BFC0 RO BFC1 RO BFC2BFC3BFC4 BFC5BFC6BFC7BFC8BFC9 BFCABFCBBFCCBFCDBFCE BFCFBFD0BFD1BFD2BFD3 BFD4BFD5BFD6BFD7BFD8 BFD9BFDABFDBBFDCBFDD BFDEBFDFBFE0BFE1BFE2 BFE3BFE4BFE5BFE6BFE7 BFE8BFE9BFEABFEBBFEC BFEDBFEEBFEFBFF0BFF1 BFF2BFF3BFF4BFF5BFF6 BFF7BFF8BFF9BFFABFFB BFFCBFFDBFFEBFFF qemu-malta # --- arch/mips/include/asm/malta.h |2 ++ include/configs/qemu-malta.h |9 +++-- 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/arch/mips/include/asm/malta.h b/arch/mips/include/asm/malta.h index f2bbf0f..ab951e6 100644 --- a/arch/mips/include/asm/malta.h +++ b/arch/mips/include/asm/malta.h @@ -16,4 +16,6 @@ #define MALTA_RESET_BASE 0x1f000500 #define GORESET0x42 +#define MALTA_FLASH_BASE 0x1fc0 + #endif /* _MIPS_ASM_MALTA_H */ diff --git a/include/configs/qemu-malta.h b/include/configs/qemu-malta.h index c72c5dd..436bb49 100644 --- a/include/configs/qemu-malta.h +++ b/include/configs/qemu-malta.h @@ -34,7 +34,7 @@ * Memory map */ #define CONFIG_SYS_TEXT_BASE 0xbfc0 /* Rom version */ -#define CONFIG_SYS_MONITOR_BASECONFIG_SYS_TEXT_BASE +#define CONFIG_SYS_MONITOR_BASECONFIG_SYS_FLASH_BASE #define CONFIG_SYS_SDRAM_BASE 0x8000 /* Cached addr */ #define CONFIG_SYS_MEM_SIZE(256 * 1024 * 1024) @@ -86,7 +86,12 @@ /* * Flash configuration */ -#define CONFIG_SYS_NO_FLASH +#define CONFIG_SYS_FLASH_BASE (KSEG1 | MALTA_FLASH_BASE) +#define CONFIG_SYS_MAX_FLASH_BANKS 1 +#define CONFIG_SYS_MAX_FLASH_SECT 128 +#define CONFIG_SYS_FLASH_CFI +#define CONFIG_FLASH_CFI_DRIVER +#define CONFIG_SYS_FLASH_USE_BUFFER_WRITE /* * Commands -- 1.7.10 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 08/10] MIPS: qemu-malta: bring up ethernet
Qemu emulates a PCNET PCI card for the Malta CoreLV board.
Enable the pcnet driver and add board specific ethernet
initialization function to bring it up. Also enable the
CONFIG_CMD_NET and CONFIG_CMD_PING options.
Signed-off-by: Gabor Juhos
Cc: Daniel Schwierzeck
---
Changes since v2:
- rebased against the master branch of git.denx.de/u-boot.git
Changes since v1:
- rebased against mips/testing
Changes since RFC: ---
Screenshot:
U-Boot 2013.04-00244-g99710fc (May 22 2013 - 13:27:18)
Board: MIPS Malta CoreLV (Qemu)
DRAM: 256 MiB
pflash_write: Unimplemented flash cmd sequence (offset ,
wcycle 0x0 cmd 0x0 value 0xf0)
Flash: 4 MiB
Using default environment
In:serial
Out: serial
Err: serial
Net: pcnet#0
qemu-malta # setenv ethaddr 00:11:22:33:44:55
qemu-malta # setenv serverip 10.0.2.2
qemu-malta # setenv ipaddr 10.0.2.1
qemu-malta # ping 10.0.2.2
Using pcnet#0 device
host 10.0.2.2 is alive
qemu-malta #
---
board/qemu-malta/qemu-malta.c |6 ++
include/configs/qemu-malta.h |3 ++-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/board/qemu-malta/qemu-malta.c b/board/qemu-malta/qemu-malta.c
index e3a733f..4cbd736 100644
--- a/board/qemu-malta/qemu-malta.c
+++ b/board/qemu-malta/qemu-malta.c
@@ -7,6 +7,7 @@
*/
#include
+#include
#include
#include
@@ -24,6 +25,11 @@ int checkboard(void)
return 0;
}
+int board_eth_init(bd_t *bis)
+{
+ return pci_eth_init(bis);
+}
+
void _machine_restart(void)
{
void __iomem *reset_base;
diff --git a/include/configs/qemu-malta.h b/include/configs/qemu-malta.h
index ef44d3d..c79c911 100644
--- a/include/configs/qemu-malta.h
+++ b/include/configs/qemu-malta.h
@@ -20,6 +20,7 @@
#define CONFIG_PCI
#define CONFIG_PCI_GT64120
#define CONFIG_PCI_PNP
+#define CONFIG_PCNET
/*
* CPU Configuration
@@ -105,10 +106,10 @@
#undef CONFIG_CMD_FPGA
#undef CONFIG_CMD_LOADB
#undef CONFIG_CMD_LOADS
-#undef CONFIG_CMD_NET
#undef CONFIG_CMD_NFS
#define CONFIG_CMD_PCI
+#define CONFIG_CMD_PING
#define CONFIG_SYS_LONGHELP/* verbose help, undef to save memory */
--
1.7.10
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 01/10] MIPS: qemu-malta: add support for emulated MIPS Malta board
Add minimal support for the MIPS Malta CoreLV board emulated by Qemu. The only supported peripherial is the UART. This is enough to boot U-Boot to the command prompt both in little and big endian mode. Signed-off-by: Gabor Juhos Cc: Daniel Schwierzeck --- Changes since v2: - rebased against the master branch of git.denx.de/u-boot.git Changes since v1: - remove custom u-boot.lds file - rebased against mips/testing Changes since RFC: --- Screenshot: U-Boot 2013.04-00237-g8321627 (May 21 2013 - 22:29:38) Board: MIPS Malta CoreLV (Qemu) DRAM: 256 MiB Using default environment In:serial Out: serial Err: serial qemu-malta # help ? - alias for 'help' base- print or set address offset bdinfo - print Board Info structure boot- boot default, i.e., run 'bootcmd' bootd - boot default, i.e., run 'bootcmd' bootm - boot application image from memory cmp - memory compare coninfo - print console devices and information cp - memory copy crc32 - checksum calculation echo- echo args to console editenv - edit environment variable env - environment handling commands go - start application at address 'addr' help- print command description/usage iminfo - print header information for application image imxtract- extract a part of a multi-image itest - return true/false on integer compare loop- infinite loop on address range md - memory display mm - memory modify (auto-incrementing address) mw - memory write (fill) nm - memory modify (constant address) printenv- print environment variables reset - Perform RESET of the CPU run - run commands in an environment variable setenv - set environment variables sleep - delay execution for some time source - run script from memory version - print monitor, compiler and linker version qemu-malta # printenv baudrate=115200 stderr=serial stdin=serial stdout=serial Environment size: 66/65532 bytes qemu-malta # --- arch/mips/include/asm/malta.h| 16 ++ board/qemu-malta/Makefile| 45 + board/qemu-malta/lowlevel_init.S | 19 +++ board/qemu-malta/qemu-malta.c| 20 boards.cfg |2 + include/configs/qemu-malta.h | 104 ++ 6 files changed, 206 insertions(+) create mode 100644 arch/mips/include/asm/malta.h create mode 100644 board/qemu-malta/Makefile create mode 100644 board/qemu-malta/lowlevel_init.S create mode 100644 board/qemu-malta/qemu-malta.c create mode 100644 include/configs/qemu-malta.h diff --git a/arch/mips/include/asm/malta.h b/arch/mips/include/asm/malta.h new file mode 100644 index 000..b215164 --- /dev/null +++ b/arch/mips/include/asm/malta.h @@ -0,0 +1,16 @@ +/* + * Copyright (C) 2013 Gabor Juhos + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 as published + * by the Free Software Foundation. + */ + +#ifndef _MIPS_ASM_MALTA_H +#define _MIPS_ASM_MALTA_H + +#define MALTA_IO_PORT_BASE 0x1000 + +#define MALTA_UART_BASE(MALTA_IO_PORT_BASE + 0x3f8) + +#endif /* _MIPS_ASM_MALTA_H */ diff --git a/board/qemu-malta/Makefile b/board/qemu-malta/Makefile new file mode 100644 index 000..6251bb8 --- /dev/null +++ b/board/qemu-malta/Makefile @@ -0,0 +1,45 @@ +# +# (C) Copyright 2003-2006 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# 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., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).o + +COBJS = $(BOARD).o +SOBJS = lowlevel_init.o + +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) +SOBJS := $(addprefix $(obj),$(SOBJS)) + +$(LIB): $(OBJS) $(SOBJS) + $(call cmd_link_o_target, $(OBJS) $(SOBJS)) + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/qemu-malta/lowlevel_init.S b/board/qemu-malta/lowlevel_in
[U-Boot] [PATCH v3 04/10] MIPS: import gt64120.h header from Linux
The Linux specific register access macros, the extern function declarations and the UL suffixes has been removed. The header file will be used for the qemu-malta board. Signed-off-by: Gabor Juhos Cc: Daniel Schwierzeck --- Changes since v2: - use the header file from Linux 3.10-rc2 instead of 3.8-rc3 - move the header file from 'arch/mips/include/asm' to 'include' - rebased against the master branch of git.denx.de/u-boot.git Changes since v1: - rebased against mips/testing Changes since RFC: --- --- include/gt64120.h | 550 + 1 file changed, 550 insertions(+) create mode 100644 include/gt64120.h diff --git a/include/gt64120.h b/include/gt64120.h new file mode 100644 index 000..c0accc6 --- /dev/null +++ b/include/gt64120.h @@ -0,0 +1,550 @@ +/* + * Copyright (C) 2000, 2004, 2005 MIPS Technologies, Inc. + * All rights reserved. + * Authors: Carsten Langgaard + * Maciej W. Rozycki + * Copyright (C) 2005 Ralf Baechle (r...@linux-mips.org) + * + * This program is free software; you can distribute it and/or modify it + * under the terms of the GNU General Public License (Version 2) as + * published by the Free Software Foundation. + * + * This program is distributed in the hope it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * for more details. + * + * You should have received a copy of the GNU General Public License along + * with this program; if not, write to the Free Software Foundation, Inc., + * 59 Temple Place - Suite 330, Boston MA 02111-1307, USA. + */ +#ifndef _ASM_GT64120_H +#define _ASM_GT64120_H + +#define MSK(n) ((1 << (n)) - 1) + +/* + * Register offset addresses + */ +/* CPU Configuration. */ +#define GT_CPU_OFS 0x000 + +#define GT_MULTI_OFS 0x120 + +/* CPU Address Decode. */ +#define GT_SCS10LD_OFS 0x008 +#define GT_SCS10HD_OFS 0x010 +#define GT_SCS32LD_OFS 0x018 +#define GT_SCS32HD_OFS 0x020 +#define GT_CS20LD_OFS 0x028 +#define GT_CS20HD_OFS 0x030 +#define GT_CS3BOOTLD_OFS 0x038 +#define GT_CS3BOOTHD_OFS 0x040 +#define GT_PCI0IOLD_OFS0x048 +#define GT_PCI0IOHD_OFS0x050 +#define GT_PCI0M0LD_OFS0x058 +#define GT_PCI0M0HD_OFS0x060 +#define GT_ISD_OFS 0x068 + +#define GT_PCI0M1LD_OFS0x080 +#define GT_PCI0M1HD_OFS0x088 +#define GT_PCI1IOLD_OFS0x090 +#define GT_PCI1IOHD_OFS0x098 +#define GT_PCI1M0LD_OFS0x0a0 +#define GT_PCI1M0HD_OFS0x0a8 +#define GT_PCI1M1LD_OFS0x0b0 +#define GT_PCI1M1HD_OFS0x0b8 +#define GT_PCI1M1LD_OFS0x0b0 +#define GT_PCI1M1HD_OFS0x0b8 + +#define GT_SCS10AR_OFS 0x0d0 +#define GT_SCS32AR_OFS 0x0d8 +#define GT_CS20R_OFS 0x0e0 +#define GT_CS3BOOTR_OFS0x0e8 + +#define GT_PCI0IOREMAP_OFS 0x0f0 +#define GT_PCI0M0REMAP_OFS 0x0f8 +#define GT_PCI0M1REMAP_OFS 0x100 +#define GT_PCI1IOREMAP_OFS 0x108 +#define GT_PCI1M0REMAP_OFS 0x110 +#define GT_PCI1M1REMAP_OFS 0x118 + +/* CPU Error Report. */ +#define GT_CPUERR_ADDRLO_OFS 0x070 +#define GT_CPUERR_ADDRHI_OFS 0x078 + +#define GT_CPUERR_DATALO_OFS 0x128 /* GT-64120A only */ +#define GT_CPUERR_DATAHI_OFS 0x130 /* GT-64120A only */ +#define GT_CPUERR_PARITY_OFS 0x138 /* GT-64120A only */ + +/* CPU Sync Barrier. */ +#define GT_PCI0SYNC_OFS0x0c0 +#define GT_PCI1SYNC_OFS0x0c8 + +/* SDRAM and Device Address Decode. */ +#define GT_SCS0LD_OFS 0x400 +#define GT_SCS0HD_OFS 0x404 +#define GT_SCS1LD_OFS 0x408 +#define GT_SCS1HD_OFS 0x40c +#define GT_SCS2LD_OFS 0x410 +#define GT_SCS2HD_OFS 0x414 +#define GT_SCS3LD_OFS 0x418 +#define GT_SCS3HD_OFS 0x41c +#define GT_CS0LD_OFS 0x420 +#define GT_CS0HD_OFS 0x424 +#define GT_CS1LD_OFS 0x428 +#define GT_CS1HD_OFS 0x42c +#define GT_CS2LD_OFS 0x430 +#define GT_CS2HD_OFS 0x434 +#define GT_CS3LD_OFS 0x438 +#define GT_CS3HD_OFS 0x43c +#define GT_BOOTLD_OFS 0x440 +#define GT_BOOTHD_OFS 0x444 + +#define GT_ADERR_OFS 0x470 + +/* SDRAM Configuration. */ +#define GT_SDRAM_CFG_OFS 0x448 + +#define GT_SDRAM_OPMODE_OFS0x474 +#define GT_SDRAM_BM_OFS0x478 +#define GT_SDRAM_ADDRDECODE_OFS 0x47c + +/* SDRAM Parameters. */ +#define GT_SDRAM_B0_OFS0x44c +#define GT_SDRAM_B1_OFS0x450 +#define GT_SDRAM_B2_OFS0x454 +#define GT_SDRAM_B3_OFS
[U-Boot] [PATCH v3 10/10] MIPS: start.S: emulate REVISION register for qemu-malta
On the origial Malta boards the REVISION register is accessible at the 0x1fc00010 address. The contents of this register gives information about the revision of the Malta and Core Boards. This register is used by the Linux kernel to identify the actual board it is running on. However the register is not emulated properly by Qemu, so put a hardcoded value into the flash to make Linux work. Signed-off-by: Gabor Juhos Cc: Daniel Schwierzeck --- Changes since v2: - rebased against the master branch of git.denx.de/u-boot.git Changes since v1: - rebased against mips/testing Changes since RFC: --- Screenshot: U-Boot 2013.04-00246-gd93f756 (May 22 2013 - 14:18:54) Board: MIPS Malta CoreLV (Qemu) DRAM: 256 MiB pflash_write: Unimplemented flash cmd sequence (offset , wcycle 0x0 cmd 0x0 value 0xf0) Flash: 4 MiB Using default environment In:serial Out: serial Err: serial Net: pcnet#0 qemu-maltael # setenv ethaddr 00:11:22:33:44:55 qemu-maltael # setenv ipaddr 10.0.2.1 qemu-maltael # setenv serverip 10.0.2.2 qemu-maltael # tftp openwrt-malta-le-uImage-gzip Using pcnet#0 device TFTP from server 10.0.2.2; our IP address is 10.0.2.1 Filename 'openwrt-malta-le-uImage-gzip'. Load address: 0x8100 Loading: # # # # # # # ## 52.8 MiB/s done Bytes transferred = 2935968 (2ccca0 hex) qemu-maltael # bootm ## Booting kernel from Legacy Image at 8100 ... Image Name: MIPS OpenWrt Linux-3.8.13 Image Type: MIPS Linux Kernel Image (gzip compressed) Data Size:2935904 Bytes = 2.8 MiB Load Address: 8010 Entry Point: 80104a90 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Starting kernel ... [0.00] Linux version 3.8.13 (juhosg@mag2) (gcc version 4.6.4 20121210 (prerelease) (Linaro GCC 4.6-2012.12) ) #1 SMP Wed May 22 14:13:27 CEST 2013 [0.00] Config serial console: console=ttyS0,38400n8r [0.00] bootconsole [early0] enabled [0.00] CPU revision is: 00019300 (MIPS 24Kc) [0.00] FPU revision is: 00739300 [0.00] Determined physical RAM map: [0.00] memory: 1000 @ (reserved) [0.00] memory: 000ef000 @ 1000 (ROM data) [0.00] memory: 00676000 @ 000f (reserved) [0.00] memory: 0f89a000 @ 00766000 (usable) [0.00] Wasting 60608 bytes for tracking 1894 unused pages [0.00] Initrd not found or empty - disabling initrd [0.00] Zone ranges: [0.00] DMA [mem 0x-0x00ff] [0.00] Normal [mem 0x0100-0x0fff] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x-0x0fff] [0.00] Primary instruction cache 2kB, VIPT, 2-way, linesize 16 bytes. [0.00] Primary data cache 2kB, 2-way, VIPT, no aliases, linesize 16 bytes [0.00] PERCPU: Embedded 7 pages/cpu @81203000 s6464 r8192 d14016 u32768 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024 [0.00] Kernel command line: console=ttyS0,38400n8r [0.00] PID hash table entries: 1024 (order: 0, 4096 bytes) [0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) [0.00] __ex_table already sorted, skipping sort [0.00] Writing ErrCtl register= [0.00] Readback ErrCtl register= [0.00] Memory: 252260k/254568k available (2517k kernel code, 2308k reserved, 624k data, 3320k init, 0k highmem) [0.00] Hierarchical RCU implementation. [0.00] RCU restricting CPUs from NR_CPUS=2 to nr_cpu_ids=1. [0.00] NR_IRQS:256 [0.00] CPU frequency 199.93 MHz [0.00] Console: colour dummy device 80x25 [0.00] Calibrating delay loop... 1168.17 BogoMIPS (lpj=5840896) [0.12] pid_max: default: 32768 minimum: 301 [0.12] Mount-cache hash table entries: 512 [0.13] Brought up 1 CPUs [0.14] NET: Registered protocol family 16 [0.18] bio: create slab at 0 [0.19] SCSI subsystem initialized [0.19] PCI host bridge to bus :00 [0.19] pci_bus :00: root bus
[U-Boot] [PATCH v3 05/10] MIPS: qemu-malta: setup GT64120 registers as done by YAMON
Move the GT64120 register base to 0x1be0 and setup PCI BAR registers as done by the original YAMON bootloader. This is needed for running Linux kernel. Signed-off-by: Gabor Juhos Cc: Daniel Schwierzeck --- Changes since v2: - rebased against the master branch of git.denx.de/u-boot.git Changes since v1: - rebased against mips/testing Changes since RFC: --- --- arch/mips/include/asm/malta.h|4 ++- board/qemu-malta/lowlevel_init.S | 52 ++ 2 files changed, 55 insertions(+), 1 deletion(-) diff --git a/arch/mips/include/asm/malta.h b/arch/mips/include/asm/malta.h index ab951e6..d4d44a2 100644 --- a/arch/mips/include/asm/malta.h +++ b/arch/mips/include/asm/malta.h @@ -9,10 +9,12 @@ #ifndef _MIPS_ASM_MALTA_H #define _MIPS_ASM_MALTA_H -#define MALTA_IO_PORT_BASE 0x1000 +#define MALTA_IO_PORT_BASE 0x1800 #define MALTA_UART_BASE(MALTA_IO_PORT_BASE + 0x3f8) +#define MALTA_GT_BASE 0x1be0 + #define MALTA_RESET_BASE 0x1f000500 #define GORESET0x42 diff --git a/board/qemu-malta/lowlevel_init.S b/board/qemu-malta/lowlevel_init.S index c5c5bd9..ff4a072 100644 --- a/board/qemu-malta/lowlevel_init.S +++ b/board/qemu-malta/lowlevel_init.S @@ -6,7 +6,20 @@ * by the Free Software Foundation. */ +#include +#include + +#include #include +#include + +#ifdef CONFIG_SYS_BIG_ENDIAN +#define CPU_TO_GT32(_x)((_x)) +#else +#define CPU_TO_GT32(_x) ( \ + (((_x) & 0xff) << 24) | (((_x) & 0xff00) << 8) |\ + (((_x) & 0xff) >> 8) | (((_x) & 0xff00) >> 24)) +#endif .text .set noreorder @@ -15,5 +28,44 @@ .globl lowlevel_init lowlevel_init: + /* +* Load BAR registers of GT64120 as done by YAMON +* +* based on a patch sent by Antony Pavlov +* to the barebox mailing list. +* The subject of the original patch: +* 'MIPS: qemu-malta: add YAMON-style GT64120 memory map' +* URL: +* http://www.mail-archive.com/barebox@lists.infradead.org/msg06128.html +* +* based on write_bootloader() in qemu.git/hw/mips_malta.c +* see GT64120 manual and qemu.git/hw/gt64xxx.c for details +*/ + + /* move GT64120 registers from 0x1400 to 0x1be0 */ + li t1, KSEG1ADDR(GT_DEF_BASE) + li t0, CPU_TO_GT32(0xdf00) + sw t0, GT_ISD_OFS(t1) + + /* setup MEM-to-PCI0 mapping */ + li t1, KSEG1ADDR(MALTA_GT_BASE) + + /* setup PCI0 io window to 0x1800-0x181f */ + li t0, CPU_TO_GT32(0xc000) + sw t0, GT_PCI0IOLD_OFS(t1) + li t0, CPU_TO_GT32(0x4000) + sw t0, GT_PCI0IOHD_OFS(t1) + + /* setup PCI0 mem windows */ + li t0, CPU_TO_GT32(0x8000) + sw t0, GT_PCI0M0LD_OFS(t1) + li t0, CPU_TO_GT32(0x3f00) + sw t0, GT_PCI0M0HD_OFS(t1) + + li t0, CPU_TO_GT32(0xc100) + sw t0, GT_PCI0M1LD_OFS(t1) + li t0, CPU_TO_GT32(0x5e00) + sw t0, GT_PCI0M1HD_OFS(t1) + jr ra nop -- 1.7.10 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 06/10] MIPS: qemu-malta: add PCI support
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
Cc: Daniel Schwierzeck
---
Changes since v2:
- move the PCI driver to drivers/pci
- fix checkpatch warnings
- rebased against the master branch of git.denx.de/u-boot.git
Changes since v1:
- rebased against mips/testing
Changes since RFC:
- use a C struct to define the register layout instead
of using a base address plus offset notation
- remove custom IO accessors
Screenshot:
U-Boot 2013.04-00242-g8960ff8 (May 22 2013 - 13:25:13)
Board: MIPS Malta CoreLV (Qemu)
DRAM: 256 MiB
pflash_write: Unimplemented flash cmd sequence (offset ,
wcycle 0x0 cmd 0x0 value 0xf0)
Flash: 4 MiB
Using default environment
In:serial
Out: serial
Err: serial
qemu-malta # pci
Scanning PCI devices on bus 0
BusDevFun VendorId DeviceId Device Class Sub-Class
_
00.00.00 0x11ab 0x4620 Bridge device 0x00
00.0a.00 0x8086 0x7110 Bridge device 0x01
00.0a.01 0x8086 0x7111 Mass storage controller 0x01
00.0a.02 0x8086 0x7112 Serial bus controller 0x03
00.0a.03 0x8086 0x7113 Bridge device 0x80
00.0b.00 0x1022 0x2000 Network controller 0x00
qemu-malta #
---
board/qemu-malta/qemu-malta.c | 12 +++
drivers/pci/Makefile |1 +
drivers/pci/pci_gt64120.c | 178 +
include/configs/qemu-malta.h |6 ++
include/pci_gt64120.h | 19 +
5 files changed, 216 insertions(+)
create mode 100644 drivers/pci/pci_gt64120.c
create mode 100644 include/pci_gt64120.h
diff --git a/board/qemu-malta/qemu-malta.c b/board/qemu-malta/qemu-malta.c
index 449da9c..e3a733f 100644
--- a/board/qemu-malta/qemu-malta.c
+++ b/board/qemu-malta/qemu-malta.c
@@ -8,8 +8,10 @@
#include
+#include
#include
#include
+#include
phys_size_t initdram(int board_type)
{
@@ -29,3 +31,13 @@ void _machine_restart(void)
reset_base = (void __iomem *)CKSEG1ADDR(MALTA_RESET_BASE);
__raw_writel(GORESET, reset_base);
}
+
+void pci_init_board(void)
+{
+ set_io_port_base(CKSEG1ADDR(MALTA_IO_PORT_BASE));
+
+ gt64120_pci_init((void *)CKSEG1ADDR(MALTA_GT_BASE),
+0x, 0x, CONFIG_SYS_MEM_SIZE,
+0x1000, 0x1000, 128 * 1024 * 1024,
+0x, 0x, 0x2);
+}
diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index 1ae35d3..02d2309 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -27,6 +27,7 @@ LIB := $(obj)libpci.o
COBJS-$(CONFIG_FSL_PCI_INIT) += fsl_pci_init.o
COBJS-$(CONFIG_PCI) += pci.o pci_auto.o pci_indirect.o
+COBJS-$(CONFIG_PCI_GT64120) += pci_gt64120.o
COBJS-$(CONFIG_FTPCI100) += pci_ftpci100.o
COBJS-$(CONFIG_IXP_PCI) += pci_ixp.o
COBJS-$(CONFIG_SH4_PCI) += pci_sh4.o
diff --git a/drivers/pci/pci_gt64120.c b/drivers/pci/pci_gt64120.c
new file mode 100644
index 000..c2f2049
--- /dev/null
+++ b/drivers/pci/pci_gt64120.c
@@ -0,0 +1,178 @@
+/*
+ * Copyright (C) 2013 Gabor Juhos
+ *
+ * Based on the Linux implementation.
+ * Copyright (C) 1999, 2000, 2004 MIPS Technologies, Inc.
+ * Authors: Carsten Langgaard
+ *Maciej W. Rozycki
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+
+#define PCI_ACCESS_READ 0
+#define PCI_ACCESS_WRITE 1
+
+struct gt64120_regs {
+ u8 unused_000[0xc18];
+ u32 intrcause;
+ u8 unused_c1c[0x0dc];
+ u32 pci0_cfgaddr;
+ u32 pci0_cfgdata;
+};
+
+struct gt64120_pci_controller {
+ struct pci_controller hose;
+ struct gt64120_regs *regs;
+};
+
+static inline struct gt64120_pci_controller *
+hose_to_gt64120(struct pci_controller *hose)
+{
+ return container_of(hose, struct gt64120_pci_controller, hose);
+}
+
+#define GT_INTRCAUSE_ABORT_BITS\
+ (GT_INTRCAUSE_MASABORT0_BIT | GT_INTRCAUSE_TARABORT0_BIT)
+
+static int gt_config_access(struct gt64120_pci_controller *gt,
+ unsigned char access_type, pci_dev_t bdf,
+ int where, u32 *data)
+{
+ unsigned int bus = PCI_BUS(bdf);
+ unsigned int dev = PCI_DEV(bdf);
+ unsigned int devfn = PCI_DEV(bdf) << 3 | PCI_FUNC(bdf);
+ u32 intr;
+ u32 addr;
+ u32 val;
+
+ if (bus == 0 && dev >= 31) {
+ /* Because of a bug in the galileo (for slot 31). */
+ return -1;
+ }
+
+ if (access_type == PCI_ACC
[U-Boot] [PATCH v3 00/10] MIPS: initial support for emulated Malta board
This patch set adds initial support for the MIPS Malta CoreLV board emulated under Qemu. The changes since the previous version of the series are described in the individual patches. The patches are against the master branch of git.denx.de/u-boot.git tree. Depends on the following patch: 'MIPS: fix __raw_* IO accessors' http://patchwork.ozlabs.org/patch/222195/ Gabor Juhos (10): MIPS: qemu-malta: add support for emulated MIPS Malta board MIPS: qemu-malta: add reset support MIPS: qemu-malta: enable flash support MIPS: import gt64120.h header from Linux MIPS: qemu-malta: setup GT64120 registers as done by YAMON MIPS: qemu-malta: add PCI support net: pcnet: use pci_virt_to_mem to obtain buffer addresses MIPS: qemu-malta: bring up ethernet MIPS: bootm.c: add YAMON style Linux preparation/jump code MIPS: start.S: emulate REVISION register for qemu-malta arch/mips/cpu/mips32/start.S |8 +- arch/mips/include/asm/malta.h| 23 ++ arch/mips/lib/bootm.c| 60 - board/qemu-malta/Makefile| 45 board/qemu-malta/lowlevel_init.S | 71 + board/qemu-malta/qemu-malta.c| 49 boards.cfg |2 + drivers/net/pcnet.c |2 +- drivers/pci/Makefile |1 + drivers/pci/pci_gt64120.c| 178 include/configs/qemu-malta.h | 116 include/gt64120.h| 550 ++ include/pci_gt64120.h| 19 ++ 13 files changed, 1120 insertions(+), 4 deletions(-) create mode 100644 arch/mips/include/asm/malta.h create mode 100644 board/qemu-malta/Makefile create mode 100644 board/qemu-malta/lowlevel_init.S create mode 100644 board/qemu-malta/qemu-malta.c create mode 100644 drivers/pci/pci_gt64120.c create mode 100644 include/configs/qemu-malta.h create mode 100644 include/gt64120.h create mode 100644 include/pci_gt64120.h -- 1.7.10 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools/fw_env: use fsync to ensure that data is physically stored
Hi Michael, Michael Heimpold [m...@heimpold.de] wrote: > fw_setenv state=2 > dd if=... of=/dev/mmcblk0... > fw_setenv state=1 How about: fw_setenv state 1 && sync BR // Mats ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] fdt_support: Use CONFIG_NR_DRAM_BANKS if defined
On Tue, Apr 30, 2013 at 10:22:00AM -, Doug Anderson wrote: > It appears that there are some cases where we have more than 4 banks > of memory. Use CONFIG_NR_DRAM_BANKS if it's defined to handle this. > This will take up a little extra stack space (64 bytes extra if we go > up to 8 banks), but that seems OK. > > Signed-off-by: Doug Anderson 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] [U-Boot, v4] bootm: Avoid 256-byte overflow in fixup_silent_linux()
On Tue, Jan 17, 2012 at 09:37:41AM -, Doug Anderson wrote: > This makes fixup_silent_linux() use malloc() to allocate its > working space, meaning that our maximum kernel command line > should only be limited by malloc(). Previously it was silently > overflowing the stack. > > Note that nothing about this change increases the kernel's maximum > command line length. If you have a command line that is >256 > bytes it's up to you to make sure that kernel can handle it. > > Signed-off-by: Doug Anderson > Acked-by: Mike Frysinger 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] .gitignore: add GNU GLOBAL files
On Sun, May 12, 2013 at 06:14:05PM -, Masahiro Yamada wrote: > Signed-off-by: Masahiro Yamada 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 2/2] Update MAINTAINERS file for sandbox
On Wed, May 15, 2013 at 09:54:41AM -0700, Simon Glass wrote: > This currently has no maintainer listed. > > Signed-off-by: Simon Glass 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 1/2] Update MAINTAINERS file for x86
On Wed, May 15, 2013 at 09:54:40AM -0700, Simon Glass wrote: > This still shows the previous maintainer. > > Signed-off-by: Simon Glass 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] ARM: cfi_flash: Fix unaligned accesses to cfi_qry structure
> From: Gabbasov, Andrew > Sent: Tuesday, May 14, 2013 21:27 > To: Albert ARIBAUD; Marek Vasut > Cc: u-boot@lists.denx.de; Masahiro Yamada; tr...@ti.com > Subject: RE: [U-Boot] ARM: cfi_flash: Fix unaligned accesses to cfi_qry > structure > > Hello Albert, > > > From: Albert ARIBAUD [albert.u.b...@aribaud.net] > > Sent: Monday, May 13, 2013 10:48 > > To: Marek Vasut > > Cc: u-boot@lists.denx.de; Masahiro Yamada; tr...@ti.com; Gabbasov, Andrew > > Subject: Re: [U-Boot] ARM: cfi_flash: Fix unaligned accesses to cfi_qry > > structure > > > > Hi Marek, > > > > On Fri, 10 May 2013 14:36:00 +0200, Marek Vasut wrote: > > > > > Hello Masahiro-san, > > > > > > By the way, I also had this unalignment access problem for my board. > > > > Before finding your patch, I was thinking another way to fix this > > > > problem. > > > > > > > > My idea is to just use 'get_unaligned' and 'put_unaligned' functions > > > > instead of introducing special macros. > > > > With this way, we don't need to change the fields of struct cfi_qry. > > > > > > I think we should make sure to use natural alignment as much as possible, > > > really. I'm keeping Albert in CC because this is his turf. > > > > Marek, you invoked me; next time be careful what you wish for. :) > > > > My rules (not 'of thumb', as they also apply to ARM) regarding > > alignment are as follows (yes, it's a more general answer than your > > question called for, but the last rules are more directly related): > > > > 0) Never assume that U-Boot can use native unaligned accesses. Yes, > > ARMv7+ can do native unaligned accesses with almost no performance > > cost, but U-Boot runs on all sorts of targets (not only ARM), some > > allowing unaligned access but with a penalty, and some unable to > > perform unaligned access at all. We always run the risk that some code > > in U-Boot ends up running on target which will die horribly on some > > unaligned access, so to avoid this we must assume and enforce strict > > alignment, even for architectures which do not require it, such as > > ARMv7+. > > > > 1) As per rule 0, always enable alignment check -- again, even on > > targets which could do without it. This allows catching any unaligned > > access, be they accidental (bad pointer arithmetic) or by design > > (misaligned field in an otherwise aligned struct). > > > > 2) Despite rules 0 and 1, always enable native unaligned accesses (IOW, > > always use option -munaligned-accesses). That is because without this > > option (or more precisely, when -mno-unaligned-accesses is in effect), > > the ARM compiler may silently detect misaligned accesses and fix them > > using smaller aligned accesses, thus hiding a potential alignment > > issue until it bites on some later and unrelated target run. > > > > 3) always size fields in a structure to their natural size, i.e., if a > > field is 16-bits, make it u16 or s16. > > > > 4) always align fields in a structure to their natural boundaries, > > i.e., if a field is 16-bits, align it to an even address. > > > > 5) if a field absolutely has to be unaligned because of hardware or > > standard, then a) document that! and b) access it with explicit > > unaligned access macros. > > > > So in essence, I am opposed to changing fields from 16-bit to 2 x 8-bit > > just 'because unaligned'. Either fix the fields' alignment, if at all > > possible; and if not, then apply rule 5: document the issue and fix it > > using explicit unaligned access macros. > > > > > Best regards, > > > Marek Vasut > > > > Amicalement, > > -- > > Albert. > > Thank you for your review and the very useful list of rules. > > Although theoretically the cfi_qry structure can be made non-packed and > with properly aligned members (and filled in by individual members assignments > when reading, rather than just copying byte-to-byte, as it is now), > it may make more sense to keep it packed and replicating the actual flash > layout > as much as possible. This also makes it more similar to what is used > in Linux kernel (although it seems to rely on native unaligned access ;-)). > > So, it seems reasonable to choose to apply rule 5: add comments to cfi_qry > strcuture > definition and use get_unaligned/put_unaligned for the necessary fields (only > for really > unaligned members, since some 16-bit fields are properly aligned). > > I'm sending the version 2 of the patch with this change as a separate message > with > Subject: [U-Boot][PATCH v2] cfi_flash: Fix unaligned accesses to cfi_qry > structure > > Please, let me know if somebody still prefers making non-packed aligned > structure, > as described above. > > Thanks. > > Best regards, > Andrew Does anybody have any comments on the mentioned updated patch? Thanks. Best regards, Andrew ___ 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 Fri, May 17, 2013 at 10:56:25PM +0200, Henrik Nordstr?m wrote: > fre 2013-05-17 klockan 14:17 -0400 skrev Tom Rini: > > > I would say you want to hypothetically add a _felboot build target for > > the allwinner boards that instead of building out a regular > > CONFIG_SPL_FRAMEWORK (I hope!) SPL spits out just a very tiny one that > > does what you need for this use case. Having different builds for > > different SPL cases is a normal thing that we do on a few boards, but > > none are quite so drastically different sounding as this. > > Yes the main SPL is using CONFIG_SPL_FRAMEWORK. But the low level board > initialization is done in s_init (via lowlevel_init). > > This other boot helper is basically only calling s_init() and then > returns to the caller with the board now configured in a reasonable > state allowing it to accept u-boot.bin to be uploaded into SDRAM. 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. -- 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] tools/fw_env: use fsync to ensure that data is physically stored
On 21/05/13 18:34, Michael Heimpold wrote: > Hi Wolfgang Denx, > >>> Closing a file descriptor does not guarantee that the data has been >>> successfully saved to disk, as the kernel might defer the write. >> >> What is the exact problem you are trying to fix? >> >> I mean, when exactly does adding the sync play a role? > > I'm using fw_setenv during system update process. The sequence > of such a shell script is something like (much simplified): > > ... > fw_setenv state=2 > dd if=... of=/dev/mmcblk0... > fw_setenv state=1 > ... > reboot Not sure what final "OS" environment you're running, but I would think that "reboot" would sync for you ? For instance, under BusyBox, we have:- # reboot --help BusyBox v1.14.0 (2012-02-15 10:28:26 GMT) multi-call binary Usage: reboot [-d delay] [-n] [-f] Reboot the system Options: -d Delay interval for rebooting -n No call to sync() -f Force reboot (don't go through init) ... and under Ubuntu, we have ... $ reboot --help Usage: reboot [OPTION]... Reboot the system. Options: -n, --no-sync don't sync before reboot or halt ... So by default, reboot would (should ?) call sync automatically. This might point to some other issue ? Mark J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] common/Makefile: Add new symbol CONFIG_SPL_ENV_SUPPORT for environment in SPL
On 05/22/2013 01:09:07 AM, Stefan Roese wrote: (sorry for jumping in so late in this discussion) On 05/21/2013 09:14 PM, Scott Wood wrote: >> This is Tom's words: >> >> a3m071 relies on SPL always building cmd_nvedit.o and env_common.o and >> duplicated CONFIG_ENV_IS_IN_FLASH in the SPL section. >> >> CONFIG_SPL_NET_SUPPORT relies on the same always-built ins and adds >> env_nowhere.o which works because the regular CONFIG_ENV_IS_IN_... >> >> section is in the non-SPL-only area. > > If "SPL: Makefile: Build a separate autoconf.mk for SPL" gets merged, > we could just have a3m071 define CONFIG_ENV_IS_NOWHERE in the SPL build > case. But the a3m071 SPL U-Boot version also uses the env from NOR flash. So defining CONFIG_ENV_IS_NOWHERE here would be really confusing! Why is it including env_nowhere.o then? When you say "the a3m071 SPL U-Boot version", do you mean the SPL itself, or the entire configuration that happens to include an SPL? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6] spl: Make CONFIG_SPL_BUILD contain more functionality
On 05/21/2013 09:15:08 PM, Zhang Ying-B40530 wrote: > diff --git a/include/configs/MPC8313ERDB.h > b/include/configs/MPC8313ERDB.h > index c28dfe0..a2bdcff 100644 > --- a/include/configs/MPC8313ERDB.h > +++ b/include/configs/MPC8313ERDB.h > @@ -40,7 +40,9 @@ > #define CONFIG_SPL_INIT_MINIMAL > #define CONFIG_SPL_SERIAL_SUPPORT > #define CONFIG_SPL_NAND_SUPPORT > +#ifdef CONFIG_SPL_BUILD > #define CONFIG_SPL_NAND_MINIMAL > +#endif > #define CONFIG_SPL_FLUSH_IMAGE > #define CONFIG_SPL_TARGET "u-boot-with-spl.bin" > #define CONFIG_SPL_MPC83XX_WAIT_FOR_NAND > diff --git a/include/configs/P1022DS.h b/include/configs/P1022DS.h > index 8b13b10..5bdd44a 100644 > --- a/include/configs/P1022DS.h > +++ b/include/configs/P1022DS.h > @@ -41,7 +41,9 @@ > #define CONFIG_SPL_INIT_MINIMAL > #define CONFIG_SPL_SERIAL_SUPPORT > #define CONFIG_SPL_NAND_SUPPORT > +#ifdef CONFIG_SPL_BUILD > #define CONFIG_SPL_NAND_MINIMAL > +#endif > #define CONFIG_SPL_FLUSH_IMAGE > #define CONFIG_SPL_TARGET "u-boot-with-spl.bin" > > diff --git a/include/configs/p1_p2_rdb_pc.h > b/include/configs/p1_p2_rdb_pc.h > index 7ed634b..bc48d62 100644 > --- a/include/configs/p1_p2_rdb_pc.h > +++ b/include/configs/p1_p2_rdb_pc.h > @@ -159,7 +159,9 @@ > #define CONFIG_SPL_INIT_MINIMAL > #define CONFIG_SPL_SERIAL_SUPPORT > #define CONFIG_SPL_NAND_SUPPORT > +#ifdef CONFIG_SPL_BUILD > #define CONFIG_SPL_NAND_MINIMAL > +#endif > #define CONFIG_SPL_FLUSH_IMAGE > #define CONFIG_SPL_TARGET "u-boot-with-spl.bin" Are you sure this belongs in this patch? [Zhang Ying] Yes, it is necessary. Because CONFIG_SPL_NAND_MINIMAL has been used in the file law.c and tlb.c in this patch. What I mean is that it should probably have been done earlier, when you introduced CONFIG_SPL_NAND_MINIMAL. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] env_mmc: allow negative CONFIG_ENV_OFFSET
On Tue, May 21, 2013 at 02:25:20PM -0600, Stephen Warren wrote: > From: Stephen Warren > > 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 NAK because you aren't also covering CONFIG_ENV_OFFSET_REDUND and you need to update the README as it says ENV_OFFFSET is from the beginning not end. -- 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 2/3] env_mmc: allow negative CONFIG_ENV_OFFSET
On 05/22/2013 09:46 AM, Tom Rini wrote: > On Tue, May 21, 2013 at 02:25:20PM -0600, Stephen Warren wrote: > >> From: Stephen Warren >> >> 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 > > NAK because you aren't also covering CONFIG_ENV_OFFSET_REDUND and > you need to update the README as it says ENV_OFFFSET is from the > beginning not end. env_mmc.c doesn't implement ENV_OFFSET_REDUND, and ENV_IS_IN_MMC isn't documented in the README (other config options like ENV_OFFSET are all documented relative to the ENV_IS_IN_xxx that defines their semantics in the README right now). Are you saying you want me to fix those issues before this series will be accepted? I have no way to test ENV_OFFSET_REDUND, so I really wouldn't want to implement that for MMC, although I guess that I could add the ENV_IS_IN_MMC section to the README if you need. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] env_mmc: allow negative CONFIG_ENV_OFFSET
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/22/2013 12:00 PM, Stephen Warren wrote: > On 05/22/2013 09:46 AM, Tom Rini wrote: >> On Tue, May 21, 2013 at 02:25:20PM -0600, Stephen Warren wrote: >> >>> From: Stephen Warren >>> >>> 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 >> >> NAK because you aren't also covering CONFIG_ENV_OFFSET_REDUND >> and you need to update the README as it says ENV_OFFFSET is from >> the beginning not end. > > env_mmc.c doesn't implement ENV_OFFSET_REDUND, and ENV_IS_IN_MMC > isn't documented in the README (other config options like > ENV_OFFSET are all documented relative to the ENV_IS_IN_xxx that > defines their semantics in the README right now). > > Are you saying you want me to fix those issues before this series > will be accepted? I have no way to test ENV_OFFSET_REDUND, so I > really wouldn't want to implement that for MMC, although I guess > that I could add the ENV_IS_IN_MMC section to the README if you > need. CONFIG_ENV_OFFSET_REDUND is already there, but possibly not in the tegra tree yet? And yes, if you can write up the ENV_IS_IN_MMC section that slipped by before, I'd appreciate it. And you have no where to grab another 8KiB from? :( - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRnO4hAAoJENk4IS6UOR1WV5oQAKpimzwQ6a9iwPbso+B/BuTi 2sSDODOVJsula8P0rkmA6u7BleJfWoM3AH3VCpBv4hGYCxMimQ6zsKjsGT6UmBER aHz0t1fLs492VfE2pLxR781rWU6A2M7U9nlsX3HFtVpBYkz6FPgXSP13zT2DW5pN Bs7oRljUKoiUvL/ISWOLH/TEcMxTf08cmdcsE6vPnqbYUffwedNFc1jDQIEd7POs cmCPtxi8tLtO1aZrLoqvD9bMKvx8Z8DvahJ5y53xJdhkVufQcTjfK6N1n+DIZrHN VFt+vhPaKejELdAt6zp0nOpg21yNlyW3x2SfloPoJdJN+29rzI8jbi3wKE38E7rK DkrUeifSYIttm5gy/icKNIFDCClz50mpa9RlLs7CUbkCJFByHg6vnyGIMwk6Ni3x Yg6utF1+89V2A8vp2Hov8BuB7Jx7JnLqyffd8KEhXe6Dn8h0gT1z319bhm9YScQQ P2p674ZU7O7SSwAZDNAAEI5MrQV+Wxlc9I5rvr0UC5hxGnoVpqf4JEDJOQ6zZYLO sNQCikoFArlYfEJtPdkvWbHmueDCqOhs7KO16mnANjhV9+9dJMNPCEvY/A+3OOD6 eIPaCBpWO4n2Xsw7Qm5zQcFcoBCspTiDPQDAHoDq9mAuYrtuxwdei5Mt1HMeHu7Q M6QYrPPnRX9taNlH6LN+ =a/cD -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 6/6] arm: mvf600: Add basic support for Vybrid MVF600TWR board
Hi Alison, On Wednesday, May 22, 2013 5:17:41 AM, Wang Huan-B18965 wrote: > Hi, Benoit, > > > -Original Message- > > From: Benoît Thébaudeau [mailto:benoit.thebaud...@advansee.com] > > Sent: Wednesday, May 22, 2013 1:29 AM > > To: Wang Huan-B18965 > > Cc: sba...@denx.de; u-boot@lists.denx.de; TsiChung Liew; Jin Zhengxiong- > > R64188; Estevam Fabio-R49496 > > Subject: Re: [U-Boot] [PATCH v3 6/6] arm: mvf600: Add basic support for > > Vybrid MVF600TWR board > > > > Hi Alison, > > > > On Tuesday, May 21, 2013 11:03:01 AM, Alison Wang wrote: > > > MVF600TWR is a board based on Vybrid MVF600 SoC. > > > > > > This patch adds basic support for Vybrid MVF600TWR board. > > > > > > Signed-off-by: Alison Wang > > > Signed-off-by: Jason Jin > > > Signed-off-by: TsiChung Liew > > > > [...] > > > > > diff --git a/include/configs/mvf600twr.h b/include/configs/mvf600twr.h > > > new file mode 100644 index 000..1cfb9f6 > > > --- /dev/null > > > +++ b/include/configs/mvf600twr.h > > > @@ -0,0 +1,140 @@ > > > +/* > > > + * Copyright 2013 Freescale Semiconductor, Inc. > > > + * > > > + * Configuration settings for the Freescale Vybrid mvf600twr board. > > > + * > > > + * This program is free software; you can redistribute it and/or > > > + * modify it under the terms of the GNU General Public License as > > > + * published by the Free Software Foundation; either version 2 of > > > + * the License, or (at your option) any later version. > > > + * > > > + * This program is distributed in the hope that it will be useful, > > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > > > + * GNU General Public License for more details. > > > + * > > > + * You should have received a copy of the GNU General Public License > > > + * along with this program; if not, write to the Free Software > > > + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, > > > + * MA 02111-1307 USA > > > + */ > > > + > > > +#ifndef __CONFIG_H > > > +#define __CONFIG_H > > > + > > > +#include > > > +#include > > > + > > > +#define CONFIG_MVF600 > > > + > > > > [...] > > > > > +#define CONFIG_CMD_PING > > > +#define CONFIG_CMD_DHCP > > > +#define CONFIG_CMD_MII > > > +#define CONFIG_CMD_NET > > > +#define CONFIG_FEC_MXC > > > +#define CONFIG_MII > > > +#define IMX_FEC_BASE ENET_BASE_ADDR > > > +#define CONFIG_FEC_XCV_TYPE RMII > > > +#define CONFIG_ETHPRIME "FEC" > > > > You don't need to define this one with only 1 Ethernet interface defined. > > But isn't the MVF600 a dual-Ethernet SoC? > [Alison Wang] Yes, MVF600 is a dual-Ethernet SoC. I will change it to "FEC0". > Thanks. CONFIG_ETHPRIME should just be removed if you are not going to enable the 2nd FEC in U-Boot. But if you plan to enable the 2nd FEC, which will have to be done now or later for a dual-Ethernet SoC, then you have to: - remove CONFIG_FEC_MXC_PHYADDR and IMX_FEC_BASE, - define CONFIG_ETHPRIME to "FEC0", - call fecmxc_initialize_multi() once for each FEC instead of calling fecmxc_initialize() from cpu_eth_init() in generic.c (you can define ENET1_BASE_ADDR and ENET2_BASE_ADDR instead of ENET_BASE_ADDR in imx-regs.h, and CONFIG_FEC1_MXC_PHYADDR and CONFIG_FEC2_MXC_PHYADDR instead of CONFIG_FEC_MXC_PHYADDR in mvf600twr.h, then pass them to fecmxc_initialize_multi() from cpu_eth_init(), with 0 and 1 as the IDs), - add support for the 2nd FEC in imx_get_mac_from_fuse(), - update doc/README.mvf600 to say which fuses are used for the MAC address of the 2nd FEC. [...] 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 v3 6/6] arm: mvf600: Add basic support for Vybrid MVF600TWR board
Hi Alison, On Wednesday, May 22, 2013 10:23:12 AM, Wang Huan-B18965 wrote: [...] > > > + > > > +#define ENET_PAD_CTRL(PAD_CTL_PUS_47K_UP | PAD_CTL_SPEED_HIGH > > | \ > > > + PAD_CTL_DSE_50ohm | PAD_CTL_OBE_IBE_ENABLE) > > > + > > > +#define DDR_PAD_CTRL PAD_CTL_DSE_25ohm > > > > MUX_PAD_CTRL() could be added to the 4 pad control definitions above in > > order to avoid repeating it everywhere below. But using MUX_PAD_CTRL() > > relies on the fact that the pad control values in mvf_pins.h are all 0 > > (which is the case, but this is dangerous if this is changed later), so > > a better approach could be to use NEW_PAD_CTRL(), e.g.: > > NEW_PAD_CTRL(MVF600_PAD_DDR_A15__DDR_A_15, DDR_PAD_CTRL), > > instead of: > > MVF600_PAD_DDR_A15__DDR_A_15 | MUX_PAD_CTRL(DDR_PAD_CTRL), > > > > > + > [Alison Wang] I have a question about using NEW_PAD_CTRL(). If NEW_PAD_CTRL() > is used, should the pad control values for MVF600_PAD_DDR_A15__DDR_A_15 in > mvf_pins.h > be the same as DDR_PAD_CTRL? I saw you didn't use the same value on other > platforms, > how do you define it? No, you don't have to change mvf_pins.h. That's what NEW_PAD_CTRL() is useful for: You can have any pad control value defined in mvf_pins.h, and a board can override the pad control values when using definitions from mvf_pins.h, without having to modify mvf_pins.h. E.g.: --- mvf_pins.h: MVF600_PAD_PTA6__RMII0_CLKIN = IOMUX_PAD(0x0, 0x0, 2, 0x0, 0, PAD_CTRL1), mvf600twr.c: NEW_PAD_CTRL(MVF600_PAD_PTA6__RMII0_CLKIN, PAD_CTRL2), --- would have the same effect as a theoretical: --- mvf_pins.h: MVF600_PAD_PTA6__RMII0_CLKIN = IOMUX_PAD(0x0, 0x0, 2, 0x0, 0, PAD_CTRL2), mvf600twr.c: MVF600_PAD_PTA6__RMII0_CLKIN, --- But if you think that the pad control values that you have defined in mvf600twr.c are not specific to this board and should be used as the default pad control values for all boards based on the MVF600, then you should move those definitions to mvf_pins.h, and use them there, which means that you will no longer need MUX_PAD_CTRL() or NEW_PAD_CTRL() in mvf600twr.c: --- mvf_pins.h: #define MVF600_DDR_PAD_CTRL PAD_CTL_DSE_25ohm ... MVF600_PAD_DDR_A15__DDR_A_15 = IOMUX_PAD(0x0220, 0x0220, 0, 0x, 0, MVF600_DDR_PAD_CTRL), mvf600twr.c: MVF600_PAD_DDR_A15__DDR_A_15, --- 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] tools/fw_env: use fsync to ensure that data is physically stored
Hi, > > ... > > fw_setenv state=2 > > dd if=... of=/dev/mmcblk0... > > fw_setenv state=1 > > ... > > reboot > > Not sure what final "OS" environment you're running, but I would think > that "reboot" would sync for you ? I'm using OpenWRT and reboot links to the busybox implementation. This implemenetation calls sync when I traced it correctly. According to "man 2 sync": DESCRIPTION sync() causes all buffered modifications to file metadata and data to be written to the underlying file systems. When I use fw_setenv with /dev/mmcblk0, that means with a block device directly, then I have a problem matching the "filesystem layer" of the description above with the "block layer" which I am using. Futhermore another quote from the very same man page: BUGS ...sync() schedules the writes, but may return before the actual writing is done. However, since version 1.3.20 Linux does actually wait. (This still does not guarantee data integrity: modern disks have large caches.) So it seems to me, that calling "sync" doesn't do the job. When looking at "man 2 fsync" I read ... This includes writing through or flushing a disk cache if present. The call blocks until the device reports that the transfer has completed This looks much better. However, I did not trace the call chain in linux kernel down to the block layer yet. Maybe I should. BR, Michael ___ 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
Hi Andrew,
On Tue, 14 May 2013 12:27:52 -0500, 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.
>
> Signed-off-by: Andrew Gabbasov
> ---
> drivers/mtd/cfi_flash.c | 15 +--
> include/mtd/cfi_flash.h | 18 +++---
> 2 files changed, 20 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
> index 22d8440..f6759a8 100644
> --- a/drivers/mtd/cfi_flash.c
> +++ b/drivers/mtd/cfi_flash.c
> @@ -38,6 +38,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -1640,9 +1641,10 @@ static void cfi_reverse_geometry(struct cfi_qry *qry)
> u32 tmp;
>
> for (i = 0, j = qry->num_erase_regions - 1; i < j; i++, j--) {
> - tmp = qry->erase_region_info[i];
> - qry->erase_region_info[i] = qry->erase_region_info[j];
> - qry->erase_region_info[j] = tmp;
> + tmp = get_unaligned(&(qry->erase_region_info[i]));
> + put_unaligned(get_unaligned(&(qry->erase_region_info[j])),
> + &(qry->erase_region_info[i]));
> + put_unaligned(tmp, &(qry->erase_region_info[j]));
> }
> }
>
> @@ -2073,8 +2075,8 @@ ulong flash_get_size (phys_addr_t base, int banknum)
> info->start[0] = (ulong)map_physmem(base, info->portwidth, MAP_NOCACHE);
>
> if (flash_detect_cfi (info, &qry)) {
> - info->vendor = le16_to_cpu(qry.p_id);
> - info->ext_addr = le16_to_cpu(qry.p_adr);
> + info->vendor = le16_to_cpu(get_unaligned(&(qry.p_id)));
> + info->ext_addr = le16_to_cpu(get_unaligned(&(qry.p_adr)));
> num_erase_regions = qry.num_erase_regions;
>
> if (info->ext_addr) {
> @@ -2163,7 +2165,8 @@ ulong flash_get_size (phys_addr_t base, int banknum)
> break;
> }
>
> - tmp = le32_to_cpu(qry.erase_region_info[i]);
> + tmp = le32_to_cpu(get_unaligned(
> + &(qry.erase_region_info[i])));
> debug("erase region %u: 0x%08lx\n", i, tmp);
>
> erase_region_count = (tmp & 0x) + 1;
> diff --git a/include/mtd/cfi_flash.h b/include/mtd/cfi_flash.h
> index 966b5e0..b644b91 100644
> --- a/include/mtd/cfi_flash.h
> +++ b/include/mtd/cfi_flash.h
> @@ -129,12 +129,16 @@ typedef union {
> } cfiword_t;
>
> /* CFI standard query structure */
> +/* The offsets and sizes of this packed structure members correspond
> + * to the actual layout in CFI Flash chips. Some 16- and 32-bit members
> + * are unaligned and must be accessed with explicit unaligned access macros.
> + */
> struct cfi_qry {
> u8 qry[3];
> - u16 p_id;
> - u16 p_adr;
> - u16 a_id;
> - u16 a_adr;
> + u16 p_id; /* unaligned */
> + u16 p_adr; /* unaligned */
> + u16 a_id; /* unaligned */
> + u16 a_adr; /* unaligned */
> u8 vcc_min;
> u8 vcc_max;
> u8 vpp_min;
> @@ -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
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?
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] input: fix unaligned access in key_matrix_decode_fdt()
From: Stephen Warren
Initialized character arrays on the stack can cause gcc to emit code that
performs unaligned accessess. Make the data static to avoid this.
Note that the unaligned accesses are made when copying data to prefix[] on
the stack from .rodata. By making the data static, the copy is completely
avoided. All explicitly written code treats the data as u8[], so will never
cause any unaligned accesses.
Signed-off-by: Stephen Warren
---
drivers/input/key_matrix.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/key_matrix.c b/drivers/input/key_matrix.c
index 946a186..c8b048e 100644
--- a/drivers/input/key_matrix.c
+++ b/drivers/input/key_matrix.c
@@ -158,7 +158,7 @@ int key_matrix_decode_fdt(struct key_matrix *config, const
void *blob,
int node)
{
const struct fdt_property *prop;
- const char prefix[] = "linux,";
+ static const char prefix[] = "linux,";
int plen = sizeof(prefix) - 1;
int offset;
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 2/4] mmc: report capacity for the selected partition
From: Stephen Warren
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
---
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 @@
#d
[U-Boot] [PATCH V2 1/4] README: document CONFIG_ENV_IS_IN_MMC
From: Stephen Warren 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 --- v2: New patch. --- README | 38 ++ 1 file changed, 38 insertions(+) diff --git a/README b/README index 3012dcd..b9936ca 100644 --- a/README +++ b/README @@ -3606,6 +3606,44 @@ 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 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 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_OFFSET. + - 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 V2 3/4] env_mmc: allow negative CONFIG_ENV_OFFSET
From: Stephen Warren
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
---
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 b9936ca..4335730 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 must be aligned to an MMC sector boundary.
- CONFIG_ENV_OFFSET_REDUND (optional):
@@ -3636,6 +3644,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 must also be aligned to an MMC sector boundary.
- CONFIG_ENV_SIZE_REDUND (optional):
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 V2 4/4] ARM: tegra: make use of negative ENV_OFFSET on NVIDIA boards
From: Stephen Warren 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 --- 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
Re: [U-Boot] [PATCH 1/5] arch/powerpc/cpu/mpc8xxx: PAMU driver support
On Thu, Mar 28, 2013 at 5:46 AM, Ruchika Gupta
wrote:
> PAMU driver basic support for usage in Secure Boot.
> In secure boot PAMU is not in bypass mode. Hence to use
> any peripheral (SEC Job ring in our case), PAMU has to be
> configured.
>
> The Header file fsl_pamu.h and few functions in driver have been derived
> from Freescale Libos.
>
> Signed-off-by: Kuldip Giroh
> Signed-off-by: Ruchika Gupta
> ---
> Based upon git://git.denx.de/u-boot.git branch master
>
You don't really have to say this as a) It's assumed, b) It becomes quickly
obsolete (as it is now). You probably only need to mention it if you're
based on an unusual git repo.
diff --git a/arch/powerpc/cpu/mpc8xxx/fsl_pamu.c
b/arch/powerpc/cpu/mpc8xxx/fsl_pamu.c
new file mode 100644
index 000..bdbec07
--- /dev/null
+++ b/arch/powerpc/cpu/mpc8xxx/fsl_pamu.c
[...]
+
+static inline int __ilog2_roundup_64(uint64_t val)
+{
+
+ if ((val & (val - 1)) == 0)
+ return __ilog2_u64(val);
+ else
+ return __ilog2_u64(val) + 1;
+}
These sorts of functions seem like they belong
in arch/powerpc/include/asm/bitops.h
> +
> +
> +static inline int count_lsb_zeroes(unsigned long val)
> +{
> + return ffs(val) - 1;
> +}
> +
>
[...]
> +static int pamu_config_ppaace(uint32_t liodn, uint64_t win_addr,
> + uint64_t win_size, uint32_t omi,
> + uint32_t snoopid, uint32_t stashid,
> + uint32_t subwin_cnt)
> +{
> + unsigned long fspi;
> + paace_t *ppaace;
> +
> + if ((win_size & (win_size - 1)) || win_size < PAMU_PAGE_SIZE)
> + return -1;
> +
> + if (win_addr & (win_size - 1))
> + return -2;
> +
> + if (liodn > NUM_PPAACT_ENTRIES) {
> + printf("Entries in PPACT not sufficient\n");
> + return -3;
> + }
>
These return values should really have names to define, up-front, what they
mean.
> +
> + ppaace = &ppaact[liodn];
> +
> + /* window size is 2^(WSE+1) bytes */
> + set_bf(ppaace->addr_bitfields, PPAACE_AF_WSE,
> + map_addrspace_size_to_wse(win_size));
> +
> + pamu_setup_default_xfer_to_host_ppaace(ppaace);
> +
> + if (sizeof(phys_addr_t) > 4)
> + ppaace->wbah = (u64)win_addr >> (PAMU_PAGE_SHIFT + 20);
> + else
> + ppaace->wbah = 0;
> +
> + set_bf(ppaace->addr_bitfields, PPAACE_AF_WBAL,
> + (win_addr >> PAMU_PAGE_SHIFT));
> +
> + /* set up operation mapping if it's configured */
> + if (omi < OME_NUMBER_ENTRIES) {
> + set_bf(ppaace->impl_attr, PAACE_IA_OTM, PAACE_OTM_INDEXED);
> + ppaace->op_encode.index_ot.omi = omi;
> + } else if (~omi != 0)
> + return -3;
>
ditto here
> +static int pamu_config_spaace(uint32_t liodn,
> + uint64_t subwin_size, uint64_t subwin_addr, uint64_t size,
> + uint32_t omi, uint32_t snoopid, uint32_t stashid)
> +{
> + paace_t *paace;
> + unsigned long fspi;
> + /* Align start addr of subwin to subwindoe size */
> + uint64_t sec_addr = subwin_addr & ~(subwin_size - 1);
> + uint64_t end_addr = subwin_addr + size;
> + int size_shift = __ilog2_u64(subwin_size);
> + uint64_t win_size = 0;
> + uint32_t index, swse;
> +
> + /* Recalculate the size */
> + size = end_addr - sec_addr;
> +
> + if (!subwin_size)
> + return -1;
>
Also need a named constant here
> +
> + if (liodn > NUM_PPAACT_ENTRIES) {
> + printf("LIODN Number to be programmed %d"
> + "greater than number of PPAACT entries %d\n",
> + liodn, NUM_PPAACT_ENTRIES);
> + return -1;
> + }
>
And here
> +
> + while (sec_addr < end_addr) {
> +#ifdef DEBUG
> + printf("sec_addr < end_addr is %llx < %llx\n", sec_addr,
> + end_addr);
> +#endif
> + paace = &ppaact[liodn];
> + if (!paace)
> + return -1;
>
And here
+
+int pamu_init(void)
+{
+ u32 base_addr = CONFIG_SYS_PAMU_ADDR;
void *base_addr = (void *)CONFIG_SYS_PAMU_ADDR;
+ ccsr_pamu_t *regs;
+ u32 i = 0;
+ u64 ppaact_phys, ppaact_lim, ppaact_size;
+ u64 spaact_phys, spaact_lim, spaact_size;
+
+ ppaact_size = sizeof(paace_t) * NUM_PPAACT_ENTRIES;
+ spaact_size = sizeof(paace_t) * NUM_SPAACT_ENTRIES;
+
+ /* Allocate space for Primary PAACT Table */
+ ppaact = memalign(PAMU_TABLE_ALIGNMENT, ppaact_size);
+ if (!ppaact)
+ return -1;
Named constant.
> + memset(ppaact, 0, ppaact_size);
> +
> + /* Allocate space for Secondary PAACT Table */
> + sec = memalign(PAMU_TABLE_ALIGNMENT, spaact_size);
> + if (!sec)
> + return -1;
>
And here
> + memset(sec, 0, spaact_size);
> +
> + ppaact_phys = virt_to_phys((void *)ppaact);
Re: [U-Boot] [PATCH v3 06/10] MIPS: qemu-malta: add PCI support
2013/5/22 Gabor Juhos :
> 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
> Cc: Daniel Schwierzeck
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]
pci_gt64120.c: In function 'gt64120_pci_init':
pci_gt64120.c:178:1: warning: control reaches end of non-void function
[-Wreturn-type]
> ---
> Changes since v2:
> - move the PCI driver to drivers/pci
> - fix checkpatch warnings
> - rebased against the master branch of git.denx.de/u-boot.git
>
> Changes since v1:
> - rebased against mips/testing
>
> Changes since RFC:
> - use a C struct to define the register layout instead
> of using a base address plus offset notation
> - remove custom IO accessors
>
> Screenshot:
>
> U-Boot 2013.04-00242-g8960ff8 (May 22 2013 - 13:25:13)
>
> Board: MIPS Malta CoreLV (Qemu)
> DRAM: 256 MiB
> pflash_write: Unimplemented flash cmd sequence (offset ,
> wcycle 0x0 cmd 0x0 value 0xf0)
> Flash: 4 MiB
> Using default environment
>
> In:serial
> Out: serial
> Err: serial
> qemu-malta # pci
> Scanning PCI devices on bus 0
> BusDevFun VendorId DeviceId Device Class Sub-Class
> _
> 00.00.00 0x11ab 0x4620 Bridge device 0x00
> 00.0a.00 0x8086 0x7110 Bridge device 0x01
> 00.0a.01 0x8086 0x7111 Mass storage controller 0x01
> 00.0a.02 0x8086 0x7112 Serial bus controller 0x03
> 00.0a.03 0x8086 0x7113 Bridge device 0x80
> 00.0b.00 0x1022 0x2000 Network controller 0x00
> qemu-malta #
> ---
> board/qemu-malta/qemu-malta.c | 12 +++
> drivers/pci/Makefile |1 +
> drivers/pci/pci_gt64120.c | 178
> +
> include/configs/qemu-malta.h |6 ++
> include/pci_gt64120.h | 19 +
> 5 files changed, 216 insertions(+)
> create mode 100644 drivers/pci/pci_gt64120.c
> create mode 100644 include/pci_gt64120.h
>
> diff --git a/board/qemu-malta/qemu-malta.c b/board/qemu-malta/qemu-malta.c
> index 449da9c..e3a733f 100644
> --- a/board/qemu-malta/qemu-malta.c
> +++ b/board/qemu-malta/qemu-malta.c
> @@ -8,8 +8,10 @@
>
> #include
>
> +#include
> #include
> #include
> +#include
>
> phys_size_t initdram(int board_type)
> {
> @@ -29,3 +31,13 @@ void _machine_restart(void)
> reset_base = (void __iomem *)CKSEG1ADDR(MALTA_RESET_BASE);
> __raw_writel(GORESET, reset_base);
> }
> +
> +void pci_init_board(void)
> +{
> + set_io_port_base(CKSEG1ADDR(MALTA_IO_PORT_BASE));
> +
> + gt64120_pci_init((void *)CKSEG1ADDR(MALTA_GT_BASE),
> +0x, 0x, CONFIG_SYS_MEM_SIZE,
> +0x1000, 0x1000, 128 * 1024 * 1024,
> +0x, 0x, 0x2);
> +}
> diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
> index 1ae35d3..02d2309 100644
> --- a/drivers/pci/Makefile
> +++ b/drivers/pci/Makefile
> @@ -27,6 +27,7 @@ LIB := $(obj)libpci.o
>
> COBJS-$(CONFIG_FSL_PCI_INIT) += fsl_pci_init.o
> COBJS-$(CONFIG_PCI) += pci.o pci_auto.o pci_indirect.o
> +COBJS-$(CONFIG_PCI_GT64120) += pci_gt64120.o
> COBJS-$(CONFIG_FTPCI100) += pci_ftpci100.o
> COBJS-$(CONFIG_IXP_PCI) += pci_ixp.o
> COBJS-$(CONFIG_SH4_PCI) += pci_sh4.o
> diff --git a/drivers/pci/pci_gt64120.c b/drivers/pci/pci_gt64120.c
> new file mode 100644
> index 000..c2f2049
> --- /dev/null
> +++ b/drivers/pci/pci_gt64120.c
> @@ -0,0 +1,178 @@
> +/*
> + * Copyright (C) 2013 Gabor Juhos
> + *
> + * Based on the Linux implementation.
> + * Copyright (C) 1999, 2000, 2004 MIPS Technologies, Inc.
> + * Authors: Carsten Langgaard
> + *Maciej W. Rozycki
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public Licens
Re: [U-Boot] [PATCH v03 1/2] OMAP3+: introduce generic ABB support
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 :(
[...]
Other than this, I have no further comments.
--
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] nand/fsl_elbc: detect page size at runtime
On Tue, Feb 26, 2013 at 01:00:50PM -, Scott Wood wrote: > This avoids needing a separate U-Boot config when some revisions > of a board have small-page NAND and other revisions have large-page > NAND (except for NAND SPL targets). > > CONFIG_FSL_ELBC_FMR is removed -- it was never used nor documented, and > it gets in the way of this change. > > Signed-off-by: Scott Wood > > --- > drivers/mtd/nand/fsl_elbc_nand.c | 39 +- > 1 file changed, 22 insertions(+), 17 deletions(-) Applied to u-boot-nand-flash. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] powerpc: fix 8xx and 82xx type-punning warnings with GCC 4.7
Dear Scott Wood, In message <20130518010154.ga28...@home.buserror.net> you wrote: > C99's strict aliasing rules are insane to use in low-level code such as a > bootloader, but as Wolfgang has rejected -fno-strict-aliasing in the > past, add a union so that 16-bit accesses can be performed. > > Compile-tested only. > > Signed-off-by: Scott Wood Thanks! Acked-by: Wolfgang Denk 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 "'Tis true, 'tis pity, and pity 'tis 'tis true." - Poloniouius, in Willie the Shake's _Hamlet, Prince of Darkness_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] common/Makefile: Add new symbol CONFIG_SPL_ENV_SUPPORT for environment in SPL
On Wed, May 22, 2013 at 08:06:01AM +, Zhang Ying-B40530 wrote: > > > -Original Message- > From: Stefan Roese [mailto:s...@denx.de] > Sent: Wednesday, May 22, 2013 2:09 PM > To: Wood Scott-B07421 > Cc: Zhang Ying-B40530; Wood Scott-B07421; x...@theia.denx.de; > u-boot@lists.denx.de; aflem...@gmail.com > Subject: Re: [U-Boot] [PATCH] common/Makefile: Add new symbol > CONFIG_SPL_ENV_SUPPORT for environment in SPL > > (sorry for jumping in so late in this discussion) > > On 05/21/2013 09:14 PM, Scott Wood wrote: > >> This is Tom's words: > >> > >> a3m071 relies on SPL always building cmd_nvedit.o and env_common.o and > >> duplicated CONFIG_ENV_IS_IN_FLASH in the SPL section. > >> > >> CONFIG_SPL_NET_SUPPORT relies on the same always-built ins and adds > >> env_nowhere.o which works because the regular CONFIG_ENV_IS_IN_... > >> > >> section is in the non-SPL-only area. > > > > If "SPL: Makefile: Build a separate autoconf.mk for SPL" gets merged, > > we could just have a3m071 define CONFIG_ENV_IS_NOWHERE in the SPL build > > case. > > But the a3m071 SPL U-Boot version also uses the env from NOR flash. So > defining CONFIG_ENV_IS_NOWHERE here would be really confusing! > [Zhang Ying] > I think Scott means that the specific boards CONFIG_SPL_NET_SUPPORT > is set should define CONFIG_ENV_IS_NOWHERE in the SPL build case. For > example: am335x and pcm051. Correct. I need to see if I can reproduce the problem I had with Joel's patch however. -- 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] nand: adjust erase/read/write partition/chip size for bad blocks
On Tue, Feb 26, 2013 at 05:21:27PM -, Harvey Chapman wrote: > Adjust the sizes calculated for whole partition/chip operations by > removing the size of bad blocks so we don't try to erase/read/write > past a partition/chip boundary. > > Signed-off-by: Harvey Chapman > > --- > common/cmd_nand.c | 35 +++ > 1 file changed, 35 insertions(+) Applied to u-boot-nand-flash... > + /* size is unspecified */ > + if (argc < 5) > + adjust_size_for_badblocks(&rwsize, off, dev); ...after fixing this to be &size rather than &rwsize. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] nand: adjust erase/read/write partition/chip size for bad blocks
On 05/22/2013 04:36:41 PM, Scott Wood wrote: On Tue, Feb 26, 2013 at 05:21:27PM -, Harvey Chapman wrote: > Adjust the sizes calculated for whole partition/chip operations by > removing the size of bad blocks so we don't try to erase/read/write > past a partition/chip boundary. > > Signed-off-by: Harvey Chapman > > --- > common/cmd_nand.c | 35 +++ > 1 file changed, 35 insertions(+) Applied to u-boot-nand-flash... > + /* size is unspecified */ > + if (argc < 5) > +adjust_size_for_badblocks(&rwsize, off, dev); ...after fixing this to be &size rather than &rwsize. ...and then noticed that the next patch in my queue was a resent version of this with that fixed. :-P -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mtd: nand: fix the partial page write condition
On Fri, Mar 01, 2013 at 10:59:27PM -, htbegin wrote: > When writelen is mtd->writesize - 1, it is still a partial page write > > Signed-off-by: Tao Hou > Cc: Scott Wood > > --- > drivers/mtd/nand/nand_base.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Applied to u-boot-nand-flash -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mtd: nand: use ssize_t instead of size_t to prevent infinite loop
On Fri, Mar 01, 2013 at 11:00:34PM -, htbegin wrote: > When a all 0xFF buffer is passed to drop_ffs, the no-0xFF check loop > will loop forever. > After the fix, If ssize_t i = -1 and size_t l = i + 1, the value of l > will still be 0 as expected. > > Signed-off-by: Tao Hou > Cc: Ben Gardiner > Cc: Scott Wood > > --- > drivers/mtd/nand/nand_util.c |3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) Applied to u-boot-nand-flash -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] nand/fsl_ifc: Convert to self-init
On Thu, Apr 04, 2013 at 06:44:06PM -, Prabhakar Kushwaha wrote: > Convert NAND IFC driver to support CONFIG_SYS_NAND_SELF_INIT. > > Signed-off-by: Prabhakar Kushwaha > > --- > Based upon git://git.denx.de/u-boot.git branch master > > drivers/mtd/nand/fsl_ifc_nand.c | 42 > ++- > include/nand.h |3 ++- > 2 files changed, 39 insertions(+), 6 deletions(-) Applied to u-boot-nand-flash -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [u-boot-mips] gp init and -pie option
Jason Harris motorolasolutions.com> writes: > > Looks like something is wrong with option processing on ld. > I take it back: The patch from http://sourceware.org/bugzilla/show_bug.cgi?id=10858 fixes it. Jason H. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6] spl: Make CONFIG_SPL_BUILD contain more functionality
-Original Message- From: Wood Scott-B07421 Sent: Wednesday, May 22, 2013 11:46 PM To: Zhang Ying-B40530 Cc: Wood Scott-B07421; u-boot@lists.denx.de; aflem...@gmail.com; Xie Xiaobo-R63061; Ilya Yanok Subject: Re: [PATCH 5/6] spl: Make CONFIG_SPL_BUILD contain more functionality On 05/21/2013 09:15:08 PM, Zhang Ying-B40530 wrote: > > diff --git a/include/configs/MPC8313ERDB.h > > b/include/configs/MPC8313ERDB.h > > index c28dfe0..a2bdcff 100644 > > --- a/include/configs/MPC8313ERDB.h > > +++ b/include/configs/MPC8313ERDB.h > > @@ -40,7 +40,9 @@ > > #define CONFIG_SPL_INIT_MINIMAL > > #define CONFIG_SPL_SERIAL_SUPPORT > > #define CONFIG_SPL_NAND_SUPPORT > > +#ifdef CONFIG_SPL_BUILD > > #define CONFIG_SPL_NAND_MINIMAL > > +#endif > > #define CONFIG_SPL_FLUSH_IMAGE > > #define CONFIG_SPL_TARGET "u-boot-with-spl.bin" > > #define CONFIG_SPL_MPC83XX_WAIT_FOR_NAND > > diff --git a/include/configs/P1022DS.h b/include/configs/P1022DS.h > > index 8b13b10..5bdd44a 100644 > > --- a/include/configs/P1022DS.h > > +++ b/include/configs/P1022DS.h > > @@ -41,7 +41,9 @@ > > #define CONFIG_SPL_INIT_MINIMAL > > #define CONFIG_SPL_SERIAL_SUPPORT > > #define CONFIG_SPL_NAND_SUPPORT > > +#ifdef CONFIG_SPL_BUILD > > #define CONFIG_SPL_NAND_MINIMAL > > +#endif > > #define CONFIG_SPL_FLUSH_IMAGE > > #define CONFIG_SPL_TARGET "u-boot-with-spl.bin" > > > > diff --git a/include/configs/p1_p2_rdb_pc.h > > b/include/configs/p1_p2_rdb_pc.h > > index 7ed634b..bc48d62 100644 > > --- a/include/configs/p1_p2_rdb_pc.h > > +++ b/include/configs/p1_p2_rdb_pc.h > > @@ -159,7 +159,9 @@ > > #define CONFIG_SPL_INIT_MINIMAL > > #define CONFIG_SPL_SERIAL_SUPPORT > > #define CONFIG_SPL_NAND_SUPPORT > > +#ifdef CONFIG_SPL_BUILD > > #define CONFIG_SPL_NAND_MINIMAL > > +#endif > > #define CONFIG_SPL_FLUSH_IMAGE > > #define CONFIG_SPL_TARGET "u-boot-with-spl.bin" > > Are you sure this belongs in this patch? > [Zhang Ying] > Yes, it is necessary. Because CONFIG_SPL_NAND_MINIMAL has been used > in the file law.c and tlb.c in this patch. What I mean is that it should probably have been done earlier, when you introduced CONFIG_SPL_NAND_MINIMAL. [Zhang Ying] I can understand you mean. Because the symbol "CONFIG_SPL_NAND_MINIMAL" has been useless, I think no need to split out a separate patch. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] common/Makefile: Add new symbol CONFIG_SPL_ENV_SUPPORT for environment in SPL
-Original Message- From: Tom Rini [mailto:tom.r...@gmail.com] On Behalf Of Tom Rini Sent: Thursday, May 23, 2013 5:23 AM To: Zhang Ying-B40530 Cc: Stefan Roese; Wood Scott-B07421; x...@theia.denx.de; aflem...@gmail.com; u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] common/Makefile: Add new symbol CONFIG_SPL_ENV_SUPPORT for environment in SPL On Wed, May 22, 2013 at 08:06:01AM +, Zhang Ying-B40530 wrote: > > > -Original Message- > From: Stefan Roese [mailto:s...@denx.de] > Sent: Wednesday, May 22, 2013 2:09 PM > To: Wood Scott-B07421 > Cc: Zhang Ying-B40530; Wood Scott-B07421; x...@theia.denx.de; > u-boot@lists.denx.de; aflem...@gmail.com > Subject: Re: [U-Boot] [PATCH] common/Makefile: Add new symbol > CONFIG_SPL_ENV_SUPPORT for environment in SPL > > (sorry for jumping in so late in this discussion) > > On 05/21/2013 09:14 PM, Scott Wood wrote: > >> This is Tom's words: > >> > >> a3m071 relies on SPL always building cmd_nvedit.o and env_common.o and > >> duplicated CONFIG_ENV_IS_IN_FLASH in the SPL section. > >> > >> CONFIG_SPL_NET_SUPPORT relies on the same always-built ins and adds > >> env_nowhere.o which works because the regular CONFIG_ENV_IS_IN_... > >> > >> section is in the non-SPL-only area. > > > > If "SPL: Makefile: Build a separate autoconf.mk for SPL" gets merged, > > we could just have a3m071 define CONFIG_ENV_IS_NOWHERE in the SPL build > > case. > > But the a3m071 SPL U-Boot version also uses the env from NOR flash. So > defining CONFIG_ENV_IS_NOWHERE here would be really confusing! > [Zhang Ying] > I think Scott means that the specific boards CONFIG_SPL_NET_SUPPORT > is set should define CONFIG_ENV_IS_NOWHERE in the SPL build case. For > example: am335x and pcm051. Correct. I need to see if I can reproduce the problem I had with Joel's patch however. [Zhang Ying] So, Can you accept this patch now? I hope to finish it early, have spent a long time. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] common/Makefile: Add new symbol CONFIG_SPL_ENV_SUPPORT for environment in SPL
-Original Message- From: Wood Scott-B07421 Sent: Wednesday, May 22, 2013 11:45 PM To: Stefan Roese Cc: Zhang Ying-B40530; Wood Scott-B07421; x...@theia.denx.de; u-boot@lists.denx.de; aflem...@gmail.com Subject: Re: [U-Boot] [PATCH] common/Makefile: Add new symbol CONFIG_SPL_ENV_SUPPORT for environment in SPL On 05/22/2013 01:09:07 AM, Stefan Roese wrote: > (sorry for jumping in so late in this discussion) > > On 05/21/2013 09:14 PM, Scott Wood wrote: > >> This is Tom's words: > >> > >> a3m071 relies on SPL always building cmd_nvedit.o and env_common.o > and > >> duplicated CONFIG_ENV_IS_IN_FLASH in the SPL section. > >> > >> CONFIG_SPL_NET_SUPPORT relies on the same always-built ins and adds > >> env_nowhere.o which works because the regular CONFIG_ENV_IS_IN_... > >> > >> section is in the non-SPL-only area. > > > > If "SPL: Makefile: Build a separate autoconf.mk for SPL" gets > merged, > > we could just have a3m071 define CONFIG_ENV_IS_NOWHERE in the SPL > build > > case. > > But the a3m071 SPL U-Boot version also uses the env from NOR flash. So > defining CONFIG_ENV_IS_NOWHERE here would be really confusing! Why is it including env_nowhere.o then? When you say "the a3m071 SPL U-Boot version", do you mean the SPL itself, or the entire configuration that happens to include an SPL? [Zhang Ying] The a3m071 SPL has not included env_nowhere.o, it only included env_flash.o and CONFIG_ENV_IS_IN_FLASH is set. The am335x and pcm051 SPL included env_nowhere.o and CONFIG_ENV_IS_NOWHERE is set. Meanwhile CONFIG_SPL_NET_SUPPORT is set. What this meant is CONFIG_SPL_NET_SUPPORT only co-exist with CONFIG_ENV_IS_NOWHERE in the SPL. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] powerpc/p1022ds: boot from SD Card with SPL
Hi, everybody.
Do you have any comments?
-Original Message-
From: Zhang Ying-B40530
Sent: Monday, May 20, 2013 2:07 PM
To: u-boot@lists.denx.de
Cc: Wood Scott-B07421; aflem...@gmail.com; Xie Xiaobo-R63061; Zhang Ying-B40530
Subject: [PATCH 6/6] powerpc/p1022ds: boot from SD Card with SPL
From: Ying Zhang
This patch introduces SPL to enable a loader stub that runs in the L2 SRAM,
after being loaded by the code from the internal on-chip ROM. It loads the
final uboot image into DDR, then jump to it to begin execution.
The SPL's size is sizeable, the maximum size must not exceed the size of L2
SRAM. It initializes the DDR through SPD code, and copys final uboot image
to DDR. So there are two stage uboot images:
* spl_boot, 96KB size. The env variables are copied to L2 SRAM, so
that ddr spd code can get the interleaving mode setting in env. It
loads final uboot image from offset 96KB.
* final uboot image, size is variable depends on the functions
enabled.
This patch is on top of the following patch:
1. common/Makefile: Add new symbol CONFIG_SPL_ENV_SUPPORT for environment
in SPL.
2. Makefile: move the common makefile line to public area
3. powerpc/mpc85xx: support application without resetvec segment in the
linker script.
4. powerpc/mpc85xx: modify the function clear_bss and the end address of
the BSS
5. spl: Make CONFIG_SPL_BUILD contain more functionality
Signed-off-by: Ying Zhang
---
README |8 ++
arch/powerpc/cpu/mpc85xx/u-boot-spl.lds|5 +
.../cpu/mpc8xxx/ddr/lc_common_dimm_params.c|4 +
board/freescale/common/Makefile|2 -
board/freescale/p1022ds/Makefile |3 +
board/freescale/p1022ds/spl.c | 112 +
board/freescale/p1022ds/tlb.c |9 ++-
doc/README.mpc85xx-sd-spi-boot | 82
drivers/mmc/Makefile |3 +
drivers/mmc/fsl_esdhc_spl.c| 132
drivers/mmc/mmc.c |4 +-
include/configs/P1022DS.h | 54 +++-
include/fsl_esdhc.h|1 +
spl/Makefile |3 +
14 files changed, 410 insertions(+), 12 deletions(-)
create mode 100644 board/freescale/p1022ds/spl.c
create mode 100644 doc/README.mpc85xx-sd-spi-boot
create mode 100644 drivers/mmc/fsl_esdhc_spl.c
diff --git a/README b/README
index d66e5b0..0ab7b4c 100644
--- a/README
+++ b/README
@@ -2941,6 +2941,14 @@ FIT uImage format:
Support for NAND boot using simple NAND drivers that
expose the cmd_ctrl() interface.
+ CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT
+ Set for the SPL on PPC mpc8xxx targets, support for
+ arch/powerpc/cpu/mpc8xxx/ddr/libddr.o in SPL binary.
+
+ CONFIG_SPL_COMMON_INIT_DDR
+ Set for common ddr init with serial presence detect in
+ SPL binary.
+
CONFIG_SYS_NAND_5_ADDR_CYCLE, CONFIG_SYS_NAND_PAGE_COUNT,
CONFIG_SYS_NAND_PAGE_SIZE, CONFIG_SYS_NAND_OOBSIZE,
CONFIG_SYS_NAND_BLOCK_SIZE, CONFIG_SYS_NAND_BAD_BLOCK_POS,
diff --git a/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
b/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
index 55ff5e8..751feaa 100644
--- a/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
+++ b/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
@@ -57,6 +57,11 @@ SECTIONS
}
_edata = .;
+ . = .;
+ __start___ex_table = .;
+ __ex_table : { *(__ex_table) }
+ __stop___ex_table = .;
+
. = ALIGN(8);
__init_begin = .;
__init_end = .;
diff --git a/arch/powerpc/cpu/mpc8xxx/ddr/lc_common_dimm_params.c
b/arch/powerpc/cpu/mpc8xxx/ddr/lc_common_dimm_params.c
index 9adde31..aa32454 100644
--- a/arch/powerpc/cpu/mpc8xxx/ddr/lc_common_dimm_params.c
+++ b/arch/powerpc/cpu/mpc8xxx/ddr/lc_common_dimm_params.c
@@ -220,12 +220,16 @@ compute_lowest_common_dimm_parameters(const dimm_params_t
*dimm_params,
if (dimm_params[i].n_ranks) {
if (dimm_params[i].registered_dimm) {
temp1 = 1;
+#ifndef CONFIG_SPL_BUILD
printf("Detected RDIMM %s\n",
dimm_params[i].mpart);
+#endif
} else {
temp2 = 1;
+#ifndef CONFIG_SPL_BUILD
printf("Detected UDIMM %s\n",
dimm_params[i].mpart);
+#endif
}
}
}
diff --git a/board/freescale/common/Makefile b/board/freescale/common/Makefile
index 72bb56c..c334797 100644
--- a/board/freescale/common/Makefile
+++ b/board/freescale/common/M
[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
---
: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
#include
+#ifdef CONFIG_DAVINCI_MMC
+#include
+#include
+#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
[U-Boot] Uboot Analysis Question
Hi, in smdk2410.c the PHYS_SDRAM_1 constant is defined in include/configs/smdk2410.h, below headers are included in smdk2410.c: #include #include #include Questions:1)but I dont see smdk2410.h is included so how is this going to work?2) should rename to ?so that it will works? Thanks Best Regards,Toh, Yong Yun ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 6/6] arm: mvf600: Add basic support for Vybrid MVF600TWR board
Hi, Benoit, > On Wednesday, May 22, 2013 5:17:41 AM, Wang Huan-B18965 wrote: > > Hi, Benoit, > > > > > -Original Message- > > > From: Benoît Thébaudeau [mailto:benoit.thebaud...@advansee.com] > > > Sent: Wednesday, May 22, 2013 1:29 AM > > > To: Wang Huan-B18965 > > > Cc: sba...@denx.de; u-boot@lists.denx.de; TsiChung Liew; Jin > > > Zhengxiong- R64188; Estevam Fabio-R49496 > > > Subject: Re: [U-Boot] [PATCH v3 6/6] arm: mvf600: Add basic support > > > for Vybrid MVF600TWR board > > > > > > Hi Alison, > > > > > > On Tuesday, May 21, 2013 11:03:01 AM, Alison Wang wrote: > > > > MVF600TWR is a board based on Vybrid MVF600 SoC. > > > > > > > > This patch adds basic support for Vybrid MVF600TWR board. > > > > > > > > Signed-off-by: Alison Wang > > > > Signed-off-by: Jason Jin > > > > Signed-off-by: TsiChung Liew > > > > > > [...] > > > > > > > diff --git a/include/configs/mvf600twr.h > > > > b/include/configs/mvf600twr.h new file mode 100644 index > > > > 000..1cfb9f6 > > > > --- /dev/null > > > > +++ b/include/configs/mvf600twr.h > > > > @@ -0,0 +1,140 @@ > > > > +/* > > > > + * Copyright 2013 Freescale Semiconductor, Inc. > > > > + * > > > > + * Configuration settings for the Freescale Vybrid mvf600twr > board. > > > > + * > > > > + * This program is free software; you can redistribute it and/or > > > > + * modify it under the terms of the GNU General Public License > as > > > > + * published by the Free Software Foundation; either version 2 > of > > > > + * the License, or (at your option) any later version. > > > > + * > > > > + * This program is distributed in the hope that it will be > > > > +useful, > > > > + * but WITHOUT ANY WARRANTY; without even the implied warranty > of > > > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.See > the > > > > + * GNU General Public License for more details. > > > > + * > > > > + * You should have received a copy of the GNU General Public > > > > +License > > > > + * along with this program; if not, write to the Free Software > > > > + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, > > > > + * MA 02111-1307 USA > > > > + */ > > > > + > > > > +#ifndef __CONFIG_H > > > > +#define __CONFIG_H > > > > + > > > > +#include > > > > +#include > > > > + > > > > +#define CONFIG_MVF600 > > > > + > > > > > > [...] > > > > > > > +#define CONFIG_CMD_PING > > > > +#define CONFIG_CMD_DHCP > > > > +#define CONFIG_CMD_MII > > > > +#define CONFIG_CMD_NET > > > > +#define CONFIG_FEC_MXC > > > > +#define CONFIG_MII > > > > +#define IMX_FEC_BASE ENET_BASE_ADDR > > > > +#define CONFIG_FEC_XCV_TYPERMII > > > > +#define CONFIG_ETHPRIME"FEC" > > > > > > You don't need to define this one with only 1 Ethernet interface > defined. > > > But isn't the MVF600 a dual-Ethernet SoC? > > [Alison Wang] Yes, MVF600 is a dual-Ethernet SoC. I will change it to > "FEC0". > > Thanks. > > CONFIG_ETHPRIME should just be removed if you are not going to enable > the 2nd FEC in U-Boot. But if you plan to enable the 2nd FEC, which > will have to be done now or later for a dual-Ethernet SoC, then you > have to: > - remove CONFIG_FEC_MXC_PHYADDR and IMX_FEC_BASE, > - define CONFIG_ETHPRIME to "FEC0", > - call fecmxc_initialize_multi() once for each FEC instead of calling >fecmxc_initialize() from cpu_eth_init() in generic.c (you can define >ENET1_BASE_ADDR and ENET2_BASE_ADDR instead of ENET_BASE_ADDR in > imx-regs.h, >and CONFIG_FEC1_MXC_PHYADDR and CONFIG_FEC2_MXC_PHYADDR instead of >CONFIG_FEC_MXC_PHYADDR in mvf600twr.h, then pass them to >fecmxc_initialize_multi() from cpu_eth_init(), with 0 and 1 as the > IDs), > - add support for the 2nd FEC in imx_get_mac_from_fuse(), > - update doc/README.mvf600 to say which fuses are used for the MAC > address of >the 2nd FEC. [Alison Wang] Agree. Thanks. Best Regards, Alison Wang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 6/6] arm: mvf600: Add basic support for Vybrid MVF600TWR board
Hi, Benoit, > On Wednesday, May 22, 2013 10:23:12 AM, Wang Huan-B18965 wrote: > > [...] > > > > > + > > > > +#define ENET_PAD_CTRL (PAD_CTL_PUS_47K_UP | PAD_CTL_SPEED_HIGH > > > | \ > > > > + PAD_CTL_DSE_50ohm | PAD_CTL_OBE_IBE_ENABLE) > > > > + > > > > +#define DDR_PAD_CTRL PAD_CTL_DSE_25ohm > > > > > > MUX_PAD_CTRL() could be added to the 4 pad control definitions > above > > > in order to avoid repeating it everywhere below. But using > > > MUX_PAD_CTRL() relies on the fact that the pad control values in > > > mvf_pins.h are all 0 (which is the case, but this is dangerous if > > > this is changed later), so a better approach could be to use > NEW_PAD_CTRL(), e.g.: > > > NEW_PAD_CTRL(MVF600_PAD_DDR_A15__DDR_A_15, DDR_PAD_CTRL), > > > instead of: > > > MVF600_PAD_DDR_A15__DDR_A_15 | MUX_PAD_CTRL(DDR_PAD_CTRL), > > > > > > > + > > [Alison Wang] I have a question about using NEW_PAD_CTRL(). If > > NEW_PAD_CTRL() is used, should the pad control values for > > MVF600_PAD_DDR_A15__DDR_A_15 in mvf_pins.h be the same as > > DDR_PAD_CTRL? I saw you didn't use the same value on other platforms, > > how do you define it? > > No, you don't have to change mvf_pins.h. That's what NEW_PAD_CTRL() is > useful > for: You can have any pad control value defined in mvf_pins.h, and a > board can override the pad control values when using definitions from > mvf_pins.h, without having to modify mvf_pins.h. > > E.g.: > --- > mvf_pins.h: > MVF600_PAD_PTA6__RMII0_CLKIN = IOMUX_PAD(0x0, 0x0, 2, 0x0, 0, > PAD_CTRL1), > > mvf600twr.c: > NEW_PAD_CTRL(MVF600_PAD_PTA6__RMII0_CLKIN, PAD_CTRL2), > --- > would have the same effect as a theoretical: > --- > mvf_pins.h: > MVF600_PAD_PTA6__RMII0_CLKIN = IOMUX_PAD(0x0, 0x0, 2, 0x0, 0, > PAD_CTRL2), > > mvf600twr.c: > MVF600_PAD_PTA6__RMII0_CLKIN, > --- > > But if you think that the pad control values that you have defined in > mvf600twr.c are not specific to this board and should be used as the > default pad control values for all boards based on the MVF600, then you > should move those definitions to mvf_pins.h, and use them there, which > means that you will no longer need MUX_PAD_CTRL() or NEW_PAD_CTRL() in > mvf600twr.c: > --- > mvf_pins.h: > #define MVF600_DDR_PAD_CTRL PAD_CTL_DSE_25ohm > ... > MVF600_PAD_DDR_A15__DDR_A_15 = IOMUX_PAD(0x0220, 0x0220, 0, 0x, 0, > MVF600_DDR_PAD_CTRL), > > mvf600twr.c: > MVF600_PAD_DDR_A15__DDR_A_15, [Alison Wang] I see. Thanks. Best Regards, Alison Wang ___ 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
Hi Albert,
On 05/22/2013 08:50 PM, Albert ARIBAUD wrote:
>> @@ -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
>
> 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 >> wrote: >>> Dear Bo Shen, >>> >>> >>> On 12.03.2013 07:15, Bo Shen wrote: Add macb support for sama5d3x devices Signed-off-by: Bo Shen --- 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
