Re: [linux-sunxi] When does the I2C probe function get called

[Dave McLaughlin]

Hi Oliver,

I finally got it working this weekend and posted the results on my blog.

I had to add some code to the Fusion driver to pass back detection state 
and also make changes to use the AllWinner GPIO drivers and read the 
sysconfig.fex during init.

There was also a bug in the eint driver that displayed a handler failure 
even though the correct value was passed back. It was an easy fix.

I now have a working 7" cap touch display but missing a few things. Pinch 
to zoom isn't working yet although the driver does pass 2 touches to the 
kernel. Also the pulldown from the top isn't working with 1 finger right 
now. Seems to only respond if 2 are used.

Even though I have this working for Android, as the driver is actually part 
of the Linux kernel it should actually work with an Linux system too.

Dave...

On Sunday, 23 March 2014 18:15:46 UTC+7, Olliver Schinagl wrote:
>
> Touch screens are very fidgity to get working right, often due to some 
> firmware that needs to be loaded, or is different between various 
> implentations of the touchscreen IC. 
>
> I personally haven't seen the fusion series pass by the mailing list ... 
>
> Olliver 
>
>

-- 
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.git] sunxi: dram: checkpatch.pl cleanups

[Chen-Yu Tsai]

Hi,

On Mon, Mar 24, 2014 at 4:21 AM, Hans de Goede  wrote:
> Hi,
>
> On 03/23/2014 04:13 PM, Ian Campbell wrote:
>> On Sat, 2014-03-22 at 20:22 +0100, Hans de Goede wrote:
>>> One thing that stands out when doing a diff against sunxi-merge-v2014.04-rc2
>>> is this:
>>>
>>> --- u-boot/drivers/net/designware.c 2014-03-21 16:26:42.229522420 +0100
>>> +++ u-boot-sunxi/drivers/net/designware.c   2014-03-22 
>>> 17:21:51.907879720 +
>>> @@ -249,10 +249,10 @@
>>> rx_descs_init(dev);
>>> tx_descs_init(dev);
>>>
>>> -   writel(FIXEDBURST | PRIORXTX_41 | BURST_16, &dma_p->busmode);
>>> +   writel(FIXEDBURST | PRIORXTX_41 | BURST_8, &dma_p->busmode);

This is required. The GMAC IP does not support DMA burst lengths above 8.

>>>
>>> -   writel(readl(&dma_p->opmode) | FLUSHTXFIFO | STOREFORWARD,
>>> -  &dma_p->opmode);
>>> +   writel(readl(&dma_p->opmode) | FLUSHTXFIFO | STOREFORWARD |
>>> +   TXSECONDFRAME, &dma_p->opmode);

This is a performance improvement change, as seen in the Linux kernel:

csr6 |= DMA_CONTROL_TSF;
   /* Operating on second frame increase the performance
 * especially when transmit store-and-forward is used.
 */
csr6 |= DMA_CONTROL_OSF;

Though AFAIK we never changed this. Maybe it was changed upstream.

>>>
>>> writel(readl(&dma_p->opmode) | RXSTART | TXSTART, &dma_p->opmode);
>>>
>>>
>>> Which we should probably fix given that you've enabled gmac support.
>>
>> Things work for me without.
>
> IIRC the BURST_8 is necessary to get certain traffic patterns to not cause
> corruption. Don't know about the rest. Wens probably knows best.

See above.

>> I was under the impression that Wens (or
>> someone else) had this under control WRT upstreaming so I was leaving it
>> for now,
>
> I'm not sure wens, or anyone for that matter is actively working on gmac
> u-boot support.

Sorry, no one is actively working on this ATM. If you could do it, that
would be nice. Only a oneliner to change the burst length is required.

>> it can easily go in as an independent fix AFAICT.
>
> It can and it should, but first we need some more info I guess, wens ?

See inline comments above.

I regret that my attention is focused elsewhere ATM, with all that's
happened in the last week (and still ongoing) in my country.

Feel free to run any GMAC related patches by me, though. I will try to
look at it.


Cheers
ChenYu


>>> I also noticed that in include/configs/sunxi-common.h you've a formatting
>>> fix for the CONFIG_PHY_ADDR #define which is not yet in u-boot-sunxi.
>>
>> CONFIG_PHY_ADDR arrived as part of the merge of v2014.04-rc2, so the fix
>> got folded into the merge when I redid it.
>
> Ah, ok.
>
>>
>> I might manage a v3, which will be a couple of cleanups and a lot of
>> clarifications about licensing, today, or I might watch game of thrones
>> and do v3 later in the week, lets see how it goes...
>
> Sounds good. I hope that your license clarification will be good enough
> for upstream, and thanks for working on this.
>
> 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] Re: [PATCH 9/9] sunxi: remove key driver

[Henrik Nordström]

mån 2014-03-24 klockan 01:18 +0100 skrev Henrik Nordström:
> sön 2014-03-16 klockan 17:34 + skrev Ian Campbell:
> > This code hasn't been called since the calls to it randomly disappeared in
> > 71e6be0ccbd5 "sunxi: get u-boot mmc spl work" and 4d29a5dd7414 "sunxi: 
> > further
> > clean sunxi platform". It seems to have only ever been used as test code 
> > anyway.
> 
> It's left as a reminder to implement something that uses it. Almost
> every device have LRADC keys and could be very useful for controlling
> boot process (i.e. boot recoery/failsafe mode).
> 
> I guess a command that sets a variable with the current pressed key
> value would be suitable.

