RE: [linux-sunxi] [PATCH] sunxi-boards: a20: Add fex file for Brown Box A20

[Paul Jones]

Hi,
I was the author of the YBKJ A20 wiki page. I couldn’t find any identifying 
brands or manufacturers in the items I received or on the web. I think “YBKJ” 
is a stupid name (that I continually misspell) but I couldn’t for the life of 
me come up with anything better.

FYI I had to increase the core voltage on mine or decrease the ram speed to 
make it stable.

Cheers,
Paul.

From: linux-sunxi@googlegroups.com [mailto:linux-sunxi@googlegroups.com] On 
Behalf Of AndrewDB
Sent: Tuesday, 23 September 2014 7:18 AM
To: linux-sunxi@googlegroups.com
Subject: [linux-sunxi] [PATCH] sunxi-boards: a20: Add fex file for Brown Box A20

Check the YBKJ A20 JN device page in the wiki and specially my discussion with 
libv about the name of the device.
Honestly, I don't have any time to waste on arguing about the name of a 
generic, no-brand device, and whether XYZ1234 or StinkyFart2 is less arbitrary 
(I prefer the later though). Also it pisses me off to have every single line of 
doc I contribute zealously rewritten, sometimes with loss of information and 
added typos and English syntax errors. There, I said it.

BTW this is the fex file as I retrieved it from the Android nand. IMHO it can 
be further customized and improved upon, since it seems the original developer 
was in a hurry and just used default values from the SDK: the file shares the 
same [product] values as three other (completely different) Allwinner devices.

I already have the device booting Linux and I will upload the u-boot patch asap.

One final note: of particular interest with the Brown Box A20 is the fact that 
it is the least expensive A20/1GB RAM/Ethernet device available on AliExpress - 
and as of now it is also the least expensive dual-core Cortex-A7 device + 1GB 
RAM + Ethernet Linux appliance available on AliExpress. This point was 
particularly important for my actual Linux software project for this device.

Cheers and may the sunxi be with you all.
--
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.

[linux-sunxi] [PATCH] u-boot-sunxi: boards: Add support for Brown Box A20 device

[AndrewDB]

Again: check the YBKJ A20 JN device page in the wiki and specially my 
discussion with libv about the name of the device.

-- 
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.
>From c108f28ea67a75f69eb141802972a8f2d8dc9c11 Mon Sep 17 00:00:00 2001
From: AndrewDB 
Date: Mon, 22 Sep 2014 23:36:27 +0200
Subject: [PATCH] Added device Brown Box A20

---
 board/sunxi/Makefile|  1 +
 board/sunxi/dram_brownbox_a20.c | 31 +++
 boards.cfg  |  1 +
 3 files changed, 33 insertions(+)
 create mode 100644 board/sunxi/dram_brownbox_a20.c

diff --git a/board/sunxi/Makefile b/board/sunxi/Makefile
index eb612e5..227dff1 100644
--- a/board/sunxi/Makefile
+++ b/board/sunxi/Makefile
@@ -22,6 +22,7 @@ obj-$(CONFIG_AMPE_A76)		+= dram_sun5i_432_512_busw16_iow16.o
 obj-$(CONFIG_AUXTEK_T003)	+= dram_auxtek_t003.o
 obj-$(CONFIG_AUXTEK_T004)	+= dram_sun5i_432_512_busw16_iow16.o
 obj-$(CONFIG_BA10_TV_BOX)	+= dram_sun4i_384_1024_iow8.o
+obj-$(CONFIG_BROWNBOX_A20)	+= dram_brownbox_a20.o
 obj-$(CONFIG_COBY_MID7042)	+= dram_sun4i_408_1024_iow16.o
 obj-$(CONFIG_COBY_MID8042)	+= dram_sun4i_360_1024_iow16.o
 obj-$(CONFIG_COBY_MID9742)	+= dram_sun4i_408_1024_iow16.o
diff --git a/board/sunxi/dram_brownbox_a20.c b/board/sunxi/dram_brownbox_a20.c
new file mode 100644
index 000..8afbd91
--- /dev/null
+++ b/board/sunxi/dram_brownbox_a20.c
@@ -0,0 +1,31 @@
+/* this file is generated, don't edit it yourself */
+
+#include "common.h"
+#include 
+
+static struct dram_para dram_para = {
+	.clock = 384,
+	.type = 3,
+	.rank_num = 1,
+	.density = 4096,
+	.io_width = 16,
+	.bus_width = 32,
+	.cas = 9,
+	.zq = 0x7f,
+	.odt_en = 0,
+	.size = 1024,
+	.tpr0 = 0x38d48893,
+	.tpr1 = 0xa0a0,
+	.tpr2 = 0x22a00,
+	.tpr3 = 0x00,
+	.tpr4 = 0x02,
+	.tpr5 = 0x00,
+	.emr1 = 0x04,
+	.emr2 = 0x10,
+	.emr3 = 0x00,
+};
+
+unsigned long sunxi_dram_init(void)
+{
+	return dramc_init(&dram_para);
+}
diff --git a/boards.cfg b/boards.cfg
index fa2faed..996b50c 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -390,6 +390,7 @@ Active  arm armv7  sunxi   -   sunxi
 Active  arm armv7  sunxi   -   sunxi   ba10_tv_box  sun4i:BA10_TV_BOX,SPL,SUNXI_EMAC  -
 Active  arm armv7  sunxi   -   sunxi   Bananapi sun7i:BANANAPI,SPL,SUNXI_GMAC,RGMII,MACPWR=SUNXI_GPH(23),STATUSLED=244,STATUSLED1=245,FAST_MBUS   -
 Active  arm armv7  sunxi   -   sunxi   Bananapi_FEL sun7i:BANANAPI,SPL_FEL,SUNXI_GMAC,RGMII,MACPWR=SUNXI_GPH(23),STATUSLED=244,STATUSLED1=245,FAST_MBUS   -
+Active  arm armv7  sunxi   -   sunxi   BrownBox-A20 sun7i:BROWNBOX_A20,SPL,NO_AXP,SUNXI_EMAC,STATUSLED=244   -
 Active  arm armv7  sunxi   -   sunxi   Coby_MID7042 sun4i:COBY_MID7042,SPL-
 Active  arm armv7  sunxi   -   sunxi   Coby_MID8042 sun4i:COBY_MID8042,SPL-
 Active  arm armv7  sunxi   -   sunxi   Coby_MID9742 sun4i:COBY_MID9742,SPL-
-- 
1.9.1

[linux-sunxi] [PATCH] sunxi-boards: a20: Add fex file for Brown Box A20

[AndrewDB]

Check the YBKJ A20 JN device page in the wiki and specially my discussion 
with libv about the name of the device.
Honestly, I don't have any time to waste on arguing about the name of a 
generic, no-brand device, and whether XYZ1234 or StinkyFart2 is less 
arbitrary (I prefer the later though). Also it pisses me off to have every 
single line of doc I contribute zealously rewritten, sometimes with loss of 
information and added typos and English syntax errors. There, I said it.

BTW this is the fex file as I retrieved it from the Android nand. IMHO it 
can be further customized and improved upon, since it seems the original 
developer was in a hurry and just used default values from the SDK: the 
file shares the same [product] values as three other (completely different) 
Allwinner devices.

I already have the device booting Linux and I will upload the u-boot patch 
asap.

One final note: of particular interest with the Brown Box A20 is the fact 
that it is the least expensive A20/1GB RAM/Ethernet device available on 
AliExpress - and as of now it is also the least expensive dual-core 
Cortex-A7 device + 1GB RAM + Ethernet Linux appliance available on 
AliExpress. This point was particularly important for my actual Linux 
software project for this device.

Cheers and may the sunxi be with you all.

-- 
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.
>From 097de6fd883c17e1b610cec3cf58b9d8aa02a1c7 Mon Sep 17 00:00:00 2001
From: AndrewBCN 
Date: Mon, 22 Sep 2014 18:09:53 +0200
Subject: [PATCH] Added fex file for Brown Box A20 device

---
 sys_config/a20/brownbox_a20.fex | 1039 +++
 1 file changed, 1039 insertions(+)
 create mode 100644 sys_config/a20/brownbox_a20.fex

