Re: [linux-sunxi] sun6i SPL support status update
Op 1 apr. 2014, om 21:55 heeft Olliver Schinagl oliver+l...@schinagl.nl het volgende geschreven: 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 :) 2 wire interface is a way of avoiding paying NXP royalties for I2C while still producing the same hardware :) regards, Koen 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. -- 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: [RFC 4/5] ARM: sun6i: dt: Add new sun6i-a31-m9 dts file for Mele M9
On Fri, Mar 28, 2014 at 11:39:39AM +0100, Hans de Goede wrote:
Hi,
On 03/28/2014 11:21 AM, Maxime Ripard wrote:
On Thu, Mar 27, 2014 at 04:56:34PM +0100, Hans de Goede wrote:
Hi,
On 03/27/2014 10:59 AM, Maxime Ripard wrote:
On Wed, Mar 26, 2014 at 09:18:00PM +0100, Hans de Goede wrote:
Add a new sun6i-a31-m9 dts file for the Mele M9 / Mele A1000G Quad. These
HTPCs use the same board in a different case, for more details see:
http://linux-sunxi.org/Mele_M9
Signed-off-by: Hans de Goede hdego...@redhat.com
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/sun6i-a31-m9.dts | 30 ++
2 files changed, 31 insertions(+)
create mode 100644 arch/arm/boot/dts/sun6i-a31-m9.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index aaa130e..5c02aac 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -291,6 +291,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += \
sun5i-a13-olinuxino.dtb \
sun5i-a13-olinuxino-micro.dtb \
sun6i-a31-colombus.dtb \
+sun6i-a31-m9.dtb \
sun7i-a20-cubieboard2.dtb \
sun7i-a20-cubietruck.dtb \
sun7i-a20-olinuxino-micro.dtb
diff --git a/arch/arm/boot/dts/sun6i-a31-m9.dts
b/arch/arm/boot/dts/sun6i-a31-m9.dts
new file mode 100644
index 000..c95ee77
--- /dev/null
+++ b/arch/arm/boot/dts/sun6i-a31-m9.dts
@@ -0,0 +1,30 @@
+/*
+ * Copyright 2014 Hans de Goede hdego...@redhat.com
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+/include/ sun6i-a31.dtsi
+
+/ {
+model = Mele M9 / A1000G Quad top set box;
+compatible = mele,m9, allwinner,sun6i-a31;
+
+chosen {
+bootargs = earlyprintk console=ttyS0,115200;
+};
How much memory does it have? You could probably add a memory node here.
It has 8x hynix h5tq2g83efr, so 2 GiB.
I don't see a memory node in any of the other sunxi dts files either,
isn't that supposed to get dynamically added by u-boot ?
It does, but not on the A31, since we don't have any DT-enabled u-boot
(yet). So providing a default for the A31 boards is a good idea for
the time being.
Well I've just send a patch series to get us a dt enabled u-boot for the A31
(even though it still uses boot0 + boot1). I think that is the better way
forward ...
Yep, of course, and this is why we don't need it on the other SoCs,
but I'd like to keep it around for a while for the A31, waiting for
u-boot to catch up and be completely featureful.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
Re: [linux-sunxi] Current u-boot crashes my cubietruck!
Hi, On 04/01/2014 10:45 PM, Olliver Schinagl wrote: Top Posting! I found the culprit. FAST_MBUS breaks it. After 48 hours of runs, enabling fast_mbus immediately breaks it even after boot. Jens and Emilio hinted that the 3.4 driver reads the FEX file for the voltage. So the higher freq. runs at a lower voltage and that may cause it. That is an interesting theory, which should be easy to verify. When you've some time can you edit the fex file and change dcdc3_vol to 1300 in there, generate a new script.bin and give that a try with a u-boot with FAST_MBUS enabled ? So I'll run without fast mbus for now, and it's stable again. Rock Solid if I may. Sorry for all the noise :( No need to be sorry this is very valuable info! Either we need to revert FAST_MBUS support or update dcdc3_vol in all fex files for boards which have FAST_MBUS set. Regards, Hans Olliver 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 ... 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] [A20] sunxi framebuffer overlay help needed
Well, as far as I can see, the community is actively working on fixing Sunxi kernel, although it seems that interest in 3.4 kernel is somehow descending. Anyway, I thought that someone would use overlay from original disp driver, which is why I posted fixes for it - same goes for CSI. As I said before, even though everything is dirty and buggy, abstraction level is much easier to grasp in contrast with Freescale i.MX series kernels, at least for beginner/intermediate in Linux programming... And honestly, it seems that A20 is suffering from much less HW bugs than i.MX6, at least as far as I can see. On Monday, March 31, 2014 5:53:52 PM UTC+2, Siarhei Siamashka wrote: On Mon, 31 Mar 2014 08:33:29 -0700 (PDT) Ivan Kozic jimm...@gmail.com javascript: wrote: Hi Luc, Found out why disp driver has choppy overlay - for me overlay comes through DMA from memory. Funny thing - disp_malloc is fetching cached memory, so choppiness or trailing is due to caching framebuffer protected memory. Very silly - I found this out by changing caching method of ARM from WRITEALLOC to WRITETHROUGH, also waited 10 minutes for system to boot up :) The matter is solved by adding the following line to disp_mmap() function: vma-vm_page_prot = pgprot_noncached(vma-vm_page_prot); Solved. Just wondering how people were using this before... As far as I know, nobody is using these bug ridden memory allocators that Allwinner has implemented in disp and g2d drivers. Except for maybe Allwinner itself in their Android code. -- 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] MK802 device pages.
Hi, After Codekipper improved the originally horribly mk802 page, i went and split it out. There are now mostly NDHed MK802 and variants pages available at: http://linux-sunxi.org/Rikomagic_mk802 http://linux-sunxi.org/Rikomagic_mk802%2B (MK802+) http://linux-sunxi.org/Rikomagic_mk802ii http://linux-sunxi.org/Semitime_g2 (MK802+ A10s) If you happen to own this hardware, please spend a few minutes on verifying and fixing the information on these pages, and perhaps add some missing photos. Thanks. 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] MK802 device pages.
On 2 April 2014 17:59, Luc Verhaegen l...@skynet.be wrote: Hi, After Codekipper improved the originally horribly mk802 page, i went and split it out. There are now mostly NDHed MK802 and variants pages available at: http://linux-sunxi.org/Rikomagic_mk802 http://linux-sunxi.org/Rikomagic_mk802%2B (MK802+) Hi Luc, I'm on the case with the mk802+ bits that are missing. Just torn it apart and will soon be revealing to world my shocking soldering. CK http://linux-sunxi.org/Rikomagic_mk802ii http://linux-sunxi.org/Semitime_g2 (MK802+ A10s) If you happen to own this hardware, please spend a few minutes on verifying and fixing the information on these pages, and perhaps add some missing photos. Thanks. 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. -- 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: A10 versus A20 , gtkperf result.
On Sunday, March 23, 2014 1:33:15 PM UTC-4, Rajesh Mallah wrote: Hi , I use gtkperf to get an idea of 2D graphics performance. the A20 based Mele M3 completes in 19secs the A10 based Cubieboard1 completes in 32 secs. both using fbturbo xorg driver . Is that much difference expected or does it needs to be _further_ investigated ? please lemme know. Regds mallah. You haven't provided nearly enough information for anyone to possibly comment on the results. What versions of the kernel did you use? What linux disto? What (if any) Mali version? Did you use the A20 Mali driver that supports the MP2? What CPU clock speeds? What DRAM clock speeds? What MBUS clock speeds? Did you run gl2mark? -- 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] MK802 device pages.
On Wed, Apr 02, 2014 at 07:47:25PM +0200, Code Kipper wrote: Hi Luc, I'm on the case with the mk802+ bits that are missing. Just torn it apart and will soon be revealing to world my shocking soldering. I've done worse. But smashing stuff, i just took it off the NDH_TODO category :) I am amazed that your board is blue though, a search on the interweb gives green boards. The layout seems to match, on a superficial glance, so it seems ok. I have taken out the info that i had found on the interweb (like for identification) and rely upon your info instead. But great indeed, another device properly documented. Thanks! 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: A10 versus A20 versus A20 , gtkperf result.
Dear Siamashka List , executing Xorg and gtkperf in different cpus using taskset does makes a difference. It was possible to cut down from 25secs to 17secs. Now I am happy with my new toy (board) :) I will also take a closer look at your other suggestions of investigation. Thanks Regds mallah. On Thu, Mar 27, 2014 at 12:12 AM, Siarhei Siamashka siarhei.siamas...@gmail.com wrote: On Tue, 25 Mar 2014 03:23:54 +0530 Rajesh Mallah mallah.raj...@gmail.com wrote: I also observed that a clone of the rootfs from Mele M3 to another A20 based TB Box consistently performed slower than Mele M3. MeleM3 :18.95 secs Other A20: 25 secs the dump from a10-meminfo-static were same in both the cases except for dram_zq param Can anyone pls explain why the difference in the A20 based boards itself ? To profile this use case, we can run the following command: $ DISPLAY=:0 perf record -e cpu-clock -a gtkperf -a This instructed perf to collect statistics for the whole system from all CPU cores while gtkperf is running. Now after we have all the statistics collected, we can check the percentage of CPU usage for different processes: $ perf report -s pid 49.02%gtkperf:19651 30.54% Xorg:19603 18.75%swapper:0 0.69%kworker/0:1:19569 0.32%xkbcomp:19656 0.31%xkbcomp:19655 0.12% perf:19650 This means that some of the time the CPU cores were idle (swapper). The CPU usage in gtkperf is almost twice higher than in Xorg. You can also run 'perf report' to see the time spent in each individual function (if you have debugging symbols). Now there is indeed one strange thing. If I run 'htop' while gtkperf is running, I can sometimes see that only one CPU core is fully loaded while the other is completely idle. And both gtkperf and Xorg processes are running on the same fully loaded CPU core. As an experiment (on an Allwinner A20 based Cubietruck board), we can try pinning gtkperf and Xorg processes to CPU cores. Start Xorg and pin it to the CPU core 0: # taskset -c 0 Xorg Then run gtkperf pinned to the same CPU 0 core as Xorg: $ DISPLAY=:0 taskset -c 0 gtkperf -a Total time: 26.78 And also pinned to a different CPU 1 core for comparison: $ DISPLAY=:0 taskset -c 1 gtkperf -a Total time: 19.44 When Xorg and gtkperf are running on different CPU cores, the performance is better. Without using taskset to pin processes to CPU cores, gtkperf result is somewhere between these 19.44 and 26.78 times, typically closer to the latter one. It basically looks like the CFS scheduler in the linux-sunxi 3.4.79 kernel is not doing a stellar job for gtkperf. However a similar gtkperf behaviour can be also observed on ARM Chromebook (dual-core Cortex-A15 1.7GHz), when using exactly the same rootfs: Total time: 9.35 (just run gtkperf without any tweaks) Total time: 9.82 (Xorg and gtkperf pinned to the same CPU core) Total time: 7.11 (Xorg and gtkperf pinned to different CPU cores) -- 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.
Re: [linux-sunxi] Re: A10 versus A20 , gtkperf result.
Ooops! I shall soon thanks regds , mallah. I am loosing track of all my chinese toys lately ! -- 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 Fri, 28 Mar 2014 14:21:33 +0100 Jens Kuske jensku...@gmail.com wrote: On 03/28/2014 11:42 AM, Siarhei Siamashka wrote: 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/ Nice tool, I already used memtester but didn't bother to load the GPU. 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. BTW, I did not mean that the tRFC patch is bad or anything. Just that no impact is observable on my hardware. Now I also have some data ready for the dcdc3 voltage tweaks as discussed on IRC a few days ago: http://irclog.whitequark.org/linux-sunxi/2014-04-01#6986335; Your observation about the dcdc3 voltage being set wrong was really spot on! Kudos for the multimeter based debugging :-) And dcdc3 really affects the maximum stable memory clock speed (stable in terms of passing the lima-memtester tests). Though changing it to 1.3v (as needed for MBUS) was not really enough to get clearly distinct results, so I pushed it even further to 1.35v. The A20 datasheet does not seem to be providing the valid voltage range for VDD-DLL: https://github.com/OLIMEX/OLINUXINO/blob/master/HARDWARE/A20-PDFs/A20%20Datasheet%20v1.0%2020130227.pdf?raw=true But I optimistically assumed that up to 1.4v might be fine. Anyway, with dcdc3 voltage set to 1.35v, I could run lima-memtester successfully for many hours on my Cubieboard2 with dram clock set to 528MHz. That's at least 24MHz more than was previously possible with dcdc3 set to 1.25v The Cubietruck is a bit different story. In general, when running lima-memtester, the following outcomes are possible: a) it runs infinitely or until terminated by the user (success) b) the device deadlocks (an obvious fail) c) the memtester log starts showing errors (a fail too) With dcdc3 originally set to 1.25v on my Cubietruck, lima-memtester fails pretty fast (typically in less than 15 minutes) and most of the failures are the device deadlocks. With dcdc3 increased to 1.35v, lima-memtester still fails, but takes much longer and the failures are reported as memtester errors in the log. Again, testing both with and without the tRFC patch in u-boot does not seem to change anything. I have the following preliminary theory. It looks like the deadlocks and memtester log errors are the symptoms of two (or more?) distinct problems. The deadlocks seem to be caused by insufficient dcdc3 voltage, and some percentage of A20 chips may be really sensitive to low dcdc3. I wonder if that's the primary cause of the 480MHz dram clock stability problems on some small percentage of Cubieboard2 devices? http://irclog.whitequark.org/linux-sunxi/2013-07-29#4520613; And the regular memtester errors with 1.35v dcdc3 are probably indicating that the traces to DDR3 are not so good on the Cubietruck PCB. Or the timings are too tight for one of the unlucky DDR3 chips in my Cubietruck. Either way, this is probably not dcdc3 voltage related. And not tRFC related either. I'll keep running tests and will provide an update if something new gets discovered. Looks like my cubietruck is a bad test device, it successfully run memtester at 504MHz for 24h and also lima-memtester runs good till now (two loops finished ok). You have an unusual definition of bad ;-) I'm not very happy having Cubietruck with slow dram, because being lower than the sunxi-typical 480MHz dram speed may affect the credibility of benchmark results. But using Cubietruck instead of Cubieboard2 is important when testing for bus address calculation bugs on systems with 2GiB of RAM. I myself would prefer to have it the other way around. A Cubieboard, which can reliably clock dram at 480MHz. And a Cubieboard2, which can't. I didn't want to stir up too much hope for faster memory, only wanted to mention the possibility. There are many other dram timing parameters that depend on things like clock speed but don't get calculated anywhere. They must be somewhere in .tpr[0-2] and therefore fixed at some (hopefully big enough) value. The tRFC was fixed for 400MHz, so with some bad luck the other parameters are also dimensioned for 400MHz. There are generally two sets of
