Fwd: [linux-sunxi] [PATCH] Add qt840a

2014-05-16 Thread Amit Kucheria
Resending because my earlier reply bounced.

-- Forwarded message --
From: Amit Kucheria amit.kuche...@verdurent.com
Date: Fri, May 16, 2014 at 12:26 AM
Subject: Re: [linux-sunxi] [PATCH] Add qt840a
To: Hans de Goede hdego...@redhat.com
Cc: linux-sunxi@googlegroups.com


On Thu, May 15, 2014 at 11:41 PM, Hans de Goede hdego...@redhat.com wrote:
 Hi,

 Thanks for the patch. Looking at the outside of the qt840a box,
 I believe it is the same as the q5 (and the brandless box I have).

 With a PCB labelled i12 and I've already added a fex file for that ...

 Can you confirm that you've the same pcb as this one:
 http://www.aliexpress.com/item/Q5-Allwinner-A20-Android-4-2-Dual-Core-1-2GHz-OTA-Miracasr-DLNA-Support-1G-RAM/1834930044.html

Yes, it looks identical and does say I12 on the PCB.

 And also does your ethernet port work ? Mine is flaky, and it seems
 that the fex file is incorrect wrt the ethernet (on my pcb it needs
 PH21 as emac power gpio to work at all.

I switched to gmac and disabled RGMII-by-default in the gmac driver
to get it to work. I'll send out the patch now that I know my earlier
patches actually hit the list.

 Is your ethernet phy also the ic ip101a-lp ?

Yes.

 Regards,

 Hans


 On 05/15/2014 08:10 AM, Amit Kucheria wrote:
 Signed-off-by: Amit Kucheria amit.kuche...@verdurent.com
 ---
  sys_config/a20/qt840a.fex | 1100 
 +
  1 file changed, 1100 insertions(+)
  create mode 100644 sys_config/a20/qt840a.fex

 diff --git a/sys_config/a20/qt840a.fex b/sys_config/a20/qt840a.fex
 new file mode 100644
 index 000..197be83
 --- /dev/null
 +++ b/sys_config/a20/qt840a.fex
 @@ -0,0 +1,1100 @@
 +[product]
 +version = 100
 +machine = QT840a
 +
 +[platform]
 +eraseflag = 0
 +
 +[target]
 +boot_clock = 912
 +dcdc2_vol = 1400
 +dcdc3_vol = 1250
 +ldo2_vol = 3000
 +ldo3_vol = 2800
 +ldo4_vol = 2800
 +power_start = 1
 +storage_type = 0
 +
 +[clock]
 +pll3 = 297
 +pll4 = 300
 +pll6 = 600
 +pll7 = 297
 +pll8 = 336
 +
 +[card_boot]
 +logical_start = 40960
 +sprite_gpio0 = port:PH201defaultdefault0
 +sprite_work_delay = 500
 +sprite_err_delay = 200
 +
 +[card0_boot_para]
 +card_ctrl = 0
 +card_high_speed = 1
 +card_line = 4
 +sdc_d1 = port:PF0021defaultdefault
 +sdc_d0 = port:PF0121defaultdefault
 +sdc_clk = port:PF0221defaultdefault
 +sdc_cmd = port:PF0321defaultdefault
 +sdc_d3 = port:PF0421defaultdefault
 +sdc_d2 = port:PF0521defaultdefault
 +
 +[card2_boot_para]
 +card_ctrl = 2
 +card_high_speed = 1
 +card_line = 4
 +sdc_cmd = port:PC0631defaultdefault
 +sdc_clk = port:PC0731defaultdefault
 +sdc_d0 = port:PC0831defaultdefault
 +sdc_d1 = port:PC0931defaultdefault
 +sdc_d2 = port:PC1031defaultdefault
 +sdc_d3 = port:PC1131defaultdefault
 +
 +[twi_para]
 +twi_port = 0
 +twi_scl = port:PB002defaultdefaultdefault
 +twi_sda = port:PB012defaultdefaultdefault
 +
 +[uart_para]
 +uart_debug_port = 0
 +uart_debug_tx = port:PB2221defaultdefault
 +uart_debug_rx = port:PB2321defaultdefault
 +
 +[uart_force_debug]
 +uart_debug_port = 0
 +uart_debug_tx = port:PF0241defaultdefault
 +uart_debug_rx = port:PF0441defaultdefault
 +
 +[jtag_para]
 +jtag_enable = 0
 +jtag_ms = port:PB143defaultdefaultdefault
 +jtag_ck = port:PB153defaultdefaultdefault
 +jtag_do = port:PB163defaultdefaultdefault
 +jtag_di = port:PB173defaultdefaultdefault
 +
 +[pm_para]
 +standby_mode = 0
 +;--
 +; if standby_mode == 1, then support super standby;
 +; else, support normal standby.
 +;--
 +usbhid_wakeup_enable= 1
 +
 +[dram_para]
 +dram_baseaddr = 0x4000
 +dram_clk = 384
 +dram_type = 3
 +dram_rank_num = 1
 +dram_chip_density = 4096
 +dram_io_width = 16
 +dram_bus_width = 32
 +dram_cas = 9
 +dram_zq = 0x7f
 +dram_odt_en = 0
 +dram_size = 1024
 +dram_tpr0 = 0x42d899b7
 +dram_tpr1 = 0xa090
 +dram_tpr2 = 0x22a00
 +dram_tpr3 = 0x0
 +dram_tpr4 = 0x1
 +dram_tpr5 = 0x0
 +dram_emr1 = 0x4
 +dram_emr2 = 0x10
 +dram_emr3 = 0x0
 +
 +[mali_para]
 +mali_used = 1
 +mali_clkdiv = 1
 +
 +[gmac_para]
 +gmac_used = 1
 +gmac_rxd3 = port:PA005default3default
 +gmac_rxd2 = port:PA015default3default
 +gmac_rxd1 = port:PA025default3default
 +gmac_rxd0 = port:PA035default3default
 +gmac_txd3 = port:PA045default3default
 +gmac_txd2 = port:PA055default3default
 +gmac_txd1 = port:PA065default3default
 +gmac_txd0 = port:PA075default3default
 +gmac_rxclk = port:PA085default3default
 +gmac_rxerr = port:PA095default3default
 +gmac_rxdV = port:PA105default3default
 +gmac_mdc = port:PA115default3default
 +gmac_mdio = port:PA125default3default
 +gmac_txen = port:PA135default3default
 +gmac_txclk = port:PA145default3default
 +gmac_crs = port:PA155default3default
 +gmac_col = port:PA165default3default
 +gmac_reset = port:PA171default3default
 +
 +;[emac_para]
 +;emac_used = 1
 +;emac_rxd3 = port:PA002defaultdefaultdefault
 +;emac_rxd2 = 

Re: [linux-sunxi] Re: [PATCH v4 6/9] regulator: AXP20x: Add support for regulators subsystem

2014-05-16 Thread Carlo Caione
On Thu, May 15, 2014 at 8:03 PM, Boris BREZILLON
boris.brezil...@free-electrons.com wrote:
 Hello Carlo,

 On 11/04/2014 11:38, Carlo Caione wrote:
 AXP202 and AXP209 come with two synchronous step-down DC-DCs and five
 LDOs. This patch introduces basic support for those regulators.

 Signed-off-by: Carlo Caione ca...@caione.org
 ---
  drivers/regulator/Kconfig|   7 +
  drivers/regulator/Makefile   |   1 +
 [...]
 + if (!np)
 + return 0;
 +
 + regulators = of_find_node_by_name(np, regulators);

 I know I'm late, and this patch has already been applied, but shouldn't
 we use of_get_child_by_name instead of of_find_node_by_name.
 This might lead to wrong regulators node parsing if other regulators are
 defined in the DT after the axp20x node, because, AFAIK, this function
 searches for DT nodes defined after the specified np node, but not
 necessarely children of the np node.

Right. I'll prepare a fix. Feel free to submit a patch if you want.

Thank you,

-- 
Carlo Caione

-- 
You received this message because you are subscribed to the Google Groups 
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [linux-sunxi] [PATCH] Add qt840a

2014-05-16 Thread Amit Kucheria
On Fri, May 16, 2014 at 1:17 PM, Hans de Goede hdego...@redhat.com wrote:
 Hi,

 On 05/15/2014 08:56 PM, Amit Kucheria wrote:
 On Thu, May 15, 2014 at 11:41 PM, Hans de Goede hdego...@redhat.com wrote:
 Hi,

 Thanks for the patch. Looking at the outside of the qt840a box,
 I believe it is the same as the q5 (and the brandless box I have).

 With a PCB labelled i12 and I've already added a fex file for that ...

 Can you confirm that you've the same pcb as this one:
 http://www.aliexpress.com/item/Q5-Allwinner-A20-Android-4-2-Dual-Core-1-2GHz-OTA-Miracasr-DLNA-Support-1G-RAM/1834930044.html

 Yes, it looks identical and does say I12 on the PCB.

 Good, since I'm having trouble with my I12 tv box with the ethernet
 I've ordered a qt840a for myself. This seems to also use a different

Shall we keep the wiki page I created[1]?

 wifi chip, as it claims to have 2.4 and 5 GHz wifi. What is written
 as identifaction number on the wifi/bt module ?

The wifi is a broadcom ap6330 using the bcmdhd driver as per factory
firmware. I've not spent too much time with it yet.

 I was going to say that it would be best if you would merge any
 improvements you've into the i12-tvbox fex file already there,
 but if you've a different wifi chip that is not a good idea.

I can't see a i12-tvbox.fex in sunxi-boards git tree. What should I look for?

 So first lets see which wifi your board uses.

What about my u-boot patch? Did you create a dram file for the board too?

 And also does your ethernet port work ? Mine is flaky, and it seems
 that the fex file is incorrect wrt the ethernet (on my pcb it needs
 PH21 as emac power gpio to work at all.

 I switched to gmac and disabled RGMII-by-default in the gmac driver
 to get it to work. I'll send out the patch now that I know my earlier
 patches actually hit the list.

 Is your ethernet phy also the ic ip101a-lp ?

 Yes.


 Hmm, and it works reliable ? Can you try to ping -f something-on-your-lan
 and see if you experience any packet drop. I get 10% packet drop or more.

Yes, I've done ping testing, nothing more yet.

 My ip101a-lp also gets quite hot, can you touch yours (for a while) while it
 is in operation to see if it too gets hot ? I've a feeling mine is just
 broken ...

I'll try it out.

[1] http://linux-sunxi.org/Semitime_Qt840a

-- 
You received this message because you are subscribed to the Google Groups 
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [linux-sunxi] [RFC PATCH u-boot-sunxi] sunxi: use TWI1 for I2C outside of SPL for EEPROM access

2014-05-16 Thread Hans de Goede
Hi,

On 05/16/2014 01:32 PM, Jonathan Liu wrote:
 This allows accessing the EEPROM on the Olimex A20-OLinuXino-MICRO
 using the i2c command.
 
 Signed-off-by: Jonathan Liu net...@gmail.com

p.s.

I don't know what you want this for, but if it is for the purpose of
getting fixed MAC addresses for the NIC, please consider implementing
this: https://github.com/linux-sunxi/linux-sunxi/commit/e7d46d2c

Instead (I've this on my todo for u-boot, so that the kernel and u-boot
behave the same).

This way you will not only help getting a fixed MAC address on the
A20-OLinuXino-MICRO, but everywhere.

Thanks,

Hans



 ---
  arch/arm/include/asm/arch-sunxi/gpio.h | 2 ++
  arch/arm/include/asm/arch-sunxi/i2c.h  | 4 
  board/sunxi/board.c| 6 ++
  include/configs/sunxi-common.h | 4 
  4 files changed, 16 insertions(+)
 
 diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h 
 b/arch/arm/include/asm/arch-sunxi/gpio.h
 index 46a111e..7a866b4 100644
 --- a/arch/arm/include/asm/arch-sunxi/gpio.h
 +++ b/arch/arm/include/asm/arch-sunxi/gpio.h
 @@ -123,6 +123,8 @@ enum sunxi_gpio_number {
  #define SUN7I_GPA0_GMAC  5
  
  #define SUNXI_GPB0_TWI0  2
 +#define SUNXI_GPB0_TWI1  2
 +#define SUNXI_GPB0_TWI2  2
  
  #define SUN4I_GPB22_UART0_TX 2
  #define SUN4I_GPB23_UART0_RX 2
 diff --git a/arch/arm/include/asm/arch-sunxi/i2c.h 
 b/arch/arm/include/asm/arch-sunxi/i2c.h
 index dc5406b..d1708d1 100644
 --- a/arch/arm/include/asm/arch-sunxi/i2c.h
 +++ b/arch/arm/include/asm/arch-sunxi/i2c.h
 @@ -8,7 +8,11 @@
  
  #include asm/arch/cpu.h
  
 +#ifdef CONFIG_SPL_BUILD
  #define CONFIG_I2C_MVTWSI_BASE   SUNXI_TWI0_BASE
 +#else
 +#define CONFIG_I2C_MVTWSI_BASE   SUNXI_TWI1_BASE
 +#endif
  /* This is abp0-clk on sun4i/5i/7i / abp1-clk on sun6i/sun8i which is 24MHz 
 */
  #define CONFIG_SYS_TCLK  2400
  
 diff --git a/board/sunxi/board.c b/board/sunxi/board.c
 index 6c362a3..c9035ba 100644
 --- a/board/sunxi/board.c
 +++ b/board/sunxi/board.c
 @@ -129,9 +129,15 @@ int board_mmc_init(bd_t *bis)
  
  void i2c_init_board(void)
  {
 +#ifdef CONFIG_SPL_BUILD
   sunxi_gpio_set_cfgpin(SUNXI_GPB(0), SUNXI_GPB0_TWI0);
   sunxi_gpio_set_cfgpin(SUNXI_GPB(1), SUNXI_GPB0_TWI0);
   clock_twi_onoff(0, 1);
 +#else
 + sunxi_gpio_set_cfgpin(SUNXI_GPB(18), SUNXI_GPB0_TWI1);
 + sunxi_gpio_set_cfgpin(SUNXI_GPB(19), SUNXI_GPB0_TWI1);
 + clock_twi_onoff(1, 1);
 +#endif
  }
  
  #if defined(CONFIG_SPL_BUILD) || defined(CONFIG_SUN6I) || 
 defined(CONFIG_SUN8I)
 diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
 index e11c4ee..19ae9c9 100644
 --- a/include/configs/sunxi-common.h
 +++ b/include/configs/sunxi-common.h
 @@ -320,7 +320,11 @@
  /* No CONFIG_SYS_I2C as we use the non converted mvtwsi driver */
  #define CONFIG_HARD_I2C
  #define CONFIG_SYS_I2C_SUNXI
 +#ifdef CONFIG_SPL_BUILD
  #define CONFIG_SYS_I2C_SPEED 40
 +#else
 +#define CONFIG_SYS_I2C_SPEED 10
 +#endif
  #define CONFIG_SYS_I2C_SLAVE 0x7f
  #define CONFIG_CMD_I2C
  
 

-- 
You received this message because you are subscribed to the Google Groups 
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [linux-sunxi] [RFC PATCH u-boot-sunxi] sunxi: use TWI1 for I2C outside of SPL for EEPROM access

2014-05-16 Thread Jonathan Liu

On 17/05/2014 12:01 AM, Hans de Goede wrote:

Hi,

On 05/16/2014 01:32 PM, Jonathan Liu wrote:

This allows accessing the EEPROM on the Olimex A20-OLinuXino-MICRO
using the i2c command.

Signed-off-by: Jonathan Liu net...@gmail.com

p.s.

I don't know what you want this for, but if it is for the purpose of
getting fixed MAC addresses for the NIC, please consider implementing
this: https://github.com/linux-sunxi/linux-sunxi/commit/e7d46d2c

Instead (I've this on my todo for u-boot, so that the kernel and u-boot
behave the same).

This way you will not only help getting a fixed MAC address on the
A20-OLinuXino-MICRO, but everywhere.

Thanks,

Hans

setenv macaddr 02:
setexpr.l sid *0x01c23800
setexpr c \${sid} / 10; setexpr c \${c} % 10; setenv macaddr 
\${macaddr}\${c}

setexpr c \${sid} % 10; setenv macaddr \${macaddr}\${c}
setexpr.l sid *0x01c2380c
setexpr c \${sid} / 1000; setenv macaddr \${macaddr}:\${c}
setexpr c \${sid} / 100; setexpr c \${c} % 10; setenv macaddr 
\${macaddr}\${c}
setexpr c \${sid} / 10; setexpr c \${c} % 10; setenv macaddr 
\${macaddr}:\${c}
setexpr c \${sid} / 1; setexpr c \${c} % 10; setenv macaddr 
\${macaddr}\${c}
setexpr c \${sid} / 1000; setexpr c \${c} % 10; setenv macaddr 
\${macaddr}:\${c}
setexpr c \${sid} / 100; setexpr c \${c} % 10; setenv macaddr 
\${macaddr}\${c}
setexpr c \${sid} / 10; setexpr c \${c} % 10; setenv macaddr 
\${macaddr}:\${c}

setexpr c \${sid} % 10; setenv macaddr \${macaddr}\${c}
setenv ethaddr \${macaddr}

Regards,
Jonathan





---
  arch/arm/include/asm/arch-sunxi/gpio.h | 2 ++
  arch/arm/include/asm/arch-sunxi/i2c.h  | 4 
  board/sunxi/board.c| 6 ++
  include/configs/sunxi-common.h | 4 
  4 files changed, 16 insertions(+)

diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h 
b/arch/arm/include/asm/arch-sunxi/gpio.h
index 46a111e..7a866b4 100644
--- a/arch/arm/include/asm/arch-sunxi/gpio.h
+++ b/arch/arm/include/asm/arch-sunxi/gpio.h
@@ -123,6 +123,8 @@ enum sunxi_gpio_number {
  #define SUN7I_GPA0_GMAC   5
  
  #define SUNXI_GPB0_TWI0		2

+#define SUNXI_GPB0_TWI12
+#define SUNXI_GPB0_TWI22
  
  #define SUN4I_GPB22_UART0_TX	2

  #define SUN4I_GPB23_UART0_RX  2
diff --git a/arch/arm/include/asm/arch-sunxi/i2c.h 
b/arch/arm/include/asm/arch-sunxi/i2c.h
index dc5406b..d1708d1 100644
--- a/arch/arm/include/asm/arch-sunxi/i2c.h
+++ b/arch/arm/include/asm/arch-sunxi/i2c.h
@@ -8,7 +8,11 @@
  
  #include asm/arch/cpu.h
  
+#ifdef CONFIG_SPL_BUILD

  #define CONFIG_I2C_MVTWSI_BASESUNXI_TWI0_BASE
+#else
+#define CONFIG_I2C_MVTWSI_BASE SUNXI_TWI1_BASE
+#endif
  /* This is abp0-clk on sun4i/5i/7i / abp1-clk on sun6i/sun8i which is 24MHz */
  #define CONFIG_SYS_TCLK   2400
  
diff --git a/board/sunxi/board.c b/board/sunxi/board.c

index 6c362a3..c9035ba 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -129,9 +129,15 @@ int board_mmc_init(bd_t *bis)
  
  void i2c_init_board(void)

  {
+#ifdef CONFIG_SPL_BUILD
sunxi_gpio_set_cfgpin(SUNXI_GPB(0), SUNXI_GPB0_TWI0);
sunxi_gpio_set_cfgpin(SUNXI_GPB(1), SUNXI_GPB0_TWI0);
clock_twi_onoff(0, 1);
+#else
+   sunxi_gpio_set_cfgpin(SUNXI_GPB(18), SUNXI_GPB0_TWI1);
+   sunxi_gpio_set_cfgpin(SUNXI_GPB(19), SUNXI_GPB0_TWI1);
+   clock_twi_onoff(1, 1);
+#endif
  }
  
  #if defined(CONFIG_SPL_BUILD) || defined(CONFIG_SUN6I) || defined(CONFIG_SUN8I)

diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index e11c4ee..19ae9c9 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -320,7 +320,11 @@
  /* No CONFIG_SYS_I2C as we use the non converted mvtwsi driver */
  #define CONFIG_HARD_I2C
  #define CONFIG_SYS_I2C_SUNXI
+#ifdef CONFIG_SPL_BUILD
  #define CONFIG_SYS_I2C_SPEED  40
+#else
+#define CONFIG_SYS_I2C_SPEED   10
+#endif
  #define CONFIG_SYS_I2C_SLAVE  0x7f
  #define CONFIG_CMD_I2C
  



--
You received this message because you are subscribed to the Google Groups 
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [linux-sunxi] [PATCH u-boot-sunxi] sunxi: support Thumb2 for FEL

2014-05-16 Thread Ian Campbell
On Fri, 2014-05-16 at 20:19 +0300, Siarhei Siamashka wrote:
 On Fri, 16 May 2014 17:04:32 +0100
 Ian Campbell i...@hellion.org.uk wrote:
 
  On Fri, 2014-05-16 at 18:05 +0300, Siarhei Siamashka wrote:
   The FEL SPL entry point at the address 0x2000 starts execution
   in the ARM mode. So we need to make sure that this particular
   code is also compiled for the ARM mode. The rest of the SPL can
   be compiled as Thumb2 and benefit from the code size reduction.
  
  What is the saving like?
 
 For A13-OLinuXinoM_FEL_config and
 gcc version 4.8.2 (Gentoo 4.8.2-r1 p1.4-ssptest, pie-0.5.9-ssptest)
 
 == before ==
 
 $ armv7a-hardfloat-linux-gnueabi-size u-boot-spl
textdata bss dec hex filename
   11010 372  16   113982c86 u-boot-spl
 
 == after ==
 
 $ armv7a-hardfloat-linux-gnueabi-size u-boot-spl
textdata bss dec hex filename
8762 372  16915023be u-boot-spl

Interesting, thanks.

 Having extra SRAM space headroom is nice. Also the unification and
 the use of Thumb2 code everywhere means that any possible compiler
 bugs are likely to affect both regular and FEL builds in the same
 way.
 
 Should I send a v2 patch with an updated commit message?

Not on my account, I was just curious.

Ian.

-- 
You received this message because you are subscribed to the Google Groups 
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [linux-sunxi] [RFC PATCH u-boot-sunxi] sunxi: use TWI1 for I2C outside of SPL for EEPROM access

2014-05-16 Thread Hans de Goede
Hi,

On 05/16/2014 04:21 PM, Jonathan Liu wrote:
 On 17/05/2014 12:01 AM, Hans de Goede wrote:
 Hi,

 On 05/16/2014 01:32 PM, Jonathan Liu wrote:
 This allows accessing the EEPROM on the Olimex A20-OLinuXino-MICRO
 using the i2c command.

 Signed-off-by: Jonathan Liu net...@gmail.com
 p.s.

 I don't know what you want this for, but if it is for the purpose of
 getting fixed MAC addresses for the NIC, please consider implementing
 this: https://github.com/linux-sunxi/linux-sunxi/commit/e7d46d2c

 Instead (I've this on my todo for u-boot, so that the kernel and u-boot
 behave the same).

 This way you will not only help getting a fixed MAC address on the
 A20-OLinuXino-MICRO, but everywhere.

 Thanks,

 Hans
 setenv macaddr 02:
 setexpr.l sid *0x01c23800
 setexpr c ${sid} / 10; setexpr c ${c} % 10; setenv macaddr ${macaddr}${c}
 setexpr c ${sid} % 10; setenv macaddr ${macaddr}${c}
 setexpr.l sid *0x01c2380c
 setexpr c ${sid} / 1000; setenv macaddr ${macaddr}:${c}
 setexpr c ${sid} / 100; setexpr c ${c} % 10; setenv macaddr 
 ${macaddr}${c}
 setexpr c ${sid} / 10; setexpr c ${c} % 10; setenv macaddr 
 ${macaddr}:${c}
 setexpr c ${sid} / 1; setexpr c ${c} % 10; setenv macaddr ${macaddr}${c}
 setexpr c ${sid} / 1000; setexpr c ${c} % 10; setenv macaddr ${macaddr}:${c}
 setexpr c ${sid} / 100; setexpr c ${c} % 10; setenv macaddr ${macaddr}${c}
 setexpr c ${sid} / 10; setexpr c ${c} % 10; setenv macaddr ${macaddr}:${c}
 setexpr c ${sid} % 10; setenv macaddr ${macaddr}${c}
 setenv ethaddr ${macaddr}

Heh, that is a cool trick, but I was actually hoping for a C-code patch doing
the same, so that we don't need to uglify our boot scripts (and make them non 
standard)
also you first need to check that: 1) No macaddr has been set, and 2) the sid 
is not
all  (which it is on some of the first batch of the A20 SoC).

Thanks,

Hans

-- 
You received this message because you are subscribed to the Google Groups 
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [linux-sunxi] [PATCH u-boot-sunxi] sunxi: support Thumb2 for FEL

2014-05-16 Thread Hans de Goede
Hi,

On 05/16/2014 08:20 PM, Ian Campbell wrote:
 On Fri, 2014-05-16 at 20:19 +0300, Siarhei Siamashka wrote:
 On Fri, 16 May 2014 17:04:32 +0100
 Ian Campbell i...@hellion.org.uk wrote:

 On Fri, 2014-05-16 at 18:05 +0300, Siarhei Siamashka wrote:
 The FEL SPL entry point at the address 0x2000 starts execution
 in the ARM mode. So we need to make sure that this particular
 code is also compiled for the ARM mode. The rest of the SPL can
 be compiled as Thumb2 and benefit from the code size reduction.

 What is the saving like?

 For A13-OLinuXinoM_FEL_config and
 gcc version 4.8.2 (Gentoo 4.8.2-r1 p1.4-ssptest, pie-0.5.9-ssptest)

 == before ==

 $ armv7a-hardfloat-linux-gnueabi-size u-boot-spl
textdata bss dec hex filename
   11010 372  16   113982c86 u-boot-spl

 == after ==

 $ armv7a-hardfloat-linux-gnueabi-size u-boot-spl
textdata bss dec hex filename
8762 372  16915023be u-boot-spl
 
 Interesting, thanks.
 
 Having extra SRAM space headroom is nice. Also the unification and
 the use of Thumb2 code everywhere means that any possible compiler
 bugs are likely to affect both regular and FEL builds in the same
 way.

 Should I send a v2 patch with an updated commit message?
 
 Not on my account, I was just curious.

I think this change is an improvement, but if we do this, we also
need to upstream it. Ian what is your take on this? IOW are you
ok with my applying this to the u-boot-sunxi git repo ?

Regards,

Hans

-- 
You received this message because you are subscribed to the Google Groups 
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [linux-sunxi] [PATCH u-boot-sunxi] sunxi: support Thumb2 for FEL

2014-05-16 Thread Henrik Nordström
fre 2014-05-16 klockan 17:04 +0100 skrev Ian Campbell:
 On Fri, 2014-05-16 at 18:05 +0300, Siarhei Siamashka wrote:
  The FEL SPL entry point at the address 0x2000 starts execution
  in the ARM mode. So we need to make sure that this particular
  code is also compiled for the ARM mode. The rest of the SPL can
  be compiled as Thumb2 and benefit from the code size reduction.
 
 What is the saving like?

Why is there a need to hunt bytes in FEL? We only need the DRAM
initialization code in the FEL binary.

Regards
Henrik

-- 
You received this message because you are subscribed to the Google Groups 
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [linux-sunxi] [PATCH u-boot-sunxi] sunxi: support Thumb2 for FEL

2014-05-16 Thread Siarhei Siamashka
On Fri, 16 May 2014 21:18:35 +0200
Hans de Goede hdego...@redhat.com wrote:

 Hi,
 
 On 05/16/2014 08:20 PM, Ian Campbell wrote:
  On Fri, 2014-05-16 at 20:19 +0300, Siarhei Siamashka wrote:
  On Fri, 16 May 2014 17:04:32 +0100
  Ian Campbell i...@hellion.org.uk wrote:
 
  On Fri, 2014-05-16 at 18:05 +0300, Siarhei Siamashka wrote:
  The FEL SPL entry point at the address 0x2000 starts execution
  in the ARM mode. So we need to make sure that this particular
  code is also compiled for the ARM mode. The rest of the SPL can
  be compiled as Thumb2 and benefit from the code size reduction.
 
  What is the saving like?
 
  For A13-OLinuXinoM_FEL_config and
  gcc version 4.8.2 (Gentoo 4.8.2-r1 p1.4-ssptest, pie-0.5.9-ssptest)
 
  == before ==
 
  $ armv7a-hardfloat-linux-gnueabi-size u-boot-spl
 textdata bss dec hex filename
11010 372  16   113982c86 u-boot-spl
 
  == after ==
 
  $ armv7a-hardfloat-linux-gnueabi-size u-boot-spl
 textdata bss dec hex filename
 8762 372  16915023be u-boot-spl
  
  Interesting, thanks.
  
  Having extra SRAM space headroom is nice. Also the unification and
  the use of Thumb2 code everywhere means that any possible compiler
  bugs are likely to affect both regular and FEL builds in the same
  way.
 
  Should I send a v2 patch with an updated commit message?
  
  Not on my account, I was just curious.
 
 I think this change is an improvement, but if we do this, we also
 need to upstream it. Ian what is your take on this? IOW are you
 ok with my applying this to the u-boot-sunxi git repo ?

Well, I'm also considering that it might be a good idea to just wait
until the basic sunxi support lands upstream. And then directly
submit the dram patches there. No need to bother you and Ian
unnecessarily.

-- 
Best regards,
Siarhei Siamashka

-- 
You received this message because you are subscribed to the Google Groups 
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [linux-sunxi] [PATCH u-boot-sunxi] sunxi: support Thumb2 for FEL

2014-05-16 Thread Ian Campbell
On Fri, 2014-05-16 at 23:11 +0300, Siarhei Siamashka wrote:
  I think this change is an improvement, but if we do this, we also
  need to upstream it. Ian what is your take on this? IOW are you
  ok with my applying this to the u-boot-sunxi git repo ?

While things aren't yet upstream I'm in two minds.

Once it does go upstream I think it would pay to be quite strict about
accepting stuff into u-boot-sunxi.git. There's not much point going to
all the effort upstreaming things if it is just allowed to diverge
again, and I don't really want to be forever playing catch up.

 Well, I'm also considering that it might be a good idea to just wait
 until the basic sunxi support lands upstream. And then directly
 submit the dram patches there. No need to bother you and Ian
 unnecessarily.

That would certainly make life easier for everyone I think.

Ian.

-- 
You received this message because you are subscribed to the Google Groups 
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] [PATCH] Revert gpio: Oscillate option

