[U-Boot] [PATCH v3 1/3] sunxi: add basic V3s support
Basic U-Boot support is now present for V3s.
Some memory addresses are changed specially for V3s, as the original
address map cannot fit into a so small DRAM.
As the DRAM controller code needs a big refactor, the SPL support is
disabled in this version.
Signed-off-by: Icenowy Zheng
---
Changes in v3:
- removed some dead code about DFU and video.
arch/arm/include/asm/arch-sunxi/gpio.h | 1 +
arch/arm/mach-sunxi/board.c| 4
arch/arm/mach-sunxi/cpu_info.c | 2 ++
board/sunxi/Kconfig| 14 --
include/configs/sun8i.h| 2 ++
include/configs/sunxi-common.h | 30 +++---
6 files changed, 48 insertions(+), 5 deletions(-)
diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h
b/arch/arm/include/asm/arch-sunxi/gpio.h
index 85a4ec3b0e..24f85206c8 100644
--- a/arch/arm/include/asm/arch-sunxi/gpio.h
+++ b/arch/arm/include/asm/arch-sunxi/gpio.h
@@ -161,6 +161,7 @@ enum sunxi_gpio_number {
#define SUN8I_GPB_UART22
#define SUN8I_A33_GPB_UART03
#define SUN8I_A83T_GPB_UART0 2
+#define SUN8I_V3S_GPB_UART03
#define SUN50I_GPB_UART0 4
#define SUNXI_GPC_NAND 2
diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
index 52be5b0551..90b3b94e51 100644
--- a/arch/arm/mach-sunxi/board.c
+++ b/arch/arm/mach-sunxi/board.c
@@ -110,6 +110,10 @@ static int gpio_init(void)
sunxi_gpio_set_cfgpin(SUNXI_GPB(9), SUN8I_A83T_GPB_UART0);
sunxi_gpio_set_cfgpin(SUNXI_GPB(10), SUN8I_A83T_GPB_UART0);
sunxi_gpio_set_pull(SUNXI_GPB(10), SUNXI_GPIO_PULL_UP);
+#elif CONFIG_CONS_INDEX == 1 && defined(CONFIG_MACH_SUN8I_V3S)
+ sunxi_gpio_set_cfgpin(SUNXI_GPB(8), SUN8I_V3S_GPB_UART0);
+ sunxi_gpio_set_cfgpin(SUNXI_GPB(9), SUN8I_V3S_GPB_UART0);
+ sunxi_gpio_set_pull(SUNXI_GPB(9), SUNXI_GPIO_PULL_UP);
#elif CONFIG_CONS_INDEX == 1 && defined(CONFIG_MACH_SUN9I)
sunxi_gpio_set_cfgpin(SUNXI_GPH(12), SUN9I_GPH_UART0);
sunxi_gpio_set_cfgpin(SUNXI_GPH(13), SUN9I_GPH_UART0);
diff --git a/arch/arm/mach-sunxi/cpu_info.c b/arch/arm/mach-sunxi/cpu_info.c
index f1f6fd5ba4..15f1e0e45a 100644
--- a/arch/arm/mach-sunxi/cpu_info.c
+++ b/arch/arm/mach-sunxi/cpu_info.c
@@ -87,6 +87,8 @@ int print_cpuinfo(void)
printf("CPU: Allwinner A83T (SUN8I %04x)\n", sunxi_get_sram_id());
#elif defined CONFIG_MACH_SUN8I_H3
printf("CPU: Allwinner H3 (SUN8I %04x)\n", sunxi_get_sram_id());
+#elif defined CONFIG_MACH_SUN8I_V3S
+ printf("CPU: Allwinner V3s (SUN8I %04x)\n", sunxi_get_sram_id());
#elif defined CONFIG_MACH_SUN9I
puts("CPU: Allwinner A80 (SUN9I)\n");
#elif defined CONFIG_MACH_SUN50I
diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index 37b42521a4..018bdd12dd 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -115,6 +115,14 @@ config MACH_SUN8I_H3
select SUPPORT_SPL
select ARMV7_BOOT_SEC_DEFAULT if OLD_SUNXI_KERNEL_COMPAT
+config MACH_SUN8I_V3S
+ bool "sun8i (Allwinner V3s)"
+ select CPU_V7
+ select CPU_V7_HAS_NONSEC
+ select CPU_V7_HAS_VIRT
+ select SUNXI_GEN_SUN6I
+ select ARMV7_BOOT_SEC_DEFAULT if OLD_SUNXI_KERNEL_COMPAT
+
config MACH_SUN9I
bool "sun9i (Allwinner A80)"
select CPU_V7
@@ -132,7 +140,8 @@ endchoice
# The sun8i SoCs share a lot, this helps to avoid a lot of "if A23 || A33"
config MACH_SUN8I
bool
- default y if MACH_SUN8I_A23 || MACH_SUN8I_A33 || MACH_SUN8I_H3 ||
MACH_SUN8I_A83T
+ default y if MACH_SUN8I_A23 || MACH_SUN8I_A33 || MACH_SUN8I_H3 || \
+ MACH_SUN8I_A83T || MACH_SUN8I_V3S
config RESERVE_ALLWINNER_BOOT0_HEADER
bool "reserve space for Allwinner boot0 header"
@@ -485,7 +494,8 @@ config AXP_GPIO
config VIDEO
bool "Enable graphical uboot console on HDMI, LCD or VGA"
- depends on !MACH_SUN8I_A83T && !MACH_SUN8I_H3 && !MACH_SUN9I &&
!MACH_SUN50I
+ depends on !MACH_SUN8I_A83T && !MACH_SUN8I_H3 && !MACH_SUN8I_V3S && \
+ !MACH_SUN9I && !MACH_SUN50I
default y
---help---
Say Y here to add support for using a cfb console on the HDMI, LCD
diff --git a/include/configs/sun8i.h b/include/configs/sun8i.h
index a4c3fb69e4..6ac42acaea 100644
--- a/include/configs/sun8i.h
+++ b/include/configs/sun8i.h
@@ -21,6 +21,8 @@
#define CONFIG_SUNXI_USB_PHYS 4
#elif defined CONFIG_MACH_SUN8I_A83T
#define CONFIG_SUNXI_USB_PHYS 3
+#elif defined CONFIG_MACH_SUN8I_V3S
+ #define CONFIG_SUNXI_USB_PHYS 1
#else
#define CONFIG_SUNXI_USB_PHYS 2
#endif
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 3ac96da190..41d47acfd2 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -75,8 +75,13 @@
#else
#define SDRAM_OFFSET(x) 0x4##x
#define CONFIG_SYS_SDRAM_BASE 0x4000
-#define CONFIG_SYS_LOAD_ADDR 0x4200 /
Re: [U-Boot] [PATCH] exynos: Drop large alignment for SDRAM parameters
Dear Simon Glass, On 9 February 2017 at 17:31, Jaehoon Chung wrote: > On 02/08/2017 09:43 PM, Simon Glass wrote: > > We don't ever search for these so there is no need for a 4KB alignment. > > It just wastes space. > > > > Drop this and use the standard 4-byte alignment. > > > > Signed-off-by: Simon Glass > > Reviewed-by: Jaehoon Chung > > applied to u-boot-samsung. Thanks, Minkyu Kang. -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] please pull u-boot-samsung master
Dear Tom, The following changes since commit f1cc97764be4383d2aeb56d5ba5415439a1d5c97: Merge branch 'master' of git://git.denx.de/u-boot-video (2017-02-09 14:54:09 -0500) are available in the git repository at: git://git.denx.de/u-boot-samsung.git master for you to fetch changes up to 5d3be0f81ca7668ac04ee0f0b7d82e123c7f59b5: exynos: Drop large alignment for SDRAM parameters (2017-02-10 18:51:51 +0900) Simon Glass (1): exynos: Drop large alignment for SDRAM parameters board/samsung/common/exynos-uboot-spl.lds |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] flash: compile common/flash.c iif CONFIG_MTD_NO_FLASH is enabled
The whole of common/flash.c is guarded by #if defined() ... #endif. Move the conditional to common/Makefile. Signed-off-by: Masahiro Yamada --- common/Makefile | 2 +- common/flash.c | 5 - 2 files changed, 1 insertion(+), 6 deletions(-) diff --git a/common/Makefile b/common/Makefile index ecc23e6..86225f1 100644 --- a/common/Makefile +++ b/common/Makefile @@ -67,7 +67,7 @@ endif # others obj-$(CONFIG_BOOTSTAGE) += bootstage.o obj-$(CONFIG_CONSOLE_MUX) += iomux.o -obj-y += flash.o +obj-$(CONFIG_MTD_NOR_FLASH) += flash.o obj-$(CONFIG_CMD_KGDB) += kgdb.o kgdb_stubs.o obj-$(CONFIG_I2C_EDID) += edid.o obj-$(CONFIG_KALLSYMS) += kallsyms.o diff --git a/common/flash.c b/common/flash.c index 6d492c7..587ef60 100644 --- a/common/flash.c +++ b/common/flash.c @@ -10,7 +10,6 @@ #include #include -#if defined(CONFIG_MTD_NOR_FLASH) #include extern flash_info_t flash_info[]; /* info for FLASH chips */ @@ -218,7 +217,3 @@ void flash_perror (int err) break; } } - -/*--- - */ -#endif /* !CONFIG_MTD_NOR_FLASH */ -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/3] Move CONFIG_SYS_NO_FLASH and rename it to CONFIG_MTD_NOR_FLASH
Masahiro Yamada (3): configs: Re-sync all defconfig files by savedefconfig flash: complete CONFIG_SYS_NO_FLASH move with renaming flash: compile common/flash.c iif CONFIG_MTD_NO_FLASH is enabled README | 13 - arch/arm/cpu/armv7/mx6/clock.c | 2 +- arch/arm/mach-uniphier/micro-support-card.c| 6 ++-- board/amcc/sequoia/sequoia.c | 8 ++--- board/atmel/at91sam9263ek/at91sam9263ek.c | 8 ++--- board/atmel/sama5d3xek/sama5d3xek.c| 4 +-- board/bf518f-ezbrd/bf518f-ezbrd.c | 4 +-- board/bf526-ezbrd/bf526-ezbrd.c| 4 +-- board/bf537-stamp/bf537-stamp.c| 4 +-- board/dnp5370/dnp5370.c| 4 +-- board/freescale/bsc9132qds/bsc9132qds.c| 2 +- board/freescale/t102xqds/law.c | 2 +- board/freescale/t102xrdb/law.c | 2 +- board/freescale/t1040qds/law.c | 2 +- board/freescale/t104xrdb/law.c | 2 +- board/renesas/blanche/blanche.c| 10 +++ cmd/cramfs.c | 2 +- cmd/flash.c| 34 +++--- cmd/load.c | 4 +-- cmd/mem.c | 4 +-- common/Kconfig | 6 common/Makefile| 2 +- common/board_r.c | 4 +-- common/flash.c | 5 common/update.c| 10 +++ configs/10m50_defconfig| 1 + configs/3c120_defconfig| 1 + configs/A20-OLinuXino-Lime2_defconfig | 1 - configs/A20-Olimex-SOM-EVB_defconfig | 1 - configs/B4420QDS_NAND_defconfig| 3 +- configs/B4420QDS_SPIFLASH_defconfig| 3 +- configs/B4420QDS_defconfig | 3 +- configs/B4860QDS_NAND_defconfig| 3 +- configs/B4860QDS_SECURE_BOOT_defconfig | 1 + configs/B4860QDS_SPIFLASH_defconfig| 3 +- configs/B4860QDS_SRIO_PCIE_BOOT_defconfig | 2 +- configs/B4860QDS_defconfig | 3 +- configs/BSC9131RDB_NAND_SYSCLK100_defconfig| 2 +- configs/BSC9131RDB_NAND_defconfig | 2 +- configs/BSC9131RDB_SPIFLASH_SYSCLK100_defconfig| 2 +- configs/BSC9131RDB_SPIFLASH_defconfig | 2 +- configs/BSC9132QDS_NAND_DDRCLK100_SECURE_defconfig | 1 + configs/BSC9132QDS_NAND_DDRCLK100_defconfig| 1 + configs/BSC9132QDS_NAND_DDRCLK133_SECURE_defconfig | 1 + configs/BSC9132QDS_NAND_DDRCLK133_defconfig| 1 + configs/BSC9132QDS_NOR_DDRCLK100_SECURE_defconfig | 1 + configs/BSC9132QDS_NOR_DDRCLK100_defconfig | 1 + configs/BSC9132QDS_NOR_DDRCLK133_SECURE_defconfig | 1 + configs/BSC9132QDS_NOR_DDRCLK133_defconfig | 1 + .../BSC9132QDS_SDCARD_DDRCLK100_SECURE_defconfig | 1 + configs/BSC9132QDS_SDCARD_DDRCLK100_defconfig | 1 + .../BSC9132QDS_SDCARD_DDRCLK133_SECURE_defconfig | 1 + configs/BSC9132QDS_SDCARD_DDRCLK133_defconfig | 1 + .../BSC9132QDS_SPIFLASH_DDRCLK100_SECURE_defconfig | 1 + configs/BSC9132QDS_SPIFLASH_DDRCLK100_defconfig| 1 + .../BSC9132QDS_SPIFLASH_DDRCLK133_SECURE_defconfig | 1 + configs/BSC9132QDS_SPIFLASH_DDRCLK133_defconfig| 1 + configs/C29XPCIE_NAND_defconfig| 3 +- configs/C29XPCIE_NOR_SECBOOT_defconfig | 1 + configs/C29XPCIE_SPIFLASH_SECBOOT_defconfig| 1 + configs/C29XPCIE_SPIFLASH_defconfig| 3 +- configs/C29XPCIE_defconfig | 3 +- configs/CHIP_defconfig | 2 +- configs/CPCI2DP_defconfig | 3 +- configs/CPCI4052_defconfig | 3 +- configs/M5208EVBE_defconfig| 3 +- configs/M52277EVB_defconfig| 3 +- configs/M52277EVB_stmicro_defconfig| 3 +- configs/M5235EVB_Flash32_defconfig | 3 +- configs/M5235EVB_defconfig | 3 +- configs/M5249EVB_defconfig | 3 +- configs/M5253DEMO_defconfig| 3 +- configs/M5253EVBE_defconfig| 3 +- configs/M5272C3_defconfig | 3 +- configs/M5275EVB_defconfig | 3 +- configs/M5282EVB_defconfig | 3 +- configs/M53017EVB_defconfig| 3 +- configs/M5329AFEE_defconfig| 3 +- configs/M5329BFEE_defconfig| 3 +- configs/M5373EVB_de
[U-Boot] [PATCH] travis-ci: Add qemu-x86_64 target
Add qemu-x86_64 to the list of targets we use for test.py runs. Signed-off-by: Tom Rini --- .travis.yml | 7 +++ 1 file changed, 7 insertions(+) diff --git a/.travis.yml b/.travis.yml index 48b7b101f1c6..dab55f34e51d 100644 --- a/.travis.yml +++ b/.travis.yml @@ -311,6 +311,13 @@ matrix: TOOLCHAIN="x86_64" BUILD_ROM="yes" - env: +- TEST_PY_BD="qemu-x86_64" + TEST_PY_TEST_SPEC="not sleep" + QEMU_TARGET="x86_64-softmmu" + BUILDMAN="^qemu-x86_64$" + TOOLCHAIN="x86_64" + BUILD_ROM="yes" +- env: - TEST_PY_BD="zynq_zc702" TEST_PY_TEST_SPEC="not sleep" QEMU_TARGET="arm-softmmu" -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 4/6] sunxi: Add selective DRAM type and timing
Hi.
On 11.02.2017 16:08, Icenowy Zheng wrote:
[..]
> @@ -299,6 +190,13 @@ static void mctl_h3_zq_calibration_quirk(struct
> dram_para *para)
> {
> struct sunxi_mctl_ctl_reg * const mctl_ctl =
> (struct sunxi_mctl_ctl_reg *)SUNXI_DRAM_CTL0_BASE;
> + int zq_count;
> +
> +#if defined CONFIG_SUNXI_DRAM_DDR3
> + zq_count = 6;
This doesn't depend on DRAM type, but on how many ZQ calibration groups
exist. H3 had three: AC, DX0/1 and DX2/3. Devices with only 16bit bus
width most likely only have AC and DX0/1.
> +#else
> +#error Unsupported DRAM type!
> +#endif
>
> if ((readl(SUNXI_SRAMC_BASE + 0x24) & 0xff) == 0 &&
> (readl(SUNXI_SRAMC_BASE + 0xf0) & 0x1) == 0) {
> @@ -327,7 +225,7 @@ static void mctl_h3_zq_calibration_quirk(struct dram_para
> *para)
>
> writel(0x0a0a0a0a, &mctl_ctl->zqdr[2]);
>
> - for (i = 0; i < 6; i++) {
> + for (i = 0; i < zq_count; i++) {
I think
for (i = 0; i < (1 + (num_databyte_lanes / 2)) * 2; i++)
would be the cleanest way of handling this, with num_databyte_lanes
being chip-dependent.
But, as the name of this function already states, this is a quirk for a
bug in H3, which always has 4 databyte lanes. Are you sure other chips
need this quirk too? H5 and A64 for example work well with 'normal' ZQ
calibration.
Jens
> u8 zq = (CONFIG_DRAM_ZQ >> (i * 4)) & 0xf;
>
> writel((zq << 20) | (zq << 16) | (zq << 12) |
> @@ -349,7 +247,9 @@ static void mctl_h3_zq_calibration_quirk(struct dram_para
> *para)
>
> writel((zq_val[1] << 16) | zq_val[0], &mctl_ctl->zqdr[0]);
> writel((zq_val[3] << 16) | zq_val[2], &mctl_ctl->zqdr[1]);
> +#if defined CONFIG_SUNXI_DRAM_DDR3
> writel((zq_val[5] << 16) | zq_val[4], &mctl_ctl->zqdr[2]);
> +#endif
> }
> }
>
> @@ -358,7 +258,12 @@ static void mctl_set_cr(struct dram_para *para)
> struct sunxi_mctl_com_reg * const mctl_com =
> (struct sunxi_mctl_com_reg *)SUNXI_DRAM_COM_BASE;
>
> - writel(MCTL_CR_BL8 | MCTL_CR_2T | MCTL_CR_DDR3 | MCTL_CR_INTERLEAVED |
> + writel(MCTL_CR_BL8 | MCTL_CR_2T | MCTL_CR_INTERLEAVED |
> +#if defined CONFIG_SUNXI_DRAM_DDR3
> +MCTL_CR_DDR3 |
> +#else
> +#error Unsupported DRAM type!
> +#endif
> (para->bank_bits == 3 ? MCTL_CR_EIGHT_BANKS :
> MCTL_CR_FOUR_BANKS) |
> MCTL_CR_BUS_FULL_WIDTH(para->bus_full_width) |
> (para->dual_rank ? MCTL_CR_DUAL_RANK : MCTL_CR_SINGLE_RANK) |
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 2/6] sunxi: Rename bus-width related macros in H3 DRAM code
Hi,
renaming is not quite enough, see the comments below.
On 11.02.2017 16:08, Icenowy Zheng wrote:
> The DesignWare DRAM controller used by H3 and newer SoCs use a bit to
> identify whether the DRAM is half-width.
>
> As H3 itself come with 32-bit DRAM, the two modes of the bit used to be
> named "MCTL_CR_32BIT" and "MCTL_CR_16BIT", but for SoCs with 16-bit DRAM
> they're really 8-bit and 16-bit.
>
> Rename the bit's macro, and also rename the variable name in
> dram_sun8i_h3.c.
>
> Signed-off-by: Icenowy Zheng
> ---
> arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h | 6 +++---
> arch/arm/mach-sunxi/dram_sunxi_dw.c | 11 ++-
> 2 files changed, 9 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h
> b/arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h
> index 25d07d9863..48bd6f7c0f 100644
> --- a/arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h
> +++ b/arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h
> @@ -52,9 +52,9 @@ struct sunxi_mctl_com_reg {
> #define MCTL_CR_SEQUENTIAL (0x1 << 15)
> #define MCTL_CR_INTERLEAVED (0x0 << 15)
>
> -#define MCTL_CR_32BIT(0x1 << 12)
> -#define MCTL_CR_16BIT(0x0 << 12)
> -#define MCTL_CR_BUS_WIDTH(x) ((x) == 32 ? MCTL_CR_32BIT : MCTL_CR_16BIT)
> +#define MCTL_CR_FULL_WIDTH (0x1 << 12)
> +#define MCTL_CR_HALF_WIDTH (0x0 << 12)
> +#define MCTL_CR_BUS_FULL_WIDTH(x)((x) << 12)
>
> #define MCTL_CR_PAGE_SIZE(x) ((fls(x) - 4) << 8)
> #define MCTL_CR_ROW_BITS(x) (((x) - 1) << 4)
> diff --git a/arch/arm/mach-sunxi/dram_sunxi_dw.c
> b/arch/arm/mach-sunxi/dram_sunxi_dw.c
> index 9f7cc7fd4c..0c73a43075 100644
> --- a/arch/arm/mach-sunxi/dram_sunxi_dw.c
> +++ b/arch/arm/mach-sunxi/dram_sunxi_dw.c
> @@ -28,7 +28,7 @@
> #define LINES_PER_BYTE_LANE (BITS_PER_BYTE + 3)
> struct dram_para {
> u16 page_size;
> - u8 bus_width;
> + u8 bus_full_width;
> u8 dual_rank;
> u8 row_bits;
> const u8 dx_read_delays[NR_OF_BYTE_LANES][LINES_PER_BYTE_LANE];
> @@ -358,7 +358,8 @@ static void mctl_set_cr(struct dram_para *para)
> (struct sunxi_mctl_com_reg *)SUNXI_DRAM_COM_BASE;
>
> writel(MCTL_CR_BL8 | MCTL_CR_2T | MCTL_CR_DDR3 | MCTL_CR_INTERLEAVED |
> -MCTL_CR_EIGHT_BANKS | MCTL_CR_BUS_WIDTH(para->bus_width) |
> +MCTL_CR_EIGHT_BANKS |
> +MCTL_CR_BUS_FULL_WIDTH(para->bus_full_width) |
> (para->dual_rank ? MCTL_CR_DUAL_RANK : MCTL_CR_SINGLE_RANK) |
> MCTL_CR_PAGE_SIZE(para->page_size) |
> MCTL_CR_ROW_BITS(para->row_bits), &mctl_com->cr);
> @@ -471,7 +472,7 @@ static int mctl_channel_init(uint16_t socid, struct
> dram_para *para)
> }
>
> /* set half DQ */
> - if (para->bus_width != 32) {
> + if (!para->bus_full_width) {
> writel(0x0, &mctl_ctl->dx[2].gcr);
> writel(0x0, &mctl_ctl->dx[3].gcr);
This is not correct, it still disables byte 2 and 3, which don't even
exist on 16bit bus devices. On a 16bit device dx[1] would have do be
disabled for half width.
> }
> @@ -509,7 +510,7 @@ static int mctl_channel_init(uint16_t socid, struct
> dram_para *para)
> ((readl(&mctl_ctl->dx[3].gsr[0]) >> 24) & 0x1)) {
> writel(0x0, &mctl_ctl->dx[2].gcr);
> writel(0x0, &mctl_ctl->dx[3].gcr);
> - para->bus_width = 16;
> + para->bus_full_width = 0;
Same here, it only detects that byte 2 and 3 are missing, to detect half
width on 16bit devices byte 1 would have to be checked in the if above.
Also, the rank detection above must not check byte 1 on 16bit devices.
> }
>
> mctl_set_cr(para);
> @@ -613,7 +614,7 @@ unsigned long sunxi_dram_init(void)
>
> struct dram_para para = {
> .dual_rank = 0,
> - .bus_width = 32,
> + .bus_full_width = 1,
> .row_bits = 15,
> .page_size = 4096,
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] test/py: Create tests for ext4 and fat testing on sandbox
On Donnerstag, 5. Januar 2017 17:15:02 CET you wrote:
> On 01/01/2017 02:48 PM, Stefan Bruens wrote:
> > On Montag, 12. Dezember 2016 11:04:34 CET you wrote:
> >> On 12/04/2016 05:52 PM, Stefan Brüns wrote:
> >>> From: Stefan Brüns
> >>>
> >>> The following checks are currently implemented:
> >>> 1. listing a directory
> >>> 2. verifying size of a file
> >>> 3. veryfying md5sum for a file region
> >>> 4. reading the beginning of a file
> >>
> >> 2) Doesn't mounting/unmounting require root? Nothing else in test/py
> >> does. It'd be useful to put a comment at the top of the file detailing
> >> which command one might want to add to /etc/sudoers to avoid having to
> >> run the whole thing as root, and use sudo within the test where
> >> necessary.
> >
> > It already uses sudo, the run command is visible from the log. Currently,
> > I
> > just run "sudo true" prior to executing the test, the password is cached
> > for 5 minutes.
>
> I don't see sudo used anywhere in test/py; can you point out where you
> see it using sudo at present?
it == the fs test
> >>> +class FsImage:
> >> ...
> >>
> >>> +def mount(self, log):
> >>> +if not os.path.exists(self.mountpath):
> >>> +os.mkdir(self.mountpath)
> >>
> >> Use os.makedirs(path) instead; you can avoid the if statement, and it'll
> >> handle parent directories too.
> >
> > exist_ok only exists in python >= 3.2.
>
> There's no need to use exist_ok; do this (example from conftest.py):
>
> try:
> os.makedirs(path)
> except OSError as exc:
> if exc.errno == errno.EEXIST and os.path.isdir(path):
> pass
> else:
> raise
Thats not what you wrote. You said "you can avoid the if statement". What you
meant is "you can replace the single line if statement with a 6 line exception
handling statement". The latter is *only* better iff you have to handle
concurrent creation of the wanted directory.
> >>> +@pytest.fixture(scope='module', params=['fat', 'ext4'])
> >>> +def fsimage(prereq_commands, u_boot_config, u_boot_log, request):
> >>> +"""Filesystem image instance."""
> >>> +datadir = u_boot_config.result_dir + '/'
> >>
> >> Wouldn't it be better to put this into
> >> u_boot_config.persistent_data_dir, plus avoid creating the image file if
> >> it already exists? See u_boot_utils.py's PersistentRandomFile() as an
> >> example. I wonder if that could be expanded to create files not just of
> >> size n, but with sparse layout specs like this test uses?
> >
> > See above. I don't think PersistentRandomFile() does fit here, as the
> > files
> > are created *inside* an image. Maybe it could be used after the image and
> > filesystem is created and mounted ...
>
> You missed my point. PersistentRandomFile() is existing code that
> creates a persistent data file. You can create a new function/... that
> uses the same techniques to create the data file, but make it create a
> filesystem image rather than random data.
The disk image is a fixture, so it should be created as a fixture. The usage
of PersistentRandomFile as currently done is wrong, it is a prerequisite of
the test, not part of the test itself.
The correct use of PersistentRandomFile might be as a helper function used by
different fixtures.
1. persistent_data_dir may be the better choice, but only if the image is
created as a template there and then copied to a different location for each
test run - the idea is to modify the image by write tests, and a clean image
is needed here. Feel free to implement this yourself.
2. PersistentRandomFile creates single files, the only parameter is the size
(although extending it to sparse files is quite possible). Disk images with
filesystems have a lot more parameters - filesystem itself, filesystem
options, filesystem contents.
Actually you missed my point here - PersistentRandomFile() is existing code,
but it is useless here. Shoehorning it in here or extending it until it suits
is a bad idea. It does one thing, and it does it fine. Creation of disk images
is a different thing it does and should not do.
> >>> +fstype = request.param
> >>> +imagepath = datadir + '3GB.' + fstype + '.img'
> >>> +mountpath = datadir + 'mnt_' + fstype
> >>> +
> >>> +with u_boot_log.section('Create image "{0}"'.format(imagepath)):
> >>> +fsimage = FsImage(fstype, imagepath, mountpath)
> >>> +fsimage.mkfs(u_boot_log)
> >>> +
> >>> +yield fsimage
> >>> +fsimage.unmount(u_boot_log)
> >>
> >> Unmounting seems to happen in a lot of different places. Can we isolate
> >> it to just one place?
> >
> > The image is mounted/unmounted for two different reasons -
> > creating/populating the image, and when accessing it using the hostfs
> > commands.
>
> IIRC, there's more duplication than that, but I'll look again when this
> is reposted.
>
> >> Also, what happens if the code throws an exception after obtaining an
> >> fsimage from this generat
Re: [U-Boot] [PATCH v2 02/10] clk: stm32f7: add clock driver for stm32f7 family
On 10 February 2017 at 16:11, Vikas Manocha wrote: > add basic clock driver support for stm32f7 to enable clocks required by > the peripherals. > > Signed-off-by: Vikas Manocha > --- > > Changed in v2: > - added blank lines in code like before return and after > variable declaration. > - re-arranged header file inclusion as per u-boot guidelines. > - remove not used function. > > arch/arm/mach-stm32/stm32f7/Makefile | 2 +- > arch/arm/mach-stm32/stm32f7/soc.c | 2 - > configs/stm32f746-disco_defconfig | 1 + > doc/device-tree-bindings/clock/st,stm32-rcc.txt| 95 > ++ > drivers/clk/Makefile | 2 +- > .../stm32f7/clock.c => drivers/clk/clk_stm32f7.c | 61 +- > 6 files changed, 157 insertions(+), 6 deletions(-) > create mode 100644 doc/device-tree-bindings/clock/st,stm32-rcc.txt > rename arch/arm/mach-stm32/stm32f7/clock.c => drivers/clk/clk_stm32f7.c (86%) Adding this back: Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 06/10] PINCTRL: stm32f7: add pin control driver
On 10 February 2017 at 16:11, Vikas Manocha wrote:
> This driver uses the same pin control binding as that of linux, binding
> document of this patch is copied from linux. One addition done is for
> GPIO input and output mode configuration which was missing.
>
> Signed-off-by: Vikas Manocha
Reviewed-by: Simon Glass
(if you add that to the patch I don't need to remember whether I reviewed
it or not)
> ---
>
> Changed in v2:
> - added blank lines in code like before return and after
> variable declaration.
> - remove not used function.
> - changed fixed length array read from DT node to relaxed length
read.
>
>
> configs/stm32f746-disco_defconfig | 3 +
> .../pinctrl/st,stm32-pinctrl.txt | 133
+
> drivers/pinctrl/Kconfig| 9 ++
> drivers/pinctrl/Makefile | 1 +
> drivers/pinctrl/pinctrl_stm32.c| 121
+++
> 5 files changed, 267 insertions(+)
> create mode 100644 doc/device-tree-bindings/pinctrl/st,stm32-pinctrl.txt
> create mode 100644 drivers/pinctrl/pinctrl_stm32.c
>
[...]
> +static int stm32_pinctrl_set_state_simple(struct udevice *dev,
> + struct udevice *periph)
> +{
> + u32 pin_mux[50];
> + struct fdtdec_phandle_args args;
> + int rv, len;
> +
> + /* Get node pinctrl-0 */
> + rv = fdtdec_parse_phandle_with_args(gd->fdt_blob,
periph->of_offset,
> + "pinctrl-0", 0, 0, 0, &args);
> + if (rv)
> + return rv;
> + /*
> +* check for "pinmux" property in each subnode (e.g. pins1 and
pins2 for
> +* usart1) of pin controller phandle "pinctrl-0"
> +* */
> + fdt_for_each_subnode(args.node, gd->fdt_blob, args.node) {
> + struct stm32_gpio_dsc gpio_dsc;
> + struct stm32_gpio_ctl gpio_ctl;
> + int i;
> +
> + /*
> +* just to get the length of "pinmux" to allocate correct
size
> +* or memory
> +* */
> + fdt_get_property(gd->fdt_blob, args.node, "pinmux", &len);
> + len /= 4;
> + debug("%s: no of pinmux entries= %d\n", __func__, len);
> + len = fdtdec_get_int_array_count(gd->fdt_blob, args.node,
> +"pinmux", pin_mux, len);
Just to be clear, instead of those 5 lines, you should be able to do:
len = fdtdec_get_int_array_count(gd->fdt_blob, args.node,
"pinmux", pin_mux,
ARRAY_SIZE(pin_mux));
> + if (len < 0)
> + return -EINVAL;
[..]
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 06/10] PINCTRL: stm32f7: add pin control driver
Hi Vikas,
On 10 February 2017 at 14:39, vikas wrote:
> Hi Simon,
>
> On 02/10/2017 08:22 AM, Simon Glass wrote:
>> Hi Vikas,
>>
>> On 4 February 2017 at 15:43, Vikas Manocha wrote:
>>> This driver uses the same pin control binding as that of linux, binding
>>> document of this patch is copied from linux. One addition done is for
>>> GPIO input and output mode configuration which was missing.
>>>
>>> Signed-off-by: Vikas Manocha
>>> ---
>>> configs/stm32f746-disco_defconfig | 3 +
>>> .../pinctrl/st,stm32-pinctrl.txt | 133
>>> +
>>> drivers/pinctrl/Kconfig| 9 ++
>>> drivers/pinctrl/Makefile | 1 +
>>> drivers/pinctrl/pinctrl_stm32.c| 118 ++
>>> 5 files changed, 264 insertions(+)
>>> create mode 100644 doc/device-tree-bindings/pinctrl/st,stm32-pinctrl.txt
>>> create mode 100644 drivers/pinctrl/pinctrl_stm32.c
>>
>> Reviewed-by: Simon Glass
>>
>> nits below
>>
[..]
>>
>>> + fdt_get_property(gd->fdt_blob, args.node, "pinmux", &len);
>>> + len /= 4;
>>> + debug("%s: no of pinmux entries= %d\n", __func__, len);
>>> + rv = fdtdec_get_int_array(gd->fdt_blob, args.node,
>>> +"pinmux", pin_mux, len);
>>
>> Can you use fdtdec_get_int_array_count() ?
>
> Yes but it's almost same, the only difference being xxx_array_count is
> relaxed on lenght/count.
> And in this case we are reading length of the property just before.
>
> In any case, i will change it to xxx_array_count in v2.
Yes your code works. I'm only suggesting the change because, in a way,
fdt_get_property() is quite a low-level function. You can do what you
want with an fdtdec function and thus avoid using libfdt directly.
[...]
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 03/10] stm32f7: serial: use clock driver to enable clock
On 10 February 2017 at 16:11, Vikas Manocha wrote: > Signed-off-by: Vikas Manocha > --- > > Changed in v2: > - added blank lines in code like before return and after > variable declaration. > > drivers/serial/serial_stm32x7.c | 18 ++ > 1 file changed, 18 insertions(+) > Adding this back: Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-rockchip
On Thu, Feb 09, 2017 at 09:20:56PM -0700, Simon Glass wrote: > Hi Tom, > > This includes a board rename and a few other minor changes. > > > The following changes since commit 21342d4aed6c77a4aa7a5b2579b3c23e21aea31a: > > Merge git://git.denx.de/u-boot-dm (2017-02-08 16:24:44 -0500) > > are available in the git repository at: > > git://git.denx.de/u-boot-rockchip.git > > for you to fetch changes up to 6f2797645562e85c407aab3e9a757bfd61a027fe: > > rockchip: rename miniarm to tinker board (2017-02-09 12:10:59 -0700) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] please pull u-boot-samsung master
On Sat, Feb 11, 2017 at 10:41:45PM +0900, Minkyu Kang wrote: > Dear Tom, > > > The following changes since commit f1cc97764be4383d2aeb56d5ba5415439a1d5c97: > > > Merge branch 'master' of git://git.denx.de/u-boot-video (2017-02-09 > 14:54:09 -0500) > > > are available in the git repository at: > > > > git://git.denx.de/u-boot-samsung.git master > > > for you to fetch changes up to 5d3be0f81ca7668ac04ee0f0b7d82e123c7f59b5: > > > exynos: Drop large alignment for SDRAM parameters (2017-02-10 18:51:51 > +0900) > > 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] [linux-sunxi] Re: [RFC PATCH 4/6] sunxi: Add selective DRAM type and timing
2017年2月12日 00:59于 Jens Kuske 写道：
>
> Hi.
>
> On 11.02.2017 16:08, Icenowy Zheng wrote:
> [..]
> > @@ -299,6 +190,13 @@ static void mctl_h3_zq_calibration_quirk(struct
> > dram_para *para)
> > {
> > struct sunxi_mctl_ctl_reg * const mctl_ctl =
> > (struct sunxi_mctl_ctl_reg *)SUNXI_DRAM_CTL0_BASE;
> > + int zq_count;
> > +
> > +#if defined CONFIG_SUNXI_DRAM_DDR3
> > + zq_count = 6;
>
> This doesn't depend on DRAM type, but on how many ZQ calibration groups
> exist. H3 had three: AC, DX0/1 and DX2/3. Devices with only 16bit bus
> width most likely only have AC and DX0/1.
>
> > +#else
> > +#error Unsupported DRAM type!
> > +#endif
> >
> > if ((readl(SUNXI_SRAMC_BASE + 0x24) & 0xff) == 0 &&
> > (readl(SUNXI_SRAMC_BASE + 0xf0) & 0x1) == 0) {
> > @@ -327,7 +225,7 @@ static void mctl_h3_zq_calibration_quirk(struct
> > dram_para *para)
> >
> > writel(0x0a0a0a0a, &mctl_ctl->zqdr[2]);
> >
> > - for (i = 0; i < 6; i++) {
> > + for (i = 0; i < zq_count; i++) {
>
> I think
> for (i = 0; i < (1 + (num_databyte_lanes / 2)) * 2; i++)
> would be the cleanest way of handling this, with num_databyte_lanes
> being chip-dependent.
>
> But, as the name of this function already states, this is a quirk for a
> bug in H3, which always has 4 databyte lanes. Are you sure other chips
> need this quirk too? H5 and A64 for example work well with 'normal' ZQ
> calibration.
This is for H3 and V3s (1680 and 1681).
>
> Jens
>
> > u8 zq = (CONFIG_DRAM_ZQ >> (i * 4)) & 0xf;
> >
> > writel((zq << 20) | (zq << 16) | (zq << 12) |
> > @@ -349,7 +247,9 @@ static void mctl_h3_zq_calibration_quirk(struct
> > dram_para *para)
> >
> > writel((zq_val[1] << 16) | zq_val[0], &mctl_ctl->zqdr[0]);
> > writel((zq_val[3] << 16) | zq_val[2], &mctl_ctl->zqdr[1]);
> > +#if defined CONFIG_SUNXI_DRAM_DDR3
> > writel((zq_val[5] << 16) | zq_val[4], &mctl_ctl->zqdr[2]);
> > +#endif
> > }
> > }
> >
> > @@ -358,7 +258,12 @@ static void mctl_set_cr(struct dram_para *para)
> > struct sunxi_mctl_com_reg * const mctl_com =
> > (struct sunxi_mctl_com_reg *)SUNXI_DRAM_COM_BASE;
> >
> > - writel(MCTL_CR_BL8 | MCTL_CR_2T | MCTL_CR_DDR3 | MCTL_CR_INTERLEAVED |
> > + writel(MCTL_CR_BL8 | MCTL_CR_2T | MCTL_CR_INTERLEAVED |
> > +#if defined CONFIG_SUNXI_DRAM_DDR3
> > + MCTL_CR_DDR3 |
> > +#else
> > +#error Unsupported DRAM type!
> > +#endif
> > (para->bank_bits == 3 ? MCTL_CR_EIGHT_BANKS : MCTL_CR_FOUR_BANKS) |
> > MCTL_CR_BUS_FULL_WIDTH(para->bus_full_width) |
> > (para->dual_rank ? MCTL_CR_DUAL_RANK : MCTL_CR_SINGLE_RANK) |
>
> --
> You received this message because you are subscribed to the Google Groups
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] Re: [RFC PATCH 4/6] sunxi: Add selective DRAM type and timing
12.02.2017, 01:00, "Jens Kuske" :
> Hi.
>
> On 11.02.2017 16:08, Icenowy Zheng wrote:
> [..]
>> @@ -299,6 +190,13 @@ static void mctl_h3_zq_calibration_quirk(struct
>> dram_para *para)
>> {
>> struct sunxi_mctl_ctl_reg * const mctl_ctl =
>> (struct sunxi_mctl_ctl_reg *)SUNXI_DRAM_CTL0_BASE;
>> + int zq_count;
>> +
>> +#if defined CONFIG_SUNXI_DRAM_DDR3
>> + zq_count = 6;
>
> This doesn't depend on DRAM type, but on how many ZQ calibration groups
> exist. H3 had three: AC, DX0/1 and DX2/3. Devices with only 16bit bus
> width most likely only have AC and DX0/1.
Is ZQ even present on DDR2? What I read is that ZQ is a new feature introduced
in DDR3...
>
>> +#else
>> +#error Unsupported DRAM type!
>> +#endif
>>
>> if ((readl(SUNXI_SRAMC_BASE + 0x24) & 0xff) == 0 &&
>> (readl(SUNXI_SRAMC_BASE + 0xf0) & 0x1) == 0) {
>> @@ -327,7 +225,7 @@ static void mctl_h3_zq_calibration_quirk(struct
>> dram_para *para)
>>
>> writel(0x0a0a0a0a, &mctl_ctl->zqdr[2]);
>>
>> - for (i = 0; i < 6; i++) {
>> + for (i = 0; i < zq_count; i++) {
>
> I think
> for (i = 0; i < (1 + (num_databyte_lanes / 2)) * 2; i++)
> would be the cleanest way of handling this, with num_databyte_lanes
> being chip-dependent.
>
> But, as the name of this function already states, this is a quirk for a
> bug in H3, which always has 4 databyte lanes. Are you sure other chips
> need this quirk too? H5 and A64 for example work well with 'normal' ZQ
> calibration.
>
> Jens
>
>> u8 zq = (CONFIG_DRAM_ZQ >> (i * 4)) & 0xf;
>>
>> writel((zq << 20) | (zq << 16) | (zq << 12) |
>> @@ -349,7 +247,9 @@ static void mctl_h3_zq_calibration_quirk(struct
>> dram_para *para)
>>
>> writel((zq_val[1] << 16) | zq_val[0], &mctl_ctl->zqdr[0]);
>> writel((zq_val[3] << 16) | zq_val[2], &mctl_ctl->zqdr[1]);
>> +#if defined CONFIG_SUNXI_DRAM_DDR3
>> writel((zq_val[5] << 16) | zq_val[4], &mctl_ctl->zqdr[2]);
>> +#endif
>> }
>> }
>>
>> @@ -358,7 +258,12 @@ static void mctl_set_cr(struct dram_para *para)
>> struct sunxi_mctl_com_reg * const mctl_com =
>> (struct sunxi_mctl_com_reg *)SUNXI_DRAM_COM_BASE;
>>
>> - writel(MCTL_CR_BL8 | MCTL_CR_2T | MCTL_CR_DDR3 | MCTL_CR_INTERLEAVED |
>> + writel(MCTL_CR_BL8 | MCTL_CR_2T | MCTL_CR_INTERLEAVED |
>> +#if defined CONFIG_SUNXI_DRAM_DDR3
>> + MCTL_CR_DDR3 |
>> +#else
>> +#error Unsupported DRAM type!
>> +#endif
>> (para->bank_bits == 3 ? MCTL_CR_EIGHT_BANKS :
>> MCTL_CR_FOUR_BANKS) |
>> MCTL_CR_BUS_FULL_WIDTH(para->bus_full_width) |
>> (para->dual_rank ? MCTL_CR_DUAL_RANK : MCTL_CR_SINGLE_RANK)
>> |
>
> --
> You received this message because you are subscribed to the Google Groups
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] Re: [RFC PATCH 2/6] sunxi: Rename bus-width related macros in H3 DRAM code
12.02.2017, 01:00, "Jens Kuske" :
> Hi,
>
> renaming is not quite enough, see the comments below.
>
> On 11.02.2017 16:08, Icenowy Zheng wrote:
>> The DesignWare DRAM controller used by H3 and newer SoCs use a bit to
>> identify whether the DRAM is half-width.
>>
>> As H3 itself come with 32-bit DRAM, the two modes of the bit used to be
>> named "MCTL_CR_32BIT" and "MCTL_CR_16BIT", but for SoCs with 16-bit DRAM
>> they're really 8-bit and 16-bit.
>>
>> Rename the bit's macro, and also rename the variable name in
>> dram_sun8i_h3.c.
>>
>> Signed-off-by: Icenowy Zheng
>> ---
>> arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h | 6 +++---
>> arch/arm/mach-sunxi/dram_sunxi_dw.c | 11 ++-
>> 2 files changed, 9 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h
>> b/arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h
>> index 25d07d9863..48bd6f7c0f 100644
>> --- a/arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h
>> +++ b/arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h
>> @@ -52,9 +52,9 @@ struct sunxi_mctl_com_reg {
>> #define MCTL_CR_SEQUENTIAL (0x1 << 15)
>> #define MCTL_CR_INTERLEAVED (0x0 << 15)
>>
>> -#define MCTL_CR_32BIT (0x1 << 12)
>> -#define MCTL_CR_16BIT (0x0 << 12)
>> -#define MCTL_CR_BUS_WIDTH(x) ((x) == 32 ? MCTL_CR_32BIT : MCTL_CR_16BIT)
>> +#define MCTL_CR_FULL_WIDTH (0x1 << 12)
>> +#define MCTL_CR_HALF_WIDTH (0x0 << 12)
>> +#define MCTL_CR_BUS_FULL_WIDTH(x) ((x) << 12)
>>
>> #define MCTL_CR_PAGE_SIZE(x) ((fls(x) - 4) << 8)
>> #define MCTL_CR_ROW_BITS(x) (((x) - 1) << 4)
>> diff --git a/arch/arm/mach-sunxi/dram_sunxi_dw.c
>> b/arch/arm/mach-sunxi/dram_sunxi_dw.c
>> index 9f7cc7fd4c..0c73a43075 100644
>> --- a/arch/arm/mach-sunxi/dram_sunxi_dw.c
>> +++ b/arch/arm/mach-sunxi/dram_sunxi_dw.c
>> @@ -28,7 +28,7 @@
>> #define LINES_PER_BYTE_LANE (BITS_PER_BYTE + 3)
>> struct dram_para {
>> u16 page_size;
>> - u8 bus_width;
>> + u8 bus_full_width;
>> u8 dual_rank;
>> u8 row_bits;
>> const u8 dx_read_delays[NR_OF_BYTE_LANES][LINES_PER_BYTE_LANE];
>> @@ -358,7 +358,8 @@ static void mctl_set_cr(struct dram_para *para)
>> (struct sunxi_mctl_com_reg *)SUNXI_DRAM_COM_BASE;
>>
>> writel(MCTL_CR_BL8 | MCTL_CR_2T | MCTL_CR_DDR3 |
>> MCTL_CR_INTERLEAVED |
>> - MCTL_CR_EIGHT_BANKS | MCTL_CR_BUS_WIDTH(para->bus_width) |
>> + MCTL_CR_EIGHT_BANKS |
>> + MCTL_CR_BUS_FULL_WIDTH(para->bus_full_width) |
>> (para->dual_rank ? MCTL_CR_DUAL_RANK : MCTL_CR_SINGLE_RANK)
>> |
>> MCTL_CR_PAGE_SIZE(para->page_size) |
>> MCTL_CR_ROW_BITS(para->row_bits), &mctl_com->cr);
>> @@ -471,7 +472,7 @@ static int mctl_channel_init(uint16_t socid, struct
>> dram_para *para)
>> }
>>
>> /* set half DQ */
>> - if (para->bus_width != 32) {
>> + if (!para->bus_full_width) {
>> writel(0x0, &mctl_ctl->dx[2].gcr);
>> writel(0x0, &mctl_ctl->dx[3].gcr);
>
> This is not correct, it still disables byte 2 and 3, which don't even
> exist on 16bit bus devices. On a 16bit device dx[1] would have do be
> disabled for half width.
Yes, verified on dram_sun8i_a33.c .
>
>> }
>> @@ -509,7 +510,7 @@ static int mctl_channel_init(uint16_t socid, struct
>> dram_para *para)
>> ((readl(&mctl_ctl->dx[3].gsr[0]) >> 24) & 0x1)) {
>> writel(0x0, &mctl_ctl->dx[2].gcr);
>> writel(0x0, &mctl_ctl->dx[3].gcr);
>> - para->bus_width = 16;
>> + para->bus_full_width = 0;
>
> Same here, it only detects that byte 2 and 3 are missing, to detect half
> width on 16bit devices byte 1 would have to be checked in the if above.
> Also, the rank detection above must not check byte 1 on 16bit devices.
>
>> }
>>
>> mctl_set_cr(para);
>> @@ -613,7 +614,7 @@ unsigned long sunxi_dram_init(void)
>>
>> struct dram_para para = {
>> .dual_rank = 0,
>> - .bus_width = 32,
>> + .bus_full_width = 1,
>> .row_bits = 15,
>> .page_size = 4096,
>
> --
> You received this message because you are subscribed to the Google Groups
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
