Re: [linux-sunxi] [PATCH u-boot-sunxi 02/11] ARM: sunxi: Add GMAC base address and clocks
On 19-12-13 10:58, Chen-Yu Tsai wrote:
From: Jens Kuske jensku...@gmail.com
Signed-off-by: Jens Kuske jensku...@gmail.com
---
arch/arm/include/asm/arch-sunxi/clock.h | 3 +++
arch/arm/include/asm/arch-sunxi/cpu.h | 1 +
2 files changed, 4 insertions(+)
diff --git a/arch/arm/include/asm/arch-sunxi/clock.h
b/arch/arm/include/asm/arch-sunxi/clock.h
index 2e65a9d..b4e540e 100644
--- a/arch/arm/include/asm/arch-sunxi/clock.h
+++ b/arch/arm/include/asm/arch-sunxi/clock.h
@@ -104,6 +104,8 @@ struct sunxi_ccm_reg {
u32 mali_clk_cfg; /* 0x154 */
u8 res7[0x4];
u32 mbus_clk_cfg; /* 0x15c */
+ u8 res8[0x4];
+ u32 gmac_clk_cfg; /* 0x164 */
};
/* apb1 bit field */
@@ -170,6 +172,7 @@ struct sunxi_ccm_reg {
#define AHB_GATE_OFFSET_USB_OHCI0 2
#define AHB_GATE_OFFSET_USB_EHCI0 1
#define AHB_GATE_OFFSET_USB 0
+#define AHB_GATE_OFFSET_GMAC 17
Looks like GMAC and EMAC use the same AHB Gate offset? Can't we use
AHB_GATE_OFFSET_EMAC? or atleast put both defines on the same (ordered)
spot?
Oliver
#define CCM_AHB_GATE_GPS (0x1 26)
#define CCM_AHB_GATE_SDRAM (0x1 14)
diff --git a/arch/arm/include/asm/arch-sunxi/cpu.h
b/arch/arm/include/asm/arch-sunxi/cpu.h
index 378989c..17facc3 100644
--- a/arch/arm/include/asm/arch-sunxi/cpu.h
+++ b/arch/arm/include/asm/arch-sunxi/cpu.h
@@ -109,6 +109,7 @@
#define SUNXI_GPS_BASE0x01c3
#define SUNXI_MALI400_BASE0x01c4
+#define SUNXI_GMAC_BASE0x01c5
/* module sram */
#define SUNXI_SRAM_C_BASE 0x01d0
--
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/groups/opt_out.
Re: [linux-sunxi] [PATCH u-boot-sunxi 03/11] ARM: sunxi: Add GMAC driver
On 19-12-13 10:58, Chen-Yu Tsai wrote:
From: Jens Kuske jensku...@gmail.com
The existing net/designware driver can be used for sunxi GMAC.
Signed-off-by: Jens Kuske jensku...@gmail.com
---
arch/arm/cpu/armv7/sunxi/board.c | 21 -
include/configs/sunxi-common.h | 9 +
2 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/sunxi/board.c b/arch/arm/cpu/armv7/sunxi/board.c
index 3e66225..8c43ab6 100644
--- a/arch/arm/cpu/armv7/sunxi/board.c
+++ b/arch/arm/cpu/armv7/sunxi/board.c
@@ -29,6 +29,7 @@
#include common.h
#include i2c.h
#include netdev.h
+#include miiphy.h
#include serial.h
#ifdef CONFIG_SPL_BUILD
#include spl.h
@@ -134,14 +135,32 @@ void enable_caches(void)
}
#endif
-#if defined(CONFIG_SUNXI_EMAC)
+#if defined(CONFIG_SUNXI_EMAC) || defined(CONFIG_SUNXI_GMAC)
/*
* Initializes on-chip ethernet controllers.
* to override, implement board_eth_init()
*/
int cpu_eth_init(bd_t *bis)
{
+#ifdef CONFIG_SUNXI_EMAC
sunxi_emac_initialize(bis);
+#else
+ 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, (0x1 2) | (0x2 0));
+
+ /* Configure pin mux settings for GMAC */
+ for (pin = SUNXI_GPA(0); pin = SUNXI_GPA(17); pin++)
+ sunxi_gpio_set_cfgpin(pin, 5);
+
+ designware_initialize(0, SUNXI_GMAC_BASE, 0x1,
PHY_INTERFACE_MODE_RGMII);
+#endif
While small, could we make that into a function called
sunxi_gmac_initialize(bis)?
Oliver
return 0;
}
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index ee21761..165b2ee 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -430,6 +430,15 @@
#define CONFIG_CMD_NET
#endif
+#ifdef CONFIG_SUNXI_GMAC
+#define CONFIG_DESIGNWARE_ETH /* GMAC can use designware driver */
+#define CONFIG_DW_AUTONEG
+#define CONFIG_SYS_DCACHE_OFF /* dw driver doesn't support dcache */
+#define CONFIG_MII /* MII PHY management */
+#define CONFIG_CMD_MII
+#define CONFIG_CMD_NET
+#endif
+
#ifdef CONFIG_CMD_NET
#define CONFIG_CMD_PING
#define CONFIG_CMD_DHCP
--
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/groups/opt_out.
Re: [linux-sunxi] [PATCH u-boot-sunxi 03/11] ARM: sunxi: Add GMAC driver
On 19-12-13 10:58, Chen-Yu Tsai wrote:
From: Jens Kuske jensku...@gmail.com
The existing net/designware driver can be used for sunxi GMAC.
Signed-off-by: Jens Kuske jensku...@gmail.com
---
arch/arm/cpu/armv7/sunxi/board.c | 21 -
include/configs/sunxi-common.h | 9 +
2 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/sunxi/board.c b/arch/arm/cpu/armv7/sunxi/board.c
index 3e66225..8c43ab6 100644
--- a/arch/arm/cpu/armv7/sunxi/board.c
+++ b/arch/arm/cpu/armv7/sunxi/board.c
@@ -29,6 +29,7 @@
#include common.h
#include i2c.h
#include netdev.h
+#include miiphy.h
#include serial.h
#ifdef CONFIG_SPL_BUILD
#include spl.h
@@ -134,14 +135,32 @@ void enable_caches(void)
}
#endif
-#if defined(CONFIG_SUNXI_EMAC)
+#if defined(CONFIG_SUNXI_EMAC) || defined(CONFIG_SUNXI_GMAC)
/*
* Initializes on-chip ethernet controllers.
* to override, implement board_eth_init()
*/
int cpu_eth_init(bd_t *bis)
{
+#ifdef CONFIG_SUNXI_EMAC
sunxi_emac_initialize(bis);
+#else
+ 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, (0x1 2) | (0x2 0));
Also, do we know how this clk struct looks? I would expect so, can we
use defines here?
oliver
+
+ /* Configure pin mux settings for GMAC */
+ for (pin = SUNXI_GPA(0); pin = SUNXI_GPA(17); pin++)
+ sunxi_gpio_set_cfgpin(pin, 5);
+
+ designware_initialize(0, SUNXI_GMAC_BASE, 0x1,
PHY_INTERFACE_MODE_RGMII);
+#endif
return 0;
}
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index ee21761..165b2ee 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -430,6 +430,15 @@
#define CONFIG_CMD_NET
#endif
+#ifdef CONFIG_SUNXI_GMAC
+#define CONFIG_DESIGNWARE_ETH /* GMAC can use designware driver */
+#define CONFIG_DW_AUTONEG
+#define CONFIG_SYS_DCACHE_OFF /* dw driver doesn't support dcache */
+#define CONFIG_MII /* MII PHY management */
+#define CONFIG_CMD_MII
+#define CONFIG_CMD_NET
+#endif
+
#ifdef CONFIG_CMD_NET
#define CONFIG_CMD_PING
#define CONFIG_CMD_DHCP
--
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/groups/opt_out.
Re: [linux-sunxi] [PATCH u-boot-sunxi 11/11] sunxi: fix gpio drive mask
On 19-12-13 15:22, Chen-Yu Tsai wrote: On Thu, Dec 19, 2013 at 6:43 PM, Olliver Schinagl oliver+l...@schinagl.nl wrote: On 19-12-13 10:58, Chen-Yu Tsai wrote: From: Ma Haijun mahaij...@gmail.com A better commit message on this patch would be good, especially explaining it a bit deeper or referencing where you found this. You mean A20 user manual reference? Sure. I'll add that. Though Hans has already merged the other half of the original fix. Yeah I saw; it's just that I wasn't aware and the commit log was a little to uncertain if this is a 'we think this is a fix' or 'we found this in the docs so should be a fix' :) It will only help people reading over the commit logs is all. Oliver wens oliver Signed-off-by: Ma Haijun mahaij...@gmail.com Signed-off-by: Chen-Yu Tsau w...@csie.org --- arch/arm/cpu/armv7/sunxi/pinmux.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/cpu/armv7/sunxi/pinmux.c b/arch/arm/cpu/armv7/sunxi/pinmux.c index 8428439..56671f6 100644 --- a/arch/arm/cpu/armv7/sunxi/pinmux.c +++ b/arch/arm/cpu/armv7/sunxi/pinmux.c @@ -69,7 +69,7 @@ int sunxi_gpio_set_drv(u32 pin, u32 val) ((struct sunxi_gpio_reg *)SUNXI_PIO_BASE)-gpio_bank[bank]; drv = readl(pio-drv[0] + index); - drv = ~(0xf offset); + drv = ~(0x3 offset); drv |= val offset; writel(drv, pio-drv[0] + index); -- 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/groups/opt_out. -- 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/groups/opt_out.
Re: [linux-sunxi] zet6221 ts driver testing
On 19-12-13 16:15, oviro...@gmail.com wrote: Hello I need to include ZET6221 driver for 3SC6410 FriendlyArm board. Can someone send source files ? I think you confuse linux-sunxi with ZET, so maybe ask them. As for our RE sources or submitted sources, I'm sure you are able to use google and find what was posted to this list (which is publicly archived) and/or check wingrime's git account for his efforts. Heck even the first few google results for zet6221 yield the proper results, so do at least SOME homework. Oliver -- 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/groups/opt_out.
Re: [linux-sunxi] Sun8i (A23) spotted in the wild.
On 22-12-13 07:30, Patrick Wood wrote: The boot_clock in the .fex file is given as 1008. Maybe because they copy/pasted the fex? look at the 'extreme_freq' in the dvfs I think it was oliver On Friday, December 20, 2013 8:46:32 PM UTC-5, Runzhong Yi wrote: It could be possible since A23 can run as high as 1.8Ghz. If the core run as 1650MHz then this mean the dram clock is 1/3 of the core clock. 2013/12/21 Patrick Wood patric...@gmail.com javascript:: Am I reading the fex file correctly? The DRAM is running at 552 MHz? On Friday, December 20, 2013 9:08:07 AM UTC-5, Luc Verhaegen wrote: On Thu, Dec 19, 2013 at 12:32:24AM +0100, Luc Verhaegen wrote: I tried to order myself one of those cheap Q88 tablets with an A13 just now. Big was my surprise when i got it and popped it open, as i was staring at an A23. Bad news all round really: * fully locked down android, no root, no adb. I will give another root exploit a try tomorrow. * our fel utility does not work. * we of course have no code for u-boot or linux yet. * nothing on the serial port. This device is a really serious GPL violator. They even went as far as removing all open source licenses from the About section under android settings. What we do know: * two obvious serial pads (which are not sending out anything atm) * it tries to boot off SD when a likely candidate is there * it has a 3.4.39 kernel, and the /proc/config.gz was world readable (this is where the string sun8i was found). * HW is an A23 which is a bga, with an AXP223 companion Board picture is available at the device page: http://linux-sunxi.org/Ippo_q8h http://linux-sunxi.org/Ippo_q8h Luc Verhaegen. In the meantime, adb access has been figured out and the device has been rooted. All is documented on the page. script.bin has been fetched, and is available from: http://dl.linux-sunxi.org/users/libv/ippo_q8h/ http://dl.linux-sunxi.org/users/libv/ippo_q8h/ Luc Verhaegen. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out https://groups.google.com/groups/opt_out. -- 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/groups/opt_out. -- 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/groups/opt_out.
Re: [linux-sunxi] FOSDEM 2014, what do we want
On 02-01-14 15:26, Luc Verhaegen wrote: On Thu, Jan 02, 2014 at 03:18:58PM +0100, Hans de Goede wrote: Hi, On 01/01/2014 10:55 PM, Oliver Schinagl wrote: Hehe, I too think it would be could to spend most of the talk on upstream progress. If possible I would also add maybe one sheet about the android derived 3.4 kernel, where you can basically summarize things by saying that everything more or less works :) Regards, Hans I do not agree. Upstream linux kernel support is not what this talk is about, and the talk should very broadly cover many aspects of the linux-sunxi project. If you wanted an upstream linux kernel talk for sunxi, you should've filed a separate talk. I think this subject is so broad, that all (kernel) directions should and could be talked about. 3.4 is interesting, 3.10 is interesting, mainline is interesting. 3.0 btw is not, but even talking a little about 3.3 is important to the crowd to know what's out there (and what to avoid). This is about new people that don't know what's going on here, all information is good :) oliver Luc Verhaegen. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] Explain the contents of bootloader...
On 02-01-14 10:49, Puneet B wrote: Hi i flashed the cubieboard image to sd card from this link. https://docs.google.com/file/d/0B-bAEPML8fwlUFd5OHVOaFJIRmc/edit. then in Volumn(bootlaoder) folder of sdcard i got fallowing binaries. 1.boot.axf This is the allwinner 'battery charging app' that also chainloads u-boot if need so. 2.boot_signature.axf this is some sort of signature required by boot.axf i assume 3.drv_hdmi.drv this is the HDMI driver to output over ... hdmi yes 4.font32.sft a font 5.magic.bin some secret sauce 6.prvt.axf some private data 7.script.bin the famous script.bin/fex 8.boot.ini a dos file for boot.axf to parse to decide what to boot 9.drv_de.drv display engine driver 10.font24.sft a nother font! 11.linux - linux.bmp linux.ini u-boot.bin (sub contents). the linux splash screen (android actually) an ini file to tell boot.axf what and how to boot it (it being u-boot). u-boot here is the lichee-u-boot, one that does NOT init dram, but DOES support NAND 12.os_show -bat0.bmp bat2.bmp bat5.bmp bat8.bmp bempty.bmp full.bmplinux2.bmp melis2.bmp wince1.bmp bat10.bmp bat3.bmp bat6.bmp bat9.bmp bootlogo.bmp head.bmplow_pwr.bmp startup.bmp wince2.bmp bat1.bmp bat4.bmp bat7.bmp battery.bmp empty.bmp linux1.bmp melis1.bmp tail.bmp boot.axf image files (like empty battery, charging, some pics they intended to use as boot selector that never happened. 13.script0.bin backup copy of script.bin, in case 1 is broken it tries to read this one 14.sprite.axf helper program to handle the loading of bitmaps it would seem. Out of these i know script.bin , and u-boot.bin (but i flashed to /dev/sdc ). you cannot flash that u-boot to a SD card, it works only on nand, and you shouldn't mess with it. Kindly tell what will be purpose of remaining binaries. and tell me what will be difference between boot0 ,boot1 and sunxi-spl.bin ,u-boot.bin. YOu really don't know this yet? Have you ever looked at our wiki? boot0 is allwinner's version of what we call u-boot-sunxi-spl. boot1 is allwinners variant of what we call u-boot.bin boot0/1 is what we call u-boot-sunxi-with-spl.bin which is inteded to be flashed to an mmc card, starting at the 8k marker. Oliver Regards Punith -- 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/groups/opt_out. -- 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/groups/opt_out.
Re: [linux-sunxi] [PATCH] a20: fix up inet_k70hc wifi
On 03-01-14 09:49, Hans de Goede wrote: Hi, On 01/03/2014 02:05 AM, Luc Verhaegen wrote: On Fri, Jan 03, 2014 at 02:01:54AM +0100, Luc Verhaegen wrote: Signed-off-by: Luc Verhaegen l...@skynet.be --- sys_config/a20/inet_k70hc.fex |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) With this patch on top, i think that the inet k70hc is well enough supported to be included in sunxi-boards. The OTG port is still useless, but i will document that for the time being. I will have to get back to this soon, as i rather rely on g_ether for doing development while travelling at 300+kmph. But first i have to buy myself a male micro usb connector where i can solder a wire to the id pin. After your previous self-nack I deleted the first patch, can you please resend it then I'll add both to the sunxi-boards repo. No need, I had them still and squashed + pushed it! Oliver Thanks, Hans -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] Seeking consultant for Linux-Sunxi integration project
On 01-01-14 04:54, npeacock wrote: I am looking for someone interested in consulting work for a company using Linux on Allwinner tablets, starting immediately. I don't want to mention the company name in the open, like this, but I would be glad to share it in private email about the job. They build vending and outdoor payment systems and have come to realize buying stock tablets is cheaper, faster and generally better than their own in house designs, assuming they have the flexibility of Linux. They came to me from my experience with PengPod and I've done a little work so far. I can help pass things over to you. Basically, they are trying to bring three tablets on-line with a real Linux image (they had a chroot proof of concept running Debian inside of Android) and modify a few drivers for their needs. They have been good to work for. They are very flexible about my schedule, they already have many remote staff (some international), they are responsive to provide the tools and answers needed to move things along. I think there is probably a need for a permanent platform position in their team, helping add features and for the various future projects they have in mind. They are pretty ambitious in the long term. I've taken a permanent position with a non-compete, so I wont be able to work for them any more after the 13th. Oh, also they paid pretty well too. Anyone who is interested please let me know. I mostly need to hear about what you have done with Allwinner devices, but the company will want see a resume. I'll put you in touch directly about wages in all after we have our QA. No on site work required, test devices will be sent to you. I assume this is US Residents work only? Just inquiring. Oliver Thanks. -- Neal Peacock PengPod -- 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/groups/opt_out. -- 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/groups/opt_out.
[linux-sunxi] Re: [PATCH v2 2/4] ARM: sunxi: Add ahci-sunxi driver for the Allwinner SUNXi SoCs sata
On 01/04/14 22:47, Arnd Bergmann wrote: On Saturday 04 January 2014 22:39:50 Arnd Bergmann wrote: +Required properties: +- compatible : compatible list, contains allwinner,sun4i-a10-ahci +- reg: registers mapping +- interrupts : interrupt mapping for AHCI IRQ +- clocks : clocks for ACHI +- clock-names: clock names for AHCI The binding needs to specify the required names for the clocks. fwiw, the imx driver uses ahb and sata_ref as the clock names. I would strongly suggest using the same names here, and documenting them in the ahci binding as optional. This is my fault, and you just reminded me I should have fixed that from the previous comments. It just slipped my mind and I'm sorry for that! Hans, I'll go over the original commit thread and pick up all changes and send them as a patch to you Monday. Oliver Arnd -- 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/groups/opt_out.
[linux-sunxi] Re: [PATCH v2 2/4] ARM: sunxi: Add ahci-sunxi driver for the Allwinner SUNXi SoCs sata
On 01/05/14 14:32, Hans de Goede wrote: Hi, On 01/05/2014 01:42 PM, Olliver Schinagl wrote: On 01/04/14 22:47, Arnd Bergmann wrote: On Saturday 04 January 2014 22:39:50 Arnd Bergmann wrote: +Required properties: +- compatible : compatible list, contains allwinner,sun4i-a10-ahci +- reg: registers mapping +- interrupts : interrupt mapping for AHCI IRQ +- clocks : clocks for ACHI +- clock-names: clock names for AHCI The binding needs to specify the required names for the clocks. fwiw, the imx driver uses ahb and sata_ref as the clock names. I would strongly suggest using the same names here, and documenting them in the ahci binding as optional. This is my fault, and you just reminded me I should have fixed that from the previous comments. It just slipped my mind and I'm sorry for that! Hans, I'll go over the original commit thread and pick up all changes and send them as a patch to you Monday. As I just mentioned to Arnd I've a better idea to be able to re-use most of the ahci_platform.c code without copy-pasting it. So I'm going to do a v3 soonish. Can you please just make a mail with summary of the requested changes and send that to me, or do this after I've send v3 ? if memory serves, it was mostly about the dt documentation and binding names, i'll work on it first thing tomorrow morning ;) Thanks, Hans -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] Seeking consultant for Linux-Sunxi integration project
On 03-01-14 14:30, Neal Peacock wrote: On Jan 3, 2014 5:01 AM, Olliver Schinagl oliver+l...@schinagl.nl mailto:oliver%2bl...@schinagl.nl wrote: On 01-01-14 04:54, npeacock wrote: I am looking for someone interested in consulting work for a company using Linux on Allwinner tablets, starting immediately. To keep this thread going, What would someone have to do for this company? How many hours a week are you expected to work for them etc etc. They do not have any staff that could do this themselves? Is it really that much work that you haven't been able to do it yet yourself? Oliver I don't want to mention the company name in the open, like this, but I would be glad to share it in private email about the job. They build vending and outdoor payment systems and have come to realize buying stock tablets is cheaper, faster and generally better than their own in house designs, assuming they have the flexibility of Linux. They came to me from my experience with PengPod and I've done a little work so far. I can help pass things over to you. Basically, they are trying to bring three tablets on-line with a real Linux image (they had a chroot proof of concept running Debian inside of Android) and modify a few drivers for their needs. They have been good to work for. They are very flexible about my schedule, they already have many remote staff (some international), they are responsive to provide the tools and answers needed to move things along. I think there is probably a need for a permanent platform position in their team, helping add features and for the various future projects they have in mind. They are pretty ambitious in the long term. I've taken a permanent position with a non-compete, so I wont be able to work for them any more after the 13th. Oh, also they paid pretty well too. Anyone who is interested please let me know. I mostly need to hear about what you have done with Allwinner devices, but the company will want see a resume. I'll put you in touch directly about wages in all after we have our QA. No on site work required, test devices will be sent to you. I assume this is US Residents work only? This is open to anyone, anywhere. The company currently has mostly remote employees, several outside the US. Just inquiring. Oliver Thanks. -- Neal Peacock PengPod -- 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 mailto:linux-sunxi%2bunsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- 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 mailto:linux-sunxi%2bunsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- 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/groups/opt_out. -- 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/groups/opt_out.
Re: [linux-sunxi] Fedora 19 from SATA
On 10-01-14 13:51, Jonathan Aquilina wrote: Hans, Technicall shouldnt it still work with out SELinux, as most stuff out there usually disable it as it causes more headaches then its worth. I just come to the realization, since the image is being dd'ed, the UUID's are identical and thus mounting 'may' go wrong? formating disks and copying the files probably works better. I thought the installer would fill fstab based on the UUID, but even if it does that, they all have the same UUID's duh I'm almost there Oliver On Fri, Jan 10, 2014 at 12:42 PM, Olliver Schinagl oliver+l...@schinagl.nl mailto:oliver+l...@schinagl.nl wrote: On 10-01-14 11:41, Hans de Goede wrote: Hi, On 01/09/2014 11:28 PM, Oliver Schinagl wrote: Hey Hans, mind helping me find my fault please? I can boot your Fedora r3 image fine from MMC, whilst running that I can mount /dev/sda3 just fine and modify/copy files. Rebooting after editing uEnv.txt to say root=/dev/sda3 instead of mmcblk0p3 makes the kernel wait forever for sata to be ready. The only debug output I noticed was that sata said it was 'disconnected?' [0.642886] sw_ahci sw_ahci.0: forcing PORTS_IMPL to 0x1 [2.490824] systemd[1]: Failed to load SELinux policy. Freezing. This indicates that your rootfs has been found and mounted, but there is some selinux issue, are you trying to run with selinux disabled ? Try to set selinux to permissive mode. Mumbo Jumbo! I dded your r3 image to my ssd; but booted from an (installed) mmc; with only changing the root= parameter. I'll go read up on SELinux ;) 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+unsubscribe@__googlegroups.com mailto:linux-sunxi%2bunsubscr...@googlegroups.com. For more options, visit https://groups.google.com/__groups/opt_out https://groups.google.com/groups/opt_out. -- Jonathan Aquilina -- 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/groups/opt_out. -- 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/groups/opt_out.
Re: [linux-sunxi] Re: How to test wifi in A20.
Hi Puneet,
bcmdhd is currently not working in the sunxi-3.4 kernel; this is known.
We will try to backport the 3.14 patches to see if that makes it work.
The cubieboard kernel's patched some stuff in but I think there's a bug
somewhere as you mention with the gpio's. I did see this document
somewhere (mailing list or some wiki; i forgot)
Oliver
On 17-01-14 08:54, Puneet B wrote:
Hi,
While tracing problem i found below issue.
i am getting error in log as:
[4.780261] [dhd_module_init] get wl_host_wake gpio failed
The code is from here:./
vim linux-sunxi/drivers/net/wireless/bcmdhd/dhd_linux.c +4396
if (gpio_request(WL_HOST_WAKE_DEF_GPIO, wl_host_wake)) {
pr_warning([%s] get wl_host_wake gpio failed\n,
__FUNCTION__);
wl_host_wake = -1;
return -1;
}
Which means some gpio error:
In script for wifi:
ap6xxx_wl_regon = port:PH091defaultdefault0
ap6xxx_wl_host_wake = port:PH100defaultdefault0
ap6xxx_bt_regon = port:PB051defaultdefault0
ap6xxx_bt_wake = port:PI201defaultdefault0
ap6xxx_bt_host_wake = port:PI210defaultdefault0
ap6xxx_lpo = port:PI124defaultdefaultdefault
For ap6xxx_wl_host_wake , i check by making high and low but error is same.
Can any one tell why that error is, Is it because of some gpio pins or
something else went wrong?
Regards
Punith
--
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/groups/opt_out.
--
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/groups/opt_out.
Re: [linux-sunxi] Booting Android with uboot
On 15-01-14 13:15, jonsm...@gmail.com wrote: On Wed, Jan 15, 2014 at 12:44 AM, Henrik Nordström hen...@henriknordstrom.net wrote: tis 2014-01-14 klockan 22:44 -0500 skrev jonsm...@gmail.com: I can boot Linux using this procedure without problem, but I can't get my Android kernel to boot. Android kernel just hangs... What is the difference between linux and an Android kernel? linux-sunxi.org kernel is an Android kernel. The CSI camera code in the Allwinner SDK kernel is far different than the code in sunxi kernel. I am unable to get the sunxi code working with a camera. sunxi code is losing buffers and after a few second stops because all of the buffers are lost. I started porting Allwinner CSI over but it relies on a lot of structure changes (gpio support) in the h files and that started rippling into a bunch of other code. The sunxi CSI code is old 3.0 code dropped CSI stuff; I don't think it received (m)any patches, so as usual, patches more then welcome! Oliver Does script.bin need to be somewhere else for the Android kernel to find it? I am using Android kernel from Allwinner SDK, not the sunxi one. So your question is do the Allwinner SDK kernel need script.bin in another place than the linux-sunxi.org kernel? No they expect script.bin in the same place. 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/groups/opt_out. -- 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/groups/opt_out.
Re: [linux-sunxi] Sudden memory failure on an A20-OLinuXino-MICRO
On 14-01-14 19:52, Axel Theilmann wrote: You probably best contact olimex for custommer support Oliver moin, i know nothing about the specific problem, but have you checked your power supply? yes, the power supply should be ok. i have used it for months without problems. it works ok with lots of other boards (both of the same type and other models). i tried different voltage levels (the board can accept 6 - 16 Volt) and the power supply is also powerful enough. tty, axel -- 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/groups/opt_out.
Re: [linux-sunxi] [PATCH u-boot-sunxi] ARM: sunxi: get script.bin file name from env
Pat,
Thanks, Pushed this now.
Yeah it doesn't hurt having it available as an env at all. I don't think
it matters greatly for having it in mainline, if everything is cleaned
up, passing script.bin or dtb is up to the user, so it may as well fly.
Oliver
On 09-01-14 06:49, Patrick Wood wrote:
All the other files can be overridden by env settings, what's so
special about script.bin?
Use the script env variable instead of hard-coding script.bin
everywhere; still defaults to script.bin, but can be overridden
from uEnv.txt or boot.scr.
Signed-off-by: Patrick Wood patrickhw...@gmail.com
---
include/configs/sunxi-common.h |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 2c86a8e..a0c41ac 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -213,6 +213,7 @@
kernel=uImage\0 \
bootenv=uEnv.txt\0 \
bootscr=boot.scr\0 \
+ script=script.bin\0 \
loadbootscr= \
fatload $device $partition $scriptaddr ${bootscr} \
|| \
@@ -231,19 +232,19 @@
if \
bootpath=/boot/ \
\
- ext2load $device $partition 0x4300 ${bootpath}script.bin \
+ ext2load $device $partition 0x4300 ${bootpath}${script} \
\
ext2load $device $partition 0x4800 ${bootpath}${kernel} \
;then true; elif \
bootpath=/ \
\
- fatload $device $partition 0x4300 script.bin \
+ fatload $device $partition 0x4300 ${script} \
\
fatload $device $partition 0x4800 ${kernel} \
;then true; elif \
bootpath=/ \
\
- ext2load $device $partition 0x4300 ${bootpath}script.bin \
+ ext2load $device $partition 0x4300 ${bootpath}${script} \
\
ext2load $device $partition 0x4800 ${bootpath}${kernel} \
;then true; else \
--
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/groups/opt_out.
Re: [linux-sunxi] Doing some sunxi hacking in Brussels the Friday before Fosdem ?
Just an FYI to the hacking session; while it sounds like a lot of fun and something really cool I could learn a lot from, I won't be able to schedule that in at all. To bad FOSDEM is so awesome and there are so many interesting talks! So sat/sun is out of the question. Oliver On 14-01-14 14:28, Benjamin Henrion wrote: On Tue, Jan 14, 2014 at 1:29 PM, Zoltan HERPAI wigy...@uid0.hu wrote: On Tue, 14 Jan 2014, Ian Campbell wrote: On Tue, 2014-01-14 at 11:49 +0100, Luc Verhaegen wrote: On Tue, Jan 14, 2014 at 10:19:36AM +, Ian Campbell wrote: It sound cool! I'm arriving at Brussels Midi at 1405 on Friday afternoon. I'm not sure if I'll have other Xen/work related commitments that afternoon though. Would it be OK to just rock up, assuming you get enough confirmed interest to go ahead? So you go from midi to your hotel and check-in and stuff... Add the 30 or so minutes commute from the gare centrale... You will be at the ulb at 16:00 at the earliest. Around 16:30 you might finally sit down and have a hacking session. There was talk of hacking until ~2000, which is 3.5hrs, plenty of time to get some useful stuff done IMHO. I'd also expect to be there more like 1500-1530 in any case. Assuming it goes ahead of course. I plan to arrive in Brussels around noon, so once settled in the hotel I could get to the place in the afternoon. Benjamin, do you have any costs with this? Event is free, but urlab sells some drinks and food. They are also interested in geek stickers, if you have some good ones. And they also accept donations... -- 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/groups/opt_out.
Re: [linux-sunxi] 24-bit Audio Isn't Working
I don't think anybody here has tested this yet either. So any findings are very welcome! Oliver On 13-01-14 05:29, George Ioakimedes wrote: We've been looking into supporting high resolution audio file playback, specifically 24-bit/96kHz and 24-bit/192kHz files. We've made some changes and had a little progress but are still not able to get proper playback of 24-bit audio files. I'm hoping that by posting here someone else has looked at this or has some ideas of what is needed to get this working. We've confirmed with Allwinner that it should work but that it was never tested. -- 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/groups/opt_out. -- 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/groups/opt_out.
Re: [linux-sunxi] [PATCH] Fix K1001L1C LCD bug
On 13-01-14 00:51, Korneliusz Osmenda wrote: Fex file for tablet didn't specified pll3 setting which caused nonworking LCD. --- sys_config/a20/k1001l1c.fex | 1 + 1 file changed, 1 insertion(+) diff --git a/sys_config/a20/k1001l1c.fex b/sys_config/a20/k1001l1c.fex index 54ac2c7..b11d75e 100644 --- a/sys_config/a20/k1001l1c.fex +++ b/sys_config/a20/k1001l1c.fex @@ -16,6 +16,7 @@ power_start = 0 storage_type = -1 [clock] +pll3 = 297 pll4 = 300 pll6 = 600 pll7 = 297 applied, thanks oliver -- 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/groups/opt_out.
Re: [linux-sunxi] Doing some sunxi hacking in Brussels the Friday before Fosdem ?
On 23-01-14 09:36, Ian Campbell wrote: On Wed, 2014-01-22 at 20:16 +0100, Hans de Goede wrote: I will be at the urlab at around 12:00 (if I make my train connection otherwise 13:00), it is fine if you decide to show up announced, I plan to stay till 20:00 and then go out for dinner. I hope to see you there. I think I should be there mid-late afternoon, my other potential commitments aren't happening AFAICT. I was thinking about hacking on SATA support for u-boot, it doesn't seem to exist yet -- do you know of anyone who is working on that? I did some early research, and there is some basic support for ahci for some platforms, problem is, there is I think 3 or 4 ways it is done right now? But yeah, it should be relatively easy, the actual sunxi glue-code isn't huge, so if you can hack that in during your train trip; that'd be awesome ;) Oliver Since there is already a libahci in u-boot it ought to be something which can be achieved in a few hours on the train + a few hours of hack session in Brussels. At least I hope it doesn't turn out to be quite so epic as the upstream Linux support ;-) 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/groups/opt_out.
Re: [linux-sunxi] Doing some sunxi hacking in Brussels the Friday before Fosdem ?
On 22-01-14 20:16, Hans de Goede wrote: Hi, On 01/14/2014 11:19 AM, Ian Campbell wrote: On Mon, 2014-01-13 at 17:13 +0100, Hans de Goede wrote: Hi All, I know it is pretty late for this, and that most of you have already made travel arrangements, sorry about that. I have this last moment spontaneous idea that it would be fun for people who are in or near Brussels anyways (*), to do some sunxi hacking on the Friday before Fosdem. Benjamin Henrion, who is also helping with organizing the sunxi dinner Saturday evening, has reserved some room for this at the urlab hackerspace: http://urlab.be/ which is around the corner of the Fosdem venue. If you think this would be fun and plan to join us Friday please let me know. If I get out of bed early enough I can be there at 10 AM, but as you can imagine if no-one else is coming (or just not that early) then I'll probably go there a bit later :) It sound cool! I'm arriving at Brussels Midi at 1405 on Friday afternoon. I'm not sure if I'll have other Xen/work related commitments that afternoon though. Would it be OK to just rock up, assuming you get enough confirmed interest to go ahead? I will be at the urlab at around 12:00 (if I make my train connection otherwise 13:00), it is fine if you decide to show up announced, I plan to stay till 20:00 and then go out for dinner. I hope to see you there. Hans, totally off-topic, but do you know if they can panelize PCB's at Urlab? Existing PCB's that is. oliver 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/groups/opt_out.
Re: [linux-sunxi] Re: How to test wifi in A20.
On 23-01-14 13:21, Puneet B wrote: Hi Patrick, Actually i compiled bcmdhd as a driver not as a module. because if i compiled as a module and try to insert it i am getting fallowing error. modprobe: FATAL: Could not load /lib/modules/3.4.75-1-g9cfbbed/modules.dep: No such file or directory looks like you forgot to run depmod -a or didn't make modules_install Do you think this will be problem? modules.dep informs modprobe about module order and dependencies; so yeah, could be. regards Punith -- 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/groups/opt_out. -- 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/groups/opt_out.
Re: [linux-sunxi] sun5i serial driver kills serial output
On 27-01-14 13:38, jonsm...@gmail.com wrote: Are you running the Fedora image? console doesn't work for me on the Fedora image but it works fine on a Linaro image. I haven't checked but Fedora image probably isn't starting getty on the console. Can't even interact with u-boot etc oliver On Mon, Jan 27, 2014 at 5:23 AM, Olliver Schinagl oliver+l...@schinagl.nl wrote: On 26-01-14 21:50, Michal Suchanek wrote: Hello, I set up a13 with the SD breakout board and while u-boot console and early kernel messages show fine initializing the sunxi serial driver stops any kernel messages from appearing. Disabling the serial driver in script.bin solves the issue but does not allow for communicating with the Linux system over the serial port. Anyone else is seeing such issue? Yes, I noticed the exact same thing on an A13 tablet, it was spewing all the debug stuff as usual, but wouldn't respond to input. I wasn't overly interested so gave up, this was using the mUSB breakout board. oliver 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- 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/groups/opt_out.
Re: [linux-sunxi] Re: How to port ubuntu in my A20 board.
On 28-01-14 13:57, Puneet B wrote: Hi Dimitriy, I downloded linaro-saucy-developer-20131216-586.tar.gz probably also without GUI. try hansg's fedora images to get yourself more familiar, that should work just fine. google for hansg cubieboard fedora 19 r3; his own repo seems to be down atm and i copied in sdcard and booted. But i got struck here: [7.057834] devtmpfs: mounted 6Freeing init memory: 216K [7.069043] Freeing init memory: 216K 6Write protecting the kernel text section c0008000 - c0817000 [7.078378] Write protecting the kernel text section c0008000 - c0817000 4init: ureadahead main process (71) terminated with status 5 [7.644747] init: ureadahead main process (71) terminated with status 5 Kindly tell me what will be the issue. Regards Punith -- 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/groups/opt_out. -- 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/groups/opt_out.
Re: [linux-sunxi] Re: Unable to play 720p video in Ubuntu
On 04-02-14 11:35, Puneet B wrote: vo: couldn't open the X11 display ()! Error opening/initializing the selected video_out (-vo) device. You probably forgot a step or two. -- 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/groups/opt_out.
Re: [linux-sunxi] Re: Unable to play 720p video in Ubuntu
On 04-02-14 15:36, Puneet B wrote: Hi Oliver, I did same procedure. what video player are you using? Only mplayer2 and mpv work; mplayer 1 will NOT work. Regards punith On Tue, Feb 4, 2014 at 8:00 PM, Olliver Schinagl oliver+l...@schinagl.nl mailto:oliver+l...@schinagl.nl wrote: On 04-02-14 11:35, Puneet B wrote: vo: couldn't open the X11 display ()! Error opening/initializing the selected video_out (-vo) device. You probably forgot a step or two. -- You received this message because you are subscribed to a topic in the Google Groups linux-sunxi group. To unsubscribe from this topic, visit https://groups.google.com/d/__topic/linux-sunxi/PGlgXgaEh24/__unsubscribe https://groups.google.com/d/topic/linux-sunxi/PGlgXgaEh24/unsubscribe. To unsubscribe from this group and all of its topics, send an email to linux-sunxi+unsubscribe@__googlegroups.com mailto:linux-sunxi%2bunsubscr...@googlegroups.com. For more options, visit https://groups.google.com/__groups/opt_out https://groups.google.com/groups/opt_out. -- 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/groups/opt_out. -- 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/groups/opt_out.
Re: [linux-sunxi] Changes to the sunxi audio drivers.
On 06-02-14 15:43, Code Kipper wrote: That's fine.I'll update the wiki with the notes that I've made on the registers and I'll try to maintain my changes on my fork for now. Do you know how often Allwinner produce a new dump?I can wait and see how much effort a backport takes when the next one comes. We have the a23 sdk dump; which is a new kernel with updated stuff; you could try integrating that into the current stuff as a starter? It's fairly straightforward to work around platform differences without #ifdefs so I'll tackle that one first, BR, CK On 6 February 2014 15:27, Olliver Schinagl oliver+l...@schinagl.nl mailto:oliver+l...@schinagl.nl wrote: On 05-02-14 08:21, Code Kipper wrote: Hi, A while ago I submitted a load of patches basically cleaning up the audio drivers to get rid of every checkpatch error and to delete stuff which I thought wasn't needed. The thread can be seen here I'm not sure if this is a great idea as it makes backporting stuff from newer dumps much harder. I think your efforts are better used in possibly starting to clean it up in a seperate branch so that it can go upstream into mainline? Mind you, no DMA yet there. Otherwise try to see if you can make the driver without #ifdefs so sunxi_soc works for sun4i, sun5i, sun7i without compile time differences. Oliver https://groups.google.com/__forum/#!msg/linux-sunxi/__u3OE9vO-MvM/WNDo3KjXT3gJ https://groups.google.com/forum/#!msg/linux-sunxi/u3OE9vO-MvM/WNDo3KjXT3gJ. I took onboard the comments that were made and I've started to break the patches down into smaller more easily manageable chunks. These are my current plans: 1)Update the wiki with the register and bit details. 2)First patch set removes all the unnecessary headers. 3)Next patch set removes all the magic numbers that I'm finding. 4)Break down the tidy up patches that I first submitted, basically it was formatting and removal of Chinese comments. 5)Remove headers which aren't shared across files. 6)Major refactoring in preparation for mainlining activities. Does anybody have anything to add to this and is anybody else working on the audio drivers at the moment?. I'm currently working my way through the sunxi-codec driver which brings me to my next question. Can anybody recommend a A20(or A31) tablet preferably 10 which I get hold of quickly in Europe?, I need this so I can make sure these codec changes aren't breaking things. Thanks in advance, CK. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@__googlegroups.com mailto:linux-sunxi%2bunsubscr...@googlegroups.com. For more options, visit https://groups.google.com/__groups/opt_out https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@__googlegroups.com mailto:linux-sunxi%2bunsubscr...@googlegroups.com. For more options, visit https://groups.google.com/__groups/opt_out https://groups.google.com/groups/opt_out. -- 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/groups/opt_out. -- 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/groups/opt_out.
Re: [linux-sunxi] Re: Unable to play 720p video in Ubuntu
Puneet, On 10-02-14 13:28, Puneet B wrote: Hi I am not able to play hd videos smoothly from this link. http://linux-sunxi.org/Cedrus Here is my Procedure what i have done: 1setenv sunxi_ve_mem_reserve '128' 2git clone https://github.com/linux-sunxi/libvdpau-sunxi 3cd libvdpau-sunxi 4make 5make install Then i have libvdpau_sunxi.so.1 libvdpau_trace.so.1 libvdpau_trace.so.1.0.0 libraries under /usr/lib/vdpau directory 4then i login as user in gnome-terminal and export fallowing path. export VDPAU_DRIVER=sunxi 5sudo chmod -R 777 /dev/disp /dev/cedar_Dev ls -laF /dev/disp /dev/cedar* and double check the permissions!! because _Dev sounds wrong, should be _dev. 6apt-get install mplayer2. 6mplayer -vo vdpau -vc ffmpeg12vdpau,ffh264vdpau, /media/9513-1851/aa.mp4 But once i play video , it is not playing smoothly. Here is my video log: MPlayer2 UNKNOWN (C) 2000-2011 MPlayer Team mplayer: could not connect to socket mplayer: No such file or directory Failed to open LIRC support. You will not be able to use your remote control. Playing /media/95E5-18AE/aga_naga.mp4. Detected file format: QuickTime/MPEG-4/Motion JPEG 2000 format (libavformat) But puneet, this is not MPEG1, MPEG2 and definitely not h264. Sounds like motion jpeg in an mpeg4 container. Try the big buck buney h264 or sintel h264 demo's. Olliver [lavf] stream 0: video (h264), -vid 0 [lavf] stream 1: audio (aac), -aid 0, -alang eng VIDEO: [H264] 1264x536 24bpp 23.976 fps 3674.8 kbps (448.6 kbyte/s) Clip info: major_brand: mp42 minor_version: 0 compatible_brands: mp42ndhdavc1isom creation_time: 2011-07-28 17:45:17 Load subtitles in /media/95E5-18AE/ [VDPAU SUNXI] VE version 0x1623 opened. == Forced video codec: ffmpeg12vdpau Forced video codec: ffh264vdpau Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family Selected video codec: [ffh264vdpau] vfm: ffmpeg (FFmpeg H.264 (VDPAU)) == == Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders AUDIO: 48000 Hz, 6 ch, s16le, 447.6 kbit/9.71% (ratio: 55947-576000) Selected audio codec: [ffaac] afm: ffmpeg (FFmpeg AAC (MPEG-2/MPEG-4 Audio)) == AO: [pulse] 48000Hz 2ch floatle (4 bytes per sample) Starting playback... Movie-Aspect is 2.36:1 - prescaling to correct movie aspect. VO: [vdpau] 1264x536 = 1264x536 H.264 VDPAU acceleration [vdpau] Got display refresh rate 50.000 Hz. [vdpau] If that value looks wrong give the -vo vdpau:fps=X suboption manually. [VDPAU SUNXI] Presentation time not supported 0 ??% ??% ??,?% 0 0 A: 12.2 V: 12.2 A-V: -0.000 ct: -0.000 0/ 0 17% 0% 7.1% 0 0 Exiting... (Quit) I tried with smplayer also but has same issue. Is i am missing anything else. Kindly suggest me. Regards Punith -- 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/groups/opt_out. -- 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/groups/opt_out.
Re: [linux-sunxi] Re: Unable to play 720p video in Ubuntu
On 10-02-14 14:36, Puneet B wrote: Hi Oliver. sorry i changed permission to cedar_dev (typo error). Try the big buck buney h264 or sintel h264 demo's. Can you explain this , as i am not getting. http://samplemedia.linaro.org/H264/big_buck_bunny_1080p_H264_AAC_25fps_7200K.MP4 if that works, your decoder is setup properly. OTher files not working simply means our driver or the decoder doesn't like your file and falls back to software decoding. Regards Punith -- 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/groups/opt_out. -- 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/groups/opt_out.
Re: [linux-sunxi] Re: Unable to play 720p video in Ubuntu
On 10-02-14 15:27, Puneet B wrote: Hi Oliver, As i played you video also , has the same issue. Video is not playing smoothly. Here is log: MPlayer2 UNKNOWN (C) 2000-2011 MPlayer Team mplayer: could not connect to socket mplayer: No such file or directory Failed to open LIRC support. You will not be able to use your remote control. Playing /media/95E5-18AE/big_buck_bunny_1080p_H264_AAC_25fps_7200K.MP4 that looks good Detected file format: QuickTime/MPEG-4/Motion JPEG 2000 format (libavformat) that looks wrong [lavf] stream 0: video (h264), -vid 0 [lavf] stream 1: audio (aac), -aid 0, -alang und VIDEO: [H264] 1280x720 24bpp 24.000 fps 1748.2 kbps (213.4 kbyte/s) That looks wrong too, 1280x720 is weir, since the video is 1080p. Maybe you are still using the wrong file, even though the name seems right? Try a different USB stick to make sure your not using the old file. Clip info: major_brand: mp42 minor_version: 0 compatible_brands: isommp42 creation_time: 2014-01-06 15:51:24 Load subtitles in /media/95E5-18AE/ [VDPAU SUNXI] VE version 0x1623 opened. == Forced video codec: ffmpeg12vdpau Forced video codec: ffh264vdpau Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family Selected video codec: [ffh264vdpau] vfm: ffmpeg (FFmpeg H.264 (VDPAU)) == == Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders AUDIO: 44100 Hz, 2 ch, s16le, 192.0 kbit/13.61% (ratio: 24000-176400) Selected audio codec: [ffaac] afm: ffmpeg (FFmpeg AAC (MPEG-2/MPEG-4 Audio)) == AO: [pulse] 44100Hz 2ch s16le (2 bytes per sample) Starting playback... Movie-Aspect is undefined - no prescaling applied. VO: [vdpau] 1280x720 = 1280x720 H.264 VDPAU acceleration [vdpau] Got display refresh rate 50.000 Hz. [vdpau] If that value looks wrong give the -vo vdpau:fps=X suboption manually. [VDPAU SUNXI] Presentation time not supported 0 ??% ??% ??,?% 0 0 [VDPAU SUNXI] vdp_output_surface_put_bits_indexed called but unimplemented! [VDPAU SUNXI] vdp_output_surface_render_output_surface called but unimplemented! A: 34.2 V: 34.2 A-V: -0.000 ct: 0.000 0/ 0 17% 0% 2.6% 0 0 Exiting... (End of file) Regards Punith -- 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/groups/opt_out. -- 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/groups/opt_out.
Re: [linux-sunxi] Converting S3C code to sunxi code
On 02/21/14 22:05, Almo Nito wrote:
Can Someone please help converting the following code into sunxi code:
#define GTP_RST_PORTS5PV210_GPJ3(6)
#define GTP_INT_PORTS5PV210_GPH1(3)
#define GTP_INT_IRQ gpio_to_irq(GTP_INT_PORT)
#define GTP_INT_CFG S3C_GPIO_SFN(0xF)
#define GTP_GPIO_AS_INPUT(pin) do{\
gpio_direction_input(pin);\
s3c_gpio_setpull(pin,
S3C_GPIO_PULL_NONE);\
}while(0)
#define GTP_GPIO_AS_INT(pin)do{\
GTP_GPIO_AS_INPUT(pin);\
s3c_gpio_cfgpin(pin,
GTP_INT_CFG);\
}while(0)
#define GTP_GPIO_GET_VALUE(pin) gpio_get_value(pin)
#define GTP_GPIO_OUTPUT(pin,level) gpio_direction_output(pin,level)
#define GTP_GPIO_REQUEST(pin, label)gpio_request(pin, label)
#define GTP_GPIO_FREE(pin) gpio_free(pin)
#define GTP_IRQ_TAB {IRQ_TYPE_EDGE_RISING,
IRQ_TYPE_EDGE_FALLING, IRQ_TYPE_LEVEL_LOW, IRQ_TYPE_LEVEL_HIGH}
This would be very very helpful for me
https://github.com/oliv3r/u-boot-sunxi/blob/8dde68488f9c9b62f41a9cb1a6403660c80a3f60/arch/arm/include/asm/arch-sunxi/gpio.h
this is how it's handled in u-boot.
not quite sure what youa re after though ...
oliver
Thank you very much
--
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/groups/opt_out.
Re: [linux-sunxi] how to flash android in NAND without phonixsuite ..
On 02/21/14 13:21, Puneet B wrote: [ 2.933] boot1: bad boot image magic, maybe not a boot.img? Your boot1 is not right, boot0 loaded fine from the flash, but it couldn't find boot1 where it expected it to be. oliver -- 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/groups/opt_out.
Re: [linux-sunxi] Kernel compile: error in sunxi-usb-rfkill.c
On 02/23/14 19:18, crawler2014 wrote: Hi guys, I tried to compile a new kernel using the sources from http://docs.cubieboard.org/tutorials/a20-cubietruck_lubuntu_server_releases, kernel 3.4.79 [Lubuntu Server, currently running kernel 3.4.61+]. Mind you, that linux-sunxi is about the kernel hosted at github.com/linux-sunxi, so which kernel are you using? If http://dl.cubieboard.org/software/a20-cubietruck/lubuntu/ct-lubuntu-nand-v1.00/ct-lubuntu-server-20131026/ is the one, then you should ask your question on the cubieboard mailinglist as we are not aware of all the patches they use ontop of our tree. Best is to use our kernel as a starting point. Chances are that bug was fixed. oliver I am compiling on the cubietruck, compiling stops after a lot of successful steps with the following error message: | /usr/src/v1.02/kernel-source/net/rfkill/sunxi-usb-rfkill.c:128:undefinedreference to `__stack_chk_fail' make: *** [.tmp_vmlinux1] Error 1 | Long version: | net/built-in.o:Infunction`sunxi_usb_rfkill_init': /usr/src/v1.02/kernel-source/net/rfkill/sunxi-usb-rfkill.c:103: undefined reference to `__stack_chk_guard' /usr/src/v1.02/kernel-source/net/rfkill/sunxi-usb-rfkill.c:103: undefined reference to `__stack_chk_guard' /usr/src/v1.02/kernel-source/net/rfkill/sunxi-usb-rfkill.c:128:undefinedreference to `__stack_chk_fail' make: *** [.tmp_vmlinux1] Error 1 | can anybody help me with this issue? -- 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/groups/opt_out. -- 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/groups/opt_out.
Re: [linux-sunxi] Fedora 19 update causes bootloader to fail?
On 02/23/14 09:07, Hans de Goede wrote: Hi, On 02/22/2014 09:57 PM, Oliver Schinagl wrote: False alarm I should have cheked it out first; After mounting my SD card in the desktop, I noticed the boot partition had a new kernel and everything was overwritten. ./select-board.sh fixed it, so no biggie. Is it an idea to remove /dev/mmcblk0p1 from fstab? Nah, just edit /etc/yum.conf and add an exclude kernel* line actually there already is an exclude line there, as we had the same problem with F-18, but the kernel package name changed in F-19, and I forgot to fix the exclude. That will also exclude the boot.cmd updates? Good to know it's that easy. Oliver 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/groups/opt_out.
Re: [linux-sunxi] Fedora 19 update causes bootloader to fail?
On 02/23/14 23:05, Hans de Goede wrote: Hi, On 02/23/2014 10:54 PM, Olliver Schinagl wrote: On 02/23/14 09:07, Hans de Goede wrote: Hi, On 02/22/2014 09:57 PM, Oliver Schinagl wrote: False alarm I should have cheked it out first; After mounting my SD card in the desktop, I noticed the boot partition had a new kernel and everything was overwritten. ./select-board.sh fixed it, so no biggie. Is it an idea to remove /dev/mmcblk0p1 from fstab? Nah, just edit /etc/yum.conf and add an exclude kernel* line actually there already is an exclude line there, as we had the same problem with F-18, but the kernel package name changed in F-19, and I forgot to fix the exclude. That will also exclude the boot.cmd updates? Yes AFAIK those are done by kernel upgrade post-install scripts. Thanks Hans, I made a warning about this in my book. I manually 'fixed' it, but I guess it's safe to just do a select-board.sh again? It only re-writes bootloader, config scripts and kernel, no matter what is in the root at that moment, right? Oliver 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/groups/opt_out.
Re: [linux-sunxi] Fedora porting in A20.
On 24-02-14 15:23, Puneet B wrote: Hi HNO, I fallow this link to boot fedora 19 in my A20 board. http://docs.cubieboard.org/tutorials/cb2/installation/cb2_fedora_19_card_install my device is booted fine. then i set root passwd and created an user. but if login both as root and user , device is showing always incorrect password. i double check it. but same result. How can i change root passwd and create one more user. You may have set up the wrong keyboard locale? As the procedure is 'guaranteed to work' more or less on a US keyboard for sure. I've done the installation a few times in the last few weeks and it worked fine, on a regular US keyboard layout. Anyway, a quick and easy fix is to shutdown fedora from the SD card, eject it from the board and put it in a carddreader of some sort. Put it in your other linux PC and mount /dev/sdb3 (or whever it ends up as) e.g. the rootfs. Edit to /mnt/lib/systemd/system/serial-getty@.service and find the line that says ... agetty and add agetty -a root this makes agetty on the serial port always login as root so if you connect via the serial port, you dont' have to log in, you can then easily change passwords as root. Not sure how the serial port and the keyboard locale on the GUI will relate however! Oliver Regards Punith -- 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/groups/opt_out. -- 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/groups/opt_out.
Re: [linux-sunxi] Fedora porting in A20.
On 02/28/14 13:58, Puneet B wrote: In Fedora, Is it possible to port vlc and mplayer with cedarx by using fallowing link. Should be http://linux-sunxi.org/VLC Haven't tried this one http://linux-sunxi.org/Cedrus I wrote the guide using Fedora have you fixed your login issue? Inform the list on what you did :) Regards Punith -- 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/groups/opt_out. -- 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/groups/opt_out.
Re: [linux-sunxi] Looking for a 3rd book reviewer!
Thanks for the people responding! I am set for now, no more queries on this :) Olliver On 03/07/14 10:55, Olliver Schinagl wrote: Hey List, I have tried poking in the IRC channel for a technical reviewer for my up coming book. Two nice gents have agreed to free some of their time to review my book, follow the tutorials etc. However a third reviewer is still needed and so I decided to write to the Mailing list to find a third person. What we are after is a person who is literate in reading the English language, as the book will obviously be written in English. You don't have to be able to write perfect English, as I will have to do that ;) Also the book is written in LibreOffice and uses .odt files, so those will have to be used ideally, but shouldn't be a problem to most of the people here. Finally having an OLinuXino or a cubieboard is kinda needed, as otherwise following the examples will be really hard ;) A mele or what not should do the trick as well of course, so bonus points for trying it on different hardware! The book is aimed at a beginner and well focuses more about general Linux usage mostly, since while it is ARM, it's still 'just linux' and there's really nothing that special ;) So if your interested as a reviewer, send me a note (on or off list) and I'll forward your contact details to Packt Publishing http://packtpub.com Thanks, Olliver -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Flight Gear
On 03/08/14 18:14, R M wrote: Hi, I came to know that there is Fedora distribution that works on sunxi devices. Yes, but afaik by default it doesn't feature opengl acceleration. I just wanted to know has anyone played Flight Gear in any of the sunxi devices ? Not that I'm aware If yes, how was the performance and gaming experience ? Try it and report your findings here! You probably do have to install the mali drivers, which are explained how to do so on the wiki. Olliver Regards, RM -- 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 mailto:linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [PATCH] Add mmc support for sun4i
Has anybody merged this into 3.4? is it worth spending time on this?
oliver
On 01/15/14 11:00, wills wrote:
It's for sunxi-3.4, use new mmc driver for sun4i.
On Wednesday, January 15, 2014 5:55:19 PM UTC+8, wills wrote:
---
drivers/mmc/host/Kconfig | 2 +-
drivers/mmc/host/sunxi-mci.h | 45
+++-
2 files changed, 33 insertions(+), 14 deletions(-)
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 958a428..5f1d3d8 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -558,7 +558,7 @@ config MMC_SH_MMCIF
config MMC_SUNXI_NEW
tristate SUNXI MMC Card Interface support (new driver)
-depends on MMC (ARCH_SUN5I || ARCH_SUN7I)
+depends on MMC (ARCH_SUN4I || ARCH_SUN5I || ARCH_SUN7I)
default y
help
This selects support for the SD/MMC controller on AllWinner
SoCs.
diff --git a/drivers/mmc/host/sunxi-mci.h b/drivers/mmc/host/sunxi-mci.h
index 8e385c5..1447257 100644
--- a/drivers/mmc/host/sunxi-mci.h
+++ b/drivers/mmc/host/sunxi-mci.h
@@ -24,17 +24,32 @@
Compiled in __DATE__ at __TIME__
/*== platform define ==*/
+/*-- for sun4i --*/
+#ifdef CONFIG_ARCH_SUN4I
+#define REG_FIFO_OS(0x100)
+#define SMC_IRQNO(x)(SW_INT_IRQNO_SDMC0 + (x))
+
+#define MMC_SRCCLK_HOSChosc
+#define MMC_SRCCLK_PLL6sdram_pll_p
+#define MMC_AHBCLK_PREFIXahb_sdc
+#define MMC_MODCLK_PREFIXsdc
+#define MMC3_DMA_TL(0x20070008)
+#define MMC_MAX_DMA_DES_BIT13
+#define MMC_DMA_DES_BIT_LEFT5
+#endif
+
/*-- for sun5i --*/
#ifdef CONFIG_ARCH_SUN5I
-#define REG_FIFO_OS(0x100)
-#define SMC_IRQNO(x)(SW_INT_IRQNO_SDMC0 + (x))
-
-#define MMC_SRCCLK_HOSChosc
-#define MMC_SRCCLK_PLL5sdram_pll_p
-#define MMC_SRCCLK_PLL6sata_pll_2
-#define MMC_AHBCLK_PREFIXahb_sdc
-#define MMC_MODCLK_PREFIXsdc
-#define MMC3_DMA_TL(0x20070008)
+#define REG_FIFO_OS(0x100)
+#define SMC_IRQNO(x)(SW_INT_IRQNO_SDMC0 + (x))
+
+#define MMC_SRCCLK_HOSChosc
+#define MMC_SRCCLK_PLL6sata_pll_2
+#define MMC_AHBCLK_PREFIXahb_sdc
+#define MMC_MODCLK_PREFIXsdc
+#define MMC3_DMA_TL(0x20070008)
+#define MMC_MAX_DMA_DES_BIT16
+#define MMC_DMA_DES_BIT_LEFT0
#endif
/*-- for sun6i --*/
@@ -47,6 +62,8 @@
#define MMC_AHBCLK_PREFIX ahb_sdmmc
#define MMC_MODCLK_PREFIX mod_sdc
#define MMC3_DMA_TL (0x2007000f)
+#define MMC_MAX_DMA_DES_BIT16
+#define MMC_DMA_DES_BIT_LEFT0
#ifdef CONFIG_AW_FPGA_PLATFORM
#undef SMC_IRQNO
@@ -61,11 +78,12 @@
#define SMC_IRQNO(x)(SW_INT_IRQNO_SDMC0 + (x))
#define MMC_SRCCLK_HOSC hosc
-#define MMC_SRCCLK_PLL5 sdram_pll_p
#define MMC_SRCCLK_PLL6 sata_pll
#define MMC_AHBCLK_PREFIX ahb_sdc
#define MMC_MODCLK_PREFIX sdc
#define MMC3_DMA_TL (0x20070008)
+#define MMC_MAX_DMA_DES_BIT16
+#define MMC_DMA_DES_BIT_LEFT0
#ifdef CONFIG_AW_FPGA_PLATFORM
#undef SMC_IRQNO
@@ -232,7 +250,7 @@
#define SDXC_IDMA_ERR (SDXC_IDMACFatalBusErr|SDXC_IDMACDesInvalid \
|SDXC_IDMACCardErrSum|SDXC_IDMACAbnormalIntSum)
-#define SDXC_DES_NUM_SHIFT(15)
+#define SDXC_DES_NUM_SHIFT(MMC_MAX_DMA_DES_BIT)
#define SDXC_DES_BUFFER_MAX_LEN(1U SDXC_DES_NUM_SHIFT)
struct sunxi_mmc_idma_des {
u32config;
@@ -244,8 +262,9 @@ struct sunxi_mmc_idma_des {
#define SDXC_IDMAC_DES0_CESBIT(30) // card error summary
#define SDXC_IDMAC_DES0_OWNBIT(31) // des owner:1-idma owns it,
0-host owns it
-u32data_buf1_sz:16,
-data_buf2_sz:16;
+u32data_buf1_sz:MMC_MAX_DMA_DES_BIT,
+data_buf2_sz:MMC_MAX_DMA_DES_BIT,
+:MMC_DMA_DES_BIT_LEFT;
u32buf_addr_ptr1;
u32buf_addr_ptr2;
};
--
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] [PATCH 3.4] sunxi-hdmiaudio: Enable 32-bit audio
Mnemoc, is this confirmed/merged?
Olliver
On 01/27/14 18:54, Patrick Wood wrote:
The original modifications for this patch originate from some custom
changes made to the 3.3 Android kernel by huangxin at allwinnertech.com.
The A10/A20 DMA engine for HDMI audio only supports 16 or 32-bit
transfers. The documentation says 16, 20, and 24 bits, but I have not
been able to get 24-bit audio, ether 3-bytes (PCM_FMTBIT_24_3LE) or
4-bytes (PCM_FMTBIT_24_LE) to work.
This patch removes the non-working PCM formats, PCM_FMTBIT_S18_3LE
and PCM_FMTBIT_S20_3LE, and PCM_FMTBIT_S24_LE and adds suppor for
32-bit HDMI audio (PCM_FMTBIT_S32_LE). It's possible that other 32-bit
formats, like PCM_FMTBIT_U32_LE or PCM_FMTBIT_FLOAT_LE might work, but
couldn't be tested.
This patch was tested with 24-bit and 32-bit .wav files and the ALSA
plughw plugin (for upconverting the 24-bit audio files to 23-bits)
with aplay -v to verify that the target format was S32_LE.
Signed-off-by: Patrick Wood patrickhw...@gmail.com
---
drivers/video/sunxi/hdmi/drv_hdmi.c |6 ++
drivers/video/sunxi/hdmi/hdmi_core.c| 30 +--
drivers/video/sunxi/hdmi/hdmi_core.h|1 +
include/linux/drv_hdmi.h|1 +
sound/soc/sunxi/hdmiaudio/sndhdmi.c | 16 +-
sound/soc/sunxi/hdmiaudio/sunxi-hdmiaudio.c |6 --
sound/soc/sunxi/hdmiaudio/sunxi-hdmipcm.c |3 ++-
7 files changed, 53 insertions(+), 10 deletions(-)
diff --git a/drivers/video/sunxi/hdmi/drv_hdmi.c
b/drivers/video/sunxi/hdmi/drv_hdmi.c
index a8d3cef..283d2ae 100644
--- a/drivers/video/sunxi/hdmi/drv_hdmi.c
+++ b/drivers/video/sunxi/hdmi/drv_hdmi.c
@@ -208,6 +208,12 @@ static __s32 Hdmi_Set_Audio_Para(hdmi_audio_t *audio_para)
if (!audio_para)
return -1;
+ if (audio_para-sample_bit != audio_info.sample_bit) {
+ if (hdmi_state = HDMI_State_Audio_config)
+ hdmi_state = HDMI_State_Audio_config;
+ audio_info.sample_bit = audio_para-sample_bit;
+ }
+
if (audio_para-sample_rate != audio_info.sample_rate) {
audio_info.sample_rate = audio_para-sample_rate;
change = audio_info.audio_en;
diff --git a/drivers/video/sunxi/hdmi/hdmi_core.c
b/drivers/video/sunxi/hdmi/hdmi_core.c
index c1c4c9c..a6dd01f 100644
--- a/drivers/video/sunxi/hdmi/hdmi_core.c
+++ b/drivers/video/sunxi/hdmi/hdmi_core.c
@@ -580,8 +580,14 @@ __s32 audio_config(void)
return 0;
if (audio_info.channel_num == 1) {
- /* audio fifo rst and select ddma, 2 ch 16bit pcm */
- writel(0x, HDMI_AUDIO_UNKNOWN_0);
+ if (audio_info.sample_bit == 32) {
+ /* audio fifo rst and select ddma, 2 ch 32bit pcm */
+ writel(0x000e, HDMI_AUDIO_UNKNOWN_0);
+ } else {
+ /* audio fifo rst and select ddma, 2 ch 16bit pcm */
+ writel(0x, HDMI_AUDIO_UNKNOWN_0);
+ }
+
/* ddma,pcm layout0 1ch */
writel(0x, HDMI_AUDIO_LAYOUT);
writel(0x76543200, HDMI_AUDIO_UNKNOWN_1);
@@ -592,8 +598,14 @@ __s32 audio_config(void)
writel(0x, HDMI_AUDIO_INFOFRAME + 8);
writel(0x, HDMI_AUDIO_INFOFRAME + 12);
} else if (audio_info.channel_num == 2) {
- /* audio fifo rst and select ddma, 2 ch 16bit pcm */
- writel(0x, HDMI_AUDIO_UNKNOWN_0);
+ if (audio_info.sample_bit == 32) {
+ /* audio fifo rst and select ddma, 2 ch 32bit pcm */
+ writel(0x000e, HDMI_AUDIO_UNKNOWN_0);
+ } else {
+ /* audio fifo rst and select ddma, 2 ch 16bit pcm */
+ writel(0x, HDMI_AUDIO_UNKNOWN_0);
+ }
+
/* ddma,pcm layout0 2ch */
writel(0x0001, HDMI_AUDIO_LAYOUT);
writel(0x76543210, HDMI_AUDIO_UNKNOWN_1);
@@ -604,8 +616,14 @@ __s32 audio_config(void)
writel(0x, HDMI_AUDIO_INFOFRAME + 8);
writel(0x, HDMI_AUDIO_INFOFRAME + 12);
} else if (audio_info.channel_num == 8) {
- /* audio fifo rst and select ddma, 2 ch 16bit pcm */
- writel(0x, HDMI_AUDIO_UNKNOWN_0);
+ if (audio_info.sample_bit == 32) {
+ /* audio fifo rst and select ddma, 2 ch 32bit pcm */
+ writel(0x000e, HDMI_AUDIO_UNKNOWN_0);
+ } else {
+ /* audio fifo rst and select ddma, 2 ch 16bit pcm */
+ writel(0x, HDMI_AUDIO_UNKNOWN_0);
+ }
+
/* ddma,pcm layout1 8ch */
writel(0x000f, HDMI_AUDIO_LAYOUT);
Re: [linux-sunxi] [PATCH 3.4] sunxi:axp20x: Enable internal thermal monitoring
Mnemoc,
have you checked and merged this yet?
Olliver
On 01/27/14 20:25, Patrick Wood wrote:
Enable the internal thermal monitoring support of AXP20X chips
Cherry-picked from:
https://github.com/cubieboard/linux-sunxi/commit/e4144b3ce62b1d7014fee36b84bc65c812469822
Creates the sysfs file temp1_input in the sunxi-i2c tree that reports the
AXP's temperature in degrees C.
According to the AXP202's datasheet, this port outputs a 12-bit value
where 0x000 == -144.7C and 0xfff == 264.8C in 0.1 degree C increments.
Signed-off-by: LABBE Corentin clabbe.montj...@gmail.com
Signed-off-by: Hans de Goede hdego...@redhat.com
Signed-off-by: Patrick Wood patrickhw...@gmail.com
---
drivers/power/axp_power/Kconfig |5 ++
drivers/power/axp_power/axp-mfd.c |7 +++
drivers/power/axp_power/axp20-mfd.h | 112 +++
include/linux/mfd/axp-mfd.h |7 +++
4 files changed, 130 insertions(+)
diff --git a/drivers/power/axp_power/Kconfig b/drivers/power/axp_power/Kconfig
index 039679f..b76f517 100644
--- a/drivers/power/axp_power/Kconfig
+++ b/drivers/power/axp_power/Kconfig
@@ -36,4 +36,9 @@ config AXP_CHGCHANGE
bool AXP charging current set when suspend\resume\shutdown
default y
+config AXP_HWMON
+ depends on HWMON
+ bool Enable the internal thermal monitoring support of AXP20X chips
+ default y
+
endif # !AW_AXP
diff --git a/drivers/power/axp_power/axp-mfd.c
b/drivers/power/axp_power/axp-mfd.c
index 9af0257..cfa894a 100644
--- a/drivers/power/axp_power/axp-mfd.c
+++ b/drivers/power/axp_power/axp-mfd.c
@@ -363,6 +363,13 @@ static int __devexit axp_mfd_remove(struct i2c_client
*client)
pm_power_off = NULL;
axp = NULL;
+#ifdef CONFIG_AXP_HWMON
+ if (chip-itm_enabled == 1) {
+ hwmon_device_unregister(chip-hwmon_dev);
+ sysfs_remove_group(client-dev.kobj, axp20_group);
+ }
+#endif
+
axp_mfd_remove_subdevs(chip);
kfree(chip);
return 0;
diff --git a/drivers/power/axp_power/axp20-mfd.h
b/drivers/power/axp_power/axp20-mfd.h
index 1c7a41b..214856e 100644
--- a/drivers/power/axp_power/axp20-mfd.h
+++ b/drivers/power/axp_power/axp20-mfd.h
@@ -22,6 +22,83 @@
#include axp-rw.h
+#ifdef CONFIG_AXP_HWMON
+
+#include linux/hwmon-sysfs.h
+#include linux/hwmon.h
+#include linux/err.h
+
+static struct axp_mfd_chip *axp20_update_device(struct device *dev);
+
+static ssize_t
+show_temp(struct device *dev, struct device_attribute *devattr, char *buf)
+{
+ struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
+ struct axp_mfd_chip *data = axp20_update_device(dev);
+ if (attr-index == 1)
+ return sprintf(buf, 264800\n);
+ if (attr-index == 2)
+ return sprintf(buf, -144700\n);
+ return sprintf(buf, %d\n, data-temperature * 100);
+}
+
+
+static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO, show_temp, NULL, 0);
+static SENSOR_DEVICE_ATTR(temp1_max, S_IRUGO, show_temp, NULL, 1);
+static SENSOR_DEVICE_ATTR(temp1_min, S_IRUGO, show_temp, NULL, 2);
+
+static struct attribute *axp20_attributes[] = {
+ sensor_dev_attr_temp1_input.dev_attr.attr,
+ sensor_dev_attr_temp1_min.dev_attr.attr,
+ sensor_dev_attr_temp1_max.dev_attr.attr,
+ NULL
+};
+
+static const struct attribute_group axp20_group = {
+ .attrs = axp20_attributes,
+};
+
+
+/*
+ * * function that update the status of the chips (temperature)
+ * */
+static struct axp_mfd_chip *axp20_update_device(struct device *dev)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct axp_mfd_chip *data = i2c_get_clientdata(client);
+ int err;
+ u8 high, low;
+
+ mutex_lock(data-lock);
+
+ if (time_after(jiffies, data-last_updated + HZ * 2)
+ || !data-valid) {
+ dev_dbg(client-dev, Updating axp20 data\n);
+ /* AXP202 datasheet page 25, 0x000 means -144.7,
+* 0xfff means 264.8, 4096 steps of 0.1 degress */
+ err = __axp_read(client, 0x5E, high);
+ if (err) {
+ dev_err(dev, AXP Error while reading high\n);
+ high = 0;
+ }
+
+ err = __axp_read(client, 0x5F, low);
+ if (err) {
+ dev_err(dev, AXP Error while reading low\n);
+ low = 0;
+ }
+
+ data-temperature = -1447 + ((high 4) + (low 0x0F));
+ data-last_updated = jiffies;
+ data-valid = 1;
+ }
+
+ mutex_unlock(data-lock);
+ return data;
+}
+
+#endif
+
static int __devinit axp20_init_chip(struct axp_mfd_chip *chip)
{
@@ -33,6 +110,9 @@ static int __devinit axp20_init_chip(struct axp_mfd_chip
*chip)
POWER20_INTSTS3, 0xff, POWER20_INTSTS4, 0xff,
POWER20_INTSTS5, 0xff };
int err;
+#ifdef CONFIG_AXP_HWMON
+ u8
Re: [linux-sunxi] Re: Not able to boot ramdisk on cubietruck
On 03/09/14 16:18, tyler.ba...@linaro.org wrote: On Sunday, March 9, 2014 8:06:27 AM UTC-7, tyler...@linaro.org wrote: Hello, I am trying to boot the cubietruck with a minimal ramdisk. However, it seems to hang at Starting kernel... whenever I pass bootz a ramdisk load address. I have built the latest cubietruck config from here: https://github.com/cubieboard/u-boot-sunxi Here is the boot log: (bootz 0x40008000 0x4200 0x4100) U-Boot 2014.01-09730-gb5bd4c9 (Mar 09 2014 - 05:55:17) Allwinner Technology CPU: Allwinner A20 (SUN7I) Board: Cubietruck I2C: ready DRAM: 2 GiB WARNING: Caches not enabled MMC: SUNXI SD/MMC: 0 *** Warning - bad CRC, using default environment In:serial Out: serial Err: serial Net: mii0 Warning: failed to set MAC address Hit any key to stop autoboot: 0 sun7i# setenv ethaddr 00:11:22:33:44:a3 sun7i# setenv autoload no sun7i# dhcp Waiting for PHY auto negotiation to complete... done ENET Speed is 1000 Mbps - FULL duplex connection BOOTP broadcast 1 BOOTP broadcast 2 DHCP client bound to address 192.168.1.218 sun7i# setenv serverip 192.168.1.1 sun7i# tftp 0x40008000 192.168.1.1:cubie/zImage Using mii0 device TFTP from server 192.168.1.1; our IP address is 192.168.1.218 Filename 'cubie/zImage'. Load address: 0x40008000 Loading: # # 2.7 MiB/s done Bytes transferred = 1779480 (1b2718 hex) sun7i# tftp 0x4200 192.168.1.1:cubie/buildroot.cpio.gz Using mii0 device TFTP from server 192.168.1.1; our IP address is 192.168.1.218 Filename 'cubie/buildroot.cpio.gz'. Load address: 0x4200 Loading: 2.7 MiB/s done Bytes transferred = 642602 (9ce2a hex) sun7i# tftp 0x4100 192.168.1.1:cubie/sun7i-a20-cubietruck.dtb Using mii0 device TFTP from server 192.168.1.1; our IP address is 192.168.1.218 Filename 'cubie/sun7i-a20-cubietruck.dtb'. Load address: 0x4100 Loading: # 2 MiB/s done Bytes transferred = 12304 (3010 hex) sun7i# setenv bootargs console=ttyS0,115200 debug earlyprintk rw root=/dev/ram0 rw sun7i# bootz 0x40008000 0x4200 0x4100 Kernel image @ 0x40008000 [ 0x00 - 0x1b2718 ] ## Loading init Ramdisk from Legacy Image at 4200 ... Image Name: Created: 2014-03-09 14:53:18 UTC Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size:642538 Bytes = 627.5 KiB Load Address: Entry Point: Verifying Checksum ... OK ## Flattened Device Tree blob at 4100 Booting using the fdt blob at 0x4100 Loading Ramdisk to bfdc9000, end bfe65dea ... OK Loading Device Tree to 40ff9000, end 40fff00f ... OK Starting kernel ... Now if I boot with bootz 0x40008000 - 0x4100 everything works fine: U-Boot 2014.01-09730-gb5bd4c9 (Mar 09 2014 - 05:55:17) Allwinner Technology CPU: Allwinner A20 (SUN7I) Board: Cubietruck I2C: ready DRAM: 2 GiB WARNING: Caches not enabled MMC: SUNXI SD/MMC: 0 *** Warning - bad CRC, using default environment In:serial Out: serial Err: serial Net: mii0 Warning: failed to set MAC address Hit any key to stop autoboot: 0 sun7i# setenv ethaddr 00:11:22:33:44:a3 sun7i# setenv autoload no sun7i# dhcp Waiting for PHY auto negotiation to complete.. done ENET Speed is 1000 Mbps - FULL duplex connection BOOTP broadcast 1 BOOTP broadcast 2 DHCP client bound to address 192.168.1.218 sun7i# setenv serverip 192.168.1.1 sun7i# tftp 0x40008000 192.168.1.1:cubie/zImage Using mii0 device TFTP from server 192.168.1.1; our IP address is 192.168.1.218 Filename 'cubie/zImage'. Load address: 0x40008000 Loading: # # 2.7 MiB/s done Bytes transferred = 1779480 (1b2718 hex) sun7i# tftp 0x4200 192.168.1.1:cubie/buildroot.cpio.gz Using mii0 device TFTP from server 192.168.1.1; our IP address is 192.168.1.218 Filename 'cubie/buildroot.cpio.gz'. Load address: 0x4200 Loading: 2.7 MiB/s done Bytes transferred = 642602 (9ce2a hex) sun7i# tftp 0x4100 192.168.1.1:cubie/sun7i-a20-cubietruck.dtb Using mii0 device TFTP from server 192.168.1.1; our IP address is 192.168.1.218 Filename 'cubie/sun7i-a20-cubietruck.dtb'. Load address: 0x4100 Loading: # 2 MiB/s done Bytes transferred = 12304 (3010 hex) sun7i# setenv bootargs console=ttyS0,115200 debug earlyprintk rw root=/dev/ram0 rw sun7i# bootz 0x40008000 - 0x4100 Kernel image @ 0x40008000 [ 0x00 - 0x1b2718 ] ## Flattened Device Tree blob at 4100 Booting using the fdt blob at 0x4100 Loading Device Tree to 40ff9000, end 40fff00f ... OK Starting kernel ... [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.14.0-rc5-00287-gca62eec
Re: [linux-sunxi] [PATCH u-boot] cmd_gpio: fix warning with GPIO_OSCILLATE
Ian,
sorry for not replying earlier, but isn't that a bug-fix against the
generic U-Boot? In that case, it's probably wise to post it on the
u-boot mailing list :)
Other then that, I think i fixed most sunxi specific compile errors and
that one has been annoying me for ages :)
Olliver
On 01/31/14 18:05, Ian Campbell wrote:
In do_gpio value is not initialised in the GPIO_OSCILLATE case:
cmd_gpio.c: In function ‘do_gpio’:
cmd_gpio.c:92:2: warning: ‘value’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
return value;
^
Returning 0 in this case seems fairly logical.
Signed-off-by: Ian Campbell i...@hellion.org.uk
Cc: Henrik Nordstrom hen...@henriknordstrom.net
---
common/cmd_gpio.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/common/cmd_gpio.c b/common/cmd_gpio.c
index d551415..a43e89e 100644
--- a/common/cmd_gpio.c
+++ b/common/cmd_gpio.c
@@ -75,6 +75,7 @@ static int do_gpio(cmd_tbl_t *cmdtp, int flag, int argc, char
* const argv[])
gpio_set_value(gpio, i1);
}
gpio_direction_input(gpio);
+ value = 0;
} else {
switch (sub_cmd) {
case GPIO_SET:value = 1; break;
--
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: Openwrt for the Cubieboard
Hi, On 02/14/14 16:01, Zoltan HERPAI wrote: http://wiki.openwrt.org/toh/cubietech/cubieboard http://wiki.openwrt.org/doc/hardware/soc/soc.allwinner.sunxi#installation.process Just a note, going over this list I noticed that the boot partition was required to be fat on an SD card, that is not true, u-boot happily boots from ext[234]. If the installation medium is on NAND, the allwinner bootloaders boot0/boot1 does scan only for the first fat partition. Olliver Of course, you'll need to use the relevant u-boot image built - you can select it in the menuconfig under Boot loaders. Regards, -w- On Fri, 14 Feb 2014, kelvinh...@gmail.com wrote: Hi, How does install to A10 cubieboard? Thanks, Kelvin On Wednesday, November 6, 2013 5:06:16 PM UTC+8, Benjamin Henrion wrote: Hi, I compiled the trunk version of openwrt for the cubie a10 here: http://filez.zoobab.com/openwrt/sunxi/ Gonna make other builds for A20 and the rest. -- Benjamin Henrion bhenrion at ffii.org FFII Brussels - +32-484-566109 - +32-2-4148403 In July 2005, after several failed attempts to legalise software patents in Europe, the patent establishment changed its strategy. Instead of explicitly seeking to sanction the patentability of software, they are now seeking to create a central European patent court, which would establish and enforce patentability rules in their favor, without any possibility of correction by competing courts or democratically elected legislators. -- 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/groups/opt_out. -- 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 Touch screen driver issue.
Hey Nathan, On 02/17/14 19:39, Nathan Buckley wrote: I rebuild the kernel to include I2C output. This can be seen here. http://pastebin.com/vV1prk5P Unsure what else to do to debug the issue. From the sound of it, the controller isn't fully compatible with the supplied source. Maybe wrong firmware? Is the firmware included in the headerfile? Does it need one at all? Debugging that will be tricky to say the least. Olliver On Thursday, 13 February 2014 19:14:30 UTC, Nathan Buckley wrote: Hi Guys, I'm hoping someone will be able to help me with an issue I've been having. For the last few days I've been trying to get a touchscreen working. The touchscreen is a gslx680. The device is a A13 whitelabel tablet. I have it booting up into Ubuntu - Xfce4, it's using the 3.4 linux sunix kernel. I'm using the driver source from https://gitorious.org/gslx680-for-sunxi https://gitorious.org/gslx680-for-sunxi and dmesg leads me to believe that it was installed (insmod) correctly and detects the chip. Alas nothing happends when I touch the screen. I tried evtest and it detects the gslx680 as input device, but again when I test it doesn't spawn any events. Dmsg, Xorg log file and evtest output can be viewed here http://pastebin.com/5Zi7KqTf Fex file that I'm using as script.bin is here http://pastebin.com/pf8CkG6u Any help, or indication how to better debug the issue would be greatly appreciated. More information, I've run i2cdetect and it detects a device at address 0x40. When I try and set a value manually via i2cset or get it does say that the address is busy. Thanks. -- 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/groups/opt_out. -- 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] A10 PIC flasher with GPIOs
On 02/18/14 11:48, Benjamin Henrion wrote: A10 PIC flasher with GPIOs: http://dangerousprototypes.com/2014/02/18/picberry-r-pi-allwinner-a10-pic-programmer-using-gpio-connector/ Very interesting concept, I did see it on DP a while ago. We should add some info to our wiki. Personally I'd only be interested in programming AVR's using avr dude :D -- 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] Hummingbird A20, anyone got it working?
On 02/21/14 21:55, Luc Verhaegen wrote: On Thu, Feb 20, 2014 at 09:50:59AM -0800, Jeremy Darling wrote: I've been looking at this board with the 7 touch display as something new to play with. But reading the comments on the sellers page it seems many people haven't had any luck with getting the Linux kernel from them and/or getting Linux to actually work on it. After asking on the Arch form I was pointed at the IRC channel. As I'm not much of an IRC person and found this list thought I'd try here first. My questions are: How far has anyone actually got toward this being a useable general hacking (hardware) board under Linux? Is there a basic distro to download to the SD that at least boots and gets you Keyboard, Display, and Network? Is it worth the $$ or is it better to get something else (cubieboard2 with the breakout board seems similar)? If there isn't a distro, how hard is it to get this up and running for someone who has a little experience compling drivers and apps for Linux but not the entire kernal itself? Any and all info greatly appreciated, I don't have a lot of $$ to waste so I'd like to make a good purchase the 1st time :) - Jeremy PS: The two projects I was thinking of for this device (or whatever I get) are a small Node.js Webserver to take to my kids events (they race) to enter the details of their races on and provide a webpage to other members of the details of the races. Nothing fancy; Express.js and LevelUp on the app side and a small wireless hub hooked to allow general access. Battery powered from 12v car plug. Headless operation. The other is in the kitchen as a general internet appliance for the wife. Calendar, Recipes, Internet Browser. Using the 7 display. It's sunxi hw, and it's not documented on our wiki and has no patches submitted to u-boot-sunxi or sunxi-boards. To get this hw supported, you need to work through: http://linux-sunxi.org/New_Device_howto This is a concise guide for bringing up your hardware, and for documenting your hardware in one swoop. It is not rocket-science and some basic linux skills will suffice. All you need to do is meticulously follow the text here. To follow up on Luc's comment here, what he says its to get the basics working. After that, you have your 7 display to get working, which shouldn't be hard and mostly will just work, but if it is a touchscreen, it will need to be a supported one. That said, on the software side, check out our wiki. You can get up and running with either a single image or debootstrap your own without any programming knowledge. Olliver Luc Verhaegen. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] SATA link down after some time.
On 03/01/14 12:35, Puneet B wrote:
Hi i am using humming board..
Have you ever bothered to go through the new device howto?
http://linux-sunxi.org/New_Device_howto
After all this time we spent on doing your work for you, taking the 10
minutes to do the new device howto would have been helpfull to us.
i flashed fedora 19 in my board.
i used kernel from this link
http://docs.cubieboard.org/tutorials/ct1/development/compiling_latest_kernel_for_cubietruck_cubieboard3
http://docs.cubieboard.org/tutorials/ct1/development/compiling_latest_kernel_for_cubietruck_cubieboard3.
Not supported kernel by this list!
For first time:
sata is also power up after some time.
able to mount hard disk in gui.
but after some time , sata links gets down and hard disk partition is
removed from GUI.
speed limited to 1.5 from 3.0 Gbps.
I am power on hard disk from humming bird board not externally.
You most very likely do not supply enough power. Get more power.
Olliver
But later:
The SATA links in not powered On.
Here will be log for sata:
[0.926792] sw_ahci sw_ahci.0: controller can't do PMP, turning off
CAP_PMP
[0.931106] sw_ahci sw_ahci.0: forcing PORTS_IMPL to 0x1
[0.938548] sw_ahci sw_ahci.0: AHCI 0001.0100 32 slots 1 ports 3 Gbps
0x1 impl platform mode
[0.945011] sw_ahci sw_ahci.0: flags: ncq sntf pm led clo only pio
slum part ccc
[0.948321] scsi0 : sw_ahci_platform
[0.955491] ata1: SATA max UDMA/133 mmio [mem 0x01c18000-0x01c18fff]
port 0x100 irq 88
[6.348940] ata1: link is slow to respond, please be patient (ready=0)
[ 10.966801] ata1: COMRESET failed (errno=-16)
[ 11.317839] ata1: SATA link down (SStatus 0 SControl 300)
[ 82.555121] ata1: exception Emask 0x10 SAct 0x0 SErr 0x4050002 action
0xe frozen
[ 82.605854] ata1: irq_stat 0x0040, connection status changed
[ 82.634155] ata1: SError: { RecovComm PHYRdyChg CommWake DevExch }
[ 82.671739] ata1: hard resetting link
[ 83.783246] ata1: SATA link down (SStatus 0 SControl 300)
[ 83.785235] ata1: EH complete
[ 83.783246] ata1: SATA link down (SStatus 0 SControl 300)
[ 84.087543] ata1: exception Emask 0x10 SAct 0x0 SErr 0x4050002 action
0xe frozen
[ 84.100147] ata1: irq_stat 0x0040, connection status changed
[ 84.111488] ata1: SError: { RecovComm PHYRdyChg CommWake DevExch }
[ 84.122753] ata1: hard resetting link
[ 85.313114] ata1: SATA link down (SStatus 0 SControl 300)
[ 85.315574] ata1: EH complete
[ 85.619974] ata1: exception Emask 0x10 SAct 0x0 SErr 0x4050002 action
0xe frozen
[ 85.632861] ata1: irq_stat 0x0040, connection status changed
[ 85.644387] ata1: SError: { RecovComm PHYRdyChg CommWake DevExch }
[ 85.655018] ata1: limiting SATA link speed to 1.5 Gbps
[ 85.657699] ata1: hard resetting link
[ 85.313114] ata1: SATA link down (SStatus 0 SControl 300)
[ 85.655018] ata1: limiting SATA link speed to 1.5 Gbps
[ 92.363710] ata1: link is slow to respond, please be patient (ready=0)
[ 95.661301] ata1: COMRESET failed (errno=-16)
[ 95.668550] ata1: hard resetting link
[ 101.463094] ata1: link is slow to respond, please be patient (ready=0)
[ 106.501534] ata1: SATA link down (SStatus 0 SControl 310)
[ 105.720693] ata1: COMRESET failed (errno=-16)
[ 105.727695] ata1: hard resetting link
[ 106.501534] ata1: SATA link down (SStatus 0 SControl 310)
[ 106.503507] ata1: EH complete
Kindly tell me what will be issue.
i check same hard disk in cubieboard2 there it is working fine.
(but not with my uImage).
Regards
Punith
--
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/groups/opt_out.
--
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] mpeg2 CedarX
On 03/05/14 09:43, xavier.rovira.lanacc...@gmail.com wrote: Is it possible to encode mpeg2 with CedarX? in homepate it is said encode mpeg must be checked. Still a todo item. If you can help, patches welcome! -- 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: Cubietruck lockup with current sunxi 3.4
On 03/09/14 07:10, Kyle Bassett wrote: Try increase .emr1 more than 0x4 . Hi, Do we know what is the difference between '.emr1=0' and other settings such as '.emr1=0x4'? We know extremely little on how the memory controller really works. This setting moving over from a different platform appears safe, but only through testing we can prove that it works; we simply do not know. Olliver Thanks! -- 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] A31 pmic (axp221) support
Hey Hans, I played with the a31 stuff in u-boot a while ago. Lacking hardware, there was little I was able to do, but check out this patch that might (or not at all) work/give an idea for the p2wi and pmic stuff. https://github.com/oliv3r/u-boot-sunxi/commit/52b8454fb8951e95da76b3d9ba82461adab5ee7f https://github.com/oliv3r/u-boot-sunxi/commit/d0c02cdba51a9e8434993b10c91e7bf0378864dd On 03/09/14 08:41, Hans de Goede wrote: Hi Maxime, Yesterday I've been playing a bit with my Mele A1000G Quad, with the purpose of trying to get usb and mmc working there. I already have wens' gmac patches for the A31 in my tree, so for starters I tried to get that to work. Unfortunately the fex shows that the phy is powered by dldo1 from the pmic, and by default that is configured to off. So I got stuck there wrt getting the gmac to work on the A1000G Quad / M9. Do you know if anyone is working on pmic support for the A31, or for the new push-pull serial bus this uses? Is this bus similar enough to i2c that we can use the i2c subsys for this, maybe with an extra controller flag, or do we need to likely write a whole new subsys for this ? Also do you know of a datasheet for the AXP221 somewhere ? Regards, Hans -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH u-boot] cmd_gpio: fix warning with GPIO_OSCILLATE
On 03/11/14 09:38, Ian Campbell wrote: On Sun, 2014-03-09 at 20:10 +0100, Olliver Schinagl wrote: Ian, sorry for not replying earlier, but isn't that a bug-fix against the generic U-Boot? In that case, it's probably wise to post it on the u-boot mailing list :) As Henrik says it's actually sunxi functionality. This particular fix is already in the sunxi tree I think. Yeah I read that mail a little later (my fault for having an e-mail backlog). Sorry for the noise Ian! Ollier Ian. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] How is the kernel mainlining process?
On 03/11/14 11:19, Draplater wrote: Have mmc support been add yet? SDIO Driver (WiP: Hans De Goede, David Lanzendörfer) WiP - Work in Progress. I belive in the devel branches it works. On Monday, March 10, 2014 9:48:28 PM UTC+8, Olliver Schinagl wrote: On 03/06/14 05:59, Draplater wrote: Website linux-sunxi writes: The upstream code does not support NAND, MMC or SATA, you can only boot off a USB harddisk. (from http://linux-sunxi.org/Mainline_Kernel_Howto http://linux-sunxi.org/Mainline_Kernel_Howto) Is there any changes? Is the mainline kernel still that unusable now? That page is likly old and outdated. Sata support has been added, USB support has been added around the same time, so that USB harddisk was possible wasn't even true back then. http://linux-sunxi.org/Mainlining_Effort http://linux-sunxi.org/Mainlining_Effort This is the latest and most up to date (kept) status. -- 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: Default initrd and fdt load behaviour on ARM (Was: Re: [linux-sunxi] Re: Not able to boot ramdisk on cubietruck)
On 03/11/14 11:38, Ian Campbell wrote: Adding u-boot list since I think this is a general issue/question. On Sun, 2014-03-09 at 20:00 +0100, Olliver Schinagl wrote: On 03/09/14 16:18, tyler.ba...@linaro.org wrote: On Sunday, March 9, 2014 8:06:27 AM UTC-7, tyler...@linaro.org wrote: Hello, I am trying to boot the cubietruck with a minimal ramdisk. However, it seems to hang at Starting kernel... whenever I pass bootz a ramdisk load address. [...] Turl help me solve this in IRC. Needed to setenv initrd_high '0x' in case anyone else runs into this. The http://linux-sunxi.org/Mainline_Kernel_Howto did mention this ;) but thanks for helping remind people! Actually it mentions fdt_high but not initrd_high. That is new to me ;) I think it was discussed in depth as to why and what, but I forgot everything about it :p (been 5 or 6 months!) http://irclog.whitequark.org/linux-sunxi/search?q=fdt_high Should give a reasonable overview, only 20 or so entries for 2013 + 2014. Olliver But what is the reason for the default behaviour of bootz doing things which do not conform to linux/Documentation/arm/Booting and therefore is not going to boot? The docs recommend that DTB and initrd go just after the 128MB boundary. If either are loaded too high then the kernel will crash on boot, often in a tricky to diagnose way (I've chased it down more than once). It's especially annoying when one has carefully loaded everything at a suitable address in the first place ;-) Should the global default be changed to either 0x (no relocation) or to start-of-ram+256MB (which should satisfy the kernels requirements without needing logic changes to handle just after the 128MB boundary as a concept). Or is it intended that each board should opt-in to a sensible default via their default environment? Does bootm suffer the same? I suspect it does, at least for fdt (since initrd has a load addr in the u-boot header). Ian. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] About decoding latency on A10 chip
On 03/11/14 15:33, lhavc2...@gmail.com wrote: Hello everyone, I am developing a video streaming application that using A10 board for live scenario, everything runs well but I found that there are 3 frames delay on decoding phase. Seems there's no option for low-latency decoding in linux-armhf build of cedarv library, but the other one, armhf2, requires sunxi-mem interface that isn't implemented on A10's kernel. Is anyone else experiencing problem on this solution? Thanks very much. You speak of the binary blob, to which a prompt reply follows. Not supported here, ask Allwinner for support. That said, you could always try the RE effort, http://linux-sunxi.org/Cederus Olliver -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] eMMC Performance test
On 03/12/14 10:32, stul...@gmail.com wrote: Dear All; Thank you soo much for all your efforts. I have a A20 based board, named INTERRA-3. It incorporates a SANDISK eMMC instead of a NAND Flash. I can run both stock android and sunxi kernel with debian on it. Basically, everything is OK, but I am not happy with the SDIO interface speed. Please see my benchmarking test against SAMSUNG NOTE-2 and SAMSUNG NOTE-3: http://s9.postimg.org/xkp1o22nz/compare.jpg As you see, the READ speed is extremely slow when we compare with Samsung devices. This test is done with the same application from Google Play Store, and it was using AW kernel. However, I get same speeds when I use sunxi kernel ( I tested according to here: https://romanrm.net/dd-benchmark ) Is it a hardware limitation, or is it possible to improve speeds via kernel driver ? FYI, here is my booting log : http://sprunge.us/YWhS Many thanks for the answers. You are getting about 2 to 3 times of nand performance. I'm not sure if the eMMC is capable of doing more, but it could be SDIO performance, though I wouldn't bet on it. Your performance isn't horrible to be honest really. BR. Sertac -- 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] A31 pmic (axp221) support
On 03/11/2014 04:13 PM, Hans de Goede wrote: Hi, On 03/11/2014 01:15 PM, Olliver Schinagl wrote: On 03/10/14 22:31, Hans de Goede wrote: Hi, On 03/10/2014 05:04 PM, Olliver Schinagl wrote: Hey Hans, I played with the a31 stuff in u-boot a while ago. Lacking hardware, there was little I was able to do, but check out this patch that might (or not at all) work/give an idea for the p2wi and pmic stuff. https://github.com/oliv3r/u-boot-sunxi/commit/52b8454fb8951e95da76b3d9ba82461adab5ee7f https://github.com/oliv3r/u-boot-sunxi/commit/d0c02cdba51a9e8434993b10c91e7bf0378864dd Cool, thanks for working on this! So you've a comment in there that the clk setup is not done there, is it already done somewhere else, or is it simply missing at this point ? I have to ask for a refresher of my memory, where exactly did you spot this? In the commit msg of: https://github.com/oliv3r/u-boot-sunxi/commit/52b8454fb8951e95da76b3d9ba82461adab5ee7f D'oh Yes, the clock stuff is handled elsewhere in the source. I didn't wanna do a whole big cleanup session first. Still waiting for my A23 tablet so i can get started hacking on u-boot again. Olliver Regards, Hans -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH-3.4] sunxi-mci: incorrect MMC_DMA_DES_BIT_LEFT
David,
can you confirm/deny this change makes sense? If so, can you give mnemoc
the ok to go ahead with this fix?
Olliver
On 03/10/2014 02:58 AM, Wills Wang wrote:
---
drivers/mmc/host/sunxi-mci.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sunxi-mci.h b/drivers/mmc/host/sunxi-mci.h
index 1447257..b885c32 100644
--- a/drivers/mmc/host/sunxi-mci.h
+++ b/drivers/mmc/host/sunxi-mci.h
@@ -35,7 +35,7 @@
#define MMC_MODCLK_PREFIX sdc
#define MMC3_DMA_TL (0x20070008)
#define MMC_MAX_DMA_DES_BIT 13
-#define MMC_DMA_DES_BIT_LEFT 5
+#define MMC_DMA_DES_BIT_LEFT 6
#endif
/*-- for sun5i --*/
@@ -250,7 +250,7 @@
#define SDXC_IDMA_ERR (SDXC_IDMACFatalBusErr|SDXC_IDMACDesInvalid \
|SDXC_IDMACCardErrSum|SDXC_IDMACAbnormalIntSum)
-#define SDXC_DES_NUM_SHIFT (MMC_MAX_DMA_DES_BIT)
+#define SDXC_DES_NUM_SHIFT (MMC_MAX_DMA_DES_BIT - 1)
#define SDXC_DES_BUFFER_MAX_LEN (1U SDXC_DES_NUM_SHIFT)
struct sunxi_mmc_idma_des {
u32 config;
--
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: Does anyone have interest in porting allwinner cedarx decoder to vlc player？
On 03/13/2014 02:57 AM, iinuyash...@gmail.com wrote: On Friday, October 26, 2012 6:00:35 AM UTC-4, wills wrote: Hi, All, I am porting allwinner cedarx decoder to native vlc player(direct render to linuxfb, not android version), does anyone have interest in it? This porting based on libcedarx(a wrapper library used libvecore, instead of libcedarv, lower level API than libcedarv). Best Regards WIlls I know this is a little old of a thread, but any chance someone could post this as an .APK installer package? There is a fairly new device called the Iben L1 gaming tablet, and it uses an Allwinner a31. We would love to have it, but none of us really know how to do any coding at all so we cannot get anything done. If someone could make it a general .APK for any Allwinner devices though, that would be amazing. Most people on this list use A10/A13/A20 hardware. A31 is not really supported due to the powerVR it has. While this is about cedarX etc, maybe you get lucky and someone hears your call; but don't count on it too strongly :) Olliver -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: How to decide NAND boot address?
On 03/14/2014 04:42 PM, hunter hu wrote: 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. correct, dram is initialized by boot0/boot1 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. nand-part may simply not support the newer version of libnand used on this tablet 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. Closed blobs make you cry. You probably have an incompatible libnand. But fear not, the mtd driver is very slowly progressing. A year from now we might be thinking 'oh, heh, good riddens libnand is gone'. 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. You are the very first one that 'might' (unlikly) have a locked down nand. I sincerly doubt it's locked down at all. Olliver 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 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 mailto:linux-sunxi+unsubscr...@googlegroups.com. For more options, visit
Re: [linux-sunxi] [PATCH+GIT 0/9] sunxi: upstream review based cleanups
On 03/16/2014 06:33 PM, Ian Campbell wrote: Hi, The following series implements some of the cleanups requested as part of the upstream review process (mostly the lower hanging fruit). This is against sunxi.git not the upstream u-boot.git (should I cc upstream here? I decided not but maybe other think I should). There's one extra patch sunxi: remove key driver which wasn't due to upstream comment but just removes something which isn't useful (or even used) to reduce the upstream diff a bit more. Lastly I've merged upstream v2014.04-rc2 onto this series and pushed the entire result to: git://gitorious.org/ijc/u-boot.git sunxi-mainlining-cleanups The majority of the conflicts were due to the upstream build system changes (to use Kbuild) and the use of phylib for designware (Wens, if you could double check what I've done that would be great). Keeping up to date with upstream should make the upstreaming easier to manage. Having been out of the loop a little lately, what exactly do you mean, keeping up to date with upstream? afaik henrik kept our u-boot reasonably upstream compatible, hasn't he? Great that this is progressing too! Olliver I've tested this on sun7i Cubieboard2 with both FEL and SD card boot. Ian. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH+GIT 0/9] sunxi: upstream review based cleanups
Hijacking your post here, have you seen the 2GiB support patch? Any thoughts on how to proceed with that one? Upstream atleast listens to you now ;) Olliver On 03/16/2014 06:33 PM, Ian Campbell wrote: Hi, The following series implements some of the cleanups requested as part of the upstream review process (mostly the lower hanging fruit). This is against sunxi.git not the upstream u-boot.git (should I cc upstream here? I decided not but maybe other think I should). There's one extra patch sunxi: remove key driver which wasn't due to upstream comment but just removes something which isn't useful (or even used) to reduce the upstream diff a bit more. Lastly I've merged upstream v2014.04-rc2 onto this series and pushed the entire result to: git://gitorious.org/ijc/u-boot.git sunxi-mainlining-cleanups The majority of the conflicts were due to the upstream build system changes (to use Kbuild) and the use of phylib for designware (Wens, if you could double check what I've done that would be great). Keeping up to date with upstream should make the upstreaming easier to manage. I've tested this on sun7i Cubieboard2 with both FEL and SD card boot. Ian. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH 2/9] sunxi: define bit shifts for CPU_AHB_APB0_CFG_REG
On 03/16/2014 06:34 PM, Ian Campbell wrote:
Signed-off-by: Ian Campbell i...@hellion.org.uk
---
arch/arm/cpu/armv7/sunxi/clock.c| 31 +++
arch/arm/include/asm/arch-sunxi/clock.h | 8 ++--
2 files changed, 29 insertions(+), 10 deletions(-)
diff --git a/arch/arm/cpu/armv7/sunxi/clock.c b/arch/arm/cpu/armv7/sunxi/clock.c
index f7eb37b..54d801c 100644
--- a/arch/arm/cpu/armv7/sunxi/clock.c
+++ b/arch/arm/cpu/armv7/sunxi/clock.c
@@ -21,12 +21,18 @@ static void clock_init_safe(void)
(struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
/* Set safe defaults until PMU is configured */
- writel(AXI_DIV_1 0 | AHB_DIV_2 4 | APB0_DIV_1 8 |
- CPU_CLK_SRC_OSC24M 16, ccm-cpu_ahb_apb0_cfg);
+ writel(AXI_DIV_1 AXI_DIV_SHIFT |
+ AHB_DIV_2 AHB_DIV_SHIFT |
+ APB0_DIV_1 APB0_DIV_SHIFT |
+ CPU_CLK_SRC_OSC24M CPU_CLK_SRC_SHIFT,
+ ccm-cpu_ahb_apb0_cfg);
Is this a pre-patch and should more be done here? I don't think this is
making anything more clear/removing magic values is it?
I probably would have done something like (ignore any stupid mistakes,
i'm a little rusty atm :p) (p.s. I didn't think define names completly
through either, so forgive me there too :)
#define CPU_AXI_CLK_DIV_RATIO(n) n) - 1) 0x3) 0)
#define CPU_ATB_APB_CLK_DIV_RATIO(n) n) - 1) 0x3) 2)
/* note to self, isn't there some mathematical way to make this better*/
#define CPU_AHB_CLK_DIV_RATIO(n) (((n) 0x3) 4)
#define __CPU_AHB_CLK_DIV_RATIO_1 0x0
#define __CPU_AHB_CLK_DIV_RATIO_2 0x1
#define __CPU_AHB_CLK_DIV_RATIO_4 0x2
#define __CPU_AHB_CLK_DIV_RATIO_8 0x3
#define CPU_AHB_CLK_DIV_RATIO_1 \
CPU_AHB_CLK_DIV_RATIO(__CPU_AHB_CLK_DIV_RATIO_1)
#define CPU_AHB_CLK_DIV_RATIO_2 \
CPU_AHB_CLK_DIV_RATIO(__CPU_AHB_CLK_DIV_RATIO_2)
#define CPU_AHB_CLK_DIV_RATIO_4 \
CPU_AHB_CLK_DIV_RATIO(__CPU_AHB_CLK_DIV_RATIO_4)
#define CPU_AHB_CLK_DIV_RATIO_8 \
CPU_AHB_CLK_DIV_RATIO(__CPU_AHB_CLK_DIV_RATIO_8)
#define CPU_AHB_CLK_SRC(n) ((n)
actually, I stop right here, because below this comment, I see more that
can be fixed :)
I'll pull your tree and send a patch in a little bit! (If you think my
method is compeltly wrong, hit me up fast!)
Olliver
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(AXI_DIV_1 AXI_DIV_SHIFT |
+ AHB_DIV_2 AHB_DIV_SHIFT |
+ APB0_DIV_1 APB0_DIV_SHIFT |
+ CPU_CLK_SRC_PLL1 CPU_CLK_SRC_SHIFT,
+ ccm-cpu_ahb_apb0_cfg);
#ifdef CONFIG_SUN5I
/* Power on reset default for PLL6 is 2400 MHz, which is faster then
* it can reliable do :| Set it to a 600 MHz instead. */
@@ -158,12 +164,18 @@ void clock_set_pll1(int hz)
apb0 = apb0 - 1;
/* Switch to 24MHz clock while changing PLL1 */
- writel(AXI_DIV_1 0 | AHB_DIV_2 4 | APB0_DIV_1 8 |
- CPU_CLK_SRC_OSC24M 16, ccm-cpu_ahb_apb0_cfg);
+ writel(AXI_DIV_1 AXI_DIV_SHIFT |
+ AHB_DIV_2 AHB_DIV_SHIFT |
+ APB0_DIV_1 APB0_DIV_SHIFT |
+ CPU_CLK_SRC_OSC24M CPU_CLK_SRC_SHIFT,
+ ccm-cpu_ahb_apb0_cfg);
sdelay(20);
/* Configure sys clock divisors */
- writel(axi 0 | ahb 4 | apb0 8 | CPU_CLK_SRC_OSC24M 16,
+ writel(axi AXI_DIV_SHIFT |
+ ahb AHB_DIV_SHIFT |
+ apb0 APB0_DIV_SHIFT |
+ CPU_CLK_SRC_OSC24M CPU_CLK_SRC_SHIFT,
ccm-cpu_ahb_apb0_cfg);
/* Configure PLL1 at the desired frequency */
@@ -171,7 +183,10 @@ void clock_set_pll1(int hz)
sdelay(200);
/* Switch CPU to PLL1 */
- writel(axi 0 | ahb 4 | apb0 8 | CPU_CLK_SRC_PLL1 16,
+ writel(axi AXI_DIV_SHIFT |
+ ahb AHB_DIV_SHIFT |
+ apb0 APB0_DIV_SHIFT |
+ CPU_CLK_SRC_PLL1 CPU_CLK_SRC_SHIFT,
ccm-cpu_ahb_apb0_cfg);
sdelay(20);
}
diff --git a/arch/arm/include/asm/arch-sunxi/clock.h
b/arch/arm/include/asm/arch-sunxi/clock.h
index 8ca2066..533f9b5 100644
--- a/arch/arm/include/asm/arch-sunxi/clock.h
+++ b/arch/arm/include/asm/arch-sunxi/clock.h
@@ -98,20 +98,24 @@ struct sunxi_ccm_reg {
#define APB1_FACTOR_N 0
/* clock divide */
-#define CPU_CLK_SRC_OSC24M 1
-#define CPU_CLK_SRC_PLL1 2
+#define AXI_DIV_SHIFT (0)
#define AXI_DIV_1 0
#define AXI_DIV_2 1
#define AXI_DIV_3 2
#define AXI_DIV_4 3
+#define AHB_DIV_SHIFT (4)
#define AHB_DIV_1 0
#define AHB_DIV_2 1
#define AHB_DIV_4 2
#define AHB_DIV_8 3
+#define APB0_DIV_SHIFT (8)
#define APB0_DIV_1
Re: [linux-sunxi] did any one know interrupt controller of allwinner 10(on naked problem)
On 03/17/2014 02:04 PM, mosmith1...@gmail.com wrote:
recently i learn to use the interrupt controller of allwinner a10.but i just
couldn't relocate the vector table to 0x.i am sure that the i did the
relocation correctly,because there is no problem when i relocate the vector to
0x4000(use p15,c12).I have been searching for a few days about this problem but
couldn't find what the problem is.here is part of my code,could you give me a
help,thanks(which is very rough):
Hi,
wow, you are doing asm yourself using an A10? pretty interesting and
also i'm sure you are pretty much the only one ;)
The A10 has its own IRQ controller, chances are it was actually
developped by AW inhouse. But nothing is certain here of course ...
I assume there is a reason you can't use regular linux?
Olliver
.global _start
.global copy_myself1
.extern main
.extern led_gpio_setup
.extern led2_light
.extern timer0_irq_c
.extern led1_off
.extern test
.extern main2
.extern uart0_puts
.extern load
_start:
b reset
ldr pc, _undefined_instruction
ldr pc, _software_interrupt
ldr pc, _prefetch_abort
ldr pc, _data_abort
ldr pc, _not_used
ldr pc, _irq
ldr pc, _fiq
_undefined_instruction: .word undefined_instruction
_software_interrupt:.word software_interrupt
_prefetch_abort:.word prefetch_abort
_data_abort:.word data_abort
_not_used: .word not_used
_irq: .word irq
_fiq: .word fiq
_pad: .word 0x12345678
.align 4
undefined_instruction:
ldr sp,=(0x8000);
adr r0,undefined_instruction_isr_string
bl uart0_puts
b .
software_interrupt:
ldr sp,=(0x8000-0x200);
adr r0,software_interrupt_isr_string
bl uart0_puts
b .
prefetch_abort:
ldr sp,=(0x8000-0x200);
adr r0,prefetch_abort_isr_string
bl uart0_puts
b .
data_abort:
ldr sp,=(0x8000-0x200);
adr r0,data_abort_isr_string
bl uart0_puts
b .
not_used:
fiq:
ldr sp,=(0x8000-0x200);
adr r0,fiq_isr_sring
bl uart0_puts
b .
.align 4
fiq_isr_sring:
.ascii fiq isr\n
.align 4
data_abort_isr_string:
.ascii data_abort isr string\n
.align 4
prefetch_abort_isr_string:
.ascii prefetch_abort\n
.align 4
software_interrupt_isr_string:
.ascii software_interrupt\n
.align 4
undefined_instruction_isr_string:
.ascii undefined_instruction\n
.align 4
irq_isr_string:
.ascii irq request\n
.align 4
irq:
ldr sp,=0x8000;
stmfd sp!,{r0-r12,lr}
adr r0,irq_isr_string
bl uart0_puts
bl timer0_irq_c;
ldmfd sp!,{r0-r12,lr}
subs pc,lr,#4;/*return from exception*/
reset:
mrs r0,cpsr;
orr r0,r0,#(0x36);/*disable the fiq and irq*/
bic r0,r0,#0x1f
orr r0,r0,#0x13;/*turn to svc mode*/
bl cpu_init_cp15;/*mmu setup(diable mmu and related cache)*/
bl setup_sp;/*setup stack pointer(SP)*/
bl irq_stack_setup;
bl led_gpio_setup;
mrs r0,cpsr /*open the irq and fiq*/
bic r0,r0,#(0x36);
msr cpsr,r0
adr r0,_start
mrc p15,0,r1,c1,c0,0
mrc p15,0,r2,c12,c0,0
mrc p15,0,r3,c12,c0,1
b main;
irq_stack_setup:
mov r1,sp;
mrs r2,cpsr;/*save the cpsr*/
mrs r0,cpsr
bic r0,r0,#0x1f
orr r0,r0,#0x12;/*turn to the irq mode*/
msr cpsr,r0;/*then we are in the irq mode*/
mov sp,r1;
msr cpsr,r2;/* restore the cpsr*/
sub r1,r1,#0x400 ;/*0x100:reserve irq stack size*/
mov sp,r1;
mov pc,lr;
cpu_init_cp15:
/*
* Invalidate L1 I/D
*/
mov r0, #0 @ set up for MCR
mcr p15, 0, r0, c8, c7, 0 @ invalidate TLBs
mcr p15, 0, r0, c7, c5, 0 @ invalidate icache
mcr p15, 0, r0, c7, c5, 6 @ invalidate BP array
mcr p15, 0, r0, c7, c10, 4 @ DSB
mcr p15, 0, r0, c7, c5, 4 @ ISB
/*
* disable MMU stuff and caches
*/
mrc p15, 0, r0, c1, c0, 0
bic r0, r0, #0x2000 @ clear bits 13 (--V-)
bic r0, r0, #0x0007 @ clear bits 2:0 (-CAM)
orr r0, r0, #0x0002 @ set bit 1 (--A-) Align
orr r0, r0, #0x0800 @ set bit 11 (Z---) BTB
#ifdef CONFIG_SYS_ICACHE_OFF
bic r0, r0, #0x1000 @ clear bit 12 (I) I-cache
#else
orr r0, r0, #0x1000 @ set bit 12 (I) I-cache
#endif
mcr p15, 0, r0, c1, c0, 0
mov pc, lr @ back to my caller
.equ CONFIG_SYS_INIT_SP_ADDR,0x8000
setup_sp:
ldr r0,=CONFIG_SYS_INIT_SP_ADDR;
mov sp,r0;
Re: [linux-sunxi] Re: [PATCH u-boot sunxi 3/4] sunxi: Implement reset_cpu
On 03/16/2014 07:38 PM, Ian Campbell wrote:
On Sun, 2014-03-16 at 14:53 +0100, Hans de Goede wrote:
There is no way to reset the cpu, so use the watchdog for this.
The sunxi.git tree does this by calling watchdog_set(0). I think it
would be better to introduce the generic watchdog support and the add
this a patch to use it for reset. Unless we don't plan to upstream the
watchdog stuff for some reason?
Not sure why cmd_watchdog.c is sunxi, seems like in principal it could
be generic.
If this is what I remember it to be, it was only hacked on and wasn't
even used anymore. I think there where some issues with the wdt initially.
As always, Henrik knows best ;)
Olliver
Ian.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
arch/arm/cpu/armv7/sunxi/board.c| 7 +++
arch/arm/include/asm/arch-sunxi/timer.h | 4
2 files changed, 11 insertions(+)
diff --git a/arch/arm/cpu/armv7/sunxi/board.c b/arch/arm/cpu/armv7/sunxi/board.c
index 98cad43..2668d52 100644
--- a/arch/arm/cpu/armv7/sunxi/board.c
+++ b/arch/arm/cpu/armv7/sunxi/board.c
@@ -70,6 +70,13 @@ int gpio_init(void)
void reset_cpu(ulong addr)
{
+ static const struct sunxi_wdog *wdog =
+((struct sunxi_timer_reg *)SUNXI_TIMER_BASE)-wdog;
+
+ /* Set the watchdog for its shortest interval (.5s) and wait */
+ writel(WDT_MODE_RESET_EN | WDT_MODE_EN, wdog-mode);
+ writel(WDT_CTRL_RESTART, wdog-ctl);
+ while (1);
}
/* do some early init */
diff --git a/arch/arm/include/asm/arch-sunxi/timer.h
b/arch/arm/include/asm/arch-sunxi/timer.h
index f9d4f4f..1489b2e 100644
--- a/arch/arm/include/asm/arch-sunxi/timer.h
+++ b/arch/arm/include/asm/arch-sunxi/timer.h
@@ -27,6 +27,10 @@
#ifndef _SUNXI_TIMER_H_
#define _SUNXI_TIMER_H_
+#define WDT_CTRL_RESTART(0x1 0)
+#define WDT_MODE_EN (0x1 0)
+#define WDT_MODE_RESET_EN (0x1 1)
+
#ifndef __ASSEMBLY__
#include linux/types.h
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: uboot for Mele M3 A20
On 03/18/2014 03:41 AM, rova wrote: Is there any way to turn off the red LED after booting up ? You need to be way more specific here. My red led might be completly different then your red led. If it is the 'power' led, its very easy to dim it. Disconnect the power ;) That's the only way afaik atm. Olliver On Thursday, January 16, 2014 3:50:39 AM UTC+8, Rajesh Mallah wrote: Hi i would like to install uboot on the internal MMC card of mele m3 (A20 , 1024MB) model. could anyone suggest which uboot source and what board config should work. thanks (but sorry if the question was too novice). regds mallah. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com mailto:linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: Build sunxi-next for A20
On 03/21/2014 12:03 PM, hmandevt...@gmail.com wrote: i trying to update multi_v7_defconfig generated .config from sunxi-next with /proc/config of working debian image with kernel 3.4 but there are many sections and i haven't a good knowledge to know what update. Could you say me a minimum CONFIG_ item that i should import from working config file ? Er, .config from sunxi-next and 3.4 kernel are completly incompatible. Both 3.4 and sunxi-next have their own defconfigs, they might not be perfect, but should be workable. Olliver -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] When does the I2C probe function get called
On 03/21/2014 04:10 PM, Dave McLaughlin wrote: I am trying to port a touchscreen driver to my system and I have the module building and installing. I have added it to the auto detect code in device.c and I can see in dmesg that the driver from i2c-core gets detected and the init function is called. What never gets called is the probe function which would setup the touch IC and the interrupt handler. When would this be called or how do I ensure this is called for my module? This is the driver I am trying to use. It's under documents and downloads. The manual explains how to integrate it except that the information on page 7, 2.2 BSP Integration, section 2.2.2 does not match up with anything I can find in the sun7i build. http://www.touchrev.com/docs/fusion7/ Where in the sunxi build do I include this information or is this what's in the sys_config.fex? [ctp_para] ctp_used = 1 ctp_name = fusion_F0710A ctp_twi_id = 2 ctp_twi_addr = 0x10 ctp_screen_max_x = 800 ctp_screen_max_y = 480 ctp_revert_x_flag = 0 ctp_revert_y_flag = 0 ctp_exchange_x_y_flag = 0 ctp_int_port = port:PC1961defaultdefault ctp_wakeup = port:PB131defaultdefaultdefault Touch screens are very fidgity to get working right, often due to some firmware that needs to be loaded, or is different between various implentations of the touchscreen IC. I personally haven't seen the fusion series pass by the mailing list ... Olliver -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com mailto: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] uboot for Mele M3 A20
On 03/23/2014 11:51 AM, Rajesh Mallah wrote: Oops I am so sorry saw this message today!. Yes i can contribute the pictures. But the bad news is that the RJ45 on the mele was flaky and i do not know if it was problem with that peice or in general. Hence i am considering some other box now. That's okay, no problem, the pics will still be very helpfull. Mostly pics of the PCB. If you could do this in combination with: http://linux-sunxi.org/New_Device_howto that would be extremly appreciated, even if you do not intend to use the board any longer. Olliver regds mallah. On Sun, Mar 9, 2014 at 5:26 PM, Olliver Schinagl oliver+l...@schinagl.nl mailto:oliver+l...@schinagl.nl wrote: Hey Rajesh, Did you ever manage to get some pictures taken of the inside? Olliver On 01/19/14 20:26, Rajesh Mallah wrote: If you would have picked up on my earlier interra3 hint, you would have seen that that is actually configured in boards.cfg. No need to hack boards.c. Bad mallah! Dear Oliver / List , firstly thanks for gesture to help . I was sort of despo. sunxi has always been a jinxed platform for me! . Specially considering that fact that most of us are used to the comforts of x86. I will definitely learn about boards.cfg and see how to add definations. You already pointed me to the correct wikis. I will have to do a careful reading of those. btw i overclocked the dram to 456 Mhz and it could run without problems. I then reduced it to 408 Mhz , seeing that gtkperf does not yeild any benefits. regds mallah. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@__googlegroups.com mailto:linux-sunxi%2bunsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/__optout 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 mailto: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] uboot for Mele M3 A20
On 03/23/2014 06:27 PM, Rajesh Mallah wrote: Hi, I regularly search Alibaba market place for devices (TV boxes) can be reused as low powered general purpose computers. Many of such devices have debug ports ( some do not have also ). Most allwinner based devices on marketplace are A20 based, 1 GB model A10 and A31 are not seen in general. In Quad core segment generally device makers are going for RK3188. In in dual core segment AMLogic MX is also seen along with RK3066. My question is that is it really worth documenting such allwinner devices in linux-sunxi website ? Yes, yes yes! The more devices are documented, the better it is for all of us :) In this specific case, the Mele was our main target for a long time. Many developers still have Mele's. The A20 based mele for some reason has been skipped and has very little information however. Which is why we are very interested in the guts and glory :) Olliver There is no surety if such devices will even be seen after even 1 year down the line. Regds mallah. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com mailto:linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: Build sunxi-next for A20
On 03/24/2014 01:55 PM, i...@integrazioneweb.com wrote: Hi Olliver, i tryed some defconfig but i haven't uart cable so i don't know where is boot problem. Then it will be next to impossible to debug. Olliver -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [U-Boot] [PATCH v2 1/9] sunxi: initial sun7i clocks and timer support.
On 03/24/2014 09:52 PM, Marek Vasut wrote:
On Friday, March 21, 2014 at 10:54:18 PM, Ian Campbell wrote:
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.
[...]
+int clock_init(void)
+{
+ struct sunxi_ccm_reg *const ccm =
+ (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
+
+#ifdef CONFIG_SPL_BUILD
+ clock_init_safe();
+#endif
+
+ /* uart clock source is apb1 */
+ sr32(ccm-apb1_clk_div_cfg, 24, 2, APB1_CLK_SRC_OSC24M);
+ sr32(ccm-apb1_clk_div_cfg, 16, 2, APB1_FACTOR_N);
+ sr32(ccm-apb1_clk_div_cfg, 0, 5, APB1_FACTOR_M);
sr32() is not defined anywhere.
it should be defined in
arch/arm/include/asm/arch-sunxi/sys_proto.h
and comes from
arch/arm/cpu/armv7/syslib.c
it was added for the ti omap's
I've got a local cleanup patch set where I fixed this already to
clrsetbits_le32
+ /* open the clock for uart */
+ sr32(ccm-apb1_gate, 16 + CONFIG_CONS_INDEX - 1, 1, CLK_GATE_OPEN);
+
+ return 0;
+}
+
+/* Return PLL5 frequency in Hz
+ * Note: Assumes PLL5 reference is 24MHz clock
+ */
+unsigned int clock_get_pll5(void)
+{
+ struct sunxi_ccm_reg *const ccm =
+ (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
+ uint32_t rval = readl(ccm-pll5_cfg);
+ int n = (rval 8) 0x1f;
+ int k = ((rval 4) 3) + 1;
+ int p = 1 ((rval 16) 3);
+ return 2400 * n * k / p;
Please fix the magic values here.
[...]
Same here, got that in my local tree too
+#ifdef CONFIG_SPL_BUILD
+#define PLL1_CFG(N, K, M, P) (1 31 | 0 30 | 8 26 | 0 25 |
\
+16 20 | (P) 16 | 2 13 | (N) 8 | \
+(K) 4 | 0 3 | 0 2 | (M) 0)
Here is well.
dito :)
+#define RDIV(a, b) ((a + (b) - 1) / (b))
This is some kind of DIV_ROUND_UP() from include/common.h ?
[...]
That one i didn't have;
Ian, I guess you can verify that generic macro works for here?
+ /* Map divisors to register values */
+ axi = axi - 1;
+ if (ahb 4)
+ ahb = 3;
+ else if (ahb 2)
+ ahb = 2;
+ else if (ahb 1)
+ ahb = 1;
+ else
+ ahb = 0;
+
+ apb0 = apb0 - 1;
+
+ /* Switch to 24MHz clock while changing PLL1 */
+ writel(AXI_DIV_1 AXI_DIV_SHIFT |
+ AHB_DIV_2 AHB_DIV_SHIFT |
+ APB0_DIV_1 APB0_DIV_SHIFT |
+ CPU_CLK_SRC_OSC24M CPU_CLK_SRC_SHIFT,
+ ccm-cpu_ahb_apb0_cfg);
+ sdelay(20);
What is sdelay() function all about ?
It also is from
arch/arm/include/asm/arch-sunxi/sys_proto.h
and I thought all where replaced with udelays
With the sr32 and sdelays gone everywhere, sunxi/sys_proto.h can even go!
[...]
+static struct sunxi_timer *timer_base =
+ ((struct sunxi_timer_reg *)SUNXI_TIMER_BASE)-timer[TIMER_NUM];
+
+/* macro to read the 32 bit timer: since it decrements, we invert read
value */ +#define READ_TIMER() (~readl(timer_base-val))
This macro has to go, just use ~readl() in place. But still, why do you use that
negation in ~readl() anyway ?
[...]
Olliver
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH u-boot (sc)] Cleanups of various clock macro's
And i'll start by commenting on my own patch On 03/25/2014 11:00 AM, oliver+l...@schinagl.nl wrote: From: Olliver Schinagl oli...@schinagl.nl This patch cleans up several macro's to remove magic values etc from clock.c and clock.h. Casualties being dragged in are some macro's from dram.c and the i2c driver. Signed-off-by: Olliver Schinagl oli...@schinagl.nl --- arch/arm/cpu/armv7/sunxi/clock.c| 162 -- arch/arm/cpu/armv7/sunxi/dram.c | 22 +- arch/arm/include/asm/arch-sunxi/clock.h | 370 ++-- drivers/i2c/sunxi_i2c.c | 2 +- 4 files changed, 373 insertions(+), 183 deletions(-) diff --git a/arch/arm/cpu/armv7/sunxi/clock.c b/arch/arm/cpu/armv7/sunxi/clock.c index 980fb90..3472fc9 100644 --- a/arch/arm/cpu/armv7/sunxi/clock.c +++ b/arch/arm/cpu/armv7/sunxi/clock.c @@ -21,27 +21,38 @@ static void clock_init_safe(void) (struct sunxi_ccm_reg *)SUNXI_CCM_BASE; /* Set safe defaults until PMU is configured */ - writel(AXI_DIV_1 AXI_DIV_SHIFT | - AHB_DIV_2 AHB_DIV_SHIFT | - APB0_DIV_1 APB0_DIV_SHIFT | - CPU_CLK_SRC_OSC24M CPU_CLK_SRC_SHIFT, + writel(CPU_AXI_CLK_DIV_RATIO(1) | + CPU_AHB_CLK_DIV_RATIO_2 | + CPU_APB0_CLK_DIV_RATIO_1 | + CPU_CLK_SRC_OSC24M, ccm-cpu_ahb_apb0_cfg); - writel(PLL1_CFG_DEFAULT, ccm-pll1_cfg); + writel(CCM_PLL1_CFG_N(16) | + CCM_PLL1_CFG_LCK_TMR_CTRL(2) | + CCM_PLL1_CFG_BIAS_CUR(16) | + CCM_PLL1_CFG_VCO_BIAS(8) | + CCM_PLL1_CFG_EN, + ccm-pll1_cfg); sdelay(200); - writel(AXI_DIV_1 AXI_DIV_SHIFT | - AHB_DIV_2 AHB_DIV_SHIFT | - APB0_DIV_1 APB0_DIV_SHIFT | - CPU_CLK_SRC_PLL1 CPU_CLK_SRC_SHIFT, + writel(CPU_AXI_CLK_DIV_RATIO(1) | + CPU_AHB_CLK_DIV_RATIO_2 | + CPU_APB0_CLK_DIV_RATIO_1 | + CPU_CLK_SRC_PLL1, ccm-cpu_ahb_apb0_cfg); #ifdef CONFIG_SUN5I /* Power on reset default for PLL6 is 2400 MHz, which is faster then * it can reliable do :| Set it to a 600 MHz instead. */ - writel(PLL6_CFG_DEFAULT, ccm-pll6_cfg); + writel(CCM_PLL6_CFG_M(1) | + CCM_PLL6_CFG_K(1) | + CCM_PLL6_CFG_N(25) | + CCM_PLL6_CFG_BW_WIDE | + CCM_PLL6_BIAS_CUR(16) | + CCM_PLL6_VCO_BIAS(16), + ccm-pll6_cfg); #endif #ifdef CONFIG_SUN7I writel(0x1 AHB_GATE_OFFSET_DMA | readl(ccm-ahb_gate0), ccm-ahb_gate0); - writel(0x1 PLL6_ENABLE_OFFSET | readl(ccm-pll6_cfg), + writel(CCM_PLL6_CFG_EN | readl(ccm-pll6_cfg), ccm-pll6_cfg); #endif } @@ -57,21 +68,33 @@ int clock_init(void) #endif /* uart clock source is apb1 */ - sr32(ccm-apb1_clk_div_cfg, 24, 2, APB1_CLK_SRC_OSC24M); - sr32(ccm-apb1_clk_div_cfg, 16, 2, APB1_FACTOR_N); - sr32(ccm-apb1_clk_div_cfg, 0, 5, APB1_FACTOR_M); + clrsetbits_le32(ccm-apb1_clk_div_cfg, + CCM_APB1_CLK_SRC_OSC24M, CCM_APB1_CLK_SRC_OSC24M); + clrsetbits_le32(ccm-apb1_clk_div_cfg, + CCM_APB1_CLK_N_1, CCM_APB1_CLK_N_1); + clrsetbits_le32(ccm-apb1_clk_div_cfg, + CCM_APB1_CLK_M(1), CCM_APB1_CLK_M(1)); I'm not convinced we always have to clear the bit, before setting it. Using setbits is probably enough, but if this gets merged somehow (even if only in our own tree for now), i'd rather see it initially merged as such, to confirm everything is still working properly, and then with tests slowly change it. I mean, there must be a reason they used sr32 before, right? Olliver /* open the clock for uart */ - sr32(ccm-apb1_gate, 16 + CONFIG_CONS_INDEX - 1, 1, CLK_GATE_OPEN); + clrsetbits_le32(ccm-apb1_clk_div_cfg, + CCM_APB_GATE_UART( + SUNXI_CONS_TO_UART(CONFIG_CONS_INDEX)), + CCM_APB_GATE_UART( + SUNXI_CONS_TO_UART(CONFIG_CONS_INDEX))); #ifdef CONFIG_NAND_SUNXI /* nand clock source is osc24m */ - sr32(ccm-nand_sclk_cfg, 24, 2, NAND_CLK_SRC_OSC24); - sr32(ccm-nand_sclk_cfg, 16, 2, NAND_CLK_DIV_N); - sr32(ccm-nand_sclk_cfg, 0, 4, NAND_CLK_DIV_M); - sr32(ccm-nand_sclk_cfg, 31, 1, CLK_GATE_OPEN); + clrsetbits_le32(ccm-nand_sclk_cfg, + CCM_NAND_SCLK_SRC_OSC24M, CCM_NAND_SCLK_SRC_OSC24M); + clrsetbits_le32(ccm-nand_sclk_cfg, + CCM_NAND_SCLK_N_1, CCM_NAND_SCLK_N_1); + clrsetbits_le32(ccm-nand_sclk_cfg, + CCM_NAND_SCLK_M(1), CCM_NAND_SCLK_M(1)); + clrsetbits_le32(ccm-nand_sclk_cfg, + CCM_NAND_SCLK_GATE_EN, CCM_NAND_SCLK_GATE_EN); /* open clock for nand */ - sr32(ccm-ahb_gate0
Re: [linux-sunxi] A10/A13/A20 interface asyncroneous memory
On 03/25/2014 07:18 PM, Dimitar Penev wrote: Thanks Runzhong for the suggestions. We need 16bit wide SRAM interface so NAND flash port doesn't suit us. We plan to build SRAM on top of GPIO system. The interface is going to be used sporadically for a fraction of second, so I guess we will be able to take the CPU fully (no DMA) while it is active. Anyone implemented similar thing with AW? I haven't heard of something as such done yet. While it should be possible to talk to an sram via gpio; don't exect it to be super fast, from what I heard, is that the GPIO's are pretty slow. Check the ML archives for more info. Olliver Thanks Dimitar 11 март 2014, вторник, 03:05:45 UTC+2, Runzhong Yi написа: It depends on your needs. If simply want to expand some DI/DO, ADC/DAC or some other peripheral, USB maybe a good, cheap and expandible option. I don't see too much needs in SRAM interface. If you desperately need a parellel interface, you can use nand flash controller with a small CPLD. 2014-03-05 17:51 GMT+08:00 Dimitar Penev dpe...@gmail.com javascript:: Thanks Runzhong, It is as a big limitation of the AW SoC, isn't it? Dimitar 04 март 2014, вторник, 12:00:58 UTC+2, Runzhong Yi написа: For A10 or A13, the answer is absolutely NO! I didn't checked the datasheet for A20, but I think it's the same. 2014-03-03 21:24 GMT+08:00 dpe...@gmail.com: Hi All, I am wondering if Allwinner A10/A13/A20 SoC can support external asynchronous memory. (8/16 bit Data bus, Address bus, \RD, \WR, \CS) I don't see information about this in the A20 datasheet. Is there some software component in sunxi Linux about this? Pointers are very welcome. Thanks Dimitar -- 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 https://groups.google.com/groups/opt_out. -- 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/groups/opt_out https://groups.google.com/groups/opt_out. -- 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 mailto: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] performance difference between two A20 boards how to debug?
On 03/25/2014 07:27 PM, Rajesh Mallah wrote: Hi , i am using tinymembench to bench mark 2 A20 based 1GB boards MELE finished in 6mins and the noname one finishes in 12mins. pls tell how to systematically debug the issue. at least dram settings are same. where else should i see? The mbus can be different, this is a compiletime option for u-boot. Then again, mbus changing might not work on a10 iirc. But try using the same bootloader for a fair comparison ... Olliver MELE: root@ltspmele:~# ./a10-meminfo-static dram_clk = 408 dram_type = 3 dram_rank_num = 1 dram_chip_density = 4096 dram_io_width = 16 dram_bus_width= 32 dram_cas = 9 dram_zq = 0x7f dram_odt_en = 0 dram_tpr0 = 0x42d899b7 dram_tpr1 = 0xa090 dram_tpr2 = 0x22a00 dram_tpr3 = 0x0 dram_emr1 = 0x4 dram_emr2 = 0x10 NONAME: root@ltspenjoy:~# ./a10-meminfo-static dram_clk = 408 dram_type = 3 dram_rank_num = 1 dram_chip_density = 4096 dram_io_width = 16 dram_bus_width= 32 dram_cas = 9 dram_zq = 0x79 dram_odt_en = 0 dram_tpr0 = 0x42d899b7 dram_tpr1 = 0xa090 dram_tpr2 = 0x22a00 dram_tpr3 = 0x0 dram_emr1 = 0x4 dram_emr2 = 0x10 dram_emr3 = 0x0 -- 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 mailto: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] New u-boot has been merged and pushed
Hey all, Just letting you know, that a new upstream u-boot version has been merged and pushed. If you are in dire need of some new u-boot version, git pull, compile and flash! Though I don't recall there being a new feature ;) It has been tested on the: Olimexino-Lime Cubieboard1 Cubieboard2 Cubieboard3 If anybody has any other boards they can test and report if there are problems that'd be great, but I don't expect it to be so. Happy testing! Olliver -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] New u-boot has been merged and pushed
On 03/26/2014 04:47 PM, Hans de Goede wrote: Hi, On 03/26/2014 04:37 PM, Olliver Schinagl wrote: P.S. one small issue is that the _config name has to match whatever is in boards.cfg (obvious) including capitalization. I think we had a patch that fixed this a while ago, so I will track this down and see if i can find it again. This special sauce to make things case-insensitive is just needless deviation from upstream. I think it would be better if we all just get used to this, and fixup sunxi build-scripts for this as needed. Or, convince upstream that it's not a bad idea to be case-insensitive and have them accept it upstream ;) I'm a lower case guy myself, i noticed that the boards.cfg only has the starting letter uppercase (which looks camelcase-ish to me imo)? So while fixing the sunxi side surely is not a bad idea, and deviating is a bad idea, it's annoying that it doesn't 'just work' to say the least ;) Olliver Regards, Hans -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH 3.4] sun7i: enable performance counters
On 03/27/2014 01:00 PM, Mans Rullgard wrote:
The PMUs on sun7i use the undocumented IRQs 152 and 153 for core 0 and 1
respectively.
Are these the performance counters people where complaining about them
missing a few days ago?
How did you obtain this information? Does the one IRQ apply to sun4i and
sun5i as well?
Thanks for figuring it all out however!!
Olliver
Signed-off-by: Mans Rullgard m...@mansr.com
---
arch/arm/plat-sunxi/devices.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/arch/arm/plat-sunxi/devices.c b/arch/arm/plat-sunxi/devices.c
index fdddc56..70fec7f 100644
--- a/arch/arm/plat-sunxi/devices.c
+++ b/arch/arm/plat-sunxi/devices.c
@@ -30,6 +30,7 @@
#include linux/pda_power.h
#include linux/io.h
#include linux/i2c.h
+#include linux/ioport.h
#include asm/mach-types.h
#include asm/mach/arch.h
@@ -113,13 +114,13 @@ struct platform_device sw_pdev_nand =
.dev = {}
};
-#ifndef CONFIG_ARCH_SUN7I
static struct resource sunxi_pmu_resources[] = {
- {
- .start = SW_INT_IRQNO_PLE_PFM,
- .end= SW_INT_IRQNO_PLE_PFM,
- .flags = IORESOURCE_IRQ,
- },
+#ifdef CONFIG_ARCH_SUN7I
+ DEFINE_RES_IRQ(152),
+ DEFINE_RES_IRQ(153),
+#else
+ DEFINE_RES_IRQ(SW_INT_IRQNO_PLE_PFM),
+#endif
};
struct platform_device sunxi_pmu_device = {
@@ -128,7 +129,6 @@ struct platform_device sunxi_pmu_device = {
.resource = sunxi_pmu_resources,
.num_resources = ARRAY_SIZE(sunxi_pmu_resources),
};
-#endif
#if defined(CONFIG_MALI_DRM) || defined(CONFIG_MALI_DRM_MODULE)
static struct platform_device sunxi_device_mali_drm = {
@@ -143,9 +143,7 @@ static struct platform_device *sw_pdevs[] __initdata = {
#endif
sw_pdev_dmac,
sw_pdev_nand,
-#ifndef CONFIG_ARCH_SUN7I
sunxi_pmu_device,
-#endif
#if defined(CONFIG_MALI_DRM) || defined(CONFIG_MALI_DRM_MODULE)
sunxi_device_mali_drm,
#endif
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH u-boot (sc)] Cleanups of various clock macro's
On 03/27/2014 10:06 PM, Ian Campbell wrote: On Tue, 2014-03-25 at 11:00 +0100, oliver+l...@schinagl.nl wrote: From: Olliver Schinagl oli...@schinagl.nl This patch cleans up several macro's to remove magic values etc from clock.c and clock.h. Casualties being dragged in are some macro's from dram.c and the i2c driver. This addresses (some of) Marek's review on the upstreaming series, is that right? Yes, but this is just some of the stuff i had done for some early sunxi review. I since have cleaned it up better, changed it a little; and with you workflow explanation, have to redo it. On top of that, i have to split it out in seperate patches *yay* I will work on that the next few days; but you now know what i'm doing, and I know how to test it :) so just diff the output of objdump -d is what you do? I should be able to do that. You mentioned in the cover letter that you had only compile tested, for this sort of cleanup the approach I would take is to make sure that objdump -d before and after is identical, this way you can be absolutely sure you didn't accidentally break something. Any changes which intentionally change something should be split out. Unfortunately the sr32 changes fall into the latter bucket, oh well. I comments on the sr32 transforms already. Some others: /* open the clock for uart */ - sr32(ccm-apb1_gate, 16 + CONFIG_CONS_INDEX - 1, 1, CLK_GATE_OPEN); + clrsetbits_le32(ccm-apb1_clk_div_cfg, + CCM_APB_GATE_UART( + SUNXI_CONS_TO_UART(CONFIG_CONS_INDEX)), Consider a helper which combines CCM_APB_GATE_UART and SUNXI_CONS_TO_UART? @@ -85,9 +108,10 @@ unsigned int clock_get_pll5(void) struct sunxi_ccm_reg *const ccm = (struct sunxi_ccm_reg *)SUNXI_CCM_BASE; uint32_t rval = readl(ccm-pll5_cfg); - int n = (rval 8) 0x1f; - int k = ((rval 4) 3) + 1; - int p = 1 ((rval 16) 3); + int n = CCM_PLL5_CFG_N_GET(rval); + int k = CCM_PLL5_CFG_K_GET(rval); + int p = CCM_PLL5_CFG_OUT_EXT_DIV_P_GET(rval); + return 2400 * n * k / p; Is 24MHz #defined somewhere? } @@ -96,40 +120,52 @@ int clock_twi_onoff(int port, int state) struct sunxi_ccm_reg *const ccm = (struct sunxi_ccm_reg *)SUNXI_CCM_BASE; - if (port 2) + if (!(port (CCM_APB_GATE_TWI1 | CCM_APB_GATE_TWI2 | + CCM_APB_GATE_TWI3 | CCM_APB_GATE_TWI4))) Maybe #define a TWI_MASK? return -1; /* set the apb1 clock gate for twi */ - sr32(ccm-apb1_gate, 0 + port, 1, state); + if (state) + clrsetbits_le32(ccm-apb1_gate, CCM_APB_GATE_TWI(port), + CCM_APB_GATE_TWI(port)); Shouldn't these macros involve state and nor port, or maybe both? The original code was passing state to sr32. + else + clrbits_le32(ccm-apb1_gate, CCM_APB_GATE_TWI(port)); return 0; } Ian. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [PATCH u-boot (sc)] Cleanups of various clock macro's
On 03/27/2014 09:58 PM, Ian Campbell wrote: On Tue, 2014-03-25 at 12:59 +0100, Olliver Schinagl wrote: - sr32(ccm-apb1_clk_div_cfg, 24, 2, APB1_CLK_SRC_OSC24M); - sr32(ccm-apb1_clk_div_cfg, 16, 2, APB1_FACTOR_N); - sr32(ccm-apb1_clk_div_cfg, 0, 5, APB1_FACTOR_M); + clrsetbits_le32(ccm-apb1_clk_div_cfg, + CCM_APB1_CLK_SRC_OSC24M, CCM_APB1_CLK_SRC_OSC24M); + clrsetbits_le32(ccm-apb1_clk_div_cfg, + CCM_APB1_CLK_N_1, CCM_APB1_CLK_N_1); + clrsetbits_le32(ccm-apb1_clk_div_cfg, + CCM_APB1_CLK_M(1), CCM_APB1_CLK_M(1)); I'm not convinced we always have to clear the bit, before setting it. Using setbits is probably enough, but if this gets merged somehow (even if only in our own tree for now), i'd rather see it initially merged as such, to confirm everything is still working properly, and then with tests slowly change it. I mean, there must be a reason they used sr32 before, right? sr32 would (I think) have cleared the entire range of bits given, not just the bits corresponding to the value which it would then set, IYSWIM. Consider the case where the source is currently set to PLL6 (0x1) and you are changing to PLL5 (0x2, because that is more illustrative than OSC24==0x0). Your code would do effectively: reg = (reg ~0x2) | 0x2 if reg started as 0x1 then the result would be 0x3 and not 0x2 as desired. when what it should do is (reg ~0x3) | 1, where 0x3 is the mask of all the bits i.e. you are clearing the field before you set it. In other words you don't want: clrsetbits_le32(ccm-apb1_clk_div_cfg, CCM_APB1_CLK_SRC_OSC24M, CCM_APB1_CLK_SRC_OSC24M); You want: clrsetbits_le32(ccm-apb1_clk_div_cfg, CCM_APB1_CLK_SRC_MASK, CCM_APB1_CLK_SRC_OSC24M); where #define CCM_APB1_CLK_SRC_MASK CCM_APB1_CLK_SRC(0x3) (or however you want to do it) HTH, That does indeed help a lot. And I will adapt to it. Thank you for taking the time to explain it. I guess your explanation also makes my statement sound silly and wrong ;) I tried to read the defines to asm stuff, I'm not sure i follow it 100%. The names however, your explanation and this comment from the code: by * specifying the mask in the 'clear' parameter and the new bit pattern * in the 'set' parameter. I do understand that you (obviously) are right and it's probably the recommended way to set them, make sure everything is zero, then write the bit, over the masked area. I probably might want to check all the other setbits where the mask is larger then 1. Since we don't know what WAS there, correct? Thanks, Olliver Ian. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [RFC PATCH u-boot 0/2] Try to improve sunxi DRAM setup code
On 03/28/2014 11:42 AM, Siarhei Siamashka wrote: On Thu, 27 Mar 2014 16:26:02 +0100 Hans de Goede hdego...@redhat.com wrote: Hi, Thanks for the patches. I've merged and pushed the 1st one. The 2nd one esp. is a good find and a nice cleanup. It also seems to explain why we were getting various reports about instability on the cubieboard2, which ships with a dram clock of 480 where as it seems to be stable at 432, which exactly matches the threshold above which you say the timings become wrong. As Olliver already indicated we would like to do some more tests with the 2nd patch first, but eventually we definitely will want to merge it (assuming the testing goes well). I'm thinking that this means that we may be able to safely bump the dram clock on the cubietruck to 480, any opinion on this ? I have a Cubietruck, which can successfully boot to a login prompt with dram clocked at 504MHz. And a Cubieboard2, which can also boot to a login prompt with dram clocked at 552MHz respectively. However it does not mean that these devices are going to really work stable in these configurations. I have tried different tests and workloads during the last year or so. And it appears that competing memory accesses from both ARM CPU and Mali GPU tend to cause problems at the memory clock speeds, which are otherwise stable for CPU-only workloads. I understand that setting up binary drivers and then running some 3D accelerated applications while checking for memory corruption bugs at the same time is not something that many people would enjoy (or even try in the first place). And I had plans to try to simplify the test setup since a long time ago. Finally here it is: https://github.com/ssvb/lima-memtester Basically, that's just a single static binary with no dependencies. It combines a memtester tool with a simple spinning textured cube demo from the work-in-progress free open source Mali400 driver project http://limadriver.org/ That's amazing, we should prep a rootfs with all of that in it maybe too? setting up lima + mali + god knows what may be a bit too much for some right now, so having a pre-defined test rootfs might proove usefull... It would be 100% free software using only free software tools if the open source lima shader compiler could handle vertex shaders. Right now only the fragment shader binary had been generated using the open source shader compiler. But the vertex shader binary (injected as an array into the source code) still used the output of the proprietary shader compiler from the libMali.so blob. Anyway, my Cubietruck passes the test at 456MHz dram clock speed and fails at 480MHz. And my Cubieboard2 passes it at 504MHz but fails at 528MHz. The second patch from Jens Kuske unfortunately does not seem to have any visible effect here and does not change anything for me. That's unfortunate, I slightly hoped that the proper timings would result in better performance. But all hope is not yet lost, maybe on badly designed boards (tablets/mele) it does work better with the right timings. More test results using different hardware are welcome. Olliver -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH u-boot-sunxi 10/11] sunxi: Add mmc support for sun6i / A31
On 03/28/2014 11:16 AM, Hans de Goede wrote:
Signed-off-by: Hans de Goede hdego...@redhat.com
---
arch/arm/cpu/armv7/sunxi/clock.c | 3 +++
arch/arm/include/asm/arch-sunxi/clock-sun6i.h | 21 +
drivers/mmc/sunxi_mmc.c | 9 -
include/configs/sunxi-common.h| 2 --
4 files changed, 32 insertions(+), 3 deletions(-)
diff --git a/arch/arm/cpu/armv7/sunxi/clock.c b/arch/arm/cpu/armv7/sunxi/clock.c
index e3c8fef..273aa3f 100644
--- a/arch/arm/cpu/armv7/sunxi/clock.c
+++ b/arch/arm/cpu/armv7/sunxi/clock.c
@@ -58,6 +58,9 @@ int clock_init(void)
/* open the clock for uart */
sr32(ccm-apb2_gate, 16 + CONFIG_CONS_INDEX - 1, 1, CLK_GATE_OPEN);
+
+ /* Dup with clock_init_safe(), drop once sun6i SPL support lands */
+ writel(PLL6_CFG_DEFAULT, ccm-pll6_cfg);
Shouldn't this only be done on sun6i then? as sun457i do have the SPL?
olliver
#else
/* uart clock source is apb1 */
sr32(ccm-apb1_clk_div_cfg, 24, 2, APB1_CLK_SRC_OSC24M);
diff --git a/arch/arm/include/asm/arch-sunxi/clock-sun6i.h
b/arch/arm/include/asm/arch-sunxi/clock-sun6i.h
index 147e6c9..2f20d5d 100644
--- a/arch/arm/include/asm/arch-sunxi/clock-sun6i.h
+++ b/arch/arm/include/asm/arch-sunxi/clock-sun6i.h
@@ -141,4 +141,25 @@ struct sunxi_ccm_reg {
#define APB2_FACTOR_M 0
#define APB2_FACTOR_N 0
+#define PLL6_CFG_DEFAULT 0x90041911
+
+#define AHB_GATE_OFFSET_MMC3 11
+#define AHB_GATE_OFFSET_MMC2 10
+#define AHB_GATE_OFFSET_MMC1 9
+#define AHB_GATE_OFFSET_MMC0 8
+#define AHB_GATE_OFFSET_MMC(n) (AHB_GATE_OFFSET_MMC0 + (n))
+
+#define CCM_MMC_CTRL_OSCM24 (0x0 24)
+#define CCM_MMC_CTRL_PLL6 (0x1 24)
+
+#define CCM_MMC_CTRL_ENABLE (0x1 31)
+
+#define SUN6I_ABP1_RESET_BASE 0x01c202c0
+
+#define ABP1_RESET_OFFSET_MMC3 11
+#define ABP1_RESET_OFFSET_MMC2 10
+#define ABP1_RESET_OFFSET_MMC1 9
+#define ABP1_RESET_OFFSET_MMC0 8
+#define ABP1_RESET_OFFSET_MMC(n) (ABP1_RESET_OFFSET_MMC0 + (n))
+
#endif /* _SUNXI_CLOCK_SUN6I_H */
diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index 4573621..4cb5dc7 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -77,7 +77,7 @@ struct sunxi_mmc_des {
u32 data_buf1_sz:13;
u32 data_buf2_sz:13;
u32 reserverd2_1:6;
-#elif defined(CONFIG_SUN5I) || defined(CONFIG_SUN7I)
+#elif defined(CONFIG_SUN5I) || defined(CONFIG_SUN6I) || defined(CONFIG_SUN7I)
#define SDXC_DES_NUM_SHIFT 16
#define SDXC_DES_BUFFER_MAX_LEN (1 SDXC_DES_NUM_SHIFT)
u32 data_buf1_sz:16;
@@ -203,6 +203,13 @@ static int mmc_clk_io_on(int sdc_no)
rval |= 1 AHB_GATE_OFFSET_MMC(sdc_no);
writel(rval, ccm-ahb_gate0);
+#if defined(CONFIG_SUN6I)
+ /* unassert reset */
+ rval = readl(SUN6I_ABP1_RESET_BASE);
+ rval |= 1 ABP1_RESET_OFFSET_MMC(sdc_no);
+ writel(rval, SUN6I_ABP1_RESET_BASE);
+#endif
+
/* config mod clock */
pll_clk = clock_get_pll6();
/* should be close to 100 MHz but no more, so round up */
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index dd7c668..212b621 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -81,7 +81,6 @@
/* mmc config */
/* Can't use MMC slot 0 if the UART is directed there */
-#ifndef CONFIG_SUN6I
#if !defined CONFIG_UART0_PORT_F || CONFIG_MMC_SUNXI_SLOT != 0
#define CONFIG_MMC
#define CONFIG_GENERIC_MMC
@@ -94,7 +93,6 @@
#define CONFIG_ENV_IS_IN_MMC
#define CONFIG_SYS_MMC_ENV_DEV0 /* first detected MMC
controller */
#endif
-#endif
/* 4MB of malloc() pool */
#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + (4 20))
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH u-boot-sunxi 00/11] Initial sun6i support
On 03/28/2014 12:24 PM, Chen-Yu Tsai wrote: Hi, On Fri, Mar 28, 2014 at 6:16 PM, Hans de Goede hdego...@redhat.com wrote: Hi All, Here is a u-boot-sunxi patch series adding initial sun6i support, it is based on Maxime's bring up work for sun6i, to which I've added mmc support. Note that this makes some changes to how we handle the mmc module clock in general, which brings the u-boot code in line with what the kernel does for the mmc mod clock. This series does not add full sun6i support, we don't have an SPL / dram setup code yet. What this series does is generate a u-boot.bin which can be used to replace the u-boot used on sdcard images generated by the allwinner tools. IOW boot0 and boot1 are still needed. Has anyone tried the dram setup code here: http://git.rhombus-tech.net/?p=u-boot.git;a=blob;f=arch/arm/cpu/armv7/sunxi/dram_sun6i.c;h=9275ca21ac99592c7d520a41c0914b359c27b913;hb=refs/heads/lichee/jb-4.2.2-a31 What else is needed for SPL? Hrmm, when did that happen and where did that come from? afaik we never got the boot0 source, and while it uses the same filename i used for my initial sun6i dram work, this does seem to have extra comments ... Of course, this may simply never have been shared with sunxi I suppose? Olliver Regards, Hans -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- 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] A23 tablet
On 03/28/2014 07:43 AM, jtd wrote: Hi all, I am new to the list. Is there any work happening on the A23 ? Nothing yet. Some devs have started to obtain A23 hardware, myself I'm getting one sent by AW, but haven't received it yet. Once devs have hardware, we can start adding support, but don't expect much initially. It will take a lot of work and a lot of time to get going. Olliver I have a couple 7 MIIDs with me. SOC A23 RAM GT8UB512M 16 512 x 16 ddr3 Flash H27UCG8t2b Hynix 8GB PMU AXP223 Touch Gsl1680 Wifi RTL8188 Any pointers to getting debian on to this. Sunxi wiki does not seem to have any pointers. I tried my luck with a working A20 Fedora 19 image and it does not boot on the A23 . Apologies if this not the right place for such posts P.S . got hold of some doze tools PhoenixSuitV1.0.6 (1).7z Wine would be a real pita to get this working. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH u-boot-sunxi 10/11] sunxi: Add mmc support for sun6i / A31
On 03/28/2014 01:45 PM, Hans de Goede wrote:
Hi,
On 03/28/2014 01:38 PM, Olliver Schinagl wrote:
On 03/28/2014 11:16 AM, Hans de Goede wrote:
Signed-off-by: Hans de Goede hdego...@redhat.com
---
arch/arm/cpu/armv7/sunxi/clock.c | 3 +++
arch/arm/include/asm/arch-sunxi/clock-sun6i.h | 21 +
drivers/mmc/sunxi_mmc.c | 9 -
include/configs/sunxi-common.h| 2 --
4 files changed, 32 insertions(+), 3 deletions(-)
diff --git a/arch/arm/cpu/armv7/sunxi/clock.c b/arch/arm/cpu/armv7/sunxi/clock.c
index e3c8fef..273aa3f 100644
--- a/arch/arm/cpu/armv7/sunxi/clock.c
+++ b/arch/arm/cpu/armv7/sunxi/clock.c
@@ -58,6 +58,9 @@ int clock_init(void)
/* open the clock for uart */
sr32(ccm-apb2_gate, 16 + CONFIG_CONS_INDEX - 1, 1, CLK_GATE_OPEN);
+
+/* Dup with clock_init_safe(), drop once sun6i SPL support lands */
+writel(PLL6_CFG_DEFAULT, ccm-pll6_cfg);
Shouldn't this only be done on sun6i then? as sun457i do have the SPL?
olliver
#else
And it is only done on sun6i, the #else above is where the non sun6i code
starts...
Ah, that bit got a little lost in translation then, probably a previous
patch. My dearest apologies!
Olliver
Regards,
Hans
/* uart clock source is apb1 */
sr32(ccm-apb1_clk_div_cfg, 24, 2, APB1_CLK_SRC_OSC24M);
diff --git a/arch/arm/include/asm/arch-sunxi/clock-sun6i.h
b/arch/arm/include/asm/arch-sunxi/clock-sun6i.h
index 147e6c9..2f20d5d 100644
--- a/arch/arm/include/asm/arch-sunxi/clock-sun6i.h
+++ b/arch/arm/include/asm/arch-sunxi/clock-sun6i.h
@@ -141,4 +141,25 @@ struct sunxi_ccm_reg {
#define APB2_FACTOR_M0
#define APB2_FACTOR_N0
+#define PLL6_CFG_DEFAULT0x90041911
+
+#define AHB_GATE_OFFSET_MMC311
+#define AHB_GATE_OFFSET_MMC210
+#define AHB_GATE_OFFSET_MMC19
+#define AHB_GATE_OFFSET_MMC08
+#define AHB_GATE_OFFSET_MMC(n)(AHB_GATE_OFFSET_MMC0 + (n))
+
+#define CCM_MMC_CTRL_OSCM24 (0x0 24)
+#define CCM_MMC_CTRL_PLL6 (0x1 24)
+
+#define CCM_MMC_CTRL_ENABLE (0x1 31)
+
+#define SUN6I_ABP1_RESET_BASE0x01c202c0
+
+#define ABP1_RESET_OFFSET_MMC311
+#define ABP1_RESET_OFFSET_MMC210
+#define ABP1_RESET_OFFSET_MMC19
+#define ABP1_RESET_OFFSET_MMC08
+#define ABP1_RESET_OFFSET_MMC(n)(ABP1_RESET_OFFSET_MMC0 + (n))
+
#endif /* _SUNXI_CLOCK_SUN6I_H */
diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index 4573621..4cb5dc7 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -77,7 +77,7 @@ struct sunxi_mmc_des {
u32 data_buf1_sz:13;
u32 data_buf2_sz:13;
u32 reserverd2_1:6;
-#elif defined(CONFIG_SUN5I) || defined(CONFIG_SUN7I)
+#elif defined(CONFIG_SUN5I) || defined(CONFIG_SUN6I) || defined(CONFIG_SUN7I)
#define SDXC_DES_NUM_SHIFT 16
#define SDXC_DES_BUFFER_MAX_LEN(1 SDXC_DES_NUM_SHIFT)
u32 data_buf1_sz:16;
@@ -203,6 +203,13 @@ static int mmc_clk_io_on(int sdc_no)
rval |= 1 AHB_GATE_OFFSET_MMC(sdc_no);
writel(rval, ccm-ahb_gate0);
+#if defined(CONFIG_SUN6I)
+/* unassert reset */
+rval = readl(SUN6I_ABP1_RESET_BASE);
+rval |= 1 ABP1_RESET_OFFSET_MMC(sdc_no);
+writel(rval, SUN6I_ABP1_RESET_BASE);
+#endif
+
/* config mod clock */
pll_clk = clock_get_pll6();
/* should be close to 100 MHz but no more, so round up */
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index dd7c668..212b621 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -81,7 +81,6 @@
/* mmc config */
/* Can't use MMC slot 0 if the UART is directed there */
-#ifndef CONFIG_SUN6I
#if !defined CONFIG_UART0_PORT_F || CONFIG_MMC_SUNXI_SLOT != 0
#define CONFIG_MMC
#define CONFIG_GENERIC_MMC
@@ -94,7 +93,6 @@
#define CONFIG_ENV_IS_IN_MMC
#define CONFIG_SYS_MMC_ENV_DEV0/* first detected MMC controller
*/
#endif
-#endif
/* 4MB of malloc() pool */
#define CONFIG_SYS_MALLOC_LEN(CONFIG_ENV_SIZE + (4 20))
--
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] sunxi: whitespace cleanup to fel mode linker script.
On 03/28/2014 01:48 PM, Hans de Goede wrote:
Hi,
On 03/28/2014 12:57 PM, Olliver Schinagl wrote:
On 03/27/2014 11:05 PM, Ian Campbell wrote:
This makes the script somewhat more conformant to the upstream coding style
using in other linker scripts.
Add a license header at the same time.
Signed-off-by: Ian Campbell i...@hellion.org.uk
Cc: Henrik Nordstrom hen...@henriknordstrom.net
---
Henrik, I added a license header here since one was missing, since you authored
the file please could you confirm it is correct and if so add your S-o-b,
thanks.
I have it applied locally, and queued up with the other patches you sent +
jemk's dram patch. If henrik gives his SoB; i'll push them all to sunxi-u-boot
I've already pushed all 5 Ian's cleanup patches. I missed this comment
about the copyright stuff. If hno objects we can always revert that bit.
I guess hno can just as easily edit the commit message and push -force ;)
I saw your e-mail after I applied them, you are way to fast!
As for pushing jemk's dram patch I've tested it on the boards we discussed
and it works fine for me.
And on that note, i've pushed the patch!
Olliver
Regards,
Hans
I've tested the dram patch on 2 boards, and hansg tested them on 3 other boards.
Olliver
---
arch/arm/cpu/armv7/sunxi/u-boot-spl-fel.lds | 124
1 file changed, 71 insertions(+), 53 deletions(-)
diff --git a/arch/arm/cpu/armv7/sunxi/u-boot-spl-fel.lds
b/arch/arm/cpu/armv7/sunxi/u-boot-spl-fel.lds
index cf02300..364e35c 100644
--- a/arch/arm/cpu/armv7/sunxi/u-boot-spl-fel.lds
+++ b/arch/arm/cpu/armv7/sunxi/u-boot-spl-fel.lds
@@ -1,59 +1,77 @@
+/*
+ * (C) Copyright 2013
+ * Henrik Nordstrom hen...@henriknordstrom.net
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
OUTPUT_FORMAT(elf32-littlearm, elf32-littlearm, elf32-littlearm)
OUTPUT_ARCH(arm)
ENTRY(s_init)
SECTIONS
{
- . = 0x2000;
- . = ALIGN(4);
- .text :
- {
- *(.text.s_init)
- *(.text*)
- }
- . = ALIGN(4);
- .rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) }
- . = ALIGN(4);
- .data : {
- *(.data*)
- }
- . = ALIGN(4);
- . = .;
- . = ALIGN(4);
- .rel.dyn : {
- __rel_dyn_start = .;
- *(.rel*)
- __rel_dyn_end = .;
- }
- .dynsym : {
- __dynsym_start = .;
- *(.dynsym)
- }
- . = ALIGN(4);
- .note.gnu.build-id :
- {
-*(.note.gnu.build-id)
- }
- _end = .;
- . = ALIGN(4096);
- .mmutable : {
- *(.mmutable)
- }
- .bss_start __rel_dyn_start (OVERLAY) : {
- KEEP(*(.__bss_start));
- __bss_base = .;
- }
- .bss __bss_base (OVERLAY) : {
- *(.bss*)
- . = ALIGN(4);
- __bss_limit = .;
- }
- .bss_end __bss_limit (OVERLAY) : {
- KEEP(*(.__bss_end));
- }
- /DISCARD/ : { *(.dynstr*) }
- /DISCARD/ : { *(.dynamic*) }
- /DISCARD/ : { *(.plt*) }
- /DISCARD/ : { *(.interp*) }
- /DISCARD/ : { *(.gnu*) }
- /DISCARD/ : { *(.note*) }
+. = 0x2000;
+
+. = ALIGN(4);
+.text :
+{
+*(.text.s_init)
+*(.text*)
+}
+
+. = ALIGN(4);
+.rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) }
+
+. = ALIGN(4);
+.data : {
+*(.data*)
+}
+
+. = ALIGN(4);
+. = .;
+
+. = ALIGN(4);
+.rel.dyn : {
+__rel_dyn_start = .;
+*(.rel*)
+__rel_dyn_end = .;
+}
+
+.dynsym : {
+__dynsym_start = .;
+*(.dynsym)
+}
+
+. = ALIGN(4);
+.note.gnu.build-id :
+{
+*(.note.gnu.build-id)
+}
+_end = .;
+
+. = ALIGN(4096);
+.mmutable : {
+*(.mmutable)
+}
+
+.bss_start __rel_dyn_start (OVERLAY) : {
+KEEP(*(.__bss_start));
+__bss_base = .;
+}
+
+.bss __bss_base (OVERLAY) : {
+*(.bss*)
+. = ALIGN(4);
+__bss_limit = .;
+}
+
+.bss_end __bss_limit (OVERLAY) : {
+KEEP(*(.__bss_end));
+}
+
+/DISCARD/ : { *(.dynstr*) }
+/DISCARD/ : { *(.dynamic*) }
+/DISCARD/ : { *(.plt*) }
+/DISCARD/ : { *(.interp*) }
+/DISCARD/ : { *(.gnu*) }
+/DISCARD/ : { *(.note*) }
}
--
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] Current u-boot crashes my cubietruck!
Hey all, I was using current head on my Cubietruck; and it kept crashing. I first tried to revert the density/width only, but that made no difference what so ever. The first crash I had on cloning git during 3.4.79+; i first reverted to Hans's 3.4 series from fedora 19, but then a big huge oops happened even during boot. And consistently during boot. It doesn't seem to be power relate either. I have since reverted to d9aa5dd3d and that seems to be stable again. I will cook dinner now, and keep the board running using the d9 hash and checkout a few newer revisions then. Stable for 10 minutes now though ;) Olliver -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Current u-boot crashes my cubietruck!
On 03/29/2014 05:37 PM, Ian Campbell wrote: On Sat, 2014-03-29 at 16:52 +0100, Olliver Schinagl wrote: Hey all, I was using current head on my Cubietruck; and it kept crashing. I first tried to revert the density/width only, but that made no difference what so ever. Oh dear. Aye! Using the merge tag seems to be fine however, d2a8c8da1. So it is one of the newer patches, will slowly progress the line, as time permits, to find the culprit. The first crash I had on cloning git during 3.4.79+; i first reverted to Hans's 3.4 series from fedora 19, but then a big huge oops happened even during boot. And consistently during boot. It doesn't seem to be power relate either. I have since reverted to d9aa5dd3d and that seems to be stable again. Which branch are you running? u-boot-sunxi/sunxi I guess but you mention Hans' series so maybe jwrdegoede/sunxi-next? for u-boot, the linux-sunxi u-boot variant. for the kernel, hans's 3.4 that comes with fedora 19; but I initially experienced these problems with one the sunxi nightlies, a 3.4.79+ I will cook dinner now, and keep the board running using the d9 hash and checkout a few newer revisions then. Stable for 10 minutes now though ;) The obvious first one to try would be d2a8c8da1c6 Merge tag 'v2014.04-rc2' into sunxi. Its immediate parent on the sunxi side is d9aa5dd3d which you've already found to be stable. If you can rule that out then the rest should be fairly tractable to bisect... Looking at gitk d9aa5dd3d...u-boot-sunxi/sunxi --not origin/master most of them are supposed to be no semantic change type cleanups or things which don't touch cubietruck... If it does turn out to be the merge then I think it will be time to take a fine toothed comb to the merge... Luckily, this does not seem the case. I will keep you all posted. Olliver Ian. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Current u-boot crashes my cubietruck!
On 03/30/2014 12:25 PM, Olliver Schinagl wrote: Status update: d2a8c8d Merge tag 'v2014.04-rc2' into sunxi seems stable and was able to compile u-boot on itself ;) linux-sunxi kept failing due to remote hung endpoints while fetching the full git tree, nothing unexpected there. 4362605 Merge remote-tracking branch 'remotes/ijc/sunxi-merge-v2014.04-rc2' into sunxi So far, that looks good; running a tar xJvf on the linux-sunxi tar.xz causes no issues yet. I'll keep using that rev for a few hours then go onto the next one. I shouted too early :( [ 508.891546] Process login (pid: 2265, stack limit = 0xee5f82f0) [ 508.901743] Stack: (0xee5f9e78 to 0xee5fa000) [ 508.910451] 9e60: 01f9 c006bab0 [ 508.923123] 9e80: d1015788 ee825a78 b7caf08b 0003 ee825a8c c0782b28 d1015788 ee5f9f10 [ 508.935835] 9ea0: 0001 c00d5498 ee5f9f10 0001 ee5f8010 c051a038 c012bc38 [ 508.948540] 9ec0: ee6398b8 ee639800 ee58cb40 271ae921 ee639800 ee63989c [ 508.961336] 9ee0: 0001 ee63990c ee58cb40 c0292cbc 0007 c05442e4 c0292504 c077f97c [ 508.974074] 9f00: ee5f8000 ee5c72c0 0001 ee639800 ee5f8000 ee5f8028 ee5f8000 [ 508.986932] 9f20: 0005 c02935c0 ee825a40 0001 ee5f8000 c000e108 c003d5b8 [ 508.999755] 9f40: b6d3c000 ee5038fc ee4f9884 c0101d18 ee4f9880 ee5038f0 c023b764 [ 509.012692] 9f60: ee4f98b8 eeb9d080 ee5f8000 00f8 c000e108 ee5f8000 [ 509.025742] 9f80: 0005 c003db38 0006efae b6f4 b6f4 00f8 c003dbc4 [ 509.038900] 9fa0: c000df00 0006efae b6f4 0006ef9a b6fbc4c0 [ 509.052039] 9fc0: 0006efae b6f4 b6f4 00f8 00857898 008513f8 000171d8 0005 [ 509.065171] 9fe0: 00f8 be9a7834 b6f0a0f3 b6eaef96 6030 [ 509.078413] [c0299810] (tty_ldisc_hangup+0x3c/0x2a4) from [c0292cbc] (__tty_hangup+0x124/0x378) [ 509.097651] [c0292cbc] (__tty_hangup+0x124/0x378) from [c02935c0] (disassociate_ctty+0x7c/0x240) [ 509.117536] [c02935c0] (disassociate_ctty+0x7c/0x240) from [c003d5b8] (do_exit+0x294/0x784) [ 509.131797] [c003d5b8] (do_exit+0x294/0x784) from [c003db38] (do_group_exit+0x54/0xc8) [ 509.145622] [c003db38] (do_group_exit+0x54/0xc8) from [c003dbc4] (__wake_up_parent+0x0/0x20) [ 509.159980] Code: e2066002 e2505000 0a18 e5953000 (e5933018) [ 509.171733] ---[ end trace 0b4cd254dfcafc0c ]--- [ 509.181906] Fixing recursive fault but reboot is needed! Going back to the parent rev, d3686aa sunxi: use a 4MB malloc pool and report then :) olliver On 03/30/2014 11:05 AM, Olliver Schinagl wrote: On 03/29/2014 05:37 PM, Ian Campbell wrote: On Sat, 2014-03-29 at 16:52 +0100, Olliver Schinagl wrote: Hey all, I was using current head on my Cubietruck; and it kept crashing. I first tried to revert the density/width only, but that made no difference what so ever. Oh dear. Aye! Using the merge tag seems to be fine however, d2a8c8da1. So it is one of the newer patches, will slowly progress the line, as time permits, to find the culprit. The first crash I had on cloning git during 3.4.79+; i first reverted to Hans's 3.4 series from fedora 19, but then a big huge oops happened even during boot. And consistently during boot. It doesn't seem to be power relate either. I have since reverted to d9aa5dd3d and that seems to be stable again. Which branch are you running? u-boot-sunxi/sunxi I guess but you mention Hans' series so maybe jwrdegoede/sunxi-next? for u-boot, the linux-sunxi u-boot variant. for the kernel, hans's 3.4 that comes with fedora 19; but I initially experienced these problems with one the sunxi nightlies, a 3.4.79+ I will cook dinner now, and keep the board running using the d9 hash and checkout a few newer revisions then. Stable for 10 minutes now though ;) The obvious first one to try would be d2a8c8da1c6 Merge tag 'v2014.04-rc2' into sunxi. Its immediate parent on the sunxi side is d9aa5dd3d which you've already found to be stable. If you can rule that out then the rest should be fairly tractable to bisect... Looking at gitk d9aa5dd3d...u-boot-sunxi/sunxi --not origin/master most of them are supposed to be no semantic change type cleanups or things which don't touch cubietruck... If it does turn out to be the merge then I think it will be time to take a fine toothed comb to the merge... Luckily, this does not seem the case. I will keep you all posted. Olliver Ian. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Current u-boot crashes my cubietruck!
On 03/30/2014 12:33 PM, Olliver Schinagl wrote: On 03/30/2014 12:25 PM, Olliver Schinagl wrote: Status update: d2a8c8d Merge tag 'v2014.04-rc2' into sunxi seems stable and was able to compile u-boot on itself ;) linux-sunxi kept failing due to remote hung endpoints while fetching the full git tree, nothing unexpected there. 4362605 Merge remote-tracking branch 'remotes/ijc/sunxi-merge-v2014.04-rc2' into sunxi So far, that looks good; running a tar xJvf on the linux-sunxi tar.xz causes no issues yet. I'll keep using that rev for a few hours then go onto the next one. I shouted too early :( [ 508.891546] Process login (pid: 2265, stack limit = 0xee5f82f0) [ 508.901743] Stack: (0xee5f9e78 to 0xee5fa000) [ 508.910451] 9e60: 01f9 c006bab0 [ 508.923123] 9e80: d1015788 ee825a78 b7caf08b 0003 ee825a8c c0782b28 d1015788 ee5f9f10 [ 508.935835] 9ea0: 0001 c00d5498 ee5f9f10 0001 ee5f8010 c051a038 c012bc38 [ 508.948540] 9ec0: ee6398b8 ee639800 ee58cb40 271ae921 ee639800 ee63989c [ 508.961336] 9ee0: 0001 ee63990c ee58cb40 c0292cbc 0007 c05442e4 c0292504 c077f97c [ 508.974074] 9f00: ee5f8000 ee5c72c0 0001 ee639800 ee5f8000 ee5f8028 ee5f8000 [ 508.986932] 9f20: 0005 c02935c0 ee825a40 0001 ee5f8000 c000e108 c003d5b8 [ 508.999755] 9f40: b6d3c000 ee5038fc ee4f9884 c0101d18 ee4f9880 ee5038f0 c023b764 [ 509.012692] 9f60: ee4f98b8 eeb9d080 ee5f8000 00f8 c000e108 ee5f8000 [ 509.025742] 9f80: 0005 c003db38 0006efae b6f4 b6f4 00f8 c003dbc4 [ 509.038900] 9fa0: c000df00 0006efae b6f4 0006ef9a b6fbc4c0 [ 509.052039] 9fc0: 0006efae b6f4 b6f4 00f8 00857898 008513f8 000171d8 0005 [ 509.065171] 9fe0: 00f8 be9a7834 b6f0a0f3 b6eaef96 6030 [ 509.078413] [c0299810] (tty_ldisc_hangup+0x3c/0x2a4) from [c0292cbc] (__tty_hangup+0x124/0x378) [ 509.097651] [c0292cbc] (__tty_hangup+0x124/0x378) from [c02935c0] (disassociate_ctty+0x7c/0x240) [ 509.117536] [c02935c0] (disassociate_ctty+0x7c/0x240) from [c003d5b8] (do_exit+0x294/0x784) [ 509.131797] [c003d5b8] (do_exit+0x294/0x784) from [c003db38] (do_group_exit+0x54/0xc8) [ 509.145622] [c003db38] (do_group_exit+0x54/0xc8) from [c003dbc4] (__wake_up_parent+0x0/0x20) [ 509.159980] Code: e2066002 e2505000 0a18 e5953000 (e5933018) [ 509.171733] ---[ end trace 0b4cd254dfcafc0c ]--- [ 509.181906] Fixing recursive fault but reboot is needed! Going back to the parent rev, d3686aa sunxi: use a 4MB malloc pool and report then :) Right, this one doesn't seem to crash; but I cant extract the .xz either... linux-sunxi/.git/objects/pack/pack-06962d550c8aab83282655647120ce3552ca5b0e.idx xz: (stdin): Compressed data is corrupt tar: Unexpected EOF in archive tar: Unexpected EOF in archive tar: Error is not recoverable: exiting now and that constantly, sometimes it gets to go 1 file further ... ironically the sha1 calculation worked fine I'll go back to pre-merge and double check that. olliver On 03/30/2014 11:05 AM, Olliver Schinagl wrote: On 03/29/2014 05:37 PM, Ian Campbell wrote: On Sat, 2014-03-29 at 16:52 +0100, Olliver Schinagl wrote: Hey all, I was using current head on my Cubietruck; and it kept crashing. I first tried to revert the density/width only, but that made no difference what so ever. Oh dear. Aye! Using the merge tag seems to be fine however, d2a8c8da1. So it is one of the newer patches, will slowly progress the line, as time permits, to find the culprit. The first crash I had on cloning git during 3.4.79+; i first reverted to Hans's 3.4 series from fedora 19, but then a big huge oops happened even during boot. And consistently during boot. It doesn't seem to be power relate either. I have since reverted to d9aa5dd3d and that seems to be stable again. Which branch are you running? u-boot-sunxi/sunxi I guess but you mention Hans' series so maybe jwrdegoede/sunxi-next? for u-boot, the linux-sunxi u-boot variant. for the kernel, hans's 3.4 that comes with fedora 19; but I initially experienced these problems with one the sunxi nightlies, a 3.4.79+ I will cook dinner now, and keep the board running using the d9 hash and checkout a few newer revisions then. Stable for 10 minutes now though ;) The obvious first one to try would be d2a8c8da1c6 Merge tag 'v2014.04-rc2' into sunxi. Its immediate parent on the sunxi side is d9aa5dd3d which you've already found to be stable. If you can rule that out then the rest should be fairly tractable to bisect... Looking at gitk d9aa5dd3d...u-boot-sunxi/sunxi --not origin/master most of them are supposed to be no semantic change type cleanups or things which don't touch cubietruck... If it does turn out to be the merge then I think it will be time to take a fine toothed comb to the merge... Luckily, this does not seem the case. I will keep you all posted. Olliver Ian
Re: [linux-sunxi] Current u-boot crashes my cubietruck!
On 03/30/2014 12:43 PM, Olliver Schinagl wrote: On 03/30/2014 12:33 PM, Olliver Schinagl wrote: On 03/30/2014 12:25 PM, Olliver Schinagl wrote: Status update: d2a8c8d Merge tag 'v2014.04-rc2' into sunxi seems stable and was able to compile u-boot on itself ;) linux-sunxi kept failing due to remote hung endpoints while fetching the full git tree, nothing unexpected there. 4362605 Merge remote-tracking branch 'remotes/ijc/sunxi-merge-v2014.04-rc2' into sunxi So far, that looks good; running a tar xJvf on the linux-sunxi tar.xz causes no issues yet. I'll keep using that rev for a few hours then go onto the next one. I shouted too early :( [ 508.891546] Process login (pid: 2265, stack limit = 0xee5f82f0) [ 508.901743] Stack: (0xee5f9e78 to 0xee5fa000) [ 508.910451] 9e60: 01f9 c006bab0 [ 508.923123] 9e80: d1015788 ee825a78 b7caf08b 0003 ee825a8c c0782b28 d1015788 ee5f9f10 [ 508.935835] 9ea0: 0001 c00d5498 ee5f9f10 0001 ee5f8010 c051a038 c012bc38 [ 508.948540] 9ec0: ee6398b8 ee639800 ee58cb40 271ae921 ee639800 ee63989c [ 508.961336] 9ee0: 0001 ee63990c ee58cb40 c0292cbc 0007 c05442e4 c0292504 c077f97c [ 508.974074] 9f00: ee5f8000 ee5c72c0 0001 ee639800 ee5f8000 ee5f8028 ee5f8000 [ 508.986932] 9f20: 0005 c02935c0 ee825a40 0001 ee5f8000 c000e108 c003d5b8 [ 508.999755] 9f40: b6d3c000 ee5038fc ee4f9884 c0101d18 ee4f9880 ee5038f0 c023b764 [ 509.012692] 9f60: ee4f98b8 eeb9d080 ee5f8000 00f8 c000e108 ee5f8000 [ 509.025742] 9f80: 0005 c003db38 0006efae b6f4 b6f4 00f8 c003dbc4 [ 509.038900] 9fa0: c000df00 0006efae b6f4 0006ef9a b6fbc4c0 [ 509.052039] 9fc0: 0006efae b6f4 b6f4 00f8 00857898 008513f8 000171d8 0005 [ 509.065171] 9fe0: 00f8 be9a7834 b6f0a0f3 b6eaef96 6030 [ 509.078413] [c0299810] (tty_ldisc_hangup+0x3c/0x2a4) from [c0292cbc] (__tty_hangup+0x124/0x378) [ 509.097651] [c0292cbc] (__tty_hangup+0x124/0x378) from [c02935c0] (disassociate_ctty+0x7c/0x240) [ 509.117536] [c02935c0] (disassociate_ctty+0x7c/0x240) from [c003d5b8] (do_exit+0x294/0x784) [ 509.131797] [c003d5b8] (do_exit+0x294/0x784) from [c003db38] (do_group_exit+0x54/0xc8) [ 509.145622] [c003db38] (do_group_exit+0x54/0xc8) from [c003dbc4] (__wake_up_parent+0x0/0x20) [ 509.159980] Code: e2066002 e2505000 0a18 e5953000 (e5933018) [ 509.171733] ---[ end trace 0b4cd254dfcafc0c ]--- [ 509.181906] Fixing recursive fault but reboot is needed! Going back to the parent rev, d3686aa sunxi: use a 4MB malloc pool and report then :) Right, this one doesn't seem to crash; but I cant extract the .xz either... linux-sunxi/.git/objects/pack/pack-06962d550c8aab83282655647120ce3552ca5b0e.idx xz: (stdin): Compressed data is corrupt tar: Unexpected EOF in archive tar: Unexpected EOF in archive tar: Error is not recoverable: exiting now and that constantly, sometimes it gets to go 1 file further ... ironically the sha1 calculation worked fine I'll go back to pre-merge and double check that. 4271202 sunxi: add board hcore hc860 seems to be un-able to extract the tar-ball and causes an oops. [ 450.179006] [c02449fc] (__list_del_entry+0x8/0xb8) from [c0244ab8] (list_del+0xc/0x24) [ 450.199528] [c0244ab8] (list_del+0xc/0x24) from [c00e48c0] (__rmqueue+0x70/0x370) [ 450.219659] [c00e48c0] (__rmqueue+0x70/0x370) from [c00e563c] (get_page_from_freelist+0x324/0x4b8) [ 450.253607] [c00e563c] (get_page_from_freelist+0x324/0x4b8) from [c00e6154] (__alloc_pages_nodemask+0x18c/0x7b4) [ 450.289644] [c00e6154] (__alloc_pages_nodemask+0x18c/0x7b4) from [c0115560] (new_slab+0x84/0x23c) [ 450.325304] [c0115560] (new_slab+0x84/0x23c) from [c0509ad0] (__slab_alloc.constprop.54+0x20c/0x450) [ 450.362016] [c0509ad0] (__slab_alloc.constprop.54+0x20c/0x450) from [c0116e84] (kmem_cache_alloc+0x70/0x18c) [ 450.400291] [c0116e84] (kmem_cache_alloc+0x70/0x18c) from [c019cb34] (ext4_alloc_inode+0x20/0xbc) [ 450.438405] [c019cb34] (ext4_alloc_inode+0x20/0xbc) from [c0133230] (alloc_inode+0x24/0x9c) [ 450.462253] [c0133230] (alloc_inode+0x24/0x9c) from [c0134c30] (new_inode_pseudo+0x10/0x50) [ 450.486131] [c0134c30] (new_inode_pseudo+0x10/0x50) from [c0134c80] (new_inode+0x10/0x24) [ 450.509985] [c0134c80] (new_inode+0x10/0x24) from [c0184ff8] (ext4_new_inode+0x94/0xee0) [ 450.533711] [c0184ff8] (ext4_new_inode+0x94/0xee0) from [c0191318] (ext4_create+0xb0/0x150) [ 450.557750] [c0191318] (ext4_create+0xb0/0x150) from [c012905c] (vfs_create+0x98/0x11c) [ 450.581516] [c012905c] (vfs_create+0x98/0x11c) from [c01294f8] (do_last+0x418/0x7e8) [ 450.605109] [c01294f8] (do_last+0x418/0x7e8) from [c012a164] (path_openat+0xc4/0x39c) [ 450.628904] [c012a164] (path_openat+0xc4/0x39c) from [c012a530] (do_filp_open+0x34/0x80) [ 450.653058] [c012a530] (do_filp_open+0x34/0x80) from [c011b7e0] (do_sys_open+0xf0/0x17c
Re: [linux-sunxi] Current u-boot crashes my cubietruck!
On 03/30/2014 01:26 PM, Ian Campbell wrote: On Sun, 2014-03-30 at 12:58 +0200, Olliver Schinagl wrote: 4271202 sunxi: add board hcore hc860 seems to be un-able to extract the tar-ball and causes an oops. That's from ages ago, isn't it? It is! I will now use the u-boot from even older; that came with fedora19, very conservative, but also 'known to be somewhat good' Are you sure it isn't some other component which has changed recently, e.g. the kernel? Software wise, i'm running it quite conservative really, really old stuff so to say. That said the sorts of random crashed you've been posting sound a lot like either a DRAM issue or overheating. Either of which could be down to u-boot setting up something wrong or bad hardware I suppose. Overheating, maybe. It feels hottish to the touch, but can hold a finger on it without any problem whatsoever. Not close to the pain point. So I estimate 50 C? Shouldn't be reason to be concerned imo. Power might be the problem, i see the input voltage under heavy load drop to 4.65 Volts @ 0.9 amps This is on an SSD, with a 2amps charger. I ran tinymembenches before never exceeding 0.7 amps; could someone confirm this on the cubietruck? I've just FEL booted with 2014.04-rc2-00665-g96510e1 (i.e. current u-boot-sunxi.git#sunxi) onto a SATA installation and have started a git clone of the kernel, after which I'll run a build and see what happens. Cool, the strange thing is, u-boot cloned and compiled fine :( Have you checked the checksum of the tarball you are extracting and tried unpacking it on a known good system? The sha1sum matches, calculated on the board, so that's good. xz -d completed successfully! tar xvf fails however, with a big ass 5 page long oops. Olliver Ian. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Current u-boot crashes my cubietruck!
On 03/30/2014 02:25 PM, Ian Campbell wrote: On Sun, 2014-03-30 at 12:26 +0100, Ian Campbell wrote: I've just FEL booted with 2014.04-rc2-00665-g96510e1 (i.e. current u-boot-sunxi.git#sunxi) onto a SATA installation and have started a git clone of the kernel, after which I'll run a build and see what happens. So, I did the git clone, checkout, config and make all -j4 has been running for quite a while now (10 minutes) with no errors. While the make was running I've messed around with git archive to produce a tar.xz, got bored waiting for that, used wget to download a tar.xz from kernel.org and unpacked it. All with no errors. IOW I'm afraid it all looks OK to me. This is all running from a SATA disk with a 2A power supply. I'm about to go out for lunch, if it crashes etc while I'm out I'll let you know after I get back. Looking forward to the result, but I'm sure it'll be fine ;) So i changed to the u-boot that comes with fedora 19 from hans, as I did all my previous work with that, and untarring of the extracted tarball works now. I have to make a deadline for my book (building the BSP, hence i bumped into this) and will do more compile/extraction tests in the next few days as time permits on hans's u-boot. I'll run some of ssvb's benchmarks to test various things. If this is all deemed stable; then it can only be u-boot that somehow broke. The only thing I can imagine is tolerances or power usage somehow. Speaking of, during the extraction power jumped from just under 0.5 amps @ 4.85V = idle; to about 0.85 amps @ 4.75V. Olliver This is all on a cubietruck BTW. ditto ;) Ian. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Azpen A727 / A23 chip
On 03/30/2014 07:17 PM, Daniel J. Grinkevich wrote: I just got an Azpen A727 (some reason it's not on the company's website), it runs the A23 chip. I managed to find the serial TX but RX is still unknown. I started a wiki page, http://linux-sunxi.org/A727 . If anyone has any specific ideas or anyway I can help, I'm willing to probe it some more. You could try by going over the New_Device_Howto though a lot of things might not work out right away. a10-meminfo won't work for example. Even so, having gone over the New_Device_Howto should get us a little bit closer. Thanks for taking the time and effort! Olliver Dan -- 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 mailto: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] Current u-boot crashes my cubietruck!
On 03/31/2014 08:04 PM, Olliver Schinagl wrote: On 03/31/2014 08:59 AM, Hans de Goede wrote: Hi, On 03/31/2014 08:49 AM, Hans de Goede wrote: Hi, On 03/30/2014 02:40 PM, Olliver Schinagl wrote: On 03/30/2014 02:25 PM, Ian Campbell wrote: On Sun, 2014-03-30 at 12:26 +0100, Ian Campbell wrote: I've just FEL booted with 2014.04-rc2-00665-g96510e1 (i.e. current u-boot-sunxi.git#sunxi) onto a SATA installation and have started a git clone of the kernel, after which I'll run a build and see what happens. So, I did the git clone, checkout, config and make all -j4 has been running for quite a while now (10 minutes) with no errors. While the make was running I've messed around with git archive to produce a tar.xz, got bored waiting for that, used wget to download a tar.xz from kernel.org and unpacked it. All with no errors. IOW I'm afraid it all looks OK to me. This is all running from a SATA disk with a 2A power supply. I'm about to go out for lunch, if it crashes etc while I'm out I'll let you know after I get back. Looking forward to the result, but I'm sure it'll be fine ;) So i changed to the u-boot that comes with fedora 19 from hans, as I did all my previous work with that, and untarring of the extracted tarball works now. I have to make a deadline for my book (building the BSP, hence i bumped into this) and will do more compile/extraction tests in the next few days as time permits on hans's u-boot. I'll run some of ssvb's benchmarks to test various things. If this is all deemed stable; then it can only be u-boot that somehow broke. The only thing I can imagine is tolerances or power usage somehow. Speaking of, during the extraction power jumped from just under 0.5 amps @ 4.85V = idle; to about 0.85 amps @ 4.75V. Hmm, this might be caused by the FAST_MBUS stuff we've for A20 now a days. You could try removing FAST_MBUS from the boards.cfg config options for the cubietruck, and see how a recent u-boot build that way works. Oh and another thing to test is to try replacing your powersupply, if is dropping that far below 5V then likely it is also outputting quite a bit of noise and spikes on the powerline. Your battery won't help you there since the power likely is not far enough below 5V to make it switch, so the board keeps using the bad powersupply taking in all the noise and power spikes. While sensible, I doubt it, it's a high-end samsung charger; I could hook it up to my oscope and see how noise the line is. But the FAST_MBUS thing, yes I will tripple check that. A small update however, I ran a unpack, compile, rm -rf run and while it only managed to complete 37 loops in 24 hours, it completed them appearantly error free (I didn't check the entire log, just the last entry). So this u-boot runs fine and is stable. I will do the loop again (with less itterations) using fast-less u-boot. So far so good, it has run through a few loops which seem to work fine. So the Fast MBUS may not always work too well on all boards ... I'll let it run a bit longer, I'll get back to this tomorrow ... Olliver Olliver Regards, Hans -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Current u-boot crashes my cubietruck!
On 03/30/2014 08:56 PM, Olliver Schinagl wrote: On 03/30/2014 05:59 PM, Ian Campbell wrote: On Sun, 2014-03-30 at 14:26 +0200, Olliver Schinagl wrote: That said the sorts of random crashed you've been posting sound a lot like either a DRAM issue or overheating. Either of which could be down to u-boot setting up something wrong or bad hardware I suppose. Overheating, maybe. It feels hottish to the touch, but can hold a finger on it without any problem whatsoever. Not close to the pain point. So I estimate 50 C? Shouldn't be reason to be concerned imo. Doesn't sound like it. Power might be the problem, i see the input voltage under heavy load drop to 4.65 Volts @ 0.9 amps Could be that. Have you checked the checksum of the tarball you are extracting and tried unpacking it on a known good system? The sha1sum matches, calculated on the board, so that's good. xz -d completed successfully! tar xvf fails however, with a big ass 5 page long oops. I'd have thought that xz -d would be *far* more CPU intensive and therefore liable to cause issues than tar xvf. If you were using spinning rust rather than an SSD then I would be inclined to suspect the power draw, but with you using an SSD I'm just not sure. I agree! though even a heavily stressed CPU doesn't change power draw hugely. Ssvb and I did some power tests a few months ago on the list. Additionally! I should mention, my CT has a battery backup which should be near full charge. a 1220 mAh battery, so even if the power supply should drop to low or something, Wens assured me that the battery would take over and no problem should be caused by bad power. Unless the battery has run down of course, which I highly doubt, especially seeing the constant current draw over USB. So for now, I just hope it's not user error ... It is not, it is FAST_MBUS, the board is still happily compiling, 24 hours later, latest u-boot, but without FAST_MBUS. It managed to do about 43 compiles this time :) So for now, FAST_MBUS should be conciderd an 'overclocking option'. I'll try to enable it again;a nd maybe tune the voltage a little higher, then again; i don't have time fort hat right now ... Olliver Olliver Ian. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] sun6i SPL support status update
On 03/31/2014 08:27 AM, Chen-Yu Tsai wrote: Hi Hans, On Sun, Mar 30, 2014 at 8:04 PM, Hans de Goede hdego...@redhat.com wrote: Hi, After wens pointed me to: http://git.rhombus-tech.net/?p=u-boot.git;a=blob;f=arch/arm/cpu/armv7/sunxi/dram_sun6i.c;h=9275ca21ac99592c7d520a41c0914b359c27b913;hb=refs/heads/lichee/jb-4.2.2-a31 I've tried to get a full SPL going on sun6i. No luck sofar, dropping in dram_sun6i.[c,h] +pll5 config seems to get the dram going, at least get_ram_size() likes it. But I cannot get the mmc to work in the SPL. I've narrowed this down to 2 problems, which I believe are related: 1) The mmc controller will simply not work with pll6 as source, after adding a test for the pll6 lock bit I believe this is caused by pll6 never locking. 2) When switching the mmc controller clocksource to OSC24M, then it does work, but gets stuck reading the first sector from the card. I believe this happens because the card is only being supplied 3.0V' rather then 3.3V. Note that the same code works fine in the no SPL u-boot when loaded through boot0 + boot1. Likely wrong power supply voltages are the culprit in both cases (the A31 also has a vdd-pll power pin. So it looks like the next step is to first get the pmic going in u-boot (which will be useful even if booted through boot0 + 1, to enable the nic-phy if nothing else). The A23 lichee u-boot has drivers for P2WI (used in sun6i) and RSB (reduced serial bus, used on A23): Are they not the same? I haven't looked I admit, I just figured they changed the name a little to make it sound distinctive. Are they similar at all? If so, I guess that the i2c vs p2wi discussion held a few days ago is moot then :) Olliver https://github.com/wens/u-boot-sunxi/tree/lichee-dev-a23/drivers/p2wi https://github.com/wens/u-boot-sunxi/tree/lichee-dev-a23/drivers/rsb And also PMIC drivers: https://github.com/wens/u-boot-sunxi/tree/lichee-dev-a23/drivers/power Judging from the code, my guess is AXP221 and AXP223 or differ in the type of interface supported. Hope this helps. :) And then see from there. Maybe I'll take a shot at this tonight, for now I'm going to spend some time with my family. Cheers, 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.