I.e. something like this patch:

>From ee16a3deaa41aa5b10ffa586cf1353a3c88468f9 Mon Sep 17 00:00:00 2001
From: Henrik Nordstrom 
Date: Mon, 24 Mar 2014 02:02:29 +0100
Subject: [PATCH] sunxi: readkey command for reading lradc key value

readkey variable
reads ldarc key value into specified variable to allow scripts
to take actions based on lradc key presses.

Signed-off-by: Henrik Nordstrom 
---
 arch/arm/cpu/armv7/sunxi/board.c |  3 +++
 arch/arm/cpu/armv7/sunxi/key.c   | 18 ++
 2 files changed, 21 insertions(+)

diff --git a/arch/arm/cpu/armv7/sunxi/board.c
b/arch/arm/cpu/armv7/sunxi/board.c
index 94c5cd0..6ad4345 100644
--- a/arch/arm/cpu/armv7/sunxi/board.c
+++ b/arch/arm/cpu/armv7/sunxi/board.c
@@ -98,6 +98,9 @@ void s_init(void)
clock_init();
timer_init();
gpio_init();
+#ifndef CONFIG_SPL_BUILD
+   sunxi_key_init();
+#endif
 
 #ifdef CONFIG_SPL_BUILD
gd = &gdata;
diff --git a/arch/arm/cpu/armv7/sunxi/key.c
b/arch/arm/cpu/armv7/sunxi/key.c
index fcdabd3..578a519 100644
--- a/arch/arm/cpu/armv7/sunxi/key.c
+++ b/arch/arm/cpu/armv7/sunxi/key.c
@@ -52,3 +52,21 @@ u32 sunxi_read_key(void)
writel(ints, &sunxi_key_base->ints);
return key;
 }
+
+int do_readkey(cmd_tbl_t *cmdtp, int flag, int argc, const char
*argv[])
+{
+   u32 key;
+
+   if (argc < 2) {
+   printf("usage: readkey variable\n");
+   }
+   setenv_ulong(argv[1], sunxi_read_key());
+   
+   return 0;
+}
+
+U_BOOT_CMD(
+   readkey, 2, 1, do_readkey,
+   "Read LDADC key value into specified variable",
+   ""
+);
-- 
1.8.5.3



-- 
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] Re: [PATCH 9/9] sunxi: remove key driver

[Henrik Nordström]

sön 2014-03-16 klockan 17:34 + skrev Ian Campbell:
> This code hasn't been called since the calls to it randomly disappeared in
> 71e6be0ccbd5 "sunxi: get u-boot mmc spl work" and 4d29a5dd7414 "sunxi: further
> clean sunxi platform". It seems to have only ever been used as test code 
> anyway.

It's left as a reminder to implement something that uses it. Almost
every device have LRADC keys and could be very useful for controlling
boot process (i.e. boot recoery/failsafe mode).

I guess a command that sets a variable with the current pressed key
value would be suitable.

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.

[linux-sunxi] Re: [PATCH u-boot sunxi 3/4] sunxi: Implement reset_cpu

[Henrik Nordström]

sön 2014-03-16 klockan 18:38 + skrev Ian Campbell:

> Not sure why cmd_watchdog.c is sunxi, seems like in principal it could
> be generic.

In principal it could, but there is no common API for setting the
watchdog timer, and no common API for disabling the watchdog once armed.

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.

[linux-sunxi] Re: [PATCH u-boot sunxi 3/4] sunxi: Implement reset_cpu

[Henrik Nordström]

sön 2014-03-16 klockan 14:53 +0100 skrev Hans de Goede:
>  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_RESTART, &wdog->ctl);
> + while (1);

This code is incomplete and do not reload the watchdog if already
running. wdog->ctl is locked by a magic key. Should use

writel(WDT_CTRL_KEY | WDT_CTRL_RESTART, &wdog->ctl);

where

#define WDT_CTRL_KEY(0x0a57 << 1)

Unfortunatley Allwinner kindly omitted this little detail from the User
Manual.

Found out while trying to use the watchdog as a watchdog and not only
reset. Asked Tom while he still was at Allwinner and got clarification
on how to use the watchdog control register.

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] Re: [PATCH] Add Ippo Q8H-v5

[Luc Verhaegen]

On Sun, Mar 23, 2014 at 02:46:17PM -0700, Joseph Dalrymple wrote:
> Pardon my ignorance, but what repository was this added to?

None yet, but it should be sunxi-boards.

I trust that you read and understood the contents of 
http://linux-sunxi.org/Ippo_q8h and know that there is no support for 
A23 yet?

Luc Verhaegen.

-- 
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] Re: [PATCH 4/9] sunxi: only try to init dram once.

[Henrik Nordström]

sön 2014-03-16 klockan 17:34 + skrev Ian Campbell:
> As Alex explains in [0] this triple call likely dates back to before the DRAM
> init code used proper timings. It is not necessary any more.

maybe, but not comfortable removing it without some test showing that
the problem is indeed solved.

We found it randomly failing on reboot some boards, I think it was
OLinuXino A13. Cold boot always worked. Then looked at Allwinner boot0
code and copied retry from there.

The code is from Sun Nov 4 22:32:41 2012 (ffe3d4fb)

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+GIT 0/9] sunxi: upstream review based cleanups

[Henrik Nordström]

sön 2014-03-23 klockan 12:21 +0100 skrev Olliver Schinagl:

