[linux-sunxi] Jpeg Encoding
Hello I start with a question,according to this log http://irclog.whitequark.org/linux-sunxi/2013-09-05 there is no possibility for jpeg-encoding,is it? i also found some interessting project for the A10,a Camera Project with h264 Encoding. Maybe someone can link this in the wiki: https://github.com/ashwing920/SimpleRecorder -- 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 v1 0/9] sunxi: initial upstreamining effort
Hi, This is my first cut at an upstreamable series based upon the https://github.com/linux-sunxi/u-boot-sunxi.git#sunxi tree. The intention is to present a minimal starting point for upstreaming to which support for other processors, peripherals, boards etc can be added in the future. Therefore this has been stripped right back and currently supports only sun7i processors and the cubietruck board. Supported peripherals are UART, MMC and Ethernet. The code here is from sunxi.git#sunxi[0] changeset d854c4de2f57 arm: Handle .gnu.hash section in ldscripts and applied to u-boot v2014.01. This series can also be found at: git://gitorious.org/ijc/u-boot.git sunxi-mainlining-v1 There is no SMP here, since that relies on the PSCI support from Marc Zyngier which has yet to land in mainline AFAIK. I've tried to give corect credit and S-o-b based upon: git log --pretty='%aN' linux-sunxi/sunxi -- [PATHS] | sort -u git log linux-sunxi/sunxi -- [PATHS] | grep -i signed.off.by | sort -u Manual inspection This will tend to over credit, since it will include folks who contributed code which has since been removed as well as those who contributed code which is not included in this patch set, but I think it is better to be conservative and include too many rather than incorrectly exclude people. Doing better than this would be IMHO too hard to be worth it (e.g. git blame would prefer a recent whitespace cleanup to the actual author of the code and prefer someone did code motion over the original author, so it would be a massive manual process). I considered using the sunxi.git#sunxi-patchqueue branch but it was 151 patches and there didn't seem to be a small enough set of prefix patches which I was comfortable starting from. Cheers, Ian. [0] https://github.com/linux-sunxi/u-boot-sunxi.git -- 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 v1 4/9] sunxi: initial generic sun7i cpu, board and start of day support
Based linux-sunxi#sunxi commit d854c4de2f57 arm: Handle .gnu.hash section in
ldscripts vs v2014.01.
This has been stripped back for mainlining and supports only sun7i. These
changes are not useful by themselves but are split out to make the patch sizes
more manageable.
As well as the following signed-off-by the sunxi branch shows commits to these
files authored by the following:
Almo Nito
Carl van Schaik
FUKAUMI Naoki
hehopmajieh
j
Sergey Lapin
Tom Cubie
Signed-off-by: Aleksei Mamlin mamli...@gmail.com
Signed-off-by: Alexandru Gagniuc mr.nuke...@gmail.com
Signed-off-by: Chen-Yu Tsai w...@csie.org
Signed-off-by: Emilio López emi...@elopez.com.ar
Signed-off-by: Hans de Goede hdego...@redhat.com
Signed-off-by: Henrik Nordstrom hen...@henriknordstrom.net
Signed-off-by: Ian Campbell i...@hellion.org.uk
Signed-off-by: Jens Kuske jensku...@gmail.com
Signed-off-by: Luc Verhaegen l...@skynet.be
Signed-off-by: Luke Leighton l...@lkcl.net
Signed-off-by: Oliver Schinagl oli...@schinagl.nl
Signed-off-by: Patrick Wood patrickhw...@gmail.com
Signed-off-by: Stefan Roese s...@denx.de
Signed-off-by: Wills Wang wills.wang.o...@gmail.com
Signed-off-by: Ian Campbell i...@hellion.org.uk
---
arch/arm/cpu/armv7/sunxi/Makefile | 11 +++
arch/arm/cpu/armv7/sunxi/board.c | 104 +
arch/arm/cpu/armv7/sunxi/cpu_info.c | 35 +
arch/arm/cpu/armv7/sunxi/start.c | 1 +
arch/arm/include/asm/arch-sunxi/cpu.h | 138 ++
board/sunxi/Makefile | 28 +++
board/sunxi/board.c | 91 ++
7 files changed, 408 insertions(+)
create mode 100644 arch/arm/cpu/armv7/sunxi/board.c
create mode 100644 arch/arm/cpu/armv7/sunxi/cpu_info.c
create mode 100644 arch/arm/cpu/armv7/sunxi/start.c
create mode 100644 arch/arm/include/asm/arch-sunxi/cpu.h
create mode 100644 board/sunxi/Makefile
create mode 100644 board/sunxi/board.c
diff --git a/arch/arm/cpu/armv7/sunxi/Makefile
b/arch/arm/cpu/armv7/sunxi/Makefile
index 41d843f..3e8a36c 100644
--- a/arch/arm/cpu/armv7/sunxi/Makefile
+++ b/arch/arm/cpu/armv7/sunxi/Makefile
@@ -26,5 +26,16 @@
obj-y += timer.o
obj-y += dram.o
+obj-y += board.o
obj-y += clock.o
obj-y += pinmux.o
+
+ifndef CONFIG_SPL_BUILD
+obj-y += cpu_info.o
+endif
+
+ifdef CONFIG_SPL_BUILD
+ifdef CONFIG_SPL_FEL
+obj-y += start.o
+endif
+endif
diff --git a/arch/arm/cpu/armv7/sunxi/board.c b/arch/arm/cpu/armv7/sunxi/board.c
new file mode 100644
index 000..98cad43
--- /dev/null
+++ b/arch/arm/cpu/armv7/sunxi/board.c
@@ -0,0 +1,104 @@
+/*
+ * (C) Copyright 2012 Henrik Nordstrom hen...@henriknordstrom.net
+ *
+ * (C) Copyright 2007-2011
+ * Allwinner Technology Co., Ltd. www.allwinnertech.com
+ * Tom Cubie tangli...@allwinnertech.com
+ *
+ * Some init for sunxi platform.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include common.h
+#include serial.h
+#ifdef CONFIG_SPL_BUILD
+#include spl.h
+#endif
+#include asm/gpio.h
+#include asm/io.h
+#include asm/arch/clock.h
+#include asm/arch/gpio.h
+#include asm/arch/sys_proto.h
+#include asm/arch/timer.h
+
+#ifdef CONFIG_SPL_BUILD
+/* Pointer to the global data structure for SPL */
+DECLARE_GLOBAL_DATA_PTR;
+
+/* The sunxi internal brom will try to loader external bootloader
+ * from mmc0, nannd flash, mmc2.
+ * Unfortunately we can't check how SPL was loaded so assume
+ * it's always the first SD/MMC controller
+ */
+u32 spl_boot_device(void)
+{
+ return BOOT_DEVICE_MMC1;
+}
+
+/* No confirmation data available in SPL yet. Hardcode bootmode */
+u32 spl_boot_mode(void)
+{
+ return MMCSD_MODE_RAW;
+}
+#endif
+
+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);
+
+ return 0;
+}
+
+void reset_cpu(ulong addr)
+{
+}
+
+/* do some early init */
+void s_init(void)
+{
+#if !defined CONFIG_SPL_BUILD
+ /* Enable SMP mode for CPU0, by setting bit 6 of Auxiliary Ctl reg */
+ asm volatile(
+ mrc p15, 0, r0, c1, c0, 1\n
+ orr r0, r0, #0x40\n
+ mcr p15, 0, r0, c1,
[linux-sunxi] [PATCH v1 9/9] sunxi: add gmac Ethernet support
Based linux-sunxi#sunxi commit d854c4de2f57 arm: Handle .gnu.hash section in
ldscripts vs v2014.01.
Signed-off-by: Chen-Yu Tsai w...@csie.org
Signed-off-by: Jens Kuske jensku...@gmail.com
Signed-off-by: Ian Campbell i...@hellion.org.uk
---
arch/arm/cpu/armv7/sunxi/board.c | 15 +
boards.cfg | 4 +--
drivers/net/Makefile | 1 +
drivers/net/sunxi_gmac.c | 34
include/configs/sunxi-common.h | 68
5 files changed, 120 insertions(+), 2 deletions(-)
create mode 100644 drivers/net/sunxi_gmac.c
diff --git a/arch/arm/cpu/armv7/sunxi/board.c b/arch/arm/cpu/armv7/sunxi/board.c
index 98cad43..73b4cf0 100644
--- a/arch/arm/cpu/armv7/sunxi/board.c
+++ b/arch/arm/cpu/armv7/sunxi/board.c
@@ -27,6 +27,8 @@
*/
#include common.h
+#include netdev.h
+#include miiphy.h
#include serial.h
#ifdef CONFIG_SPL_BUILD
#include spl.h
@@ -102,3 +104,16 @@ void enable_caches(void)
dcache_enable();
}
#endif
+
+#if defined(CONFIG_SUNXI_GMAC)
+/*
+ * Initializes on-chip ethernet controllers.
+ * to override, implement board_eth_init()
+ */
+int cpu_eth_init(bd_t *bis)
+{
+ sunxi_gmac_initialize(bis);
+
+ return 0;
+}
+#endif
diff --git a/boards.cfg b/boards.cfg
index a513376..090e956 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -353,8 +353,8 @@ Active arm armv7 rmobile renesas
koelsch
Active arm armv7 s5pc1xx samsung goni
s5p_goni -
Mateusz Zalega m.zal...@samsung.com
Active arm armv7 s5pc1xx samsung smdkc100
smdkc100 -
Minkyu Kang mk7.k...@samsung.com
Active arm armv7 socfpga altera socfpga
socfpga_cyclone5 -
-
-Active arm armv7 sunxi - sunxi
Cubietruck sun7i:CUBIETRUCK,SPL
-
-Active arm armv7 sunxi - sunxi
Cubietruck_FEL sun7i:CUBIETRUCK,SPL_FEL
-
+Active arm armv7 sunxi - sunxi
Cubietruck sun7i:CUBIETRUCK,SPL,SUNXI_GMAC,RGMII
-
+Active arm armv7 sunxi - sunxi
Cubietruck_FEL
sun7i:CUBIETRUCK,SPL_FEL,SUNXI_GMAC,RGMII
-
Active arm armv7 u8500 st-ericsson snowball
snowball -
Mathieu Poirier mathieu.poir...@linaro.org
Active arm armv7 u8500 st-ericsson u8500
u8500_href -
-
Active arm armv7 vf610 freescale vf610twr
vf610twr
vf610twr:IMX_CONFIG=board/freescale/vf610twr/imximage.cfg
Alison Wang
b18...@freescale.com
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 7f9ce90..2300c00 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -51,6 +51,7 @@ obj-$(CONFIG_SH_ETHER) += sh_eth.o
obj-$(CONFIG_SMC9) += smc9.o
obj-$(CONFIG_SMC911X) += smc911x.o
obj-$(CONFIG_SUNXI_WEMAC) += sunxi_wemac.o
+obj-$(CONFIG_SUNXI_GMAC) += sunxi_gmac.o
obj-$(CONFIG_DRIVER_TI_EMAC) += davinci_emac.o
obj-$(CONFIG_TSEC_ENET) += tsec.o fsl_mdio.o
obj-$(CONFIG_DRIVER_TI_CPSW) += cpsw.o
diff --git a/drivers/net/sunxi_gmac.c b/drivers/net/sunxi_gmac.c
new file mode 100644
index 000..432d7b2
--- /dev/null
+++ b/drivers/net/sunxi_gmac.c
@@ -0,0 +1,34 @@
+#include common.h
+#include netdev.h
+#include miiphy.h
+#include asm/gpio.h
+#include asm/io.h
+#include asm/arch/clock.h
+#include asm/arch/gpio.h
+
+int sunxi_gmac_initialize(bd_t *bis)
Re: [linux-sunxi] [PATCH v1 9/9] sunxi: add gmac Ethernet support
On Fri, Mar 14, 2014 at 6:33 PM, Ian Campbell i...@hellion.org.uk wrote:
Based linux-sunxi#sunxi commit d854c4de2f57 arm: Handle .gnu.hash section in
ldscripts vs v2014.01.
Signed-off-by: Chen-Yu Tsai w...@csie.org
Signed-off-by: Jens Kuske jensku...@gmail.com
Signed-off-by: Ian Campbell i...@hellion.org.uk
---
arch/arm/cpu/armv7/sunxi/board.c | 15 +
boards.cfg | 4 +--
drivers/net/Makefile | 1 +
drivers/net/sunxi_gmac.c | 34
include/configs/sunxi-common.h | 68
5 files changed, 120 insertions(+), 2 deletions(-)
create mode 100644 drivers/net/sunxi_gmac.c
[..]
diff --git a/drivers/net/sunxi_gmac.c b/drivers/net/sunxi_gmac.c
new file mode 100644
index 000..432d7b2
--- /dev/null
+++ b/drivers/net/sunxi_gmac.c
@@ -0,0 +1,34 @@
+#include common.h
+#include netdev.h
+#include miiphy.h
+#include asm/gpio.h
+#include asm/io.h
+#include asm/arch/clock.h
+#include asm/arch/gpio.h
+
+int sunxi_gmac_initialize(bd_t *bis)
+{
+ int pin;
+ struct sunxi_ccm_reg *const ccm =
+ (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
+
+ /* Set up clock gating */
+ setbits_le32(ccm-ahb_gate1, 0x1 AHB_GATE_OFFSET_GMAC);
+
+ /* Set MII clock */
+ setbits_le32(ccm-gmac_clk_cfg, CCM_GMAC_CTRL_TX_CLK_SRC_INT_RGMII |
+ CCM_GMAC_CTRL_GPIT_RGMII);
+
+ /* Configure pin mux settings for GMAC */
+ for (pin = SUNXI_GPA(0); pin = SUNXI_GPA(16); pin++) {
+ /* skip unused pins in RGMII mode */
+ if (pin == SUNXI_GPA(9) || pin == SUNXI_GPA(14))
+ continue;
+ sunxi_gpio_set_cfgpin(pin, 5);
+ sunxi_gpio_set_drv(pin, 3);
+ }
+
+ designware_initialize(0, SUNXI_GMAC_BASE, 0x1,
PHY_INTERFACE_MODE_RGMII);
Hi,
Thanks for working on this!
I see you left out all the CONFIG_RGMII ifdefs from this file. Not
sure if it's because you're aiming to support only the Cubietruck
first. I think you should keep them in the same patch. You can then
just add the appropriate config options when support of other A20
boards roll in.
There are 3 changes to the designware driver since u-boot-sunxi's
last merge (2014.1-rc1):
50b0df8 net/designware: make driver compatible with data cache
92a190a net/designware - switch driver to phylib usage
74cb708 net/designware: add explicit reset of {tx|rx}_currdescnum
The move to phylib will likely break the current code. Maybe we could
merge 2014.4-rc1 in to fix it first.
Also, GMAC support depends on
5a51af3 net/designware: Reduce DMA burst length
by Jens Kuske (jemk). Neither of us bothered to send this upstream yet.
Cheers
ChenYu
+
+ return 0;
+}
[..]
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH v1 9/9] sunxi: add gmac Ethernet support
On Fri, 2014-03-14 at 19:11 +0800, Chen-Yu Tsai wrote:
Thanks for working on this!
No problem.
I see you left out all the CONFIG_RGMII ifdefs from this file. Not
sure if it's because you're aiming to support only the Cubietruck
first.
Yes, exactly.
I think you should keep them in the same patch. You can then
just add the appropriate config options when support of other A20
boards roll in.
I don't have any boards which require this, so I cannot test it. I'd
prefer to leave it to whoever adds support for the first such board to
put this stuff back in, it's a pretty trivial git diff invocation to
spot the needed bits.
There are 3 changes to the designware driver since u-boot-sunxi's
last merge (2014.1-rc1):
50b0df8 net/designware: make driver compatible with data cache
92a190a net/designware - switch driver to phylib usage
74cb708 net/designware: add explicit reset of {tx|rx}_currdescnum
The move to phylib will likely break the current code. Maybe we could
merge 2014.4-rc1 in to fix it first.
I'm happy to track any merges updates etc, sounds like at least this
patch will need some rebasing. Since this one is last I think it needn't
stop the rest going in (although I anticipate at least some review and
rebasing for all of it).
Also, GMAC support depends on
5a51af3 net/designware: Reduce DMA burst length
by Jens Kuske (jemk). Neither of us bothered to send this upstream yet.
I think I saw that in the sunxi tree but since it touched core code I
punted on it for now since I wasn't sure how to reconcile it with
non-sunxi platforms (i.e. what is the downside for other boards? Worse
performance?)
Thanks for your feedback.
Ian.
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH 1/3] irqchip: sun4i: Don't mask + unmask for the non oneshot case
On Thu, 13 Mar 2014, Hans de Goede wrote:
Since sun4i and sun5i are single core SOCs there is no need to mask non
oneshot IRQs, to achieve this we use handle_fasteoi_irq with a dummy eoi.
This is slightly wrong :)
Even on a SMP system there is no need to mask the interrupt when the
controller works like that sunxi one. If the controller is not broken
beyond repair then it does not deliver the same interrupt to a
different cpu. Such a thing would always deliver it to all cores and
those would race to grab the spinlock and mask it. I've seen such
horror, but don't ask how that performs.
The reason why you can spare the mask/unmask dance is that the
controller does not require any action and clears the interrupt when
the level goes back to inactive. That happens when the device handler
acks it at the device level.
Now there might be the case when the device reactivates the interrupt
before the RETI. But that does not matter as we run the primary
interrupt handlers with interrupts disabled.
Thanks,
tglx
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/irqchip/irq-sun4i.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-sun4i.c b/drivers/irqchip/irq-sun4i.c
index a0ed1ea..0a71990 100644
--- a/drivers/irqchip/irq-sun4i.c
+++ b/drivers/irqchip/irq-sun4i.c
@@ -74,8 +74,17 @@ static void sun4i_irq_unmask(struct irq_data *irqd)
sun4i_irq_base + SUN4I_IRQ_ENABLE_REG(reg));
}
+/*
+ * Since sun4i and sun5i are single core SOCs there is no need to mask non
+ * oneshot IRQs, to achieve this we use handle_fasteoi_irq with a dummy eoi.
+ */
+static void sun4i_irq_dummy_eoi(struct irq_data *irqd)
+{
+}
+
static struct irq_chip sun4i_irq_chip = {
.name = sun4i_irq,
+ .irq_eoi= sun4i_irq_dummy_eoi,
.irq_mask = sun4i_irq_mask,
.irq_unmask = sun4i_irq_unmask,
};
@@ -97,7 +106,7 @@ static int sun4i_irq_map(struct irq_domain *d, unsigned
int virq,
handle_fasteoi_irq);
else
irq_set_chip_and_handler(virq, sun4i_irq_chip,
- handle_level_irq);
+ handle_fasteoi_irq);
set_irq_flags(virq, IRQF_VALID | IRQF_PROBE);
--
1.9.0
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v1 0/9] sunxi: initial upstreamining effort
Hi Ian, On Fri, 14 Mar 2014 10:33:32 +, Ian Campbell i...@hellion.org.uk wrote: Hi, This is my first cut at an upstreamable series based upon the https://github.com/linux-sunxi/u-boot-sunxi.git#sunxi tree. The intention is to present a minimal starting point for upstreaming to which support for other processors, peripherals, boards etc can be added in the future. Therefore this has been stripped right back and currently supports only sun7i processors and the cubietruck board. Supported peripherals are UART, MMC and Ethernet. I am not familiar with all of AllWinner's CPUs, so please forgive me if I'm saying something stupid. Does sun7i support mean that A31 might be supported as well? From what I understand, UART and Eth should be somewhat common between A20 and A31, but MMC won't. In any case, I am willing to try and add Mele A1000G U-Boot support based on your series if that makes any sense. :) Amicalement, -- Albert. -- 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 v1 0/9] sunxi: initial upstreamining effort
On Fri, 2014-03-14 at 08:55 -0400, Tom Rini wrote: On Fri, Mar 14, 2014 at 10:33:32AM +, Ian Campbell wrote: Hi, This is my first cut at an upstreamable series based upon the https://github.com/linux-sunxi/u-boot-sunxi.git#sunxi tree. The intention is to present a minimal starting point for upstreaming to which support for other processors, peripherals, boards etc can be added in the future. Therefore this has been stripped right back and currently supports only sun7i processors and the cubietruck board. Supported peripherals are UART, MMC and Ethernet. First of all, yay. Second, how hard would it be to add sun5i / a13-olinuxino-micro support on top of this? I ask since I've got one of those sitting around here. Would we be talking just board level things or is sun5i vs sun7i a big deal? Thanks! I think it would be pretty small, if you fetch my tree and git diff it against the sunxi.git tree the diff bits with sun5i in them stand out reasonably clearly. I don't have such a platform myself though which is why I've not just done it. Ian. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [U-Boot] [PATCH v1 0/9] sunxi: initial upstreamining effort
On Fri, Mar 14, 2014 at 10:33:32AM +, Ian Campbell wrote: Hi, This is my first cut at an upstreamable series based upon the https://github.com/linux-sunxi/u-boot-sunxi.git#sunxi tree. The intention is to present a minimal starting point for upstreaming to which support for other processors, peripherals, boards etc can be added in the future. Therefore this has been stripped right back and currently supports only sun7i processors and the cubietruck board. Supported peripherals are UART, MMC and Ethernet. Some global comments: - If you haven't already, make sure it's all checkpatch clean. - Use the SPDX tags rather than including the GPL boilerplate. - Please re-word the commit messages. The how we got here / where this is from is fine for the cover letter. - Magic numbers need to be defined. Thanks! -- Tom signature.asc Description: Digital signature
[linux-sunxi] Re: [U-Boot] [PATCH v1 4/9] sunxi: initial generic sun7i cpu, board and start of day support
On Fri, Mar 14, 2014 at 10:33:46AM +, Ian Campbell wrote:
[snip]
+/* The sunxi internal brom will try to loader external bootloader
+ * from mmc0, nannd flash, mmc2.
Typo.
+#ifdef CONFIG_SPL_BUILD
+void sunxi_board_init(void)
+{
+ int power_failed = 0;
+ unsigned long ramsize;
+
+ printf(DRAM:);
+ ramsize = sunxi_dram_init();
+ if (!ramsize) {
+ printf( ?);
+ ramsize = sunxi_dram_init();
+ }
+ if (!ramsize) {
+ printf( ?);
+ ramsize = sunxi_dram_init();
+ }
We have to try 3 times? What?
+ /*
+ * Only clock up the CPU to full speed if we are reasonably
+ * assured it's being powered with suitable core voltage
+ */
+ if (!power_failed)
+ clock_set_pll1(91200);
Define that please.
--
Tom
signature.asc
Description: Digital signature
[linux-sunxi] Re: [U-Boot] [PATCH v1 1/9] sunxi: initial sun7i clocks and timer support.
On Fri, Mar 14, 2014 at 10:33:43AM +, Ian Campbell wrote:
[snip]
+ writel(0xa1005000, ccm-pll1_cfg);
+ sdelay(200);
+ writel(AXI_DIV_1 0 | AHB_DIV_2 4 | APB0_DIV_1 8 |
+CPU_CLK_SRC_PLL1 16, ccm-cpu_ahb_apb0_cfg);
+ writel(0x1 6 | readl(ccm-ahb_gate0), ccm-ahb_gate0);
+ writel(0x1 31 | readl(ccm-pll6_cfg), ccm-pll6_cfg);
All magic bits and shifts need defining.
+/*
+ * This function is derived from PowerPC code (timebase clock frequency).
+ * On ARM it returns the number of timer ticks per second.
+ */
+ulong get_tbclk(void)
+{
+ ulong tbclk;
+ tbclk = CONFIG_SYS_HZ;
+ return tbclk;
+}
So, just return CONFIG_SYS_HZ ?
--
Tom
signature.asc
Description: Digital signature
[linux-sunxi] Re: [U-Boot] [PATCH v1 0/9] sunxi: initial upstreamining effort
On Fri, Mar 14, 2014 at 01:59:38PM +, Ian Campbell wrote: On Fri, 2014-03-14 at 08:55 -0400, Tom Rini wrote: On Fri, Mar 14, 2014 at 10:33:32AM +, Ian Campbell wrote: Hi, This is my first cut at an upstreamable series based upon the https://github.com/linux-sunxi/u-boot-sunxi.git#sunxi tree. The intention is to present a minimal starting point for upstreaming to which support for other processors, peripherals, boards etc can be added in the future. Therefore this has been stripped right back and currently supports only sun7i processors and the cubietruck board. Supported peripherals are UART, MMC and Ethernet. First of all, yay. Second, how hard would it be to add sun5i / a13-olinuxino-micro support on top of this? I ask since I've got one of those sitting around here. Would we be talking just board level things or is sun5i vs sun7i a big deal? Thanks! I think it would be pretty small, if you fetch my tree and git diff it against the sunxi.git tree the diff bits with sun5i in them stand out reasonably clearly. I don't have such a platform myself though which is why I've not just done it. OK good, I think Albert and I might end up starting the sun4i/sun5i stuff as those are the boards we've got sitting around. -- Tom signature.asc Description: Digital signature
Re: [U-Boot] [linux-sunxi] [PATCH v1 9/9] sunxi: add gmac Ethernet support
On Fri, Mar 14, 2014 at 11:28:06AM +, Ian Campbell wrote: On Fri, 2014-03-14 at 19:11 +0800, Chen-Yu Tsai wrote: [snip] I think you should keep them in the same patch. You can then just add the appropriate config options when support of other A20 boards roll in. I don't have any boards which require this, so I cannot test it. I'd prefer to leave it to whoever adds support for the first such board to put this stuff back in, it's a pretty trivial git diff invocation to spot the needed bits. I agree with this as well. -- Tom signature.asc Description: Digital signature
[linux-sunxi] Re: [U-Boot] [PATCH v1 0/9] sunxi: initial upstreamining effort
On Friday, March 14, 2014 at 11:33:32 AM, Ian Campbell wrote: Hi, This is my first cut at an upstreamable series based upon the https://github.com/linux-sunxi/u-boot-sunxi.git#sunxi tree. The intention is to present a minimal starting point for upstreaming to which support for other processors, peripherals, boards etc can be added in the future. Therefore this has been stripped right back and currently supports only sun7i processors and the cubietruck board. Supported peripherals are UART, MMC and Ethernet. The code here is from sunxi.git#sunxi[0] changeset d854c4de2f57 arm: Handle .gnu.hash section in ldscripts and applied to u-boot v2014.01. This series can also be found at: git://gitorious.org/ijc/u-boot.git sunxi-mainlining-v1 Nice, finally! Best regards, Marek Vasut -- 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 v1 0/9] sunxi: initial upstreamining effort
On Fri, 2014-03-14 at 10:16 -0400, Tom Rini wrote: On Fri, Mar 14, 2014 at 10:33:32AM +, Ian Campbell wrote: Hi, This is my first cut at an upstreamable series based upon the https://github.com/linux-sunxi/u-boot-sunxi.git#sunxi tree. The intention is to present a minimal starting point for upstreaming to which support for other processors, peripherals, boards etc can be added in the future. Therefore this has been stripped right back and currently supports only sun7i processors and the cubietruck board. Supported peripherals are UART, MMC and Ethernet. Some global comments: - If you haven't already, make sure it's all checkpatch clean. I hadn't realised u-boot had a checkpatch. I shall do this. - Use the SPDX tags rather than including the GPL boilerplate. Agreed, I already sent out a patch to sunxi.git to make this happen there so I could sync it to this tree (so sunxi guys consider this a ping on 1394161088-9835-1-git-send-email-...@hellion.org.uk ;-)) I suppose I don't need to wait, but it was convenient to have a diff which always shrank... - Please re-word the commit messages. The how we got here / where this is from is fine for the cover letter. OK, that was mostly for my own reference. Mind if I put it at the end after --- so git am will strip it? - Magic numbers need to be defined. Will do. Thanks, Ian. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [U-Boot] [PATCH v1 0/9] sunxi: initial upstreamining effort
On Fri, Mar 14, 2014 at 03:04:28PM +, Ian Campbell wrote: On Fri, 2014-03-14 at 10:16 -0400, Tom Rini wrote: On Fri, Mar 14, 2014 at 10:33:32AM +, Ian Campbell wrote: Hi, This is my first cut at an upstreamable series based upon the https://github.com/linux-sunxi/u-boot-sunxi.git#sunxi tree. The intention is to present a minimal starting point for upstreaming to which support for other processors, peripherals, boards etc can be added in the future. Therefore this has been stripped right back and currently supports only sun7i processors and the cubietruck board. Supported peripherals are UART, MMC and Ethernet. Some global comments: [snip] - Please re-word the commit messages. The how we got here / where this is from is fine for the cover letter. OK, that was mostly for my own reference. Mind if I put it at the end after --- so git am will strip it? Yeah, that's a good idea. - Magic numbers need to be defined. Will do. Thanks! -- Tom signature.asc Description: Digital signature
[linux-sunxi] Re: [PATCH v1 0/9] sunxi: initial upstreamining effort
fre 2014-03-14 klockan 10:33 + skrev Ian Campbell: This is my first cut at an upstreamable series based upon the https://github.com/linux-sunxi/u-boot-sunxi.git#sunxi tree. Thanks for picking this up. Much needed. 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: gslx680 driver ported to sunxi
13 Mart 2014 Perşembe 14:22:52 UTC+2 tarihinde Joe Burmeister yazdı: On 13/03/14 12:05, selimte...@gmail.com wrote: 13 Mart 2014 Perşembe 12:20:15 UTC+2 tarihinde Joe Burmeister yazdı: On 13/03/14 09:52, selimte...@gmail.com wrote: 27 Ağustos 2013 Salı 22:14:14 UTC+3 tarihinde joe.a.bu...@gmail.com yazdı: Hi, For a while I've been working on getting my A13 tablet touch screen working with GNU/Linux. It's now working well enough for my purposes and I figured it was time to push it out. The code can be found at: https://gitorious.org/gslx680-for-sunxi It would be easy to move it in tree. What is a bit different from the other touch screen drivers is that it doesn't include the firmware in the driver. I've split the firmware into a separate file that you name in the fex/script.bin file. The reason for this is that the firmware defines things about the hardware such as resolution and can't be easily modified. So to support multiple devices you'd need multiple firmware included. Or your have to build for each driver+firmware combination. Better to have it a seperate file and which firmware be a configuration thing. That fits better to me with fex/script.bin or Device Tree. I've also added legacy single touch as well as multi touch. Not sure where we go from here, but no point me sitting on it. ;-) Joe Hi, I have a A13 tablet (just like this one -- http://moveontechnology.com/hugoenchina/?p=324) and while trying to make touchscreen working I came acrross with this gslx680 driver(https://gitorious.org/gslx680-for-sunxi) I'm using sunxi-3.4 kernel and compiled the driver successfully for this kernel. My screen resolution is 800x480 so I'm using the firmware supplied by the source code. I can successfully insmod the driver, got the successfull dmesg messages as expected, but when I try testing the driver with evtest tool, i got totally no output from gslx680 mmodule (/dev/event/event1). I am completely stuck at this point, any suggestion will be really helpfull. Thanks in advance. selim Hi Selim, I've done an update recently that makes the new code work properly with X, it was broken at one point. At this point, as far as I know, I need to start the process of getting it into sunxi properly. Maybe add DT and get it fully upstreamed. Yet to start that process. Anyway, no output from evtest tells me the problem is probably the firmware. You need to extract the firmware from your android driver. There is a python script in the firmware directory called fw_extractor (and fw_info) that should be able to do this, if the driver is related to the Android one with my device. If the firmware isn't in the Android driver, then we need to find where it lives on your device and put it into the same binary format. If you feel you aren't getting anywhere, send me the Android driver and I'll have a look to see if the firmware is in there and adapt the script to find it there too. We need to start building a database of the firmware for the gslx680 chips. If we can work out how to tell which chip needs which firmware, we can select the right one automatically. The aim of course is everything just works. :-) Joe Joe Hi, Thanks for the quick reply, Indeed I have read in some forum posts that people trying wrong gslx680 firmwares got shifted touch outputs, I haven't seen a post with no output from the driver. I hope its about the wrong firmware. Ok, now I will pull the successfully running driver (gslX680.ko) from running android device and extract the firmware as you suggested. Thanks again. selim Hi Selim, No prob, delighted when someone has a play with it. :-) The result of the wrong firmware is hard to guess. The firmware for this device is just a buck load of settings from what I can see. Only thing that probably holds is it depends how far out your device is from the settings in the firmware on how well it works. Please please let me know how you get on. Joe Hi Joe, Today I have rooted my tablet, successfully find the touchscreen module named as A13_gslX680 and pulled the ko file with adb pull. Good news :) After extracting the firmware from the original module and trying gslx680_ts driver with the original firmware everything worked like a charm, now I can get outputs from evtest tool. More information about my tablet and firmware is; my tablet exactly looks like this one -- https://drive.google.com/file/d/0B7kdmqnGET4eeHVlY1k2REVlemc/edit?usp=sharing Screen size: 9 , 800x480 Mainboard ID : TW_A0910_16B_V1.1_0830 Touch screen
Re: [linux-sunxi] Re: How to decide NAND boot address?
Hi, OK, I think I need to close the topic and drew a conclusion: The conclusion is: my board in question, which is an IView435TPC, doesn't allow any hacking on NAND by doing something magic inside closed source boot1. The conclusion fis based on my following observations: 1. I have tried Installing to NAND sunxi wiki instructions, it works fine. just git checkout lichee-dev, make the CONFIG_BOOTCOMMAND changes with fatload inside include/configs/sun5i_a13.h, basically that is the line we put inside boot.cmd for boot.scr. No need to do any dram configurations as we want to do in sd card boot case. 2. when I was using nand-part tool to repartition the internal NAND, the last re-read partition table command returns -1 on the iview tablet, but return 0 on Olimex a13 board, which indicates something is going on in the iview nand. 3. I could see no debugging output from serial when hooking up with UART1 on the iview, but everything is OK on Olimex NAND, I can see boot0 loading messages, as well as lichee-dev uboot, and my uImage output. So, the lesson learned here is for some of the commercial tablets out there, they must have put some magic keys/encryptions to lock down their internal NAND to prevent any hacking or manipulations, no debug output from serial is a very good sign of such lock down. Hope these notes are helpful to someone, and my appreciations to all the help from you guys. Cheers, -Hunter On Friday, March 7, 2014 5:09:41 PM UTC-6, hunter hu wrote: Hi, I finally got the serial port working on my board, just a side note, we need a pull up resistor at the Rx pin, and I am using UART1 with SD card approach, anyone struggles with serial port, here is the thread that helped me: https://www.olimex.com/forum/index.php?topic=1788.0 All goes well with the SD u-boot and I can stop at u-boot prompt and play with it, booting up as usual too by typing boot. However when I set the NAND stuff up with lichee-dev u-boot built out of sun5i_a13, there is no serial output at all upon boot and stuck at logo, which indicates something is wrong with the u-boot image and it didn't run as expected. I also tried just use the stock android u-boot, some posts say we can stop android u-boot when booting up, I didn't see that happen either. Any ideas how to proceed from here would be greatly appreciated. Thanks in advance, -Hunter On Wednesday, March 5, 2014 10:13:45 PM UTC-6, hunter hu wrote: Thanks Pat, I have used the correct syntax, but still, stuck at the SUNXI logo; at this moment I have a few questions: 1 my cpu is A13, your u-boot is for A20, I would think that is not working for me? 2 I have been using lichee-dev, sun5i_a13 board, trying to modify the configurations as shown before; when I was adding my board to the u-boot-sunxi, I had to add a dram_myboard.c to configure the DRAM by following the sunxi wiki instructions, I tried to do with and without the DRAM stuff, the same, stuck at the logo, I believe I have to get the serial port working first. Thank you very much for all help so far, I greatly appreciated. -Hunter On Wednesday, March 5, 2014 9:35:06 PM UTC-6, Patrick Wood wrote: fatload nand 0 kernel_address kernel_file Note that my u-boot is based on a heavily-modified version of the one used by android. On Wednesday, March 5, 2014 10:10:03 PM UTC-5, hunter hu wrote: Hi Pat, I was not be able to get serial port access yet, work in progress. Regarding the syntax, what are the correct ones? thanks, -Hunter On Wednesday, March 5, 2014 8:51:22 PM UTC-6, Patrick Wood wrote: That's not the right syntax for file access. Don't you have a serial port you can get boot logs from? -- 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 v1 7/9] sunxi: mmc support
Hi Ian,
On Mar 14, 2014, at 12:33 PM, Ian Campbell wrote:
Based linux-sunxi#sunxi commit d854c4de2f57 arm: Handle .gnu.hash section in
ldscripts vs v2014.01.
As well as the following signed-off-by the sunxi branch shows commits to these
files authored by the following:
Stefan Roese
Tom Cubie
yemao
Signed-off-by: Henrik Nordstrom hen...@henriknordstrom.net
Signed-off-by: Luke Leighton l...@lkcl.net
Signed-off-by: Oliver Schinagl oli...@schinagl.nl
Signed-off-by: Wills Wang wills.wang.o...@gmail.com
Signed-off-by: Ian Campbell i...@hellion.org.uk
---
arch/arm/include/asm/arch-sunxi/mmc.h | 66
board/sunxi/board.c | 13 +
drivers/mmc/Makefile | 1 +
drivers/mmc/sunxi_mmc.c | 650 ++
include/configs/sunxi-common.h| 11 +
5 files changed, 741 insertions(+)
create mode 100644 arch/arm/include/asm/arch-sunxi/mmc.h
create mode 100755 drivers/mmc/sunxi_mmc.c
diff --git a/arch/arm/include/asm/arch-sunxi/mmc.h
b/arch/arm/include/asm/arch-sunxi/mmc.h
new file mode 100644
index 000..639a7fc
--- /dev/null
+++ b/arch/arm/include/asm/arch-sunxi/mmc.h
@@ -0,0 +1,66 @@
+/*
+ * (C) Copyright 2007-2011
+ * Allwinner Technology Co., Ltd. www.allwinnertech.com
+ * Aaron leafy.m...@allwinnertech.com
+ *
+ * MMC register definition for allwinner sunxi platform.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#ifndef _SUNXI_MMC_H
+#define _SUNXI_MMC_H
+
+#include linux/types.h
+
+struct sunxi_mmc {
+ u32 gctrl; /* (0x00) SMC Global Control Register */
+ u32 clkcr; /* (0x04) SMC Clock Control Register */
+ u32 timeout;/* (0x08) SMC Time Out Register */
+ u32 width; /* (0x0c) SMC Bus Width Register */
+ u32 blksz; /* (0x10) SMC Block Size Register */
+ u32 bytecnt;/* (0x14) SMC Byte Count Register */
+ u32 cmd;/* (0x18) SMC Command Register */
+ u32 arg;/* (0x1c) SMC Argument Register */
+ u32 resp0; /* (0x20) SMC Response Register 0 */
+ u32 resp1; /* (0x24) SMC Response Register 1 */
+ u32 resp2; /* (0x28) SMC Response Register 2 */
+ u32 resp3; /* (0x2c) SMC Response Register 3 */
+ u32 imask; /* (0x30) SMC Interrupt Mask Register */
+ u32 mint; /* (0x34) SMC Masked Interrupt Status Reg */
+ u32 rint; /* (0x38) SMC Raw Interrupt Status Register */
+ u32 status; /* (0x3c) SMC Status Register */
+ u32 ftrglevel; /* (0x40) SMC FIFO Threshold Watermark Reg */
+ u32 funcsel;/* (0x44) SMC Function Select Register */
+ u32 cbcr; /* (0x48) SMC CIU Byte Count Register */
+ u32 bbcr; /* (0x4c) SMC BIU Byte Count Register */
+ u32 dbgc; /* (0x50) SMC Debug Enable Register */
+ u32 res0[11]; /* (0x54~0x7c) */
+ u32 dmac; /* (0x80) SMC IDMAC Control Register */
+ u32 dlba; /* (0x84) SMC IDMAC Descr List Base Addr Reg */
+ u32 idst; /* (0x88) SMC IDMAC Status Register */
+ u32 idie; /* (0x8c) SMC IDMAC Interrupt Enable Register */
+ u32 chda; /* (0x90) */
+ u32 cbda; /* (0x94) */
+ u32 res1[26]; /* (0x98~0xff) */
+ u32 fifo; /* (0x100) SMC FIFO Access Address */
+};
+
+int sunxi_mmc_init(int sdc_no);
+#endif /* _SUNXI_MMC_H */
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index bffef4f..5dbcf2a 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -30,6 +30,7 @@
#include common.h
#include asm/arch/clock.h
#include asm/arch/dram.h
+#include asm/arch/mmc.h
DECLARE_GLOBAL_DATA_PTR;
@@ -59,6 +60,18 @@ int dram_init(void)
return 0;
}
+#ifdef CONFIG_GENERIC_MMC
+int board_mmc_init(bd_t *bis)
+{
+ sunxi_mmc_init(CONFIG_MMC_SUNXI_SLOT);
+#if !defined (CONFIG_SPL_BUILD) defined (CONFIG_MMC_SUNXI_SLOT_EXTRA)
+
Re: [linux-sunxi] Re: [U-Boot] [PATCH v1 3/9] sunxi: initial sun7i dram setup support
fre 2014-03-14 klockan 10:17 -0400 skrev Tom Rini: And as for the rest of the code, lots of magic numbers to #define what/why (why udelay(2) and 22?) Unfortunately the only documentation we have on the sun7i DRAM controller is Allwinner boot0 + boot1 code, and that code uses.. magic numbers shifts with no explanations. We have guessed some small bits, but a lot is completely unknown. Regards Henriki -- 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 v1 3/9] sunxi: initial sun7i dram setup support
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/14/2014 09:17 AM, Tom Rini wrote:
On Fri, Mar 14, 2014 at 10:33:45AM +, Ian Campbell wrote:
[snip]
+static void mctl_ddr3_reset(void) +{ + struct sunxi_dram_reg
*dram = +(struct sunxi_dram_reg *)SUNXI_DRAMC_BASE; + +
{ +
clrbits_le32(dram-mcr, DRAM_MCR_RESET); + udelay(2); +
setbits_le32(dram-mcr, DRAM_MCR_RESET); + }
That seems like an odd construction, why the extra braces?
This originally had a conditional depending on the SoC family. (Yeah,
they need to reset the ram differently). It seems it wasn't removed
properly.
And as for the rest of the code, lots of magic numbers to #define
what/why (why udelay(2) and 22?)
Before going into more detail, remember this is ram initialization
code. That's always going to be a pain :(.
There's nothing magic here. It's just a fact of life. Every step is
going to need a different delay. No need to bloat the headers by
#defining each. It also makes raminit code more unreadable.
We got these numbers from allwinner code dumps. We used to have these
as sdelay() numbers, which usually meant units of 2 clock cycles. So
we had to convert them to udelay() to at least make the delays
independent of CPU clock. The old sdelay() numbers made no sense either.
Alex
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJTIzsgAAoJEL0kPHNPXJJKasUQAKygf9UpJc6IINH41LKOFnBf
fBEVB8ECIu96JWUDE9r0BQw0l6Pc82Mqx+XUZdbNhhZNhhVf8EJ/9koHQrP/X8By
J8MninT7pgDi7IH9Y+U5GfuHEA1nDQT0kf+nYMNrUIx1b9cuv5vLvhpeKL0AJotb
DE8miBRCcuRcAivCjERjlVFKCicMERKx1cTrris7+aQyNAxPEGrFj0pS8RBpSgBF
j+NkRSjbdnAOKHOfpXZi7VMqhHIt6NDxsuSrM0roSJz1v79+J5TGqUdPFKvGVZro
BbsWB3pRq8zSdO6OYvojUjyWPG95PfhDQvLSlvKA5Z1AlgNHu32YGkFWGbUve/z7
8dn057RjY4KtrAn+jVOL8+sBAj6yr0VIJmxqa1xPqGOMBAn0Cn+JJZ6auCNPZGqx
yt5glg0B5lHsVgCnmDGvoKs8SAv7n7IQfmiF+gvD8Pn0/NC31UQ2WA3khJoPt6Gp
9G5q+sn6BRrUpQOiQmhJTPX4W3g3nmXFqWYkd+VAWEHeEfHTIuqOlcfgdwMmP4Ti
hrhrk/CWSOPjtYuI5yByA6RCZ93smb4uexSmrzzafzuYrdwK/DmP+TumFrE8pycT
cMsxAx40UEElJ5OHN7YaWtt6NNhCT6BVlo76awqFY/vGme0cef74SQqB8EdyVYSE
PDoq+Sog13y4A8OjQ5rT
=e7kN
-END PGP SIGNATURE-
--
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 v1 8/9] sunxi: non-FEL SPL boot support for sun7i
Hi, On 03/14/2014 03:17 PM, Tom Rini wrote: On Fri, Mar 14, 2014 at 10:33:50AM +, Ian Campbell wrote: Based linux-sunxi#sunxi commit d854c4de2f57 arm: Handle .gnu.hash section in ldscripts vs v2014.01. [snip] +/* Flat Device Tree (FDT/DT) support */ +#define CONFIG_OF_LIBFDT +#define CONFIG_SYS_BOOTMAPSZ(16 20) This seems pretty small. This is to keep things from being relocated into highmem right? Hmm, this reminds me that we currently need to do a env set fdt_high in our boot scripts to get ftd to work at all. Would be nice to fix this for upstream. I'm afraid I'm clueless as to why we (sunxi) need it, but we do. 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.
[linux-sunxi] Re: [U-Boot] [PATCH v1 8/9] sunxi: non-FEL SPL boot support for sun7i
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/14/2014 02:50 PM, Hans de Goede wrote: Hi, On 03/14/2014 03:17 PM, Tom Rini wrote: On Fri, Mar 14, 2014 at 10:33:50AM +, Ian Campbell wrote: Based linux-sunxi#sunxi commit d854c4de2f57 arm: Handle .gnu.hash section in ldscripts vs v2014.01. [snip] +/* Flat Device Tree (FDT/DT) support */ +#define CONFIG_OF_LIBFDT +#define CONFIG_SYS_BOOTMAPSZ (16 20) This seems pretty small. This is to keep things from being relocated into highmem right? Hmm, this reminds me that we currently need to do a env set fdt_high in our boot scripts to get ftd to work at all. Would be nice to fix this for upstream. I'm afraid I'm clueless as to why we (sunxi) need it, but we do. You want to be setting bootm_low (even for bootz, it's about the underlying boot mechanics that bootz and bootelf and ... hook into) to the amount of lowmem the kernel will have. We do this because we do want to make sure that the device tree isn't overwritten by the kernel BSS or similar. Everyone with more DDR than kernel lowmem needs to be doing something along these lines. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTI1J0AAoJENk4IS6UOR1WUocP/Aojl084qj0+sibvo6r7xb0T 23QaTqoGo+0i48mssFhiCo3KY1RMTiokQ0VgE0r29GQSipc5y75nIj24p0SpFD9N H2e2hWoTTQ106+MFx4upK61KLvmDA7LUJIHkVYWmgyOP7qL1wdwB5/5hqHuLkSlF Osz37r2JSbrWgYG+hs8Yby5D/fVizOTpf8f8F5GHrDA+3qlsOOHxUogfPGQeTPpk 9EhrLPSWWIN5l6qnykiiYz0QHDotJvrKoCVm2DJ4APnsIBS3/QyFNkePjVRRrmIT 1zob5wmprYywOjVNeBZ10HjPM8AHuyO2xBr+H3ZwcjfgI4MYiTJiG3eSJ1lTcveY FGbQa7HFzpnp9vwvvpWtT720D58WYdkjYQRarYHBWpXn+i2xKf4zGggX14jytUXU dFrqSDQ1hIEZd6uWj/jQMqHuZWDvnJ46ySqlE37UCZwcO1dQ/6WkNrve+XK1+HGQ EQlTlfRD64a+U2Plh2qoU/xadb+cWNV3fOppUgiwjdvx/+H/8TXsj6h0euaUe7JG ej+xqeH1a5HoVg5g30Ihn/KHNHwefG6ap3/vsdGH6hq5euodNxIzfBNZAEJ+dY58 tUkfuB3G5OeKV6JvbfD2vOJOl7AHRgqabXNHcNDS3AWAFnodcsgRO2E0od1ao7Ii n6pN0HAAzINC4y1kR/tJ =6IRY -END PGP SIGNATURE- -- 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 v1 0/9] sunxi: initial upstreamining effort
Hi, First of all: Ian: Many many thanks for working on this, you rock! On 03/14/2014 04:01 PM, Albert ARIBAUD wrote: Hi Tom, On Fri, 14 Mar 2014 10:19:27 -0400, Tom Rini tr...@ti.com wrote: OK good, I think Albert and I might end up starting the sun4i/sun5i stuff as those are the boards we've got sitting around. As I have a Mele A1000G (A31), that would be sun6i, not sun4i/sun5i So I'm very interested in getting sunxi support in upstream u-boot too, and I've a ton of sunxi devices. I'll start working on doing a sun4i patch-set on top of Ian's sun7i patch-set. Then Tom can start working on sun5i. Tom, since I've started working on sunxi stuff 2 years ago I've gained a lot of experience with these little SoCs so let me know if you hit some roadblock and I can take a look. Disclaimer I'm more of a kernel / device driver guy, all the low-level RAM init (and having to think about where in memory to put all the bits) is mostly new, so have some patience with me please :) and yes, I would like to contribute support for it. If someone can start working on sun6i support that would be awesome. My sunxi-next u-boot branch: https://github.com/jwrdegoede/u-boot-sunxi/commits/sunxi-next Has some minimal patches by Maxime to get u-boot to run as a secondary boot-loader, using allwinner's boot0 and boot1 as primary loader. What we really want is to get a working SPL for sun6i, there are 2 ways to get to a working SPL: 1) Use allwinners special USB boot mode called FEL, this way no MMC / NAND reading code is necessary. 2) First get MMC to work using uboot as a secondary loader only, and once we've working MMC code try to get a SPL which can read the real u-boot directly from MMC. And then for 2, there is the option to first get MMC for sun6i working in the upstream Linux kernel, so that we know exactly what changes are needed compared to sun5i / sun7i MMC (which are identical). I've done a lot of work on the upstream kernel mmc host driver, and I actually wanted to start looking into MMC for sun6i in the upstream kernel one of these days. But now that Ian has published his awesome work to get sunxi support upstream, my first priority is to get sun4i + sun5i support added on top of Ian's patches. 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.
[linux-sunxi] Re: [U-Boot] [PATCH v1 0/9] sunxi: initial upstreamining effort
Hi, snip and yes, I would like to contribute support for it. If someone can start working on sun6i support that would be awesome. p.s. One thing I forgot about sun6i / A31 support Oliver Schinagl has some preliminary u-boot patches for it here: https://github.com/oliv3r/u-boot-sunxi/commits/wip/a31 AFAIK these are based on various allwinner source dumps, and are untested as Oliver does not have an A31 device. 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] CSI driver problems in 16bit mode + some successful debug
On 2014-03-14 10:42, Ivan Kozic wrote: If someone knows something, please share - if I had some more documentation, I would have probably already made the whole thing work, I don't know anything, but by chance I was looking here today: http://dl.linux-sunxi.org/A10/ My impression was that there is an 8 bit channel and a 24 bit channel. So perhaps it won't do 16 bits? Martin -- 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 v1 0/9] sunxi: initial upstreamining effort
On Fri, 14 Mar 2014 10:16:42 -0400 Tom Rini tr...@ti.com wrote: On Fri, Mar 14, 2014 at 10:33:32AM +, Ian Campbell wrote: Hi, This is my first cut at an upstreamable series based upon the https://github.com/linux-sunxi/u-boot-sunxi.git#sunxi tree. The intention is to present a minimal starting point for upstreaming to which support for other processors, peripherals, boards etc can be added in the future. Therefore this has been stripped right back and currently supports only sun7i processors and the cubietruck board. Supported peripherals are UART, MMC and Ethernet. Some global comments: - If you haven't already, make sure it's all checkpatch clean. - Use the SPDX tags rather than including the GPL boilerplate. - Please re-word the commit messages. The how we got here / where this is from is fine for the cover letter. - Magic numbers need to be defined. I have a quick request also, Please incorporate the ongoing generic distro work as most if not all of the sunxi systems I know of are targets for generic distros. Dennis -- 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] CSI driver problems in 16bit mode + some successful debug
Hi John - just saw your post. I think you're looking at a wrong document,
as for A20, the register setting 100 for bits 22:20 is YUV422 16bit - it's
written in the A20 User Manual on page 371. The problem is in fact this
very vague information in the User Manual - it's almost useless. This is
why I'm asking for help from someone who maybe knows the kernel a bit more
- for instance, I'm not even sure which DMA is used for transfers from CSI
to memory, because I have to figure it out from the driver.
I'm also not sure where to search for the driver or more help. This group
seems most professional of all by far - I have tried to contact Allwinner,
but to no avail so far. As for sunxi kernel and drivers, I only know of the
Git branch, but noone there has touched CSI driver for 8 months. Although I
did always look in the 3.4 branch, maybe I should check out mainline...
Anyway, I'll search for the actual solution myself and if I find it post
back - If anyone can speed me up, I'll be most grateful.
On Saturday, March 15, 2014 12:01:41 AM UTC+1, Jon Smirl wrote:
I haven't tried any of this...
Look like you would set the input format...
22:20 R/W 3 INPUT_FMT
Input data format
000: RAW stream
001: reserved
010: CCIR656(one channel）
011: YUV422
100: YUV444（{R, B, G} or {Pr, Pb, Y}）
When the input format is set YUV444
1100: field planar YUV 444
1101: field planar YUV 422 UV combined
1110: frame planar YUV 444
: frame planar YUV 422 UV combined
The the output format is always 24b, right?
You're going to have to read the user manual. I don't believe anyone
has played with this before. But it looks like the hardware supports
it.
Also - the CSI driver in the sunxi tree is quite old. First thing I'd
do is update it using the most recent Allwinner CSI driver we can
locate. You might even get lucky and the newer Allwinner drivers could
support 16b.
On Fri, Mar 14, 2014 at 3:57 PM, Martin Collins
mar...@mkcollins.orgjavascript:
wrote:
On 2014-03-14 10:42, Ivan Kozic wrote:
If someone knows something, please share - if I had some more
documentation, I would have probably already made the whole thing work,
I don't know anything, but by chance I was looking here today:
http://dl.linux-sunxi.org/A10/
My impression was that there is an 8 bit channel and a 24 bit channel.
So perhaps it won't do 16 bits?
Martin
--
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 javascript:.
For more options, visit https://groups.google.com/d/optout.
--
Jon Smirl
jons...@gmail.com javascript:
--
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.
