sunxi: Bug fixes, sun4i and sun5i support and network improvements
v3 cover sunxi: Bug fixes, sun4i and sun5i support and network improvements
Hi All,
Here is v2 of my patch series to be applied on top of Ian's recently merged basic sun7i support.
This patch series begins with a few bug fixes found while working on preparing the rest of the series, adds sun4i and sun5i support and rounds things of with some networking fixes / additions.
Changes since v1:
-Improved various commit messages
-Various small typo fixes
-Cleaned up the axp209 and axp152 drivers
-Added Acked-by: Ian Campbell ... to the patches which got acked by Ian
Changes since v2:
-Dropped the i2c + pmic support patches as they need more work -Split out the boards.cfg Cubietruck maintainer field changes from the axp209
support patch into its own patch
-Added Acked-by: Ian Campbell ... to the patches which got acked by Ian
Regards,
Hans
PATCH v3 1/10 sunxi: mksunxiboot: Fix loading of files with a size which is not a multiple of 4
We should not be aligning the amount of bytes which we try to read from the disk, this leads to trying to read more bytes then there are which fails.
file_size is already aligned to BLOCK_SIZE before being stored in img.header.length, so there is no need for load_size at all.
--- tools/mksunxiboot.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-)
tools/mksunxiboot.c +4 -6
@@ -77,7 +77,7 @@ int main(int argc, char *argv[]) {int fd_in, fd_out;struct boot_img img; -unsigned file_size, load_size; +unsigned file_size;int count;if (argc <2 ) {
@@ -101,8 +101,6 @@ int main(int argc, char *argv[])if (file_size >SRAM_LOAD_MAX_SIZE ) {fprintf (stderr,"ERROR: File too large!\n" );return EXIT_FAILURE ; - }else { - load_size =ALIGN (file_size,sizeof (int )); } fd_out =open (argv[2 ],O_WRONLY |O_CREAT ,0666 );
@@ -113,8 +111,8 @@ int main(int argc, char *argv[])/* read file to buffer to calculate checksum */ lseek (fd_in,0 ,SEEK_SET ); - count =read (fd_in, img.code, load_size); -if (count != load_size) { + count =read (fd_in, img.code, file_size); +if (count != file_size) {perror ("Reading input image" );return EXIT_FAILURE ; }
@@ -126,7 +124,7 @@ int main(int argc, char *argv[]) & 0x00FFFFFF);memcpy (img.header.magic,BOOT0_MAGIC ,8 );/* no '0' termination */ img.header.length = -ALIGN (load_size +sizeof (struct boot_file_head ),BLOCK_SIZE ); +ALIGN (file_size +sizeof (struct boot_file_head ),BLOCK_SIZE );gen_check_sum (&img.header); count =write (fd_out, &img, img.header.length);
Signature · 1 line
2.0.0
PATCH v3 2/10 sunxi: Fix u-boot-spl.lds to refer to .vectors
In reply to Hans de GoedeAdjust the u-boot-spl.lds linker script to match the changes made in the 41623c91b09a0c865fab41acdaff30f060f29ad6 "arm: move exception handling out of start.S files" commit.
--- arch/arm/cpu/armv7/sunxi/u-boot-spl.lds | 1 + 1 file changed, 1 insertion(+)
arch/arm/cpu/armv7/sunxi/u-boot-spl.lds +1 -0
@@ -27,6 +27,7 @@ SECTIONS .text : { __start = .; + *(.vectors) arch/arm/cpu/armv7/start.o (.text) *(.text*) } > .sram
Signature · 1 line
2.0.0
PATCH v3 3/10 sunxi: Remove mmc DMA support
In reply to Hans de GoedeThe DMA code in sunxi_mmc.c is broken. mmc_trans_data_by_dma() allocates the dma descriptors on the stack, and then exits while the dma transfer is in progress, so the dma engine is reading stack memory which at that point may be re-used. So far we've gotten away with this by luck, but recent u-boot changes have shifted the stack start address by 16 bytes, which combined with dma alignment now exposes this problem.
Since we end up just busy waiting for the dma engine anyway, this commit fixes things by simply removing the dma code, resulting in smaller bug-free code.
--- drivers/mmc/sunxi_mmc.c | 140 ++--------------------------------------- include/configs/sunxi-common.h | 1 - 2 files changed, 6 insertions(+), 135 deletions(-)
drivers/mmc/sunxi_mmc.c +6 -134
@@ -16,28 +16,6 @@#include <asm/arch/cpu.h> #include <asm/arch/mmc.h> -struct sunxi_mmc_des { -u32 reserved1_1:1 ; -u32 dic:1 ;/* disable interrupt on completion */ -u32 last_des:1 ;/* 1-this data buffer is the last buffer */ -u32 first_des:1 ;/* 1-data buffer is the first buffer, -0-data buffer contained in the next -descriptor is 1st buffer */ -u32 des_chain:1 ;/* 1-the 2nd address in the descriptor is the -next descriptor address */ -u32 end_of_ring:1 ;/* 1-last descriptor flag when using dual -data buffer in descriptor */ -u32 reserved1_2:24 ; -u32 card_err_sum:1 ;/* transfer error flag */ -u32 own:1 ;/* des owner:1-idma owns it, 0-host owns it */ -#define SDXC_DES_NUM_SHIFT 16 -#define SDXC_DES_BUFFER_MAX_LEN (1 << SDXC_DES_NUM_SHIFT) -u32 data_buf1_sz:16 ; -u32 data_buf2_sz:16 ; -u32 buf_addr_ptr1; -u32 buf_addr_ptr2; -}; -struct sunxi_mmc_host {unsigned mmc_no;uint32_t *mclkreg;
@@ -189,6 +167,9 @@ static int mmc_core_init(struct mmc *mmc)/* Reset controller */ writel (SUNXI_MMC_GCTRL_RESET , &mmchost->reg->gctrl); +udelay (1000 ); +/* Always read / write data through the CPU */ +writel (SUNXI_MMC_GCTRL_ACCESS_BY_AHB , &mmchost->reg->gctrl);return 0 ; }
@@ -220,85 +201,6 @@ static int mmc_trans_data_by_cpu(struct mmc *mmc, struct mmc_data *data)return 0 ; } -static int mmc_trans_data_by_dma (struct mmc *mmc,struct mmc_data *data) -{ -struct sunxi_mmc_host *mmchost = mmc->priv; -unsigned byte_cnt = data->blocksize * data->blocks; -unsigned char *buff; -unsigned des_idx =0 ; -unsigned buff_frag_num = - (byte_cnt +SDXC_DES_BUFFER_MAX_LEN -1 ) >>SDXC_DES_NUM_SHIFT ; -unsigned remain; -unsigned i, rval; - ALLOC_CACHE_ALIGN_BUFFER(struct sunxi_mmc_des, pdes, buff_frag_num); - - buff = data->flags &MMC_DATA_READ ? - (unsigned char *)data->dest : (unsigned char *)data->src; - remain = byte_cnt & (SDXC_DES_BUFFER_MAX_LEN -1 ); - -flush_cache ((unsigned long )buff, (unsigned long )byte_cnt); -for (i =0 ; i < buff_frag_num; i++, des_idx++) { -memset ((void *)&pdes[des_idx],0 ,sizeof (struct sunxi_mmc_des )); - pdes[des_idx].des_chain =1 ; - pdes[des_idx].own =1 ; - pdes[des_idx].dic =1 ; -if (buff_frag_num >1 && i != buff_frag_num -1 ) - pdes[des_idx].data_buf1_sz =0 ;/* 0 == max_len */ -else - pdes[des_idx].data_buf1_sz = remain; - - pdes[des_idx].buf_addr_ptr1 = - (u32 ) buff + i *SDXC_DES_BUFFER_MAX_LEN ; -if (i ==0 ) - pdes[des_idx].first_des =1 ; - -if (i == buff_frag_num -1 ) { - pdes[des_idx].dic =0 ; - pdes[des_idx].last_des =1 ; - pdes[des_idx].end_of_ring =1 ; - pdes[des_idx].buf_addr_ptr2 =0 ; - }else { - pdes[des_idx].buf_addr_ptr2 = (u32)&pdes[des_idx +1 ]; - } - } -flush_cache ((unsigned long )pdes, -sizeof (struct sunxi_mmc_des ) * (des_idx +1 )); - - rval =readl (&mmchost->reg->gctrl); -/* Enable DMA */ -writel (rval |SUNXI_MMC_GCTRL_DMA_RESET |SUNXI_MMC_GCTRL_DMA_ENABLE , - &mmchost->reg->gctrl); -/* Reset iDMA */ -writel (SUNXI_MMC_IDMAC_RESET , &mmchost->reg->dmac); -/* Enable iDMA */ -writel (SUNXI_MMC_IDMAC_FIXBURST |SUNXI_MMC_IDMAC_ENABLE , - &mmchost->reg->dmac); - rval =readl (&mmchost->reg->idie) & - ~(SUNXI_MMC_IDIE_TXIRQ |SUNXI_MMC_IDIE_RXIRQ ); -if (data->flags &MMC_DATA_WRITE ) - rval |=SUNXI_MMC_IDIE_TXIRQ ; -else - rval |=SUNXI_MMC_IDIE_RXIRQ ; -writel (rval, &mmchost->reg->idie); -writel ((u32 ) pdes, &mmchost->reg->dlba); -writel ((0x2 <<28 ) | (0x7 <<16 ) | (0x01 <<3 ), - &mmchost->reg->ftrglevel); - -return 0 ; -} - -static void mmc_enable_dma_accesses (struct mmc *mmc,int dma) -{ -struct sunxi_mmc_host *mmchost = mmc->priv; - -unsigned int gctrl =readl (&mmchost->reg->gctrl); -if (dma) - gctrl &= ~SUNXI_MMC_GCTRL_ACCESS_BY_AHB ; -else - gctrl |=SUNXI_MMC_GCTRL_ACCESS_BY_AHB ; -writel (gctrl, &mmchost->reg->gctrl); -} -static int mmc_rint_wait (struct mmc *mmc,unsigned int timeout_msecs,unsigned int done_bit,const char *what) {
@@ -327,7 +229,6 @@ static int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd,unsigned int timeout_msecs;int error =0 ;unsigned int status =0 ; -unsigned int usedma =0 ;unsigned int bytecnt =0 ;if (mmchost->fatal_err)
@@ -378,20 +279,8 @@ static int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd, bytecnt = data->blocksize * data->blocks;debug ("trans data %d bytes\n" , bytecnt); -#if defined(CONFIG_MMC_SUNXI_USE_DMA ) && !defined(CONFIG_SPL_BUILD ) -if (bytecnt >64 ) { -#else -if (0 ) { -#endif - usedma =1 ; -mmc_enable_dma_accesses (mmc,1 ); - ret =mmc_trans_data_by_dma (mmc, data); -writel (cmdval | cmd->cmdidx, &mmchost->reg->cmd); - }else { -mmc_enable_dma_accesses (mmc,0 ); -writel (cmdval | cmd->cmdidx, &mmchost->reg->cmd); - ret =mmc_trans_data_by_cpu (mmc, data); - } +writel (cmdval | cmd->cmdidx, &mmchost->reg->cmd); + ret =mmc_trans_data_by_cpu (mmc, data);if (ret) { error =readl (&mmchost->reg->rint) & \SUNXI_MMC_RINT_INTERRUPT_ERROR_BIT ;
@@ -405,7 +294,7 @@ static int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd, goto out;if (data) { - timeout_msecs = usedma ?120 * bytecnt :120 ; + timeout_msecs =120 ;debug ("cacl timeout %x msec\n" , timeout_msecs); error = mmc_rint_wait(mmc, timeout_msecs, data->blocks > 1 ?
@@ -442,23 +331,6 @@ static int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd,debug ("mmc resp 0x%08x\n" , cmd->response[0 ]); } out: -if (data && usedma) { -/* IDMASTAREG -* IDST[0] : idma tx int -* IDST[1] : idma rx int -* IDST[2] : idma fatal bus error -* IDST[4] : idma descriptor invalid -* IDST[5] : idma error summary -* IDST[8] : idma normal interrupt sumary -* IDST[9] : idma abnormal interrupt sumary -*/ - status =readl (&mmchost->reg->idst); -writel (status, &mmchost->reg->idst); -writel (0 , &mmchost->reg->idie); -writel (0 , &mmchost->reg->dmac); -writel (readl (&mmchost->reg->gctrl) & ~SUNXI_MMC_GCTRL_DMA_ENABLE , - &mmchost->reg->gctrl); - }if (error <0 ) {writel (SUNXI_MMC_GCTRL_RESET , &mmchost->reg->gctrl);mmc_update_clk (mmc);
include/configs/sunxi-common.h +0 -1
@@ -70,7 +70,6 @@#define CONFIG_CMD_MMC #define CONFIG_MMC_SUNXI #define CONFIG_MMC_SUNXI_SLOT 0 -#define CONFIG_MMC_SUNXI_USE_DMA #define CONFIG_ENV_IS_IN_MMC #define CONFIG_SYS_MMC_ENV_DEV 0/* first detected MMC controller */
Signature · 1 line
2.0.0
PATCH v3 3/10 sunxi: Remove mmc DMA support
Quoted 7 lines · On Mon, 9 Jun 2014 11:36:55 +0200 Hans de Goede <[email protected]> wrote:
The DMA code in
sunxi_mmc.cis broken.mmc_trans_data_by_dma()allocates the dma descriptors on the stack, and then exits while the dma transfer is in progress, so the dma engine is reading stack memory which at that point may be re-used. So far we've gotten away with this by luck, but recent u-boot changes have shifted the stack start address by 16 bytes, which combined with dma alignment now exposes this problem.
Quoted 6 lines
Since we end up just busy waiting for the dma engine anyway, this commit fixes things by simply removing the dma code, resulting in smaller bug-free code.
Signed-off-by Hans de Goede <[email protected]>Acked-by Ian Campbell <[email protected]>
Was it a good idea to keep v2014.07 release relying on luck without this patch?
Signature · 2 lines
Best regards, Siarhei Siamashka
PATCH v3 3/10 sunxi: Remove mmc DMA support
Hi,
Quoted 10 lines · Siarhei Siamashka
Quoted 7 lines · On Mon, 9 Jun 2014 11:36:55 +0200 Hans de Goede <[email protected]> wrote:
The DMA code in
sunxi_mmc.cis broken.mmc_trans_data_by_dma()allocates the dma descriptors on the stack, and then exits while the dma transfer is in progress, so the dma engine is reading stack memory which at that point may be re-used. So far we've gotten away with this by luck, but recent u-boot changes have shifted the stack start address by 16 bytes, which combined with dma alignment now exposes this problem.
Quoted 8 lines
Quoted 6 lines
Since we end up just busy waiting for the dma engine anyway, this commit fixes things by simply removing the dma code, resulting in smaller bug-free code.
Signed-off-by Hans de Goede <[email protected]>Acked-by Ian Campbell <[email protected]>
Thanks for the review. Note Ian has already submitted a pull-request for these patches, so your ack won't make it upstream.
Quoted 2 lines
Was it a good idea to keep v2014.07 release relying on luck without this patch?
Considering that things just work there, and the timing of when I found this out, yes.
Regards,
Hans
PATCH v3 4/10 sunxi: Implement reset_cpu
In reply to Hans de GoedeThere is no way to reset the cpu, so use the watchdog for this.
--- arch/arm/cpu/armv7/sunxi/board.c | 7 +++++++ arch/arm/include/asm/arch-sunxi/timer.h | 5 +++++ 2 files changed, 12 insertions(+)
arch/arm/cpu/armv7/sunxi/board.c +7 -0
@@ -56,6 +56,13 @@ int gpio_init(void)void reset_cpu (ulong addr) { +static const struct sunxi_wdog *wdog = + &((struct sunxi_timer_reg *)SUNXI_TIMER_BASE )->wdog; + +/* Set the watchdog for its shortest interval (.5s) and wait */ +writel (WDT_MODE_RESET_EN |WDT_MODE_EN , &wdog->mode); +writel (WDT_CTRL_KEY |WDT_CTRL_RESTART , &wdog->ctl); +while (1 ); }/* do some early init */
arch/arm/include/asm/arch-sunxi/timer.h +5 -0
@@ -11,6 +11,11 @@#ifndef _SUNXI_TIMER_H_#define _SUNXI_TIMER_H_ +#define WDT_CTRL_RESTART (0x1 << 0) +#define WDT_CTRL_KEY (0x0a57 << 1) +#define WDT_MODE_EN (0x1 << 0) +#define WDT_MODE_RESET_EN (0x1 << 1) +#ifndef __ASSEMBLY__#include <linux/types.h>
Signature · 1 line
2.0.0
PATCH v3 4/10 sunxi: Implement reset_cpu
Quoted 4 lines · On Mon, 9 Jun 2014 11:36:56 +0200 Hans de Goede <[email protected]> wrote:
There is no way to reset the cpu, so use the watchdog for this.
Signed-off-by Hans de Goede <[email protected]>Acked-by Ian Campbell <[email protected]>
However shouldn't this be squashed with
http://patchwork.ozlabs.org/patch/359692/ ?
Otherwise there is a range of commits, where reset is broken on sun5i hardware in the middle of the patch set.
Signature · 2 lines
Best regards, Siarhei Siamashka
PATCH v3 4/10 sunxi: Implement reset_cpu
Hi,
Quoted 5 lines · Siarhei Siamashka
Quoted 2 lines · On Mon, 9 Jun 2014 11:36:56 +0200 Hans de Goede <[email protected]> wrote:
There is no way to reset the cpu, so use the watchdog for this.
Quoted 7 lines
Quoted 2 lines
Signed-off-by Hans de Goede <[email protected]>Acked-by Ian Campbell <[email protected]>However shouldn't this be squashed with
http://patchwork.ozlabs.org/patch/359692/ ?
Good point, unfortunately the pull-req has already gone out.
Quoted 2 lines
Otherwise there is a range of commits, where reset is broken on sun5i hardware in the middle of the patch set.
True, but what are the chances people will be testing reset in a bisect? Other then for a bisect this should not be an issue as this is all part of a single pull-req.
Regards,
Hans
PATCH v3 5/10 sunxi: Add sun4i support
In reply to Hans de GoedeAdd support for the Allwinner A10 SoC also known as the Allwinner sun4i family, and add the Cubieboard board which uses the A10 SoC.
Compared to sun7 only the DRAM controller is a bit different:
-Controller reset bits are inverted, but only for Rev. A -Different hpcr values
-No MBUS on sun4i
-Various other initialization changes
--- arch/arm/cpu/armv7/sunxi/Makefile | 2 + arch/arm/cpu/armv7/sunxi/cpu_info.c | 7 ++++ arch/arm/cpu/armv7/sunxi/dram.c | 81 +++++++++++++++++++++++++++++++++++-- board/sunxi/Makefile | 1 + board/sunxi/dram_cubieboard.c | 31 ++++++++++++++ boards.cfg | 1 + include/configs/sun4i.h | 23 +++++++++++ 7 files changed, 143 insertions(+), 3 deletions(-) create mode 100644 board/sunxi/dram_cubieboard.c create mode 100644 include/configs/sun4i.h
arch/arm/cpu/armv7/sunxi/Makefile +2 -0
@@ -11,6 +11,7 @@ obj-y += timer.o obj-y += board.o obj-y += clock.o obj-y += pinmux.o +obj-$(CONFIG_SUN4I) += clock_sun4i.o obj-$(CONFIG_SUN7I) += clock_sun4i.o ifndef CONFIG_SPL_BUILD
@@ -18,6 +19,7 @@ obj-y += cpu_info.o endif ifdef CONFIG_SPL_BUILD +obj-$(CONFIG_SUN4I) += dram.o obj-$(CONFIG_SUN7I) += dram.o ifdef CONFIG_SPL_FEL obj-y += start.o
arch/arm/cpu/armv7/sunxi/cpu_info.c +7 -0
@@ -13,7 +13,14 @@#ifdef CONFIG_DISPLAY_CPUINFO int print_cpuinfo (void ) { +#ifdef CONFIG_SUN4I +puts ("CPU: Allwinner A10 (SUN4I)\n" ); +#elif definedCONFIG_SUN7I puts ("CPU: Allwinner A20 (SUN7I)\n" ); +#else +#warning Please update cpu_info.c with correct CPU information +puts ("CPU: SUNXI Family\n" ); +#endif return 0 ; }#endif
arch/arm/cpu/armv7/sunxi/dram.c +78 -3
151 lines not on this page · raw message
board/sunxi/Makefile +1 -0
@@ -10,4 +10,5 @@ # obj-y += board.o obj-$(CONFIG_SUNXI_GMAC) += gmac.o +obj-$(CONFIG_CUBIEBOARD) += dram_cubieboard.o obj-$(CONFIG_CUBIETRUCK) += dram_cubietruck.o
board/sunxi/dram_cubieboard.c new file +31 -0
@@ -0,0 +1,31 @@ +/* this file is generated, don't edit it yourself */ + +#include <common.h> +#include <asm/arch/dram.h> + +static struct dram_para dram_para = { + .clock =480 , + .type =3 , + .rank_num =1 , + .density =4096 , + .io_width =16 , + .bus_width =32 , + .cas =6 , + .zq =123 , + .odt_en =0 , + .size =1024 , + .tpr0 =0x30926692 , + .tpr1 =0x1090 , + .tpr2 =0x1a0c8 , + .tpr3 =0 , + .tpr4 =0 , + .tpr5 =0 , + .emr1 =0 , + .emr2 =0 , + .emr3 =0 , +}; + +unsigned long sunxi_dram_init (void ) +{ +return dramc_init (&dram_para); +}
boards.cfg +1 -0
@@ -374,6 +374,7 @@ Active arm armv7 rmobile renesas lager Active arm armv7 s5pc1xx samsung goni s5p_goni - Przemyslaw Marczak <[email protected]> Active arm armv7 s5pc1xx samsung smdkc100 smdkc100 - Minkyu Kang <[email protected]> Active arm armv7 socfpga altera socfpga socfpga_cyclone5 - - +Active arm armv7 sunxi - sunxi Cubieboard sun4i:CUBIEBOARD,SPL Hans de Goede <[email protected]> Active arm armv7 sunxi - sunxi Cubietruck sun7i:CUBIETRUCK,SPL,SUNXI_GMAC,RGMII - Active arm armv7 sunxi - sunxi Cubietruck_FEL sun7i:CUBIETRUCK,SPL_FEL,SUNXI_GMAC,RGMII - Active arm armv7 u8500 st-ericsson snowball snowball - Mathieu Poirier <[email protected]>
include/configs/sun4i.h new file +23 -0
@@ -0,0 +1,23 @@ +/* +* (C) Copyright 2012-2013 Henrik Nordstrom <[email protected]> +* +* Configuration settings for the Allwinner A10 (sun4i) CPU +* +* SPDX-License-Identifier: GPL-2.0+ +*/ +#ifndef __CONFIG_H +#define __CONFIG_H + +/* +* A10 specific configuration +*/ +#define CONFIG_SUN4I /* sun4i SoC generation */ + +#define CONFIG_SYS_PROMPT "sun4i# " + +/* +* Include common sunxi configuration where most the settings are +*/ +#include <configs/sunxi-common.h> + +#endif /* __CONFIG_H */
Signature · 1 line
2.0.0
PATCH v3 5/10 sunxi: Add sun4i support
Quoted 15 lines · On Mon, 9 Jun 2014 11:36:57 +0200 Hans de Goede <[email protected]> wrote:
Add support for the Allwinner A10 SoC also known as the Allwinner sun4i family, and add the Cubieboard board which uses the A10 SoC.
Compared to sun7 only the DRAM controller is a bit different:
(quoted diff) +0
-4-Controller reset bits are inverted, but only for Rev. A -Different hpcr values -No MBUS on sun4i -Various other initialization changesSigned-off-by Henrik Nordstrom <[email protected]>Signed-off-by Stefan Roese <[email protected]>Signed-off-by Oliver Schinagl <[email protected]>Signed-off-by Hans de Goede <[email protected]>Acked-by Ian Campbell <[email protected]>
Quoted 11 lines
--- arch/arm/cpu/armv7/sunxi/Makefile | 2 + arch/arm/cpu/armv7/sunxi/cpu_info.c | 7 ++++ arch/arm/cpu/armv7/sunxi/dram.c | 81 +++++++++++++++++++++++++++++++++++-- board/sunxi/Makefile | 1 + board/sunxi/dram_cubieboard.c | 31 ++++++++++++++ boards.cfg | 1 + include/configs/sun4i.h | 23 +++++++++++ 7 files changed, 143 insertions(+), 3 deletions(-) create mode 100644 board/sunxi/dram_cubieboard.c create mode 100644 include/configs/sun4i.h
This patch is piling up a lot of various loosely related changes. Isn't the addition of Cubieboard to boards.cfg kind of orthogonal to the sun4i SoC variant support? This makes cherry picking or reverting the patch unnecessarily difficult.
Signature · 2 lines
Best regards, Siarhei Siamashka
PATCH v3 6/10 sunxi: Add sun5i support
In reply to Hans de GoedeAdd support for the Allwinner A13 and A10s SoCs also know as the Allwinner sun5i family, and the A13-OLinuXinoM A13 based and r7-tv-dongle A10s based boards.
The only differences compared to the already supported sun4i and sun7i families are all in the DRAM controller initialization:
-Different hcpr values
-Different MBUS settings
-Some other small initialization changes
--- arch/arm/cpu/armv7/sunxi/Makefile | 2 ++ arch/arm/cpu/armv7/sunxi/board.c | 12 ++++++++++++ arch/arm/cpu/armv7/sunxi/cpu_info.c | 8 ++++++++ arch/arm/cpu/armv7/sunxi/dram.c | 21 +++++++++++++++++++++ board/sunxi/Makefile | 2 ++ board/sunxi/dram_a13_oli_micro.c | 32 ++++++++++++++++++++++++++++++++ board/sunxi/dram_r7dongle.c | 31 +++++++++++++++++++++++++++++++ boards.cfg | 2 ++ include/configs/sun5i.h | 23 +++++++++++++++++++++++ include/configs/sunxi-common.h | 2 ++ 10 files changed, 135 insertions(+) create mode 100644 board/sunxi/dram_a13_oli_micro.c create mode 100644 board/sunxi/dram_r7dongle.c create mode 100644 include/configs/sun5i.h
arch/arm/cpu/armv7/sunxi/Makefile +2 -0
@@ -12,6 +12,7 @@ obj-y += board.o obj-y += clock.o obj-y += pinmux.o obj-$(CONFIG_SUN4I) += clock_sun4i.o +obj-$(CONFIG_SUN5I) += clock_sun4i.o obj-$(CONFIG_SUN7I) += clock_sun4i.o ifndef CONFIG_SPL_BUILD
@@ -20,6 +21,7 @@ endif ifdef CONFIG_SPL_BUILD obj-$(CONFIG_SUN4I) += dram.o +obj-$(CONFIG_SUN5I) += dram.o obj-$(CONFIG_SUN7I) += dram.o ifdef CONFIG_SPL_FEL obj-y += start.o
arch/arm/cpu/armv7/sunxi/board.c +12 -0
@@ -47,9 +47,21 @@ u32 spl_boot_mode(void)int gpio_init (void ) { +#if CONFIG_CONS_INDEX ==1 && (defined(CONFIG_SUN4I ) || defined(CONFIG_SUN7I ))sunxi_gpio_set_cfgpin (SUNXI_GPB (22 ),SUN4I_GPB22_UART0_TX );sunxi_gpio_set_cfgpin (SUNXI_GPB (23 ),SUN4I_GPB23_UART0_RX );sunxi_gpio_set_pull (SUNXI_GPB (23 ),1 ); +#elif CONFIG_CONS_INDEX ==1 && defined(CONFIG_SUN5I ) +sunxi_gpio_set_cfgpin (SUNXI_GPB (19 ),SUN5I_GPB19_UART0_TX ); +sunxi_gpio_set_cfgpin (SUNXI_GPB (20 ),SUN5I_GPB20_UART0_RX ); +sunxi_gpio_set_pull (SUNXI_GPB (20 ),1 ); +#elif CONFIG_CONS_INDEX ==2 && defined(CONFIG_SUN5I ) +sunxi_gpio_set_cfgpin (SUNXI_GPG (3 ),SUN5I_GPG3_UART1_TX ); +sunxi_gpio_set_cfgpin (SUNXI_GPG (4 ),SUN5I_GPG4_UART1_RX ); +sunxi_gpio_set_pull (SUNXI_GPG (4 ),1 ); +#else +#error Unsupported console port number. Please fix pin mux settings in board.c +#endif return 0 ; }
arch/arm/cpu/armv7/sunxi/cpu_info.c +8 -0
@@ -15,6 +15,14 @@ int print_cpuinfo(void) {#ifdef CONFIG_SUN4I puts ("CPU: Allwinner A10 (SUN4I)\n" ); +#elif definedCONFIG_SUN5I +u32 val =readl (SUNXI_SID_BASE +0x08 ); +switch ((val >>12 ) &0xf ) { +case 0 :puts ("CPU: Allwinner A12 (SUN5I)\n" );break ; +case 3 :puts ("CPU: Allwinner A13 (SUN5I)\n" );break ; +case 7 :puts ("CPU: Allwinner A10s (SUN5I)\n" );break ; +default :puts ("CPU: Allwinner A1X (SUN5I)\n" ); + }#elif definedCONFIG_SUN7I puts ("CPU: Allwinner A20 (SUN7I)\n" );#else
arch/arm/cpu/armv7/sunxi/dram.c +21 -0
@@ -155,6 +155,16 @@ static void mctl_enable_dllx(u32 phase) } static u32 hpcr_value[32] = { +#ifdef CONFIG_SUN5I +0 ,0 ,0 ,0 , +0 ,0 ,0 ,0 , +0 ,0 ,0 ,0 , +0 ,0 ,0 ,0 , +0x1031 ,0x1031 ,0x0735 ,0x1035 , +0x1035 ,0x0731 ,0x1031 ,0 , +0x0301 ,0x0301 ,0x0301 ,0x0301 , + 0x0301, 0x0301, 0x0301, 0 +#endif #ifdef CONFIG_SUN4I0x0301 ,0x0301 ,0x0301 ,0x0301 , 0x0301, 0x0301, 0, 0,
@@ -257,9 +267,15 @@ static void mctl_setup_dram_clock(u32 clk)#if defined(CONFIG_SUN5I ) || defined(CONFIG_SUN7I )/* setup MBUS clock */ reg_val = CCM_MBUS_CTRL_GATE | +#ifdef CONFIG_SUN7I CCM_MBUS_CTRL_CLK_SRC (CCM_MBUS_CTRL_CLK_SRC_PLL6 ) |CCM_MBUS_CTRL_N (CCM_MBUS_CTRL_N_X (2 )) |CCM_MBUS_CTRL_M (CCM_MBUS_CTRL_M_X (2 )); +#else /* defined(CONFIG_SUN5I) */ +CCM_MBUS_CTRL_CLK_SRC (CCM_MBUS_CTRL_CLK_SRC_PLL5 ) | +CCM_MBUS_CTRL_N (CCM_MBUS_CTRL_N_X (1 )) | +CCM_MBUS_CTRL_M (CCM_MBUS_CTRL_M_X (2 )); +#endif writel (reg_val, &ccm->mbus_clk_cfg);#endif
@@ -468,6 +484,11 @@ unsigned long dramc_init(struct dram_para *para)/* setup DRAM relative clock */ mctl_setup_dram_clock (para->clock); +#ifdef CONFIG_SUN5I +/* Disable any pad power save control */ +writel (0 , &dram->ppwrsctl); +#endif +/* reset external DRAM */ #ifndef CONFIG_SUN7I mctl_ddr3_reset ();
board/sunxi/Makefile +2 -0
@@ -10,5 +10,7 @@ # obj-y += board.o obj-$(CONFIG_SUNXI_GMAC) += gmac.o +obj-$(CONFIG_A13_OLINUXINOM) += dram_a13_oli_micro.o obj-$(CONFIG_CUBIEBOARD) += dram_cubieboard.o obj-$(CONFIG_CUBIETRUCK) += dram_cubietruck.o +obj-$(CONFIG_R7DONGLE) += dram_r7dongle.o
board/sunxi/dram_a13_oli_micro.c new file +32 -0
@@ -0,0 +1,32 @@ +/* this file is generated, don't edit it yourself */ + +#include <common.h> +#include <asm/arch/dram.h> + +static struct dram_para dram_para = { + .clock =408 , + .type =3 , + .rank_num =1 , + .density =2048 , + .io_width =16 , + .bus_width =16 , + .cas =9 , + .zq =123 , + .odt_en =0 , + .size =256 , + .tpr0 =0x42d899b7 , + .tpr1 =0xa090 , + .tpr2 =0x22a00 , + .tpr3 =0 , + .tpr4 =0 , + .tpr5 =0 , + .emr1 =0 , + .emr2 =0x10 , + .emr3 =0 , + +}; + +unsigned long sunxi_dram_init (void ) +{ +return dramc_init (&dram_para); +}
board/sunxi/dram_r7dongle.c new file +31 -0
@@ -0,0 +1,31 @@ +/* this file is generated, don't edit it yourself */ + +#include <common.h> +#include <asm/arch/dram.h> + +static struct dram_para dram_para = { + .clock =384 , + .type =3 , + .rank_num =1 , + .density =2048 , + .io_width =8 , + .bus_width =32 , + .cas =9 , + .zq =123 , + .odt_en =0 , + .size =1024 , + .tpr0 =0x42d899b7 , + .tpr1 =0xa090 , + .tpr2 =0x22a00 , + .tpr3 =0 , + .tpr4 =0 , + .tpr5 =0 , + .emr1 =0x04 , + .emr2 =0x10 , + .emr3 =0 , +}; + +unsigned long sunxi_dram_init (void ) +{ +return dramc_init (&dram_para); +}
boards.cfg +2 -0
@@ -374,9 +374,11 @@ Active arm armv7 rmobile renesas lager Active arm armv7 s5pc1xx samsung goni s5p_goni - Przemyslaw Marczak <[email protected]> Active arm armv7 s5pc1xx samsung smdkc100 smdkc100 - Minkyu Kang <[email protected]> Active arm armv7 socfpga altera socfpga socfpga_cyclone5 - - +Active arm armv7 sunxi - sunxi A13-OLinuXinoM sun5i:A13_OLINUXINOM,SPL,CONS_INDEX=2 Hans de Goede <[email protected]> Active arm armv7 sunxi - sunxi Cubieboard sun4i:CUBIEBOARD,SPL Hans de Goede <[email protected]> Active arm armv7 sunxi - sunxi Cubietruck sun7i:CUBIETRUCK,SPL,SUNXI_GMAC,RGMII - Active arm armv7 sunxi - sunxi Cubietruck_FEL sun7i:CUBIETRUCK,SPL_FEL,SUNXI_GMAC,RGMII - +Active arm armv7 sunxi - sunxi r7-tv-dongle sun5i:R7DONGLE,SPL Hans de Goede <[email protected]> Active arm armv7 u8500 st-ericsson snowball snowball - Mathieu Poirier <[email protected]> Active arm armv7 u8500 st-ericsson u8500 u8500_href - - Active arm armv7 vf610 freescale vf610twr vf610twr vf610twr:IMX_CONFIG=board/freescale/vf610twr/imximage.cfg Alison Wang <[email protected]>
include/configs/sun5i.h new file +23 -0
@@ -0,0 +1,23 @@ +/* +* (C) Copyright 2012-2013 Henrik Nordstrom <[email protected]> +* +* Configuration settings for the Allwinner A13 (sun5i) CPU +* +* SPDX-License-Identifier: GPL-2.0+ +*/ +#ifndef __CONFIG_H +#define __CONFIG_H + +/* +* High Level Configuration Options +*/ +#define CONFIG_SUN5I /* sun5i SoC generation */ + +#define CONFIG_SYS_PROMPT "sun5i# " + +/* +* Include common sunxi configuration where most the settings are +*/ +#include <configs/sunxi-common.h> + +#endif /* __CONFIG_H */
include/configs/sunxi-common.h +2 -0
@@ -161,7 +161,9 @@#undef CONFIG_CMD_NET#undef CONFIG_CMD_NFS +#ifndef CONFIG_CONS_INDEX #define CONFIG_CONS_INDEX 1/* UART0 */ +#endif #ifdef CONFIG_SUNXI_GMAC #define CONFIG_DESIGNWARE_ETH /* GMAC can use designware driver */
Signature · 1 line
2.0.0
PATCH v3 6/10 sunxi: Add sun5i support
Quoted 16 lines · On Mon, 9 Jun 2014 11:36:58 +0200 Hans de Goede <[email protected]> wrote:
Add support for the Allwinner A13 and A10s SoCs also know as the Allwinner sun5i family, and the A13-OLinuXinoM A13 based and r7-tv-dongle A10s based boards.
The only differences compared to the already supported sun4i and sun7i families are all in the DRAM controller initialization:
(quoted diff) +0
-3-Different hcpr values -Different MBUS settings -Some other small initialization changesSigned-off-by Henrik Nordstrom <[email protected]>Signed-off-by Stefan Roese <[email protected]>Signed-off-by Oliver Schinagl <[email protected]>Signed-off-by Hans de Goede <[email protected]>Acked-by Ian Campbell <[email protected]>
Quoted 15 lines
--- arch/arm/cpu/armv7/sunxi/Makefile | 2 ++ arch/arm/cpu/armv7/sunxi/board.c | 12 ++++++++++++ arch/arm/cpu/armv7/sunxi/cpu_info.c | 8 ++++++++ arch/arm/cpu/armv7/sunxi/dram.c | 21 +++++++++++++++++++++ board/sunxi/Makefile | 2 ++ board/sunxi/dram_a13_oli_micro.c | 32 ++++++++++++++++++++++++++++++++ board/sunxi/dram_r7dongle.c | 31 +++++++++++++++++++++++++++++++ boards.cfg | 2 ++ include/configs/sun5i.h | 23 +++++++++++++++++++++++ include/configs/sunxi-common.h | 2 ++ 10 files changed, 135 insertions(+) create mode 100644 board/sunxi/dram_a13_oli_micro.c create mode 100644 board/sunxi/dram_r7dongle.c create mode 100644 include/configs/sun5i.h
Even if there is a valid reason to bundle the addition of some example sun5i based board to boards.cfg with the changes needed for sun5i SoC variant, why is it *two* boards this time?
Signature · 2 lines
Best regards, Siarhei Siamashka
PATCH v3 6/10 sunxi: Add sun5i support
Hi,
Quoted 29 lines · Siarhei Siamashka
Quoted 26 lines · On Mon, 9 Jun 2014 11:36:58 +0200 Hans de Goede <[email protected]> wrote:
Add support for the Allwinner A13 and A10s SoCs also know as the Allwinner sun5i family, and the A13-OLinuXinoM A13 based and r7-tv-dongle A10s based boards.
The only differences compared to the already supported sun4i and sun7i families are all in the DRAM controller initialization:
(quoted diff) +0
-3-Different hcpr values -Different MBUS settings -Some other small initialization changesSigned-off-by Henrik Nordstrom <[email protected]>Signed-off-by Stefan Roese <[email protected]>Signed-off-by Oliver Schinagl <[email protected]>Signed-off-by Hans de Goede <[email protected]>Acked-by Ian Campbell <[email protected]>--- arch/arm/cpu/armv7/sunxi/Makefile | 2 ++ arch/arm/cpu/armv7/sunxi/board.c | 12 ++++++++++++ arch/arm/cpu/armv7/sunxi/cpu_info.c | 8 ++++++++ arch/arm/cpu/armv7/sunxi/dram.c | 21 +++++++++++++++++++++ board/sunxi/Makefile | 2 ++ board/sunxi/dram_a13_oli_micro.c | 32 ++++++++++++++++++++++++++++++++ board/sunxi/dram_r7dongle.c | 31 +++++++++++++++++++++++++++++++ boards.cfg | 2 ++ include/configs/sun5i.h | 23 +++++++++++++++++++++++
Quoted 8 lines
Quoted 5 lines
include/configs/sunxi-common.h | 2 ++ 10 files changed, 135 insertions(+)create mode 100644
board/sunxi/dram_a13_oli_micro.ccreate mode 100644board/sunxi/dram_r7dongle.ccreate mode 100644include/configs/sun5i.hEven if there is a valid reason to bundle the addition of some example sun5i based board to boards.cfg
To address this first, I believe that it is a good idea when adding functionality to also enable it, otherwise one is just adding dead code.
Quoted 2 lines
with the changes needed for sun5i SoC
variant, why is it *two* boards this time?
Because there are 2 sun5i variants A13 and A10s
Regards,
Hans
PATCH v3 7/10 net: Rename and cleanup sunxi (Allwinner) emac driver
In reply to Hans de GoedeFrom: Stefan Roese <[email protected]>
There have been 3 versions of the sunxi_emac support patch during its development. Somehow version 2 ended up in upstream u-boot where as the u-boot-sunxi git repo got version 3.
This bumps the version in upstream u-boot to version 3 of the patch:
- Initialize MII clock earlier so mii access to allow independent use
- Name change from WEMAC to EMAC to match mainline kernel & chip manual
- Cosmetic code cleanup
--- drivers/net/Makefile | 2 +- drivers/net/sunxi_emac.c | 521 +++++++++++++++++++++++++++++++++++++++++++++ drivers/net/sunxi_wemac.c | 525 ---------------------------------------------- include/netdev.h | 2 +- 4 files changed, 523 insertions(+), 527 deletions(-) create mode 100644 drivers/net/sunxi_emac.c delete mode 100644 drivers/net/sunxi_wemac.c
drivers/net/Makefile +1 -1
@@ -20,6 +20,7 @@ obj-$(CONFIG_DNET) += dnet.o obj-$(CONFIG_E1000) += e1000.o obj-$(CONFIG_E1000_SPI) += e1000_spi.o obj-$(CONFIG_EEPRO100) += eepro100.o +obj-$(CONFIG_SUNXI_EMAC) += sunxi_emac.o obj-$(CONFIG_ENC28J60) += enc28j60.o obj-$(CONFIG_EP93XX) += ep93xx_eth.o obj-$(CONFIG_ETHOC) += ethoc.o
@@ -51,7 +52,6 @@ obj-$(CONFIG_RTL8169) += rtl8169.o obj-$(CONFIG_SH_ETHER) += sh_eth.o obj-$(CONFIG_SMC91111) += smc91111.o obj-$(CONFIG_SMC911X) += smc911x.o -obj-$(CONFIG_SUNXI_WEMAC) += sunxi_wemac.o obj-$(CONFIG_DRIVER_TI_EMAC) += davinci_emac.o obj-$(CONFIG_TSEC_ENET) += tsec.o fsl_mdio.o obj-$(CONFIG_DRIVER_TI_CPSW) += cpsw.o
drivers/net/sunxi_emac.c new file +521 -0
521 lines not on this page · raw message
drivers/net/sunxi_wemac.c deleted +0 -525
525 lines not on this page · raw message
include/netdev.h +1 -1
@@ -78,8 +78,8 @@ int sh_eth_initialize(bd_t *bis);int skge_initialize (bd_t *bis);int smc91111_initialize (u8 dev_num,int base_addr);int smc911x_initialize (u8 dev_num,int base_addr); +int sunxi_emac_initialize (bd_t *bis);int sunxi_gmac_initialize (bd_t *bis); -int sunxi_wemac_initialize (bd_t *bis);int tsi108_eth_initialize (bd_t *bis);int uec_standard_init (bd_t *bis);int uli526x_initialize (bd_t *bis);
Signature · 1 line
2.0.0
PATCH v3 7/10 net: Rename and cleanup sunxi (Allwinner) emac driver
Quoted 11 lines · On Mon, 9 Jun 2014 11:36:59 +0200 Hans de Goede <[email protected]> wrote:
From: Stefan Roese <[email protected]>
There have been 3 versions of the
sunxi_emacsupport patch during its development. Somehow version 2 ended up in upstream u-boot where as the u-boot-sunxi git repo got version 3.This bumps the version in upstream u-boot to version 3 of the patch:
- Initialize MII clock earlier so mii access to allow independent use
- Name change from WEMAC to EMAC to match mainline kernel & chip manual
- Cosmetic code cleanup
Quoted 5 lines
Signed-off-by Stefan Roese <[email protected]>Signed-off-by Henrik Nordstrom <[email protected]>Signed-off-by Oliver Schinagl <[email protected]>Signed-off-by Hans de Goede <[email protected]>Acked-by Ian Campbell <[email protected]>
Shouldn't the cosmetic and functional changes be normally split into separate patches? Indeed, it looks like the move of
+ /* Set MII clock */
+ clrsetbits_le32(®s->mac_mcfg, 0xf << 2, 0xd << 2);
is the only functional change in this rather large patch.
And could you please elaborate on
Quoted 1 line
- Initialize MII clock earlier so mii access to allow independent use
was this causing any user visible problems?
Signature · 2 lines
Best regards, Siarhei Siamashka
PATCH v3 7/10 net: Rename and cleanup sunxi (Allwinner) emac driver
Hi,
Quoted 26 lines · Siarhei Siamashka
Quoted 11 lines · On Mon, 9 Jun 2014 11:36:59 +0200 Hans de Goede <[email protected]> wrote:
From: Stefan Roese <[email protected]>
There have been 3 versions of the
sunxi_emacsupport patch during its development. Somehow version 2 ended up in upstream u-boot where as the u-boot-sunxi git repo got version 3.This bumps the version in upstream u-boot to version 3 of the patch:
- Initialize MII clock earlier so mii access to allow independent use
- Name change from WEMAC to EMAC to match mainline kernel & chip manual
- Cosmetic code cleanupQuoted 5 lines
Signed-off-by Stefan Roese <[email protected]>Signed-off-by Henrik Nordstrom <[email protected]>Signed-off-by Oliver Schinagl <[email protected]>Signed-off-by Hans de Goede <[email protected]>Acked-by Ian Campbell <[email protected]>Shouldn't the cosmetic and functional changes be normally split into separate patches? Indeed, it looks like the move of
drivers/net/sunxi_emac.c new file +2
-0+/* Set MII clock */ +clrsetbits_le32 (®s->mac_mcfg,0xf <<2 ,0xd <<2 );
Quoted 7 lines
is the only functional change in this rather large patch.
And could you please elaborate on
Quoted 1 line
- Initialize MII clock earlier so mii access to allow independent use
was this causing any user visible problems?
I'm not the author if the patch, so you will need to ask Stefan. Note though that the code after this patch is the code which we've been using in the linux-sunxi-u-boot for as long as I can remember, and the code which went upstream was never enabled / used as is.
Regards,
Hans
PATCH v3 7/10 net: Rename and cleanup sunxi (Allwinner) emac driver
Hi,
Quoted 31 lines · Hans de Goede
Hi,
Quoted 28 lines · Siarhei Siamashka
Quoted 11 lines · On Mon, 9 Jun 2014 11:36:59 +0200 Hans de Goede <[email protected]> wrote:
From: Stefan Roese <[email protected]>
There have been 3 versions of the
sunxi_emacsupport patch during its development. Somehow version 2 ended up in upstream u-boot where as the u-boot-sunxi git repo got version 3.This bumps the version in upstream u-boot to version 3 of the patch:
- Initialize MII clock earlier so mii access to allow independent use
- Name change from WEMAC to EMAC to match mainline kernel & chip manual
- Cosmetic code cleanupQuoted 5 lines
Signed-off-by Stefan Roese <[email protected]>Signed-off-by Henrik Nordstrom <[email protected]>Signed-off-by Oliver Schinagl <[email protected]>Signed-off-by Hans de Goede <[email protected]>Acked-by Ian Campbell <[email protected]>Shouldn't the cosmetic and functional changes be normally split into separate patches? Indeed, it looks like the move of
drivers/net/sunxi_emac.c new file +2
-0+/* Set MII clock */ +clrsetbits_le32 (®s->mac_mcfg,0xf <<2 ,0xd <<2 );is the only functional change in this rather large patch.
Quoted 7 lines
Quoted 5 lines
And could you please elaborate on
Quoted 1 line
- Initialize MII clock earlier so mii access to allow independent use
was this causing any user visible problems?
I'm not the author if the patch, so you will need to ask Stefan.
Yes. Sorry, but this was so long ago and I really can't remember the details here. I suggest to improve the code with follow-up patches if needed.
Thanks,
Stefan
PATCH v3 8/10 sunxi: Add emac glue, enable emac on the cubieboard
In reply to Hans de Goede--- arch/arm/cpu/armv7/sunxi/board.c | 8 ++++++++ boards.cfg | 2 +- include/configs/sunxi-common.h | 5 +++++ 3 files changed, 14 insertions(+), 1 deletion(-)
arch/arm/cpu/armv7/sunxi/board.c +8 -0
@@ -117,6 +117,14 @@ int cpu_eth_init(bd_t *bis) {int rc; +#ifdef CONFIG_SUNXI_EMAC + rc =sunxi_emac_initialize (bis); +if (rc <0 ) { +printf ("sunxi: failed to initialize emac\n" ); +return rc; + } +#endif +#ifdef CONFIG_SUNXI_GMAC rc =sunxi_gmac_initialize (bis);if (rc <0 ) {
boards.cfg +1 -1
@@ -375,7 +375,7 @@ Active arm armv7 s5pc1xx samsung goni Active arm armv7 s5pc1xx samsung smdkc100 smdkc100 - Minkyu Kang <[email protected]> Active arm armv7 socfpga altera socfpga socfpga_cyclone5 - - Active arm armv7 sunxi - sunxi A13-OLinuXinoM sun5i:A13_OLINUXINOM,SPL,CONS_INDEX=2 Hans de Goede <[email protected]> -Active arm armv7 sunxi - sunxi Cubieboard sun4i:CUBIEBOARD,SPL Hans de Goede <[email protected]> +Active arm armv7 sunxi - sunxi Cubieboard sun4i:CUBIEBOARD,SPL,SUNXI_EMAC Hans de Goede <[email protected]> Active arm armv7 sunxi - sunxi Cubietruck sun7i:CUBIETRUCK,SPL,SUNXI_GMAC,RGMII - Active arm armv7 sunxi - sunxi Cubietruck_FEL sun7i:CUBIETRUCK,SPL_FEL,SUNXI_GMAC,RGMII - Active arm armv7 sunxi - sunxi r7-tv-dongle sun5i:R7DONGLE,SPL Hans de Goede <[email protected]>
include/configs/sunxi-common.h +5 -0
@@ -165,6 +165,11 @@#define CONFIG_CONS_INDEX 1/* UART0 */ #endif +/* Ethernet support */ +#ifdef CONFIG_SUNXI_EMAC +#define CONFIG_MII /* MII PHY management */ +#endif +#ifdef CONFIG_SUNXI_GMAC #define CONFIG_DESIGNWARE_ETH /* GMAC can use designware driver */ #define CONFIG_DW_AUTONEG
Signature · 1 line
2.0.0
PATCH v3 8/10 sunxi: Add emac glue, enable emac on the cubieboard
Quoted 7 lines · On Mon, 9 Jun 2014 11:37:00 +0200 Hans de Goede <[email protected]> wrote:
Signed-off-by Hans de Goede <[email protected]>Acked-by Ian Campbell <[email protected]>--- arch/arm/cpu/armv7/sunxi/board.c | 8 ++++++++ boards.cfg | 2 +- include/configs/sunxi-common.h | 5 +++++ 3 files changed, 14 insertions(+), 1 deletion(-)
Again, this may be not a valid reason to complain (sorry if this is the case), but combining generic sunxi code changes in sunxi/board.c with the individual board support tweaks in boards.cfg is rather cherry-pick/revert unfriendly.
Signature · 2 lines
Best regards, Siarhei Siamashka
PATCH v3 9/10 sunxi: Add support for using MII phy-s with the GMAC nic
In reply to Hans de GoedeFrom: Chen-Yu Tsai <[email protected]>
Many A20 boards (ie Cubieboard2, A20-OLinuXino_MICRO) use an 100 Mbit MII phy together with the GMAC nic found in the A20 SoC, add support for this (this will get used when we add these boards in a later patch).
--- board/sunxi/gmac.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
board/sunxi/gmac.c +11 -0
@@ -16,17 +16,28 @@ int sunxi_gmac_initialize(bd_t *bis)setbits_le32 (&ccm->ahb_gate1,0x1 <<AHB_GATE_OFFSET_GMAC );/* Set MII clock */ +#ifdef CONFIG_RGMII setbits_le32 (&ccm->gmac_clk_cfg,CCM_GMAC_CTRL_TX_CLK_SRC_INT_RGMII |CCM_GMAC_CTRL_GPIT_RGMII ); +#else +setbits_le32 (&ccm->gmac_clk_cfg,CCM_GMAC_CTRL_TX_CLK_SRC_MII | +CCM_GMAC_CTRL_GPIT_MII ); +#endif /* Configure pin mux settings for GMAC */ for (pin =SUNXI_GPA (0 ); pin <=SUNXI_GPA (16 ); pin++) { +#ifdef CONFIG_RGMII /* skip unused pins in RGMII mode */ if (pin ==SUNXI_GPA (9 ) || pin ==SUNXI_GPA (14 ))continue ; +#endif sunxi_gpio_set_cfgpin (pin,SUN7I_GPA0_GMAC );sunxi_gpio_set_drv (pin,3 ); } +#ifdef CONFIG_RGMII return designware_initialize (SUNXI_GMAC_BASE ,PHY_INTERFACE_MODE_RGMII ); +#else +return designware_initialize (SUNXI_GMAC_BASE ,PHY_INTERFACE_MODE_MII ); +#endif }
Signature · 1 line
2.0.0
PATCH v3 9/10 sunxi: Add support for using MII phy-s with the GMAC nic
Quoted 9 lines · On Mon, 9 Jun 2014 11:37:01 +0200 Hans de Goede <[email protected]> wrote:
From: Chen-Yu Tsai <[email protected]>
Many A20 boards (ie Cubieboard2, A20-OLinuXino_MICRO) use an 100 Mbit MII phy together with the GMAC nic found in the A20 SoC, add support for this (this will get used when we add these boards in a later patch).
Signed-off-by Chen-Yu Tsai <[email protected]>Signed-off-by Hans de Goede <[email protected]>Acked-by Ian Campbell <[email protected]>
Signature · 2 lines
Best regards, Siarhei Siamashka
PATCH v3 10/10 sunxi: Add Ian Campbell and Hans de Goede as cubietruck board-maintainers
In reply to Hans de Goede--- boards.cfg | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
boards.cfg +2 -2
@@ -376,8 +376,8 @@ Active arm armv7 s5pc1xx samsung smdkc100 Active arm armv7 socfpga altera socfpga socfpga_cyclone5 - - Active arm armv7 sunxi - sunxi A13-OLinuXinoM sun5i:A13_OLINUXINOM,SPL,CONS_INDEX=2 Hans de Goede <[email protected]> Active arm armv7 sunxi - sunxi Cubieboard sun4i:CUBIEBOARD,SPL,SUNXI_EMAC Hans de Goede <[email protected]> -Active arm armv7 sunxi - sunxi Cubietruck sun7i:CUBIETRUCK,SPL,SUNXI_GMAC,RGMII - -Active arm armv7 sunxi - sunxi Cubietruck_FEL sun7i:CUBIETRUCK,SPL_FEL,SUNXI_GMAC,RGMII - +Active arm armv7 sunxi - sunxi Cubietruck sun7i:CUBIETRUCK,SPL,SUNXI_GMAC,RGMII Ian Campbell <[email protected]>:Hans de Goede <[email protected]> +Active arm armv7 sunxi - sunxi Cubietruck_FEL sun7i:CUBIETRUCK,SPL_FEL,SUNXI_GMAC,RGMII Ian Campbell <[email protected]>:Hans de Goede <[email protected]> Active arm armv7 sunxi - sunxi r7-tv-dongle sun5i:R7DONGLE,SPL Hans de Goede <[email protected]> Active arm armv7 u8500 st-ericsson snowball snowball - Mathieu Poirier <[email protected]> Active arm armv7 u8500 st-ericsson u8500 u8500_href - -
Signature · 1 line
2.0.0
v3 cover sunxi: Bug fixes, sun4i and sun5i support and network improvements
In reply to Hans de GoedeHi Albert,
Any comments on these sunxi series from Hans and myself?
Thanks,
Ian.
Quoted 29 lines · Hans de Goede
Hi All,
Here is v2 of my patch series to be applied on top of Ian's recently merged basic sun7i support.
This patch series begins with a few bug fixes found while working on preparing the rest of the series, adds sun4i and sun5i support and rounds things of with some networking fixes / additions.
Changes since v1:
(quoted diff) +0
-4-Improved various commit messages -Various small typo fixes -Cleaned up the axp209 and axp152 drivers -Added Acked-by: Ian Campbell ... to the patches which got acked by IanChanges since v2:
(quoted diff) +0
-3-Dropped the i2c + pmic support patches as they need more work -Split out the boards.cfg Cubietruck maintainer field changes from the axp209 support patch into its own patch -Added Acked-by: Ian Campbell ... to the patches which got acked by IanRegards,
Hans
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
v3 cover sunxi: Bug fixes, sun4i and sun5i support and network improvements
(re-adding Hans whose CC I seem to have dropped somehow, sorry)
Quoted 3 lines · Ian Campbell
Hi Albert,
Any comments on these sunxi series from Hans and myself?
I wonder if Hans and I should be applying for a u-boot-sunxi.git custodian tree[0]?
Ian.
[0] http://www.denx.de/wiki/U-Boot/CustodianGitTrees
Quoted 41 lines
Thanks,
Ian.Quoted 21 lines · Hans de Goede
Hi All,
Here is v2 of my patch series to be applied on top of Ian's recently merged basic sun7i support.
This patch series begins with a few bug fixes found while working on preparing the rest of the series, adds sun4i and sun5i support and rounds things of with some networking fixes / additions.
Changes since v1:
(quoted diff) +0
-4-Improved various commit messages -Various small typo fixes -Cleaned up the axp209 and axp152 drivers -Added Acked-by: Ian Campbell ... to the patches which got acked by IanChanges since v2:
(quoted diff) +0
-3-Dropped the i2c + pmic support patches as they need more work -Split out the boards.cfg Cubietruck maintainer field changes from the axp209 support patch into its own patch -Added Acked-by: Ian Campbell ... to the patches which got acked by IanQuoted 8 lines
Regards,
Hans
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
v3 cover sunxi: Bug fixes, sun4i and sun5i support and network improvements
Quoted 9 lines · Ian Campbell
(re-adding Hans whose CC I seem to have dropped somehow, sorry)
Quoted 3 lines · Ian Campbell
Hi Albert,
Any comments on these sunxi series from Hans and myself?
I wonder if Hans and I should be applying for a u-boot-sunxi.git custodian tree[0]?
Yes, I'm all for it. This would definitely help to speed up the process and reduce the load on other custodians.
Tom, Albert, what do you think?
Thanks,
Stefan
v3 cover sunxi: Bug fixes, sun4i and sun5i support and network improvements
In reply to Hans de GoedeQuoted 2 lines · Hans de Goede
Here is v2 of my patch series to be applied on top of Ian's recently merged basic sun7i support.
For the A13-OLinuXinoM and r7-tv-dongle with this series I'm seeing:
arch/arm/cpu/armv7/sunxi/board.c: In function ?cpu_eth_init?:arch/arm/cpu/armv7/sunxi/board.c:118:6: warning: unused variable ?rc? [-Wunused-variable]
int rc;
^because they both have neither EMAC or GMAC. This resolves it:
8<------------------
v3 cover sunxi: Bug fixes, sun4i and sun5i support and network improvements
Hi Ian,
Slightly off-topic, but... When you provide some code excerpt, you should make sure it doesn't look like a git patch, because if it does, then our Patchwork, which reads the list, will think it is actually a patch submission:
http://patchwork.ozlabs.org/patch/367391/
Amicalement,
Albert.
Quoted 39 lines · Ian Campbell
Quoted 2 lines · Hans de Goede
Here is v2 of my patch series to be applied on top of Ian's recently merged basic sun7i support.
For the A13-OLinuXinoM and r7-tv-dongle with this series I'm seeing:
arch/arm/cpu/armv7/sunxi/board.c: In function ?cpu_eth_init?:arch/arm/cpu/armv7/sunxi/board.c:118:6: warning: unused variable ?rc? [-Wunused-variable]int rc; ^because they both have neither EMAC or GMAC. This resolves it:
8<------------------
From
4eed69132de51d07586e7b070eda72297825a674Mon Sep 17 00:00:00 2001
From: Ian Campbell <[email protected]>
Date: Sun, 6 Jul 2014 20:03:20 +0100
Subject: [PATCH] sunxi: Avoid unused variable warningSigned-off-by Ian Campbell <[email protected]>--- arch/arm/cpu/armv7/sunxi/board.c | 2 ++ 1 file changed, 2 insertions(+)arch/arm/cpu/armv7/sunxi/board.c +2
-0@@ -115,7 +115,9 @@ void enable_caches(void)*/ int cpu_eth_init (bd_t *bis) { +#if defined(CONFIG_SUNXI_EMAC ) || defined(CONFIG_SUNXI_GMAC )int rc; +#endif #ifdef CONFIG_SUNXI_EMAC rc =sunxi_emac_initialize (bis);
v3 cover sunxi: Bug fixes, sun4i and sun5i support and network improvements
Quoted 6 lines · Albert ARIBAUD
Hi Ian,
Slightly off-topic, but... When you provide some code excerpt, you should make sure it doesn't look like a git patch, because if it does, then our Patchwork, which reads the list, will think it is actually a patch submission:
I suppose this was a submission, although I was mostly planning to short circuit it straight into the appropriate branch.
How much do I need to corrupt something before patchwork will ignore it?
Ian.
v3 cover sunxi: Bug fixes, sun4i and sun5i support and network improvements
Hi Ian,
Quoted 10 lines · Ian Campbell
Quoted 6 lines · Albert ARIBAUD
Hi Ian,
Slightly off-topic, but... When you provide some code excerpt, you should make sure it doesn't look like a git patch, because if it does, then our Patchwork, which reads the list, will think it is actually a patch submission:
I suppose this was a submission, although I was mostly planning to short circuit it straight into the appropriate branch.
Hmm, short-circuiting a code change is risky -- all U-Boot code should go through the list and be reviewed.
If your post was a submission, then it should be the pure result of a git format-patch or of a patman command.
Quoted 1 line
How much do I need to corrupt something before patchwork will ignore it?
Basically, if you can (try to) 'git apply' the post, chances are PW will consider it a submission.
Quoted 1 line
Ian.
Amicalement,
Signature · 1 line
Albert.
v3 cover sunxi: Bug fixes, sun4i and sun5i support and network improvements
Quoted 13 lines · Albert ARIBAUD
Hi Ian,
Quoted 8 lines · Ian Campbell
Quoted 6 lines · Albert ARIBAUD
Hi Ian,
Slightly off-topic, but... When you provide some code excerpt, you should make sure it doesn't look like a git patch, because if it does, then our Patchwork, which reads the list, will think it is actually a patch submission:
Quoted 5 lines
Quoted 2 lines
I suppose this was a submission, although I was mostly planning to short circuit it straight into the appropriate branch.
Hmm, short-circuiting a code change is risky -- all U-Boot code should go through the list and be reviewed.
Oh, I didn't mean to suggest skipping all that good stuff, just that the patch is already in a local branch ready to go when it is acked so I don't need to fetch it from patchwork.
Getting it reviewed was why I posted it.
Quoted 2 lines
If your post was a submission, then it should be the pure result of a git format-patch or of a patman command.
The thing I posted was the output of git format-patch.
Quoted 4 lines
Quoted 1 line
How much do I need to corrupt something before patchwork will ignore it?
Basically, if you can (try to) 'git apply' the post, chances are PW will consider it a submission.
I think that is what I wanted on this occasion.
Ian.
v3 cover sunxi: Bug fixes, sun4i and sun5i support and network improvements
Dear Ian Campbell,
Quoted 4 lines · In message <[email protected]> you wrote:
Oh, I didn't mean to suggest skipping all that good stuff, just that the patch is already in a local branch ready to go when it is acked so I don't need to fetch it from patchwork.
It is a very good thiong to fetch patches from PW, as this will allow you to automatically also fetch all ACKs you get from other people. If you don't use PW, you will have to track the mailing list and insert all Acked-by: and Tested-By: etc. manually. I don;t think you want to do that.
Best regards,
Wolfgang Denk
Signature · 5 lines
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: wd at denx.de The one who says it cannot be done should never interrupt the one who is doing it.
v3 cover sunxi: Bug fixes, sun4i and sun5i support and network improvements
In reply to Ian CampbellHi Ian,
Quoted 30 lines · Ian Campbell
Quoted 2 lines · Hans de Goede
Here is v2 of my patch series to be applied on top of Ian's recently merged basic sun7i support.
For the A13-OLinuXinoM and r7-tv-dongle with this series I'm seeing:
arch/arm/cpu/armv7/sunxi/board.c: In function ?cpu_eth_init?:arch/arm/cpu/armv7/sunxi/board.c:118:6: warning: unused variable ?rc? [-Wunused-variable]int rc; ^because they both have neither EMAC or GMAC. This resolves it:
8<------------------
From
4eed69132de51d07586e7b070eda72297825a674Mon Sep 17 00:00:00 2001
From: Ian Campbell <[email protected]>
Date: Sun, 6 Jul 2014 20:03:20 +0100
Subject: [PATCH] sunxi: Avoid unused variable warningSigned-off-by Ian Campbell <[email protected]>--- arch/arm/cpu/armv7/sunxi/board.c | 2 ++ 1 file changed, 2 insertions(+)arch/arm/cpu/armv7/sunxi/board.c +0
-0
arch/arm/cpu/armv7/sunxi/board.c void enable_caches(void) · line 123
Quoted 9 lines
arch/arm/cpu/armv7/sunxi/board.c +2
-0@@ -115,7 +115,9 @@ void enable_caches(void)*/ int cpu_eth_init (bd_t *bis) { +#if defined(CONFIG_SUNXI_EMAC ) || defined(CONFIG_SUNXI_GMAC )int rc; +#endif #ifdef CONFIG_SUNXI_EMAC rc =sunxi_emac_initialize (bis);
AFAIK we will never define both EMAC and GMAC for the same board, so IMHO a better fix would be to change this line:
rc = sunxi_emac_initialize(bis);
to:
int rc = sunxi_emac_initialize(bis);
And the same for gmac.
Regards,
Hans
v3 cover sunxi: Bug fixes, sun4i and sun5i support and network improvements
Quoted 1 line · Hans de Goede
AFAIK we will never define both EMAC and GMAC for the same board,
If we are sure of this (and I suspect this is the case, since IIRC they share some pins) then I agree with your suggestion.
Quoted 18 lines
so IMHO a better fix would be to change this line:
rc = sunxi_emac_initialize(bis);to:
int rc = sunxi_emac_initialize(bis);And the same for gmac.
Regards,
Hans
v3 cover sunxi: Bug fixes, sun4i and sun5i support and network improvements
Quoted 13 lines · Ian Campbell
Quoted 1 line · Hans de Goede
AFAIK we will never define both EMAC and GMAC for the same board,
If we are sure of this (and I suspect this is the case, since IIRC they share some pins) then I agree with your suggestion.
Quoted 7 lines
so IMHO a better fix would be to change this line:
rc = sunxi_emac_initialize(bis);to:
int rc = sunxi_emac_initialize(bis);
That's not how we like things to look however when we can help it. Just toss a __maybe_unused in front of the declaration (and make sure we have <linux/compiler.h> included.
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140707/5ddad13c/attachment.pgp>
v3 cover sunxi: Bug fixes, sun4i and sun5i support and network improvements
Quoted 3 lines · Tom Rini
That's not how we like things to look however when we can help it. Just toss a
__maybe_unusedin front of the declaration (and make sure we have <linux/compiler.h> included.
OK. How about the following?
Hans, BTW, I spotted this issue with:
CROSS_COMPILE=arm-linux-gnueabihf- ./MAKEALL -s sunxi
which is a very useful invocation indeed!
8<-------------------
v3 cover sunxi: Bug fixes, sun4i and sun5i support and network improvements
Quoted 10 lines · Ian Campbell
Quoted 3 lines · Tom Rini
That's not how we like things to look however when we can help it. Just toss a
__maybe_unusedin front of the declaration (and make sure we have <linux/compiler.h> included.OK. How about the following?
Hans, BTW, I spotted this issue with:
CROSS_COMPILE=arm-linux-gnueabihf- ./MAKEALL -s sunxi
which is a very useful invocation indeed!
FWIW, you might want to run -a arm from time to time since there's some shared drivers between sunxi and others.
Quoted 9 lines
From
5e0659b772380114a9e86624aefd1dcb09a90bd9Mon Sep 17 00:00:00 2001
From: Ian Campbell <[email protected]>
Date: Sun, 6 Jul 2014 20:03:20 +0100
Subject: [PATCH] sunxi: Avoid unused variable warning.Mark rc as
__maybe_unusedsince it is infact unused on systems with neither EMAC nor GMAC.Signed-off-by Ian Campbell <[email protected]>
Thanks.
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140707/57d17129/attachment.pgp>
v3 cover sunxi: Bug fixes, sun4i and sun5i support and network improvements
Quoted 6 lines · Tom Rini
Quoted 5 lines · Ian Campbell
Quoted 3 lines · Tom Rini
That's not how we like things to look however when we can help it. Just toss a
__maybe_unusedin front of the declaration (and make sure we have <linux/compiler.h> included.
Quoted 8 lines
Quoted 5 lines
OK. How about the following?
Hans, BTW, I spotted this issue with:
CROSS_COMPILE=arm-linux-gnueabihf- ./MAKEALL -s sunxi
which is a very useful invocation indeed!FWIW, you might want to run -a arm from time to time since there's some shared drivers between sunxi and others.
Ack.
I don't suppose there is a bot somewhere which provides baseline results for comparison?
Quoted 5 lines
Quoted 5 lines
From
5e0659b772380114a9e86624aefd1dcb09a90bd9Mon Sep 17 00:00:00 2001
From: Ian Campbell <[email protected]>
Date: Sun, 6 Jul 2014 20:03:20 +0100
Subject: [PATCH] sunxi: Avoid unused variable warning.
Quoted 8 lines
Quoted 4 lines
Mark rc as
__maybe_unusedsince it is infact unused on systems with neither EMAC nor GMAC.Signed-off-by Ian Campbell <[email protected]>Acked-by Tom Rini <[email protected]>Thanks.
Thank you.
Ian.
v3 cover sunxi: Bug fixes, sun4i and sun5i support and network improvements
Quoted 13 lines · Ian Campbell
Quoted 12 lines · Tom Rini
Quoted 10 lines · Ian Campbell
Quoted 3 lines · Tom Rini
That's not how we like things to look however when we can help it. Just toss a
__maybe_unusedin front of the declaration (and make sure we have <linux/compiler.h> included.OK. How about the following?
Hans, BTW, I spotted this issue with:
CROSS_COMPILE=arm-linux-gnueabihf- ./MAKEALL -s sunxi
which is a very useful invocation indeed!
Quoted 7 lines
Quoted 2 lines
FWIW, you might want to run -a arm from time to time since there's some shared drivers between sunxi and others.
Ack.
I don't suppose there is a bot somewhere which provides baseline results for comparison?
Marek, is your builder still going? Having more CI stuff available widely is something I'd like but not far along.
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140708/8468e317/attachment.pgp>
v3 cover sunxi: Bug fixes, sun4i and sun5i support and network improvements
In reply to Ian CampbellHi,
Quoted 10 lines · Ian Campbell
Quoted 3 lines · Tom Rini
That's not how we like things to look however when we can help it. Just toss a
__maybe_unusedin front of the declaration (and make sure we have <linux/compiler.h> included.OK. How about the following?
Hans, BTW, I spotted this issue with:
CROSS_COMPILE=arm-linux-gnueabihf- ./MAKEALL -s sunxi
which is a very useful invocation indeed!
Indeed, I've saved it for future reference.
Regards,
Hans
Quoted 39 lines
8<-------------------
From
5e0659b772380114a9e86624aefd1dcb09a90bd9Mon Sep 17 00:00:00 2001
From: Ian Campbell <[email protected]>
Date: Sun, 6 Jul 2014 20:03:20 +0100
Subject: [PATCH] sunxi: Avoid unused variable warning.Mark rc as
__maybe_unusedsince it is infact unused on systems with neither EMAC nor GMAC.Signed-off-by Ian Campbell <[email protected]>--- arch/arm/cpu/armv7/sunxi/board.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)arch/arm/cpu/armv7/sunxi/board.c +3
-1@@ -24,6 +24,8 @@#include <asm/arch/sys_proto.h> #include <asm/arch/timer.h> +#include <linux/compiler.h> +#ifdef CONFIG_SPL_BUILD /* Pointer to the global data structure for SPL */ DECLARE_GLOBAL_DATA_PTR ;@@ -115,7 +117,7 @@ void enable_caches(void)*/ int cpu_eth_init (bd_t *bis) { -int rc; +__maybe_unused int rc;#ifdef CONFIG_SUNXI_EMAC rc =sunxi_emac_initialize (bis);
v3 cover sunxi: Bug fixes, sun4i and sun5i support and network improvements
In reply to Hans de GoedeQuoted 1 line · Hans de Goede
adds sun4i and sun5i support
Does this series omit FEL mode support or did you just not include it for the new boards?
I think in general we want a _FEL variant for every board except the minority which don't have an OTG port etc.
Ian.
v3 cover sunxi: Bug fixes, sun4i and sun5i support and network improvements
Hi,
Quoted 5 lines · Ian Campbell
Quoted 1 line · Hans de Goede
adds sun4i and sun5i support
Does this series omit FEL mode support or did you just not include it for the new boards?
I just did not include it.
Quoted 2 lines
I think in general we want a
_FELvariant for every board except the minority which don't have an OTG port etc.
I'm not sold on this idea. Normal users (and distros) will never use the FEL variants, and a developer needing a FEL build can just as easily edit boards.cfg, instead of us having 2 lines there for each and every sunxi board (of which there are *a lot*.
Regards,
Hans
v3 cover sunxi: Bug fixes, sun4i and sun5i support and network improvements
Quoted 11 lines · Hans de Goede
Hi,
Quoted 5 lines · Ian Campbell
Quoted 1 line · Hans de Goede
adds sun4i and sun5i support
Does this series omit FEL mode support or did you just not include it for the new boards?
I just did not include it.
Quoted 7 lines
Quoted 2 lines
I think in general we want a
_FELvariant for every board except the minority which don't have an OTG port etc.I'm not sold on this idea. Normal users (and distros) will never use the FEL variants, and a developer needing a FEL build can just as easily edit boards.cfg, instead of us having 2 lines there for each and every sunxi board (of which there are *a lot*.
... and once we have Kconfig it will be an easy thing to enable as needed.
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140707/e4e0c40f/attachment.pgp>
v3 cover sunxi: Bug fixes, sun4i and sun5i support and network improvements
In reply to Hans de GoedeQuoted 11 lines · Hans de Goede
Hi,
Quoted 5 lines · Ian Campbell
Quoted 1 line · Hans de Goede
adds sun4i and sun5i support
Does this series omit FEL mode support or did you just not include it for the new boards?
I just did not include it.
Quoted 7 lines
Quoted 2 lines
I think in general we want a
_FELvariant for every board except the minority which don't have an OTG port etc.I'm not sold on this idea. Normal users (and distros) will never use the FEL variants, and a developer needing a FEL build can just as easily edit boards.cfg, instead of us having 2 lines there for each and every sunxi board (of which there are *a lot*.
Actually Debian is providing the FEL binaries for CT in its u-boot packages already.
I was planning to provide a script to automatically install Debian starting from a bare board booted in FEL mode from a host system and getting the installer to put the bootloader on the MMC etc etc. (I'm a long way from actually having this working...)
Ian.
v3 cover sunxi: Bug fixes, sun4i and sun5i support and network improvements
Hi,
Quoted 15 lines · Ian Campbell
Quoted 14 lines · Hans de Goede
Hi,
Quoted 5 lines · Ian Campbell
Quoted 1 line · Hans de Goede
adds sun4i and sun5i support
Does this series omit FEL mode support or did you just not include it for the new boards?
I just did not include it.
Quoted 2 lines
I think in general we want a
_FELvariant for every board except the minority which don't have an OTG port etc.
Quoted 7 lines
Quoted 4 lines
I'm not sold on this idea. Normal users (and distros) will never use the FEL variants, and a developer needing a FEL build can just as easily edit boards.cfg, instead of us having 2 lines there for each and every sunxi board (of which there are *a lot*.
Actually Debian is providing the FEL binaries for CT in its u-boot packages already.
Hmm, ok.
Quoted 4 lines
I was planning to provide a script to automatically install Debian starting from a bare board booted in FEL mode from a host system and getting the installer to put the bootloader on the MMC etc etc. (I'm a long way from actually having this working...)
Interesting (mostly for emmc devices, of which there are a few sunxi ones now).
I'm still not sold on having 2 entries for each and every board though.
Have you looked at extending the SPL buildsys bits, which in essence do 2 builds, to do 3 builds for sunxi, so that we simply always build both SPL flavors?
Regards,
Hans
v3 cover sunxi: Bug fixes, sun4i and sun5i support and network improvements
Quoted 3 lines · Hans de Goede
Have you looked at extending the SPL buildsys bits, which in essence do 2 builds, to do 3 builds for sunxi, so that we simply always build both SPL flavors?
I hadn't thought of it. Is it only the SPL binary which differs between FEL and non-FEL then?
Ian.
v3 cover sunxi: Bug fixes, sun4i and sun5i support and network improvements
Hi,
Quoted 7 lines · Ian Campbell
Quoted 3 lines · Hans de Goede
Have you looked at extending the SPL buildsys bits, which in essence do 2 builds, to do 3 builds for sunxi, so that we simply always build both SPL flavors?
I hadn't thought of it. Is it only the SPL binary which differs between FEL and non-FEL then?
AFAIK, Yes.
Note an alternative to doing 3 builds would be to move the load address for the mmc spl to 0x2000 too, and to change the mmc spl header to jump to 0x2000 instead of 0x20. The question here is if the spl with mmc support will fit if we don't use the first 0x2000 bytes. One thing we could do is move the stack to another sram area (the area where we later copy the PSCI code for example), which will free up some space.
We would then also need to modify the unified SPL to detect whether it has booted from mmc or FEL, and only try to load the real u-boot from mmc in the mmc boot case.
If we do this, we would just need to modify the final build steps of the SPL build a bit to produce both SPL flavors.
I guess the big question is if we can make the mmc spl fit if we load it at 0x2000. If you're interested in working on this you should probably talk to hno about this. Another complication is that the brom uses some of the 32k sram at address 0 when in fel mode, so I think you cannot use all of it. hno can probably give more details here about which bits of the first 32k sram are used by the brom in fel mode and in mmc mode.
Regards,
Hans
v3 cover sunxi: Bug fixes, sun4i and sun5i support and network improvements
In reply to Ian Campbellons 2014-07-09 klockan 09:00 +0100 skrev Ian Campbell:
Quoted 2 lines
I hadn't thought of it. Is it only the SPL binary which differs between FEL and non-FEL then?
There is also a small difference in the default environment to enable boot-from-RAM in the FEL version of main u-boot. This is not enabled in the normal u-boot to avoid any risk of infinite looping boot failure from wrongly detected ram boot image.
Regards
Henrik
v3 cover sunxi: Bug fixes, sun4i and sun5i support and network improvements
Hi,
Quoted 9 lines · Henrik Nordstr?m
ons 2014-07-09 klockan 09:00 +0100 skrev Ian Campbell:
Quoted 2 lines
I hadn't thought of it. Is it only the SPL binary which differs between FEL and non-FEL then?
There is also a small difference in the default environment to enable boot-from-RAM in the FEL version of main u-boot. This is not enabled in the normal u-boot to avoid any risk of infinite looping boot failure from wrongly detected ram boot image.
Henrik, can you provide us with some memorymap info of the first 32K of SRAM for when booted from FEL vs MMC for all of sun4i, sun5i and sun7i ?
It would be good to know which bits of SRAM actually get uses by the BROM, and thus should not be overwritten, and which ones are free to use.
Regards,
Hans