> It's not a huge bug I suppose, but still, it's wrong isn't it. Wolfgang 
> Denk even said 'this is wrong, you are right' but nothing came from it I 
> think :)

So just ping the list with a response to his response asking if there is
anything that needs to be improved?

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.git] sunxi: dram: checkpatch.pl cleanups

[Henrik Nordström]

fre 2014-03-21 klockan 16:33 + skrev Ian Campbell:

> Thanks, I was really hoping we could pull mainline up to this level too
> ASAP. I want to avoid the possibility of diverging into two forks with
> different featuresets. But I guess hno isn't around so this will have to
> do.

What is held back on me?

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.

[linux-sunxi] Re: [PATCH+GIT 0/9] sunxi: upstream review based cleanups

[Henrik Nordström]

sön 2014-03-16 klockan 19:40 +0100 skrev Hans de Goede:

> Thanks I've added the 9 patches to the u-boot-sunxi repo sunxi branch,
> as for the merge with v2014.04-rc2, I would like to wait what HNO has
> to say about that.

Merges from upstream is always welcome. Just make sure it builds and
boots on some board before pushing.

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] Re: Fwd: [fedora-arm] Fedora 20 Allwinner Remix image

[chavchan]

> I trying to use this image on OlinuXino A20 and work fine but i need to use 
> also on VGA monitor and also i changed uEnv.txt as README file say, it 
> doesn't work.
> 
> i tryed with
>   disp.screen0_output_type=4 disp.screen0_output_mode=1360x768

I had the same problem on Cubietruck, passing disp.screen0_output_type kernel 
argument causes kernel panic.

The workaround was not to pass disp.screen0_output_type argument, but to modify 
script.bin instead using sunxi-tools. That way it works fine. This page 
describes how to modify script.bin:

 https://github.com/cubieplayer/Cubian/wiki/VGA-output

(there are script.bin and corresponding fex files for different boards on uboot 
partition)

And here is modified script.bin for Cubietruck that defaults to VGA 1280x1024 
output just in case if someone needs it:

 http://lykt.info/cubietruck/1280x1024/
 

-- 
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] Re: [PATCH] Add Ippo Q8H-v5

[Joseph Dalrymple]

Pardon my ignorance, but what repository was this added to?

