[linux-sunxi] Re: [PATCH 2/2] ARM: dts: sunxi: Remove overclocked/overvoltaged OPP
On Thu, Mar 19, 2015 at 2:59 PM, Siarhei Siamashka siarhei.siamas...@gmail.com wrote: On Thu, 19 Mar 2015 10:39:33 +0800 Chen-Yu Tsai w...@csie.org wrote: Without proper regulator support for individual boards, it is dangerous to have overclocked/overvoltaged OPPs in the list. Cpufreq will increase the frequency without the accompanying voltage increase, resulting in an unstable system. Remove them for now. We can revisit them with the new version of OPP bindings, which support boost settings and frequency ranges, among other things. Signed-off-by: Chen-Yu Tsai w...@csie.org --- arch/arm/boot/dts/sun5i-a13.dtsi | 3 +-- arch/arm/boot/dts/sun7i-a20.dtsi | 3 +-- 2 files changed, 2 insertions(+), 4 deletions(-) What about the sun4i-a10.dtsi file? Was it forgotten or skipped deliberately? sun4i-a10.dtsi does not have any overclocked/overvoltaged settings. The highest setting is 1008MHz @ 1.4V. ChenYu -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH 1/2] ARM: dts: sun4i: a10-lime: Override and remove 1008MHz OPP setting
On Thu, 19 Mar 2015 10:39:32 +0800
Chen-Yu Tsai w...@csie.org wrote:
The Olimex A10-Lime is known to be unstable when running at 1008MHz.
Signed-off-by: Chen-Yu Tsai w...@csie.org
---
arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts
b/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts
index 31dc2f1c3870..16ecb8938e19 100644
--- a/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts
+++ b/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts
@@ -74,6 +74,20 @@
status = okay;
};
+cpu0 {
+ /* The A10-Lime is known to be unstable when running at 1008 MHz */
+ operating-points =
+ /* kHzuV */
+ 96 140
+ 912000 140
+ 864000 130
+ 72 120
+ 528000 110
+ 312000 100
+ 144000 90
+ ;
+};
+
ehci0 {
status = okay;
};
Thanks for the patch. At least it should make my A10-OLinuXino-LIME
working without obvious failures out of the box (the U-Boot is still
another story though and there is a gap during boot up when the board
is running with unreliable settings, but the probability of a failure
is rather low).
I should also mention that using 960MHz @1.4V does not fail, but it does
not have any safety headroom either (the cyan 'sun4i_poorlime' line
on the plot):
http://people.freedesktop.org/~siamashka/files/20140512/sunxi-cpufreq-plot.png
On the other hand, my board is on the worst part of the spectrum (many
other a10-lime boards do not fail even at 1008MHz), so maybe having
extra safety headroom is less necessary.
An interesting question is whether the same problem may be reproducible
on the Allwinner A10 devices other than A10-OLinuXino-LIME. My original
problem report
https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg04343.html
mentioned the A10-OLinuXino-LIME rev.A and introduced some sort of
a bias by itself. At least I have seen people saying something like
my a10-lime revision is not rev.A, so it's none of my concern and
I'm not going to bother running any tests. So far we have accumulated
reports from 4 or 5 people having this reliability problem on their
A10-OLinuXino-LIME (various revisions, not just rev.A), but not
much from the other boards owners.
Anyway, this particular patch is
Tested-by: Siarhei Siamashka siarhei.siamas...@gmail.com
Acked-by: Siarhei Siamashka siarhei.siamas...@gmail.com
--
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.
[linux-sunxi] Re: [PATCH 2/2] ARM: dts: sunxi: Remove overclocked/overvoltaged OPP
On Thu, 19 Mar 2015 10:39:33 +0800 Chen-Yu Tsai w...@csie.org wrote: Without proper regulator support for individual boards, it is dangerous to have overclocked/overvoltaged OPPs in the list. Cpufreq will increase the frequency without the accompanying voltage increase, resulting in an unstable system. Remove them for now. We can revisit them with the new version of OPP bindings, which support boost settings and frequency ranges, among other things. Signed-off-by: Chen-Yu Tsai w...@csie.org --- arch/arm/boot/dts/sun5i-a13.dtsi | 3 +-- arch/arm/boot/dts/sun7i-a20.dtsi | 3 +-- 2 files changed, 2 insertions(+), 4 deletions(-) What about the sun4i-a10.dtsi file? Was it forgotten or skipped deliberately? -- 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.
[linux-sunxi] Re: [PATCH 2/2] ARM: dts: sunxi: Remove overclocked/overvoltaged OPP
On Thu, Mar 19, 2015 at 3:11 PM, Chen-Yu Tsai w...@csie.org wrote: On Thu, Mar 19, 2015 at 2:59 PM, Siarhei Siamashka siarhei.siamas...@gmail.com wrote: On Thu, 19 Mar 2015 10:39:33 +0800 Chen-Yu Tsai w...@csie.org wrote: Without proper regulator support for individual boards, it is dangerous to have overclocked/overvoltaged OPPs in the list. Cpufreq will increase the frequency without the accompanying voltage increase, resulting in an unstable system. Remove them for now. We can revisit them with the new version of OPP bindings, which support boost settings and frequency ranges, among other things. Signed-off-by: Chen-Yu Tsai w...@csie.org --- arch/arm/boot/dts/sun5i-a13.dtsi | 3 +-- arch/arm/boot/dts/sun7i-a20.dtsi | 3 +-- 2 files changed, 2 insertions(+), 4 deletions(-) What about the sun4i-a10.dtsi file? Was it forgotten or skipped deliberately? sun4i-a10.dtsi does not have any overclocked/overvoltaged settings. The highest setting is 1008MHz @ 1.4V. Oops. Sorry. I missed it. Will send v2. ChenYu -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [PATCH 2/3] ARM: sun8i: Add SMP support for the Allwinner A23
One question I couldn't find any answer to is that does the SMP bit is
set in secondary_startup?
I couldn't find where it was set, but it still looks like the right
thing to do, so I would expect the code to do that.
I don't see it either. The sun8i code is just the sun6i code with the
power clamps removed. And sun6i secondary_startup was removed some time
ago in commit 1146b600044d (ARM: sunxi: fix build for THUMB2_KERNEL).
ChenYu
The SMP bit should be set in the function of __v7_ca7mp_setup, which is
located
in the file:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/mm/proc-v7.S?id=refs/tags/v4.0-rc4
I'm not sure if this is your discussion.
Best Regards,
kevin.z.m...@gmail.com
From: Chen-Yu Tsai
Date: 2015-03-19 10:07
To: Maxime Ripard
CC: Chen-Yu Tsai; linux-arm-kernel; linux-kernel; linux-sunxi; Marc Zyngier
Subject: [linux-sunxi] Re: [PATCH 2/3] ARM: sun8i: Add SMP support for the
Allwinner A23
On Wed, Mar 18, 2015 at 6:29 PM, Maxime Ripard
maxime.rip...@free-electrons.com wrote:
On Wed, Mar 18, 2015 at 11:24:01AM +0800, Chen-Yu Tsai wrote:
The A23 is a dual Cortex-A7. Add the logic to use the IPs used to
control the CPU configuration and the CPU power so that we can
bring up secondary CPUs at boot.
Signed-off-by: Chen-Yu Tsai w...@csie.org
---
We can't use of_io_request_and_map() here, as it will conflict
with PRCM, and leave us without a serial console.
I think a proper way to solve this would be a syscon device or
something like the mfd-simple device posted by Arnd.
---
Documentation/devicetree/bindings/arm/cpus.txt | 1 +
arch/arm/mach-sunxi/platsmp.c | 69
++
2 files changed, 70 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/cpus.txt
b/Documentation/devicetree/bindings/arm/cpus.txt
index 8b9e0a95de31..40202d85b132 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -188,6 +188,7 @@ nodes to be present and contain the properties described
below.
# On ARM 32-bit systems this property is optional and
can be one of:
allwinner,sun6i-a31
+ allwinner,sun8i-a23
arm,psci
brcm,brahma-b15
marvell,armada-375-smp
diff --git a/arch/arm/mach-sunxi/platsmp.c b/arch/arm/mach-sunxi/platsmp.c
index 587b0468efcc..e8483ec79d67 100644
--- a/arch/arm/mach-sunxi/platsmp.c
+++ b/arch/arm/mach-sunxi/platsmp.c
@@ -121,3 +121,72 @@ static struct smp_operations sun6i_smp_ops __initdata =
{
.smp_boot_secondary = sun6i_smp_boot_secondary,
};
CPU_METHOD_OF_DECLARE(sun6i_a31_smp, allwinner,sun6i-a31, sun6i_smp_ops);
+
+static void __init sun8i_smp_prepare_cpus(unsigned int max_cpus)
+{
+ struct device_node *node;
+
+ node = of_find_compatible_node(NULL, NULL, allwinner,sun8i-a23-prcm);
+ if (!node) {
+ pr_err(Missing A23 PRCM node in the device tree\n);
+ return;
+ }
+
+ prcm_membase = of_iomap(node, 0);
+ if (!prcm_membase) {
+ pr_err(Couldn't map A23 PRCM registers\n);
+ return;
+ }
+
+ node = of_find_compatible_node(NULL, NULL,
+allwinner,sun8i-a23-cpuconfig);
+ if (!node) {
+ pr_err(Missing A23 CPU config node in the device tree\n);
+ return;
+ }
+
+ cpucfg_membase = of_iomap(node, 0);
+ if (!cpucfg_membase)
+ pr_err(Couldn't map A23 CPU config registers\n);
+
+}
+
+static int sun8i_smp_boot_secondary(unsigned int cpu,
+ struct task_struct *idle)
+{
+ u32 reg;
+
+ if (!(prcm_membase cpucfg_membase))
+ return -EFAULT;
+
+ spin_lock(cpu_lock);
+
+ /* Set CPU boot address */
+ writel(virt_to_phys(secondary_startup),
+cpucfg_membase + CPUCFG_PRIVATE0_REG);
One question I couldn't find any answer to is that does the SMP bit is
set in secondary_startup?
I couldn't find where it was set, but it still looks like the right
thing to do, so I would expect the code to do that.
I don't see it either. The sun8i code is just the sun6i code with the
power clamps removed. And sun6i secondary_startup was removed some time
ago in commit 1146b600044d (ARM: sunxi: fix build for THUMB2_KERNEL).
ChenYu
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
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
[linux-sunxi] Re: [PATCH 1/2] ARM: dts: sun4i: a10-lime: Override and remove 1008MHz OPP setting
On Thu, Mar 19, 2015 at 2:57 PM, Siarhei Siamashka
siarhei.siamas...@gmail.com wrote:
On Thu, 19 Mar 2015 10:39:32 +0800
Chen-Yu Tsai w...@csie.org wrote:
The Olimex A10-Lime is known to be unstable when running at 1008MHz.
Signed-off-by: Chen-Yu Tsai w...@csie.org
---
arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts
b/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts
index 31dc2f1c3870..16ecb8938e19 100644
--- a/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts
+++ b/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts
@@ -74,6 +74,20 @@
status = okay;
};
+cpu0 {
+ /* The A10-Lime is known to be unstable when running at 1008 MHz */
+ operating-points =
+ /* kHzuV */
+ 96 140
+ 912000 140
+ 864000 130
+ 72 120
+ 528000 110
+ 312000 100
+ 144000 90
+ ;
+};
+
ehci0 {
status = okay;
};
Thanks for the patch. At least it should make my A10-OLinuXino-LIME
working without obvious failures out of the box (the U-Boot is still
another story though and there is a gap during boot up when the board
is running with unreliable settings, but the probability of a failure
is rather low).
I should also mention that using 960MHz @1.4V does not fail, but it does
not have any safety headroom either (the cyan 'sun4i_poorlime' line
on the plot):
http://people.freedesktop.org/~siamashka/files/20140512/sunxi-cpufreq-plot.png
On the other hand, my board is on the worst part of the spectrum (many
other a10-lime boards do not fail even at 1008MHz), so maybe having
extra safety headroom is less necessary.
An interesting question is whether the same problem may be reproducible
on the Allwinner A10 devices other than A10-OLinuXino-LIME. My original
problem report
https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg04343.html
mentioned the A10-OLinuXino-LIME rev.A and introduced some sort of
a bias by itself. At least I have seen people saying something like
my a10-lime revision is not rev.A, so it's none of my concern and
I'm not going to bother running any tests. So far we have accumulated
reports from 4 or 5 people having this reliability problem on their
A10-OLinuXino-LIME (various revisions, not just rev.A), but not
much from the other boards owners.
Anyway, this particular patch is
Tested-by: Siarhei Siamashka siarhei.siamas...@gmail.com
Acked-by: Siarhei Siamashka siarhei.siamas...@gmail.com
Good to hear it works. Did you test all the settings? I copied the
wrong settings, from sun5i-a13.dtsi instead of sun4i-a10.dtsi.
I'll send a fixed version later.
ChenYu
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [PATCH 2/3] ARM: sun8i: Add SMP support for the Allwinner A23
Hi Kevin, On Thu, Mar 19, 2015 at 12:05:06PM +0800, kevin.z.m...@gmail.com wrote: One question I couldn't find any answer to is that does the SMP bit is set in secondary_startup? I couldn't find where it was set, but it still looks like the right thing to do, so I would expect the code to do that. I don't see it either. The sun8i code is just the sun6i code with the power clamps removed. And sun6i secondary_startup was removed some time ago in commit 1146b600044d (ARM: sunxi: fix build for THUMB2_KERNEL). ChenYu The SMP bit should be set in the function of __v7_ca7mp_setup, which is located in the file: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/mm/proc-v7.S?id=refs/tags/v4.0-rc4 I'm not sure if this is your discussion. It is, but I wasn't seeing it called anywhere in the secondary_startup code path. I was expecting a direct call, but it looks like it's a dynamic call, with a function-pointer like call, that is indeed run both in the kernel entry point and the secondary_startup. https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/kernel/head.S?id=refs/tags/v4.0-rc4#n389 Thanks! 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 1/2] ARM: dts: sun4i: a10-lime: Override and remove 1008MHz OPP setting
On Thu, 19 Mar 2015 16:17:30 +0800
Chen-Yu Tsai w...@csie.org wrote:
On Thu, Mar 19, 2015 at 2:57 PM, Siarhei Siamashka
siarhei.siamas...@gmail.com wrote:
On Thu, 19 Mar 2015 10:39:32 +0800
Chen-Yu Tsai w...@csie.org wrote:
The Olimex A10-Lime is known to be unstable when running at 1008MHz.
Signed-off-by: Chen-Yu Tsai w...@csie.org
---
arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts
b/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts
index 31dc2f1c3870..16ecb8938e19 100644
--- a/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts
+++ b/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts
@@ -74,6 +74,20 @@
status = okay;
};
+cpu0 {
+ /* The A10-Lime is known to be unstable when running at 1008 MHz */
+ operating-points =
+ /* kHzuV */
+ 96 140
+ 912000 140
+ 864000 130
+ 72 120
+ 528000 110
+ 312000 100
+ 144000 90
+ ;
+};
+
ehci0 {
status = okay;
};
Thanks for the patch. At least it should make my A10-OLinuXino-LIME
working without obvious failures out of the box (the U-Boot is still
another story though and there is a gap during boot up when the board
is running with unreliable settings, but the probability of a failure
is rather low).
I should also mention that using 960MHz @1.4V does not fail, but it does
not have any safety headroom either (the cyan 'sun4i_poorlime' line
on the plot):
http://people.freedesktop.org/~siamashka/files/20140512/sunxi-cpufreq-plot.png
On the other hand, my board is on the worst part of the spectrum (many
other a10-lime boards do not fail even at 1008MHz), so maybe having
extra safety headroom is less necessary.
An interesting question is whether the same problem may be reproducible
on the Allwinner A10 devices other than A10-OLinuXino-LIME. My original
problem report
https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg04343.html
mentioned the A10-OLinuXino-LIME rev.A and introduced some sort of
a bias by itself. At least I have seen people saying something like
my a10-lime revision is not rev.A, so it's none of my concern and
I'm not going to bother running any tests. So far we have accumulated
reports from 4 or 5 people having this reliability problem on their
A10-OLinuXino-LIME (various revisions, not just rev.A), but not
much from the other boards owners.
Anyway, this particular patch is
Tested-by: Siarhei Siamashka siarhei.siamas...@gmail.com
Acked-by: Siarhei Siamashka siarhei.siamas...@gmail.com
Good to hear it works. Did you test all the settings?
You have nailed it. I was about to send the results of the full
round of tests after running them a bit longer and revoke the
initial Tested-by.
Turns out that the 312MHz and 144MHz operating points fail to work
reliable and tend to deadlock:
Testing CPU 0
960 MHz OK
912 MHz OK
864 MHz OK
720 MHz OK
528 MHz OK
312 MHz OK
144 MHz Write failed: Broken pipe
Testing CPU 0
960 MHz OK
912 MHz OK
864 MHz OK
720 MHz OK
528 MHz OK
312 MHz .Write failed: Broken pipe
I copied the wrong settings, from sun5i-a13.dtsi instead of sun4i-a10.dtsi.
I guess, this explains the problems at lower operating points.
I'll send a fixed version later.
Thanks.
--
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.
[linux-sunxi] Fwd: Re: [media-codec] media-codec / cedar released as LGPL, but where is the source? (#5)
Luc, Sunxi-community, It looks like they replaced a few function (names only) so the symbols don't show up with a simple grep (I cannot find ff_huff_build_tree for example). Can anybody confirm/deny that they went over a list of a few functions just to change the names/obfuscate things? The symbols still show a mix and match of coding style (camelcase etc etc) which still indicates a lot of copy/paste. I don't even know how this all works legally, so curious on that regard too. Anyhow, if somebody can help with some 'proof', that'd be great, though I'm sure they just obfuscate (if i'm right about that) some more. Olliver Forwarded Message Subject: Re: [media-codec] media-codec / cedar released as LGPL, but where is the source? (#5) Date: Thu, 19 Mar 2015 00:42:57 -0700 From: allwinner-zh notificati...@github.com Reply-To: allwinner-zh/media-codec reply+0013009d911e6a9cdfd4aa8b9bd4bea2b90606ffdbe5170792cf00011122400192a169ce03bfc...@reply.github.com To: allwinner-zh/media-codec media-co...@noreply.github.com CC: Olliver Schinagl oli...@schinagl.nl No, there is none GPL issues in the media-codec-lib. Please provide the evidence to me. — Reply to this email directly or view it on GitHub https://github.com/allwinner-zh/media-codec/issues/5#issuecomment-83393411. -- 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] Fwd: Re: [media-codec] media-codec / cedar released as LGPL, but where is the source? (#5)
On Thu, Mar 19, 2015 at 11:05:30AM +0100, Olliver Schinagl wrote:
Luc, Sunxi-community,
It looks like they replaced a few function (names only) so the symbols
don't show up with a simple grep (I cannot find ff_huff_build_tree for
example). Can anybody confirm/deny that they went over a list of a few
functions just to change the names/obfuscate things? The symbols still
show a mix and match of coding style (camelcase etc etc) which still
indicates a lot of copy/paste.
I don't even know how this all works legally, so curious on that regard too.
Anyhow, if somebody can help with some 'proof', that'd be great, though
I'm sure they just obfuscate (if i'm right about that) some more.
Olliver
Forwarded Message
Subject: Re: [media-codec] media-codec / cedar released as LGPL, but
where is the source? (#5)
Date: Thu, 19 Mar 2015 00:42:57 -0700
From: allwinner-zh notificati...@github.com
Reply-To: allwinner-zh/media-codec
reply+0013009d911e6a9cdfd4aa8b9bd4bea2b90606ffdbe5170792cf00011122400192a169ce03bfc...@reply.github.com
To: allwinner-zh/media-codec media-co...@noreply.github.com
CC: Olliver Schinagl oli...@schinagl.nl
No, there is none GPL issues in the media-codec-lib.
Please provide the evidence to me.
Yes. Jens Kuske alerted me to that a few days ago. I have done the
legwork on one of those functions, but was too busy yesterday to make a
stink about it yet.
What is shown below is next to lgpl symbols that i had identified before
and which (also) still remain, and which i will not expose to allwinner
today, as i know how they will react. What Jens told me about is
separate, and new, and therefor shows just how nasty this game of
Allwinner is.
H264FillDefaultRefList() and a lot of code around it is straight out of
the libavcodec h264 decoder. The original name for that function is
ff_h264_fill_default_ref_list() in libavcodec/h264_refs.c:
https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/h264_refs.c#L115
This is new, as some totally different code for h264 was available in
the previous versions of the cedarx binaries.
When Allwinner stated that they did CedarX2.0 about two months ago, they
added _more_ lgpled code. But this time they tried to trivially disguise
the code origins. This is a totally new low for Allwinner, and it shows
clearly that they have no licensing control over the contents of their
binary driver, and that no-one can believe them when they state that
they are adhering to licenses. No matter what binaries Allwinner
produces, nobody can believe that these are completely Allwinners
property and that Allwinner has the right to distribute such software.
Attached is the manual decompilation of H264BuildDefList() (originally
build_def_list() in h264.c). This can be compared easily by
looking at
https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/h264_refs.c#L67
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.
int
H264BuildDefList(uint8_t *arg0, uint32_t *arg1, uint32_t arg2, uint32_t arg3,
uint32_t arg4)
{
int j = 0;
int k = 0;
int i = 0;
while ((j arg2) || (k arg2)) {
while ((k arg2) (!arg1[k] || !(arg4 arg1[k][0xA4])))
k++;
while ((j arg2) (!arg1[j] ||
!((arg4 ^ 3) arg1[j][0xA4])))
j++;
if (k arg2) {
if (arg3)
arg1[k][0x10] = k;
else
arg1[k][0x10] = arg1[k][0x0C];
H264SplitFieldCopy(arg0[224 * i], arg1[k], arg4, 1);
k++;
i++;
}
if (j arg2) {
if (arg3)
arg1[j][0x10] = j;
else
arg1[j][0x10] = arg1[j][0x0C];
H264SplitFieldCopy(arg0[224 * i], arg1[j], arg4 ^ 3, 0);
j++;
i++;
}
}
return i;
}
Re: [linux-sunxi] Re: r3p2 version of the Mali driver A20
Thank you all, So, the last hope is what Siarhei Siamashka is suggesting? Any chance this will happen? BR, @lex On Thursday, March 19, 2015 at 8:42:32 AM UTC-3, Henrik Nordström wrote: ons 2015-03-18 klockan 06:17 -0700 skrev @lex: I have looked into ODROID r4p0 blobs and headers and did not find any EULA, perhaps it is kept with the sources? http://forum.odroid.com/viewtopic.php?f=52t=4956 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] Fwd: Re: [media-codec] media-codec / cedar released as LGPL, but where is the source? (#5)
Hey, On 19-03-15 12:39, Luc Verhaegen wrote: On Thu, Mar 19, 2015 at 11:05:30AM +0100, Olliver Schinagl wrote: snip When Allwinner stated that they did CedarX2.0 about two months ago, they added _more_ lgpled code. But this time they tried to trivially disguise the code origins. This is a totally new low for Allwinner, and it shows clearly that they have no licensing control over the contents of their binary driver, and that no-one can believe them when they state that they are adhering to licenses. While you are 100% correct and true, I do want to say, this may not be Allwinner in general, just some lone engineer* (and maybe his direct manager) that are responsible. It very well does reflect badly on Allwinner together, as they communicate it as such to the outside world. I still have hope for Allwinner as a company. * I heard in the past, that the cedarX code was written by some engineer who didn't really care for OSS and wanted to do his thing on his little island. How much of this is true and how much of this is in the past, I don't know, just some background. I myself doubt, that a manger is pushing him to keep it closed, if anything it sounds like it would be the reverse. This all being just my view and opinion of the case however. 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: r3p2 version of the Mali driver A20
ons 2015-03-18 klockan 06:17 -0700 skrev @lex: I have looked into ODROID r4p0 blobs and headers and did not find any EULA, perhaps it is kept with the sources? http://forum.odroid.com/viewtopic.php?f=52t=4956 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] Fwd: Re: [media-codec] media-codec / cedar released as LGPL, but where is the source? (#5)
On Thu, Mar 19, 2015 at 12:44:40PM +0100, Olliver Schinagl wrote: Hey, On 19-03-15 12:39, Luc Verhaegen wrote: On Thu, Mar 19, 2015 at 11:05:30AM +0100, Olliver Schinagl wrote: snip When Allwinner stated that they did CedarX2.0 about two months ago, they added _more_ lgpled code. But this time they tried to trivially disguise the code origins. This is a totally new low for Allwinner, and it shows clearly that they have no licensing control over the contents of their binary driver, and that no-one can believe them when they state that they are adhering to licenses. While you are 100% correct and true, I do want to say, this may not be Allwinner in general, just some lone engineer* (and maybe his direct manager) that are responsible. It very well does reflect badly on Allwinner together, as they communicate it as such to the outside world. I still have hope for Allwinner as a company. * I heard in the past, that the cedarX code was written by some engineer who didn't really care for OSS and wanted to do his thing on his little island. How much of this is true and how much of this is in the past, I don't know, just some background. I myself doubt, that a manger is pushing him to keep it closed, if anything it sounds like it would be the reverse. This all being just my view and opinion of the case however. Olliver Still. Allwinner could not be in a worse position with their CedarX driver. I think the time for letting Allwinner bullshit us and stall us is over completely now. 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] Re: [RFC] Serial number on sunxi devices
On 17/03/15 07:15, Olliver Schinagl wrote: Hey Iain, On 17-03-15 01:38, Iain Paton wrote: The eeproms are physically present on all boards as far as I can tell, however on every olinuxino I have, they are blank from the factory (i.e. content of every byte is 0xFF). Yeah they are all blank, with good purpose, it's for the user to define what to do with it ;) That's all good, up until we hard-code a format into u-boot or the kernel at which point the user doesn't get to decide anymore. 3) Allows for configurable format As for 3, not sure how feasible that is. Where do you store the storage definition? First few bytes defines the storage, then the actual storage? While possible, it adds a lot of overhead. But as always, everything is up for discussion. Perhaps it could be something defined in a Kconfig entry? Compile time configurable will probably be ok for most things. Easier, yes, but not useful at all. On our end, for example, we want to have our own unique serial numbering scheme, unrelated to Olimex's numbering. Now we may use olimex boards, in the future, we may decide to build our own boards, for example. Exactly. I simply want something that, as far as possible, covers all of those possibilities. Not something that only fits a single, use for a single person, where the rest of us have to carry patches to make it useful for us as well. -- 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] Directions for video engine support (CedarX)
On 19 March 2015 at 11:39, Simos Xenitellis simos.li...@googlemail.com wrote: On Wed, Mar 18, 2015 at 11:48 AM, Michal Suchanek hramr...@gmail.com wrote: Hello, as this does not seem to get any attention from anyone who has some idea about VE I will try to write some high level info which is hopefully not completely wrong. On 16 March 2015 at 14:44, Simos Xenitellis simos.li...@googlemail.com wrote: Hi All, I recently I had a conversation with Manuel about what can be done for better support for the video engine (CedarX) that is found in the A-series of SoCs from Allwinner. The way I understood all these was that there are short-term and long-term goals for better support with the video engine. The long-term goal would be to support CedarX in Video4Linux2 (V4L2), as it is already described in http://linux-sunxi.org/VE_Planning It makes sense to have CedarX supported in V4L2 (Linux kernel) as it is part of the mainlining process of the Allwinner SoCs. There are some open questions that need discussion (such as feasibility, what resources are needed, etc). This is most likely feasible. If the current v4l2 framework cannot work with cedar hardware it should be updated to work with it. Existing hardware is undisputable reality. In addition, it is important to describe the benefits from having CedarX support in V4L2 and especially when we should expect to have the first benefits when starting work on this. The benefit is that the v4l2 framework is a standard linux interface. Presumably adding support for v4l2 on application side and writing v4l2 driver on kernel side should be something you do once for good. From then on the application should not be bothered by new hardware codecs emerging and the codec drivers not bothered by new applications emerging. Practically different applications use different features and different codecs implement different features so there is always room for finding new and exciting bugs everywhere. Also Cedar will probably be one of the first VEs to have such driver. As it looks that this would be a difficult task, it would make sense to make a case that Allwinner may want to allocate resources towards this direction. The ability to perform hardware audio/video encoding and decoding even as soon as the Linux kernel boots up, from the A10 SoC and onwards, would be amazing. However, does a video engine driver in V4L2 offer any benefits on Android? I have no idea. Technically the Android media framework is just another application which can grow a v4l interface and be done with this for good. If such driver exists and for which versions of Android is another question. In terms of projects and software that support V4L2, there are the least those at http://en.wikipedia.org/wiki/Video4Linux Many of those are for watching video on screen (i.e. HDMI output or LCD). Wouldn't there be a bottleneck with the current state of video drivers on Linux? Totally. And if it turns out that the chosen buffer manager does not work with the KMS driver it would have to be replaced to interface to KMS and see something on the screen. For an application to encode video from USB cameras (or MIPI, if available/usable) and stream over the network, I suppose it can implement it directly (V4L2) or use some existing software library. It looks like there would be no big problems here apart from bottlenecks elsewhere (number of cameras sending data, ethernet/wifi bandwidth). Also for the directly attached cameras you need an image postprocessor driver as it turns out the image quality is unusable otherwise. With the USB cameras you might have harder time adapting the driver so it can pass the (uncompressed) image data without kernel copying the buffers which costs a lot of memory bandwidth. The important message here would be that if the benefits are really great, then it would justify to put many resources. When looking at https://github.com/torvalds/linux/tree/master/drivers/media/platform (Manuel pointed me to these), there is already a driver for Samsung SoCs (dir: s5p-jpeg and s5p-mfc) and also a driver for the Coda video engine for Freescale SoCs (dir: coda). So Cedar would be 3rd. Also related is that the v4l2 driver should share buffers with any image postprocessing engine(s) and display engine(s) (such as the sunxi KMS driver) and camera drivers using some kernel-wide buffer management. Ideally, the buffers can be passed around by a handle without the application using the drivers ever looking at them (unless it has some actual use for the data) or the kernel copying them. Hardware restrictions and driver defects may apply. I would like to let Manuel to take over here, explain and expand on what his thoughts are. The short-term goals would be to use better what is available now, include libvdpau (anything needs fixing?) AFAIK the libvdpau is more proof of concept than a finished driver. It is usable
Re: [linux-sunxi] Directions for video engine support (CedarX)
(The subject has, CedarX is the name of the proprietaries libraries, and by so is not my business.) On Thu, 19 Mar 2015 12:39:22 +0200 Simos Xenitellis simos.li...@googlemail.com wrote: Would it make sense then to just focus on V4L2? I did not find an initial driver for V4L2. I would think the first step would be to have a driver that just detects the presence of the video engine hardware and report any details that the hardware can provide. As said we have for more than 1 year all the information(from reverse engineering) need to start, meaning that we could have already a V4l2 driver in somewhat functional state by now. If only there was more support. I took the task to start this driver, but every week there are only distractions, that hit hard in the motivation. And this last weeks are a very good example, to see this huge disregard of the software licenses used. Makes me wonder how in the future the license of this v4l2 driver will be handled. It's very simple, if you all want a proper mainlined driver for this video engine, then you all should support the people working to make this a reality. -- 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.