diff --git a/sys_config/a20/brownbox_a20.fex b/sys_config/a20/brownbox_a20.fex
new file mode 100644
index 000..df5b41b
--- /dev/null
+++ b/sys_config/a20/brownbox_a20.fex
@@ -0,0 +1,1039 @@
+[product]
+version = "100"
+machine = "sugar-ref001"
+
+[platform]
+eraseflag = 1
+
+[target]
+boot_clock = 912
+dcdc2_vol = 1400
+dcdc3_vol = 1250
+ldo2_vol = 3000
+ldo3_vol = 2800
+ldo4_vol = 2800
+power_start = 0
+storage_type = -1
+usb_recovery = 0
+
+[clock]
+pll3 = 297
+pll4 = 300
+pll6 = 600
+pll7 = 297
+pll8 = 336
+
+[card_boot]
+logical_start = 40960
+sprite_gpio0 = port:PH20<1><0>
+sprite_work_delay = 500
+sprite_err_delay = 200
+
+[card0_boot_para]
+card_ctrl = 0
+card_high_speed = 1
+card_line = 4
+sdc_d1 = port:PF00<2><1>
+sdc_d0 = port:PF01<2><1>
+sdc_clk = port:PF02<2><1>
+sdc_cmd = port:PF03<2><1>
+sdc_d3 = port:PF04<2><1>
+sdc_d2 = port:PF05<2><1>
+
+[card2_boot_para]
+card_ctrl = 2
+card_high_speed = 1
+card_line = 4
+sdc_cmd = port:PC06<3><1>
+sdc_clk = port:PC07<3><1>
+sdc_d0 = port:PC08<3><1>
+sdc_d1 = port:PC09<3><1>
+sdc_d2 = port:PC10<3><1>
+sdc_d3 = port:PC11<3><1>
+
+[twi_para]
+twi_port = 0
+twi_scl = port:PB00<2>
+twi_sda = port:PB01<2>
+
+[uart_para]
+uart_debug_port = 0
+uart_debug_tx = port:PB22<2><1>
+uart_debug_rx = port:PB23<2><1>
+
+[uart_force_debug]
+uart_debug_port = 0
+uart_debug_tx = port:PF02<4><1>
+uart_debug_rx = port:PF04<4><1>
+
+[jtag_para]
+jtag_enable = 1
+jtag_ms = port:PB14<3>
+jtag_ck = port:PB15<3>
+jtag_do = port:PB16<3>
+jtag_di = port:PB17<3>
+
+[pm_para]
+standby_mode = 0
+usbhid_wakeup_enable = 1
+
+[dram_para]
+dram_baseaddr = 0x4000
+dram_clk = 384
+dram_type = 3
+dram_rank_num = -1
+dram_chip_density = -1
+dram_io_width = -1
+dram_bus_width = -1
+dram_cas = 9
+dram_zq = 0x7f
+dram_odt_en = 0
+dram_size = -1
+dram_tpr0 = 0x38d48893
+dram_tpr1 = 0xa0a0
+dram_tpr2 = 0x22a00
+dram_tpr3 = 0x0
+dram_tpr4 = 0x0
+dram_tpr5 = 0x0
+dram_emr1 = 0x4
+dram_emr2 = 0x10
+dram_emr3 = 0x0
+
+[mali_para]
+mali_used = 1
+mali_clkdiv = 1
+
+[emac_para]
+emac_used = 1
+emac_rxd3 = port:PA00<2>
+emac_rxd2 = port:PA01<2>
+emac_rxd1 = port:PA02<2>
+emac_rxd0 = port:PA03<2>
+emac_txd3 = port:PA04<2>
+emac_txd2 = port:PA05<2>
+emac_txd1 = port:PA06<2>
+emac_txd0 = port:PA07<2>
+emac_rxclk = port:PA08<2>
+emac_rxerr = port:PA09<2>
+emac_rxdV = port:PA10<2>
+emac_mdc = port:PA11<2>
+emac_mdio = port:PA12<2>
+emac_txen = port:PA13<2>
+emac_txclk = port:PA14<2>
+emac_crs = port:PA15<2>
+emac_col = port:PA16<2>
+emac_reset = port:PA17<1>
+
+[twi0_para]
+twi0_used = 1
+twi0_scl = port:PB00<2>
+twi0_sda = port:PB01<2>
+
+[twi1_para]
+twi1_used = 1
+twi1_scl = port:PB18<2>
+twi1_sda = port:PB19<2>
+
+[twi2_para]
+twi2_used = 1
+twi2_scl = port:PB20<2>
+twi2_sda = port:PB21<2>
+
+[twi3_para]
+twi3_used = 1
+twi3_scl = port:PI00<3>
+twi3_sda = port:PI01<3>
+
+[twi4_para]
+twi4_used = 1
+twi4_scl = port:PI02<3>
+twi4_sda = port:PI03<3>
+
+[uart_para0]
+uart_used = 1
+uart_port = 0
+uart_type = 2
+uart_tx = port:PB22<2><1>
+uart_rx = port:PB23<2><1>
+
+[uart_para

Re: [linux-sunxi] Availability of A80 boards to developers

[Simos Xenitellis]

On Mon, Sep 22, 2014 at 11:14 PM, Olliver Schinagl 
wrote:

> Hi list,
>
> long time, no write.
>
> Where did this come from may I ask? I was in contact with Eva about a
> month or so ago (august) where I supplied them with a list of code
> committers. Did you meanwhile submit this list? I do hope we are not asking
> in tripples and making AW feel we're just being greedy.
>
> I'll go read the rest of this thread now :)
>

Hi Olliver,

My contact for this was Eva as well, thus there should not be an issue
about greediness.
The way I approached this was to ask for developers to email me if they are
interested for the dev board,
considering that the initial work on the A80 would be quite low level.

I think that there is interest from Allwinner to assist the community with
hardware.
If these initial boards are put into good use, then it is highly likely
that there will be more rounds of donations.

Simos


>
> Olliver
>
>
> On 09/11/2014 04:22 PM, Simos Xenitellis wrote:
>
>> Hi All,
>>
>> I asked Allwinner about the possibility of donation of a few A80
>> developer boards to developers and I got a positive response. So, I'll
>> be doing the clerical work to arrange the donation.
>>
>> There should be several batches of boards being donated.
>> This first batch is for five A80 OptimusBoard developer boards. I think
>> they should be coming in the packaging that is shown at
>> http://community.arm.com/thread/6449
>>
>> The criteria are:
>> 1. You have already done some relevant work with other Allwinner SoCs.
>> 2. You plan to do work with the board towards mainline Linux support
>> (describe what).
>> This also includes any work with u-boot or other packages that let the
>> A80 boot with a mainline kernel.
>>
>> Send me mail in private if you are interested to receive one.
>> I'll process the requests and forward to Allwinner so that they can send
>> the boards.
>> If there are more than five requests, I'll keep the details for the
>> subsequent batch.
>>
>> Simos
>>
>> --
>> 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.
>

-- 
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] Availability of A80 boards to developers

[Olliver Schinagl]

Hi list,

long time, no write.

Where did this come from may I ask? I was in contact with Eva about a 
month or so ago (august) where I supplied them with a list of code 
committers. Did you meanwhile submit this list? I do hope we are not 
asking in tripples and making AW feel we're just being greedy.


I'll go read the rest of this thread now :)

Olliver

On 09/11/2014 04:22 PM, Simos Xenitellis wrote:

Hi All,

I asked Allwinner about the possibility of donation of a few A80
developer boards to developers and I got a positive response. So, I'll
be doing the clerical work to arrange the donation.

There should be several batches of boards being donated.
This first batch is for five A80 OptimusBoard developer boards. I think
they should be coming in the packaging that is shown at
http://community.arm.com/thread/6449

The criteria are:
1. You have already done some relevant work with other Allwinner SoCs.
2. You plan to do work with the board towards mainline Linux support
(describe what).
This also includes any work with u-boot or other packages that let the
A80 boot with a mainline kernel.

Send me mail in private if you are interested to receive one.
I'll process the requests and forward to Allwinner so that they can send
the boards.
If there are more than five requests, I'll keep the details for the
subsequent batch.

Simos

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

[linux-sunxi] Re: [PATCH v3 1/2] mtd: nand: support ONFI timing mode retrieval for non-ONFI NANDs

[Brian Norris]

> diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
> index b7c1199..b0b74cc 100644
> --- a/include/linux/mtd/nand.h
> +++ b/include/linux/mtd/nand.h
> @@ -587,6 +587,11 @@ struct nand_buffers {
>   * @ecc_step_ds: [INTERN] ECC step required by the @ecc_strength_ds,
>   *  also from the datasheet. It is the recommended ECC 
> step
>   *   size, if known; if unknown, set to zero.
> + * @onfi_timing_mode_default: [INTERN] default ONFI timing mode. This field 
> is
> + * either deduced from the datasheet if the NAND
> + * chip is not ONFI compliant or set to 0 if it is
> + * (an ONFI chip is always configured in mode 0
> + * after a NAND reset)

This is probably OK only if every NAND chip is at least as fast as ONFI
mode 0. For older / legacy flash, I'm not sure if that's 100% true.
Maybe we'll need an UNKNOWN value, for those whose timing information is
not known?

Anyway, I think this is OK for now. Pushed the series to l2-mtd.git.
Thanks!

>   * @numchips:[INTERN] number of physical chips
>   * @chipsize:[INTERN] the size of one chip for multichip 
> arrays
>   * @pagemask:[INTERN] page number mask = number of (pages / 
> chip) - 1

Brian

-- 
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 v2 1/2] mtd: nand: support ONFI timing mode retrieval for non-ONFI NANDs

[Boris BREZILLON]

On Mon, 22 Sep 2014 10:58:34 -0700
Brian Norris  wrote:

> On Mon, Sep 22, 2014 at 04:25:10PM +0200, Boris BREZILLON wrote:
> > Add an onfi_timing_mode_default field to nand_chip and nand_flash_dev in
> > order to support NAND timings definition for non-ONFI NAND.
> > 
> > NAND that support better timings mode than the default one have to define
> > a new entry in the nand_ids table.
> > 
> > The default timing mode should be deduced from timings description from
> > the datasheet and the ONFI specification
> > (www.onfi.org/~/media/ONFI/specs/onfi_3_1_spec.pdf, chapter 4.15
> > "Timing Parameters").
> > You should choose the closest mode that fit the timings requirements of
> > your NAND chip.
> > 
> > Signed-off-by: Boris BREZILLON 
> 
> You have some (new?) checkpatch warnings:
> 

Sorry for that. I just sent a new version fixing those warnings.

Best Regards,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

-- 
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 v3 1/2] mtd: nand: support ONFI timing mode retrieval for non-ONFI NANDs

[Boris BREZILLON]

Add an onfi_timing_mode_default field to nand_chip and nand_flash_dev in
order to support NAND timings definition for non-ONFI NAND.

NAND that support better timings mode than the default one have to define
a new entry in the nand_ids table.

The default timing mode should be deduced from timings description from
the datasheet and the ONFI specification
(www.onfi.org/~/media/ONFI/specs/onfi_3_1_spec.pdf, chapter 4.15
"Timing Parameters").
You should choose the closest mode that fit the timings requirements of
your NAND chip.