On Monday, March 17, 2014 11:33:01 PM UTC-5, Chen-Yu Tsai wrote:
>
> Signed-off-by: Chen-Yu Tsai > 
> --- 
>  sys_config/a23/ippo-q8h-v5.fex | 844 
> + 
>  1 file changed, 844 insertions(+) 
>  create mode 100644 sys_config/a23/ippo-q8h-v5.fex 
>
> diff --git a/sys_config/a23/ippo-q8h-v5.fex 
> b/sys_config/a23/ippo-q8h-v5.fex 
> new file mode 100644 
> index 000..be31310 
> --- /dev/null 
> +++ b/sys_config/a23/ippo-q8h-v5.fex 
> @@ -0,0 +1,844 @@ 
> +[product] 
> +version = "100" 
> +machine = "a23-a70H" 
> + 
> +[platform] 
> +eraseflag = 1 
> +next_work = 2 
> + 
> +[target] 
> +boot_clock = 1008 
> +storage_type = -1 
> + 
> +[power_sply] 
> +dcdc1_vol = 3000 
> +dcdc2_vol = 1100 
> +dcdc3_vol = 1260 
> +dcdc4_vol = 0 
> +dcdc5_vol = 1500 
> +aldo2_vol = 2500 
> +aldo3_vol = 3000 
> + 
> +[card_boot] 
> +logical_start = 40960 
> +sprite_gpio0 = 
> + 
> +[card0_boot_para] 
> +card_ctrl = 0 
> +card_high_speed = 1 
> +card_line = 4 
> +sdc_d1 = port:PF00<2><1><2> 
> +sdc_d0 = port:PF01<2><1><2> 
> +sdc_clk = port:PF02<2><1><2> 
> +sdc_cmd = port:PF03<2><1><2> 
> +sdc_d3 = port:PF04<2><1><2> 
> +sdc_d2 = port:PF05<2><1><2> 
> + 
> +[card2_boot_para] 
> +card_ctrl = 2 
> +card_high_speed = 1 
> +card_line = 4 
> +sdc_clk = port:PC05<3><1><2> 
> +sdc_cmd = port:PC06<3><1><2> 
> +sdc_d0 = port:PC08<3><1><2> 
> +sdc_d1 = port:PC09<3><1><2> 
> +sdc_d2 = port:PC10<3><1><2> 
> +sdc_d3 = port:PC11<3><1><2> 
> + 
> +[twi_para] 
> +twi_port = 0 
> +twi_scl = port:PH02<2> 
> +twi_sda = port:PH03<2> 
> + 
> +[uart_para] 
> +uart_debug_port = 0 
> +uart_debug_tx = port:PF02<3><1> 
> +uart_debug_rx = port:PF04<3><1> 
> + 
> +[jtag_para] 
> +jtag_enable = 0 
> +jtag_ms = port:PF00<3> 
> +jtag_ck = port:PF05<3> 
> +jtag_do = port:PF03<3> 
> +jtag_di = port:PF01<3> 
> + 
> +[clock] 
> +pll3 = 297 
> +pll4 = 300 
> +pll6 = 600 
> +pll8 = 408 
> +pll9 = 480 
> +pll10 = 468 
> + 
> +[pm_para] 
> +standby_mode = 1 
> + 
> +[dram_para] 
> +dram_clk = 480 
> +dram_type = 3 
> +dram_zq = 0xf777 
> +dram_odt_en = 1 
> +dram_para1 = 17835008 
> +dram_para2 = 0 
> +dram_mr0 = 6736 
> +dram_mr1 = 4 
> +dram_mr2 = 16 
> +dram_mr3 = 0 
> +dram_tpr0 = 0x2ab83def 
> +dram_tpr1 = 0x18082356 
> +dram_tpr2 = 0x34156 
> +dram_tpr3 = 0x448c5533 
> +dram_tpr4 = 0x8010d00 
> +dram_tpr5 = 0x340b20f 
> +dram_tpr6 = 0x20d118cc 
> +dram_tpr7 = 0x14062485 
> +dram_tpr8 = 0x220d1d52 
> +dram_tpr9 = 0x1e078c22 
> +dram_tpr10 = 0x3c 
> +dram_tpr11 = 0x0 
> +dram_tpr12 = 0x96 
> +dram_tpr13 = 0x3 
> + 
> +[wakeup_src_para] 
> +cpu_en = 0 
> +cpu_freq = 48 
> +pll_ratio = 273 
> +dram_selfresh_en = 1 
> +dram_freq = 36 
> + 
> +[twi0] 
> +twi_used = 1 
> +twi_scl = port:PH02<2> 
> +twi_sda = port:PH03<2> 
> + 
> +[twi1] 
> +twi_used = 1 
> +twi_scl = port:PH04<2> 
> +twi_sda = port:PH05<2> 
> + 
> +[twi2] 
> +twi_used = 1 
> +twi_scl = port:PE12<3> 
> +twi_sda = port:PE13<3> 
> + 
> +[uart0] 
> +uart_used = 0 
> +uart_port = 0 
> +uart_type = 2 
> +uart_tx = port:PF02<3><1> 
> +uart_rx = port:PF04<3><1> 
> + 
> +[uart1] 
> +uart_used = 0 
> +uart_type = 4 
> +uart_tx = port:PG06<2><1> 
> +uart_rx = port:PG07<2><1> 
> +uart_rts = port:PG08<2><1> 
> +uart_cts = port:PG09<2><1> 
> + 
> +[uart2] 
> +uart_used = 0 
> +uart_type = 4 
> +uart_tx = port:PB00<2><1> 
> +uart_rx = port:PB01<2><1> 
> +uart_rts = port:PB02<2><1> 
> +uart_cts = port:PB03<2><1> 
> + 
> +[uart3] 
> +uart_used = 0 
> +uart_type = 4 
> +uart_tx = port:PH06<3><1> 
> +uart_rx = port:PH07<3><1> 
> +uart_rts = port:PH08<3><1> 
> +uart_cts = port:PH09<3><1> 
> + 
> +[uart4] 
> +uart_used = 0 
> +uart_port = 4 
> +uart_type = 2 
> +uart_tx = port:PA04<2><1> 
> +uart_rx = port:PA05<2><1> 
> +uart_rts = port:PA06<2><1> 
> +uart_cts = port:PA07<2><1> 
> + 
> +[spi0] 
> +spi_used = 0 
> +spi_cs_bitmap = 1 
> +spi_mosi = port:PC00<3> 
> +spi_miso = port:PC01<3> 
> +spi_sclk = port:PC02<3> 
> +spi_cs0 = port:PC03<3><1> 
> + 
> +[spi1] 
> +spi_used = 0 
> +spi_cs_bitmap = 1 
> +spi_cs0 = port:PA00<2><1> 
> +spi_sclk = port:PA01<2> 
> +spi_mosi = port:PA02<2> 
> +spi_miso = port:PA03<2> 
> + 
> +[spi_devices] 
> +spi_dev_num = 0 
> + 
> +[spi_board0] 
> +modalias = "at25df641" 
> +max_speed_hz = 5000 
> +bus_num = 0 
> +chip_select = 0 
> +mode = 0 
> + 
> +[ctp_para] 
> +ctp_used = 1 
> +ctp_name = "gsl1688_a70" 
> +ctp_twi_id = 0 
> +ctp_twi_addr = 0x40 
> +ctp_screen_max_x = 800 
> +ctp_screen_max_y = 480 
> +ctp_revert_x_flag = 0 
> +ctp_revert_y_flag = 0 
> +ctp_exchange_x_y_flag = 1 
> +ctp_int_port = port:PB05<4> 
> +ctp_wakeup = port:PH01<1><1> 
> + 
> +[ctp_list_para] 
> +ctp_det_used = 1 
> +ft5x_ts = 1 
> +gt82x = 1 
> +gslX680 = 1 
> +gslX680new = 0 
> +gt9xx_ts = 1 
> +gt9xxf_ts = 0 
> +gt811 = 1 
> +gt818 = 1 
> +zet622x = 1 
> +aw5306_ts = 1 
> + 
> +[tkey_para] 
> +tkey_used = 0 
> +tkey_twi_id = 
> +tkey_twi_addr = 
> +tkey_int = 
> + 
> +[motor_para] 
> +motor_used = 0 
>

Re: [linux-sunxi] [PATCH u-boot-sunxi.git] sunxi: dram: checkpatch.pl cleanups

[Hans de Goede]

Hi,