2014-05-16 Thread Ian Campbell
This reverts commits d104fc0ee38a and af9f4057a591.

Henrik says in 
https://groups.google.com/forum/#!msg/linux-sunxi/nSKH4IcTaX8/YBVQLMrzfKwJ:

GPIO_OSCILLATE is a hack in our u-boot used for measuring PIO performance.
Should likely be removed.

This is one less thing to worry about for upstreaming, or at least removes
something from the diff...

Signed-off-by: Ian Campbell i...@hellion.org.uk
Cc: Henrik Nordstrom hen...@henriknordstrom.net
---
 common/cmd_gpio.c | 10 --
 1 file changed, 10 deletions(-)

diff --git a/common/cmd_gpio.c b/common/cmd_gpio.c
index 0aa9ab0..778aa5f 100644
--- a/common/cmd_gpio.c
+++ b/common/cmd_gpio.c
@@ -20,7 +20,6 @@ enum gpio_cmd {
GPIO_SET,
GPIO_CLEAR,
GPIO_TOGGLE,
-   GPIO_OSCILLATE,
 };
 
 #if defined(CONFIG_DM_GPIO)  !defined(gpio_status)
@@ -139,7 +138,6 @@ static int do_gpio(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
case 's': sub_cmd = GPIO_SET;break;
case 'c': sub_cmd = GPIO_CLEAR;  break;
case 't': sub_cmd = GPIO_TOGGLE; break;
-   case 'o': sub_cmd = GPIO_OSCILLATE; break;
default:  goto show_usage;
}
 
@@ -170,14 +168,6 @@ static int do_gpio(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
if (sub_cmd == GPIO_INPUT) {
gpio_direction_input(gpio);
value = gpio_get_value(gpio);
-   } else if (sub_cmd == GPIO_OSCILLATE) {
-   int i;
-   gpio_direction_output(gpio, 0);
-   for (i = 0; i  1; i++) {
-   gpio_set_value(gpio, i1);
-   }
-   gpio_direction_input(gpio);
-   value = 0;
} else {
switch (sub_cmd) {
case GPIO_SET:value = 1; break;
-- 
1.9.0

-- 
You received this message because you are subscribed to the Google Groups 
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.