Signed-off-by: Boris BREZILLON 
---
 drivers/mtd/nand/nand_base.c |  2 ++
 include/linux/mtd/nand.h | 11 +++
 2 files changed, 13 insertions(+)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index ae6e7c4..c37fa2a 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -3594,6 +3594,8 @@ static bool find_full_id_nand(struct mtd_info *mtd, 
struct nand_chip *chip,
chip->options |= type->options;
chip->ecc_strength_ds = NAND_ECC_STRENGTH(type);
chip->ecc_step_ds = NAND_ECC_STEP(type);
+   chip->onfi_timing_mode_default =
+   type->onfi_timing_mode_default;
 
*busw = type->options & NAND_BUSWIDTH_16;
 
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index b7c1199..b0b74cc 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -587,6 +587,11 @@ struct nand_buffers {
  * @ecc_step_ds:   [INTERN] ECC step required by the @ecc_strength_ds,
  *  also from the datasheet. It is the recommended ECC step
  * size, if known; if unknown, set to zero.
+ * @onfi_timing_mode_default: [INTERN] default ONFI timing mode. This field is
+ *   either deduced from the datasheet if the NAND
+ *   chip is not ONFI compliant or set to 0 if it is
+ *   (an ONFI chip is always configured in mode 0
+ *   after a NAND reset)
  * @numchips:  [INTERN] number of physical chips
  * @chipsize:  [INTERN] the size of one chip for multichip arrays
  * @pagemask:  [INTERN] page number mask = number of (pages / chip) - 1
@@ -671,6 +676,7 @@ struct nand_chip {
uint8_t bits_per_cell;
uint16_t ecc_strength_ds;
uint16_t ecc_step_ds;
+   int onfi_timing_mode_default;
int badblockpos;
int badblockbits;
 
@@ -773,6 +779,10 @@ struct nand_chip {
  *   @ecc_step_ds in nand_chip{}, also from the datasheet.
  *   For example, the "4bit ECC for each 512Byte" can be set with
  *   NAND_ECC_INFO(4, 512).
+ * @onfi_timing_mode_default: the default ONFI timing mode entered after a NAND
+ *   reset. Should be deduced from timings described
+ *   in the datasheet.
+ *
  */
 struct nand_flash_dev {
char *name;
@@ -793,6 +803,7 @@ struct nand_flash_dev {
uint16_t strength_ds;
uint16_t step_ds;
} ecc;
+   int onfi_timing_mode_default;
 };
 
 /**
-- 
1.9.1

-- 
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 v3 0/2] mtd: nand: support ONFI timings mode retrieval for non-ONFI NANDs

[Boris BREZILLON]

Hi,

Following the series adding ONFI timing mode support, here is a series
adding support for timing mode retrieval on non-ONFI NANDs.

It just adds a new field to the nand_chip and nand_flash_dev struct so
that anyone can define its chip requirements in the nand_ids table.

The 2nd patch serves as an example and adds an entry for the Hynix
H27UCG8T2ATR-BC NAND chip used on the Cubietruck board.

Best Regards,

Boris

Changes since v2:
- fix checkpatch warnings

Changes since v1:
- fix H27UCG8T2ATR-BC definition
- rename onfi_timing_mode_ds field into onfi_timing_mode_default

Boris BREZILLON (2):
  mtd: nand: support ONFI timing mode retrieval for non-ONFI NANDs
  mtd: nand: add Hynix's H27UCG8T2ATR-BC to nand_ids table

 drivers/mtd/nand/nand_base.c |  2 ++
 drivers/mtd/nand/nand_ids.c  |  4 
 include/linux/mtd/nand.h | 11 +++
 3 files changed, 17 insertions(+)

-- 
1.9.1

-- 
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 v3 2/2] mtd: nand: add Hynix's H27UCG8T2ATR-BC to nand_ids table

[Boris BREZILLON]

Add the full description of the Hynix H27UCG8T2ATR-BC NAND chip in the
nand_ids table so that we can later use the NAND ECC infos and ONFI timings
mode in controller drivers.

Signed-off-by: Boris BREZILLON 
---
 drivers/mtd/nand/nand_ids.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/mtd/nand/nand_ids.c b/drivers/mtd/nand/nand_ids.c
index 3d7c89f..fbde8910 100644
--- a/drivers/mtd/nand/nand_ids.c
+++ b/drivers/mtd/nand/nand_ids.c
@@ -46,6 +46,10 @@ struct nand_flash_dev nand_flash_ids[] = {
{"SDTNRGAMA 64G 3.3V 8-bit",
{ .id = {0x45, 0xde, 0x94, 0x93, 0x76, 0x50} },
  SZ_16K, SZ_8K, SZ_4M, 0, 6, 1280, NAND_ECC_INFO(40, SZ_1K) },
+   {"H27UCG8T2ATR-BC 64G 3.3V 8-bit",
+   { .id = {0xad, 0xde, 0x94, 0xda, 0x74, 0xc4} },
+ SZ_8K, SZ_8K, SZ_2M, 0, 6, 640, NAND_ECC_INFO(40, SZ_1K),
+ 4 },
 
LEGACY_ID_NAND("NAND 4MiB 5V 8-bit",   0x6B, 4, SZ_8K, SP_OPTIONS),
LEGACY_ID_NAND("NAND 4MiB 3,3V 8-bit", 0xE3, 4, SZ_8K, SP_OPTIONS),
-- 
1.9.1

-- 
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 v2 1/2] mtd: nand: support ONFI timing mode retrieval for non-ONFI NANDs

[Brian Norris]

On Mon, Sep 22, 2014 at 04:25:10PM +0200, Boris BREZILLON wrote:
> Add an onfi_timing_mode_default field to nand_chip and nand_flash_dev in
> order to support NAND timings definition for non-ONFI NAND.
> 
> NAND that support better timings mode than the default one have to define
> a new entry in the nand_ids table.
> 
> The default timing mode should be deduced from timings description from
> the datasheet and the ONFI specification
> (www.onfi.org/~/media/ONFI/specs/onfi_3_1_spec.pdf, chapter 4.15
> "Timing Parameters").
> You should choose the closest mode that fit the timings requirements of
> your NAND chip.
> 
> Signed-off-by: Boris BREZILLON 

You have some (new?) checkpatch warnings:

WARNING: please, no space before tabs
#49: FILE: include/linux/mtd/nand.h:591:
+ * ^I^I^I  either deduced from the datasheet if the NAND$

WARNING: please, no space before tabs
#50: FILE: include/linux/mtd/nand.h:592:
+ * ^I^I^I  chip is not ONFI compliant or set to 0 if it is$

WARNING: please, no space before tabs
#51: FILE: include/linux/mtd/nand.h:593:
+ * ^I^I^I  (an ONFI chip is always configured in mode 0$

WARNING: please, no space before tabs
#52: FILE: include/linux/mtd/nand.h:594:
+ * ^I^I^I  after a NAND reset)$

total: 0 errors, 4 warnings, 43 lines checked

Your patch has style problems, please review.

If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.

Brian

> ---
>  drivers/mtd/nand/nand_base.c |  2 ++
>  include/linux/mtd/nand.h | 11 +++
>  2 files changed, 13 insertions(+)
> 
> diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
> index ae6e7c4..c37fa2a 100644
> --- a/drivers/mtd/nand/nand_base.c
> +++ b/drivers/mtd/nand/nand_base.c
> @@ -3594,6 +3594,8 @@ static bool find_full_id_nand(struct mtd_info *mtd, 
> struct nand_chip *chip,
>   chip->options |= type->options;
>   chip->ecc_strength_ds = NAND_ECC_STRENGTH(type);
>   chip->ecc_step_ds = NAND_ECC_STEP(type);
> + chip->onfi_timing_mode_default =
> + type->onfi_timing_mode_default;
>  
>   *busw = type->options & NAND_BUSWIDTH_16;
>  
> diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
> index b7c1199..e795fbf 100644
> --- a/include/linux/mtd/nand.h
> +++ b/include/linux/mtd/nand.h
> @@ -587,6 +587,11 @@ struct nand_buffers {
>   * @ecc_step_ds: [INTERN] ECC step required by the @ecc_strength_ds,
>   *  also from the datasheet. It is the recommended ECC 
> step
>   *   size, if known; if unknown, set to zero.
> + * @onfi_timing_mode_default: [INTERN] default ONFI timing mode. This field 
> is
> + * either deduced from the datasheet if the NAND
> + * chip is not ONFI compliant or set to 0 if it is
> + * (an ONFI chip is always configured in mode 0
> + * after a NAND reset)
>   * @numchips:[INTERN] number of physical chips
>   * @chipsize:[INTERN] the size of one chip for multichip 
> arrays
>   * @pagemask:[INTERN] page number mask = number of (pages / 
> chip) - 1
> @@ -671,6 +676,7 @@ struct nand_chip {
>   uint8_t bits_per_cell;
>   uint16_t ecc_strength_ds;
>   uint16_t ecc_step_ds;
> + int onfi_timing_mode_default;
>   int badblockpos;
>   int badblockbits;
>  
> @@ -773,6 +779,10 @@ struct nand_chip {
>   *   @ecc_step_ds in nand_chip{}, also from the datasheet.
>   *   For example, the "4bit ECC for each 512Byte" can be set with
>   *   NAND_ECC_INFO(4, 512).
> + * @onfi_timing_mode_default: the default ONFI timing mode entered after a 
> NAND
> + * reset. Should be deduced from timings described
> + * in the datasheet.
> + *
>   */
>  struct nand_flash_dev {
>   char *name;
> @@ -793,6 +803,7 @@ struct nand_flash_dev {
>   uint16_t strength_ds;
>   uint16_t step_ds;
>   } ecc;
> + int onfi_timing_mode_default;
>  };
>  
>  /**
> -- 
> 1.9.1
> 

-- 
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 v5 0/2] mtd: nand: add sunxi NAND flash controller support

[Boris BREZILLON]

Hi,

This patch series adds support for the sunxi NAND Flash Controller (NFC)
block.

These two patches only add support for the basic NAND stuff:
 - NAND controller operations
 - SW and HW ECC handling (with both syndrome and normal ECC scheme)

If you want support for advanced features you can find it on my github
repo [1]:
 - HW randomization support
 - per partition ECC/Randomizer to handle bootloader partitions

DMA transfers are not supported yet, but I have reworked the OOB layout
when using the HW ECC scheme to match the one used when accessing the NAND
with DMA transfers (the available OOB bytes are placed at the end of the
OOB area).

This patch series depends on this patch [2] adding support for ONFI timing
mode retrieval on non-ONFI NANDs.

Best Regards,

Boris

[1]https://github.com/bbrezillon/linux-sunxi/tree/sunxi-nand-v5
[2]https://patchwork.ozlabs.org/patch/391968/

Changes since v4:
 - adapt to v2 of "mtd: nand: support ONFI timing mode retrieval for non-ONFI
   NANDs" series

Changes since v3:
 - removed nand core code modifications from the patch series (submitted
   separately)
 - added documentation to the code
 - forced timeout (a default timeout is used when none is provided by the
   caller) on controller operations
 - fixed coding style issues
 - removed unneeded irq field from the sunxi_nfc struct
 - fixed several memory leaks
 - reworked the NFC reset code (to avoid potential garbage config from the
   bootloader)
 - made use of ECC_EXCEPTION flag to prevent erased page from generating
   ECC errors
 - changed the OOB layout for HW ECC scheme

Changes since v2:
 - merge HW ECC implementation in base implementation patch
 - fix timing config when interfacing with an ONFI compatible chip

Changes since v1:
 - add HW ECC support
 - rework NAND timings retrieval (use ONFI timing mode instead of raw timings)
 - add nand-ecc-level property to specify NAND ECC requirements from DT

Boris BREZILLON (2):
  mtd: nand: add sunxi NAND flash controller support
  mtd: nand: add sunxi NFC dt bindings doc

Boris BREZILLON (2):
  mtd: nand: add sunxi NAND flash controller support
  mtd: nand: add sunxi NFC dt bindings doc

 .../devicetree/bindings/mtd/sunxi-nand.txt |   45 +
 drivers/mtd/nand/Kconfig   |6 +
 drivers/mtd/nand/Makefile  |1 +
 drivers/mtd/nand/sunxi_nand.c  | 1362 
 4 files changed, 1414 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mtd/sunxi-nand.txt
 create mode 100644 drivers/mtd/nand/sunxi_nand.c

-- 
1.9.1

-- 
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 v5 2/2] mtd: nand: add sunxi NFC dt bindings doc

[Boris BREZILLON]

Add the sunxi NAND Flash Controller dt bindings documentation.

Signed-off-by: Boris BREZILLON 
---
 .../devicetree/bindings/mtd/sunxi-nand.txt | 45 ++
 1 file changed, 45 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mtd/sunxi-nand.txt

diff --git a/Documentation/devicetree/bindings/mtd/sunxi-nand.txt 
b/Documentation/devicetree/bindings/mtd/sunxi-nand.txt
new file mode 100644
index 000..0273adb
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/sunxi-nand.txt
@@ -0,0 +1,45 @@
+Allwinner NAND Flash Controller (NFC)
+
+Required properties:
+- compatible : "allwinner,sun4i-a10-nand".
+- reg : shall contain registers location and length for data and reg.
+- interrupts : shall define the nand controller interrupt.
+- #address-cells: shall be set to 1. Encode the nand CS.
+- #size-cells : shall be set to 0.
+- clocks : shall reference nand controller clocks.
+- clock-names : nand controller internal clock names. Shall contain :
+* "ahb" : AHB gating clock
+* "mod" : nand controller clock
+
+Optional children nodes:
+Children nodes represent the available nand chips.
+
+Optional properties:
+- allwinner,rb : shall contain the native Ready/Busy ids.
+ or
+- rb-gpios : shall contain the gpios used as R/B pins.
+- nand-ecc-mode : one of the supported ECC modes ("hw", "hw_syndrome", "soft",
+  "soft_bch" or "none")
+
+see Documentation/devicetree/mtd/nand.txt for generic bindings.
+
+
+Examples:
+nfc: nand@01c03000 {
+   compatible = "allwinner,sun4i-a10-nand";
+   reg = <0x01c03000 0x1000>;
+   interrupts = <0 37 1>;
+   clocks = <&ahb_gates 13>, <&nand_clk>;
+   clock-names = "ahb", "mod";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&nand_pins_a &nand_cs0_pins_a &nand_rb0_pins_a>;
+   status = "okay";
+
+   nand@0 {
+   reg = <0>;
+   allwinner,rb = <0>;
+   nand-ecc-mode = "soft_bch";
+   };
+};
-- 
1.9.1

-- 
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 v5 1/2] mtd: nand: add sunxi NAND flash controller support

[Boris BREZILLON]

Add support for the sunxi NAND Flash Controller (NFC).

Signed-off-by: Boris BREZILLON 
---
 drivers/mtd/nand/Kconfig  |6 +
 drivers/mtd/nand/Makefile |1 +
 drivers/mtd/nand/sunxi_nand.c | 1362 +
 3 files changed, 1369 insertions(+)
 create mode 100644 drivers/mtd/nand/sunxi_nand.c

diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index f1cf503..bd94d12 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -513,4 +513,10 @@ config MTD_NAND_XWAY
  Enables support for NAND Flash chips on Lantiq XWAY SoCs. NAND is 
attached
  to the External Bus Unit (EBU).
 
+config MTD_NAND_SUNXI
+   tristate "Support for NAND on Allwinner SoCs"
+   depends on ARCH_SUNXI
+   help
+ Enables support for NAND Flash chips on Allwinner SoCs.
+
 endif # MTD_NAND
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index a035e7c..ff56eaf 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -49,5 +49,6 @@ obj-$(CONFIG_MTD_NAND_JZ4740) += jz4740_nand.o
 obj-$(CONFIG_MTD_NAND_GPMI_NAND)   += gpmi-nand/
 obj-$(CONFIG_MTD_NAND_XWAY)+= xway_nand.o
 obj-$(CONFIG_MTD_NAND_BCM47XXNFLASH)   += bcm47xxnflash/
+obj-$(CONFIG_MTD_NAND_SUNXI)   += sunxi_nand.o
 
 nand-objs := nand_base.o nand_bbt.o nand_timings.o
diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
new file mode 100644
index 000..4fcecfb
--- /dev/null
+++ b/drivers/mtd/nand/sunxi_nand.c
@@ -0,0 +1,1362 @@
+/*
+ * Copyright (C) 2013 Boris BREZILLON 
+ *
+ * Derived from:
+ * https://github.com/yuq/sunxi-nfc-mtd
+ * Copyright (C) 2013 Qiang Yu 
+ *
+ * https://github.com/hno/Allwinner-Info
+ * Copyright (C) 2013 Henrik Nordström 
+ *
+ * Copyright (C) 2013 Dmitriy B. 
+ * Copyright (C) 2013 Sergey Lapin 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#define pr_fmt(fmt)KBUILD_MODNAME ": " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define NFC_REG_CTL0x
+#define NFC_REG_ST 0x0004
+#define NFC_REG_INT0x0008
+#define NFC_REG_TIMING_CTL 0x000C
+#define NFC_REG_TIMING_CFG 0x0010
+#define NFC_REG_ADDR_LOW   0x0014
+#define NFC_REG_ADDR_HIGH  0x0018
+#define NFC_REG_SECTOR_NUM 0x001C
+#define NFC_REG_CNT0x0020
+#define NFC_REG_CMD0x0024
+#define NFC_REG_RCMD_SET   0x0028
+#define NFC_REG_WCMD_SET   0x002C
+#define NFC_REG_IO_DATA0x0030
+#define NFC_REG_ECC_CTL0x0034
+#define NFC_REG_ECC_ST 0x0038
+#define NFC_REG_DEBUG  0x003C
+#define NFC_REG_ECC_CNT0   0x0040
+#define NFC_REG_ECC_CNT1   0x0044
+#define NFC_REG_ECC_CNT2   0x0048
+#define NFC_REG_ECC_CNT3   0x004c
+#define NFC_REG_USER_DATA_BASE 0x0050
+#define NFC_REG_SPARE_AREA 0x00A0
+#define NFC_RAM0_BASE  0x0400
+#define NFC_RAM1_BASE  0x0800
+
+/* define bit use in NFC_CTL */
+#define NFC_EN BIT(0)
+#define NFC_RESET  BIT(1)
+#define NFC_BUS_WIDYH  BIT(2)
+#define NFC_RB_SEL BIT(3)
+#define NFC_CE_SEL GENMASK(26, 24)
+#define NFC_CE_CTL BIT(6)
+#define NFC_CE_CTL1BIT(7)
+#define NFC_PAGE_SIZE  GENMASK(11, 8)
+#define NFC_SAMBIT(12)
+#define NFC_RAM_METHOD BIT(14)
+#define NFC_DEBUG_CTL  BIT(31)
+
+/* define bit use in NFC_ST */
+#define NFC_RB_B2R BIT(0)
+#define NFC_CMD_INT_FLAG   BIT(1)
+#define NFC_DMA_INT_FLAG   BIT(2)
+#define NFC_CMD_FIFO_STATUSBIT(3)
+#define NFC_STABIT(4)
+#define NFC_NATCH_INT_FLAG BIT(5)
+#define NFC_RB_STATE0  BIT(8)
+#define NFC_RB_STATE1  BIT(9)
+#define NFC_RB_STATE2  BIT(10)
+#define NFC_RB_STATE3  BIT(11)
+
+/* define bit use in NFC_INT */
+#define NFC_B2R_INT_ENABLE BIT(0)
+#define NFC_CMD_INT_ENABLE BIT(1)
+#define NFC_DMA_INT_ENABLE BIT(2)
+#define NFC_INT_MASK   (NFC_B2R_INT_ENABLE | \
+NFC_CMD_INT_ENABLE | \
+NFC_DMA_INT_ENABLE)
+
+/* define bit use in NFC_CMD */
+#define NFC_CMD_LOW_BYTE   GENMASK(7, 0)
+#define NFC_CMD_HIGH_BYTE  GENMASK(15,

[linux-sunxi] [PATCH v2 2/2] mtd: nand: add Hynix's H27UCG8T2ATR-BC to nand_ids table

[Boris BREZILLON]

Add the full description of the Hynix H27UCG8T2ATR-BC NAND chip in the
nand_ids table so that we can later use the NAND ECC infos and ONFI timings
mode in controller drivers.

Signed-off-by: Boris BREZILLON 
---
 drivers/mtd/nand/nand_ids.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/mtd/nand/nand_ids.c b/drivers/mtd/nand/nand_ids.c
index 3d7c89f..fbde8910 100644
--- a/drivers/mtd/nand/nand_ids.c
+++ b/drivers/mtd/nand/nand_ids.c
@@ -46,6 +46,10 @@ struct nand_flash_dev nand_flash_ids[] = {
{"SDTNRGAMA 64G 3.3V 8-bit",
{ .id = {0x45, 0xde, 0x94, 0x93, 0x76, 0x50} },
  SZ_16K, SZ_8K, SZ_4M, 0, 6, 1280, NAND_ECC_INFO(40, SZ_1K) },
+   {"H27UCG8T2ATR-BC 64G 3.3V 8-bit",
+   { .id = {0xad, 0xde, 0x94, 0xda, 0x74, 0xc4} },
+ SZ_8K, SZ_8K, SZ_2M, 0, 6, 640, NAND_ECC_INFO(40, SZ_1K),
+ 4 },
 
LEGACY_ID_NAND("NAND 4MiB 5V 8-bit",   0x6B, 4, SZ_8K, SP_OPTIONS),
LEGACY_ID_NAND("NAND 4MiB 3,3V 8-bit", 0xE3, 4, SZ_8K, SP_OPTIONS),
-- 
1.9.1

-- 
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 v2 1/2] mtd: nand: support ONFI timing mode retrieval for non-ONFI NANDs

[Boris BREZILLON]

Add an onfi_timing_mode_default field to nand_chip and nand_flash_dev in
order to support NAND timings definition for non-ONFI NAND.

NAND that support better timings mode than the default one have to define
a new entry in the nand_ids table.

The default timing mode should be deduced from timings description from
the datasheet and the ONFI specification
(www.onfi.org/~/media/ONFI/specs/onfi_3_1_spec.pdf, chapter 4.15
"Timing Parameters").
You should choose the closest mode that fit the timings requirements of
your NAND chip.

Signed-off-by: Boris BREZILLON 
---
 drivers/mtd/nand/nand_base.c |  2 ++
 include/linux/mtd/nand.h | 11 +++
 2 files changed, 13 insertions(+)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index ae6e7c4..c37fa2a 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -3594,6 +3594,8 @@ static bool find_full_id_nand(struct mtd_info *mtd, 
struct nand_chip *chip,
chip->options |= type->options;
chip->ecc_strength_ds = NAND_ECC_STRENGTH(type);
chip->ecc_step_ds = NAND_ECC_STEP(type);
+   chip->onfi_timing_mode_default =
+   type->onfi_timing_mode_default;
 
*busw = type->options & NAND_BUSWIDTH_16;
 
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index b7c1199..e795fbf 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -587,6 +587,11 @@ struct nand_buffers {
  * @ecc_step_ds:   [INTERN] ECC step required by the @ecc_strength_ds,
  *  also from the datasheet. It is the recommended ECC step
  * size, if known; if unknown, set to zero.
+ * @onfi_timing_mode_default: [INTERN] default ONFI timing mode. This field is
+ *   either deduced from the datasheet if the NAND
+ *   chip is not ONFI compliant or set to 0 if it is
+ *   (an ONFI chip is always configured in mode 0
+ *   after a NAND reset)
  * @numchips:  [INTERN] number of physical chips
  * @chipsize:  [INTERN] the size of one chip for multichip arrays
  * @pagemask:  [INTERN] page number mask = number of (pages / chip) - 1
@@ -671,6 +676,7 @@ struct nand_chip {
uint8_t bits_per_cell;
uint16_t ecc_strength_ds;
uint16_t ecc_step_ds;
+   int onfi_timing_mode_default;
int badblockpos;
int badblockbits;
 
@@ -773,6 +779,10 @@ struct nand_chip {
  *   @ecc_step_ds in nand_chip{}, also from the datasheet.
  *   For example, the "4bit ECC for each 512Byte" can be set with
  *   NAND_ECC_INFO(4, 512).
+ * @onfi_timing_mode_default: the default ONFI timing mode entered after a NAND
+ *   reset. Should be deduced from timings described
+ *   in the datasheet.
+ *
  */
 struct nand_flash_dev {
char *name;
@@ -793,6 +803,7 @@ struct nand_flash_dev {
uint16_t strength_ds;
uint16_t step_ds;
} ecc;
+   int onfi_timing_mode_default;
 };
 
 /**
-- 
1.9.1

-- 
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 v2 0/2] mtd: nand: support ONFI timings mode retrieval for non-ONFI NANDs

[Boris BREZILLON]

Hi,

Following the series adding ONFI timing mode support, here is a series
adding support for timing mode retrieval on non-ONFI NANDs.

It just adds a new field to the nand_chip and nand_flash_dev struct so
that anyone can define its chip requirements in the nand_ids table.

The 2nd patch serves as an example and adds an entry for the Hynix
H27UCG8T2ATR-BC NAND chip used on the Cubietruck board.

Best Regards,

Boris

Changes since v1:
- fix H27UCG8T2ATR-BC definition
- rename onfi_timing_mode_ds field into onfi_timing_mode_default

Boris BREZILLON (2):
  mtd: nand: support ONFI timing mode retrieval for non-ONFI NANDs
  mtd: nand: add Hynix's H27UCG8T2ATR-BC to nand_ids table

 drivers/mtd/nand/nand_base.c |  2 ++
 drivers/mtd/nand/nand_ids.c  |  4 
 include/linux/mtd/nand.h | 11 +++
 3 files changed, 17 insertions(+)

-- 
1.9.1

-- 
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] OV2643 Camera on A20

[George Ioakimedes]

Yes, basic SCCB/I2C communication is working but the actual drivers do not 
work. From what I can tell all of the OmniVision cameras use the same 
SCCB/I2C communication and the only difference are the register definitions 
and settings.

Unfortunately I have not been successful in getting the drivers to work, 
they either crash the kernel or reply with an error. For some reason the 
drivers are written differently than what I seen from TI and Freescale and 
internet searching shows both of those platforms have working solutions.

I want to get this working but I am not a driver developer so my work is 
slow and wastes a lot time. I'm hoping to find someone to help with this 
project!

On Monday, September 22, 2014 6:58:09 AM UTC-7, Joseph Nguya wrote:
>
> Thanks, we'll try.
>
> On Monday, September 22, 2014 3:50:18 PM UTC+2, Jon Smirl wrote:
>>
>> On Mon, Sep 22, 2014 at 9:48 AM, Joseph Nguya  
>> wrote:
>>
>>> Are you able to share your ov2643.c driver; for what kernel was it built
>>>
>>> George is using OV5642.
>>
>>  
>>
>>> On Monday, September 22, 2014 3:30:23 PM UTC+2, Jon Smirl wrote:

 George has i2c working.

 On Mon, Sep 22, 2014 at 9:16 AM, Joseph Nguya  
 wrote:

> Hi Jon,
>
> The A20 does not support SCCB protocol. Did you manage to get a 
> working sccb driver for the ov2643 working over i2c for the A20? What did 
> you do to get it working.
>
> Thanks.
>
>
> On Sunday, January 5, 2014 7:19:05 PM UTC+2, Jon Smirl wrote:
>>
>> The unit has a Chinese Android build on it which is slowing me down. 
>>
>> I haven't figure out how to start adb Ethernet daemon on target 
>> device.
>>
>>
>> On Sun, Jan 5, 2014 at 12:01 PM, jons...@gmail.com > > wrote:
>>
>>>
>>>
>>>
>>> On Sun, Jan 5, 2014 at 11:55 AM, Michal Suchanek  
>>> wrote:
>>>
 On 5 January 2014 17:48, jons...@gmail.com  
 wrote:
 >
 >
 >
 > On Sun, Jan 5, 2014 at 11:43 AM, Michal Suchanek <
 hram...@gmail.com> wrote:
 >>
 >>
 >>
 >>
 >> On 5 January 2014 16:50, jons...@gmail.com  
 wrote:
 >>
 >>>
 >>>
 >>>
 >>> On Sun, Jan 5, 2014 at 5:38 AM, Michal Suchanek <
 hram...@gmail.com>

 >>> wrote:
 
  AFAIK the camera board is connected digitally so the noise is 
 something
  that is internal to the camera board.
 
  It is normal that under low light condition the image is 
 noisy. Did you
  try taking pictures in full daylight or using some photography 
 lighting?
 >>>
 >>>
 >>> I have four other USB webcams and none of them have this noise 
 under same
 >>> lighting conditions. I have two other Allwinner systems with 
 cameras and
 >>> they all have noise. I checked it out this morning under 
 sunlight. It is
 >>> better but the noise is still there.
 >>>
 >>> Maybe the camera images need some image processing that is not 
 getting
 >>> turned on under the Allwinner platform? All of the Allwinner 
 devices appear
 >>> to be running Allwinner SDK with only minor changes. They 
 probably all
 >>> copied each other.
 >>>
 >>> The datasheet for the image sensor is here:
 >>> http://files.virt2real.ru/docs/
 >>>
 >>> It is also possible that image processing features of the 
 sensor chip are
 >>> not properly enabled.
 >>>
 >>
 >> According to the datasheet the camera chip has various image 
 processing
 >> filters including noise reduction. Does the driver support 
 tuning these
 >> filters?
 >
 >
 > I can modify driver. But that triggers the whole problem of being 
 able to
 > rebuild the software for these devices. I'm trying to figure out 
 how to
 > extract the fex files. They are STBs and don't have normal 
 Android buttons.

 Meaning not even a FEL button?

 No OTG USB port. They put a hub chip on the board and only exposed 
>>> host port. 
>>>
>>>  
>>>
 Do you get access to the boot partition with adb?

 The other way would be to run a non-broken Linux system from SD 
 card.
 Getting at least serial or ethernet should be easy if the box has
 those. Or an USB Ethernet.

>>>
>>> It has Ethernet. I'm trying to figure it out, I haven't used Android 
>>> SDK with Ethernet before.
>>>  
>>>

 Thanks

 Michal

 --
 You received this message because you are subscribed to the Go

Re: [linux-sunxi] OV2643 Camera on A20

[Joseph Nguya]

Thanks, we'll try.

On Monday, September 22, 2014 3:50:18 PM UTC+2, Jon Smirl wrote:
>
> On Mon, Sep 22, 2014 at 9:48 AM, Joseph Nguya  > wrote:
>
>> Are you able to share your ov2643.c driver; for what kernel was it built
>>
>> George is using OV5642.
>
>  
>
>> On Monday, September 22, 2014 3:30:23 PM UTC+2, Jon Smirl wrote:
>>>
>>> George has i2c working.
>>>
>>> On Mon, Sep 22, 2014 at 9:16 AM, Joseph Nguya  
>>> wrote:
>>>
 Hi Jon,

 The A20 does not support SCCB protocol. Did you manage to get a working 
 sccb driver for the ov2643 working over i2c for the A20? What did you do 
 to 
 get it working.

 Thanks.


 On Sunday, January 5, 2014 7:19:05 PM UTC+2, Jon Smirl wrote:
>
> The unit has a Chinese Android build on it which is slowing me down. 
>
> I haven't figure out how to start adb Ethernet daemon on target device.
>
>
> On Sun, Jan 5, 2014 at 12:01 PM, jons...@gmail.com  
> wrote:
>
>>
>>
>>
>> On Sun, Jan 5, 2014 at 11:55 AM, Michal Suchanek  
>> wrote:
>>
>>> On 5 January 2014 17:48, jons...@gmail.com  
>>> wrote:
>>> >
>>> >
>>> >
>>> > On Sun, Jan 5, 2014 at 11:43 AM, Michal Suchanek <
>>> hram...@gmail.com> wrote:
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> On 5 January 2014 16:50, jons...@gmail.com  
>>> wrote:
>>> >>
>>> >>>
>>> >>>
>>> >>>
>>> >>> On Sun, Jan 5, 2014 at 5:38 AM, Michal Suchanek <
>>> hram...@gmail.com>
>>>
>>> >>> wrote:
>>> 
>>>  AFAIK the camera board is connected digitally so the noise is 
>>> something
>>>  that is internal to the camera board.
>>> 
>>>  It is normal that under low light condition the image is noisy. 
>>> Did you
>>>  try taking pictures in full daylight or using some photography 
>>> lighting?
>>> >>>
>>> >>>
>>> >>> I have four other USB webcams and none of them have this noise 
>>> under same
>>> >>> lighting conditions. I have two other Allwinner systems with 
>>> cameras and
>>> >>> they all have noise. I checked it out this morning under 
>>> sunlight. It is
>>> >>> better but the noise is still there.
>>> >>>
>>> >>> Maybe the camera images need some image processing that is not 
>>> getting
>>> >>> turned on under the Allwinner platform? All of the Allwinner 
>>> devices appear
>>> >>> to be running Allwinner SDK with only minor changes. They 
>>> probably all
>>> >>> copied each other.
>>> >>>
>>> >>> The datasheet for the image sensor is here:
>>> >>> http://files.virt2real.ru/docs/
>>> >>>
>>> >>> It is also possible that image processing features of the sensor 
>>> chip are
>>> >>> not properly enabled.
>>> >>>
>>> >>
>>> >> According to the datasheet the camera chip has various image 
>>> processing
>>> >> filters including noise reduction. Does the driver support tuning 
>>> these
>>> >> filters?
>>> >
>>> >
>>> > I can modify driver. But that triggers the whole problem of being 
>>> able to
>>> > rebuild the software for these devices. I'm trying to figure out 
>>> how to
>>> > extract the fex files. They are STBs and don't have normal Android 
>>> buttons.
>>>
>>> Meaning not even a FEL button?
>>>
>>> No OTG USB port. They put a hub chip on the board and only exposed 
>> host port. 
>>
>>  
>>
>>> Do you get access to the boot partition with adb?
>>>
>>> The other way would be to run a non-broken Linux system from SD card.
>>> Getting at least serial or ethernet should be easy if the box has
>>> those. Or an USB Ethernet.
>>>
>>
>> It has Ethernet. I'm trying to figure it out, I haven't used Android 
>> SDK with Ethernet before.
>>  
>>
>>>
>>> Thanks
>>>
>>> Michal
>>>
>>> --
>>> 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...@googlegroups.com.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>
>>
>>
>> -- 
>> Jon Smirl
>> jons...@gmail.com 
>>
>
>
>
> -- 
> Jon Smirl
> jons...@gmail.com 
>
  -- 
 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...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

>>>
>>>
>>>
>>> -- 
>>> Jon Smirl
>>> jons...@gmail.com 
>>>
>>  -- 
>> You received this message because you are subscribed to the Google Groups 
>> "linux-sunxi" group.
>> To unsubscribe fro

Re: [linux-sunxi] OV2643 Camera on A20

[jonsm...@gmail.com]

On Mon, Sep 22, 2014 at 9:48 AM, Joseph Nguya 
wrote:

> Are you able to share your ov2643.c driver; for what kernel was it built
>
> George is using OV5642.



> On Monday, September 22, 2014 3:30:23 PM UTC+2, Jon Smirl wrote:
>>
>> George has i2c working.
>>
>> On Mon, Sep 22, 2014 at 9:16 AM, Joseph Nguya 
>> wrote:
>>
>>> Hi Jon,
>>>
>>> The A20 does not support SCCB protocol. Did you manage to get a working
>>> sccb driver for the ov2643 working over i2c for the A20? What did you do to
>>> get it working.
>>>
>>> Thanks.
>>>
>>>
>>> On Sunday, January 5, 2014 7:19:05 PM UTC+2, Jon Smirl wrote:

 The unit has a Chinese Android build on it which is slowing me down.

 I haven't figure out how to start adb Ethernet daemon on target device.


 On Sun, Jan 5, 2014 at 12:01 PM, jons...@gmail.com 
 wrote:

>
>
>
> On Sun, Jan 5, 2014 at 11:55 AM, Michal Suchanek 
> wrote:
>
>> On 5 January 2014 17:48, jons...@gmail.com  wrote:
>> >
>> >
>> >
>> > On Sun, Jan 5, 2014 at 11:43 AM, Michal Suchanek 
>> wrote:
>> >>
>> >>
>> >>
>> >>
>> >> On 5 January 2014 16:50, jons...@gmail.com 
>> wrote:
>> >>
>> >>>
>> >>>
>> >>>
>> >>> On Sun, Jan 5, 2014 at 5:38 AM, Michal Suchanek <
>> hram...@gmail.com>
>>
>> >>> wrote:
>> 
>>  AFAIK the camera board is connected digitally so the noise is
>> something
>>  that is internal to the camera board.
>> 
>>  It is normal that under low light condition the image is noisy.
>> Did you
>>  try taking pictures in full daylight or using some photography
>> lighting?
>> >>>
>> >>>
>> >>> I have four other USB webcams and none of them have this noise
>> under same
>> >>> lighting conditions. I have two other Allwinner systems with
>> cameras and
>> >>> they all have noise. I checked it out this morning under
>> sunlight. It is
>> >>> better but the noise is still there.
>> >>>
>> >>> Maybe the camera images need some image processing that is not
>> getting
>> >>> turned on under the Allwinner platform? All of the Allwinner
>> devices appear
>> >>> to be running Allwinner SDK with only minor changes. They
>> probably all
>> >>> copied each other.
>> >>>
>> >>> The datasheet for the image sensor is here:
>> >>> http://files.virt2real.ru/docs/
>> >>>
>> >>> It is also possible that image processing features of the sensor
>> chip are
>> >>> not properly enabled.
>> >>>
>> >>
>> >> According to the datasheet the camera chip has various image
>> processing
>> >> filters including noise reduction. Does the driver support tuning
>> these
>> >> filters?
>> >
>> >
>> > I can modify driver. But that triggers the whole problem of being
>> able to
>> > rebuild the software for these devices. I'm trying to figure out
>> how to
>> > extract the fex files. They are STBs and don't have normal Android
>> buttons.
>>
>> Meaning not even a FEL button?
>>
>> No OTG USB port. They put a hub chip on the board and only exposed
> host port.
>
>
>
>> Do you get access to the boot partition with adb?
>>
>> The other way would be to run a non-broken Linux system from SD card.
>> Getting at least serial or ethernet should be easy if the box has
>> those. Or an USB Ethernet.
>>
>
> It has Ethernet. I'm trying to figure it out, I haven't used Android
> SDK with Ethernet before.
>
>
>>
>> Thanks
>>
>> Michal
>>
>> --
>> 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...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>
>
> --
> Jon Smirl
> jons...@gmail.com
>



 --
 Jon Smirl
 jons...@gmail.com

>>>  --
>>> 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...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Jon Smirl
>> jons...@gmail.com
>>
>  --
> 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.
>



-- 
Jon Smirl
jonsm...@gmail.com

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group

Re: [linux-sunxi] OV2643 Camera on A20

[Joseph Nguya]

Are you able to share your ov2643.c driver; for what kernel was it built

On Monday, September 22, 2014 3:30:23 PM UTC+2, Jon Smirl wrote:
>
> George has i2c working.
>
> On Mon, Sep 22, 2014 at 9:16 AM, Joseph Nguya  > wrote:
>
>> Hi Jon,
>>
>> The A20 does not support SCCB protocol. Did you manage to get a working 
>> sccb driver for the ov2643 working over i2c for the A20? What did you do to 
>> get it working.
>>
>> Thanks.
>>
>>
>> On Sunday, January 5, 2014 7:19:05 PM UTC+2, Jon Smirl wrote:
>>>
>>> The unit has a Chinese Android build on it which is slowing me down. 
>>>
>>> I haven't figure out how to start adb Ethernet daemon on target device.
>>>
>>>
>>> On Sun, Jan 5, 2014 at 12:01 PM, jons...@gmail.com  
>>> wrote:
>>>



 On Sun, Jan 5, 2014 at 11:55 AM, Michal Suchanek  
 wrote:

> On 5 January 2014 17:48, jons...@gmail.com  wrote:
> >
> >
> >
> > On Sun, Jan 5, 2014 at 11:43 AM, Michal Suchanek  
> wrote:
> >>
> >>
> >>
> >>
> >> On 5 January 2014 16:50, jons...@gmail.com  
> wrote:
> >>
> >>>
> >>>
> >>>
> >>> On Sun, Jan 5, 2014 at 5:38 AM, Michal Suchanek  >
>
> >>> wrote:
> 
>  AFAIK the camera board is connected digitally so the noise is 
> something
>  that is internal to the camera board.
> 
>  It is normal that under low light condition the image is noisy. 
> Did you
>  try taking pictures in full daylight or using some photography 
> lighting?
> >>>
> >>>
> >>> I have four other USB webcams and none of them have this noise 
> under same
> >>> lighting conditions. I have two other Allwinner systems with 
> cameras and
> >>> they all have noise. I checked it out this morning under sunlight. 
> It is
> >>> better but the noise is still there.
> >>>
> >>> Maybe the camera images need some image processing that is not 
> getting
> >>> turned on under the Allwinner platform? All of the Allwinner 
> devices appear
> >>> to be running Allwinner SDK with only minor changes. They probably 
> all
> >>> copied each other.
> >>>
> >>> The datasheet for the image sensor is here:
> >>> http://files.virt2real.ru/docs/
> >>>
> >>> It is also possible that image processing features of the sensor 
> chip are
> >>> not properly enabled.
> >>>
> >>
> >> According to the datasheet the camera chip has various image 
> processing
> >> filters including noise reduction. Does the driver support tuning 
> these
> >> filters?
> >
> >
> > I can modify driver. But that triggers the whole problem of being 
> able to
> > rebuild the software for these devices. I'm trying to figure out how 
> to
> > extract the fex files. They are STBs and don't have normal Android 
> buttons.
>
> Meaning not even a FEL button?
>
> No OTG USB port. They put a hub chip on the board and only exposed 
 host port. 

  

> Do you get access to the boot partition with adb?
>
> The other way would be to run a non-broken Linux system from SD card.
> Getting at least serial or ethernet should be easy if the box has
> those. Or an USB Ethernet.
>

 It has Ethernet. I'm trying to figure it out, I haven't used Android 
 SDK with Ethernet before.
  

>
> Thanks
>
> Michal
>
> --
> 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...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>



 -- 
 Jon Smirl
 jons...@gmail.com 

>>>
>>>
>>>
>>> -- 
>>> Jon Smirl
>>> jons...@gmail.com 
>>>
>>  -- 
>> 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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Jon Smirl
> jons...@gmail.com  
>

-- 
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 7/7] ARM: sunxi: Add basic A31 support

[Chen-Yu Tsai]

On Mon, Sep 22, 2014 at 3:01 AM, Maxime Ripard
 wrote:
> Hi Ian,
>
> On Sun, Sep 21, 2014 at 07:51:17PM +0100, Ian Campbell wrote:
>> On Mon, 2014-09-08 at 21:28 +0800, Chen-Yu Tsai wrote:
>> > From: Maxime Ripard 
>> >
>> > Add a new sun6i machine that doesn't do much for now.
>>
>> Can you briefly outline here what it _does_ do, please.
>
> When I contributed this patch, it was only having the UART support,
> but judging from the rest of the patches Chen-Yu sent, I guess it does
> a bit more than that now, especially MMC.

Yeah. I'll rewrite the commit message.

>> The actual code looks ok to me. There is some possibility we might
>> consolidate some of these Kconfig options, or at least move them to the
>> sunxi Kconfig. We can cross the bridge when we come to it though.
>>
>> Any links to some info about the Colombus? Is it the WITS development
>> kit which google found for me?
>
> It is.

I'll split out the Colombus defconfig into a separate patch, like we
split machine support and board files for the kernel.


ChenYu

-- 
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] OV2643 Camera on A20

[jonsm...@gmail.com]

George has i2c working.

On Mon, Sep 22, 2014 at 9:16 AM, Joseph Nguya 
wrote:

> Hi Jon,
>
> The A20 does not support SCCB protocol. Did you manage to get a working
> sccb driver for the ov2643 working over i2c for the A20? What did you do to
> get it working.
>
> Thanks.
>
>
> On Sunday, January 5, 2014 7:19:05 PM UTC+2, Jon Smirl wrote:
>>
>> The unit has a Chinese Android build on it which is slowing me down.
>>
>> I haven't figure out how to start adb Ethernet daemon on target device.
>>
>>
>> On Sun, Jan 5, 2014 at 12:01 PM, jons...@gmail.com 
>> wrote:
>>
>>>
>>>
>>>
>>> On Sun, Jan 5, 2014 at 11:55 AM, Michal Suchanek 
>>> wrote:
>>>
 On 5 January 2014 17:48, jons...@gmail.com  wrote:
 >
 >
 >
 > On Sun, Jan 5, 2014 at 11:43 AM, Michal Suchanek 
 wrote:
 >>
 >>
 >>
 >>
 >> On 5 January 2014 16:50, jons...@gmail.com 
 wrote:
 >>
 >>>
 >>>
 >>>
 >>> On Sun, Jan 5, 2014 at 5:38 AM, Michal Suchanek 

 >>> wrote:
 
  AFAIK the camera board is connected digitally so the noise is
 something
  that is internal to the camera board.
 
  It is normal that under low light condition the image is noisy.
 Did you
  try taking pictures in full daylight or using some photography
 lighting?
 >>>
 >>>
 >>> I have four other USB webcams and none of them have this noise
 under same
 >>> lighting conditions. I have two other Allwinner systems with
 cameras and
 >>> they all have noise. I checked it out this morning under sunlight.
 It is
 >>> better but the noise is still there.
 >>>
 >>> Maybe the camera images need some image processing that is not
 getting
 >>> turned on under the Allwinner platform? All of the Allwinner
 devices appear
 >>> to be running Allwinner SDK with only minor changes. They probably
 all
 >>> copied each other.
 >>>
 >>> The datasheet for the image sensor is here:
 >>> http://files.virt2real.ru/docs/
 >>>
 >>> It is also possible that image processing features of the sensor
 chip are
 >>> not properly enabled.
 >>>
 >>
 >> According to the datasheet the camera chip has various image
 processing
 >> filters including noise reduction. Does the driver support tuning
 these
 >> filters?
 >
 >
 > I can modify driver. But that triggers the whole problem of being
 able to
 > rebuild the software for these devices. I'm trying to figure out how
 to
 > extract the fex files. They are STBs and don't have normal Android
 buttons.

 Meaning not even a FEL button?

 No OTG USB port. They put a hub chip on the board and only exposed host
>>> port.
>>>
>>>
>>>
 Do you get access to the boot partition with adb?

 The other way would be to run a non-broken Linux system from SD card.
 Getting at least serial or ethernet should be easy if the box has
 those. Or an USB Ethernet.

>>>
>>> It has Ethernet. I'm trying to figure it out, I haven't used Android SDK
>>> with Ethernet before.
>>>
>>>

 Thanks

 Michal

 --
 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...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.

>>>
>>>
>>>
>>> --
>>> Jon Smirl
>>> jons...@gmail.com
>>>
>>
>>
>>
>> --
>> Jon Smirl
>> jons...@gmail.com
>>
>  --
> 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.
>



-- 
Jon Smirl
jonsm...@gmail.com

-- 
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: [U-Boot] [PATCH 6/7] ARM: sun6i: Setup the A31 UART0 muxing

[Chen-Yu Tsai]

On Mon, Sep 22, 2014 at 2:10 PM, Michael Trimarchi
 wrote:
> Hi
>
> Il 08/set/2014 15:36 "Chen-Yu Tsai"  ha scritto:
>
>
>>
>> From: Maxime Ripard 
>>
>> Signed-off-by: Maxime Ripard 
>> Signed-off-by: Hans de Goede 
>> [w...@csie.org: commit message was "ARM: sunxi: Setup the A31 UART0
>> muxing"]
>> Signed-off-by: Chen-Yu Tsai 
>> ---
>>  arch/arm/cpu/armv7/sunxi/board.c | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/arch/arm/cpu/armv7/sunxi/board.c
>> b/arch/arm/cpu/armv7/sunxi/board.c
>> index f2cedbb..fc6aa4b 100644
>> --- a/arch/arm/cpu/armv7/sunxi/board.c
>> +++ b/arch/arm/cpu/armv7/sunxi/board.c
>> @@ -54,6 +54,10 @@ int gpio_init(void)
>> 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_SUN6I)
>> +   sunxi_gpio_set_cfgpin(SUNXI_GPH(20), 2);
>> +   sunxi_gpio_set_cfgpin(SUNXI_GPH(21), 2);
>> +   sunxi_gpio_set_pull(SUNXI_GPH(21), 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);
>> --
>> 2.1.0
>>
>
> I don't know if it is correct that every architecture has a specific
> function to MUX, but can we define what is 2 2 and 1?

Yes they do. I will add them in a patch before this one in v2,
and also a separate patch to clean up the existing sunxi_gpio_set_pull
calls.


ChenYu

-- 
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] OV2643 Camera on A20

[Joseph Nguya]

Hi Jon,

The A20 does not support SCCB protocol. Did you manage to get a working 
sccb driver for the ov2643 working over i2c for the A20? What did you do to 
get it working.

Thanks.


On Sunday, January 5, 2014 7:19:05 PM UTC+2, Jon Smirl wrote:
>
> The unit has a Chinese Android build on it which is slowing me down. 
>
> I haven't figure out how to start adb Ethernet daemon on target device.
>
>
> On Sun, Jan 5, 2014 at 12:01 PM, jons...@gmail.com  <
> jons...@gmail.com > wrote:
>
>>
>>
>>
>> On Sun, Jan 5, 2014 at 11:55 AM, Michal Suchanek > > wrote:
>>
>>> On 5 January 2014 17:48, jons...@gmail.com  <
>>> jons...@gmail.com > wrote:
>>> >
>>> >
>>> >
>>> > On Sun, Jan 5, 2014 at 11:43 AM, Michal Suchanek >> > wrote:
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> On 5 January 2014 16:50, jons...@gmail.com  <
>>> jons...@gmail.com > wrote:
>>> >>
>>> >>>
>>> >>>
>>> >>>
>>> >>> On Sun, Jan 5, 2014 at 5:38 AM, Michal Suchanek >> >
>>> >>> wrote:
>>> 
>>>  AFAIK the camera board is connected digitally so the noise is 
>>> something
>>>  that is internal to the camera board.
>>> 
>>>  It is normal that under low light condition the image is noisy. Did 
>>> you
>>>  try taking pictures in full daylight or using some photography 
>>> lighting?
>>> >>>
>>> >>>
>>> >>> I have four other USB webcams and none of them have this noise under 
>>> same
>>> >>> lighting conditions. I have two other Allwinner systems with cameras 
>>> and
>>> >>> they all have noise. I checked it out this morning under sunlight. 
>>> It is
>>> >>> better but the noise is still there.
>>> >>>
>>> >>> Maybe the camera images need some image processing that is not 
>>> getting
>>> >>> turned on under the Allwinner platform? All of the Allwinner devices 
>>> appear
>>> >>> to be running Allwinner SDK with only minor changes. They probably 
>>> all
>>> >>> copied each other.
>>> >>>
>>> >>> The datasheet for the image sensor is here:
>>> >>> http://files.virt2real.ru/docs/
>>> >>>
>>> >>> It is also possible that image processing features of the sensor 
>>> chip are
>>> >>> not properly enabled.
>>> >>>
>>> >>
>>> >> According to the datasheet the camera chip has various image 
>>> processing
>>> >> filters including noise reduction. Does the driver support tuning 
>>> these
>>> >> filters?
>>> >
>>> >
>>> > I can modify driver. But that triggers the whole problem of being able 
>>> to
>>> > rebuild the software for these devices. I'm trying to figure out how to
>>> > extract the fex files. They are STBs and don't have normal Android 
>>> buttons.
>>>
>>> Meaning not even a FEL button?
>>>
>>> No OTG USB port. They put a hub chip on the board and only exposed host 
>> port. 
>>
>>  
>>
>>> Do you get access to the boot partition with adb?
>>>
>>> The other way would be to run a non-broken Linux system from SD card.
>>> Getting at least serial or ethernet should be easy if the box has
>>> those. Or an USB Ethernet.
>>>
>>
>> It has Ethernet. I'm trying to figure it out, I haven't used Android SDK 
>> with Ethernet before.
>>  
>>
>>>
>>> Thanks
>>>
>>> Michal
>>>
>>> --
>>> 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...@googlegroups.com .
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>
>>
>>
>> -- 
>> Jon Smirl
>> jons...@gmail.com  
>>
>
>
>
> -- 
> Jon Smirl
> jons...@gmail.com  
>

-- 
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/7] ARM: sun6i: Add clock support

[Chen-Yu Tsai]

On Mon, Sep 22, 2014 at 9:15 PM, Ian Campbell  wrote:
> On Mon, 2014-09-22 at 20:47 +0800, Chen-Yu Tsai wrote:
>> On Mon, Sep 22, 2014 at 2:35 AM, Ian Campbell  wrote:
>> > On Mon, 2014-09-08 at 21:28 +0800, Chen-Yu Tsai wrote:
>> >> + /* Set PLL ldo voltage without this PLL6 does not work properly */
>> >
>> > Is "this" here the doing it 3 times bit? If that's deliberate then
>> > please say so explicitly. e.g. "Set PLL LDO voltage 3 times, without ...
>> > etc"), if it's not deliberate then please fix ;-)
>>
>> Hans, if you could enlighten us? :)
>>
>> > I'm assuming this is one of those "no docs, allwinner code did it but
>> > nobody knows why it works" scenarios. Of course if the reason is
>> > known/doc'd then please add a reference.
>>
>> I looked at the boot1 sources we recently got.
>>
>> First it sets PRCM_PLL_CTRL_LDO_KEY to enable write access to the other
>> values.
>>
>> Then it sets PRCM_PLL_CTRL_IN_PWR_HIGH (which is the default) and
>> PRCM_PLL_CTRL_LDO_OUT_L(1140) in one call.
>>
>> Then it busy loops for some time to wait for it to stabilize.
>
> My guess would be that 3 writes happens to cause enough time to pass
> that things have (often!) stabilised, which is certainly not as good as
> an explicit waiting busy loop. But as you say lets see what Hans says.

FYI I'm dropping this part from the patch, so this discussion is for
future reference. :)

>> >> + writel(PRCM_PLL_CTRL_LDO_DIGITAL_EN | PRCM_PLL_CTRL_LDO_ANALOG_EN |
>> >> + PRCM_PLL_CTRL_EXT_OSC_EN | PRCM_PLL_CTRL_LDO_OUT_L(1140) |
>> >> + PRCM_PLL_CTRL_LDO_KEY, &prcm->pll_ctrl1);
>> >> + writel(PRCM_PLL_CTRL_LDO_DIGITAL_EN | PRCM_PLL_CTRL_LDO_ANALOG_EN |
>> >> + PRCM_PLL_CTRL_EXT_OSC_EN | PRCM_PLL_CTRL_LDO_OUT_L(1140) |
>> >> + PRCM_PLL_CTRL_LDO_KEY, &prcm->pll_ctrl1);
>> >> + writel(PRCM_PLL_CTRL_LDO_DIGITAL_EN | PRCM_PLL_CTRL_LDO_ANALOG_EN |
>> >> + PRCM_PLL_CTRL_EXT_OSC_EN | PRCM_PLL_CTRL_LDO_OUT_L(1140),
>> >> + &prcm->pll_ctrl1);
>> > [...]

-- 
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/7] ARM: sun6i: Add clock support

[Ian Campbell]

On Mon, 2014-09-22 at 20:47 +0800, Chen-Yu Tsai wrote:
> On Mon, Sep 22, 2014 at 2:35 AM, Ian Campbell  wrote:
> > On Mon, 2014-09-08 at 21:28 +0800, Chen-Yu Tsai wrote:
> >> + /* Set PLL ldo voltage without this PLL6 does not work properly */
> >
> > Is "this" here the doing it 3 times bit? If that's deliberate then
> > please say so explicitly. e.g. "Set PLL LDO voltage 3 times, without ...
> > etc"), if it's not deliberate then please fix ;-)
> 
> Hans, if you could enlighten us? :)
> 
> > I'm assuming this is one of those "no docs, allwinner code did it but
> > nobody knows why it works" scenarios. Of course if the reason is
> > known/doc'd then please add a reference.
> 
> I looked at the boot1 sources we recently got.
> 
> First it sets PRCM_PLL_CTRL_LDO_KEY to enable write access to the other
> values.
> 
> Then it sets PRCM_PLL_CTRL_IN_PWR_HIGH (which is the default) and
> PRCM_PLL_CTRL_LDO_OUT_L(1140) in one call.
> 
> Then it busy loops for some time to wait for it to stabilize.

My guess would be that 3 writes happens to cause enough time to pass
that things have (often!) stabilised, which is certainly not as good as
an explicit waiting busy loop. But as you say lets see what Hans says.

> 
> >> + writel(PRCM_PLL_CTRL_LDO_DIGITAL_EN | PRCM_PLL_CTRL_LDO_ANALOG_EN |
> >> + PRCM_PLL_CTRL_EXT_OSC_EN | PRCM_PLL_CTRL_LDO_OUT_L(1140) |
> >> + PRCM_PLL_CTRL_LDO_KEY, &prcm->pll_ctrl1);
> >> + writel(PRCM_PLL_CTRL_LDO_DIGITAL_EN | PRCM_PLL_CTRL_LDO_ANALOG_EN |
> >> + PRCM_PLL_CTRL_EXT_OSC_EN | PRCM_PLL_CTRL_LDO_OUT_L(1140) |
> >> + PRCM_PLL_CTRL_LDO_KEY, &prcm->pll_ctrl1);
> >> + writel(PRCM_PLL_CTRL_LDO_DIGITAL_EN | PRCM_PLL_CTRL_LDO_ANALOG_EN |
> >> + PRCM_PLL_CTRL_EXT_OSC_EN | PRCM_PLL_CTRL_LDO_OUT_L(1140),
> >> + &prcm->pll_ctrl1);
> > [...]
> 
> ChenYu
> 


-- 
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/7] ARM: sun6i: Add clock support

[Chen-Yu Tsai]

On Mon, Sep 22, 2014 at 2:35 AM, Ian Campbell  wrote:
> On Mon, 2014-09-08 at 21:28 +0800, Chen-Yu Tsai wrote:
>
>> +#ifdef CONFIG_SPL_BUILD
>
> Since there is no SPL support this is dead code right now, correct?

This was part of Hans' attempt to support SPL. It was not finished.

> I'm wondering whether we should leave it out of mainline until the SPL
> stuff is done, so SPL will be upstreamed all at once. What do others
> think?

Sounds reasonable.

>> + /* Set PLL ldo voltage without this PLL6 does not work properly */
>
> Is "this" here the doing it 3 times bit? If that's deliberate then
> please say so explicitly. e.g. "Set PLL LDO voltage 3 times, without ...
> etc"), if it's not deliberate then please fix ;-)

Hans, if you could enlighten us? :)

> I'm assuming this is one of those "no docs, allwinner code did it but
> nobody knows why it works" scenarios. Of course if the reason is
> known/doc'd then please add a reference.

I looked at the boot1 sources we recently got.

First it sets PRCM_PLL_CTRL_LDO_KEY to enable write access to the other
values.

Then it sets PRCM_PLL_CTRL_IN_PWR_HIGH (which is the default) and
PRCM_PLL_CTRL_LDO_OUT_L(1140) in one call.

Then it busy loops for some time to wait for it to stabilize.

>> + writel(PRCM_PLL_CTRL_LDO_DIGITAL_EN | PRCM_PLL_CTRL_LDO_ANALOG_EN |
>> + PRCM_PLL_CTRL_EXT_OSC_EN | PRCM_PLL_CTRL_LDO_OUT_L(1140) |
>> + PRCM_PLL_CTRL_LDO_KEY, &prcm->pll_ctrl1);
>> + writel(PRCM_PLL_CTRL_LDO_DIGITAL_EN | PRCM_PLL_CTRL_LDO_ANALOG_EN |
>> + PRCM_PLL_CTRL_EXT_OSC_EN | PRCM_PLL_CTRL_LDO_OUT_L(1140) |
>> + PRCM_PLL_CTRL_LDO_KEY, &prcm->pll_ctrl1);
>> + writel(PRCM_PLL_CTRL_LDO_DIGITAL_EN | PRCM_PLL_CTRL_LDO_ANALOG_EN |
>> + PRCM_PLL_CTRL_EXT_OSC_EN | PRCM_PLL_CTRL_LDO_OUT_L(1140),
>> + &prcm->pll_ctrl1);
> [...]

ChenYu

-- 
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: Availability of A80 boards to developers

[Simos Xenitellis]

On Thu, Sep 11, 2014 at 5:22 PM, Simos Xenitellis <
simos.li...@googlemail.com> wrote:

> Hi All,
>
> I asked Allwinner about the possibility of donation of a few A80 developer
> boards to developers and I got a positive response. So, I'll be doing the
> clerical work to arrange the donation.
>
> There should be several batches of boards being donated.
> This first batch is for five A80 OptimusBoard developer boards. I think
> they should be coming in the packaging that is shown at
> http://community.arm.com/thread/6449
>
> The criteria are:
> 1. You have already done some relevant work with other Allwinner SoCs.
> 2. You plan to do work with the board towards mainline Linux support
> (describe what).
> This also includes any work with u-boot or other packages that let the A80
> boot with a mainline kernel.
>
> Send me mail in private if you are interested to receive one.
> I'll process the requests and forward to Allwinner so that they can send
> the boards.
> If there are more than five requests, I'll keep the details for the
> subsequent batch.
>

Hi All,

Thanks for your requests.
I processed them, submitted them to Allwinner and I just received the
tracking numbers
which I will be forwarding to each recipient respectively.

Thanks,
Simos

-- 
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] [u-boot] [PATCH V1 1/1] mmc: sunxi: add SDHC support for sun6i/sun7i/sun8i