On 03/23/2014 04:13 PM, Ian Campbell wrote:
> On Sat, 2014-03-22 at 20:22 +0100, Hans de Goede wrote:
>> One thing that stands out when doing a diff against sunxi-merge-v2014.04-rc2
>> is this:
>>
>> --- u-boot/drivers/net/designware.c 2014-03-21 16:26:42.229522420 +0100
>> +++ u-boot-sunxi/drivers/net/designware.c   2014-03-22 
>> 17:21:51.907879720 +
>> @@ -249,10 +249,10 @@
>> rx_descs_init(dev);
>> tx_descs_init(dev);
>>
>> -   writel(FIXEDBURST | PRIORXTX_41 | BURST_16, &dma_p->busmode);
>> +   writel(FIXEDBURST | PRIORXTX_41 | BURST_8, &dma_p->busmode);
>>
>> -   writel(readl(&dma_p->opmode) | FLUSHTXFIFO | STOREFORWARD,
>> -  &dma_p->opmode);
>> +   writel(readl(&dma_p->opmode) | FLUSHTXFIFO | STOREFORWARD |
>> +   TXSECONDFRAME, &dma_p->opmode);
>>
>> writel(readl(&dma_p->opmode) | RXSTART | TXSTART, &dma_p->opmode);
>>
>>
>> Which we should probably fix given that you've enabled gmac support.
> 
> Things work for me without.

IIRC the BURST_8 is necessary to get certain traffic patterns to not cause
corruption. Don't know about the rest. Wens probably knows best.

> I was under the impression that Wens (or
> someone else) had this under control WRT upstreaming so I was leaving it
> for now,

I'm not sure wens, or anyone for that matter is actively working on gmac
u-boot support.

> it can easily go in as an independent fix AFAICT.

It can and it should, but first we need some more info I guess, wens ?

>> I also noticed that in include/configs/sunxi-common.h you've a formatting
>> fix for the CONFIG_PHY_ADDR #define which is not yet in u-boot-sunxi.
> 
> CONFIG_PHY_ADDR arrived as part of the merge of v2014.04-rc2, so the fix
> got folded into the merge when I redid it.

Ah, ok.

> 
> I might manage a v3, which will be a couple of cleanups and a lot of
> clarifications about licensing, today, or I might watch game of thrones
> and do v3 later in the week, lets see how it goes...

Sounds good. I hope that your license clarification will be good enough
for upstream, and thanks for working on this.

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] Testing of Line In my A20 board.

[Rajesh Mallah]

Dear Puneet,

The line In needs to be tested with a mic preamplifier . Do not expect to
plugin a mic
and record voice.

in case of cubieboard read below

http://linux-sunxi.org/Cubieboard/FAQ#Looks_like_there_are_two_3.5mm_jacks._Are_the_HP_out_and_Mic_in.3F

regds
mallah.

-- 
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] Re: How to boot from onboard eMMC ?

[Rajesh Mallah]

On Tue, Mar 18, 2014 at 8:50 AM, simon wong  wrote:

> Hi,
> Mallah's method is OK. Recompile the u-boot.
>
> Thanks.
>
>
Hi ,  The method was not OK . i did it becoz of lack of skills and
patience. The right method
was indicated in the new device how to. regds -- mallah.

-- 
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] A10 versus A20 , gtkperf result.

[Rajesh Mallah]

Hi ,

I use gtkperf to get an idea of 2D graphics performance.

the A20 based Mele M3  completes in 19secs
the A10 based Cubieboard1 completes in 32 secs.

both using fbturbo xorg driver .

Is that much difference expected or does it needs to
be _further_ investigated ? please lemme know.

Regds
mallah.

-- 
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] uboot for Mele M3 A20

[Rajesh Mallah]

Hi,

I regularly search Alibaba market place for devices (TV boxes) can be
reused as low powered general purpose computers. Many of such devices have
debug
ports ( some do not have also ).

Most allwinner based devices on marketplace are A20 based, 1 GB model
A10 and A31  are not seen in general. In Quad core segment generally device
makers are
going for RK3188.  In in dual core segment AMLogic MX is also seen along
with RK3066.

My question is that is it really worth documenting such allwinner devices
in linux-sunxi
website ?

There is no surety if such devices will even be seen after even 1 year down
the line.

Regds
mallah.

-- 
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.git] sunxi: dram: checkpatch.pl cleanups

[Ian Campbell]

On Sat, 2014-03-22 at 20:22 +0100, Hans de Goede wrote:
> One thing that stands out when doing a diff against sunxi-merge-v2014.04-rc2
> is this:
> 
> --- u-boot/drivers/net/designware.c 2014-03-21 16:26:42.229522420 +0100
> +++ u-boot-sunxi/drivers/net/designware.c   2014-03-22 17:21:51.907879720 
> +
> @@ -249,10 +249,10 @@
> rx_descs_init(dev);
> tx_descs_init(dev);
> 
> -   writel(FIXEDBURST | PRIORXTX_41 | BURST_16, &dma_p->busmode);
> +   writel(FIXEDBURST | PRIORXTX_41 | BURST_8, &dma_p->busmode);
> 
> -   writel(readl(&dma_p->opmode) | FLUSHTXFIFO | STOREFORWARD,
> -  &dma_p->opmode);
> +   writel(readl(&dma_p->opmode) | FLUSHTXFIFO | STOREFORWARD |
> +   TXSECONDFRAME, &dma_p->opmode);
> 
> writel(readl(&dma_p->opmode) | RXSTART | TXSTART, &dma_p->opmode);
> 
> 
> Which we should probably fix given that you've enabled gmac support.

