[U-Boot] [PATCH 1/5] sun6i: Make dram clk and zq value Kconfig options
It turns out that there is a too large spread between boards to handle this with a default value, turn this into Kconfig options, and set the values the factory images are using for the Colombus and Mele_M9 boards.
Signed-off-by: Hans de Goede hdegoede@redhat.com --- arch/arm/cpu/armv7/sunxi/dram_sun6i.c | 12 +++++------- board/sunxi/Kconfig | 17 +++++++++++++++++ configs/Colombus_defconfig | 2 ++ configs/Mele_M9_defconfig | 2 ++ 4 files changed, 26 insertions(+), 7 deletions(-)
diff --git a/arch/arm/cpu/armv7/sunxi/dram_sun6i.c b/arch/arm/cpu/armv7/sunxi/dram_sun6i.c index 10a6241..30439dc 100644 --- a/arch/arm/cpu/armv7/sunxi/dram_sun6i.c +++ b/arch/arm/cpu/armv7/sunxi/dram_sun6i.c @@ -17,9 +17,7 @@ #include <asm/arch/dram.h> #include <asm/arch/prcm.h>
-/* DRAM clk & zq defaults, maybe turn these into Kconfig options ? */ -#define DRAM_CLK_DEFAULT 312000000 -#define DRAM_ZQ_DEFAULT 0x78 +#define DRAM_CLK (CONFIG_DRAM_CLK * 1000000)
struct dram_sun6i_para { u8 bus_width; @@ -48,7 +46,7 @@ static void mctl_sys_init(void) (struct sunxi_ccm_reg *)SUNXI_CCM_BASE; const int dram_clk_div = 2;
- clock_set_pll5(DRAM_CLK_DEFAULT * dram_clk_div); + clock_set_pll5(DRAM_CLK * dram_clk_div);
clrsetbits_le32(&ccm->dram_clk_cfg, CCM_DRAMCLK_CFG_DIV0_MASK, CCM_DRAMCLK_CFG_DIV0(dram_clk_div) | CCM_DRAMCLK_CFG_RST | @@ -173,7 +171,7 @@ static void mctl_channel_init(int ch_index, struct dram_sun6i_para *para)
await_completion(&mctl_phy->pgsr, 0x03, 0x03);
- writel(DRAM_ZQ_DEFAULT, &mctl_phy->zq0cr1); + writel(CONFIG_DRAM_ZQ, &mctl_phy->zq0cr1);
setbits_le32(&mctl_phy->pir, MCTL_PIR_CLEAR_STATUS); writel(MCTL_PIR_STEP1, &mctl_phy->pir); @@ -219,9 +217,9 @@ static void mctl_channel_init(int ch_index, struct dram_sun6i_para *para) await_completion(&mctl_ctl->sstat, 0x07, 0x01);
/* Set number of clks per micro-second */ - writel(DRAM_CLK_DEFAULT / 1000000, &mctl_ctl->togcnt1u); + writel(DRAM_CLK / 1000000, &mctl_ctl->togcnt1u); /* Set number of clks per 100 nano-seconds */ - writel(DRAM_CLK_DEFAULT / 10000000, &mctl_ctl->togcnt100n); + writel(DRAM_CLK / 10000000, &mctl_ctl->togcnt100n); /* Set memory timing registers */ writel(MCTL_TREFI, &mctl_ctl->trefi); writel(MCTL_TMRD, &mctl_ctl->tmrd); diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig index 246cd9a..352f04e 100644 --- a/board/sunxi/Kconfig +++ b/board/sunxi/Kconfig @@ -32,6 +32,23 @@ config MACH_SUN8I
endchoice
+if MACH_SUN6I + +config DRAM_CLK + int "sun6i dram clock speed" if EXPERT + default 312 + ---help--- + Set the dram clock speed, valid range 240 - 480, must be a multiple + of 24. + +config DRAM_ZQ + int "sun6i dram zq value" if EXPERT + default 123 + ---help--- + Set the dram zq value. + +endif + config SYS_CONFIG_NAME string default "sun4i" if MACH_SUN4I diff --git a/configs/Colombus_defconfig b/configs/Colombus_defconfig index bef568d..5e245a3 100644 --- a/configs/Colombus_defconfig +++ b/configs/Colombus_defconfig @@ -4,3 +4,5 @@ CONFIG_FDTFILE="sun6i-a31-colombus.dtb" +S:CONFIG_ARCH_SUNXI=y +S:CONFIG_MACH_SUN6I=y +S:CONFIG_TARGET_COLOMBUS=y ++S:CONFIG_DRAM_CLK=288 ++S:CONFIG_DRAM_ZQ=379 diff --git a/configs/Mele_M9_defconfig b/configs/Mele_M9_defconfig index f46439f..7e50888 100644 --- a/configs/Mele_M9_defconfig +++ b/configs/Mele_M9_defconfig @@ -5,6 +5,8 @@ CONFIG_FDTFILE="sun6i-a31-m9.dtb" +S:CONFIG_ARCH_SUNXI=y +S:CONFIG_MACH_SUN6I=y +S:CONFIG_TARGET_MELE_M9=y ++S:CONFIG_DRAM_CLK=312 ++S:CONFIG_DRAM_ZQ=120 # Ethernet phy power +S:CONFIG_AXP221_DLDO1_VOLT=3300 # USB hub power
Add a sunxi_get_ss_bonding_id() function, and use it to differentiate between the A31s and the A31.
Signed-off-by: Hans de Goede hdegoede@redhat.com --- arch/arm/cpu/armv7/sunxi/cpu_info.c | 38 ++++++++++++++++++++++++++- arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 4 ++- arch/arm/include/asm/arch-sunxi/cpu.h | 5 ++++ 3 files changed, 45 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/armv7/sunxi/cpu_info.c b/arch/arm/cpu/armv7/sunxi/cpu_info.c index 41b9add..5146dc4 100644 --- a/arch/arm/cpu/armv7/sunxi/cpu_info.c +++ b/arch/arm/cpu/armv7/sunxi/cpu_info.c @@ -9,6 +9,32 @@ #include <common.h> #include <asm/io.h> #include <asm/arch/cpu.h> +#include <asm/arch/clock.h> + +#ifdef CONFIG_MACH_SUN6I +int sunxi_get_ss_bonding_id(void) +{ + struct sunxi_ccm_reg * const ccm = + (struct sunxi_ccm_reg *)SUNXI_CCM_BASE; + static int bonding_id = -1; + + if (bonding_id != -1) + return bonding_id; + + /* Enable Security System */ + setbits_le32(&ccm->ahb_reset0_cfg, 1 << AHB_RESET_OFFSET_SS); + setbits_le32(&ccm->ahb_gate0, 1 << AHB_GATE_OFFSET_SS); + + bonding_id = readl(SUNXI_SS_BASE); + bonding_id = (bonding_id >> 16) & 0x7; + + /* Disable Security System again */ + clrbits_le32(&ccm->ahb_gate0, 1 << AHB_GATE_OFFSET_SS); + clrbits_le32(&ccm->ahb_reset0_cfg, 1 << AHB_RESET_OFFSET_SS); + + return bonding_id; +} +#endif
#ifdef CONFIG_DISPLAY_CPUINFO int print_cpuinfo(void) @@ -24,7 +50,17 @@ int print_cpuinfo(void) default: puts("CPU: Allwinner A1X (SUN5I)\n"); } #elif defined CONFIG_MACH_SUN6I - puts("CPU: Allwinner A31 (SUN6I)\n"); + switch (sunxi_get_ss_bonding_id()) { + case SUNXI_SS_BOND_ID_A31: + puts("CPU: Allwinner A31 (SUN6I)\n"); + break; + case SUNXI_SS_BOND_ID_A31S: + puts("CPU: Allwinner A31s (SUN6I)\n"); + break; + default: + printf("CPU: Allwinner A31? (SUN6I, id: %d)\n", + sunxi_get_ss_bonding_id()); + } #elif defined CONFIG_MACH_SUN7I puts("CPU: Allwinner A20 (SUN7I)\n"); #elif defined CONFIG_MACH_SUN8I diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h index 50a4b69..7e810bb 100644 --- a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h +++ b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h @@ -209,6 +209,7 @@ struct sunxi_ccm_reg { #define AHB_GATE_OFFSET_MMC1 9 #define AHB_GATE_OFFSET_MMC0 8 #define AHB_GATE_OFFSET_MMC(n) (AHB_GATE_OFFSET_MMC0 + (n)) +#define AHB_GATE_OFFSET_SS 5
/* ahb_gate1 offsets */ #define AHB_GATE_OFFSET_DRC0 25 @@ -270,8 +271,9 @@ struct sunxi_ccm_reg { #define AHB_RESET_OFFSET_MMC1 9 #define AHB_RESET_OFFSET_MMC0 8 #define AHB_RESET_OFFSET_MMC(n) (AHB_RESET_OFFSET_MMC0 + (n)) +#define AHB_RESET_OFFSET_SS 5
-/* ahb_reset0 offsets */ +/* ahb_reset1 offsets */ #define AHB_RESET_OFFSET_DRC0 25 #define AHB_RESET_OFFSET_DE_BE0 12 #define AHB_RESET_OFFSET_HDMI 11 diff --git a/arch/arm/include/asm/arch-sunxi/cpu.h b/arch/arm/include/asm/arch-sunxi/cpu.h index bdee89e..90e06c0 100644 --- a/arch/arm/include/asm/arch-sunxi/cpu.h +++ b/arch/arm/include/asm/arch-sunxi/cpu.h @@ -135,9 +135,14 @@
#define SUNXI_CPU_CFG (SUNXI_TIMER_BASE + 0x13c)
+/* SS bonding ids used for cpu identification */ +#define SUNXI_SS_BOND_ID_A31 4 +#define SUNXI_SS_BOND_ID_A31S 5 + #ifndef __ASSEMBLY__ void sunxi_board_init(void); void sunxi_reset(void); +int sunxi_get_ss_bonding_id(void); #endif /* __ASSEMBLY__ */
#endif /* _CPU_H */
On Sun, 2014-11-16 at 17:16 +0100, Hans de Goede wrote:
Add a sunxi_get_ss_bonding_id() function, and use it to differentiate between the A31s and the A31.
Signed-off-by: Hans de Goede hdegoede@redhat.com
Acked-by: Ian Campbell ijc@hellion.org.uk
The A31s only has one dram channel, so do not bother with trying to initalize a second channel.
Signed-off-by: Hans de Goede hdegoede@redhat.com --- arch/arm/cpu/armv7/sunxi/Makefile | 2 +- arch/arm/cpu/armv7/sunxi/dram_sun6i.c | 11 +++++++++-- 2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/arm/cpu/armv7/sunxi/Makefile b/arch/arm/cpu/armv7/sunxi/Makefile index 3b6ae47..1337b60 100644 --- a/arch/arm/cpu/armv7/sunxi/Makefile +++ b/arch/arm/cpu/armv7/sunxi/Makefile @@ -10,6 +10,7 @@ obj-y += timer.o obj-y += board.o obj-y += clock.o +obj-y += cpu_info.o obj-y += pinmux.o obj-$(CONFIG_MACH_SUN6I) += prcm.o obj-$(CONFIG_MACH_SUN8I) += prcm.o @@ -21,7 +22,6 @@ obj-$(CONFIG_MACH_SUN7I) += clock_sun4i.o obj-$(CONFIG_MACH_SUN8I) += clock_sun6i.o
ifndef CONFIG_SPL_BUILD -obj-y += cpu_info.o ifdef CONFIG_ARMV7_PSCI obj-y += psci.o endif diff --git a/arch/arm/cpu/armv7/sunxi/dram_sun6i.c b/arch/arm/cpu/armv7/sunxi/dram_sun6i.c index 30439dc..2ac0b58 100644 --- a/arch/arm/cpu/armv7/sunxi/dram_sun6i.c +++ b/arch/arm/cpu/armv7/sunxi/dram_sun6i.c @@ -372,10 +372,15 @@ unsigned long sunxi_dram_init(void) .rows = 16, };
+ /* A31s only has one channel */ + if (sunxi_get_ss_bonding_id() == SUNXI_SS_BOND_ID_A31S) + para.chan = 1; + mctl_sys_init();
mctl_dll_init(0, ¶); - mctl_dll_init(1, ¶); + if (para.chan == 2) + mctl_dll_init(1, ¶);
setbits_le32(&mctl_com->ccr, MCTL_CCR_MASTER_CLK_EN | @@ -383,7 +388,9 @@ unsigned long sunxi_dram_init(void) MCTL_CCR_CH1_CLK_EN);
mctl_channel_init(0, ¶); - mctl_channel_init(1, ¶); + if (para.chan == 2) + mctl_channel_init(1, ¶); + mctl_com_init(¶); mctl_port_cfg();
On Sun, 2014-11-16 at 17:16 +0100, Hans de Goede wrote:
The A31s only has one dram channel, so do not bother with trying to initalize
"initialize"
a second channel.
Signed-off-by: Hans de Goede hdegoede@redhat.com
arch/arm/cpu/armv7/sunxi/Makefile | 2 +- arch/arm/cpu/armv7/sunxi/dram_sun6i.c | 11 +++++++++-- 2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/arm/cpu/armv7/sunxi/Makefile b/arch/arm/cpu/armv7/sunxi/Makefile index 3b6ae47..1337b60 100644 --- a/arch/arm/cpu/armv7/sunxi/Makefile +++ b/arch/arm/cpu/armv7/sunxi/Makefile @@ -10,6 +10,7 @@ obj-y += timer.o obj-y += board.o obj-y += clock.o +obj-y += cpu_info.o obj-y += pinmux.o obj-$(CONFIG_MACH_SUN6I) += prcm.o obj-$(CONFIG_MACH_SUN8I) += prcm.o @@ -21,7 +22,6 @@ obj-$(CONFIG_MACH_SUN7I) += clock_sun4i.o obj-$(CONFIG_MACH_SUN8I) += clock_sun6i.o
ifndef CONFIG_SPL_BUILD -obj-y += cpu_info.o ifdef CONFIG_ARMV7_PSCI obj-y += psci.o endif diff --git a/arch/arm/cpu/armv7/sunxi/dram_sun6i.c b/arch/arm/cpu/armv7/sunxi/dram_sun6i.c index 30439dc..2ac0b58 100644 --- a/arch/arm/cpu/armv7/sunxi/dram_sun6i.c +++ b/arch/arm/cpu/armv7/sunxi/dram_sun6i.c @@ -372,10 +372,15 @@ unsigned long sunxi_dram_init(void) .rows = 16, };
- /* A31s only has one channel */
- if (sunxi_get_ss_bonding_id() == SUNXI_SS_BOND_ID_A31S)
para.chan = 1;
mctl_channel_init seems to contain some auto detection code, I suppose that doesn't work in this case for some reason? Or is this just an optimisation? In which case is the benefit just quicker to boot?
mctl_sys_init();
mctl_dll_init(0, ¶);
- mctl_dll_init(1, ¶);
- if (para.chan == 2)
mctl_dll_init(1, ¶);
Both this an the next one are basically unrolled for-loops over 0-para.chan now. I suppose it doesn't really matter.
Ian.
Hi,
On 11/17/2014 08:00 PM, Ian Campbell wrote:
On Sun, 2014-11-16 at 17:16 +0100, Hans de Goede wrote:
The A31s only has one dram channel, so do not bother with trying to initalize
"initialize"
Fixed in my local tree.
a second channel.
Signed-off-by: Hans de Goede hdegoede@redhat.com
arch/arm/cpu/armv7/sunxi/Makefile | 2 +- arch/arm/cpu/armv7/sunxi/dram_sun6i.c | 11 +++++++++-- 2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/arm/cpu/armv7/sunxi/Makefile b/arch/arm/cpu/armv7/sunxi/Makefile index 3b6ae47..1337b60 100644 --- a/arch/arm/cpu/armv7/sunxi/Makefile +++ b/arch/arm/cpu/armv7/sunxi/Makefile @@ -10,6 +10,7 @@ obj-y += timer.o obj-y += board.o obj-y += clock.o +obj-y += cpu_info.o obj-y += pinmux.o obj-$(CONFIG_MACH_SUN6I) += prcm.o obj-$(CONFIG_MACH_SUN8I) += prcm.o @@ -21,7 +22,6 @@ obj-$(CONFIG_MACH_SUN7I) += clock_sun4i.o obj-$(CONFIG_MACH_SUN8I) += clock_sun6i.o
ifndef CONFIG_SPL_BUILD -obj-y += cpu_info.o ifdef CONFIG_ARMV7_PSCI obj-y += psci.o endif diff --git a/arch/arm/cpu/armv7/sunxi/dram_sun6i.c b/arch/arm/cpu/armv7/sunxi/dram_sun6i.c index 30439dc..2ac0b58 100644 --- a/arch/arm/cpu/armv7/sunxi/dram_sun6i.c +++ b/arch/arm/cpu/armv7/sunxi/dram_sun6i.c @@ -372,10 +372,15 @@ unsigned long sunxi_dram_init(void) .rows = 16, };
- /* A31s only has one channel */
- if (sunxi_get_ss_bonding_id() == SUNXI_SS_BOND_ID_A31S)
para.chan = 1;mctl_channel_init seems to contain some auto detection code, I suppose that doesn't work in this case for some reason? Or is this just an optimisation? In which case is the benefit just quicker to boot?
My assumption was that it would not work, as the A31s has only one channel, or so the datasheets claim. But it turned out it does work, so they may be using the same die in a different package, I'll go and mail Allwinner and see if they are willing to disclose anything about this (knowing it is the same die would be useful).
So in the end this is only an optimization.
mctl_sys_init();
mctl_dll_init(0, ¶);
- mctl_dll_init(1, ¶);
- if (para.chan == 2)
mctl_dll_init(1, ¶);Both this an the next one are basically unrolled for-loops over 0-para.chan now. I suppose it doesn't really matter.
True, note that in mctl_com_init() we've:
if (para->chan == 1) { /* Shutdown channel 1 */ ... }
So I would prefer to keep this as is (rather then turn it into a loop), for consistency.
Regards,
Hans
On Tue, 2014-11-18 at 13:34 +0100, Hans de Goede wrote:
Hi,
On 11/17/2014 08:00 PM, Ian Campbell wrote:
On Sun, 2014-11-16 at 17:16 +0100, Hans de Goede wrote:
The A31s only has one dram channel, so do not bother with trying to initalize
"initialize"
Fixed in my local tree.
a second channel.
Signed-off-by: Hans de Goede hdegoede@redhat.com
arch/arm/cpu/armv7/sunxi/Makefile | 2 +- arch/arm/cpu/armv7/sunxi/dram_sun6i.c | 11 +++++++++-- 2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/arm/cpu/armv7/sunxi/Makefile b/arch/arm/cpu/armv7/sunxi/Makefile index 3b6ae47..1337b60 100644 --- a/arch/arm/cpu/armv7/sunxi/Makefile +++ b/arch/arm/cpu/armv7/sunxi/Makefile @@ -10,6 +10,7 @@ obj-y += timer.o obj-y += board.o obj-y += clock.o +obj-y += cpu_info.o obj-y += pinmux.o obj-$(CONFIG_MACH_SUN6I) += prcm.o obj-$(CONFIG_MACH_SUN8I) += prcm.o @@ -21,7 +22,6 @@ obj-$(CONFIG_MACH_SUN7I) += clock_sun4i.o obj-$(CONFIG_MACH_SUN8I) += clock_sun6i.o
ifndef CONFIG_SPL_BUILD -obj-y += cpu_info.o ifdef CONFIG_ARMV7_PSCI obj-y += psci.o endif diff --git a/arch/arm/cpu/armv7/sunxi/dram_sun6i.c b/arch/arm/cpu/armv7/sunxi/dram_sun6i.c index 30439dc..2ac0b58 100644 --- a/arch/arm/cpu/armv7/sunxi/dram_sun6i.c +++ b/arch/arm/cpu/armv7/sunxi/dram_sun6i.c @@ -372,10 +372,15 @@ unsigned long sunxi_dram_init(void) .rows = 16, };
- /* A31s only has one channel */
- if (sunxi_get_ss_bonding_id() == SUNXI_SS_BOND_ID_A31S)
para.chan = 1;mctl_channel_init seems to contain some auto detection code, I suppose that doesn't work in this case for some reason? Or is this just an optimisation? In which case is the benefit just quicker to boot?
My assumption was that it would not work, as the A31s has only one channel, or so the datasheets claim. But it turned out it does work, so they may be using the same die in a different package, I'll go and mail Allwinner and see if they are willing to disclose anything about this (knowing it is the same die would be useful).
So in the end this is only an optimization.
mctl_sys_init();
mctl_dll_init(0, ¶);
- mctl_dll_init(1, ¶);
- if (para.chan == 2)
mctl_dll_init(1, ¶);Both this an the next one are basically unrolled for-loops over 0-para.chan now. I suppose it doesn't really matter.
True, note that in mctl_com_init() we've:
if (para->chan == 1) { /* Shutdown channel 1 */ ...}
So I would prefer to keep this as is (rather then turn it into a loop), for consistency.
OK.
(IMHO that shutdown should be pulled up to before/after the loop, but lets not block these patches on that.)
Ian.
This bit of code is the rtc ram being used to detect coming out of "super-standby" mode, and if that is the case, going out of self-refresh mode.
Since we do not support "super-standby" mode, this can be dropped.
Signed-off-by: Hans de Goede hdegoede@redhat.com --- arch/arm/cpu/armv7/sunxi/dram_sun6i.c | 3 --- 1 file changed, 3 deletions(-)
diff --git a/arch/arm/cpu/armv7/sunxi/dram_sun6i.c b/arch/arm/cpu/armv7/sunxi/dram_sun6i.c index 2ac0b58..5e163cb 100644 --- a/arch/arm/cpu/armv7/sunxi/dram_sun6i.c +++ b/arch/arm/cpu/armv7/sunxi/dram_sun6i.c @@ -140,9 +140,6 @@ static void mctl_channel_init(int ch_index, struct dram_sun6i_para *para)
writel((MCTL_TITMSRST << 18) | (MCTL_TDLLLOCK << 6) | MCTL_TDLLSRST, &mctl_phy->ptr0); - /* Unknown magic performed by boot0 */ - if ((readl(SUNXI_RTC_BASE + 0x20c) & 3) == 2) - setbits_le32(&mctl_phy->ptr0, 1 << 18);
writel((MCTL_TDINIT1 << 19) | MCTL_TDINIT0, &mctl_phy->ptr1); writel((MCTL_TDINIT3 << 17) | MCTL_TDINIT2, &mctl_phy->ptr2);
On Sun, 2014-11-16 at 17:16 +0100, Hans de Goede wrote:
This bit of code is the rtc ram being used to detect coming out of "super-standby" mode, and if that is the case, going out of self-refresh mode.
Since we do not support "super-standby" mode, this can be dropped.
Signed-off-by: Hans de Goede hdegoede@redhat.com
Acked-by: Ian Campbell ijc@hellion.org.uk
(perhaps start the commit log with "Allwinner tells us that..."? Ack either way)
arch/arm/cpu/armv7/sunxi/dram_sun6i.c | 3 --- 1 file changed, 3 deletions(-)
diff --git a/arch/arm/cpu/armv7/sunxi/dram_sun6i.c b/arch/arm/cpu/armv7/sunxi/dram_sun6i.c index 2ac0b58..5e163cb 100644 --- a/arch/arm/cpu/armv7/sunxi/dram_sun6i.c +++ b/arch/arm/cpu/armv7/sunxi/dram_sun6i.c @@ -140,9 +140,6 @@ static void mctl_channel_init(int ch_index, struct dram_sun6i_para *para)
writel((MCTL_TITMSRST << 18) | (MCTL_TDLLLOCK << 6) | MCTL_TDLLSRST, &mctl_phy->ptr0);
/* Unknown magic performed by boot0 */
if ((readl(SUNXI_RTC_BASE + 0x20c) & 3) == 2)
setbits_le32(&mctl_phy->ptr0, 1 << 18);writel((MCTL_TDINIT1 << 19) | MCTL_TDINIT0, &mctl_phy->ptr1); writel((MCTL_TDINIT3 << 17) | MCTL_TDINIT2, &mctl_phy->ptr2);
Hi,
On 11/17/2014 08:01 PM, Ian Campbell wrote:
On Sun, 2014-11-16 at 17:16 +0100, Hans de Goede wrote:
This bit of code is the rtc ram being used to detect coming out of "super-standby" mode, and if that is the case, going out of self-refresh mode.
Since we do not support "super-standby" mode, this can be dropped.
Signed-off-by: Hans de Goede hdegoede@redhat.com
Acked-by: Ian Campbell ijc@hellion.org.uk
(perhaps start the commit log with "Allwinner tells us that..."? Ack either way)
Fixed in my local tree.
Regards,
Hans
arch/arm/cpu/armv7/sunxi/dram_sun6i.c | 3 --- 1 file changed, 3 deletions(-)
diff --git a/arch/arm/cpu/armv7/sunxi/dram_sun6i.c b/arch/arm/cpu/armv7/sunxi/dram_sun6i.c index 2ac0b58..5e163cb 100644 --- a/arch/arm/cpu/armv7/sunxi/dram_sun6i.c +++ b/arch/arm/cpu/armv7/sunxi/dram_sun6i.c @@ -140,9 +140,6 @@ static void mctl_channel_init(int ch_index, struct dram_sun6i_para *para)
writel((MCTL_TITMSRST << 18) | (MCTL_TDLLLOCK << 6) | MCTL_TDLLSRST, &mctl_phy->ptr0);
/* Unknown magic performed by boot0 */
if ((readl(SUNXI_RTC_BASE + 0x20c) & 3) == 2)
setbits_le32(&mctl_phy->ptr0, 1 << 18);writel((MCTL_TDINIT1 << 19) | MCTL_TDINIT0, &mctl_phy->ptr1); writel((MCTL_TDINIT3 << 17) | MCTL_TDINIT2, &mctl_phy->ptr2);
The CSQ CS908 is an A31s based top-set box, with 1G RAM, 8G NAND, rtl8188etv usb wifi, 2 USB A receptacles (1 connected through the OTG controller), ethernet, 3.5 mm jack with a/v out and hdmi out:
http://www.geekbuying.com/item/CS908-Allwinner-A31S-Quad-Core-1-2GHz-Android...
Note it has no sdcard slot!
Signed-off-by: Hans de Goede hdegoede@redhat.com --- configs/CSQ_CS908_defconfig | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) create mode 100644 configs/CSQ_CS908_defconfig
diff --git a/configs/CSQ_CS908_defconfig b/configs/CSQ_CS908_defconfig new file mode 100644 index 0000000..024df47 --- /dev/null +++ b/configs/CSQ_CS908_defconfig @@ -0,0 +1,16 @@ +CONFIG_SPL=y +CONFIG_SYS_EXTRA_OPTIONS="USB_EHCI" +CONFIG_FDTFILE="sun6i-a31s-cs908.dtb" ++S:CONFIG_ARM=y ++S:CONFIG_ARCH_SUNXI=y ++S:CONFIG_MACH_SUN6I=y ++S:CONFIG_TARGET_CSQ_CS908=y ++S:CONFIG_DRAM_CLK=432 ++S:CONFIG_DRAM_ZQ=123 +# Wifi power ++S:CONFIG_AXP221_ALDO1_VOLT=3300 +# HDMI power ? ++S:CONFIG_AXP221_ALDO2_VOLT=1800 ++S:CONFIG_AXP221_ALDO3_VOLT=3000 +# No Vbus gpio for usb1 ++S:CONFIG_USB1_VBUS_PIN=""
On Sun, 2014-11-16 at 17:16 +0100, Hans de Goede wrote:
The CSQ CS908 is an A31s based top-set box, with 1G RAM, 8G NAND, rtl8188etv usb wifi, 2 USB A receptacles (1 connected through the OTG controller), ethernet, 3.5 mm jack with a/v out and hdmi out:
http://www.geekbuying.com/item/CS908-Allwinner-A31S-Quad-Core-1-2GHz-Android...
Note it has no sdcard slot!
What are the implications of that?
Signed-off-by: Hans de Goede hdegoede@redhat.com
Acked-by: Ian Campbell ijc@hellion.org.uk
Hi,
On 11/17/2014 08:03 PM, Ian Campbell wrote:
On Sun, 2014-11-16 at 17:16 +0100, Hans de Goede wrote:
The CSQ CS908 is an A31s based top-set box, with 1G RAM, 8G NAND, rtl8188etv usb wifi, 2 USB A receptacles (1 connected through the OTG controller), ethernet, 3.5 mm jack with a/v out and hdmi out:
http://www.geekbuying.com/item/CS908-Allwinner-A31S-Quad-Core-1-2GHz-Android...
Note it has no sdcard slot!
What are the implications of that?
That we can only fel-boot it. This is mostly a warning to end users to avoid this box if they want a box on which they can easily run Linux.
This does mean I got to use make foo_felconfig, works like a charm :)
Thanks for the reviews.
Regards,
Hans
On Tue, 2014-11-18 at 13:47 +0100, Hans de Goede wrote:
Hi,
On 11/17/2014 08:03 PM, Ian Campbell wrote:
On Sun, 2014-11-16 at 17:16 +0100, Hans de Goede wrote:
The CSQ CS908 is an A31s based top-set box, with 1G RAM, 8G NAND, rtl8188etv usb wifi, 2 USB A receptacles (1 connected through the OTG controller), ethernet, 3.5 mm jack with a/v out and hdmi out:
http://www.geekbuying.com/item/CS908-Allwinner-A31S-Quad-Core-1-2GHz-Android...
Note it has no sdcard slot!
What are the implications of that?
That we can only fel-boot it. This is mostly a warning to end users to avoid this box if they want a box on which they can easily run Linux.
Ah, right. Probably best to end the sentence with "and therefore can only be fel booted" or something then.
Presumably In The Fullness Of Time(tm) it'll be possible to boot from NAND too, but lets not muddy those waters here...
This does mean I got to use make foo_felconfig, works like a charm :)
Oh good ;-)
Ian.
Hi,
On 11/18/2014 03:10 PM, Ian Campbell wrote:
On Tue, 2014-11-18 at 13:47 +0100, Hans de Goede wrote:
Hi,
On 11/17/2014 08:03 PM, Ian Campbell wrote:
On Sun, 2014-11-16 at 17:16 +0100, Hans de Goede wrote:
The CSQ CS908 is an A31s based top-set box, with 1G RAM, 8G NAND, rtl8188etv usb wifi, 2 USB A receptacles (1 connected through the OTG controller), ethernet, 3.5 mm jack with a/v out and hdmi out:
http://www.geekbuying.com/item/CS908-Allwinner-A31S-Quad-Core-1-2GHz-Android...
Note it has no sdcard slot!
What are the implications of that?
That we can only fel-boot it. This is mostly a warning to end users to avoid this box if they want a box on which they can easily run Linux.
Ah, right. Probably best to end the sentence with "and therefore can only be fel booted" or something then.
Good idea, I've amended the commit message with this in my personal tree.
Presumably In The Fullness Of Time(tm) it'll be possible to boot from NAND too, but lets not muddy those waters here...
Hopefully we will eventually support NAND booting, yes.
Regards,
Hans
On Sun, 2014-11-16 at 17:16 +0100, Hans de Goede wrote:
+config DRAM_ZQ
- int "sun6i dram zq value" if EXPERT
- default 123
== 0x7b, which differs from the previous default of 0x78 (not by much, but still)
diff --git a/configs/Colombus_defconfig b/configs/Colombus_defconfig index bef568d..5e245a3 100644 --- a/configs/Colombus_defconfig +++ b/configs/Colombus_defconfig @@ -4,3 +4,5 @@ CONFIG_FDTFILE="sun6i-a31-colombus.dtb" +S:CONFIG_ARCH_SUNXI=y +S:CONFIG_MACH_SUN6I=y +S:CONFIG_TARGET_COLOMBUS=y ++S:CONFIG_DRAM_CLK=288 ++S:CONFIG_DRAM_ZQ=379
Do these actually take affect if CONFIG_EXPERT=n?
Perhaps CONFIG_TARGET_COLOMBUS should select DRAM_CLK == 288 and DRAM_CLK should be a hidden option?
Ian.
Hi,
On 11/17/2014 07:54 PM, Ian Campbell wrote:
On Sun, 2014-11-16 at 17:16 +0100, Hans de Goede wrote:
+config DRAM_ZQ
- int "sun6i dram zq value" if EXPERT
- default 123
== 0x7b, which differs from the previous default of 0x78 (not by much, but still)
Right, this is deliberate as I've gotten access to more boards, 123 seems a better default (this is also what most A10 / A13 / A20 boards use).
diff --git a/configs/Colombus_defconfig b/configs/Colombus_defconfig index bef568d..5e245a3 100644 --- a/configs/Colombus_defconfig +++ b/configs/Colombus_defconfig @@ -4,3 +4,5 @@ CONFIG_FDTFILE="sun6i-a31-colombus.dtb" +S:CONFIG_ARCH_SUNXI=y +S:CONFIG_MACH_SUN6I=y +S:CONFIG_TARGET_COLOMBUS=y ++S:CONFIG_DRAM_CLK=288 ++S:CONFIG_DRAM_ZQ=379
Do these actually take affect if CONFIG_EXPERT=n?
Ugh, I just checked, and no they don't.
Perhaps CONFIG_TARGET_COLOMBUS should select DRAM_CLK == 288 and DRAM_CLK should be a hidden option?
I would prefer to keep these inside the defconfig's so that for adding a new board only a defconfig needs to be added.
Currently the only CONFIG_TARGET_BOARD we actually use in u-boot is the bananapi gmac tx clk delay tweak, and I would actually like to keep things that way. Actually thinking more about this, I think that that should be turned into a GMAC specific Kconfig option and all the CONFIG_TARGET_BOARD stuff should be dropped, as it is just a drag causing extra maintenance going forward.
So is there a way to not show a choice to the user unless EXPERT mode is set, and still override it from Kconfig ?
If that is not (easily) possible, then I guess we will just need to not make these "if EXPERT".
Regards,
Hans
On Tue, 2014-11-18 at 12:32 +0100, Hans de Goede wrote:
Hi,
On 11/17/2014 07:54 PM, Ian Campbell wrote:
On Sun, 2014-11-16 at 17:16 +0100, Hans de Goede wrote:
+config DRAM_ZQ
- int "sun6i dram zq value" if EXPERT
- default 123
== 0x7b, which differs from the previous default of 0x78 (not by much, but still)
Right, this is deliberate as I've gotten access to more boards, 123 seems a better default (this is also what most A10 / A13 / A20 boards use).
Please mention this in the commit log.
diff --git a/configs/Colombus_defconfig b/configs/Colombus_defconfig index bef568d..5e245a3 100644 --- a/configs/Colombus_defconfig +++ b/configs/Colombus_defconfig @@ -4,3 +4,5 @@ CONFIG_FDTFILE="sun6i-a31-colombus.dtb" +S:CONFIG_ARCH_SUNXI=y +S:CONFIG_MACH_SUN6I=y +S:CONFIG_TARGET_COLOMBUS=y ++S:CONFIG_DRAM_CLK=288 ++S:CONFIG_DRAM_ZQ=379
Do these actually take affect if CONFIG_EXPERT=n?
Ugh, I just checked, and no they don't.
Perhaps CONFIG_TARGET_COLOMBUS should select DRAM_CLK == 288 and DRAM_CLK should be a hidden option?
I would prefer to keep these inside the defconfig's so that for adding a new board only a defconfig needs to be added.
Currently the only CONFIG_TARGET_BOARD we actually use in u-boot is the bananapi gmac tx clk delay tweak, and I would actually like to keep things that way. Actually thinking more about this, I think that that should be turned into a GMAC specific Kconfig option and all the CONFIG_TARGET_BOARD stuff should be dropped, as it is just a drag causing extra maintenance going forward.
Hrm, I'm not sure yet which way I fall on this question.
So is there a way to not show a choice to the user unless EXPERT mode is set, and still override it from Kconfig ?
Not AFAIK, but I'm not expert (no pun intended) in Kconfig.
If that is not (easily) possible, then I guess we will just need to not make these "if EXPERT".
Probably :-(
Hi,
On 11/18/2014 03:07 PM, Ian Campbell wrote:
On Tue, 2014-11-18 at 12:32 +0100, Hans de Goede wrote:
Hi,
On 11/17/2014 07:54 PM, Ian Campbell wrote:
On Sun, 2014-11-16 at 17:16 +0100, Hans de Goede wrote:
+config DRAM_ZQ
- int "sun6i dram zq value" if EXPERT
- default 123
== 0x7b, which differs from the previous default of 0x78 (not by much, but still)
Right, this is deliberate as I've gotten access to more boards, 123 seems a better default (this is also what most A10 / A13 / A20 boards use).
Please mention this in the commit log.
Fixed in my personal tree.
diff --git a/configs/Colombus_defconfig b/configs/Colombus_defconfig index bef568d..5e245a3 100644 --- a/configs/Colombus_defconfig +++ b/configs/Colombus_defconfig @@ -4,3 +4,5 @@ CONFIG_FDTFILE="sun6i-a31-colombus.dtb" +S:CONFIG_ARCH_SUNXI=y +S:CONFIG_MACH_SUN6I=y +S:CONFIG_TARGET_COLOMBUS=y ++S:CONFIG_DRAM_CLK=288 ++S:CONFIG_DRAM_ZQ=379
Do these actually take affect if CONFIG_EXPERT=n?
Ugh, I just checked, and no they don't.
Perhaps CONFIG_TARGET_COLOMBUS should select DRAM_CLK == 288 and DRAM_CLK should be a hidden option?
I would prefer to keep these inside the defconfig's so that for adding a new board only a defconfig needs to be added.
Currently the only CONFIG_TARGET_BOARD we actually use in u-boot is the bananapi gmac tx clk delay tweak, and I would actually like to keep things that way. Actually thinking more about this, I think that that should be turned into a GMAC specific Kconfig option and all the CONFIG_TARGET_BOARD stuff should be dropped, as it is just a drag causing extra maintenance going forward.
Hrm, I'm not sure yet which way I fall on this question.
Ok, so how do you feel no that you've slept a night on it ?
May main reason for wanting to get rid of this is that it does not buy us much, unless we start adding things like select FOO in there as you suggested, but that seems less transparent then having all the board specific settings in the _defconfig. To me the ideal scenario is that adding a new board is just adding a new _defconfig, and likewise figuring out what board specific settings are done for a certain board also is just a manner of inspecting the _defconfig, and not 2 - 3 different files.
If we decide we want everything in the _defconfig, and thus CONFIG_TARGET_BOARD does not select / enable anything, iow is essentially unused, then we might just as well drop it.
So is there a way to not show a choice to the user unless EXPERT mode is set, and still override it from Kconfig ?
Not AFAIK, but I'm not expert (no pun intended) in Kconfig.
If that is not (easily) possible, then I guess we will just need to not make these "if EXPERT".
Probably :-(
Ok, so I've dropped the "if EXPERT" from the version in my personal tree.
Regards,
Hans
participants (2)
-
Hans de Goede -
Ian Campbell