[Wills Wang]

Allwinner A20/A23/A31's SD/MMC host support SDHC High Capacity feature. 

Signed-off-by: Wills Wang 
---
 drivers/mmc/sunxi_mmc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index 459e476..0f3ee67 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -376,6 +376,9 @@ int sunxi_mmc_init(int sdc_no)
cfg->voltages = MMC_VDD_32_33 | MMC_VDD_33_34;
cfg->host_caps = MMC_MODE_4BIT;
cfg->host_caps |= MMC_MODE_HS_52MHz | MMC_MODE_HS;
+#if defined(CONFIG_SUN6I) || defined(CONFIG_SUN7I) || defined(CONFIG_SUN8I)
+   cfg->host_caps |= MMC_MODE_HC;
+#endif
cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
 
cfg->f_min = 40;
-- 
1.8.3.2

-- 
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: GPL Violations round-up.

[Carlo Caione]

On Sun, Sep 21, 2014 at 10:02:15PM -0700, AndrewDB wrote:
> For what it's worth, I fully support Luc's actions to document Allwinner's 
> GPL violations.
> 
> I also believe it is in Allwinner's interest to fully comply with the GPL 
> and that it's a pity that they don't understand this. How many (extremely 
> expensive) engineer-hours has this community generously contributed to 
> firmware/software development on Allwinner SOCs? I am positive that 
> Allwinner's present market share is in good part the result of this 
> community's work (although this assertion is impossible to prove), so why 
> not help this community by not having to reverse-engineer so many things?
> 
> And finally, last but not least, I firmly believe that it is in the 
> interest of this community to have Allwinner fully comply with the GPL and 
> freely provide as much documentation as possible. So we should all stand 
> behind Luc and not be indifferent or worse, critical of his actions.
> 
> Let me explain briefly where I am coming from:
> - First developer to have Linux booting on a dual-core Cortex-A9 AML8726MX 
> tablet.  Tried in vain to get any response from Amlogic about cooperation 
> with the Linux development community. Dropped development on this platform 
> because of total lack of support from Amlogic. Apparently in the last few 
> months they have been trying to reverse this situation, but I would say 
> it's too little, too late.