Things work for me without. I was under the impression that Wens (or
someone else) had this under control WRT upstreaming so I was leaving it
for now, it can easily go in as an independent fix AFAICT.

> I also noticed that in include/configs/sunxi-common.h you've a formatting
> fix for the CONFIG_PHY_ADDR #define which is not yet in u-boot-sunxi.

CONFIG_PHY_ADDR arrived as part of the merge of v2014.04-rc2, so the fix
got folded into the merge when I redid it.

I might manage a v3, which will be a couple of cleanups and a lot of
clarifications about licensing, today, or I might watch game of thrones
and do v3 later in the week, lets see how it goes...

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] uboot for Mele M3 A20

[Olliver Schinagl]

On 03/23/2014 11:51 AM, Rajesh Mallah wrote:

Oops I am so sorry saw this message today!. Yes i can contribute the
pictures. But
the bad news is that the RJ45 on the mele was flaky and i do not know if
it was
problem with that peice or in general. Hence i am considering some other
box now.
That's okay, no problem, the pics will still be very helpfull. Mostly 
pics of the PCB.


If you could do this in combination with:
http://linux-sunxi.org/New_Device_howto

that would be extremly appreciated, even if you do not intend to use the 
board any longer.


Olliver


regds
mallah.


On Sun, Mar 9, 2014 at 5:26 PM, Olliver Schinagl
mailto:oliver+l...@schinagl.nl>> wrote:

Hey Rajesh,

Did you ever manage to get some pictures taken of the inside?

Olliver


On 01/19/14 20:26, Rajesh Mallah wrote:

If you would have picked up on my earlier interra3 hint, you
would have
seen that that is actually configured in boards.cfg. No need
to hack
boards.c. Bad mallah!



Dear Oliver / List ,

firstly thanks for gesture to help . I was sort of despo. sunxi
has always
been a jinxed platform for me! .
Specially considering that fact that most of us are used to the
comforts of
x86.

I will definitely learn about boards.cfg and see how to add
definations.
You already pointed me to the correct wikis.
I will have to do a careful reading of those.

btw i overclocked the dram to 456 Mhz and it could run without
problems. I
then reduced it to 408 Mhz , seeing that gtkperf
does not yeild any benefits.

regds
mallah.


--
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+unsubscribe@__googlegroups.com
.
For more options, visit https://groups.google.com/d/__optout
.


--
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.


--
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+GIT 0/9] sunxi: upstream review based cleanups

[Olliver Schinagl]

On 03/22/2014 09:48 AM, Hans de Goede wrote:

Hi,

On 03/21/2014 09:14 PM, Olliver Schinagl wrote:

Hijacking your post here,

have you seen the 2GiB support patch? Any thoughts on how to proceed with that 
one? Upstream atleast listens to you now ;)


2GiB seems to just work upstream, despite them still using signed longs
for this.


Yeah, it works for sunxi equally well,

It's not a huge bug I suppose, but still, it's wrong isn't it. Wolfgang 
Denk even said 'this is wrong, you are right' but nothing came from it I 
think :)


Olliver


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] When does the I2C probe function get called

[Olliver Schinagl]

On 03/21/2014 04:10 PM, Dave McLaughlin wrote:

I am trying to port a touchscreen driver to my system and I have the
module building and installing.

I have added it to the auto detect code in device.c and I can see in
dmesg that the driver from i2c-core gets detected and the init function
is called.

What never gets called is the probe function which would setup the touch
IC and the interrupt handler.

When would this be called or how do I ensure this is called for my module?


This is the driver I am trying to use. It's under documents and
downloads. The manual explains how to integrate it except that the
information on page 7, 2.2 BSP Integration, section 2.2.2 does not match
up with anything I can find in the sun7i build.

http://www.touchrev.com/docs/fusion7/

Where in the sunxi build do I include this information or is this what's
in the sys_config.fex?

[ctp_para]
ctp_used = 1
ctp_name = "fusion_F0710A"
ctp_twi_id = 2
ctp_twi_addr = 0x10
ctp_screen_max_x = 800
ctp_screen_max_y = 480
ctp_revert_x_flag = 0
ctp_revert_y_flag = 0
ctp_exchange_x_y_flag = 0
ctp_int_port = port:PC19<6><1>
ctp_wakeup = port:PB13<1>


Touch screens are very fidgity to get working right, often due to some 
firmware that needs to be loaded, or is different between various 
implentations of the touchscreen IC.


I personally haven't seen the fusion series pass by the mailing list ...

Olliver


--
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.


--
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] Re: Build sunxi-next for A20

[Olliver Schinagl]

On 03/21/2014 12:03 PM, hmandevt...@gmail.com wrote:

i trying to update multi_v7_defconfig generated .config from sunxi-next with 
/proc/config of working debian image with kernel 3.4 but there are many 
sections and i haven't a good knowledge to know what update.
Could you say me a minimum CONFIG_ item that i should import from working 
config file ?


Er, .config from sunxi-next and 3.4 kernel are completly incompatible.

Both 3.4 and sunxi-next have their own defconfigs, they might not be 
perfect, but should be workable.


Olliver

--
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] how to flash android in NAND without phonixsuite ..

[Olliver Schinagl]

On 03/13/2014 08:12 AM, Puneet B wrote:

how to erase boot0 and boot1 in nand.

i tried by using mkfs.ext4 /dev/nand.

