Re: [linux-sunxi] [ANNOUNCE] Allwinner releasing CedarX open source
Hi Kevin, Am 19.05.2015 um 02:44 schrieb ke...@allwinnertech.com: Hi All, We're proud to announce a new code release today for CedarX. Before delving into the details, I'd like to share some context: i'm glad to see, that AW tries to make a move in the right direction. Although steps are not finished. 1. As a growing company, we are doing our best to understand the needs of the open source software community. This is a learning process. We're working with different people across the Linux development community to better understand best practices. 2. Open source software development is a collaborative process. It works because people genuinely want to help others improve and be successful. Some people are new and others help them learn the ropes over time. We hope that this same positive feedback process can be applied to GPL. With that context, here's an update on our CedarX code release (we welcome constructive feedback!) 1. New code architecture. Driver has been split into several plugins, one plugin per video format. 2. GPL-complaint. We have scanned and analyzed the code to ensure that there is no GPL code used or called. 3. Partial CedarX video decoder source code release. MPEG2, MPEG4, MJPEG, and H264 drivers source code available. I wonder, if you guys have ever recognized http://linux-sunxi.org/VE_Register_guide or http://linux-sunxi.org/Cedrus from our community wiki. Most of the registers, that are needed to make the VE (MPEG1/2/4, H264) work without the recent source code drop or the old binaries, are known already - figured out by reverse engineering. So, i wonder, why there are still missing register descriptions. For example https://github.com/allwinner-zh/media-codec/blob/master/sunxi-cedarx/SOURCE/vdecoder/include/veregister.h#L193 , which are known to deal with the maf deinterlacer. We hope this is helpful to everyone. If not, please let us know how we can improve. Thanks! Although it's fine and essential to try to resolve the GPL issues by publishing the source code, another step to help the open source community will be to complete the register documentation, we already know in most parts anyway. In addition, there are missing some schematics about what versions of the VE is used within which SoC and what registers are available or have been altered. The user manuals are in genreal a good resource when someone wants to figure out sth about the registers, but the Video Engine is sadly completely missing there... Please also read the other thread https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg11469.html and think about the statements. Best Regards, kevin.z.m Regards Andreas NOTICE: This e-mail and any included attachments are intended only for the sole use of named and intended recipient (s) only. If you are the named and intended recipient, please note that the information contained in this email and its embedded files are confidential and privileged. If you are neither the intended nor named recipient, you are hereby notified that any unauthorized review, use, disclosure, dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. Please reply to the sender and destroy the original message and all your records of this message (whether electronic or otherwise). Furthermore, you should not disclose to any other person, use, copy or disseminate the contents of this e-mail and/or the documents accompanying it. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com 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] Re: [PATCH v2 04/10] pinctrl: sunxi: Prepare for building SoC specific drivers as modules
On Mon, May 18, 2015 at 11:32:31AM +0200, Jens Kuske wrote:
Hi,
On 05/17/15 16:19, Maxime Ripard wrote:
On Fri, May 15, 2015 at 06:38:54PM +0200, Jens Kuske wrote:
Add a remove function and export the init and remove function
to allow us to build the SoC specific drivers as modules.
Signed-off-by: Jens Kuske jensku...@gmail.com
---
drivers/pinctrl/sunxi/pinctrl-sunxi.c | 25 +++--
drivers/pinctrl/sunxi/pinctrl-sunxi.h | 2 ++
2 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
index f8e171b..4ef6b3d 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
@@ -856,7 +856,6 @@ int sunxi_pinctrl_init(struct platform_device *pdev,
struct sunxi_pinctrl *pctl;
struct resource *res;
int i, ret, last_pin;
- struct clk *clk;
pctl = devm_kzalloc(pdev-dev, sizeof(*pctl), GFP_KERNEL);
if (!pctl)
@@ -954,13 +953,13 @@ int sunxi_pinctrl_init(struct platform_device *pdev,
goto gpiochip_error;
}
- clk = devm_clk_get(pdev-dev, NULL);
- if (IS_ERR(clk)) {
- ret = PTR_ERR(clk);
+ pctl-clk = devm_clk_get(pdev-dev, NULL);
+ if (IS_ERR(pctl-clk)) {
+ ret = PTR_ERR(pctl-clk);
goto gpiochip_error;
}
- ret = clk_prepare_enable(clk);
+ ret = clk_prepare_enable(pctl-clk);
if (ret)
goto gpiochip_error;
@@ -1015,10 +1014,24 @@ int sunxi_pinctrl_init(struct platform_device
*pdev,
return 0;
clk_error:
- clk_disable_unprepare(clk);
+ clk_disable_unprepare(pctl-clk);
gpiochip_error:
gpiochip_remove(pctl-chip);
pinctrl_error:
pinctrl_unregister(pctl-pctl_dev);
return ret;
}
+EXPORT_SYMBOL(sunxi_pinctrl_init);
+
+int sunxi_pinctrl_remove(struct platform_device *pdev)
+{
+ struct sunxi_pinctrl *pctl = platform_get_drvdata(pdev);
+
+ gpiochip_remove(pctl-chip);
+ pinctrl_unregister(pctl-pctl_dev);
+
+ clk_disable_unprepare(pctl-clk);
We should also remove the domain and the interrupt mapping here.
Ouch, I missed that. Only looked at the *_error: labels.
Apart from that, currently the kernel panics some seconds after removing
the pinctrl module because mmc wants to access a gpio. Can this be
prevented somehow? I think pinctrl must not be removed once other
devices use any pin-related things.
pinctrl_unregister doesn't look like it cares about whether or not
there's users left in the system.
Maybe the easiest path would be to just make this builtin like Paul
suggested then ... :/
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: Digital signature
[linux-sunxi] Re: [PATCH v2 04/10] pinctrl: sunxi: Prepare for building SoC specific drivers as modules
On Tue, May 19, 2015 at 3:55 PM, Maxime Ripard
maxime.rip...@free-electrons.com wrote:
On Mon, May 18, 2015 at 11:32:31AM +0200, Jens Kuske wrote:
Hi,
On 05/17/15 16:19, Maxime Ripard wrote:
On Fri, May 15, 2015 at 06:38:54PM +0200, Jens Kuske wrote:
Add a remove function and export the init and remove function
to allow us to build the SoC specific drivers as modules.
Signed-off-by: Jens Kuske jensku...@gmail.com
---
drivers/pinctrl/sunxi/pinctrl-sunxi.c | 25 +++--
drivers/pinctrl/sunxi/pinctrl-sunxi.h | 2 ++
2 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
index f8e171b..4ef6b3d 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
@@ -856,7 +856,6 @@ int sunxi_pinctrl_init(struct platform_device *pdev,
struct sunxi_pinctrl *pctl;
struct resource *res;
int i, ret, last_pin;
- struct clk *clk;
pctl = devm_kzalloc(pdev-dev, sizeof(*pctl), GFP_KERNEL);
if (!pctl)
@@ -954,13 +953,13 @@ int sunxi_pinctrl_init(struct platform_device *pdev,
goto gpiochip_error;
}
- clk = devm_clk_get(pdev-dev, NULL);
- if (IS_ERR(clk)) {
- ret = PTR_ERR(clk);
+ pctl-clk = devm_clk_get(pdev-dev, NULL);
+ if (IS_ERR(pctl-clk)) {
+ ret = PTR_ERR(pctl-clk);
goto gpiochip_error;
}
- ret = clk_prepare_enable(clk);
+ ret = clk_prepare_enable(pctl-clk);
if (ret)
goto gpiochip_error;
@@ -1015,10 +1014,24 @@ int sunxi_pinctrl_init(struct platform_device
*pdev,
return 0;
clk_error:
- clk_disable_unprepare(clk);
+ clk_disable_unprepare(pctl-clk);
gpiochip_error:
gpiochip_remove(pctl-chip);
pinctrl_error:
pinctrl_unregister(pctl-pctl_dev);
return ret;
}
+EXPORT_SYMBOL(sunxi_pinctrl_init);
+
+int sunxi_pinctrl_remove(struct platform_device *pdev)
+{
+ struct sunxi_pinctrl *pctl = platform_get_drvdata(pdev);
+
+ gpiochip_remove(pctl-chip);
+ pinctrl_unregister(pctl-pctl_dev);
+
+ clk_disable_unprepare(pctl-clk);
We should also remove the domain and the interrupt mapping here.
Ouch, I missed that. Only looked at the *_error: labels.
Apart from that, currently the kernel panics some seconds after removing
the pinctrl module because mmc wants to access a gpio. Can this be
prevented somehow? I think pinctrl must not be removed once other
devices use any pin-related things.
pinctrl_unregister doesn't look like it cares about whether or not
there's users left in the system.
Maybe the easiest path would be to just make this builtin like Paul
suggested then ... :/
Is there a way to mark modules as not removable? At least we can keep
the multi-platform kernel image small.
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v2 02/10] clk: sunxi: Add support for multiple parents to gates
On Mon, May 18, 2015 at 11:11:34AM +0200, Jens Kuske wrote:
Hi,
On 05/17/15 14:50, Maxime Ripard wrote:
Hi Jens,
On Fri, May 15, 2015 at 06:38:52PM +0200, Jens Kuske wrote:
Some newer sunxi SoCs (A83T, H3) don't have individual registers for
AHB1, APB1 and APB2 gates anymore, but one big bus gates area where each
gate can have a different parent.
The current clock driver sets the same parent for all gates in a group.
This commit adds a new parents field to the gates_data structure, which
allows us to specify an array of parent indices for every single gate.
Signed-off-by: Jens Kuske jensku...@gmail.com
---
drivers/clk/sunxi/clk-sunxi.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 9a82f17..17cba4d 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -898,6 +898,8 @@ static void __init sunxi_divider_clk_setup(struct
device_node *node,
struct gates_data {
DECLARE_BITMAP(mask, SUNXI_GATES_MAX_SIZE);
+ /* If used, ARRAY_SIZE(parents) has to be = bitmap_weight(mask) */
+ const u8 *parents;
};
static const struct gates_data sun4i_axi_gates_data __initconst = {
@@ -1000,16 +1002,21 @@ static void __init sunxi_gates_clk_setup(struct
device_node *node,
struct gates_data *data)
{
struct clk_onecell_data *clk_data;
+ const char *parents[SUNXI_MAX_PARENTS];
const char *clk_parent;
const char *clk_name;
void __iomem *reg;
+ int npar = 0;
int qty;
int i = 0;
int j = 0;
reg = of_iomap(node, 0);
- clk_parent = of_clk_get_parent_name(node, 0);
+ while (npar SUNXI_MAX_PARENTS
+ (parents[npar] = of_clk_get_parent_name(node, npar)) != NULL)
+ npar++;
+ clk_parent = parents[0];
/* Worst-case size approximation and memory allocation */
qty = find_last_bit(data-mask, SUNXI_GATES_MAX_SIZE);
@@ -1026,6 +1033,9 @@ static void __init sunxi_gates_clk_setup(struct
device_node *node,
of_property_read_string_index(node, clock-output-names,
j, clk_name);
+ if (data-parents !WARN_ON(data-parents[j] = npar))
+ clk_parent = parents[data-parents[j]];
+
I'm currently removing that code, so I was more expecting a new
standalone driver for that clock.
How do you want to replace that code? To me this looks like a good way
to set up all the different gates sunxi has.
By using clock-indices and moving all this gate stuff out of clk-sunxi
and into a new driver.
It's done already, I just need to make sure everything works at it
used to on all the SoCs.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: Digital signature
Re: [linux-sunxi] [ANNOUNCE] Allwinner releasing CedarX open source
On Tue, May 19, 2015 at 08:44:13AM +0800, ke...@allwinnertech.com wrote: Hi All, We're proud to announce a new code release today for CedarX. Before delving into the details, I'd like to share some context: 1. As a growing company, we are doing our best to understand the needs of the open source software community. This is a learning process. We're working with different people across the Linux development community to better understand best practices. 2. Open source software development is a collaborative process. It works because people genuinely want to help others improve and be successful. Some people are new and others help them learn the ropes over time. We hope that this same positive feedback process can be applied to GPL. With that context, here's an update on our CedarX code release (we welcome constructive feedback!) 1. New code architecture. Driver has been split into several plugins, one plugin per video format. 2. GPL-complaint. We have scanned and analyzed the code to ensure that there is no GPL code used or called. 3. Partial CedarX video decoder source code release. MPEG2, MPEG4, MJPEG, and H264 drivers source code available. We hope this is helpful to everyone. If not, please let us know how we can improve. Thanks! This is a good first step, not only to try to meet some legal obligations, but also to support Allwinners customers and the sunxi community. But... The choice of exactly those codecs for a first(?) release, the fact that you underline the use of a code scanner/analyzer, and then the fact that Allwinner chose to turn this into a modular design with codecs as modules... All that seems to hint at Allwinner intending to keep upcoming modules as binaries. If this happens, not only will that be another massive marketing setback for Allwinner, but we will push the legal limits hard and force a full release of the source code of all binaries that allwinner has released so far. As said countless times before, the LGPL applies to the whole of the binaries Allwinner released before, not just those codecs where LGPLed code was used. 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] A20 with Samsung's SDRAM 'K4B1G1646G BCK0'
Hi, On 19-05-15 12:56, sufi al hussaini hassani kamili raheemi wrote: I have a board that's got A20 with Samsung's SDRAM 'K4B1G1646G BCK0'. The problem I'm facing now is that I'm not able to get it to boot. I keep getting the following on debug UART: U-Boot SPL 2014.04-10706-g36080eb (Aug 19 2014 - 16:42:16) That is a pretty old u-boot we're doing all sunxi u-boot development upstream now: http://git.denx.de/?p=u-boot.git;a=summary And we are detecting the most important DRAM parameters (like bus-width) automatically now. The only thing you need to set really is the clock-speed. So I think that giving upstream u-boot a try on your board is a good idea. Regards, Hans DRAM:Timeout initialising DRAM resetting ... (Repeats infinitely) I suspected that the (old) '[dram_para]' in my FEX file was causing this, as it was configured for 'K4B4G1646D' (which is widely used). So, I edited the FEX file based on the info I could gather from the SDRAM's datasheet. It now looks like this: [dram_para] dram_baseaddr = 0x4000 dram_clk = 384 dram_type = 3 dram_rank_num = 1 dram_chip_density = 1024 dram_io_width = 16 dram_bus_width = 32 dram_cas = 9 dram_zq = 0x7f dram_odt_en = 0 dram_size = 256 dram_tpr0 = 0x42d899b7 dram_tpr1 = 0xa090 dram_tpr2 = 0x22a00 dram_tpr3 = 0x0 dram_tpr4 = 0x0 dram_tpr5 = 0x0 dram_emr1 = 0x4 dram_emr2 = 0x10 dram_emr3 = 0x0 I tried booting with this but to no avail. The problem persists (same error). I looked for ways to get the DRAM info directly from the hardware and found meminfo in sunxi tools. I was able to compile (and run) it (on a A20 based commercial board), but I just can't figure out how to get it running on my board. Now, I'm confused- whether just setting the correct values in my FEX would suffice or would I have to rebuild U-Boot. I would appreciate if someone could point me in the right direction to solve this problem. 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] Re: Request for detaild for GSL1680 driver for porting to Linux x86_64 kernel on baytrail 3735f platform
The problem is that there is usually NOAndroid kernel for device, for example Chuwi vi8 super with its plarform (vendor) drivers and platform initial settings. Actually I have found of the way how to detect corresponding gpio pin but it is manual (scripted + manual) guessing (enumerating). Moreover from kenel to kernel this is different gpio pin number. I still could not fix it how to immediately find out which exactly pin inside Z3735F architecture is used and how to find out it's number in any linux kernelю Currently - I just enumerating all on concrete linux kernel and for each kernel finding out its number - :( this is ridiculous but its works! Regards, Serge. On Tuesday, May 19, 2015 at 10:58:21 AM UTC+3, Henrik Nordström wrote: fre 2015-05-15 klockan 18:40 -0400 skrev jons...@gmail.com javascript:: Another way - hook up JTAG. Use boundary scan to toggle the pins. That will tell you the pin number. Look up the pin number and figure out the GPIO. Or look at the source of the Android kernel running on the device for any hints. Regards Henrik -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: New firmware for GSL1680
Thank you for make it clear. ;-) Lets transform this knowledge into practical result! I have successfully compiled i2c-tools for x86 Android. So, what is the exact command line to grab all loaded into GSL 1680 chip firmware? i2cbus or i2cget? and how to use it , How via this toolset I could enumerate all 256 chunks of 128 bytes using information that chip resides on 0x40 I2c adress, dev is /dev/i2c-3, Page register is 0xF0 (8 bit too, so holds 256 addresses) and registers that store current 128 chunk are 0x00-0x7F Cheers, Serge. On Tuesday, May 19, 2015 at 1:48:14 PM UTC+3, Michal Suchanek wrote: On 19 May 2015 at 12:36, sergk...@gmail.com javascript: wrote: On Tuesday, May 19, 2015 at 12:53:43 PM UTC+3, Michal Suchanek wrote: That's one page of the configuration which is 128 bytes or 32 integers. Writing the page register gives access (read or write) to different pages. So one blob might have multiple such pages or the firmware can be composed of multiple pages stored in multiple blobs Still not clear - where does stored these blobs? 0x00-0x7F = 128 items 128 * x =1 byte registers. So physically chip could reside only 128 byte. 0xF0: PAGE register. Contains the memory page number currently mapped in the 0x00-0x7F registers. What is logic of these Page register and 0x00-0x7F registers? Am I right that firmware is loaded into ram splitted by 128 byte pages and 0xF0 register contains a set of adressed in RAM of such 128 byte chunks? Yes, that's what the datasheet says. F0 stores a page number and each page has different set of registers to map to 00-7F. The chip has more memory than can be accessible through i2c at any given time due to the i2c 1 byte address limit so it uses paging to make more data accessible. 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/d/optout.
[linux-sunxi] Re: A20 with Samsung's SDRAM 'K4B1G1646G BCK0'
Thanks for the guidance @Hans. I'm trying to build Mainline U-Boot http://linux-sunxi.org/Mainline_U-boot now. Will post my progress here. On Tuesday, May 19, 2015 at 2:56:30 PM UTC+4, sufi al hussaini hassani kamili raheemi wrote: I have a board that's got A20 with Samsung's SDRAM 'K4B1G1646G BCK0'. The problem I'm facing now is that I'm not able to get it to boot. I keep getting the following on debug UART: U-Boot SPL 2014.04-10706-g36080eb (Aug 19 2014 - 16:42:16) DRAM:Timeout initialising DRAM resetting ... (Repeats infinitely) I suspected that the (old) '[dram_para]' in my FEX file was causing this, as it was configured for 'K4B4G1646D' (which is widely used). So, I edited the FEX file based on the info I could gather from the SDRAM's datasheet. It now looks like this: [dram_para] dram_baseaddr = 0x4000 dram_clk = 384 dram_type = 3 dram_rank_num = 1 dram_chip_density = 1024 dram_io_width = 16 dram_bus_width = 32 dram_cas = 9 dram_zq = 0x7f dram_odt_en = 0 dram_size = 256 dram_tpr0 = 0x42d899b7 dram_tpr1 = 0xa090 dram_tpr2 = 0x22a00 dram_tpr3 = 0x0 dram_tpr4 = 0x0 dram_tpr5 = 0x0 dram_emr1 = 0x4 dram_emr2 = 0x10 dram_emr3 = 0x0 I tried booting with this but to no avail. The problem persists (same error). I looked for ways to get the DRAM info directly from the hardware and found meminfo in sunxi tools. I was able to compile (and run) it (on a A20 based commercial board), but I just can't figure out how to get it running on my board. Now, I'm confused- whether just setting the correct values in my FEX would suffice or would I have to rebuild U-Boot. I would appreciate if someone could point me in the right direction to solve this problem. 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] Re: New firmware for GSL1680
On 19 May 2015 at 11:39, sergk.ad...@gmail.com wrote: Sorry but your post makes it more weird. According https://linux-sunxi.org/GSL1680 page GSL1680 controller stores Firmware in 0x00-0x7F: these registers are used to load portions of the firmware This is only 128 8bit = 1byte registers. So main question is - does this registers = 128 1 byte registers store the whole firmware? That's one page of the configuration which is 128 bytes or 32 integers. Writing the page register gives access (read or write) to different pages. So one blob might have multiple such pages or the firmware can be composed of multiple pages stored in multiple blobs. Also there is nothing stopping the driver writing the registers again after sending the blob patching/adjusting some values or leaving them out from the blob and sending them separately. What is the logic of working of controller chip with firmware? For example = why when I am loading firmware Silead.fw taken from my tablet from Windows 8.1 with ported Sergio Costas user space driver for GSL1680 I could not get correct feedback (coordinates that are read from 0x84-0x87 ) for my 1280x800 touch? I have response for all but not 1280x800, acrtually weird coordinates like 1725x1120 or something close. The logic is that with the chip configurable you can save on PCB design because you can design traces as convenient and configure which trace connects where in firmware. The obvious result is that without correct configuration the chip is useless so dumb non-configurable chips are a win when dealing with non-cooperative vendors. 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/d/optout.
Re: [linux-sunxi] Re: New firmware for GSL1680
On Tuesday, May 19, 2015 at 12:53:43 PM UTC+3, Michal Suchanek wrote: That's one page of the configuration which is 128 bytes or 32 integers. Writing the page register gives access (read or write) to different pages. So one blob might have multiple such pages or the firmware can be composed of multiple pages stored in multiple blobs Still not clear - where does stored these blobs? 0x00-0x7F = 128 items 128 * x =1 byte registers. So physically chip could reside only 128 byte. 0xF0: PAGE register. Contains the memory page number currently mapped in the 0x00-0x7F registers. What is logic of these Page register and 0x00-0x7F registers? Am I right that firmware is loaded into ram splitted by 128 byte pages and 0xF0 register contains a set of adressed in RAM of such 128 byte chunks? -- 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: New firmware for GSL1680
On 19 May 2015 at 12:36, sergk.ad...@gmail.com wrote: On Tuesday, May 19, 2015 at 12:53:43 PM UTC+3, Michal Suchanek wrote: That's one page of the configuration which is 128 bytes or 32 integers. Writing the page register gives access (read or write) to different pages. So one blob might have multiple such pages or the firmware can be composed of multiple pages stored in multiple blobs Still not clear - where does stored these blobs? 0x00-0x7F = 128 items 128 * x =1 byte registers. So physically chip could reside only 128 byte. 0xF0: PAGE register. Contains the memory page number currently mapped in the 0x00-0x7F registers. What is logic of these Page register and 0x00-0x7F registers? Am I right that firmware is loaded into ram splitted by 128 byte pages and 0xF0 register contains a set of adressed in RAM of such 128 byte chunks? Yes, that's what the datasheet says. F0 stores a page number and each page has different set of registers to map to 00-7F. The chip has more memory than can be accessible through i2c at any given time due to the i2c 1 byte address limit so it uses paging to make more data accessible. 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/d/optout.
Re: [linux-sunxi] [ANNOUNCE] Allwinner releasing CedarX open source
On Tue, 19 May 2015 08:44:13 +0800 ke...@allwinnertech.com ke...@allwinnertech.com wrote: 3. Partial CedarX video decoder source code release. MPEG2, MPEG4, MJPEG, and H264 drivers source code available. And for the others codecs, what are allwinner plans? Should we expect for them to also be released, and which and in what time frame should be this expected to happen? This would be a very useful information to have, because this would help us decide if we also have to reverse engineering h265, or only wait for your release. As h265 is the next much wished codec to have, is certain it will be reversed engineered if allwinner takes too long. Don't forget that, VP8 decoding, h264 encoding, jpeg encoding, was also successful reversed engineered. This is only to tell that, it is hardware documentation that we are interested in, not the software in the form of your cedarx library. We hope this is helpful to everyone. If not, please let us know how we can improve. Thanks! In the socs datasheets, in the video engine features description, it has as feature alpha bending. Can we have more information what is mean by this. I tried my guess by poking random isp subengine registers but only we could find is at the wiki page. http://linux-sunxi.org/VE_Register_guide#ISP_Engine_Registers If this is what it appears to be, then this would be very useful for subtitles/osd, because if the bending can occur in the video engine, then this is optimal in the performance point of view. -- Manuel Braga -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v2 07/10] pinctrl: sunxi: Add H3 PIO controller support
On Fri, May 15, 2015 at 6:38 PM, Jens Kuske jensku...@gmail.com wrote: The H3 uses the same pin controller as previous SoC's from Allwinner. Add support for the pins controlled by the main PIO controller. Signed-off-by: Jens Kuske jensku...@gmail.com Waiting for Maxime's ACKs on these patches before merging. Yours, Linus Walleij -- 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] [ANNOUNCE] Allwinner releasing CedarX open source
1. New code architecture. Driver has been split into several plugins, one plugin per video format. 2. GPL-complaint. We have scanned and analyzed the code to ensure that there is no GPL code used or called. 3. Partial CedarX video decoder source code release. MPEG2, MPEG4, MJPEG, and H264 drivers source code available. Thanks a lot, guys, for your hard work! Ayeee, I'm dancing in circles! Looking forward for next steps. We hope this is helpful to everyone. If not, please let us know how we can improve. Thanks! -- Best Regards, kevin.z.m NOTICE: This e-mail and any included attachments are intended only for the sole use of named and intended recipient (s) only. If you are the named and intended recipient, please note that the information contained in this email and its embedded files are confidential and privileged. If you are neither the intended nor named recipient, you are hereby notified that any unauthorized review, use, disclosure, dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. Please reply to the sender and destroy the original message and all your records of this message (whether electronic or otherwise). Furthermore, you should not disclose to any other person, use, copy or disseminate the contents of this e-mail and/or the documents accompanying it. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- 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: A20 with Samsung's SDRAM 'K4B1G1646G BCK0'
Has anyone tried this specific DRAM (Samsung's SDRAM 'K4B1G1646G BCK0')? I was wondering if someone could provide me with '[dram_para]' for the FEX file for this specific RAM. Thanks. On Tuesday, May 19, 2015 at 2:56:30 PM UTC+4, sufi al hussaini hassani kamili raheemi wrote: I have a board that's got A20 with Samsung's SDRAM 'K4B1G1646G BCK0'. The problem I'm facing now is that I'm not able to get it to boot. I keep getting the following on debug UART: U-Boot SPL 2014.04-10706-g36080eb (Aug 19 2014 - 16:42:16) DRAM:Timeout initialising DRAM resetting ... (Repeats infinitely) I suspected that the (old) '[dram_para]' in my FEX file was causing this, as it was configured for 'K4B4G1646D' (which is widely used). So, I edited the FEX file based on the info I could gather from the SDRAM's datasheet. It now looks like this: [dram_para] dram_baseaddr = 0x4000 dram_clk = 384 dram_type = 3 dram_rank_num = 1 dram_chip_density = 1024 dram_io_width = 16 dram_bus_width = 32 dram_cas = 9 dram_zq = 0x7f dram_odt_en = 0 dram_size = 256 dram_tpr0 = 0x42d899b7 dram_tpr1 = 0xa090 dram_tpr2 = 0x22a00 dram_tpr3 = 0x0 dram_tpr4 = 0x0 dram_tpr5 = 0x0 dram_emr1 = 0x4 dram_emr2 = 0x10 dram_emr3 = 0x0 I tried booting with this but to no avail. The problem persists (same error). I looked for ways to get the DRAM info directly from the hardware and found meminfo in sunxi tools. I was able to compile (and run) it (on a A20 based commercial board), but I just can't figure out how to get it running on my board. Now, I'm confused- whether just setting the correct values in my FEX would suffice or would I have to rebuild U-Boot. I would appreciate if someone could point me in the right direction to solve this problem. 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.
[linux-sunxi] Re: [PATCH v2 07/10] pinctrl: sunxi: Add H3 PIO controller support
On Tue, May 19, 2015 at 04:04:58PM +0200, Linus Walleij wrote: On Fri, May 15, 2015 at 6:38 PM, Jens Kuske jensku...@gmail.com wrote: The H3 uses the same pin controller as previous SoC's from Allwinner. Add support for the pins controlled by the main PIO controller. Signed-off-by: Jens Kuske jensku...@gmail.com Waiting for Maxime's ACKs on these patches before merging. There's still the modules issue being debated on another patch of this serie, so there will probably be a v3 of these patches. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
Re: [linux-sunxi] [ANNOUNCE] Allwinner releasing CedarX open source
On Tue, 19 May 2015 08:44:13 +0800 ke...@allwinnertech.com ke...@allwinnertech.com wrote: 2. Open source software development is a collaborative process. It works because people genuinely want to help others improve and be successful. Some people are new and others help them learn the ropes over time. We hope that this same positive feedback process can be applied to GPL. I am sorry, but i find curious the reference here to the GPL license. In order of Some people are new and others help them learn the ropes over time., i will try to explain. This, have nothing to do with any particular license. The GPL license is only the most known and used copyleft license, and by being so, is the license that is more talked about. And by this, it happened to be the license(LGPL) involved in ours license issues. It would happened with any other license, the problems are the existence of the issues by itself. The key point here, is that the existence of the issues is a disrespect towards the developers that wrote those same software source code, and in some cases did without paid and in their free time. And is not with license issues that allwinner or any other will attract the contribution of open source developers. -- Manuel Braga -- 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: A20 with Samsung's SDRAM 'K4B1G1646G BCK0'
I tried building mainline u-boot as you suggested @Hans. Here's what I did (please bear with me): Compiled u-boot (natively on olimex A20-micro): (Installed dtc first) git clone git://git.denx.de/u-boot.git make A20-OLinuXino_MICRO_defconfig make Wrote the bootloader files to an SD card using: sudo dd if=~/u-boot/u-boot.bin of=/dev/disk2 bs=1024 seek=32 sudo dd if=~/u-boot/spl/sunxi-spl.bin of=/dev/disk2 bs=1024 seek=8 However, I still (sadly) get the same error. U-Boot SPL 2015.07-rc1-00255-g0e6b7a2 (May 19 2015 - 16:55:13) DRAM:Timeout initialising DRAM As seen above, this is a recent U-Boot version, so I'm guessing I did compile the U-Boot alright. But, the problem persists and I've run out of ideas. Any other suggestions? Could there be any other reason (apart from DRAM parameters) that could be causing this? Thanks and regards, Shoaib. On Tuesday, May 19, 2015 at 2:56:30 PM UTC+4, sufi al hussaini hassani kamili raheemi wrote: I have a board that's got A20 with Samsung's SDRAM 'K4B1G1646G BCK0'. The problem I'm facing now is that I'm not able to get it to boot. I keep getting the following on debug UART: U-Boot SPL 2014.04-10706-g36080eb (Aug 19 2014 - 16:42:16) DRAM:Timeout initialising DRAM resetting ... (Repeats infinitely) I suspected that the (old) '[dram_para]' in my FEX file was causing this, as it was configured for 'K4B4G1646D' (which is widely used). So, I edited the FEX file based on the info I could gather from the SDRAM's datasheet. It now looks like this: [dram_para] dram_baseaddr = 0x4000 dram_clk = 384 dram_type = 3 dram_rank_num = 1 dram_chip_density = 1024 dram_io_width = 16 dram_bus_width = 32 dram_cas = 9 dram_zq = 0x7f dram_odt_en = 0 dram_size = 256 dram_tpr0 = 0x42d899b7 dram_tpr1 = 0xa090 dram_tpr2 = 0x22a00 dram_tpr3 = 0x0 dram_tpr4 = 0x0 dram_tpr5 = 0x0 dram_emr1 = 0x4 dram_emr2 = 0x10 dram_emr3 = 0x0 I tried booting with this but to no avail. The problem persists (same error). I looked for ways to get the DRAM info directly from the hardware and found meminfo in sunxi tools. I was able to compile (and run) it (on a A20 based commercial board), but I just can't figure out how to get it running on my board. Now, I'm confused- whether just setting the correct values in my FEX would suffice or would I have to rebuild U-Boot. I would appreciate if someone could point me in the right direction to solve this problem. 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.
[linux-sunxi] Re: [PATCH v2 04/10] pinctrl: sunxi: Prepare for building SoC specific drivers as modules
On Tue, May 19, 2015 at 9:55 AM, Maxime Ripard maxime.rip...@free-electrons.com wrote: Apart from that, currently the kernel panics some seconds after removing the pinctrl module because mmc wants to access a gpio. Can this be prevented somehow? I think pinctrl must not be removed once other devices use any pin-related things. pinctrl_unregister doesn't look like it cares about whether or not there's users left in the system. Both GPIO and pinctrl has this problem, Johan Hovold has been looking at fixing the GPIO side of things. Patches welcome. Yours, Linus Walleij -- 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: A20 with Samsung's SDRAM 'K4B1G1646G BCK0'
On Tue, 19 May 2015 08:20:24 -0700 (PDT) sufi al hussaini hassani kamili raheemi sufialhussa...@gmail.com wrote: Has anyone tried this specific DRAM (Samsung's SDRAM 'K4B1G1646G BCK0')? Regarding the has anyone tried part of the question, this particular DDR3 chip does not seem to be very popular, according to the information from http://linux-sunxi.org/DDR3 However this should not be a problem and DRAM should work just fine. Assuming that the board itself is not defective. I was wondering if someone could provide me with '[dram_para]' for the FEX file for this specific RAM. The FEX file is not used by U-Boot at all. All the DRAM parameters are configured in the U-Boot defconfig files. And this is explained at: http://linux-sunxi.org/Mainline_U-boot#DRAM_Settings The http://linux-sunxi.org/Fex_Guide#SDRAM section probably needs to be adjusted and explicitly say that you don't want to touch this stuff unless using the Allwinner's boot0 bootloader and/or livesuit. If there is some other part of the wiki with misleading information, please let us know. -- Best regards, Siarhei Siamashka Thanks. On Tuesday, May 19, 2015 at 2:56:30 PM UTC+4, sufi al hussaini hassani kamili raheemi wrote: I have a board that's got A20 with Samsung's SDRAM 'K4B1G1646G BCK0'. The problem I'm facing now is that I'm not able to get it to boot. I keep getting the following on debug UART: U-Boot SPL 2014.04-10706-g36080eb (Aug 19 2014 - 16:42:16) DRAM:Timeout initialising DRAM resetting ... (Repeats infinitely) I suspected that the (old) '[dram_para]' in my FEX file was causing this, as it was configured for 'K4B4G1646D' (which is widely used). So, I edited the FEX file based on the info I could gather from the SDRAM's datasheet. It now looks like this: [dram_para] dram_baseaddr = 0x4000 dram_clk = 384 dram_type = 3 dram_rank_num = 1 dram_chip_density = 1024 dram_io_width = 16 dram_bus_width = 32 dram_cas = 9 dram_zq = 0x7f dram_odt_en = 0 dram_size = 256 dram_tpr0 = 0x42d899b7 dram_tpr1 = 0xa090 dram_tpr2 = 0x22a00 dram_tpr3 = 0x0 dram_tpr4 = 0x0 dram_tpr5 = 0x0 dram_emr1 = 0x4 dram_emr2 = 0x10 dram_emr3 = 0x0 I tried booting with this but to no avail. The problem persists (same error). I looked for ways to get the DRAM info directly from the hardware and found meminfo in sunxi tools. I was able to compile (and run) it (on a A20 based commercial board), but I just can't figure out how to get it running on my board. Now, I'm confused- whether just setting the correct values in my FEX would suffice or would I have to rebuild U-Boot. I would appreciate if someone could point me in the right direction to solve this problem. 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] Re: A20 with Samsung's SDRAM 'K4B1G1646G BCK0'
On Tue, 19 May 2015 07:57:19 -0700 (PDT) sufi al hussaini hassani kamili raheemi sufialhussa...@gmail.com wrote: I tried building mainline u-boot as you suggested @Hans. Here's what I did (please bear with me): Compiled u-boot (natively on olimex A20-micro): (Installed dtc first) git clone git://git.denx.de/u-boot.git make A20-OLinuXino_MICRO_defconfig make So you have an A20-OLinuXino_MICRO board, which is working fine. That's very good. Using it you can learn quite a lot about the Allwinner hardware in general. And this experience should help with the other boards. Wrote the bootloader files to an SD card using: sudo dd if=~/u-boot/u-boot.bin of=/dev/disk2 bs=1024 seek=32 sudo dd if=~/u-boot/spl/sunxi-spl.bin of=/dev/disk2 bs=1024 seek=8 However, I still (sadly) get the same error. U-Boot SPL 2015.07-rc1-00255-g0e6b7a2 (May 19 2015 - 16:55:13) DRAM:Timeout initialising DRAM As seen above, this is a recent U-Boot version, so I'm guessing I did compile the U-Boot alright. Your U-Boot is configured for the A20-OLinuXino_MICRO board. Does the A20-OLinuXino_MICRO board boot fine with this new freshly compiled mainline U-Boot? Using the A20-OLinuXino_MICRO config for a different Allwinner based board may lead to unpredictable results. Each board has its own defconfig file for a reason. You need to provide a proper defconfig file for your board. To help people to succeed in this task, there is a guide about bringing up new and previously unsupported devices: http://linux-sunxi.org/New_Device_howto But, the problem persists and I've run out of ideas. Any other suggestions? Could there be any other reason (apart from DRAM parameters) that could be causing this? Based on the Timeout initialising DRAM error message, this is often encountered when you have configured U-Boot for the wrong SoC type. Is your board really using specifically the *A20* SoC? And as an extra experiment, you may also try: https://github.com/ssvb/sunxi-bootsetup/releases/tag/20141215-sunxi-bootsetup-prototype If your board is really A10, A10s or A20 (and the hardware is not defective), then you may successfully boot it with this SD card image. -- Best regards, Siarhei Siamashka -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