FWIW I'm working on mainlining amlogic SoCs and several patches have
been already submitted to LKML for Meson6 and Meson8 architectures. I'm
in contact with a couple of engineers in Amlogic and they seem willing
to help the community. They also promised to provide me with all the
documentation I need. We will see.

-- 
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] Re: GPL Violations round-up.

[Marius Cirsta]

On Monday, September 22, 2014 8:24:21 AM UTC+3, Tom Cubie wrote:
>
> On Mon, Sep 22, 2014 at 1:02 PM, AndrewDB  > wrote: 
> > For what it's worth, I fully support Luc's actions to document 
> Allwinner's 
> > GPL violations. 
> > 
> > I also believe it is in Allwinner's interest to fully comply with the 
> GPL 
> > and that it's a pity that they don't understand this. How many 
> (extremely 
> > expensive) engineer-hours has this community generously contributed to 
> > firmware/software development on Allwinner SOCs? I am positive that 
> > Allwinner's present market share is in good part the result of this 
> > community's work (although this assertion is impossible to prove), so 
> why 
> > not help this community by not having to reverse-engineer so many 
> things? 
> > 
> > And finally, last but not least, I firmly believe that it is in the 
> interest 
> > of this community to have Allwinner fully comply with the GPL and freely 
> > provide as much documentation as possible. So we should all stand behind 
> Luc 
> > and not be indifferent or worse, critical of his actions. 
> > 
> > Let me explain briefly where I am coming from: 
> > - First developer to have Linux booting on a dual-core Cortex-A9 
> AML8726MX 
> > tablet.  Tried in vain to get any response from Amlogic about 
> cooperation 
> > with the Linux development community. Dropped development on this 
> platform 
> > because of total lack of support from Amlogic. Apparently in the last 
> few 
> > months they have been trying to reverse this situation, but I would say 
> it's 
> > too little, too late. 
> > - First developer to have Linux booting on a dual-core RK3066 stick. 
> Tried 
> > in vain to get any response from Rockchip and from RK3066 stick 
> > manufacturers about cooperation with the Linux development community. 
> Again, 
> > dropped development on this platform and all subsequent Rockchip SOCs 
> > because of total lack of support from Rockchip (one of the Android stick 
> > manufacturers explained to me that he was himself being charged by 
> Rockchip 
> > for kernel customization services and did not have access to the kernel 
> > source). And if I may add, to this day the various kernels that they 
> have 
> > discreetly leaked are so unstable that I personally consider Rockchip 
> SOCs 
> > to be among the worst possible platforms for Linux and Android. 
>
> The situation has changed for rockchip. Rockchip is now actively doing 
> the mainline work. They have sent development boards to some kernel 
> maintainers too[1]. Their latest soc rk3288 goes to mainline three 
> months ago[2]. Patches are sent to kernel ML everyday from Rockchip 
> engineers. 
>
> [1] https://plus.google.com/111049168280159033135/posts/eZncP6ym3nZ 
> [2] http://www.spinics.net/lists/arm-kernel/msg338779.html 
>
>
Indeed I saw that Rockchip changed their attitude towards mainline and the 
community in a big way. Rockchip is now working on having mainline support 
and I even saw Chrome OS devs contributing to Rockchip mainline code. It 
seems Google had a big role in convincing companies such as Rockchip and 
Mediatek to change their ways.
Given all of this it would be wise for Allwinner to accelerate their 
efforts of collaborating with the community. I've seen some shy attempts at 
this but more could certainly be done about this.
 

> > 
> > 
> > On Wednesday, August 27, 2014 4:21:35 PM UTC+2, Luc Verhaegen wrote: 
> >> 
> >> In order to satisfy wikipedia, i have to provide a more reliable source 
> >> than our wiki. 
> >> 
> >> ... 
> > 
> > -- 
> > 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...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>
>
>
> -- 
> radxa rock - quad core arm computer that rocks 
>
> radxa.com 
>

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