but still boot0 and boot1 is not erased.

kindly tell me how to erase the nand memory.

Regards
Punith


Boot0 and boot1 are BEFORE /dev/nand, you need specialized access to 
remove/invalidate them.


Yuq's mtd stuff may be actually used to invalidate nand and make the 
board refusing to load it.


--
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] uboot for Mele M3 A20

[Rajesh Mallah]

Oops I am so sorry saw this message today!. Yes i can contribute the
pictures. But
the bad news is that the RJ45 on the mele was flaky and i do not know if it
was
problem with that peice or in general. Hence i am considering some other
box now.
regds
mallah.


On Sun, Mar 9, 2014 at 5:26 PM, Olliver Schinagl wrote:

> Hey Rajesh,
>
> Did you ever manage to get some pictures taken of the inside?
>
> Olliver
>
>
> On 01/19/14 20:26, Rajesh Mallah wrote:
>
>> If you would have picked up on my earlier interra3 hint, you would have
>>> seen that that is actually configured in boards.cfg. No need to hack
>>> boards.c. Bad mallah!
>>>
>>
>>
>> Dear Oliver / List ,
>>
>> firstly thanks for gesture to help . I was sort of despo. sunxi has always
>> been a jinxed platform for me! .
>> Specially considering that fact that most of us are used to the comforts
>> of
>> x86.
>>
>> I will definitely learn about boards.cfg and see how to add definations.
>> You already pointed me to the correct wikis.
>> I will have to do a careful reading of those.
>>
>> btw i overclocked the dram to 456 Mhz and it could run without problems. I
>> then reduced it to 408 Mhz , seeing that gtkperf
>> does not yeild any benefits.
>>
>> regds
>> mallah.
>>
>>
> --
> 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.
>

-- 
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] FocalTech ft5x TouchScreen calibration (with the ft5x_ts driver)

[Alejandro Mery]

On 21/03/14 19:01, Drona Nagarajan wrote:

Hey, if this thread is any good now, I have managed to make the ft5x
driver to be detected as a touchpad. Like you on laptops. I can drag
the cursor around and do stuff like open an on screen keyboard. Write
commands on terminal and do some insmods that chroot on my host
couldnt. Am running Allwinner A20 processor on my tablet by the way.



hi Drona, can you resubmit?

Cheers,
Alejandro Mery

--
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] Re: uboot for Mele M3 A20

[Olliver Schinagl]

On 03/18/2014 03:41 AM, rova wrote:

Is there any way to turn off the red LED after booting up ?
You need to be way more specific here. My red led might be completly 
different then your red led.


If it is the 'power' led, its very easy to dim it.

Disconnect the power ;)

That's the only way afaik atm.

Olliver


On Thursday, January 16, 2014 3:50:39 AM UTC+8, Rajesh Mallah wrote:



Hi

i would like to install uboot on the internal MMC card of mele m3
(A20 , 1024MB)
model. could anyone suggest which uboot source and what board config
should work.

thanks (but sorry if the question was too novice).

regds
mallah.

--
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.


--
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] Re: [PATCH u-boot sunxi 3/4] sunxi: Implement reset_cpu

[Olliver Schinagl]

On 03/16/2014 07:38 PM, Ian Campbell wrote:

On Sun, 2014-03-16 at 14:53 +0100, Hans de Goede wrote:

There is no way to reset the cpu, so use the watchdog for this.


The sunxi.git tree does this by calling watchdog_set(0). I think it
would be better to introduce the generic watchdog support and the add
this a patch to use it for reset. Unless we don't plan to upstream the
watchdog stuff for some reason?

Not sure why cmd_watchdog.c is sunxi, seems like in principal it could
be generic.
If this is what I remember it to be, it was only hacked on and wasn't 
even used anymore. I think there where some issues with the wdt initially.


As always, Henrik knows best ;)

Olliver


Ian.


Signed-off-by: Hans de Goede 
---
  arch/arm/cpu/armv7/sunxi/board.c| 7 +++
  arch/arm/include/asm/arch-sunxi/timer.h | 4 
  2 files changed, 11 insertions(+)

diff --git a/arch/arm/cpu/armv7/sunxi/board.c b/arch/arm/cpu/armv7/sunxi/board.c
index 98cad43..2668d52 100644
--- a/arch/arm/cpu/armv7/sunxi/board.c
+++ b/arch/arm/cpu/armv7/sunxi/board.c
@@ -70,6 +70,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_RESTART, &wdog->ctl);
+   while (1);
  }

  /* do some early init */
diff --git a/arch/arm/include/asm/arch-sunxi/timer.h 
b/arch/arm/include/asm/arch-sunxi/timer.h
index f9d4f4f..1489b2e 100644
--- a/arch/arm/include/asm/arch-sunxi/timer.h
+++ b/arch/arm/include/asm/arch-sunxi/timer.h
@@ -27,6 +27,10 @@
  #ifndef _SUNXI_TIMER_H_
  #define _SUNXI_TIMER_H_

+#define WDT_CTRL_RESTART(0x1 << 0)
+#define WDT_MODE_EN (0x1 << 0)
+#define WDT_MODE_RESET_EN   (0x1 << 1)
+
  #ifndef __ASSEMBLY__

  #include 





--
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] did any one know interrupt controller of allwinner 10(on naked problem)

[Olliver Schinagl]

On 03/17/2014 02:04 PM, mosmith1...@gmail.com wrote:

recently i learn to use the interrupt controller of allwinner a10.but i just 
couldn't relocate the vector table to 0x.i am sure that the i did the 
relocation correctly,because there is no problem when i relocate the vector to 
0x4000(use p15,c12).I have been searching for a few days about this problem but 
couldn't find what the problem is.here is part of my code,could you give me a 
help,thanks(which is very rough):

Hi,

wow, you are doing asm yourself using an A10? pretty interesting and 
also i'm sure you are pretty much the only one ;)


The A10 has its own IRQ controller, chances are it was actually 
developped by AW inhouse. But nothing is certain here of course ...


I assume there is a reason you can't use regular linux?

Olliver


.global _start
.global copy_myself1
.extern main
.extern led_gpio_setup
.extern led2_light
.extern timer0_irq_c
.extern led1_off
.extern test
.extern main2
.extern uart0_puts
.extern load
_start:
b reset
ldr pc, _undefined_instruction
ldr pc, _software_interrupt
ldr pc, _prefetch_abort
ldr pc, _data_abort
ldr pc, _not_used
ldr pc, _irq
ldr pc, _fiq

_undefined_instruction: .word undefined_instruction
_software_interrupt:.word software_interrupt
_prefetch_abort:.word prefetch_abort
_data_abort:.word data_abort
_not_used:  .word not_used
_irq:   .word irq
_fiq:   .word fiq
_pad:   .word 0x12345678

.align 4
undefined_instruction:

ldr sp,=(0x8000);
adr r0,undefined_instruction_isr_string
bl uart0_puts

b .
software_interrupt:
ldr sp,=(0x8000-0x200);
adr r0,software_interrupt_isr_string
bl uart0_puts

b .
prefetch_abort:
ldr sp,=(0x8000-0x200);
adr r0,prefetch_abort_isr_string
bl uart0_puts
b .
data_abort:

ldr sp,=(0x8000-0x200);
adr r0,data_abort_isr_string
bl uart0_puts
b .
not_used:
fiq:

ldr sp,=(0x8000-0x200);
adr r0,fiq_isr_sring
bl uart0_puts
b .
.align 4
fiq_isr_sring:
.ascii "fiq isr\n"
.align 4
data_abort_isr_string:
.ascii "data_abort isr string\n"
.align 4
prefetch_abort_isr_string:
.ascii "prefetch_abort\n"
.align 4
software_interrupt_isr_string:
.ascii "software_interrupt\n"
.align 4
undefined_instruction_isr_string:
.ascii "undefined_instruction\n"
.align 4
irq_isr_string:
.ascii "irq request\n"
.align 4
irq:
ldr sp,=0x8000;
stmfd sp!,{r0-r12,lr}
adr r0,irq_isr_string
bl uart0_puts
bl timer0_irq_c;
ldmfd sp!,{r0-r12,lr}
subs pc,lr,#4;/*return from exception*/

reset:
mrs r0,cpsr;
orr r0,r0,#(0x3<<6);/*disable the fiq and irq*/
bic r0,r0,#0x1f
orr r0,r0,#0x13;/*turn to svc mode*/

bl cpu_init_cp15;/*mmu setup(diable mmu and related cache)*/
bl setup_sp;/*setup stack pointer(SP)*/
bl irq_stack_setup;
bl led_gpio_setup;

mrs r0,cpsr /*open the irq and fiq*/
bic r0,r0,#(0x3<<6);
msr cpsr,r0

adr r0,_start
mrc p15,0,r1,c1,c0,0
mrc p15,0,r2,c12,c0,0
mrc p15,0,r3,c12,c0,1

b main;
irq_stack_setup:
mov r1,sp;
mrs r2,cpsr;/*save the cpsr*/

mrs r0,cpsr
bic r0,r0,#0x1f
orr r0,r0,#0x12;/*turn to the irq mode*/
msr cpsr,r0;/*then we are in the irq mode*/
mov sp,r1;

msr cpsr,r2;/* restore the cpsr*/

sub r1,r1,#0x400 ;/*0x100:reserve irq stack size*/
mov sp,r1;

mov pc,lr;
cpu_init_cp15:
/*
 * Invalidate L1 I/D
 */
mov r0, #0  @ set up for MCR
mcr p15, 0, r0, c8, c7, 0   @ invalidate TLBs
mcr p15, 0, r0, c7, c5, 0   @ invalidate icache
mcr p15, 0, r0, c7, c5, 6   @ invalidate BP array
mcr p15, 0, r0, c7, c10, 4  @ DSB
mcr p15, 0, r0, c7, c5, 4   @ ISB

/*
 * disable MMU stuff and caches
 */
mrc p15, 0, r0, c1, c0, 0
bic r0, r0, #0x2000 @ clear bits 13 (--V-)
bic r0, r0, #0x0007 @ clear bits 2:0 (-CAM)
orr r0, r0, #0x0002 @ set bit 1 (--A-) Align
orr r0, r0, #0x0800 @ set bit 11 (Z---) BTB
#ifdef CONFIG_SYS_ICACHE_OFF
bic r0, r0, #0x1000 @ clear bit 12 (I) I-cache
#else
orr r0, r0, #0x1000 @ set bit 12 (I) I-cache
#endif
mcr p15, 0, r0, c1, c0, 0
mov pc, lr  @ back to my caller

.equ CONFIG_SYS_INIT_SP_ADDR,0x8000
setup_sp:
ldr r0,=CONFIG_SYS_INIT_SP_ADDR;
mo